Later in this chapter, we will install Ansible, so you will need a machine capable of running it. I will go into more detail about these requirements in the second half of the chapter. We will also use Multipass to launch a virtual machine locally. A section walks through installing Multipass and downloading an Ubuntu image to use the virtual machine’s base, which is a download of a few hundred MBs. You can find all of the code used in this chapter at https://github.com/PacktPublishing/Learn-Ansible-Second-Edition/tree/main/Chapter01.

I have been working with servers, primarily ones that serve web pages, since the late 90s, and the landscape is unrecognizable. Here is a quick overview of my first few years running servers to give you an idea of how I used to operate my early 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 website I was running outgrew shared hosting due to the forum, which made up part of the site’s popularity. I moved to a dedicated server, where I thought I could flex my future system administrator muscles, but I was wrong.

The server I got was a Cobalt RaQ 3; this was a 1U server appliance that was ahead of its time. However, I did not have root-level access to the machine, and I had to use the web-based control panel for everything I needed to do. Eventually, I got a level of access where I could access the server using Telnet; I now know this isn’t...

Let’s take a quick look at who developed Ansible and what it actually is.

What is Ansible?

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, which was first published in 1966. In the story’s context, an Ansible is a fictional device that sends and receives messages faster than light.

Note

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, which, as you will discover...

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 using the WinRM protocol in the case of Windows machines or API calls—there should be no reliance on custom agents or additional ports that need to be opened or interacted with on the target host. The machine running Ansible should need line of sight of the target resource network-wise.
• Minimal: You should be able to manage new remote machines without installing any new software on the target host; each Linux target host will typically have at least SSH and Python installed as part of a minimal installation, which is all needed to run Ansible.
• Descriptive: You should be able to describe your infrastructure, stack, or task in a language readable by machines and humans.
...

Before we finish this part of the chapter, I would like to finish the story of my journey. As mentioned earlier 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 servers’ state.

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

It was around this time, which was December 2014, that I decided to look at Ansible. I know the date because I wrote a blog post entitled First Steps With Ansible; I don’t think I have looked back since. I have since introduced several of my work...

Let’s dive straight in and install Ansible. Throughout this book, I will assume you are running a macOS host machine or a Linux machine with an Ubuntu LTS release. While we will cover running Ansible on Windows 11 using the Linux subsystem for Windows, this book will not support using Windows as a host machine.

Installing on macOS

You can install Ansible on your macOS host machine in a few different ways. I will cover both here. As we are discussing two different ways of installing Ansible, I recommend reading through this section and the Pros and cons subsection before choosing which installation method to use on your local machine.

Installing with Homebrew

The first installation method is to use a package manager called Homebrew.

Note

Homebrew is a package manager of macOS. It can be used to install command-line tools and desktop packages. It describes itself as “The missing package manager for macOS”, and it usually...

To launch a virtual machine to run our first set of Ansible commands against, we will use a tool called Multipass. This tool allows you to run Ubuntu virtual machines on your local host. It works with macOS, Linux, and Windows.

To install Multipass on macOS, we can use Homebrew and run the following command:

$ brew install multipass

To install on Ubuntu, you can run the following command:

$ snap install multipass

Finally, for Windows 11 users, you will have to first download and install the VirtualBox Windows executable from https://www.virtualbox.org/wiki/Downloads and then download and install Multipass from https://multipass.run/install. I recommend reading through the installation notes for Windows, which can be found at the following URL https://multipass.run/docs/installing-on-windows before installing.

Note

While you can run the same commands in Ubuntu running under Windows Subsystem for Linux, you will need to replace all references...

Typically, in IT, a playbook is a set of instructions run by someone when something happens; a little vague, I know, but stay with me. These range from building and configuring new server instances to deploying code updates and dealing with problems when they occur.

In the traditional sense, a playbook is typically a collection of scripts or instructions for a user to follow, and while they are meant to introduce consistency and conformity across systems, even with the best intentions, this is seldom the case.

This is where Ansible comes in. Using an Ansible playbook, you are telling it to apply these changes and commands against these sets of hosts rather than having to log in and start working your way through the playbook manually.

Before we run a playbook, let’s discuss how we provide Ansible with a list of hosts to target. To do this, we will be using the ansible.builtin.setup module. This connects to a host and then fetches as much...

In this chapter, we have taken our first steps with Ansible by installing it locally and then, using Vagrant, launching a virtual machine to interact with. We learned about basic host inventory files and used the Ansible command to execute a single task against our virtual machine.

We then looked at playbooks, starting with a basic playbook that returned some information on our target before progressing to a playbook that updates all the installed operating system packages before installing and configuring the NTP service.

By the end of the chapter, we had launched a second virtual machine and quickly brought it up to the same configuration level as our first virtual machine.

In the next chapter, we will look at Ansible Galaxy and discuss how Ansible packages up and maintains its community modules.

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—an open source version and an enterprise version that Puppet, the company, supports. It is a declarative system and is closely tied to Ruby. For more information on Puppet, see https://www.puppet.com/.
• SaltStack is another configuration management tool. It is highly 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://www.vmware.com/support/acquisitions/saltstack.html.
• I also mentioned my personal blog, which you can find at https://www.russ.foo/.

We used the following Ansible modules, and you can find out more information on each module at the following links:

• ansible.builtin.setup: https://docs.ansible.com/ansible/latest/collections/ansible...