You've heard of it, but you haven't done it. You know it's where you want to be, but it's not where you are. You know there exist many ways of doing it, but you don't know where to start.
So how do you go about automating your infrastructure?
A pretty simple yet powerful tool to get you started is Ansible. There are lots of other tools out there for this, but here we will only focus on Ansible.
There are several characteristics of Ansible that make it easy to get started:
- Only you need to have it installed to use it. You don't need to install any software on any other machine.
- There are lots of modules to get you started, so there is a very good chance that Ansible already has a solution to begin automating some of the things you are doing manually today.
- Because it's been around for a while and is widely used, there are lots of examples out there on which you can lean to help you automate just about anything. In addition, Ansible documentation is an excellent resource to get you going.
Ok, that sounds nice, but where do you really begin?
Well, I said you can automate just about anything with this tool, so you can start by taking notes (mental or digital) of the things that you do today that are not automated. And sorry, but writing code, fixing bugs, and doing laundry don't count.
The biggest candidates for automation are tasks you perform by having to SSH onto a server and "do that thing." A few examples may be:
- restart a dying but not-quite-dead process
git pulland "redeploy"
- add someone's public key to a list of
authorized_keysso that someone else can then SSH onto that server and manually do the things you do
- delete old log files from an archive folder because the server is running out of space
Some of those sound familiar to you?
Great! Let's get started.
To get our feet wet, let's try to automate the process of deleting unnecessary log files. This is a good task to start with because deleting files on a server somewhere, especially in an automated fashion that we're not familiar with, should allow for an adequate level of adrenaline in our bloodstream and keep us vigilant for the duration of this blog. As a nice side-effect, we may walk away from this retaining more knowledge than we otherwise would have.
The first step is, obviously, to get Ansible installed, so go ahead and do that now.
But seriously, go and get Ansible installed. You will need it.
Wonderful. Now that you've done that, we have two paths we can take from
here. We can start by either executing a series of one-off
directly on the command line, or we can create a playbook, which is essentially
a file that contains groups of Ansible commands to be run in sequence.
Although we can achieve the same results using either approach, for the purpose of this example we'll choose to create a playbook. Doing so will give us something tangible that we can later move into source control, share with others, and continuously improve upon.
Fire up your favorite editor and create a file called
the following snippet of yaml into that file:
- name: "Delete logs that we for sure 100% won't ever need to look at" hosts: localhost tasks: - name: "Create file" file: path=my-ansible-file state=touch
Now before we run this, let's break it down line by line to make sure we understand what's going on.
The first line, beginning with
- name: "Delete ..., has a strictly informative
purpose: it is a short phrase that communicates to the user what this playbook
does. You can change "Delete logs that ..." to any text you'd like. It should
clearly communicate what this specific playbook is used for.
The line after that,
hosts: localhost, specifies which machine(s) the
playbook should target. Note that we are using
localhost because we didn't
actually create any external machines on which we'd like to operate. I will
show you how to operate on external machines shortly.
Line number three,
tasks:, simply declares that everything below this line will be a list
of tasks (or commands) that should be run on a given machine.
The next line,
- name: Create file is the beginning of our one and only task
that we currently have in this playbook. It is also informative to the user and
meant to communicate what the intent of this specific task is. When the
playbook is run, the string you enter here will get printed to the console when
this task actually begins running.
Finally, the last line,
file: path=my-ansible-file state=touch, is where the
"interesting" stuff happens. This line instructs Ansible to use the file
module to create (touch) an
empty file called
my-ansible-file. Note that because we are targeting
localhost, the file will be created in the directory from which you will run
Now I know that you have gigabytes of juicy data logs that you're anxious to delete, and so far this playbook does not delete anything, but hold on. Let's take small steps so we don't get lost.
In your terminal, in the directory where you saved that file, tell Ansible to run the playbook by using the following command:
You may see some warnings about optional dependencies, or something about missing hosts files–don't worry about those for now. The important thing is that somewhere amidst that output you see something like:
TASK [Create file] ************************************************************* changed: [localhost]
What that means is that your "Create file" task completed successfully. You can
ensure that the file was created by running
ls my-ansible-file and seeing
that it shows up. It will be empty, because we haven't written anything to it,
but it will be present.
Let's just take this one step further and delete the file. Modify your playbook so that it now looks like this:
- name: "Delete logs that we for sure 100% won't ever need to look at" hosts: localhost tasks: - name: "Create file" file: path=my-ansible-file state=touch - name: "Delete that file we just created. Why? I don't know." file: path=my-ansible-file state=absent
The only thing we added there were the last two lines. What this gives us is a playbook that has two tasks: one for creating a file, and one for deleting it immediately after.
Notice that we're using the same file
module for the second task.
The only difference between the two tasks is the
state attribute. The more
you use Ansible, the more you'll realize that
state=absent/present/something-else is actually a pretty common attribute for
a lot of tasks. It typically translates to "make sure this resource does not
exist, and if it does then delete it" or "make sure this resource does exist,
and if it doesn't then create it." The word "resource" here can mean anything
from a server somewhere in the cloud, to a piece of software installed on some
server, to a file as we see here.
Make sure to save the playbook file and rerun the playbook (
This time there should be a little bit more output. Specifically, we should see something like:
TASK [Create file] ******************************************** changed: [localhost] TASK [Delete that file we just created. Why? I don't know.] *** changed: [localhost]
This means that both tasks ran successfully and that the file we created should now be gone.
Pretty cool, huh? Surely, much more interesting than running a simple
touch my-ansible-file && rm my-ansible-file on the command line.
So how do you run this on a server somewhere?
Before we continue, the prerequisite here is that you already have a server up and running somewhere and that you can connect to it over ssh without a password, but a public-private key pair instead. This blog will not show you how to set that up.
Assuming you have that setup, let's continue. And here is where things get a liiiittle bit more complicated. We'll have to do a few things in order to run those same tasks on a remote server:
- Add one line in the
delete-logs.ymlplaybook to specify which user we will be operating as on the server.
- Change one line in the
delete-logs.ymlplaybook so that we operate on "all" machines and not just
- Add parameters to our
ansible-playbookcommand that specify which machine we want to operate on and which private key file should be used for connecting to that machine.
1. Specify user in playbook
Open up the playbook again and, right underneath the first
name key and right
hosts key, add a
user key with the name of a user that you can
use to log in to your server.
2. Change "localhost" to "all"
Modify the playbook and change the value of
hosts key from
After this step, the top of your playbook should look almost identical to:
- name: "Delete logs that we for sure 100% won't ever need to look at" user: dariusz # <- here is where your username goes hosts: all tasks:
3. Add parameters to ansible-playbook command
-i argument can take a list of hosts to operate on or the name of a file
that contains a list of hosts to operate on. We will provide the name of our
host directly on the command line.
The --private-key argument takes the path to a private key file, which can be used to connect to the remote machine as the user you specified in step 1 above.
As an example, if my machine's IP address is
220.127.116.11 and my private key is
/super-secret, then my new playbook command would look like:
ansible-playbook -i "18.104.22.168," --private-key=/super-secret delete-logs.yml
Note the comma after the IP address. The comma signals to ansible-playbook that
what you provided is a list of hosts, and not a path to a file that contains a
list of hosts. Without the comma, ansible-playbook will attempt to read a file
22.214.171.124 and fail.
One other thing to note is that the
--private-key argument is actually
optional if you use your default key (typically located in
connect to the machine.
Run that command and you should see an ouput like:
TASK [Create file] ************************************************************* changed: [126.96.36.199] TASK [Delete that file we just created. Why? I don't know.] ******************** changed: [188.8.131.52]
If you don't this, then you'll probably see an error message telling you that Ansible failed to connect to the host you specified. If that's the case, double-check the path to your ssh key, the username you entered in the playbook file, and the IP address you entered on the command line. Make sure all of these are correct.
If that still doesn't work, then double-check again. This will result in what is commonly known as a triple-check.
Run the command one last time, and you should now see the expected output indicating success. Feel free to manually ssh onto the server and behold that ... nothing actually changed. That's because the same file we created with the first task in our playbook was immediately deleted by the second task.
At this point, you should be able to modify the playbook yourself to delete or create any files you'd like on your server. Go ahead and play around with that and try to create a playbook for removing those space-consuming log files that you were hoping to get rid of earlier. .
Now someone might say that this is stupid, and that really you should have a Cron job for doing these sort of maintenance things like deleting files and freeing space. Thanks for the suggestion, Johnny. That's really not a bad idea. But how would you configure that Cron job? Would you just ssh onto the server and update the crontabs?
This really sounds like something you could use Ansible for. Your crontabs can live in the same repo as your playbooks, and you can use Ansible to get the crontabs onto your servers. What you get here is a repeatable, automated way to deploy crontabs to your server or many servers, and you get source-controlled crontabs at no additional cost. Go ahead and try that as an exercise.
I'm glad you stuck with me through this short and simple exercise on Ansible. By no means was this intended to be an in-depth intro to the tool, but rather a motivation for actually picking it up and starting to use it. Remember, automating your entire infrastructure is not something that happens overnight, or even over a one-week span. It is something that gradually evolves over time to meet the needs of your team and organization.
One thing that's certain is, if it's done correctly and well-maintained, an automated infrastructure will save you and your team a great deal of time. It doesn't come for free, as it needs to be built up and will change as your organization changes, but it certainly beats pages of documentation and manual clicking around when it comes time to "install this piece of software on such and such machine" and "provision a new AWS instance that can be used for this and that."
To leave you with a few words of advice, I recommend that you start small. If you're just getting into infrastructure automation, don't try to tackle the toughest of problems first. Take small, manual tasks that are easy to automate and automate them. This way, not only are you moving forward, but you are also getting more and more comfortable with the tool. The more you use it, the more you will understand it and the easier it will be to tackle bigger and bigger automation tasks. Keep at it, and before long you'll be surprised at how much you have automated!
Secondly, take a peak at Ansible's playbook best practices page. Don't worry about doing everything exactly as they recommend in there, especially in the beginning. Focus on getting stuff working first. As your repository gets bigger and bigger and you see that your team is actually using it, then you can start worrying about making it "proper."
 I highly advise against doing this "playing around" or testing of playbooks on a production server. Be sure to test your playbooks thoroughly on servers where you can't cause any damage.