Book Image

Ansible Playbook Essentials

By : Gourav Shah, GOURAV JAWAHAR SHAH
Book Image

Ansible Playbook Essentials

By: Gourav Shah, GOURAV JAWAHAR SHAH

Overview of this book

Ansible Playbook Essentials will show you how to write a blueprint of your infrastructure, encompassing multitier applications using Ansible's playbooks. Beginning with basic concepts such as plays, tasks, handlers, inventory, and YAML Ain't Markup Language (YAML) syntax that Ansible uses, you'll understand how to organize your code into a modular structure. Building on this, you will study techniques to create data-driven playbooks with variables, templates, logical constructs, and encrypted data, which will further strengthen your application skills in Ansible. Adding to this, the book will also take you through advanced clustering concepts, such as discovering topology information about other nodes in the cluster and managing multiple environments with isolated configurations. As you approach the concluding chapters, you can expect to learn about orchestrating infrastructure and deploying applications in a coordinated manner. By the end of this book, you will be able to design solutions to your automation and orchestration problems using playbooks quickly and efficiently.
Table of Contents (20 chapters)
Ansible Playbook Essentials
Credits
About the Author
Acknowledgments
About the Reviewers
www.PacktPub.com
Preface
Setting Up the Learning Environment
References
Index

Variable precedence


We specified variable defaults, used them in inventory files, and defined the same variable from different places (for example, defaults, vars, and inventory). Let's now analyze the output of the templates to understand what happened with all those variables.

The following is the figure showing the my.cnf file on Ubuntu:

The following is the analysis of the screenshot:

  • The file has a notice in the comments section. This can deter admins from making manual changes to the file.

  • Most of the variables come from the defaults in a role. This is because Debian is our default family of operating systems and we already have sane defaults set for it. Similarly, for other operating system platforms, we are setting variable defaults from the vars directory in a role.

  • Even though the bind_address parameter is specified in the defaults and group_vars, it takes a value from the playbook's role parameter, which has a higher precedence over the other two levels.

The following diagram explains...