Tricks Of The Trades

Ansible – Installing and Running

Pinterest LinkedIn Tumblr

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.

Arch Linux

Ansible has a Pacman package in the community repository.

  1. $ sudo pacman -S ansible

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:

  1. $ yaourt -S ansible-git


Open up the Debian software sources file.

  1. $ sudo vim /etc/apt/sources.list

Add the following line to /etc/apt/sources.list:

deb trusty main

Add the Ansible software repository key to the system; it’s the same source as the Ubuntu PPA.

  1. $ sudo apt-key adv –keyserver –recv-keys 93C4A3FD7BB9C367

Update the package manager to verify the changes and then install Ansible itself:

  1. $ sudo apt-get update
  2. $ sudo apt-get install ansible


Install the common software properties package if you don’t already have it.

  1. $ sudo apt-get install software-properties-common

Add the official Ansible package repository to the system and update the package manager database.

  1. $ sudo apt-add-repository ppa:ansible/ansible
  2. $ sudo apt-get update

Install Ansible from the newly added package repository.

  1. $ sudo apt-get install ansible


Fedora users can install Ansible directly:

  1. $ sudo yum -y update
  2. $ sudo yum -y install ansible


EPEL must be configured before trying to install Ansible on these systems.

  1. $ sudo yum -y update
  2. $ sudo yum -y install ansible

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:

  1. $ cd .ssh/
  2. $ ssh-keygen -t rsa -b 4096 -C “ansible-control-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.

  1. $ ssh-copy-id -i ansible-control-host -p 3980 [email protected]
  2. $ ssh-copy-id -i ansible-control-host -p 3980 [email protected]
  3. $ ssh-copy-id -i ansible-control-host -p 3980 [email protected]

Next open the main Ansible configuration file; which is explained more in a latter section.

  1. sudo vim /etc/ansible/ansible.cfg

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.



  1. # if set, always use this private key file for authentication, same as
  2. # if passing –private-key to ansible or ansible-playbook
  3. private_key_file = ~/.ssh/ansible-control-host

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.

  1. $ sudo mv /etc/ansible/hosts /etc/ansible/hosts.orig

Begin writing to a new buffer to create a new “hosts” file.

  1. $ sudo vim /etc/ansible/hosts

Add the contents of the next code snippet into the hosts file, substituting in the IP addresses of your remotes in the process.



  1. [servers]
  3. remote.two.ip.address
  4. remote.three.ip.address

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:


  1. [servers]
  2. server-name-1 ansible_user=username ansible_port=3980
  3. server-name-2 ansible_host=remote.two.ip.address ansible_user=username ansible_port=3980
  4. server-name-3 ansible_host=remote.three.ip.address ansible_user=username ansible_port=3980

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 (ansible.cfg).

4 – Test Ansible Connectivity

An Ansible module named “ping” is useful for testing the previous host file configuration we added.

Note that 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.

  1. $ ansible all -m ping

A successful hosts and SSH key configuration returns an output similar to:

  1. hostname1 | SUCCESS => {
  2. “changed”: false,
  3. “invocation”: {
  4. “module_args”: {
  5. “data”: null
  6. },
  7. “module_name”: “ping”
  8. },
  9. “ping”: “pong”
  10. }
  11. hostname2 | SUCCESS => {
  12. “changed”: false,
  13. “invocation”: {
  14. “module_args”: {
  15. “data”: null
  16. },
  17. “module_name”: “ping”
  18. },
  19. “ping”: “pong”
  20. }
  21. hostname3 | SUCCESS => {
  22. “changed”: false,
  23. “invocation”: {
  24. “module_args”: {
  25. “data”: null
  26. },
  27. “module_name”: “ping”
  28. },
  29. “ping”: “pong”
  30. }

Manual options are also sometimes added to these ad hoc Ansible commands.

Here -u selects a Linux user to issue the command as:

  1. $ ansible all -m ping -u <username>

Furthermore the -b option triggers the command to be run with sudo privileges:

  1. $ ansible all -m ping -u <username> -b

This is all with the “ping” module example, but live commands are just as easy.

  1. $ ansible all -a “/bin/echo hello world!”

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 df program:

  1. $ ansible -m command -a “df -h” servers

Example output from one host:


  1. hostname1 | SUCCESS | rc=0 >>
  2. Filesystem Size Used Avail Use% Mounted on
  3. /dev/disk/by-label/DOROOT 30G 6.1G 22G 22% /
  4. udev 10M 0 10M 0% /dev
  5. tmpfs 202M 25M 178M 13% /run
  6. tmpfs 505M 0 505M 0% /dev/shm
  7. tmpfs 5.0M 0 5.0M 0% /run/lock
  8. tmpfs 505M 0 505M 0% /sys/fs/cgroup
  9. tmpfs 101M 0 101M 0% /run/user/1001

Checking disk space on multiple nodes has never been easier!

  1. $ ansible -m command -a “free -h” servers

Example output from one host:

  1. hostname2 | SUCCESS | rc=0 >>
  2. total used free shared buffers cached
  3. Mem: 1.0G 875M 134M 25M 187M 570M
  4. -/+ buffers/cache: 117M 892M
  5. Swap: 2.0G 32K 2.0G

Query the system’s uptime of only one requested host using the assigned alias from the hosts file:

  1. $ ansible -m command -a “uptime -p” hostname3

Example output:


  1. hostname3 | SUCCESS | rc=0 >>
  2. up 7 weeks, 1 day, 7 minutes

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:

  1. * ANSIBLE_CONFIG (an environment variable)
  2. * ansible.cfg (in the current directory)
  3. * .ansible.cfg (in the home directory)
  4. * .ansible.cdg (in /etc/ansible/ansible.cfg)

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.

  1. sudo vim /etc/ansible/ansible.cfg

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.


  1. #inventory = /etc/ansible/hosts

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.


  1. #forks = 5

To control whether an Ansible playbook prompts for a sudo password when sudoing – set this next directive to true.


  1. #ask_sudo_pass = True

Similarly to set whether an Ansible playbook prompts for a password when run – set this next line to true.


  1. #ask_pass = 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.

  1. #remote_port = 22

Set the time out value for SSH queries here on this line:


  1. # SSH timeout
  2. #timeout = 10

Enable playbook logging capability in the specified directory on these lines here:


  1. # logging is off by default unless this path is defined
  2. # if so defined, consider logrotate
  3. #log_path = /var/log/ansible.log

Who doesn’t like cowsay ?


  1. # don’t like cows? that’s unfortunate.
  2. # set to 1 if you don’t want cowsay support or export ANSIBLE_NOCOWS=1
  3. #nocows = 1

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.


  1. [privilege_escalation]
  2. <…>
  3. [paramiko_connection]
  4. <…>
  5. [ssh_connection]
  6. <…>
  7. [accelerate]
  8. <…>
  9. [selinux]
  10. <…>

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.

  1. drwx—— 2 scarlz scarlz 4096 Jun 21 15:12 ./
  2. drwx—— 3 scarlz scarlz 4096 Jun 21 15:12 ../

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 chmod / chown or failing that delete the directory then re-run Ansible.

Write A Comment