Ansible Quick Start Guide

Control and monitor infrastructures of any size, physical or virtual

Mohamed Alibi

• Publisher: Packt Publishing
• Year: 2018
• ISBN:
  9781789538731
• Edition: 1
• Topic: Computer Science
• Subtopic: System Administration
• Index: Computer Science

Configure Ansible and start coding YAML playbooks using the appropriate modules

Key Features

• Create and use Ansible Playbook to script and organise management tasks
• Benefit from the Ansible community roles and modules to resolve complex and niche tasks
• Write configuration management code to automate infrastructure

Book Description

Configuration Management (CM) tools help administrators reduce their workload. Ansible is one of the best Configuration Management tools, and can act as an orchestrator for managing other CMs. This book is the easiest way to learn how to use Ansible as an orchestrator and a Configuration Management tool. With this book, you will learn how to control and monitor computer and network infrastructures of any size, physical or virtual.

You will begin by learning about the Ansible client-server architecture. To get started, you will set up and configure an Ansible server. You will then go through the major features of Ansible: Playbook and Inventory. Then, we will look at Ansible systems and network modules.

You will then use Ansible to enable infrastructure automated configuration management, followed by best practices for using Ansible roles and community modules.

Finally, you will explore Ansible features such as Ansible Vault, Ansible Containers, and Ansible plugins.

What you will learn

• Implement Playbook YAML scripts and its capacities to simplify day-to-day tasks
• Setup Static and Dynamic Inventory
• Use Ansible predefined modules for Linux, Windows, networking, and virtualisation administration
• Organize and configure the host filesystem using storage and files modules
• Implement Ansible to enable infrastructure automated configuration management
• Simplify infrastructure administration
• Search and install new roles and enable them within Ansible
• Secure your data using Ansible Vault

Who this book is for

This book is targeted at System Administrators and Network Administrators who want to use Ansible to automate an infrastructure. No knowledge of Ansible is required.

Ansible Modules

In order to master Ansible playbooks, we need to learn about modules and how useful they can be. Ansible modules are essential components that define the actions performed by every playbook. Each module is set up to enable a task to be performed. They are designed to function smoothly with no overheads because all their dependencies and requirements are covered. Ansible modules enable the user to manage several operating systems, services, applications, databases, packages managers, virtualized infrastructure datastores, and cloud environments. In this chapter, we will cover the following:

• Overview of the use of Ansible modules
• Ansible Linux modules and their varieties
• Implementing Ansible Windows modules
• A common constructor: Ansible network modules
• The Ansible cloud modules of the big three cloud providers

Ansible modules overview

When installing Ansible, the user will also receive a very handy set of modules. This set is called a module library. It is a list of predefined functions and actions to be called when using Ansible, either via ad hoc commands or by running playbooks. An Ansible user is not limited to the predefined Ansible modules; they can easily write their own using Python and JSON scripting. The modules that come with the installation of Ansible might be referred to as task plugins or library plugins, but do not mistake these for the actual Ansible plugins, which are the scripts that allow Ansible to interact with other systems, a subject for another chapter.

The Ansible module library comes with its own machine library. Use the ansible-doc command followed by the name of the module to find out more about how it is used and what its output variables are:

ansible-doc apt

To list all the available modules, use the -l option:

ansible-doc -l

Using modules is very simple. You need to identify the name of the module, then input its arguments if required. Not all modules require argument input (the ping module, for example, doesn't require this) but most do. For other modules, inputting arguments is optional and might allow you to personalize the action, such as in the case of the Windows reboot module. As an example, let's look at executing modules in both ad hoc and playbook mode.

Ad hoc versus playbook: the ping module

As discussed previously, Ansible ad hoc can be used for a quick check, such as running a ping command to check if the hosts are up and running. The command should look as follows:

ansible servers -m ping

The output of the command will look similar to the following:

The ping module can also be used in the playbook as part of the bigger script, where the result of the ping can be piped to be the condition for another action. The playbook code is as follows:

---
- name: Ping module playbook usage
 hosts: servers
 gather_facts: false
 tasks:
 - name: ping the local servers
 ping:

The output of this code will look as follows:

Ad hoc versus playbook: the win_reboot module

The ad hoc command can be simply executed as shown in the following two examples:

ansible winservers -m win_reboot

ansible win servers -m win_reboot –args="msg='Reboot initiated by remote admin' pre_reboot_delay=5"

The resulting output of either command will look as follows:

This playbook file contains two ways of restarting hosts using the same module:

---
- name: Reboot Windows hosts
 hosts: winservers
 fast_gathering: false
 tasks:
 - name: restart Windows hosts with default settings
 win_reboot
 
 - name: restart Windows hosts with personalized 
 settings
 win_reboot:
 msg: "Reboot initiated by remote admin"
 pre_reboot_delay: 5

The resulting playbook output will look as follows:

ad-hoc versus playbook: the copy module

The Ansible copy module can be used in ad hoc mode to quickly run a copy job:

ansible servers -m copy --args="src=./file1.txt dest=~/file1.txt"

The output of this command should look as follows:

Alternatively, this can be used in a playbook with various options for a personalized result:

---
- name: copy a file to hosts
 hosts: servers
 become: true
 fast_gathering: false
 tasks:
 - name: copy a file to the home directory of a user
 copy:
 src: ./file1.txt
 dest: ~/file1.txt
 owner: setup
 mode: 0766

Ansible module return values

Return values are the key feature for monitoring and managing task execution. An administrator can determine the status of each action and run other tasks accordingly, either to fix, improve, or follow up on the bigger job. Ansible modules are fitted with a variety of return values. Each module will have the common values and some extra specific ones for the role performed by the module. These extra return values can be used for numerous functionalities. In Ansible, most return values are used as input for playbook conditions and loops. This scripting allows the pipelining of actions and tasks to achieve an automated configuration management. Ansible basically collects all the useful output data about the action performed by the module and arranges it into variables presented as return values.

There is no need to learn all the return values of these modules; you can easily get very good documentation about each module using the ansible-doc command. Alternatively, consult the official Ansible documentation using module index.

As for the most common return values, we can identify the following:

• stdout or stdout_lines: This is the variable that contains the standard output of commands executed using an execution module such as raw, command, shell, or win_shell. The stdout_lines have the same value and string as stdout but they have a more organized output—a human-readable text divided into lines.
• stderr or stderr_lines: This has the same output source as stdout, but this is the error message output. If the command executed returns an error message, it will be stored in this variable. The stderr_lines also have the same output string as stderr but are more organized into lines.
• changed: This is the return value that indicates the status of the task or action if the task has made a change to the target host. It will contain a Boolean value of True or False.
• failed: This is another status update return value that indicates whether the task or action has failed or not. It is also a Boolean v...