Search icon CANCEL
Arrow left icon
Explore Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Conferences
Free Learning
Arrow right icon
Arrow up icon
GO TO TOP
Mastering Ansible, 4th Edition

You're reading from   Mastering Ansible, 4th Edition Automate configuration management and overcome deployment challenges with Ansible

Arrow left icon
Product type Paperback
Published in Dec 2021
Publisher Packt
ISBN-13 9781801818780
Length 540 pages
Edition 4th Edition
Tools
Arrow right icon
Authors (2):
Arrow left icon
Jesse Keating Jesse Keating
Author Profile Icon Jesse Keating
Jesse Keating
James Freeman James Freeman
Author Profile Icon James Freeman
James Freeman
Arrow right icon
View More author details
Toc

Table of Contents (18) Chapters Close

Preface 1. Section 1: Ansible Overview and Fundamentals
2. Chapter 1: The System Architecture and Design of Ansible FREE CHAPTER 3. Chapter 2: Migrating from Earlier Ansible Versions 4. Chapter 3: Protecting Your Secrets with Ansible 5. Chapter 4: Ansible and Windows – Not Just for Linux 6. Chapter 5: Infrastructure Management for Enterprises with AWX 7. Section 2: Writing and Troubleshooting Ansible Playbooks
8. Chapter 6: Unlocking the Power of Jinja2 Templates 9. Chapter 7: Controlling Task Conditions 10. Chapter 8: Composing Reusable Ansible Content with Roles 11. Chapter 9: Troubleshooting Ansible 12. Chapter 10: Extending Ansible 13. Section 3: Orchestration with Ansible
14. Chapter 11: Minimizing Downtime with Rolling Deployments 15. Chapter 12: Infrastructure Provisioning 16. Chapter 13: Network Automation 17. Other Books You May Enjoy

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 ansible.builtin.command family of modules (commandshellraw, 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 failedchanged, or skipped. There is simply no way for these modules to assume a changed versus unchanged condition, as they cannot be expected to understand or interpret every possible shell command you might execute using them.

The changed_when condition allows a playbook author to instruct a module on how to interpret a change. Just like failed_whenchanged_when performs a test to generate a Boolean result. Frequently, the tasks used with changed_when are commands that will exit...

lock icon The rest of the chapter is locked
Register for a free Packt account to unlock a world of extra content!
A free Packt account unlocks extra newsletters, articles, discounted offers, and much more. Start advancing your knowledge today.
Unlock this book and the full library FREE for 7 days
Get unlimited access to 7000+ expert-authored eBooks and videos courses covering every tech area you can think of
Renews at £16.99/month. Cancel anytime