Mastering Ansible

Effectively automate configuration management and deployment challenges with Ansible 2.7, 3rd Edition

James Freeman, Jesse Keating

• Publisher: Packt Publishing
• Year: 2019
• eBook ISBN: 9781789959000
• Edition: 3
• Topic: Computer Science
• Subtopic: Programming in Python
• Index: Computer Science

Design, develop, and solve real-world automation and orchestration problems by unlocking the automation capabilities of Ansible.

Key Features

• Tackle complex automation challenges with the newly added features in Ansible 2.7

Book Description

Automation is essential for success in the modern world of DevOps. Ansible provides a simple, yet powerful, automation engine for tackling complex automation challenges.

This book will take you on a journey that will help you exploit the latest version's advanced features to help you increase efficiency and accomplish complex orchestrations. This book will help you understand how Ansible 2.7 works at a fundamental level and will also teach you to leverage its advanced capabilities. Throughout this book, you will learn how to encrypt Ansible content at rest and decrypt data at runtime. Next, this book will act as an ideal resource to help you master the advanced features and capabilities required to tackle complex automation challenges. Later, it will walk you through workflows, use cases, orchestrations, troubleshooting, and Ansible extensions. Lastly, you will examine and debug Ansible operations, helping you to understand and resolve issues.

By the end of the book, you will be able to unlock the true power of the Ansible automation engine and tackle complex, real- world actions with ease.

What you will learn

• Gain an in-depth understanding of how Ansible works under the hood
• Fully automate Ansible playbook executions with encrypted data
• Access and manipulate variable data within playbooks
• Use blocks to perform failure recovery or cleanup
• Explore the Playbook debugger and the Ansible Console
• Troubleshoot unexpected behavior effectively
• Work with cloud infrastructure providers and container systems
• Develop custom modules, plugins, and dynamic inventory sources

Who this book is for

This book is for Ansible developers and operators who have an understanding of its core elements and applications but are now looking to enhance their skills in applying automation using Ansible.

Section 1: Ansible Overview and Fundamentals

In this section, we will explore the fundamentals of how Ansible works and establish a sound basis on which to develop playbooks and workflows.

The following chapters are included in this section:

Chapter 1, The System Architecture and Design of Ansible

Chapter 2, Protecting Your Secrets with Ansible

Chapter 3, Ansible and Windows – Not Just for Linux

Chapter 4, Infrastructure Management for Enterprises with AWX

The System Architecture and Design of Ansible

This chapter provides a detailed exploration of the architecture and design of Ansible, and how it goes about performing tasks on your behalf. We will cover the basic concepts of inventory parsing and how data is discovered, and then proceed onto playbook parsing. We will take a walk through module preparation, transportation, and execution. Lastly, we will detail variable types and find out where the variables are located, their scope of use, and how precedence is determined when variables are defined in more than one location. All these things will be covered in order to lay the foundation for mastering Ansible!

In this chapter, we will cover the following topics:

• Ansible version and configuration
• Inventory parsing and data sources
• Playbook parsing
• Execution strategies
• Module transport and execution
• Variable types and locations
• Magic variables
• Variable precedence (and interchanging this with variable priority ordering)

Technical requirements

Check out the following video to see the Code in Action:

http://bit.ly/2ulbmEl

Ansible version and configuration

It is assumed that you have Ansible installed on your system. There are many documents out there that cover installing Ansible in a way that is appropriate to the operating system and version that you might be using. This book will assume use of Ansible version 2.7.x.x. To discover the version in use on a system where Ansible is already installed, make use of the version argument, that is, either ansible or ansible-playbook, as follows:

ansible-playbook --version

This command should give you an output that's similar to the following screenshot:

Note that ansible is the executable for doing ad hoc one-task executions, and ansible-playbook is the executable that will process playbooks for orchestrating many tasks.

The configuration for Ansible can exist in a few different locations, where the first file found will be used. The search involves the following:

• ANSIBLE_CFG: This environment variable is used, provided it is set
• ansible.cfg: This is located in the current directory
• ~/.ansible.cfg: This is located in the user's home directory
• /etc/ansible/ansible.cfg

Some installation methods may include placing a config file in one of these locations. Look around to check whether such a file exists and see what settings are in the file to get an idea of how Ansible operation may be affected. This book will assume that there are no settings in the ansible.cfg file that would affect the default operation of Ansible.

Inventory parsing and data sources

In Ansible, nothing happens without an inventory. Even ad hoc actions performed on the localhost require an inventory, though that inventory may just consist of the localhost. The inventory is the most basic building block of Ansible architecture. When executing ansible or ansible-playbook, an inventory must be referenced. Inventories are either files or directories that exist on the same system that runs ansible or ansible-playbook. The location of the inventory can be referenced at runtime with the --inventory-file (-i) argument, or by defining the path in an Ansible config file.

