ROLLING UPDATES AND MULTITIER APPLICATIONS
The absolute requirement in a CD system is the ability to orchestrate rolling updates among various architecture tiers in an application. Ansible’s unique multitier, multistep orchestration capabilities, combined with its push-based architecture, allow for extremely rapid execution of these types of complex workflows. As soon as one tier is updated, the next can begin, easily sharing data between tiers.
One of the core features of Ansible that enables this is the ability to define “plays,” which select a particular fine-grained group of hosts and assign some tasks (or “roles”) for them to execute. Tasks are typically declarations that a particular resource be in a particular state, such that a package be installed at a specific version or that a source control repository be checked out at a particular version. Ansible Playbooks are reusable, which saves IT staff substantial time in defining roles and tasks.
In most web application topologies, it is necessary to update particular tiers in a tight sequence. For instance, the database schema may need to be migrated and the caching servers flushed prior to updating the application servers.
More importantly, it is vital to not be managing the applications and configuration of the system for all systems in production at the same time.
When services restart, they may not be immediately available. Replacing an application version may also not be instantaneous. It is important to be able to take machines out of a load balanced pool prior to update. It is also then critical to be able to automate the actions of taking machines in and out of the pool.
Ansible allows you to control the size of a rolling update window through the “serial” keyword. Additionally, Ansible’s rolling update handling is smart enough so that if a batch fails, the rolling update will stop, leaving the rest of your infrastructure online.
CONTINUOUS DEPLOYMENT OF MANAGEMENT CONTENT
In addition to CD of production services, it’s also possible to continuously deploy Ansible Playbook content itself. This allows systems administrators and developers to commit their Ansible Playbook code to a central repository, run some tests against a stage environment, and automatically apply those configurations to production upon passing stage. This allows the same software process used for deploying software to be applied to configuration management, reaping many of the same benefits.
As software or configuration change is a significant cause of unintended outage, both automated testing and human review can be useful measures to implement. This can be coupled with a code review system, like Gerrit (gerritcodereview.com), to require sign off from multiple users before changes are applied.
ROLLING UPDATES AS APPLIED TO LOAD BALANCING AND MONITORING
Ansible works well with tools such as load balancers in the course of executing a rolling update. In the middle of any Playbook “host loop,” it is possible to say “do this action on system X on behalf of host Y.”
This includes both communicating with load balancers of all kinds, as well as flagging outage windows for particular hosts to disable monitoring alerts for the hosts currently being updated. Simple idioms like “disable monitoring - remove from pool - update tier - add to pool - enable monitoring” allow for updates without downtime or false alarm pager alerts that work in an automated manner every time without manual intervention.
INTEGRATED STAGE TESTING WITH ANSIBLE
Using Red Hat Ansible Automation Platform with multiple inventory sources allows for testing an Ansible Playbook with a stage environment and requiring successful execution of an update prior to rollout into production. This setup, while optional, is ideal for modeling production update scenarios (perhaps at a smaller scale) prior to updating systems in the real world. Just use the “-i” parameter to an Ansible Playbook to specify what inventory source the Playbook should run against, and use the same Playbook for both stage and production.
VERSION CONTROL-BASED DEPLOYMENT
Various organizations like to package their applications with OS packages (RPM, debs, etc.) but in many cases, particularly for dynamic web applications, such packaging is unnecessary. For this reason Ansible contains numerous modules for deploying straight from version control. A Playbook can request that a repository be checked out at a specific tag or version, and then the system will make sure this is true across the various servers. Ansible can report change events to trigger additional follow up actions when the version of software needed to change, so that associated services are not restarted unnecessarily.
INTEGRATIONS WITH MONITORING TOOLS
Because Ansible is an orchestration system, integrations can be made with APM monitoring tools as well. For instance, let’s assume that during an integration test or deployment, an APM system has an agent that needs to be installed/updated on the application. Ansible can have a Role that handles the install of the agent against the application stack. Once the agent is online, Ansible can then set alerts up (if they don’t already exist) in the monitoring stack. This monitoring can then provide immediate data back to teams interested in the deployment; letting them know if the application is running without issue.
If something were to occur with the application in production after the upgrade, Ansible could be invoked by the monitoring tool to revert to a previously known good build of the application. Obviously this can be done if, and only if, the application will allow for the reverted build.
CALLBACKS AND PLUGGABILITY
When building and deploying code using CI/CD, it can often be useful to provide alerts when events occur. Ansible includes several features to do this, including an integrated mail module. Additionally, a callback facility allows for plugging in notifications with arbitrary systems, which can include chat broadcasts (IRC, Campfire, etc), custom logging, or internal social media.
THE DESIRED STATE RESOURCE MODEL AS APPLIED TO DEPLOYMENT
One of the key features that makes Ansible interesting for software deployment is the use of state-based resource model, made popular in configuration management tooling, within the process of updating software. While traditionally some open source tooling has had to be supplemented with additional deployment software and scripts, this is not the case for Ansible.
This is made possible by the ability for Ansible to finely control the order of events between different tiers of systems, to delegate actions to other systems, and also to mix resource model directives (“the state of package X should be Y”) versus traditional command patterns (“run script. sh”) in the same process.
Ansible also allows easily executing commands to test for various conditions, and then make conditional decisions based on the results of those commands. By unifying configuration and deployment under one toolchain, it is possible to reduce overhead of managing different tooling, and also achieve better unification between OS and application policy.