If you need to deploy hundreds of server or client nodes in parallel, maybe on-premises or in the cloud, and you need to configure each and every single one of them, what do you do? How do you do it? Where do you even begin? Many configuration management frameworks exist to address most, if not all, of these questions and concerns. Ansible is one such framework.

You may have heard of Ansible already, but for those who haven't or don't know what it is, Ansible is a configuration management and provisioning tool. (I'll get to exactly what that means shortly.) It's very similar to other tools, such as Puppet, Chef and Salt.

Why use Ansible? Well, because it's simple to master. I don't mean that the others are not simple, but Ansible makes it easy for individuals to pick up quickly. That's because Ansible uses YAML as its base to provision, configure and deploy. And because of this approach, tasks are executed in a specific order. During execution, if you trip over a syntax error, it will fail once you hit it, potentially making it easier to debug.

Now, what's YAML? YAML (or YAML Ain't Markup Language) is a human-readable data-serialization language mostly used to capture configuration files. You know how JSON is easier to implement and use over XML? Well, YAML takes a more simplistic approach than JSON. Here's an example of a typical YAML structure containing a list:

data:
    - var1:
        a: 1
        b: 2
    - var2:
        a: 1
        b: 2
        c: 3

Now, let's swing back to Ansible. Ansible is an open-source automation platform freely available for Linux, macOS and BSD. Again, it's very simple to set up and use, without compromising any power. Ansible is designed to aid you in configuration management, application deployment and the automation of assorted tasks. It works great in the realm of IT orchestration, in which you need to run specific tasks in sequence and create a chain of events that must happen on multiple and different servers or devices.

Here's a good example: say you have a group of web servers behind a load balancer. You need to upgrade those web servers, but you also need to ensure that all but one server remains online for the upgrade process. Ansible can handle such a complex task.

Ansible uses SSH to manage remote systems across the network, and those systems are required to have a local installation of not only SSH but also Python. That means you don't have to install and configure a client-server environment for Ansible.

Install Ansible

Although you can build the package from source (either from the public Git repository or from a tarball), most modern Linux distributions will have binary packages available in their local package repositories. You need to have Ansible installed on at least one machine (your control node). Remember, all that's required on the remote machines are SSH and Python.

To install on Red Hat or CentOS:

$ sudo yum install ansible

To install on Ubuntu:

$ sudo apt install ansible

Configure Your SSH Keys and Install Them on the Remote Hosts

Life will be much easier once you install SSH keys on each node as an authorized key. The purpose of this exercise is to provision access to each node from the other without requiring a password for each login. This feature facilitates automated and passwordless logins using the SSH protocol. Another name for key-based authentication in SSH is called public key authentication.

Create an RSA key pair:

$ ssh-keygen -t rsa

For the sake of simplicity, let's leave the defaults to both the location of the key and the passphrase. Proceed by pressing enter for every requested input until you return back to the shell prompt.

Once the SSH key has been created, copy the public key to the remote server. In this exercise, you're required to do this from the control node over to the remote node:

$ cat ~/.ssh/id_rsa.pub | ssh user@192.168.1.109 "cat >>
 ↪~/.ssh/authorized_keys"

Replace the user name and IP address as needed. You can make sure that everything works by SSHing to the remote node from your designated control node. If done correctly, you won't be prompted for a password, and you'll automatically log in to the shell of the remote machine.

Define the Remote Machines

Let's define which nodes are going to be the remote nodes from the control node. But before doing that, let's first relocate the default hosts configuration file:

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

Create a new /etc/ansible/hosts file, and define a new group with a list of the IP addresses to be identified under that same group. In this case, let's define a group called web, and underneath it, let's have a single remote node, 192.168.1.109:

[web]
192.168.1.109

If you want to add more to this group, you would do so on a new line. For example:

[web]
192.168.1.109
192.168.1.110
192.168.1.111

If you want to test this on a local machine instead of two or more separate nodes, create a group called local, and add the localhost IP address:

[local]
127.0.0.1

Run Basic Tasks

Now that you've done all of this, you should be able to run tasks on the defined remote servers. But, first let's make sure that all is well. Remember, Ansible needs to be able to log in directly to the remote nodes via SSH and without a password. If you haven't already, please refer to the SSH key section above. Run the following command:

$ ansible all -m ping

Your response should look something like this JSON output for all the nodes in all the groups defined in the /etc/ansible/hosts file:

192.168.1.109 | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python"
    },
    "changed": false,
    "ping": "pong"
}

If you want to run a command to all of your nodes under the group web, and you know that each node in that group is a Debian-based distribution, you would run the following:

$ ansible web -m shell -a 'cat /etc/debian_version'

Note: the -m option defines the module to be used. The first attempt used the ping module, and this example shows invoking the shell for a shell-based command.

The output of the above command will look similar to the following:

192.168.1.109 | CHANGED | rc=0 >>
buster/sid

Now let's say you need to run a command as a completely different user:

$ ansible web --become-user=root -m shell -a 'tail -n5
 ↪/var/log/syslog'

You can rely on the --become-user= option and append the desired user to the parameter. The tail command above will output what you would typically expect:

