Ubuntu Server 18.04 – Getting started with Ansible

How to install Ubuntu Server 19.10

The first thing to know about Ansible is that it changes constantly. New versions with exciting features are released regularly, and it shows no sign of slowing down whatsoever. There is a lot of excitement around this technology, so it’s regularly improving. The reason I’m bringing this up is that many distributions often offer an older version of Ansible in their repositories, with Ubuntu being no exception. This means that if you simply run apt install ansible to get the software from Ubuntu’s repositories, you may get an older version, and that version may not work with example solutions you find online. I think it’s better to get the software from the developers themselves.

The examples in this tutorial were created with Ansible 2.5 in mind. However, depending on when you are reading this, a new version is most likely available. This shouldn’t be an issue  in regards to the examples in this chapter, because Ansible handles backwards compatibility pretty well. Even a newer version should run the code in this tutorial just fine. However, be on the lookout for examples online that utilize features that may not exist in your version (which is where you may run into a problem).

So, what do we do? Simple: we add a PPA to our server that is maintained by the developers of Ansible themselves. This repository will always give you the latest stable version that’s available. Let’s go ahead and get this wonderful tool installed. We’ll install Ansible on a central server (or even just our workstation). We won’t need to install Ansible on the individual hosts that we’ll maintain. As I mentioned, there’s no agent with Ansible, so there’s nothing to install on the clients.

First, we will add this PPA to our central server or workstation:

sudo apt-add-repository ppa:ansible/ansible

Next, let’s update our package indexes:

sudo apt update

Then, we’ll install Ansible itself:

sudo apt install ansible

Now you should have the ansible-playtutorial command available, which is the main binary that is used with Ansible. There are other commands that Ansible provides us, but we’re not concerned with those.

In order to follow along with the remainder of this chapter, it’s recommended that you have at least two servers to work with; the more the better. If you have a virtual machine solution such as VirtualBox available, simply create additional VMs. To save time, consider cloning an existing VM a few times (just make sure you don’t overload your computer/server by over-allocating resources).

The most common workflow of Ansible works something like this: you have a main server or workstation, on which Ansible is installed. While you don’t need an agent on the clients, they will, however, need OpenSSH installed and configured as that’s how Ansible communicates. To make things easy, it’s recommended to have a dedicated Ansible user on each machine, and the Ansible user on the server should be able to connect to each machine without a password. It doesn’t matter what you call the Ansible user; you can simply use ansible or something clever. We already covered how to create SSH keys in Chapter 4, Connecting to Networks, so refer back to that if you need a reminder. Creating users was covered in Chapter 2, Managing Users. In a nutshell, here are the things you should work on in order to set up your environment for Ansible:

  1. Install Ansible on a central server or workstation.
  2. Create an Ansible user on each machine you want to manage configuration on
  3. Create the same user on your server or local machine.
  4. Set up the Ansible user on the server such that it can connect to clients via SSH without a password.
  5. Configure sudo on the client machines such that the Ansible user can execute commands with sudo with no password.

In previous chapters, we covered how to create users and SSH keys, but we have yet to cover the last point. Assuming you named your Ansible user ansible, create the following file:


Inside that file, place the following text:


Next, we need to ensure that the file is owned by root:

sudo chown root:root /etc/sudoers.d/ansible

Finally, we need to adjust the permissions of the file:

sudo chmod 440 /etc/sudoers.d/ansible

Go ahead and test this out. On the server, switch to the ansible user:

sudo su - ansible

Then, to test this out, use SSH to execute a command on a remote machine:

ssh sudo ls /etc

How does this work? You may or may not know this, but if you use SSH to execute just one command, you don’t necessarily need to set up a persistent connection. In this example, we first switch to the ansible user. Then, we connect to (or whatever the IP address of the client is) and tell it to execute sudo ls /etc. Executing an ls command with sudo may seem like a silly thing to do, but it’s great—it allows you to test whether or not sudo works without doing anything potentially dangerous. Listing the contents of a directory is about as innocent as you can get.

It may seem like an awful lot of steps in order to get configuration management working. But make sure you think with a system administrator’s mindset—these setup tips can be automated. In my case, I have a Bash script that I run on each of my servers that sets up the required user, keys, and sudo access. Anytime I want to add a new server to Ansible, I simply run that script on the machine just once, and from that point forward Ansible will take care of the rest.

What should have happened is that the command should have executed and printed the contents of /etc without prompting you for a password. If this doesn’t work, make sure you completed each of the recommended steps. You should have an ansible user on each machine, and that user should have access to sudo without a password since we created a file for that user in /etc/sudoers.d. If the SSH portion fails, check the log file at /var/log/auth.log for clues, as that is where related errors will be saved. Once you have met these requirements, we can get automating with Ansible!

Comments are closed.