Created by Michael DeHaan and acquired by Red Hat in 2015, Ansible is an open- source, agentless, tool for software provisioning, configuration management, and application deployment. Users have the flexibility to turn their laptops into an Ansible control station to automate basic tasks, or they can deploy a dedicated host to use Ansible as an orchestration tool to roll out application updates while ensuring minimal downtime. Ansible provides a simple domain-specific language (DSL) to enable these different use cases. Ansible is popular among infrastructure engineers and developers because it requires minimal time and effort to get up and running. Before describing the specifics of Ansible, the following sections provide a high-level overview of how Ansible works.

A basic workflow for Ansible using playbooks looks something like that shown in Figure 17-1:

Figure 17-1 Workflow for Ansible Using Playbooks

1. Engineers create Ansible playbooks in YAML that describe a workflow or the configuration of infrastructure.

2. Ansible playbooks are deployed to an Ansible control station.

3. When the control station runs the Ansible playbooks, they typically copy modules written in Python to remote hosts.

4. Finally, Ansible runs the modules on the remote hosts to perform the work described in playbooks.

Ansible Components

Ansible requires a control machine to run the Ansible tool. By default, Ansible uses a push model to push changes to remote hosts from the Ansible control machine. The control machine can be any Linux/UNIX host with a Python interpreter that supports SSH or the required transport to devices managed by Ansible. Some of the important components of the Ansible control machine are as follows:

Modules are typically written in Python. They are typically copied to remote hosts and run by the Ansible tool. Ansible modules are referenced as tasks in Ansible playbooks or using CLI arguments in the Ansible ad hoc CLI tool.

Inventory files contain the hosts operated by Ansible. They contain group and host definitions that can be referenced by Ansible playbooks or using CLI arguments from the Ansible ad hoc CLI tool. A host can belong to multiple groups.

Playbooks are written in YAML and contain Ansible domain-specific language. To enable reuse, playbooks can be modularized much like software. Variables containing data for playbooks can be separated into YAML files residing on the Ansible control machine.

Configuration files control how the tool runs. For example, the configuration file can change the default directories of the modules.