Learning Ansible 2.7

Automate your organization's infrastructure using Ansible 2.7, 3rd Edition

Fabio Alessandro Locati

• Publisher: Packt Publishing
• Year: 2019
• ISBN:
  9781789950007
• Edition: 3
• Topic: Computer Science
• Subtopic: Computer Science General
• Index: Computer Science

Use Ansible to configure your systems, deploy software, and orchestrate advanced IT tasks

Key Features

• Get familiar with the fundamentals of Ansible 2.7
• Understand how to use Ansible Tower to scale your IT automation
• Gain insights into how to develop and test Ansible playbooks

Book Description

Ansible is an open source automation platform that assists organizations with tasks such as application deployment, orchestration, and task automation. With the release of Ansible 2.7, even complex tasks can be handled much more easily than before.

Learning Ansible 2.7 will help you take your first steps toward understanding the fundamentals and practical aspects of Ansible by introducing you to topics such as playbooks, modules, and the installation of Linux, Berkeley Software Distribution (BSD), and Windows support. In addition to this, you will focus on various testing strategies, deployment, and orchestration to build on your knowledge. The book will then help you get accustomed to features including cleaner architecture, task blocks, and playbook parsing, which can help you to streamline automation processes. Next, you will learn how to integrate Ansible with cloud platforms such as Amazon Web Services (AWS) before gaining insights into the enterprise versions of Ansible, Ansible Tower and Ansible Galaxy. This will help you to use Ansible to interact with different operating systems and improve your working efficiency.

By the end of this book, you will be equipped with the Ansible skills you need to automate complex tasks for your organization.

What you will learn

• Create a web server using Ansible
• Write a custom module and test it
• Deploy playbooks in the production environment
• Troubleshoot networks using Ansible
• Use Ansible Galaxy and Ansible Tower during deployment
• Deploy an application with Ansible on AWS, Azure and DigitalOcean

Who this book is for

This beginner-level book is for system administrators who want to automate their organization's infrastructure using Ansible 2.7. No prior knowledge of Ansible is required

Section 1: Creating a Web Server Using Ansible

This section will help you create simple playbooks that will allow you to automate some simple tasks that you already perform on a daily basis.

This section contains the following chapters:

• Chapter 1, Getting Started with Ansible
• Chapter 2, Automating Simple Tasks

Getting Started with Ansible

Information and communications technology (ICT) is often described as a fast-growing industry. I think that the best quality of the ICT industry is not related to its ability to grow at a super-high speed, but is related to its ability to revolutionize itself, and the rest of the world, at an astonishing pace.

Every 10 to 15 years there are major shifts in how this industry works, and every shift solves problems that were very hard to manage up to that point, creating new challenges. Also, at every major shift, many of the best practices of the previous iteration are classified as anti-patterns, and new best practices are created. Although it might appear that those changes are impossible to predict, this is not always true. Obviously, it is not possible to know exactly what changes will occur and when they will take place, but looking at companies with a large number of servers and many lines of code usually reveals what the next steps will be.

The current shift has already happened in big companies such as Amazon Web Services (AWS), Facebook, and Google. It is the implementation of IT automation systems to create and manage servers.

In this chapter we will cover the following topics:

• IT automation
• What is Ansible?
• The secure shell
• Installing Ansible
• Creating a test environment with Vagrant
• Version control systems
• Using Ansible with Git

Technical requirements

To support the learning of Ansible, I suggest having a machine where you can install Vagrant. Using Vagrant will allow you to try many operations, even destructive ones, without fear.

Additionally, AWS and Azure accounts are suggested, since some examples will be on those platforms.

All examples in this book are available in the GitHub repository at https://github.com/PacktPublishing/-Learning-Ansible-2.X-Third-Edition/.

IT automation

IT automation is – in its broader sense – the processes and software that help with the management of the IT infrastructure (servers, networking, and storage). In the current shift, we are supporting for a huge implementation of such processes and software.

At the beginning of IT history, there were very few servers, and a lot of people were needed to make them work properly, usually more than one person for each machine. Over the years, servers became more reliable and easier to manage, so it was possible to have multiple servers managed by a single system administrator. In that period, the administrators manually installed the software, upgraded the software manually, and changed the configuration files manually. This was obviously a very labor-intensive and error-prone process, so many administrators started to implement scripts and other means to make their lives easier. Those scripts were (usually) pretty complex, and they did not scale very well.

In the early years of this century, data centers started to grow a lot due to companies' needs. Virtualization helped in keeping prices low, and the fact that many of these services were web services meant that many servers were very similar to each other. At this point, new tools were needed to substitute the scripts that were used before: the configuration management tools.

CFEngine was one of the first tools to demonstrate configuration management capabilities way back in the 1990s; more recently, there has been Puppet, Chef, and Salt, besides Ansible.

Advantages of IT automation

People often wonder if IT automation really brings enough advantages, considering that implementing it has some direct and indirect costs. The main benefits of IT automation are the following:

• The ability to provision machines quickly
• The ability to recreate a machine from scratch in minutes
• The ability to track any change performed on the infrastructure

