Keating Mastering Ansible

Master the ins and outs of advanced operations with Ansible
2. Auflage 2024
ISBN: 978-1-78712-677-0
Verlag: De Gruyter
Format: PDF
Kopierschutz: Adobe DRM (»Systemvoraussetzungen)

E-Book, Englisch, 310 Seiten

This book provides you with the knowledge you need to understand how Ansible 2.1 works at a fundamental level and leverage its advanced capabilities. You'll learn how to encrypt Ansible content at rest and decrypt data at runtime. You will master the advanced features and capabilities required to tackle the complex automation challenges of today and beyond.
You will gain detailed knowledge of Ansible workflows, explore use cases for advanced features, craft well thought out orchestrations, troubleshoot unexpected behaviour, and extend Ansible through customizations. Finally, you will discover the methods used to examine and debug Ansible operations, helping you to understand and resolve issues.

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

Autoren/Hrsg.

Keating, Jesse

Fachgebiete

• Mathematik | Informatik EDV | Informatik Technische Informatik Systemverwaltung & Management
• Mathematik | Informatik EDV | Informatik Computerkommunikation & -vernetzung

Inhaltsverzeichnis

Table of Contents - System Architecture and Design of Ansible
- Protecting Your Secrets with Ansible
- Unlocking the Power of Jinja2 Templates
- Controlling Task Conditions
- Composing Reusable Ansible Content with Roles
- Minimizing Downtime with Rolling Deployments
- Troubleshooting Ansible
- Extending Ansible

- Infrastructure Provisioning

Leseproben

Inventory parsing and data sources

In Ansible, nothing happens without an inventory. Even ad hoc actions performed on localhost require an inventory, even if that inventory consists just of the localhost. The inventory is the most basic building block of Ansible architecture. When executing or , an inventory must be referenced. Inventories are either files or directories that exist on the same system that runs or . The location of the inventory can be referenced at runtime with the () argument, or by defining the path in an Ansible 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 as well, 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 format. Here is an example of a static inventory file describing a single host, :

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 hostname, or the special group. This can be quite tedious when developing a playbook that operates across different sets of 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 some groupings:

[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 , which indicates to Ansible's inventory parser that this group by the name of 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.

By utilizing generic group names, such as and , 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 preproduction 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 staging or production environment because it refers to the generic group names that exist in both inventories. Simply refer to the right inventory to execute it in the desired environment.

Inventory variable data

Inventories provide more than just system names and groupings. Data about the systems can be passed along as well. This can include:

• 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 the ways 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 is how to expand the dataset. Note that variable data can come from many different sources, and one source may override another source. Variable precedence order is covered later in this chapter.

Let's improve upon our existing example inventory and add to it some variable data. We will add some host-specific data as well as group-specific data:

[web] mastery.example.name ansible_host=192.168.10.25 [dns] backend.example.name [database] backend.example.name [frontend:children] web [backend:children] dns database [web:vars] http_port=88 proxy_timeout=5 [backend:vars] ansible_port=314 [all:vars] ansible_ssh_user=otto

In this example, we defined for to be the IP address of . The variable is a behavioral inventory variable, which is intended to alter the way Ansible behaves when operating with this host. In this case, the variable instructs Ansible to connect to the system using the provided IP address rather than performing a DNS lookup on the name . There are a number of other behavioral inventory variables, which are listed at the end of this section along with their intended use.

Note

As of version 2.0, the longer form of some behavioral inventory parameters has been deprecated. The  part of , , and is no longer required. A future release may ignore the longer form of these variables.

Our new inventory data also provides group-level variables for the web and backend groups. The web group defines , which may be used in an nginx configuration file, and , which might be used to determine HAProxy behavior. The group makes use of another behavioral inventory parameter to instruct Ansible to connect to the hosts in this group using port for SSH, rather than the default of .

Finally, a construct is introduced that provides variable data across all the hosts in the inventory by utilizing a built-in group. Variables defined within this group will apply to every host in the inventory. In this particular example, we instruct Ansible to log in as the user when connecting to the systems. This is also a behavioral change, as the Ansible default behavior is to log in as a user with the same name as the user executing or on the control host.

Here is a table of behavior inventory variables and the behavior they intend to modify:

Inventory parameters

Behaviour

This is the DNS name or IP address used to connect to the host, if different from the inventory name, or the name of the Docker container to connect to.

This is the SSH port number, if not .

This is the default SSH username or user inside a Docker container to use.

This is the SSH password to use (this is insecure; we strongly recommend using or the SSH keys).

This is the private key file used by SSH. This is useful if you use multiple keys and you don't want to use SSH agent.

This defines SSH arguments to append to the default arguments for , , and .

This setting is always appended to the default command-line arguments.

This setting is always appended to the default command-line arguments.

This setting is always appended to the default command-line arguments.

This setting uses a Boolean to define whether or not SSH pipelining should be used for this...

Über Autor(innen)

Keating Jesse :

Jesse Keating is an accomplished Ansible user, contributor, and presenter. He has been an active member of the Linux and open source community for over 15 years. He has firsthand experience involving a variety of IT activities, software development, and large-scale system administration. He has presented at numerous conferences and meetups, and has written many articles on a variety of topics.