Let's take quick a look at who wrote Ansible, and also what Ansible means.

Before we discuss how Ansible started, we should quickly discuss the origin of the name. The term Ansible was penned by science fiction novelist Ursula K. Le Guin; it was first used in her novel Rocannon's World, first published in 1966. In the context of the story, an Ansible is a fictional device that is able to send and receive messages faster than light.

The term has since been used by several other notable authors within the genre to describe communication devices that are capable of relaying messages over interstellar distances.

Ansible, the software, was originally developed by Michael DeHaan, who was also the author of Cobbler, which was developed while DeHaan was working for Red Hat.

DeHaan left Red Hat and worked for companies such as Puppet, which was a good fit since many users of Cobbler used it to hand off to a Puppet server to manage the servers once they had been provisioned.

A few years after leaving Puppet, DeHaan made the first public commit on the Ansible project; this was on February 23, 2012. The original README file gave quite a simple description that laid the foundation for what Ansible would eventually become:

Since that first commit, and at the time of writing, there have been over 35,000 commits by 3,000 contributors over 38 branches and 195 releases.

In 2013, the project had grown and Ansible, Inc., was founded to offer commercial support to Ansible users who had relied on the project to manage both their instructors and servers, be they physical, virtual, or hosted on public clouds.

Out of the formation of Ansible, Inc., which received $6 million in series A funding, came the commercial Ansible Tower, which acted as a web-based frontend where end users can consume role-based access to Ansible services.

Then, in October 2015, Red Hat announced that they were to acquire Ansible for $150 million. In the announcement, Joe Fitzgerald, who was Vice President, Management, Red Hat at the time of the acquisition, was quoted as saying:

During the course of this book, you will find that the statement in the original README file and Red Hat's statement at the time of acquiring Ansible both still ring true.

Before we look at rolling our sleeves up and installing Ansible, which we will be doing in the next chapter, we should look at some of the core concepts surrounding it.

If you look at the design principles in the first commit compared to the current version, you will notice that while there have been some additions and tweaks, the core principles remain pretty much intact:

• Agentless: Everything should be managed by the SSH daemon, the WinRM protocol in the case of Windows machines, or API calls—there should be no reliance on either custom agents or additional ports that need to be opened or interacted with on the target host
• Minimal: You should be able to manage new remote machines without having to install any new software as each Linux host will typically have at least SSH and Python installed as part of a minimal installation
• Descriptive: You should be able to describe your infrastructure, stack, or task in a language that is readable by both machines and humans
• Simple: The setup processes and learning curve should be simple and feel intuitive
• Easy to use: It should be the easiest IT automation system to use, ever

A few of these principles make Ansible quite different to other tools. Let's take a look at the most basic difference between Ansible and other tools, such as Puppet and Chef.

When I first started using Ansible, I had already implemented Puppet to help manage the stacks on the machines that I was managing. As the configuration became more and more complex, the Puppet code became extremely complicated. This is when I started looking at alternatives, and ones that fixed some of the issues I was facing.

Puppet uses a custom declarative language to describe the configuration. Puppet then packages this configuration as a manifest that the agent running on each server then applies.

The use of declarative language means that Puppet, Chef, and other configuration tools such as CFEngine all operate using the principle of eventual consistency, meaning that eventually, after a few runs of the agent, your desired configuration would be in place.

Ansible, on the other hand, is an imperative language meaning that, rather than just defining the end state of your desired outcome and letting the tool decide how it should get there, you also define the order in which tasks are executed in order to reach the state you have defined.

The example I tend to use is as follows. We have a configuration where the following states need to be applied to a server:

1. Create a group called Team
2. Create a user Alice and add her to the group Team
3. Create a user Bob and add him to the group Team
4. Give the user Alice escalated privileges

This may seem simple; however, when you execute these tasks using a declarative language, you may, for example, find that the following happens:

• Run 1: The tasks are executed in the following order: 2, 1, 3, and 4. This means that on the first run, as the group called Team does not exist, adding the user Alice fails, which means that Alice is never given escalated privileges. However, the group Team is added and the user called Bob is added.
• Run 2: Again, the tasks are executed in the following order: 2, 1, 3, and 4. Because the group Team was created during run 1, the user Alice is now created and she is also given escalated privileges. As the group Team and user Bob already exist, they are left as is.
• Run 3: The tasks are executed in the same order as runs 1 and 2; however, as the desired configuration had been reached, no changes were made.

Each subsequent run would continue until there was either a change to the configuration or on the host itself, for example, if Bob had really annoyed Alice and she used her escalated privileges to remove the user Bob from the host. When the agent next runs, Bob will be recreated as that is still our desired configuration, no matter what access Alice thinks Bob should have.

If we were to run the same tasks using an imperative language, then the following should happen:

• Run 1: The tasks are executed in the order we defined them, meaning that the group is created, then the two users, and finally the escalated privileges of Alice are applied
• Run 2: Again, the tasks are executed in the order and checks are made to ensure that our desired configuration is in place

As you can see, both ways get to our final configuration and they also enforce our desired state. With the tools that use declarative language, it is possible to declare dependencies, meaning that we can simply engineer out the issue we came across when running the tasks.

However, this example only has four steps; what happens when you have a few hundred steps that are launching servers in public cloud platforms and then installing software that needs several prerequisites?