For these reasons, it's possible to reduce the cost of managing the IT infrastructure by reducing the repetitive operations often performed by system administrators.

Disadvantages of IT automation

As with any other technology, IT automation does come with some disadvantages. From my point of view, these are the biggest disadvantages:

• Automating all of the small tasks that were once used to train new system administrators.
• If an error is performed, it will be propagated everywhere.

The consequence of the first is that new ways to train junior system administrators will need to be implemented.

The second one is trickier. There are a lot of ways to limit this kind of damage, but none of those will prevent it completely. The following mitigation options are available:

• Always have backups: Backups will not prevent you from nuking your machine – they will only make the restore process possible.
• Always test your infrastructure code (playbooks/roles) in a non-production environment: Companies have developed different pipelines to deploy code, and those usually include environments such as dev, test, staging, and production. Use the same pipeline to test your infrastructure code. If a buggy application reaches the production environment it could be a problem. If a buggy playbook reaches the production environment, it can be catastrophic.
• Always peer-review your infrastructure code: Some companies have already introduced peer-reviews for the application code, but very few have introduced it for the infrastructure code. As I was saying in the previous point, I think that infrastructure code is way more critical than application code, so you should always peer-review your infrastructure code, whether you do it for your application code or not.
• Enable SELinux: SELinux is a security kernel module that is available on all Linux distributions (it is installed by default on Fedora, Red Hat Enterprise Linux, CentOS, Scientific Linux, and Unbreakable Linux). It allows you to limit users and process powers in a very granular way. I suggest using SELinux instead of other similar modules (such as AppArmor) because it is able to handle more situations and permissions. SELinux will prevent a huge amount of damage because, if correctly configured, it will prevent many dangerous commands from being executed.
• Run the playbooks from a limited account: Even though user and privilege escalation schemes have been in Unix code for more than 40 years, it seems as if not many companies use them. Using a limited user for all your playbooks, and escalating privileges only for commands that need higher privileges, will help prevent you from nuking a machine while trying to clean an application temporary folder.
• Use horizontal privilege escalation: The sudo command is a well known, but is often used in its more dangerous form. The sudo command supports the -u parameter that will allow you to specify a user that you want to impersonate. If you have to change a file that is owned by another user, please do not escalate to root to do so, just escalate to that user. In Ansible, you can use the become_user parameter to achieve this.
• When possible, don't run a playbook on all your machines at the same time: Staged deployments can help you detect a problem before it's too late. There are many problems that are not detectable in dev, test, staging, and QA environments. The majority of them are related to a load that is hard to emulate properly in those non-production environments. A new configuration you have just added to your Apache HTTPd or MySQL servers could be perfectly OK from a syntax point of view, but disastrous for your specific application under your production load. A staged deployment will allow you to test your new configuration on your actual load without risking downtime in case something was wrong.
• Avoid guessing commands and modifiers: A lot of system administrators will try to remember the right parameter, and try to guess if they don't remember it exactly. I've done it too, a lot of times, but this is very risky. Checking the man page or the online documentation will usually take you less than two minutes, and often, by reading the manual, you'll find interesting notes you did not know. Guessing modifiers is dangerous because you could be fooled by a non-standard modifier (that is, -v is not a verbose mode for grep, and -h is not a help command for the MySQL CLI).
• Avoid error-prone commands: Not all commands have been created equally. Some commands are (way) more dangerous than others. If you can assume a cat-based command safe, you have to assume that a dd-based command is dangerous, since it performs copies and conversion of files and volumes. I've seen people using dd in scripts to transform DOS files to Unix (instead of dos2unix) and many other, very dangerous, examples. Please, avoid such commands, because they could result in a huge disaster if something goes wrong.
• Avoid unnecessary modifiers: If you need to delete a simple file, use rm ${file}, not rm -rf ${file}. The latter is often performed by users that have learned to be sure, always use rm -rf, because at some time in their past, they have had to delete a folder. This will prevent you from deleting an entire folder if the ${file} variable is set wrongly.
• Always check what could happen if a variable is not set: If you want to delete the contents of a folder and you use the rm -rf ${folder}/* command, you are looking for trouble. In case the ${folder} variable is not set for some reason, the shell will read a rm -rf /* command, which is deadly (considering the fact that the rm -rf / command will not work on the majority of current OSes because it requires a --no-preserve-root option, while the rm -rf /* will work as expected). I'm using this specific command as an example because I have seen such situations: ...

Table of contents

• Title Page
• Copyright and Credits
• About Packt
• Contributors
• Preface
• Section 1: Creating a Web Server Using Ansible
• Getting Started with Ansible
• Automating Simple Tasks
• Section 2: Deploying Playbooks in a Production Environment
• Scaling to Multiple Hosts
• Handling Complex Deployment
• Going Cloud
• Getting Notification from Ansible
• Section 3: Deploying an Application with Ansible
• Creating a Custom Module
• Debugging and Error Handling
• Complex Environments
• Section 4: Deploying an Application with Ansible
• Introducing Ansible for Enterprises
• Getting Started with AWX
• Working with AWX Users, Permissions, and Organizations
• Other Books You May Enjoy