Book Image

Mastering Ansible. - Third Edition

By : James Freeman, Jesse Keating
Book Image

Mastering Ansible. - Third Edition

By: James Freeman, Jesse Keating

Overview of this book

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.
Table of Contents (17 chapters)
Free Chapter
1
Section 1: Ansible Overview and Fundamentals
6
Section 2: Writing and Troubleshooting Ansible Playbooks
12
Section 3: Orchestration with Ansible

Defining a change

Similar to defining a task failure, it is also possible to define what constitutes a changed task result. This capability is particularly useful with the command family of modules (command, shell, raw, and script). Unlike most other modules, the modules of this family do not have an inherent idea of what a change may be. In fact, unless otherwise directed, these modules only result in failed, changed, or skipped. There is simply no way for these modules to assume a changed condition versus unchanged.

The changed_when condition allows a playbook author to instruct a module on how to interpret a change. Just like failed_when, changed_when performs a test to generate a Boolean result. Frequently, the tasks used with changed_when are commands that will exit nonzero to indicate that no work is needed to be done, so, often, authors will combine changed_when and failed_when...