Search icon
Arrow left icon
All Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Newsletters
Free Learning
Arrow right icon
Mastering Ansible, 4th Edition - Fourth Edition

You're reading from  Mastering Ansible, 4th Edition - Fourth Edition

Product type Book
Published in Dec 2021
Publisher Packt
ISBN-13 9781801818780
Pages 540 pages
Edition 4th Edition
Languages
Authors (2):
James Freeman James Freeman
Profile icon James Freeman
Jesse Keating Jesse Keating
Profile icon Jesse Keating
View More author details

Table of Contents (18) Chapters

Preface 1. Section 1: Ansible Overview and Fundamentals
2. Chapter 1: The System Architecture and Design of Ansible 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 €14.99/month. Cancel anytime}