192.168.1.109 | CHANGED | rc=0 >>
Jun 15 20:17:51 ubuntu-test systemd[1]: Started Session 9
 ↪of user petros.
Jun 15 20:17:52 ubuntu-test ansible-command: Invoked with
 ↪creates=None executable=None _uses_shell=True
 ↪strip_empty_ends=True _raw_params=cat
 ↪/etc/debian_version removes=None argv=None warn=True
 ↪chdir=None stdin_add_newline=True stdin=None
Jun 15 20:25:12 ubuntu-test systemd[1]: Started Session 10
 ↪of user petros.
Jun 15 20:25:13 ubuntu-test ansible-command: Invoked with
 ↪creates=None executable=None _uses_shell=True
 ↪strip_empty_ends=True _raw_params=tail -n5
 ↪/var/log/messages removes=None argv=None warn=True
 ↪chdir=None stdin_add_newline=True stdin=None
Jun 15 20:25:34 ubuntu-test ansible-command: Invoked with
 ↪creates=None executable=None _uses_shell=True
 ↪strip_empty_ends=True _raw_params=tail -n5
 ↪/var/log/syslog removes=None argv=None warn=True
 ↪chdir=None stdin_add_newline=True stdin=None

Create Playbooks

Using these basic functions, you easily can batch a few commands to various nodes across your network, but often you'll find yourself in need of running more than one or two shell commands. This is where Playbooks come into the picture. Playbooks run multiple tasks and provide more advanced functionality than your ad hoc commands.

Say you want to install a few packages when a remote node comes online. You'll need to create a YAML file to capture those actions. Using a text editor, create a file named package-install.yml with the following YAML structure:

---
- hosts: web
  tasks:
   - name: Install Make
     apt: pkg=make state=present update_cache=true
     become: yes
   - name: Install GCC
     apt: pkg=gcc state=present update_cache=true
     become: yes

You're essentially going to tell Ansible that you want to install both the Make and GCC packages (alongside its dependencies) on all nodes in the group web. You also are telling Ansible that you need to install these two packages as a privileged user with the become: yes field.

Now it's time to kick off the Ansible Playbook. If you're not executing as a privileged user already, you need to add the --ask-become-pass option, which will prompt you for a password to su into root to execute the desired actions. This works only if all nodes under the same group share the same user and password schemes:

$ ansible-playbook --ask-become-pass package-install.yml
BECOME password:

PLAY [web]
**************************************************************

TASK [Gathering Facts]
**************************************************************
ok: [192.168.1.109]

TASK [Install Make]
**************************************************************
 [WARNING]: Updating cache and auto-installing missing
 ↪dependency: python-apt

changed: [192.168.1.109]

TASK [Install GCC]
**************************************************************
changed: [192.168.1.109]

PLAY RECAP
**************************************************************
192.168.1.109       : ok=3    changed=2    unreachable=0
 ↪failed=0    skipped=0    rescued=0    ignored=0

Now you should be starting to see some real power here: both Make and GCC have been installed to the nodes in the group.

Handlers

Ansible supports an event-handling system called handlers. A handler is sort of like a task, and it can pretty much accomplish anything a task can do, but it'll instead run when called by another task. A handler will take action only when the event it's listening for is called.

Say your YAML file looks like the following:

---
- hosts: web
  tasks:
   - name: Install Apache
     apt: pkg=apache2 state=present update_cache=true
     become: yes
     notify:
      - Start Apache
  handlers:
   - name: Start Apache
     service: name=apache2 state=started

This instructs Ansible to run a task named "Install Apache", and once it completes, it will notify a handler named "Start Apache" to start the web service. It's able to start the web service via a service module, which supports your typical start, stop, restart and reload commands. (I mentioned the concept of modules earlier, if you can recall both ping and shell.) The output of the above YAML structure should look something like this:

$ ansible-playbook --ask-become-pass package-install.yml
BECOME password:

PLAY [web]
**************************************************************

TASK [Gathering Facts]
**************************************************************
ok: [192.168.1.109]

TASK [Install Apache]
**************************************************************
changed: [192.168.1.109]

RUNNING HANDLER [Start Apache]
**************************************************************
ok: [192.168.1.109]

PLAY RECAP
**************************************************************
192.168.1.109      : ok=3    changed=1    unreachable=0
 ↪failed=0   skipped=0    rescued=0    ignored=0

Summary

The examples here are quite small and limited. As you likely have guessed, you are able to add more tasks and notify more handlers from within a single YAML file. It doesn't need to be limited to just a few. It may take some time and trial and error to build up enough of a list to handle every action in your automated environment. There is so much more that you can do with Ansible and so much more to cover. Although this guide provides a good foundation to get you started, I barely scraped the surface of this extremely powerful configuration management framework.

Resources

• Ansible
• "Ansible: the Automation Framework that Thinks Like a Sysadmin" by Shawn Powers, LJ, August 2017
• "Ansible: Making Things Happen" by Shawn Powers, LJ, September 2017
• "Ansible, Part III: Playbooks" by Shawn Powers, LJ, October 2017
• Ansible, Part IV, Putting It All Together" by Shawn Powers, LJ, November 2017