Ansible @ an efficient configuration management tool-ansible configure management-translation (9)

If you do not have written authorization, do not reprint it.

Chapter 4 Use of ansible in large projects

New features in 1.3There are two features in Ansible 1.3 that were alluded to previously in the chapter.The first feature is the metadata roles. They allow you to specify that your roledepends on other roles. For example, if the application that you are deploying needsto send mail, your role could depend on a Postfix role. This would mean thatbefore the application is set up and installed, Postfix will be installed and set up.The meta/main.yml file would look similar to the following code:---allow_duplicates: nodependencies:- apacheThe allow_duplicates line is set to no , which is the default. If you set this to no ,Ansible will not run a role the second time, if it is included twice with the samearguments. If you set it to yes , it will repeat the role even if it has run before. You canleave it off instead of setting it to no .Dependencies are specified in the same format as roles. This means, you can passvariables here; either static values or variables that are passed to the current role.The second feature included with Ansible 1.3 is variable default values. If you placea main.yml file in the defaults directory for the role, these variables will be read intothe role; however they can be overridden by variables in the vars/main.yml file, orthe variables that are passed to the role when it is included. This allows you to makepassing variables to the role optional. These files look exactly like other variablefiles. For example, if you used a variable named port in your role, and you wantedto default it to port 80 , your defaults/main.yml file would look similar to thefollowing code:---port: 80

New features in version 1.3

The first feature is the metadata role, which allows us to specify a role to depend on another role. For example, if the application you are deploying needs to use the sendmail service, your role may have to be Postfix. You need to install and configure Postfix before deploying the application. The following code is used:

---
Allow_duplicates: No
Dependencies:
-Apache

The default value of allow_duplicates is "no". If it is set to "no", it means that it will not run more than once in the role. If it is "yes", it will run again after it has run once, if you do not set this keyword, the default value is no.

The same is true for specifying dependencies in a role. You can pass variables, static values, and dynamic values to the current role.

The second feature is that variables can have default values. if the yml file is placed under the defult directory, the variables will be passed to the role, but they will be/vars/main. yml file overwrites and can be passed to roles that contain them, which means you can pass optional variables to the role. These files are similar to other variable files. For example, if you use a role that contains the port variable and you want its default value to be 80, then your/defaults/main. the yml file should be like the following code:

---
Port: 80

Speeding things upAs you add more and more machines and services to your Ansible configuration,you will find things getting slower and slower. Fortunately, there are several tricksyou can use to make Ansible work on a bigger scale.TagsAnsible tags are features that allow you to select which parts of a playbook you needto run, and which should be skipped. While Ansible modules are idempotent andwill automatically skip if there are no changes, this often requires a connection to theremote hosts. The yum module is often quite slow in determining if a module is thelatest, as it will need to refresh all the repositories.If you know you don't need certain actions to be run, you can select only runmodules that have been tagged with a particular tag. This doesn't even try to run themodule, it simply skips over it. This will save time on almost all the modules even ifthere is nothing to be done.Let's say you have a machine which has a large number of shell accounts, but alsoseveral services set up to run on it. Now, imagine that a single user's SSH key hasbeen compromised and needs to be removed immediately. Instead of running theentire playbook, or rewriting the playbooks to only include the steps necessary toremove that key, you could simply run the existing playbooks with the SSH keystag, and it would only run the steps necessary to copy out the new keys, instantlyskipping anything else.This is particularly useful if you have a playbook with playbook includes in it thatcovers your whole infrastructure. With this setup, you can quickly deploy securitypatches, change passwords, and revoke keys across your entire infrastructure asquickly as possible.Tagging tasks is really easy; simply add a key named tag , and set its value to a list ofthe tags you want to give it. The following code shows us how to do this:

Acceleration for paly

When your ansible configurations contain more and more machines and services, you will find that the running speed is getting slower and slower. Fortunately, there are several tips to improve our performance.

Tags

The tags tag allows you to choose which parts of the playbook to run and which parts to skip. While ansible modules are idempotent and will automatically skip if there are no changes, this often requires a connection to the remote hosts. if the yum module creates a lastest, it usually runs slowly because it needs to refresh the repositories of all databases.

If you can determine that the operations are not necessary, you can mark the modules you want to run. Unmarked items are skipped, which saves a lot of time.

Suppose you have a machine with many shell users and many services. If one user has a weak SSH key, it needs to be removed immediately. Compared to running the entire play, or writing a new playbook, it is more efficient to mark the existing playbook with tags for the corresponding SSH key operations, in this way, you only need to perform the necessary steps to copy the new key and skip other steps. It is useful when your script contains facilities of all machines, allowing you to quickly deploy security updates, change passwords, and revoke keys for all devices.

It is very easy to use tags. You only need to Add Tag keywords and set the expected values. The following is the sample code:

This play defines the tags patch, deploy, and config. You can customize the tag options you want to execute. You only need to provide the tag parameters.
If you are not running in the command line, all operations are performed by default. For example, if you want to run the tag deploy, enter the following command in the command line:

$ Ansible-playbook webservers. yml -- tags deploy

In addition to discrete tasks, the role can also use tags. In the command line, ansible can select the marked role to run the task. The operation method is similar to that of the task. The Code is as follows:

