Search icon CANCEL
Subscription
0
Cart icon
Your Cart (0 item)
Close icon
You have no products in your basket yet
Arrow left icon
Explore Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Free Learning
Arrow right icon
Arrow up icon
GO TO TOP
Mastering Ansible

You're reading from   Mastering Ansible Effectively automate configuration management and deployment challenges with Ansible 2.7

Arrow left icon
Product type Paperback
Published in Mar 2019
Publisher Packt
ISBN-13 9781789951547
Length 412 pages
Edition 3rd 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 (17) Chapters Close

Preface 1. Section 1: Ansible Overview and Fundamentals FREE CHAPTER
2. The System Architecture and Design of Ansible 3. Protecting Your Secrets with Ansible 4. Ansible and Windows - Not Just for Linux 5. Infrastructure Management for Enterprises with AWX 6. Section 2: Writing and Troubleshooting Ansible Playbooks
7. Unlocking the Power of Jinja2 Templates 8. Controlling Task Conditions 9. Composing Reusable Ansible Content with Roles 10. Troubleshooting Ansible 11. Extending Ansible 12. Section 3: Orchestration with Ansible
13. Minimizing Downtime with Rolling Deployments 14. Infrastructure Provisioning 15. Network Automation 16. 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 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...

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 $19.99/month. Cancel anytime
Banner background image