Скачать или смотреть Handlers - Ansible Tutorial

Handlers is a free tutorial by Ugur Oktay from Ansible course
Link to this course(Special Discount):
https://www.udemy.com/course/ansible-...
This is the best Ansible Course
Course summary:
Configuration management with Ansible
Install and configure Ansible Automation Engine on a control node
Run ad-hoc automation tasks from the command line
Write Ansible playbooks to automate multiple system administration tasks on managed hosts
Work with Ansible in conjunction with Vagrant and Virtualbox in a DevOps environment
Parameterize Ansible playbooks using variables and facts
Ansible variable precedence system and overriding
Use Jinja2 templating to enable dynamic expressions and access to variables
Create Ansible playbooks/roles to deploy a 3-tier web application
Configure Ansible roles with tasks, handlers, files, templates, dependencies and variables
Be able to create Ansible playbooks/roles to deploy a 3-tier web application
English [Auto]
We've discussed item potency before. It's an essential concept for and civil as well as any other configuration management tools out there with some exceptions most of the time and Ansel provides item potent operations but item potency is not always something we can achieve by using item potent modules. This is simply not enough for having an item potent playbook and we'll see why in a second to be item potent an operation should check the state if nothing needs to be change then do nothing. This holds true both at the task and playbook levels. Now let me run our Apache playbook once again and we'll look at the results together in our Apache playbook. We are defining a state when we run it. We can achieve that state with our tasks in the playbook and also we see a change here. Something has changed. Let's run the playbook once again. Again we have a change here. We didn't introduce any changes in the playbook but it's reporting a change. Every time I run it something might be going wrong. Let's see what's going on here. As you see here the tasks that run yum copy line in file modules are all green meaning they are already at the desired state. Those tasks don't change anything because there is no need to. So those three tasks are fine. I can call the playbook as many times as I want and they will not make any change because we're already at the desired state. But the last task restarts the service. Every time I run the playbook and reports a change considering the fact that the rest of the playbook doesn't introduce any changes at all then it shouldn't restart the service. Right. There is no need to bounce a DPD demon and cause service downtime. But what else can we do. Or how can we fix it. Another alternative could be to set the state of that task as reloaded. If I do that it would be slightly better because instead of a restart which stops and restarts the service it will then only reload the configuration without bouncing the service. But again if the other tasks don't introduce any changes why should I reload the service. Or what happens when a change is introduced by some other task and a restart is required at the moments. The modules I'm using are item potent but the way I use them is breaking item potency and also at the same time introducing risks which may even cause downtime. The recommended way to handle such situations is by using handlers handlers are the tasks at the end of the play that are triggered by changes made on the managed notes. If a change has been made by a task animal tracks that and we have the chance to call a handler task that will only run. In that case we can define which tasks Change calls which specific handler task or tasks. Let's see an example and it will be clear this is a basic task copying a configuration file to a folder. If this operation means a change the notification at the end of the task will be triggered. So this is an example of restarting a service when the contents of a file change but only if the file changes. This is again the same task copying a configuration file to a folder. But this time if this operation means a change to notifications will be triggered. So a task can trigger more than one notification in case of a need. Handlers are placed at the end of the play. They can only be called by notify actions at the end of tasks. So if I add a notify action to a task and in case the task introduces any change the handler is called. If the task doesn't introduce any change handler will not be called which handler is called after which task is entirely up to us. We can even call multiple handlers from a single task like this example. So this is the method playbooks used to recognize and respond to changes introduced at the task level. If all the modules a playbook uses are item potent then the playbook i