Getting Started With iApps: Components
Our last article, Getting Started with iApps: Conceptual Overview we breezed through iApps are and how they can benefit deployment and management of your nastiest applications. That’s fine and dandy, but the real benefit of iApps is through creation and customization of your very own iApps. To get you started, it’s helpful to understand how iApps are put together, specifically the components involved. This article will get you familiar with the internal workings of iApps and by doing so, lower the intimidation factor they sometimes cause. The iApps Framework: Templates iApp templates generate an application servicefrom user answers related totheir applicationrequirements. Templates provide a procedural graphic interface and context-sensitive help for the administrator. A new deployment uses a a single template to create an interface and guide the user through the configuration process, deploying the configuration when published. For common-deployed infrastructure, a well-defined template can be reused for multiple application services creation. During deployment a template can: Create new configuration objects Reference existing BIG-IP configuration objects, i.e. profiles or monitors Create additional configuration objects dynamically based on template requirements. For example, if an iApp creates a pool member with an IP address that does not already exist as a node, the BIG-IP will create the node automatically Objects created by templates are identified as components of the application service, and can be viewed on the deployed application service component tab. There are 5 sections to make up an iApp Template: Attributes Required BIG-IP modules Min/Max BIG-IP version Presentation Defines User Interface Application Presentation Language (APL is used to build the interface) Implementation Processing code TCL and TMSH commands Macro Creates an iRule dynamically Help HTML-based help tab Inline help (in presentation section) iApps Templates: Attributes The template attributes defined by the developer designate what versions and modules the template needs to execute one or more of the commands defined int presentation and implementation sections. These include: System-supplied property: Indicates if the template is provided with the installed version of BIG-IP or if it was copied/imported elsewhere. This is a read-only field. Required BIG-IP Modules property: This is used to set the required modules that must be provisioned before the template can be used by an application service. Minimum BIG-IP Version property: Displays minimum version of BIG-IP the template supports. If the system does not meet the min requirement, the system will post an invalid-template alert, and does not include make that template available for deployment. Maximum BIG-IP Version property: Displays the maximum version of software supported by the template. Similar to the above minimum version, BIG-IP will issue the same alert and mark it unavailable for deployment. Verification property: Indicates if the template is verified by F5 Support. iApps Templates: Presentation Using the Application Presentation Language (APL), the presentation section builds the user interface for the iApps template being deployed. The user is given a series of questions and options, and answers provided determine the configuration objects created and/or referenced. The APL describes what questions to ask, in what order to ask, how the questions are presented (free form, drop down, lists…), and the names of the variables used to store configuration data prior to publishing the template. Below we can see the APL code defined in F5 NIST SP800-53 RC4 template for the question related to access control. sc10 "Idle Timeouts for Management Access -- AC-2(5), SC-10" sc10.purpose "" sc10.mins "How many minutes for each Idle Timeout value? " sc10.mins_help "" sc10.mins.timeout_gui "Management GUI" sc10.mins.timeout_ssh "SSH" sc10.mins.timeout_console "Console" sc10.mins.timeout_tmsh "TMSH" section sc10 { message purpose "Configure idle timeouts for management access facilities. For each facility the value zero selects a 12-hour timeout." row mins { string timeout_gui required display "small" validator "nonnegativenumber" default tcl { set tmp [tmsh::run_proc nist80053:my_item \ /sys httpd auth-pam-idle-timeout] return [expr {int(($tmp + 59) / 60)}] } string timeout_ssh required display "small" validator "nonnegativenumber" default tcl { set tmp [tmsh::run_proc nist80053:my_item \ /sys sshd inactivity-timeout] return [expr {int(($tmp + 59) / 60)}] } string timeout_console required display "small" validator "nonnegativenumber" default tcl { set tmp [tmsh::run_proc nist80053:my_item \ /sys global-settings console-inactivity-timeout] return [expr {int(($tmp + 59) / 60)}] } string timeout_tmsh required display "small" validator "nonnegativenumber" default tcl { set tmp [tmsh::run_proc nist80053:my_item \ /cli global-settings idle-timeout] return [expr {($tmp eq "disabled") ? 0 : $tmp}] } } optional (intro.help == "show") { message mins_help "For each field, type the number of minutes of idle time that should elapse before the session times out. Using a value of zero (0) sets the timeout to 12 hours (720 minutes)." } } iApps Template: Implementation Using our ol’ standby TCL, this section of the template is written in the TMSH scripting language. This is the programmatic heart of the iApp template and builds the configuration needed to run your application as a unique service. We’re using the same F5 NIST SP800-53 iApp template and the Implementation code shown below is responsible for converting the answers defined in the presentation section into BIG-IP usable commands. #various login timeout settings if {[set tmp [expr {$::sc10__mins__timeout_gui * 60}]] == 0} { set tmp 43200 } elseif {$tmp < 120} { set tmp 120 } iapp_conf "modify /sys httpd auth-pam-idle-timeout ${tmp}" iapp_conf "modify /sys httpd auth-pam-dashboard-timeout on" if {[set tmp [expr {$::sc10__mins__timeout_ssh * 60}]] == 0} { set tmp 43200 } iapp_conf "modify /sys sshd inactivity-timeout ${tmp}" if {[set tmp [expr {$::sc10__mins__timeout_console * 60}]] == 0} { set tmp 43200 } iapp_conf "modify /sys global-settings console-inactivity-timeout ${tmp}" if {[set tmp $::sc10__mins__timeout_tmsh] == 0} { set tmp 720 } iapp_conf "modify /cli global-settings idle-timeout ${tmp}" iApps Templates: Help The help section is html defined and used to either give a large overview of the iApp template being used. The snippet below shows inline help questions that the user might need for specific questions they may not be sure of. This can also be used to help define formatting for more complex questions, such as an LDAP baseDN or LDAP filter to be used. <h6>SC-7 - Boundary Protection</h6> <p>This iApp lets you manage the IP subnets from which BIG-IP management may be accessed as well as services accessible on self IP’s.</p> <h6>SC-10 - Network Disconnect</h6> <p>This iApp exposes several timeout settings for access to the system.</p> <h6>SC-17 - Public Key Infrastructure Certificates</h6> <p>This iApp does not manage TLS/SSL PKI certificates or cryptographic material as such. However, you can select the appropriate certificates and keys for single-ended and mutual authentication of connections to external authentication/directory services.</p> The iApps Framework: Application Services We’ve configured an iApps Template, and clicked Finished. This starts the deployment and creation process of converting your answers into a unique application service and if we have good connections and all services are up, a functional application. A running application service can be administered by clicking reconfigure after selecting it in the iApps Application Services menu. From there, the same questions previously answered during deployment are available for modification. This is useful when IP’s or certificate profiles change and simple and quick updates are needed. The Application Service also provides a Components view that lists each object in use to manage the specific application service and if applicable, it’s operational status. Below is a completed LDAP application service. Note the familiar red diamonds because none of the LDAP servers referenced in this service are available. I’m a bad admin, I know. Also note that I created a CA and made wicked awesome certs just for this example (really I accidentally deleted my old virtual machine with the previous CA). iApps Template: Availability and Support Some of you that frequent DevCentral know there’s a lot of information on iApps available in Codeshare and the Wiki (The wiki is managed by the iApps team so make sure to check it out). However, DevCentral is not on officialsupport channelso here’s a quick breakdown of where to get your variously supported/unsupported iApps.. iApps on the BIG-IP system: Those are created and supported by F5. Enjoy iApps on F5 Support: If there is no RC status (release candidate) then they are supported by F5. iApps on DevCentral’s Codeshare: These are usuallyworks-in-progress, release candidate, user submitted, or F5 submitted; but not certified;none are officially supported. These are use-at-your-own risk but of course you have dev and test environments for just such occasions. You wouldn’t DARE test out an unsupported iApp off DevCentral in your production environment right??? That wasn’t so bad, was it. Now that you have a better understanding of what goes into an iApp, they’re not so intimidating. If you’ve done any iRule coding, you probably have an urge to start modifying one after finishing this article. Check out the different iApps out there on DevCentral and see if you have any upcoming deployments that may benefit from using iApps. Get your developers involved too as iApps are a natural progression in your DevOp’ish plans. Tomorrow our very own Jason “Lord of the Dance and TCL” Rahm will cover modifying and creating iApps so please stay tuned and get your dev hat ready.Getting Started with iApps: A Conceptual Overview
tl;dr - iApps provide admins and service desks a template solution for application deployment and management services. Deploying and managing applications require a lot of information across several disciplines. Architects have their holistic view of the application ecosystem and relevant lifecycles. Developers have their granular relationship with each application under their umbrella. Networks admins make sure applications are behaving appropriately on the network instead of hijacking QoS classes or hijacking DNS. Then there are those missing details that no one wants to own until something breaks (looking at you Java CA store). Originally F5 introduced deployment guides to help administrators understand the requirements and configurations needed to deploy popular applications behind BIG-IP. However, after the deployment was complete, those configurations were still managed through object types alone (e.g. virtual servers, pools, profiles, iRules, monitors). That can get quite tedious when you have hundreds of applications on a single BIG-IP stack. Someone somewhere said “Wouldn’t it be nice if we could have an application-based view of all the different objects that help us deploy, manage, and secure each application”? Enter iApps Introduced in BIG-IP 11.0, iApps are a customizable framework for deploying and managing application as a service. Using out-of-the-box templates, administrators can deploy commonly-used applications such as Oracle, SAP, or Exchange by completing a series of questions that relate to their management and infrastructure needs. Rather than create a bunch of virtual servers, followed by a handful of monitors, then a plethora of whatever, the responses to iApps questions create all of the BIG-IP objects needed to properly run your application. The iApps application service becomes the responsible manager of all virtual servers, monitors, policies, profiles, and iRules required to run. Consolidating these into a single view makes management and troubleshooting much easier to handle. iApps Framework iApps consist of two main elements, the template and application services created by publishing a template. We’ll dive into this in our next article, Getting Started With iApps: Components. Templates: The base configuration object which contains the layout and scripting used to configure and publish application instances. Some templates are prebuilt and included in BIG-IP, while others can be download from DevCentral (are not officially supported) or F5 support (certified and supported). Developer-oriented teams can also build custom templates for frequently used configurations or services. Application Service: An application service is the result of using an iApps template to drive the configuration process. The Administrator uses the configuration utility to create a new application service from the selected iApps template. Created objects are grouped into components of the application service and are managed accordingly. The iApps Advantage iApps are not for everyone. If you like keeping tribal control over your BIG-IP ecosystem or if you like naming virtual servers after your pets, iApps may not be for you. iApps do have an advantage if you want to templatize your deployment scenarios or wish to allow other administrators access to the services they manage. iApps reduce a lot of the mystique and intimidation a lengthy set of profiles, policies, and pools can sometimes cause to the new or intermediate administrator. Above we show an example of building a highly available LDAP namespace for internal applications with the default built-in LDAP iApps template. By providing a certificate and and answering a few questions, an LDAP environment is created for all of your internal directory authentication or lookup requirements. From there, modifying the configuration is easy as selecting the Reconfigure tab in the existing application service. Changing settings within iApps Sometimes you just want a template to assist with application deployment and from there you’re perfectly fine managing the individual object types. The Component view will show you all objects affected by the application service but if you try to apply a change, you’ll receive an error similar to: This is by design because the iApps application service is the rightful owner of the system object and shouldn’t be edited directly. However in certain cases you don’t the iApp anymore or want more granular control of some features the iApps my not have, there is an option. Each application service published via iApps have a Properties tab which allow you to disable the Strict Updates method of management. Unchecked, each object is configurable on it’s own but will deviate from the templates last known state. Some administrators prefer to operate this way, only using the iApp as a deployment method, and that’s perfectly fine. We’re leaving your application management style and method up to you. As BIG-IP expands to cover more of the application landscape, people are increasingly taking advantage of more programmatic features and iApps is no exception. Allowing our administrators to improve their ease of deployment and use is why iApps exist and we’ll continue to develop and improve these features. Our next article Getting Started with iApps: Components will dive into more detail on the properties required to create and manage iApps. Take the time to get to know iApps, they’re your ally for keeping your applications in order.
