Ansible: suite of software tools that enables infrastructure as code

Ansible is a suite of software tools that enables infrastructure as code. The suite is open-source and includes software provisioning, configuration management, and application deployment functionality.

Originally written by Michael DeHaan and acquired by Red Hat in 2015, Ansible is designed to configure Unix-like systems and Microsoft Windows. System configuration is defined in part by using its declarative language. Ansible is agentless, relying on temporary remote connections via SSH or Windows Remote Management, allowing PowerShell execution. The Ansible control node runs on most Unix-like systems that can run Python, including Windows, with WSL installed.

Ansible helps to manage multiple machines by selecting portions of Ansible's inventory stored in simple ASCII text files. The stock is configurable, and target machine inventory can be sourced dynamically or from cloud-based sources in different formats (YAML, INI).

Sensitive data can be stored in encrypted files using Ansible Vault since 2014.[16] In contrast with other popular configuration-management software — such as Chef, Puppet, Salt, and CFEngine — Ansible uses an agentless architecture, with Ansible software not normally running or even installed on the controlled node. Instead, Ansible temporarily orchestrates a node by installing and running modules on the node via SSH. For the duration of an orchestration task, a process running the module communicates with the controlling machine with a JSON-based protocol via its standard input and output.[18] When Ansible is not managing a node, it does not consume resources on the node because no daemons are run, or software is installed.

Dependencies

Ansible requires Python to be installed on all managing machines, including pip package manager, configuration-management software, and its dependent packages. Managed network devices require no extra dependencies and are agentless.

Control node

The control node (master host) is intended to manage (orchestrate) target machines (nodes termed as "inventory", see below). Control nodes are only available for Linux; Windows OSs are not supported. Multiple control nodes are allowed. Ansible does not require a single controlling machine for orchestration, ensuring disaster recovery is simple. The controlling node manages nodes over SSH.

Design goals

The design goals of Ansible include:

Minimal in nature. Management systems should not impose additional dependencies on the environment.

Consistent. With Ansible, one should be able to create consistent environments.

Secure. Ansible does not deploy agents to nodes. Only OpenSSH and Python are required on the managed nodes.

Reliable. It is possible to write playbooks that are not idempotent. When carefully written, an Ansible playbook can be idempotent to prevent unexpected side effects on the managed systems.

Minimal learning is required. Playbooks use an easy and descriptive language based on YAML and Jinja templates.

Modules

Modules are primarily standalone and can be written in a standard scripting language (such as Python, Perl, Ruby, Bash, etc.). One of the guiding goals of modules is idempotency, which means that even if an operation is repeated multiple times (e.g., upon recovery from an outage), it will always place the system in the same state.[non-primary source needed]