When your infrastructure landscape becomes larger and larger you definitely need a tool which helps you in managing your servers, no matter if pḧysical or virtual, running in the cloud or not. One tool (many others are around) which assists you in provisioning, configuration management and mass deployment is Ansible. If you look at the man page you can find this sentence: “Ansible is an extra-simple tool/framework/API for doing ‘remote things’ over SSH.”. What is better than learning by doing? Lets start:

I have three CentOS 7.2 core installations:

hostname description ip
ansible-control The ansible control host. All Ansible commands will be executed from here
ansible-pg1 The first host that will be managed by Ansible
ansible-pg2 The second host that will be managed by Ansible

All of these hosts are on the same CentOS release (although that does not really matter):

[[email protected]~]$ cat /etc/centos-release
CentOS Linux release 7.2.1511 (Core)

Obviously the first step is to get Ansible installed on the control host. There is nothing we need to install on the hosts we want to manage. Ansible does not require to setup any agents which is one of the main advantages over other tools. The only requirement is ssh. There are various ways to get Ansible installed but for the scope of this post we’ll go with yum as Ansible is available in the EPEL repository. Lets add the repository:

[[email protected]~]$ yum install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
[[email protected]~]$ rpm -qa | grep epel

From there on installing Ansible is just a matter of using yum:

[[email protected]~]$ yum install -y ansible

At the time of writing this will install version 1.9.4 of Ansible:

[[email protected] ~]$ ansible --version
ansible 1.9.4
  configured module search path = None

Yum will take care of all the dependencies (e.g. python) and setup everything for us. Before starting to work with Ansible (because we do not want to work with root) all three hosts get a group and a user created. So, for all hosts:

[[email protected]~]$ groupadd ansible
[[email protected]~]$ useradd -g ansible ansible
[[email protected]~]$ passwd ansible 
[[email protected]~]$ su - ansible
[[email protected]~]$ ssh-keygen -t rsa

The generation of the ssh keys is important as we’ll use password-less ssh authentication for talking from the control host to the managed hosts. To succeed with this we’ll need to copy the ssh ids from the control host to the managed hosts:

[[email protected] ~]$ ssh-copy-id -i .ssh/id_rsa.pub [email protected]
[[email protected] ~]$ ssh-copy-id -i .ssh/id_rsa.pub [email protected]

How does the control host know which hosts it shall manage if nothing gets installed on the clients? Quite easy: there is a configuration file in /etc/ansible. As we do want to work with our dedicated user we’ll change the permissions:

[[email protected]~]$ chown -R ansible:ansible /etc/ansible/*

Using the Ansible user we can now create our first hosts file:

[[email protected] ~]$ cat /etc/ansible/hosts

The name in brackets is a so called group name. This means be referencing “postgres-servers” in the Ansible commands Ansible resolves the group name to the server names listed for that group. Lets do a basic test to check if we can talk to our clients:

[[email protected] ~]$ ansible postgres-servers -a "/bin/echo 11" | success | rc=0 >>
11 | success | rc=0 >>

Cool, works. We can run the same command on both clients. If there are more clients you can tell Ansible to use N parallel forks to execute the commands by using the “-f” switch (5 is the default):

[[email protected] ~]$ ansible postgres-servers -a "/bin/echo 11" -f 5 | success | rc=0 >>
11 | success | rc=0 >>

You might already guessed it from the naming of the clients that there will be something about PostgreSQL in this post. And, you’re right 🙂 To outline one use case for Ansible we’ll setup PostgreSQL on two hosts in exactly the same way using Ansible in the next post.