Sign In Start Free Trial
Account

Add to playlist

Create a Playlist

Modal Close icon
You need to login to use this feature.
  • Mastering Ansible, 4th Edition
  • Toc
  • feedback
Mastering Ansible, 4th Edition

Mastering Ansible, 4th Edition

By : James Freeman, Keating
3.5 (8)
close
Mastering Ansible, 4th Edition

Mastering Ansible, 4th Edition

3.5 (8)
By: James Freeman, Keating

Overview of this book

Ansible is a modern, YAML-based automation tool (built on top of Python, one of the world’s most popular programming languages) with a massive and ever-growing user base. Its popularity and Python underpinnings make it essential learning for all in the DevOps space. This fourth edition of Mastering Ansible provides complete coverage of Ansible automation, from the design and architecture of the tool and basic automation with playbooks to writing and debugging your own Python-based extensions. You'll learn how to build automation workflows with Ansible’s extensive built-in library of collections, modules, and plugins. You'll then look at extending the modules and plugins with Python-based code and even build your own collections — ultimately learning how to give back to the Ansible community. By the end of this Ansible book, you'll be confident in all aspects of Ansible automation, from the fundamentals of playbook design to getting under the hood and extending and adapting Ansible to solve new automation challenges.
Table of Contents (18 chapters)
close
1
Section 1: Ansible Overview and Fundamentals
7
Section 2: Writing and Troubleshooting Ansible Playbooks
13
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 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...

bookmark search playlist download font-size

Change the font size

margin-width

Change margin width

day-mode

Change background colour

Close icon Search
Country selected

Close icon Your notes and bookmarks

Delete Bookmark

Modal Close icon
Are you sure you want to delete it?
Cancel
Yes, Delete