New features in 1.3 There 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 role depends on other roles. For example, if the application that you are deploying needs to send mail, your role could depend on a Postfix role. This would mean that before 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: no dependencies: - apache The 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 same arguments. If you set it to yes , it will repeat the role even if it has run before. You can leave it off instead of setting it to no . Dependencies are specified in the same format as roles. This means, you can pass variables 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 place a main.yml file in the defaults directory for the role, these variables will be read into the role; however they can be overridden by variables in the vars/main.yml file, or the variables that are passed to the role when it is included. This allows you to make passing variables to the role optional. These files look exactly like other variable files. For example, if you used a variable named port in your role, and you wanted to default it to port 80 , your defaults/main.yml file would look similar to the following code: --- port: 80
第一个特性是Metadata角色，它可以让我们指定一个角色依赖另外一个角色。比如，如果你现在部署的应用程序需要使用sendmail服务，那么你的角色可能要以来postfix角色。你需要在部署应用程序之前先安装和配置postfix。下面是代码:
---
allow_duplicates: no
dependencies:
- apache
allow_duplicates的默认值是no，如果设置成no，表示他不会在角色中运行的次数不会超过1次，如果是yes则会在运行过一次之后重复运行，你可以不设置这个关键字，那么它的默认值是no。
在角色中指定依赖关系也一样，你可以传递变量、静态值、动态的值给现在的角色。
第二个特性是变量可以有默认值，如果你把main.yml文件放到defult目录下面，那么变量会传递给角色，但是它们会被／vars/main.yml文件覆盖，还可以传递到包含他们的角色，这意味着你可以传递可选的变量到角色里面。这些文件和其他变量文件类似，比如你使用一个包含port变量的角色，你希望它的默认值是80，那么你的／defaults/main.yml文件应该像下面的代码这样：
---
port: 80
Speeding things up As you add more and more machines and services to your Ansible configuration, you will find things getting slower and slower. Fortunately, there are several tricks you can use to make Ansible work on a bigger scale. Tags Ansible tags are features that allow you to select which parts of a playbook you need to run, and which should be skipped. While Ansible modules are idempotent and will automatically skip if there are no changes, this often requires a connection to the remote hosts. The yum module is often quite slow in determining if a module is the latest, 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 run modules that have been tagged with a particular tag. This doesn't even try to run the module, it simply skips over it. This will save time on almost all the modules even if there is nothing to be done. Let's say you have a machine which has a large number of shell accounts, but also several services set up to run on it. Now, imagine that a single user's SSH key has been compromised and needs to be removed immediately. Instead of running the entire playbook, or rewriting the playbooks to only include the steps necessary to remove that key, you could simply run the existing playbooks with the SSH keys tag, and it would only run the steps necessary to copy out the new keys, instantly skipping anything else. This is particularly useful if you have a playbook with playbook includes in it that covers your whole infrastructure. With this setup, you can quickly deploy security patches, change passwords, and revoke keys across your entire infrastructure as quickly as possible. Tagging tasks is really easy; simply add a key named tag , and set its value to a list of the tags you want to give it. The following code shows us how to do this:
当你的Ansible配置中的机器和服务越来越多，你会发现运行速度会变得越来越慢。幸运的是，这有几个技巧可以让我们改善性能。
tags标记可以让你选择运行playbook中哪些部分，跳过哪些。While Ansible modules are idempotent and will automatically skip if there are no changes, this often requires a connection to the remote hosts.如果yum模块制定lastest的话通常运行很慢，因为他要刷新所有资料库repositories.
如果你可以确定那些操作不是必须的，你可以标记那些你希望运行的模块。没有被标记的会被跳过，而这可以节约大量时间。
假设你有一台机器上面有很多的shell用户，还运行了很多服务。如果有一个用户的 ssh key有点弱，需要马上被移除。比起运行整个play，或者重新写一个编写一个playbook，对现存的playbook对相应的ssh key的操作打个tags标记显然更加有效率，这样你只需要执行必要的步骤来复制新的密钥，跳过其他的步骤。当你的剧本包含所有机器的设施的时候很有用，让你可以快速对所有设备部署安全更新、更改密码、撤销密钥。
使用tag非常简单，只需要添加tag关键字，然后设定你希望的值，下面是示例代码：
这个play定义了patch , deploy , config这些标记，你自定义执行你希望的标记选项，只需要简单的提供标记参数就可以了。
如果你不在命令行里运行，默认是执行所有的操作。比如你想运行标记deploy，在命令行中输入以下命令：
$ ansible-playbook webservers.yml --tags deploy
除了离散的任务，角色也可以使用tags，在命令行中，Ansible可以选择打了标记的角色来运行，操作方式跟任务差不多，代码如下：
---
- hosts: website1
roles:
- common
- { role: apache, tags: ["patch"] }
- { role: website2, tags: ["deploy", "patch"] }
common角色中没有打任何标记，当其他标记被应用的时候common角色不会被运行；如果path标记被应用，那么apache和website2角色会被执行，common不会；如果deploy标记，则只有website2角色会被执行。
这样在部署或者打补丁的时候，通过使用标记来选择我们制定的角色，我们可以大大缩短play的运行时间。
Ansible's pull mode Ansible includes a pull mode which can drastically improve the scalability of your playbooks. So far we have only covered using Ansible to configure another machine over SSH. This is a contrast to Ansible's pull mode, which runs on the host that you wish 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 this mode, you provide your configuration in a git repository which Ansible downloads and 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 members of auto-scaling server farms ? You have a large amount of machines to configure and even with large values of forks , it would take a long time to configure them all ? You want machines to update their configuration automatically when the repository changes ? You want to run Ansible on a machine that may not have network access yet, such as in a kick start post install However, pull mode does have the following disadvantages that make it unsuitable for certain circumstances: ? To connect to other machines and gather variables, or copy a file you need to have credentials on the managed nodes ? You need to co-ordinate the running of the playbook across a server farm; for example, if you could only take three servers offline at a time ? The servers are behind strict firewalls that don't allow incoming SSH connections from the nodes you use to configure them for Ansible
Ansible有一个pull（push 推送是它的反义词）可以大大提高你playbooks的伸缩性。目前为止，我们都是使用Ansible通过ssh来配置另外一台机器，这跟pull模式刚好相反，pull模式在被配置的机器上运行，速度很快。在这种模式下，你需要提供一个git资料来供Ansible下载来配置你的机器。
在以下场景你可以使用pull模式：
以下的场景不适合pull模式
Pull mode doesn't require anything special in your playbooks, but it does require some setup on the nodes you want configured. In some circumstances, you could do this using Ansible's normal push mode. Here is a small play to setup play mode on a machine:
In this example, we performed the following steps: ? First, we( )installed and set up EPEL. This is a repository with extra software for 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 git repository the whole time; only updates are required. ? Finally, we set up a cron job that will try to run the ansible-pull mode config every five minutes.
The preceding code downloads the repository off an internal HTTPS git server. If you want to download the repository instead of SSH, you will need to add a step to install SSH keys, or generate keys and copy them to the git machine.
Summary In this chapter, we have covered the techniques required when moving from a simple setup to a larger deployment. We discussed how to separate your playbook into multiple parts using includes. We then looked at how we can package up related includes and automatically include them all at once using roles. Finally we discussed pull mode, which allows you to automate the deployment of playbooks on the remote node itself. In the next chapter, we will cover writing your own modules. We start this by building a simple module using bash scripting. We then look at how Ansible searches for modules, and how to make it find your own custom ones. Then, we take a look at how you can use Python to write more advanced modules using features that Ansible provides. Finally, we will write a script that configures Ansible to pull its inventory from an external source.
在本章中，我们学习了如何从一个简单的设置到一个复杂的部署任务。介绍了如何使用包含来分割playbook，如何使用角色来自动实现包含，最后我们介绍了Anisble的pull模式，它可以让远程受管主机自己运行playbook。
下一章，我们将介绍如何自己来创建自定义的模块。我们将先介绍在bash中建立简单模块，如何介绍Ansible如何搜寻模块，如何自定义自己的模块。然后我们将介绍如何使用python利用Anisble提供的特性来编写高级模块，最后，我们将写一个脚本来配置Ansible从外部的数据源来引用它自己的清单inventory。
Ansible@一个高效的配置管理工具--Ansible configure management--翻译（九）,布布扣,bubuko.com
Ansible@一个高效的配置管理工具--Ansible configure management--翻译（九）
原文：http://blog.csdn.net/smallfish1983/article/details/37813911
