Category: Configuration Management

Connection types determine how Ansible connects to managed hosts in order to communicate with them. By default, Ansible uses the SSH protocol for remote connection to target nodes. Assuming pipelining is not enabled, Ansible uses this SSH connection to transfer modules and template files, to run remote commands, and to run the plays in the playbook on managed hosts. Thus having a fast, stable, and secure SSH connection is of paramount importance to Ansible. Besides ssh, Ansible offers other connection types which can be used to connect to managedhosts, including paramiko, and local. The connection type can be specified in the Ansible configuration file (ansible.cfg), in the inventory on a host or group basis, inside a playbook, or
on the command-line interface.

Continue reading “Ansible Connection Type”

Ansible may need access to sensitive data such as passwords or API keys in order to configure remote servers. Normally, this information might be stored as plain text in inventory variables or other Ansible files. But in that case, any user with access to the Ansible files or a version control system which stores the Ansible files would have access to this sensitive data. This poses an
obvious security risk.

Continue reading “Ansible Vault”

Ansible Galaxy is essentially a large public repository of Ansible roles. Roles ship with readmes detailing role use and available variables. Galaxy contains a large number of roles that are constantly evolving and increasing. Galaxy can use git allowing for other role sources such as GitHub.

Continue reading “Ansible Galaxy”

When dealing with extensive playbooks, it is easier to split the tasks into roles. This also helps in reusing the roles in the future. Roles are a collection of tasks, which can be moved from one playbook to another, can be run independently but only through a playbook file. In other words, roles are a feature of Ansible that facilitate reuse and further promote modularization of configuration.

Continue reading “Ansible Roles”

Ansible evaluates the return codes of modules and commands to determine whether a task succeeded or failed. Normally, when a task fails Ansible immediately aborts the plays, skipping all subsequent tasks.
However, sometimes an administrator may want to have playbook execution continue even if a task fails. For example, it may be expected that a particular command will fail.

Continue reading “Ansible Handling Errors”