Ansible is one of many configuration management tools but has its own unique set of differences. The platform aims to provide solutions for the entirety of a setup. With consideration for infrastructure provisioning, application deployment, and overall orchestration taken into account.
Some of its features it uses to achieve this are agentless management, multi-node deployment, ad hoc task execution, module libraries, and use of higher level install scripts referred to as playbooks. Security and reliability is maintained throughout this with SSH as the transport protocol.
Compared to to other CM tools the learning curve is also seen as much lower with Ansible, making it easier to understand and use from the outset. Only Python and a designated control machine are required for the actual installation. With all configuration for the “inventory” assets written in YAML to keep things simple and clean.
1 – Control Machine Installation
The host you want to use as the control machine for Ansible requires Python 2.6 or 2.7 installed. This control machine can be a desktop, laptop, or workstation etc as long it’s running a Linux based OS such as Debian/Ubuntu, Arch, CentOS, RHEL, OS X, or any version of BSD.
Windows as a platform is not currently supported for the control machine.
In this post the commands are shown for installing Ansible onto the control machine using system package managers, and for only a few of the many Linux distributions on offer.
Ansible has a Pacman package in the community repository.
The AUR also has a package build that pulls directly from GitHub called
ansible-git. Any Aurum helper can be used to automatically build and install this, for example:
Open up the Debian software sources file.
Add the following line to
deb http://ppa.launchpad.net/ansible/ansible/ubuntu trusty main
Add the Ansible software repository key to the system; it’s the same source as the Ubuntu PPA.
Update the package manager to verify the changes and then install Ansible itself:
Install the common software properties package if you don’t already have it.
Add the official Ansible package repository to the system and update the package manager database.
Install Ansible from the newly added package repository.
Fedora users can install Ansible directly:
RHEL / CentOS
2 – Remote Nodes SSH Setup
On the remote nodes you want Ansible to interact with you need to register the control machine’s public SSH key. This is as Ansible uses SSH to communicate and operate by default.
To generate a new SSH key for the control machine use the next command on the control machine host:
Then copy the new key across to the remote client nodes; changing the
-p value for your own relevant SSH port number. Along with the usernames plus remote host IP addresses.
Next open the main Ansible configuration file; which is explained more in a latter section.
Locate the lines that describe private key authentication (shown below) and remove the
# symbol whilst adding in the path to the new private key we created.
Save and exit the file.
This forces Ansible to use this private key for all operations by default. An alternative to this would be to use the
ansible_ssh_private_key_file variable in the
hosts file explained later on.
Like with the control machine the remote nodes must have Python installed (2.4 or later) as a prerequisite to using Ansible with them. So any remote nodes that do not have Python already installed must be attended to before continuing.
3 – Ansible Hosts File Setup
Continuing on with the control machine – backup the template Ansible hosts file.
Begin writing to a new buffer to create a new “hosts” file.
Add the contents of the next code snippet into the hosts file, substituting in the IP addresses of your remotes in the process.
This configuration file is very flexible and can be expanded to use variables, aliases, and port numbers. Which is what we need to add to ensure the SSH connectivity.
Note: If your SSH port is the default port 22 on these remote nodes then you do not have to set this upcoming port variable.
Expand the file by adding a hostname alias, host variable, user variable, and port number variable:
Save the changes and exit the text editor.
As an extra option here, adding an
ansible_ssh_private_key_file=~/.ssh/ansible-control-host variable to each host line is another possibility. Instead of what we set in the last step i.e. the default private key directive in Ansible’s main configuration file (
4 – Test Ansible Connectivity
An Ansible module named “ping” is useful for testing the previous host file configuration we added.
all can be replaced for a group name like
server – which is taken from the example earlier to only select those hosts in that group.
A successful hosts and SSH key configuration returns an output similar to:
Manual options are also sometimes added to these ad hoc Ansible commands.
-u selects a Linux user to issue the command as:
-b option triggers the command to be run with
This is all with the “ping” module example, but live commands are just as easy.
You can do this without invoking the program directly and use the
command module with Ansible instead.
Return the “servers” group drive partitions using the
Example output from one host:
Checking disk space on multiple nodes has never been easier!
Example output from one host:
Query the system’s uptime of only one requested host using the assigned alias from the hosts file:
5 – Ansible Configuration File
Custom changes to the Ansible install and how it behaves are made through the configuration files.
Changes in relation to the configuration are processed and picked up in the following order:
In this section we’re taking a quick look at the
ansible.cfg file we modified slightly earlier.
There’s not much wrong with the default contents of the main
/etc/ansible.cfg file, but you may need to delve into it at some point in the future.
Here are some cherry picked lines and directives from the file that may be of interest. Remember if/when setting these to remove the
# symbol to uncomment.
To assign a different directory for a custom hosts file location.
This next line designates the number of parallel processes to generate when talking with remote hosts. The value will always depend upon your hardware capabilities and amount of remote nodes in play.
Higher fork values will help to complete actions across the nodes faster. Assuming you have the hardware needed. A common value is 50, rather than the default of 5.
To control whether an Ansible playbook prompts for a sudo password when sudoing – set this next directive to true.
Similarly to set whether an Ansible playbook prompts for a password when run – set this next line to true.
This sets the default SSH port for all system connections, be aware that any settings in the inventory (e.g. hosts file) will override this.
Set the time out value for SSH queries here on this line:
Enable playbook logging capability in the specified directory on these lines here:
Who doesn’t like
The lines following these let you tweak and customise components of cowsay even further!
After which the remaining sections that have been omitted here contain more background areas of Ansible, should you need to examine or change them in the future.
Any major changes or crucial updates to the configuration file syntax and formatting will likely be pushed to the GitHub development configuration file at:
Or shown in the official documentation.
7 – Ansible Temp Directory Permissions
Should the permissions and or ownership rights of the below directory become allocated to root, Ansible will not be able to write to this directory (and thereby fail to run).
Here’s how the permissions should look; substituted with your own Linux username.
Simply make sure the user you are running Ansible as posseses sufficient permissions to utilise this directory. If this is not the case either alter the permissions with
chown or failing that delete the directory then re-run Ansible.