Book Image

Ansible for Real-Life Automation

By : Gineesh Madapparambath
Book Image

Ansible for Real-Life Automation

By: Gineesh Madapparambath

Overview of this book

Get ready to leverage the power of Ansible’s wide applicability to automate and manage IT infrastructure with Ansible for Real-Life Automation. This book will guide you in setting up and managing the free and open source automation tool and remote-managed nodes in the production and dev/staging environments. Starting with its installation and deployment, you’ll learn automation using simple use cases in your workplace. You’ll go beyond just Linux machines to use Ansible to automate Microsoft Windows machines, network devices, and private and public cloud platforms such as VMWare, AWS, and GCP. As you progress through the chapters, you’ll integrate Ansible into your DevOps workflow and deal with application container management and container platforms such as Kubernetes. This Ansible book also contains a detailed introduction to Red Hat Ansible Automation Platform to help you get up to speed with Red Hat AAP and integration with CI/CD and ITSM. What’s more, you’ll implement efficient automation solutions while learning best practices and methods to secure sensitive data using Ansible Vault and alternatives to automate non-supported platforms and operations using raw commands, command modules, and REST API calls. By the end of this book, you’ll be proficient in identifying and developing real-life automation use cases using Ansible.
Table of Contents (22 chapters)
1
Part 1: Using Ansible as Your Automation Tool
6
Part 2: Finding Use Cases and Integrations
16
Part 3: Managing Your Automation Development Flow with Best Practices

Hello engineers!

The primary role of a systems engineer is building and managing IT infrastructure for hosting applications and their data. In the olden days, the number of applications used was a lot less, hence the infrastructure size. As the applications and components grew, the IT infrastructure also grew, and systems engineers and system administrators started experiencing resource conjunction. In other ways, systems engineers are spending more time on building, maintaining, and supporting the infrastructure rather than spending time on improving the infrastructure designs and optimizing them.

For the support team, 90% of the event tickets are simple fixes including disk space full, user account locked, volumes not mounted, and so on. But the support engineer still needs to manually log in to each and every server and fix the issues one by one.

The task can be fixing a low disk space issue on servers, installing some packages, patching OSs, creating virtual machines, or resetting a user password; engineers are doing the same job repeatedly for multiple systems, and this led to the invention of automated operations. Initially, the solution for automation was custom scripts developed and maintained by individual engineers, but it was never a real solution for the enterprises as there was no collaboration, maintenance, or accountability for such custom automation scripts. If the developer leaves the organization, the script will become an orphan and the next engineer will create their own custom scripts.

With the introduction of DevOps methodologies and practices, developers, systems engineers, operations teams, and other platform teams started working together, the boundaries between them became thinner, and a better accountable ecosystem evolved. Everyone started building and maintaining the applications and the underlying IT infrastructure, which, in turn, made the automation use case list bigger and more complex.