[{"id":"ch01lvl1sec01","contentType":"text","title":"An Introduction to Ansible","content":"

An Introduction to Ansible

In our first chapter, we are going to be looking at the technology world before tools such as Ansible came into existence in order to get an understanding of why Ansible was needed.

Before we start to talk about Ansible, let's quickly discuss the old world. I have been working with servers, mostly ones that serve web pages, since the late 90s, and the landscape is unrecognizable. To give you an idea of how I used to operate my early servers, here is a quick overview of my first few years running servers.

Like most people at the time, I started with a shared hosting account where I had very little control over anything on the server side when the site I was running at the time outgrew shared hosting. I moved to a dedicated server—this is where I thought I would be able to flex my future system administrator muscles, but I was wrong.

The server I got was a Cobalt RaQ 3, a 1U server appliance, which, in my opinion, was ahead of its time. However, I did not have root level access to the machine and for everything I needed to do, I had to use the web-based control panel. Eventually, I got a level of access where I could access the server using SSH or Telnet (I know, it was the early days), and I started to teach myself how to be a system administrator by making changes in the web control panel and looking at the changes to the configuration files on the server.

After a while, I changed servers and this time opted to forego any web-based control panel and just use what I had learned with the Cobalt RaQ to configure my first proper Linux, Apache, MySQL, PHP (LAMP) server by using the pages of notes I had made. I had created my own runbooks of one-liners to install and configure the software I needed, as well as numerous scribbles to help me look into problems and keep the lights on.

After I got my second server for another project, I realized that was probably a good time to type out my notes so that I could copy and paste them when I needed to deploy a server, which I am glad I did, as it was shortly after my first server failed—my host apologized and replaced it with a higher-specification but completely fresh machine with an updated operating system.

So I grabbed my Microsoft Word file containing the notes I made and proceeded to then copy and paste each instruction, making tweaks based on what I needed to install and also on the upgraded operating system. Several hours later, I had my server up and running and my data restored.

One of the important lessons I learned, other than that there is no such thing as too many backups, was to not use Microsoft Word to store these types of notes; the command doesn't care if your notes are all nicely formatted with headings and courier font for the bits you need to paste. What it does care about is using proper syntax, which Word had managed to autocorrect and format for print.

So, I made a copy of the history file on the server and transcribed my notes in plaintext. These notes provided the base for the next few years as I started to script parts of them, mostly the bits that didn't require any user input.

These scraps of commands, one-liners, and scripts were all adapted through Red Hat Linux 6—note the lack of the word Enterprise—all the way through to CentOS 3 and 4.

Things got complicated when I changed roles, stopped consuming services from web hosts, and started working for one. All of a sudden, I was building servers for customers who may have different requirements than my own projects—no one server was the same.

From here, I started working with Kickstart scripts, PXE boot servers, gold masters on imaging servers, virtual machines, and bash scripts that started prompting for information on the system that was being built. I had also moved from only needing to worry about maintaining my own servers to having to log in to hundreds of different physical and virtual servers, from ones that belonged to the company I was working for to customer machines.

Over the next few years, my single text file quickly morphed into a complex collection of notes, scripts, precompiled binaries, and spreadsheets of information that, if I am being honest, really only made sense to me.

While I had moved to automate quite a few parts of my day-to-day work using bash scripts and stringing commands together, I found that my days were still very much filled with running all of these tasks manually, as well as working a service desk dealing with customer-reported problems and queries.

My story is probably typical of many people, while the operating systems used will probably be considered quite ancient. Now, the entry point of using a GUI and moving to the command line, while also keeping a scratch pad of common commands, is quite a common one I have heard.

We will be covering the following topics:

Who is behind Ansible
The differences between Ansible and other tools
The problem Ansible solves

","url":"https://subscription.packtpub.com/book/cloud-and-networking/9781788998758/1","metaDescription":"","titleSlug":"an-introduction-to-ansible"},{"id":"ch01lvl1sec02","contentType":"text","title":"Ansible's story","content":"

Ansible's story

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

The term

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.

In 1974, Ursula K. Le Guin's novel The Dispossessed: An Ambiguous Utopia, was published; this book features the development of the Ansible technology by exploring the (fictional) details of the mathematical theory that would make such a device possible.

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.

The software

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.

Cobbler is a Linux installation server that allows you to quickly deploy servers within your network; it can help with DNS, DHCP, package updates and distribution, virtual machine deployment, power management of physical hosts, and also the handoff of a newly deployed server, be it physical or virtual, to a configuration management system.

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:

"Ansible is an extra-simple Python API for doing 'remote things' over SSH. As Func, which I co-wrote, aspired to avoid using SSH and have it's own daemon infrastructure, Ansible aspires to be quite different and more minimal, but still able to grow more modularly over time."

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:

"Ansible is a clear leader in IT automation and DevOps, and helps Red Hat take a significant step forward in our goal of creating frictionless IT."

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.

","url":"https://subscription.packtpub.com/book/cloud-and-networking/9781788998758/1/ch01lvl1sec02/ansible-s-story","metaDescription":"","titleSlug":"ansible-s-story"},{"id":"ch01lvl1sec03","contentType":"text","title":"Ansible versus other tools","content":"

Ansible versus other tools

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.

Declarative versus imperative

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:

Create a group called Team
Create a user Alice and add her to the group Team
Create a user Bob and add him to the group Team
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.

Configuration versus orchestration

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.

Infrastructure as code

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.

","url":"https://subscription.packtpub.com/book/cloud-and-networking/9781788998758/1/ch01lvl1sec03/ansible-versus-other-tools","metaDescription":"","titleSlug":"ansible-versus-other-tools"},{"id":"ch01lvl1sec04","contentType":"text","title":"Summary","content":"

Summary

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.

","url":"https://subscription.packtpub.com/book/cloud-and-networking/9781788998758/1/ch01lvl1sec04/summary","metaDescription":"","titleSlug":"summary"},{"id":"ch01lvl1sec05","contentType":"text","title":"Further reading","content":"

Learn Ansible

By : Russ McKendrick

Learn Ansible

By: Russ McKendrick

Overview of this book

Related Content you might be interested in

Current Title:

Learn Ansible

Ansible Quick Start Guide

Infrastructure as Code for Beginners

Practical Ansible 2