This is the position I found myself in before I started to use Ansible. Puppet was great at enforcing my desired end configuration; however, when it came to getting there, I found myself having to worry about building a lot of logic into my manifests to arrive at my desired state.

What was also annoying is that each successful run would take about 40 minutes to complete. But as I was having dependency issues, I had to start from scratch with each failure and change to ensure that I was actually fixing the problem and not because things were starting to become consistent—not what you want when you are on a deadline.

Another key difference between Ansible and the other tools that it is commonly compared to is that the majority of these tools have their origins as systems that are designed to deploy and police a configuration state.

They typically require an agent to be installed on each host, that agent discovers some information about the host it is installed on, and then calls back to a central server basically saying Hi, I am server XYZ, could I please have my configuration? The server then decides what the configuration for the server looks like and sends it across to the agent, which then applies it. Typically, this exchange takes place every 15 to 30 minutes—this is great if you need to enforce a configuration on a server.

However, the way that Ansible has been designed to run allows it to act as an orchestration tool; for example, you can run it to launch a server in your VMware environment, and once the server has been launched, it can then connect to your newly launched machine and install a LAMP stack. Then, it never has to connect to that host again, meaning that all we are left with is the server, the LAMP stack, and nothing else, other than maybe a few comments in files to say that Ansible added some lines of configuration—but that should be the only sign that Ansible was used to configure the host.

Before we finish this chapter and move on to installing Ansible, let's quickly discuss infrastructure as code, first of all by looking at some actual code. The following bash script installs several RPMs using the yum package manager:

#!/bin/sh
LIST_OF_APPS="dstat lsof mailx rsync tree vim-enhanced git whois iptables-services"
yum install -y $LIST_OF_APPS

The following is a Puppet class that does the same task as the previous bash script:

class common::apps {
  package{
    [
      'dstat',
      'lsof',
      'mailx',
      'rsync',
      'tree',
      'vim-enhanced',
      'git',
      'whois',
      'iptables-services',
    ]:
    ensure => installed,
  }
}

Next up, we have the same task using SaltStack:

common.packages:
  pkg.installed:
    - pkgs:
      - dstat
      - lsof
      - mailx
      - rsync
      - tree
      - vim-enhanced
      - git
      - whois
      - iptables-services

Finally, we have the same task again, this time using Ansible:

- name: install packages we need
  yum:
    name: "{{ item }}"
    state: "latest"
  with_items:
    - dstat
    - lsof
    - mailx
    - rsync
    - tree
    - vim-enhanced
    - git
    - whois
    - iptables-services

Even without going into any detail, you should be able to get the general gist of what each of the three examples is doing. All three, while not strictly infrastructure, are valid examples of infrastructure as code.

This is where you manage the code that manages your infrastructure in exactly the same way as a developer would manage the source code for their application. You use source control, store it in a centrally available repository where you can collaborate with your peers, you branch and use pull requests to check in your changes, and, where possible, you write and execute unit tests to ensure that changes to your infrastructure are successful and error-free before deploying to production. This should be as automated as possible. Any manual intervention in the tasks mentioned should be seen as potentially a point of failure and you should work to automate the task.

This approach to infrastructure management has a few advantages, one being that you, as system administrators, are using the same processes and tooling as your developer colleagues, meaning that any procedures that apply to them also apply to you. This makes for a more consistent working experience, as well as exposing you to tools that you may not have been exposed to or used before.

Secondly, and more importantly, it allows you to share your work. Before this approach, this type of work seemed to others a dark art performed only by system administrators. Doing this work in the open allows you to have your peers review and comment on your configuration, as well as being able to do the same yourself to theirs. Also, you can share your work so that others can incorporate elements into their own projects.

Before we finish this chapter, I would like to just finish up my own personal journey. As mentioned elsewhere in the chapter, I moved from my collection of scripts and runbooks to Puppet, which was great until my requirements moved away from managing just server configuration and maintaining the state of the servers I was managing.

I needed to start to manage infrastructure in public clouds. This requirement quickly started to frustrate me when using Puppet. At the time, Puppet's coverage of the APIs I need to use for my infrastructure was lacking. I am assured it is a lot better now, but also I found myself having to build too much logic into my manifests with regard to the order in which each task was executed.

It is around this time, which was December 2014, that I decided to look at Ansible. I know this because I wrote a blog post entitled First Steps With Ansible, and since then, I don't think I have looked back. I have since introduced several of my work colleagues and customers to Ansible, as well as writing previous books for Packt.

In this chapter, we have taken a look at my own personal history with both Ansible and some of the other tools that Ansible is compared to, and we have discussed the differences between these tools and also where Ansible originated.

In the next chapter, we are going to look at installing Ansible and running our first playbooks against a local virtual machine.

In this chapter, we mentioned Puppet and SaltStack:

• Puppet is a configuration management tool that runs a server/agent configuration. It comes in two flavors—the open source version and an enterprise version that is supported by Puppet, the company. It is a declarative system and is closely tied to Ruby. For more information on Puppet, see https://puppet.com/.
• SaltStack is another configuration management tool. It is extremely scalable and, while it shares a design approach with Ansible, it works in a similar way to Puppet in that it has a server/agent approach. You can find more information on SaltStack at https://saltstack.com/.
• I also mentioned my blog, which you can find at https://media-glass.es/.