How to make your IT infrastructure boring
Michael DeHaan is the person who created Ansible. Many things that system administrators, release- and DevOps-engineers do on a regular basis are, to put it mildly, uninteresting. DeHaan wants these people to free their time for more interesting things (at work or outside the office door), and wrote a product code that frees administrator time.
More time, less adrenaline during business hours, fewer scripts and fewer errors.
By the way, you can finish reading on this paragraph, instead of connecting to livestream on June ? here is here .
Gerrit , and apply the changes only after they are approved by responsible comrades.
Alternate updates and load balancing systems
Ansible works very independently with load balancing systems when performing incremental updates. So you can just write in the Playbook script, in any loop for a group of hosts, something like "do this action on the X system on behalf of host Y", and Ansible will take care of the rest.
Ansible works well with load balancers of all kinds and knows how to set the temporary disable flag of the host to deactivate the availability monitoring for the upgrade period. A simple scheme "turn off monitoring - remove from the pool - update the required level of software - return to the pool - enable monitoring" - easily implements a sequential update with zero downtime and without false alarms. And all this in a fully automated mode, without operator involvement.
Integrated intermediate testing
Tower can work with various inventory files (Inventory), which makes it easy to test scenarios of the sequential update in the staging environment before running them on "combat" servers. To do this, it's enough to simulate the production environment in the test environment, run Ansible with the -i option and specify which inventory file should be used when executing the script - for the test environment or for the production environment. The script itself does not need to be modified.
Deployment based on the version control system
Some people like to pack packages together with OS packages (RPM, debs, etc.), but often, especially for web applications, such packaging is not needed. Therefore, Ansible includes several modules for deploying applications directly from version control systems. In the Playbook scenario, you can register a reconciliation with the code repository by the specified tag or version number, after which Ansible will check that this condition is met on all target servers and activate subsequent actions only if the version needs replacing, thus eliminating unnecessary service restarts.
Integration with monitoring tools
As a full-fledged orchestration system, Ansible supports integration with APM application performance management systems at the monitoring level. For example, during the deployment or integration testing phase, you must install or update the APM software agent with the application. In Ansible there is a special role for this, and after installing and activating the agent, Ansible can configure it on the APM monitoring stack (if it is not already configured) so that application management specialists can immediately check that the new version is installed and works without problems .
If something went wrong after the application was updated in the production environment, the monitoring tools can call Ansible to roll back to the previous version. Of course, only if such a rollback is allowed.
Notification of events
In the CI /CD paradigm, everyone wants to receive notifications of events as quickly as possible. Ansible offers both built-in features, including an email module, and integration with external notification tools, like messengers, social networks or event logging systems.
Deployment using the resource status model
One of the key features of Ansible, which makes it a very useful tool for deploying applications, is the regular use in the software update process of the resource status model that has gained popularity in managing system configurations. Unlike traditional open source management tools, Ansible does not need to be retrofitted with any additional software or special scripts to organize the delivery of applications.
In Ansible, you can very accurately register and monitor the order of events at different levels of the architecture, which allows you to delegate actions to other systems, as well as combine resource model directives (like "package X must be in Y state") and traditional script commands (like "run script .sh ") within the same process.
Ansible also allows you to easily run commands to test various conditions and make decisions based on the results of their execution. Integrating system configuration processes and deploying applications within a single tool chain is much more efficient than a schema with several specialized tools, and, in addition, increases the consistency of OS policies and applications.
Testing during the deployment of
The more opportunities, the higher the responsibility. The automation of continuous delivery processes dramatically increases the risk of deploying a failed configuration on all nodes of the system. To reduce risks, Ansible proposes to insert test scripts in the script, which will interrupt the next update, if something goes wrong. To test various conditions, including the status of the services, you can deploy arbitrary tests using the Command or Script modules, and even create such tests as separate Ansible modules.
The Fail module can interrupt execution of the script on the host at any time, which allows you to catch failures at an early stage of the sequential update. For example, due to the difference between the intermediate environment and the production one, a configuration error occurs in the latter, which disables the "combat" servers. In this case, in the Playbooks scenario, you can register an emergency exit at the first stage of the next update. And if you have 100 servers, and the window size of the incremental update is 1? then such an emergency stop will give time to calmly figure it all out, fix the script and continue the update.
In the event of a failure, Ansible does not continue to work, leaving the system in a semi-tuned state, and generates an error to get the operator's attention and tell him which hosts the update cycle went through with errors, and how many changes were made on each platform. In Ansible, there is a simulation run mode, when the system generates a report about what changes would have been made when the script was executed without its real execution.
There are environments where configurations are changed only when there is no way to do it. Any changes in such environments are preliminarily analyzed. Here systems of continuous delivery "with reservations" are used.
In Ansible, there is a simulation run mode (activated with the "--check" flag), when the system generates an account of what changes would have been made during the execution of the script. Real execution of the script does not happen, the simulation run does not allow to catch errors, but it helps to better understand and analyze the details and results of the proposed changes.
On the other hand, even with the continuous deployment of new assemblies, Ansible allows you to run compliance checks much more often to catch the moment when things in the production environment change as a result of human intervention and must be corrected by running the corresponding Ansible script, for example, to change software version, correct the resolution, etc.
Deployment on autopilot
If you live in a world of dolorit is more likely that the CI /CD is carried out exclusively by operators (both manually and with partial automation) and require, as in the dance, the coordinated actions of all the participants in the process. Ansible, along with its unique architecture and the absence of software agents on target hosts (which increases security and eliminates the need to manage the management system itself), can easily describe and automate complex deployment processes, that is, Ansible implements full autopilot mode here.
Examples of Ansible automation scenarios can be found at GitHub , and now we will give a baseline and an example of how to write a Playbook script that can be performed in Ansible or Ansible Tower. Together with the list of modules and other documents it will help you learn how to create your own Playbooks scripts.
What is a Playbook?
A Playbook script is essentially a set of instructions that is sent to one remote host or group of hosts. It's like a guide to assembling furniture from IKEA: follow the instructions exactly and get exactly what you saw in the store. This is how scenarios work.
We will create a Playbook that will install the web server on the RHEL /CentOS 7 host and create an index.html file on it based on the template specified in the script. The example script shown here is fully operational and ready to use. Below we will look at an example of a Playbook script and show you how to use modules.
The author is the one who creates instructions that will be executed by modules (often together with additional values: arguments, locations, etc.). Modules are executed on the target host in the order that they follow in the Playbook script (including include and other additional files included in it). The host state changes (or does not change) depending on the results of the module execution, which are displayed as an Ansible and Tower output.
Running the Playbookscript.
To begin with, you need to understand a few things about running Playbook scripts. Playbook is a kind of system of conditional signs, informing the module about the need to perform a task. To successfully launch Playbook it is important to understand the following:
1. Target system
Since the Playbook scripts give instructions to the modules and provide interaction with them, Ansible believes that you understand what you are trying to do and just automate it. That's why we say that Playbooks are like instructions or instructions: you tell automated elements how you want to configure a task. But at the same time you need to understand very well how the target host running the Playbook script works.
If you need to run a web server in some part of the Playbook, you need to understand how to do this to know which service module to use, and start the Web server by name. If Playbook installs a software package, you need to know how it is done on the target host. You also need to understand, at least at a basic level, the essence of the tasks performed. Do you need additional host configuration for the software you want to install? Are there branchings depending on the conditions and values of the arguments? If some variables are transferred in the process, you must understand exactly what and why.
Example of a Playbook script
The following example of a Playbook script will help you understand what you just read. The target host is the RHEL /CentOS 7 server, to which our script installs the NGINX web server, and then creates an index.html file in the default webroot directory. After the installation is completed and the index is created, the web server is started.
* Note: to run this example of a Playbook script in Ansible Tower, you must first configure inventory and accounts.
Playbooks start with three YAML dashes (---), followed by:
Name : just the name of the script to keep the readability of the Playbook.
Hosts : the list of target hosts on which Ansible should work.
Become : here we have written the true statement to make sure that nginx is installed without problems (this field is required not always).
2 - name: Install nginx
3 hosts: host.name.ip
4 become: true
With the indentation that the three previous lines, the directive is. tasks :, after which, with additional indentation (according to the rules of nesting YAML), tasks (plays) are listed. In this example, we have two tasks, and both use the Yum module. The first task adds an epel-release repository so that you can install nginx. After the epel appears in the system, the second task installs the nginx package.
Directive state : means that Ansible must check the state of the target host before performing any further actions. In our example, if the repository or nginx on the host already exists, Ansible understands that it is not necessary to perform these two tasks, and proceeds to the following.
2 - name: Add epel-release repo
4 name: epel-release
5 state: present
7 - name: Install nginx
9 name: nginx
10 state: present
The download page, which is used in nginx by default, is great to check that nginx is installed correctly, but you will most likely want to do this with your start-up html file. In this example, for simplicity, the index file template is in the same directory where Playbook is launched. Destination is simply the default path in nginix without any configured sites.
1 - name: Insert Index Page
3 src: index.html
4 dest: /usr/share/nginx/html/index.html
The last line in our Playbook only serves to verify that the nginx service was successfully started (or run it, if not).
1 - name: Start NGiNX
3 name: nginx
4 state: started
The entire Playbook script turned out about the same length as the introductory paragraph in this post:
2 - name: Install nginx
3 hosts: host.name.ip
4 become: true
7 - name: Add epel-release repo
9 name: epel-release
10 state: present
12 - name: Install nginx
14 name: nginx
15 state: present
17 - name: Insert Index Page
19 src: index.html
20 dest: /usr/share/nginx/html/index.html
22 - name: Start NGiNX
24 name: nginx
25 state: started
Playbook scripts are a simple and convenient way to do a lot of things with a small amount of code. In the example above, we used three modules - yum, template and service, to install the repository and software package on the server, create a file from the local template, and then run the newly installed service. In this case, our script Playbook came out a little longer than this sentence! And although we did it on the same host, it can just as well do it on dozens and hundreds of servers, it only requires making some minor changes to it. In addition, Tower allows you to put the Playbook script in the job template to run on a server group in the AWS cloud or in the corporate data center.
The architectural features of Ansible and the ability to integrate with CI-systems, like Jenkins, provide automation not only for configuration management processes, but also for a much wider range of IT tasks. That's why we affectionately call Ansible a complex orchestration system, and not just a tool for deploying software and managing configurations.
It may be interesting