From manual tmsh to an AS3 pipeline
A platform team manages 140 virtual servers across two BIG-IP pairs. Application teams currently submit tmsh scripts that network operations runs manually. Deployments are weekly, and last month a script removed a pool member from production because it used a stale list. The team wants a pipeline that creates and updates virtual servers, pools, and iRules from Git. They propose posting a full configuration declaration to /mgmt/shared/appsvcs/declare on every run, using the admin account stored in the CI tool, and ignoring the asynchronous response because 'the API returns 200'. The BIG-IP pair is active/standby, and the team wants changes to survive failover. A security review requires least privilege and an audit trail of who changed what. The pipeline must also be safe to rerun after a partial failure without deleting unrelated services.
1. Evaluate the proposed full-declaration AS3 approach. What are the failure modes, and how should declarations be scoped?
Read the worked answer
A full declaration across every application on every run is dangerous because AS3 treats a tenant declaration as the desired state for that tenant. If the declaration is stale or incomplete, objects omitted from it can be removed. That is the same stale-list failure the team is trying to escape, just at a larger scale. Concurrent pipeline runs can also overwrite each other, and a partial failure can leave a tenant half-applied.
Scope declarations per application or per self-contained tenant. Each application team owns its tenant and declares only its virtual servers, pools, monitors, and iRules. Do not mix unrelated services in one tenant, and do not post a global declaration from every pipeline. Before posting, read the current declaration with GET /mgmt/shared/appsvcs/declare and compare it with the intended state so the pipeline detects drift. Make the declaration idempotent: rerunning it should produce the same result, not duplicate objects.
Use a non-production pair to validate the declaration first. Keep a rollback declaration and test that removing an application is an explicit, reviewed action rather than a side effect of a missing file.
2. How should the pipeline handle AS3 asynchronous responses and verify success?
Read the worked answer
Do not treat an HTTP 200 or 202 as proof that the configuration is live. AS3 accepts a declaration and returns a task identifier when processing is asynchronous. The pipeline should read the response body, extract the task ID, and poll GET /mgmt/shared/appsvcs/task/ until the task reaches a terminal state. Inspect the results array for per-service failures, not just the top-level status.
After completion, read back the tenant declaration with GET /mgmt/shared/appsvcs/declare/ and compare the key objects with what was intended. Check that the virtual server is available and that pool members are healthy. On failure, stop the pipeline and surface the AS3 error message; do not continue to the next stage as if the change succeeded.
For validation errors, AS3 returns an error response before creating a task, so the pipeline must handle both immediate rejection and asynchronous task failure. Log the task ID, declaration version, and commit hash so an operator can trace a production change back to Git.
3. What identity, authorization, and HA-sync controls would you put in place?
Read the worked answer
Replace the shared admin account with per-team service accounts that have only the access needed for their partitions or AS3 tenants. Use a role that can manage application objects and AS3 declarations without granting user management, network configuration, or access to other partitions. Store credentials in a secrets manager, rotate them, and issue short-lived tokens where possible. The CI tool should not hold an admin password in plaintext.
For audit, send BIG-IP logs to a remote syslog server and retain AS3 task results and pipeline logs. Each service account should identify the team, so a change can be attributed to a person or pipeline run rather than to 'admin'.
In an active/standby pair, apply changes to the active device and then sync the configuration to the standby. Verify synchronization with the configuration-sync status before declaring success, and do not run the pipeline against both devices independently. Test failover after a pipeline deployment to confirm the new objects exist on the standby and that traffic groups move correctly.