Overview

This iApp template uses a multi-stage execution flow to allow full deployment of services available on the BIG-IP platform. The number of stages used vary based on the specific features utilized during a particular deployment.

Each stage executes sequentially after the previous stage completes in the following order:

1. Implementation layer TCL code
2. Post depoly bundler iCall script to handle L4-7 policy deployment
3. Post depoly final iCall script to handle deferred TMSH commands

Step 2 above is only executed if deployment of a L4-7 service policy is required. For more details on L4-7 policies see Resource Bundling & L4-7 Policies

Implementation Layer

The Implementation Layer consists of TCL code that executes sequentially and adheres to the underlying ordering required by the BIG-IP platform. The overall flow is as follows:

1. Template startup (determine mode, debug level, input fix-up, etc)
2. SSL/TLS Profile Creation
3. Monitors
4. Pools
5. L7 Policy Creation (may be deferred to postdeploy_final)
6. Virtual Servers
   1. Bundled iRules (see: Resource Bundling & L4-7 Policies)
   2. Profile Processing
   3. SNAT
   4. SSL/TLS Profiles
   5. Policies
   6. Additional Listeners
7. Statistics Handlers
8. Virtual Address Options
   1. Route Advertisement
   2. Advanced Options
9. Post depoly bundler handler creation (only required for WAF/IAM policies)
10. Post depoly final handler creation

postdeploy_bundler

The Post depoly bundler iCall script is scheduled for execution by the Implementation Layer as required. The primary purpose of this script is to create L4-7 policy elements (Resource Bundling & L4-7 Policies) and associate those policies with any required Virtual Servers. Execution can be tracked via the mechanisms detailed in Logging & Debugging or via specific iStat keys that are populated at each step of execution of the script. The iStat keys are tied to the Application Service Object (ASO) that is created by the iApp framework for each deployment. The iStat keys created are:

Key Name	Possible States
deploy.postdeploy_bundler	ASM_IN_PROGRESS ASM_COMPLETE APM_IN_PROGRESS APM_COMPLETE DEFERRED_CMDS_IN_PROGRESS DEFERRED_CMDS_COMPLETE FINISHED
deploy.postdeploy_bundler.asm.<po licy name>	DEPLOY_IN_PROGRESS DEPLOY_COMPLETE
deploy.postdeploy_bundler.apm.<po licy name>	DEPLOY_IN_PROGRESS DEPLOY_COMPLETE

The final action of the Post depoly bundler script is to create an iCall handler that executes the Post depoly final script.

postdeploy_final

The Post depoly final iCall script is scheduled for execution by either the Implementation Layer or the postdeploy_bundler script. The purpose of this script is to execute any final commands that have been deferred to this stage. Additionally this script populates iStat keys that should be used to determine success or failure of the deployment. The iStat keys created are:

Key Name	Possible States
deploy.postdeploy_final	STARTED DEFERRED_CMDS_IN_PROGRESS DEFERRED_CMDS_COMPLETE FINISHED_<epoch timestamp>

Determining Success/Failure of Deployment

To determine overall success of a deployment the upstream system should NOT rely on the state returned via the GUI or API on the initial creation of the deployment. Rather, the

deploy.postdeploy_final

iStat key should be queried for the

FINISHED_<epoch timestamp>

state. A reference implementation of this mechanism can be found in the depoly iapp script helper script. The mechanism implemented performs the following:

1. Capture current start epoch time from deployment system

2. Determine polling interval and max number of polls

3. Loop until max number of polls

   1. Send REST POST to retrieve deploy.postdeploy_final iStat key

   2. Check if returned state starts with

      FINISHED_
      

      1. Check if timestamp returned in state is greater than start time
         1. Return success

   1. Sleep until next polling interval

4. Return failure