---
-Hosts: website1
Roles:
-Common
-{Role: Apache, tags: ["patch"]}
-{Role: website2, tags: ["deploy", "patch"]}

The common role does not have any tag. When other tags are applied, the common role will not run. If the path tag is applied, the Apache and website2 roles will be executed, and the common role will not; if deploy is marked, only the website2 role will be executed.

In this way, when deploying or patching, we can use tags to select our role, which can greatly shorten the running time of play.

Ansible's pull modeAnsible includes a pull mode which can drastically improve the scalability of yourplaybooks. So far we have only covered using Ansible to configure another machineover SSH. This is a contrast to Ansible's pull mode, which runs on the host that youwish to configure. Since ansible-pull runs on the machine that it is configuring,it doesn't need to make connections to other machines and runs much faster. In thismode, you provide your configuration in a git repository which Ansible downloadsand uses to configure your machine.You should use Ansible's pull mode in the following situations:? Your node might not be available when configuring them, such as membersof auto-scaling server farms? You have a large amount of machines to configure and even with largevalues of forks , it would take a long time to configure them all? You want machines to update their configuration automatically when therepository changes? You want to run Ansible on a machine that may not have network access yet,such as in a kick start post installHowever, pull mode does have the following disadvantages that make it unsuitablefor certain circumstances:? To connect to other machines and gather variables, or copy a file you need tohave credentials on the managed nodes? You need to co-ordinate the running of the playbook across a server farm; forexample, if you could only take three servers offline at a time? The servers are behind strict firewalls that don't allow incoming SSHconnections from the nodes you use to configure them for Ansible

Ansible's Pull Mode

Ansible has a pull (push is the opposite of it) that can greatly improve the scalability of your playbooks. So far, we have used ansible to configure another machine through SSH. This is just the opposite of the PULL mode. The PULL mode runs on the configured machine and is fast. In this mode, you need to provide a git file for ansible to download and configure your machine.

You can use the PULL mode in the following scenarios:

• Your node is not available when you configure it, such as the auto-scaling Service pool.
• You have a large number of machines that need to be configured. It takes a lot of time to use very high threads.
• You need to run anisble on a machine without a network connection, for example, install

The following scenarios are not suitable for the PULL mode:

• You need to connect to other machines to collect variables, or the creden are required to copy files on the Control Host.
• Your playbook must span all devices. For example, you can only have three servers offline at the same time.
• The network where the ansible machine you configured is located cannot penetrate the SSH protocol.

Pull mode doesn't require anything special in your playbooks, but it does requiresome setup on the nodes you want configured. In some circumstances, you could dothis using Ansible's normal push mode. Here is a small play to setup play mode on amachine:

Pull Mode does not require any special settings in playbooks, but it requires some settings on the machine you configured. Sometimes, you can use the normal push mode. Below is a small play used to set the play mode on the machine:

In this example, we performed the following steps:? First, we( )installed and set up EPEL. This is a repository with extra softwarefor CentOS. Ansible is available in the EPEL repository.? Next, we installed Ansible, making sure to enable the EPEL repository.? Then, we created a directory for Ansible's pull mode to put the playbooks in.Keeping these files around means you don't need to download the whole gitrepository the whole time; only updates are required.? Finally, we set up a cron job that will try to run the ansible-pull modeconfig every five minutes.

In this example, the steps are as follows:

1. Set rpel, which is the software database of the centos operating system.
2. Confirm that epel database is enabled and ansible is installed
3. Create a directory for ansible to store playbooks. Saving these files allows you to update the GIT database only as needed, instead of downloading all the databases each time.
4. Finally, we added a new cron task to run the ansible-pull mode, which runs every 5 minutes.
   

The preceding code downloads the repository off an internal HTTPSgit server. If you want to download the repository instead of SSH, youwill need to add a step to install SSH keys, or generate keys and copythem to the git machine.

Note: The above code downloads the database from an internal HTTPS git server. If you want to use SSH, You need to configure and install SSH, generate the key, and copy it to the GIT machine.

SummaryIn this chapter, we have covered the techniques required when moving from asimple setup to a larger deployment. We discussed how to separate your playbookinto multiple parts using includes. We then looked at how we can package up relatedincludes and automatically include them all at once using roles. Finally we discussedpull mode, which allows you to automate the deployment of playbooks on theremote node itself.In the next chapter, we will cover writing your own modules. We start this bybuilding a simple module using bash scripting. We then look at how Ansiblesearches for modules, and how to make it find your own custom ones. Then, we takea look at how you can use Python to write more advanced modules using featuresthat Ansible provides. Finally, we will write a script that configures Ansible to pullits inventory from an external source.

Summary of this Chapter

In this chapter, we learned how to configure a simple deployment task to a complex deployment task. This section describes how to use inclusion to separate playbooks and how to use roles to automatically implement inclusion. Finally, we introduce anisble's pull mode, which allows remote managed hosts to run playbooks themselves.

The next chapter describes how to create a custom module. We will first introduce how to create simple modules in bash, how to introduce how ansible searches for modules, and how to customize its own modules. Next, we will introduce how to use python to compile advanced modules using the features provided by anisble. Finally, we will write a script to configure ansible to reference its own inventory from external data sources.