High-Level View

When it comes to the architecture, Ansible is a straightforward automation engine. Its components and the relationships among them are shown in Figure 2.

Ansible works by connecting via ssh to the hosts (without the need for a special agent to be installed on the host itself), and by pushing modules to the hosts itself. The modules are then executed locally on the host, and the output is pushed back to the Ansible server.

Since it uses ssh, it can very easily connect to clients using SSH-Keys authentication, which simplifies the whole process.

Figure 2: Ansible orchestration engine architecture

Users

Users are simply the developers, operators, and DevOps practitioners who are writing or executing the automation scripts. This automation and orchestration script is called the Ansible playbook. A user can execute those scripts by using the Ansible orchestration engine.

Modules

Modules are executed directly on remote hosts through playbooks or by running them individually from the command line. Modules, therefore, are the units of code Ansible executes.

Each module has a particular use, from administering users on a specific type of database, to managing VLAN interfaces on a specific type of network device.

Ansible allows users to write their own modules and provides out-of-the-box core (maintained by the Ansible team) or extras modules (maintained by community).

Some of the most commonly used modules are:

• File handling: file, stat, copy, template
• Remote execution: command, shell
• Service management: service
• Package management: apt, yum, bsd, ports
• Source control system: git, subversion

To get an idea of the scope of the available Ansible modules, take a look at the list of all modules.

Plugins

Plugins should not be confused with Ansible modules. While modules are executed on the managed hosts, plugins are extensions to the Ansible runtime. Operations such as data transformation, logging of the output, and inventory handling are plugins.

Plugins are often working in conjunction with modules.

Inventories

Ansible works against multiple managed nodes or hosts that are part of the infrastructure, and the list of those items is also known as the inventory.

Inventory is a file, defined in a YAML or INI format, that contains a list of hosts (nodes) along with their IP addresses, servers, and databases, which need to be managed. Ansible then takes action via a transport to connect to them: ssh for UNIX, Linux, or networking devices; and WinRM for Windows system.

Ansible playbooks

Playbooks are files (scripts) that combine configuration, deployment, and orchestration functions. Playbooks are executed to provide a way of automating the remote systems in a consistent and repeatable manner.

Playbooks will execute predefined tasks, such as installing a new package on a remote system, and tasks on their own will use modules to provide such a functionality. In that sense, playbooks can be seen as the ultimate place where all the automation code converges.

Playbooks are human-readable and use the YAML format, which is easy to write and understand.