Inventories can be static or dynamic, or even a combination of both, and Ansible is not limited to a single inventory. The standard practice is to split inventories across logical boundaries, such as staging and production, allowing an engineer to run a set of plays against their staging environment for validation, and then follow with the same exact plays run against the production inventory set.

Variable data, such as specific details on how to connect to a particular host in your inventory, can be included, along with an inventory in a variety of ways, and we'll explore the options available to you.

Static inventory

The static inventory is the most basic of all the inventory options. Typically, a static inventory will consist of a single file in the ini format. Here is an example of a static inventory file describing a single host, mastery.example.name:

mastery.example.name 

That is all there is to it. Simply list the names of the systems in your inventory. Of course, this does not take full advantage of all that an inventory has to offer. If every name were listed like this, all plays would have to reference specific hostnames, or the special built-in all group (which, as it suggests, contains all hosts in the inventory). This can be quite tedious when developing a playbook that operates across different environments within your infrastructure. At the very least, hosts should be arranged into groups.

A design pattern that works well is to arrange your systems into groups based on expected functionality. At first, this may seem difficult if you have an environment where single systems can play many different roles, but that is perfectly fine. Systems in an inventory can exist in more than one group, and groups can even consist of other groups! Additionally, when listing groups and hosts, it's possible to list hosts without a group. These would have to be listed first before any other group is defined. Let's build on our previous example and expand our inventory with a few more hosts and groupings as follows:

[web] mastery.example.name [dns] backend.example.name [database] backend.example.name [frontend:children] web [backend:children] dns database 

What we have created here is a set of three groups with one system in each, and then two more groups, which logically group all three together. Yes, that's right; you can have groups of groups. The syntax used here is [groupname:children], which indicates to Ansible's inventory parser that this group, going by the name of groupname, is nothing more than a grouping of other groups.

The children, in this case, are the names of the other groups. This inventory now allows writing plays against specific hosts, low-level, role-specific groups, or high-level logical groupings, or any combination thereof.

By utilizing generic group names, such as dns and database, Ansible plays can reference these generic groups rather than the explicit hosts within. An engineer can create one inventory file that fills in these groups with hosts from a pre-production staging environment, and another inventory file with the production versions of these groupings. The playbook content does not need to change when executing on either a staging or production environment because it refers to the generic group names that exist in both inventories. Simply refer to the correct inventory to execute it in the desired environment.

Inventory ordering

A new play-level keyword, order, was added to Ansible in version 2.4. Prior to this, Ansible processed the hosts in the order specified in the inventory file, and continues to do so by default, even in newer versions. However, the following values can be set for the order keyword for a given play, resulting in the processing order of hosts described as follows:

• inventory: This is the default option, and simply means Ansible proceeds as it always has, processing the hosts in the order specified in the inventory file
• reverse_inventory: This results in the hosts being processed in the reverse of the order specified in the inventory
• sorted: The hosts are processed in alphabetically sorted order by name
• reverse_sorted: The hosts are processed in reverse alphabetically sorted order
• shuffle: The hosts are processed in a random order, with the order being randomized on each run

In Ansible, the alphabetical sorting used is otherwise known as lexicographical. In short this means that values are sorted as strings, with the strings being processed from left to right. Thus, say we have three hosts—mastery1, mastery11, and mastery2. In this list, mastery1 comes first as the character as position 8 is a 1. Then comes mastery11, as the character at position 8 is still a 1, but now there is an additional character at position 9. Finally comes mastery2, as character 8 is a 2 and 2 comes after 1. This is important as numerically we know that 11 is greater than 2, but in this list mastery11 comes before mastery2.

Inventory variable data

Inventories provide more than just system names and groupings. Data pertaining to the systems can be passed along as well. This data may include the following:

• Host-specific data to use in templates
• Group-specific data to use in task arguments or conditionals
• Behavioral parameters to tune how Ansible interacts with a system

Variables are a powerful construct within Ansible and can be used in a variety of ways, not just those described here. Nearly every single thing done in Ansible can include a variable reference. While Ansible can discover data about a system during the setup phase, not all data can be discovered. Defining data with the inventory e...

Table of contents

• Title Page
• Copyright and Credits
• About Packt
• Contributors
• Preface
• Section 1: Ansible Overview and Fundamentals
• The System Architecture and Design of Ansible
• Protecting Your Secrets with Ansible
• Ansible and Windows - Not Just for Linux
• Infrastructure Management for Enterprises with AWX
• Section 2: Writing and Troubleshooting Ansible Playbooks
• Unlocking the Power of Jinja2 Templates
• Controlling Task Conditions
• Composing Reusable Ansible Content with Roles
• Troubleshooting Ansible
• Extending Ansible
• Section 3: Orchestration with Ansible
• Minimizing Downtime with Rolling Deployments
• Infrastructure Provisioning
• Network Automation
• Other Books You May Enjoy