Ansible Introduction

Ansible has become a favorite tool for systems operators looking to automate many of their previously manual, or simply scripted processes with its ability to very quickly turn those processes into idempotent automation tasks. Automating the deployment and long-term management of a number of complex distributed web skill systems. While I've found Ansible to be beneficial in its ability to drive consistency in the management of these systems, often Ansible developed for an initial problem is not managed and maintained in a reusable fashion.

So when we talk about Ansible we're really talking about as system that is designed to help us automate systems management tasks. So this things like modifying and managing the state of a configuration file. And it does this based on the concept of a target state that the system should have and that we should try to attain that state. This allows us to create idempotent or repeatable without change types of scripts and that's really the core model behind Ansible. When we look at what that means in terms of how we execute tasks or how we describe things, we're really talking Ansible as programs or plays.

• Play is the term that we use when we talk about Ansible doing something for us, and we wrap our plays in playbooks.

• Now the plays themselves are made up of individual tasks.

• The tasks are a subset, or each task is its own module, and a module could be something simple UNIX command module

If we look at the actual program structure, this is how a play is actually put together.

• We can see that we describe our hosts

• Put those systems together and say how many and which target machines do we want to talk to

• List out the individual tasks that make up that play, including the module that we want to use and any parameters that we might include in that play

• In order to then target those plays against something we have an inventory file, which describes the target systems including the ability to group and further segment the systems

As we add more and more tasks into a single playbook, we find that it's useful to start grouping those tasks in unique or consistent function-like models, basically grouping tasks with something consistent. And we'll then import those sets of tasks into one, master playbook.

If you defined a set of variables that are important to running a task at the top of my file. How do you actually start sharing those? The process of doing that, at least in the Ansible world, is to create a role. And a role has many of these similar sorts of functions. Our tasks end up in a task directory. Our templates end up in a templates directory. In fact, our variables or default variables end up in two different places because there's a variables directory for variables that are actually important to the system that you effectively really do want to change, and there are also a set of defaults which are less likely to change but actually easier to override. And the easiest way to actually get started creating a role, other than just sort of the organic process that I just described here of creating a tasks directory

One of the key value propositions of a tool like Ansible is the fact that you can create a playbook that you should be able to run over and over and over again and have it always provide the exact same results. If we look at our yaml file below, we have a number of different commands that we're running here. For example, a copy command. This is an Ansible module and it will copy the source file to the destination file but it will only do it if the source and destination files are different. So for example if the destination doesn't exist we'll do a copy. Once it exists we'll actually compare the file itself, or at least a file hash, some way of determining if the contents have changed to make sure that we only have to do that copy if the change occurs. That's idempotency.

--- - hosts: web1 tasks:   - name: an idempotent create command copy: src: files/idempotent.txt dest: /tmp/idempotent.txt tags:       - create   - name: an idempotent command lineinfile: dest: /tmp/idempotent.txt regexp: '^(.*)is an(.*)$' backrefs: true line: '\1is really an\2' tags:       - create   - name: a non idempotent command shell: "echo this is a non-idempotent file >> /tmp/non-idempotent.txt" tags:       - create   - name: remove the file we created file: path: /tmp/*idempotent.txt state: absent tags:       - destroy

We can even do things on a file like change that file and that is also an idempotent command. If I rerun this file I'm not going to keep making that same change over and over and over again. In this case I'm going to replace a component inside the file and make it something slightly different.

While most people start with Ansible by using Ansible in the command line there is actually a user interface for Ansible as well and it's actually much more powerful than just what the command line might let us do called Ansible Tower.

We can create different versions of these inventories fairly easily. So we have a web version which just includes the web hosts for example and then we also have a database version which just includes the database host. And we can use this both for just targeting playbooks differently rather than using groups we could use these inventories. But this is actually more powerful because we can actually start limiting visibility into these different inventories to different users because we have, within this environment, an entire roles based access and user subsystem as well. We can keep track of credentials, not just access credentials, A very powerful overall tool. There's also the ability to schedule tasks. So here are a set of schedule-able projects and scheduled tasks within the system. We can schedule, or actually execute, and look at the state of jobs and, of course, we can look at a dashboard which gives us an overview of the current system and sort of what's going in within the environment.

Now the next step - start automating something with all these great tools that you have. And the best way to do that is to pick a task and try to figure out what module might be available to help automate that task. Now in the Ansible documentation page, docs.ansible.com, there's a list of modules and an index of all of the different modules for different technologies, you know, network modules for dealing with all the different network types of devices that are available. The ones that I actually find interesting are the files modules because this is sort of manipulating and modifying files.

I actually find it a little easier to just go to Google and say Google, Ansible and then the topic that you're trying to do like modifying a file or setting up a clustering system or what have you, and you'll almost always find the very first link will point you right back to the Ansible docs site and the module that supports that particular function so it's incredibly powerful from that perspective. And a great way to continue your understanding of how to consume and use Ansible for automating your environments.