Use Case: Provisioning new resources and services
Ansible works with and within infrastructure and service pipelines, performing well as a step within the process of provisioning hardware, resources, or services, just as easily as the coordinator of the full request process, taking the defined state from configuration and ensuring necessary resources match that state.
When functioning as a step in the process of provisioning new resources, Ansible playbooks will run as configured to perform commands and API calls to consistently perform the same set of operations each run. Within a playbook, each task is defined in code as a configuration that will be applied against target resources. Those can be API calls, filesystem changes, system commands, or a custom resource, and Ansible will apply the configuration to update those resources to the desired state.
The flexibility of Ansible allows it to take structured requests like API calls, which known or expected inputs and outputs, or amorphous tasks, like complicated shell commands, and define the intended task or command to be executed as well as the expected outcome to verify the success of failure of an action, all in declarative configuration.
Use Case: Deploying changes to applications
Once an application or service has been deployed to production, many of the tasks involved in deploying the project are going to be reused to deploy new versions, additional components, update agents, or migrate it to new hardware. Often, only a subset of the tasks performed to provision the infrastructure are required to deploy version updates, patch dependencies, or configure additional telemetry.
Utilizing Ansible Automation Platform, the deploy process is defined by a template of tasks, inventory, and credentials, and then configured each run by providing variables, like the software or platform version to be deployed, to create a consistent and idempotent change process.
Enterprises can then use those pipelines to create a template to standardize similar project deployments. Multiple teams can use the playbook and central inventory within Ansible Automation Platform and combine them with their own configuration deploy separate projects easily.
Use Case: Remediating drift
In systems that can’t or don’t use immutable infrastructure, it’s vital to ensure that as other changes are made to a system or resource, the current state of deployed resources matches the expected state from a configuration. Ansible allows infrastructure managers to ensure that the expected configuration of a system matches the actual configuration of the system each time a playbook is run.
For each playbook run, Ansible takes a collection of tasks and applies them with the expected configuration against all resources in an inventory. Defining the tasks in an Ansible playbook ensures that each run is idempotent, utilizing the same configuration and running the same collection of tasks each time, so it can safely be run anytime to ensure the target hosts match the expected state, and reconfigure any hosts that do not.
Engineers and sysadmins can also utilize “Check Mode” within Ansible Automation Platform job templates to perform dry runs to locate and document where configuration has started to drift and notify stakeholders before remediation.
Use Case: Incident response
When there is an incident, Ansible standardizes and codifies the process of gathering incident context from affected services, speeding up the investigation and time to resolution of an incident.
Event-Driven Ansible, deployed alongside the Ansible Automation Platform, connects event streams, such as Amazon Kinesis or Apache MQTT, webhooks, or other alerting and event sources, to playbooks within Ansible Automation Platform.
Teams can define playbooks that consist of a set of tasks, like grabbing log data, a list of running processes, or an API result, and send that data to update a ticket in the CMDB and notify the support via Teams or Slack.
Ansible Automation Platform can additional expedite time to resolution by automatically executing playbooks against the target inventory when a known incident occurs. Engineers configure Event-Driven Ansible to invoke playbooks to pull context or parse an event to trigger job templates within Ansible Automation Platform which can perform recovery tasks automatically, reducing the load on support teams.
 | Christopher Gerber, Solutions Architect Chris brings extensive experience in building developer and data platforms on AWS and GCP. As part of our technical pre-sales team, he supports sales efforts and leads projects focused on AWS, GCP, Ansible, CloudFormation, and container implementations. With a passion for enhancing developer experiences and creating resilient platforms, Chris is dedicated to helping clients achieve their goals through innovative solutions. Like what you read? Follow Christopher on LinkedIn |