如无书面授权，请勿转载
Larger Projects Until now, we have been looking at single plays in one playbook file. This approach will work for simple infrastructures, or when using Ansible as a simple deployment mechanism. However, if you have a large and complicated infrastructure, then you will need to take actions to prevent things from going out of control. This chapter will include the following topics: • Separating your playbooks into different files, and including them from some other location • Using roles to include multiple files that perform a similar function • Methods for increasing the speed at which Ansible configures your machines
第四章 大型项目中Ansible的使用
至此，我们已经介绍了怎样用一个playbook文件执行一个plays。在小型架构或则使用Ansible做一个简单的部署机制时这已经非常实用了。可是，假设你有一个非常大非常复杂的系统架构，你可能须要一些额外的操作来保证事情不会超出我们的控制。本章包括下面主题：
- 将你的playbooks分离成多个文件，存储在不同的地方
- 使用角色包括多个文件来完毕相同的功能
- 加速使用Ansible配置机器的方法
Includes One of the first issues you will face with a complex infrastructure is that your playbooks will rapidly increase in size. Large playbooks can become difficult to read and maintain. Ansible allows you to combat this problem by the way of includes. Includes allow you to split your plays into multiple sections. You can then include each section from other plays. This allows you to have several different parts built for a different purpose, all included in a main play. There are four types of includes, namely variable includes, playbook includes, task includes, and handler includes. Including variables from an external vars_file files has been discussed already in Chapter 2, Simple Playbooks. The following is a summary of what each includes does: • Variable includes: They allow you to put your variables in external YAML files • Playbook includes: They are used to include plays from other files in a s ingle playLarger Projects • Task includes: They let you put common tasks in other files and include them wherever required • Handler includes: They let you put all your handlers in the one place
包括
在大型复杂架构中。你第一个要面对的问题就是不断增长的playbooks文件大小。一个非常大的playbooks非常难去理解和维护，解决的方法是使用包括includes。
将你的plays分解成多个不同的段，然后在其它的plays中包括他们。不同的段依据不同目的地分类，所有包括在主play中。
有四种类型的包括，各自是变量包括、playbook包括、任务包括、处理程序handler包括。
从外部变量文件包括变量。在第二章已经讨论过。以下是每一个包括类型的介绍：
- 变量包括：同意你将变量存在外部YAML文件
- playbook包括：一个大型项目中能够包括多个plays
- 任务包括：将任务放到普通文件里，当须要的时候包括他们
- 处理程序Handler包括：同意你将全部的handlers处理程序放到一个地方
Task includes
Task includes can be used when you have a lot of common tasks that will be
repeated. For example, you may have a set of tasks that removes a machine, from
monitoring, and a load balancer before you can configure it. You can put these tasks
in a separate YAML file, and then include them from your main task.
Task includes inherit the facts from the play they are included from. You can also
provide your own variables, which are passed into the task and available for use.
Finally, task includes can have conditionals applied to them. If you do this,
conditionals will separately be added to each included task. The tasks are all still
included. In most cases, this is not an important distinction, but in circumstances
where variables may change, it is.
The file to include as a task includes contains a list of tasks. If you assume the
existence of any variables and hosts or groups, then you should state them in
comments at the top. This makes reusing the file much easier.
So, if you wanted to create a bunch of users and set up their environment with their
public keys, you would split out the tasks that do a single user to one file. This file
would look similar to the following code:
---
# Requires a user variable to specify user to setup
- name: Create user account
#2
user: name={{ user }} state=present
#3
#1
- name: Make user SSH config dir
#4
file: path=/home/{{ user }}/.ssh owner={{ user }} group={{ user
}} mode=0600 state=directory
#5
- name: Copy in public key
#6
copy: src=keys/{{ user }}.pub dest=/home/{{ user
}}/.ssh/authorized_keys mode=0600 owner={{ user }} group={{ user
}}
#7
We expect that a variable named user will be passed to us, and that their public
key will be in the keys directory. The account is created, the ssh config directory
is made, and finally we can copy this in their public key. The easiest way to use this
config file would be to include it with the with_items keyword we learned about in
Chapter 3, Advanced Playbooks. This would look similar to the following code:
---
- hosts: ansibletest
user: root
tasks:
- include: usersetup.yml user={{ item }}
with_items:
- mal
- dan
- kate
任务包括
当你有非常多类似的任务须要反复运行的时候，你能够使用任务包括。比方。在你配置一台设备之前。须要从负载均衡或者监控系统中删除这台设备，你能够把这样的任务分别放进不同的YAML文件里，然后在你的主任务文件里包括他们。
被包括的任务facts会继承包括他的play的facts，你也能够自己提供变量，他们在play中都是可用的。
此外，任务包括能够是有条件的。假设你设定了条件，那么条件将会被加入到每个包括它的任务中，任务会一直被包括。多数情况下，这样没什么重要的差别，但假设存在变量的话。就不一样了。一个任务文件能够包括非常多任务，假设你要设定变量，最好在文件的顶部来凝视他们。这样能够使得它更加易于被理解和利用。
比方你要创建非常多用户，并用他们的公钥来环境变量设置。你能够先做好一个用户的的任务放到一个文件里，这个文件代码例如以下：
---
# Requires a user variable to specify user to setup
- name: Create user account
user: name={{ user }} state=present
- name: Make user SSH config dir
file: path=/home/{{ user }}/.ssh owner={{ user }} group={{ user
}} mode=0600 state=directory
- name: Copy in public key
copy: src=keys/{{ user }}.pub dest=/home/{{ user
}}/.ssh/author
我们估计变量名｛｛user｝｝会被传递给我们，他们的公钥在keys文件夹中。
用户建立之后。ssh config文件夹就被创建，然后我们复制公钥文件进去。包括这个任务最简单的办法就是使用第三章介绍的with_itemskeyword
代码例如以下：
---
- hosts: ansibletest
user: root
tasks:
- include: usersetup.yml user={{ item }}
with_items:
- mal
- dan
- kate
Handler includes When writing Ansible playbooks, you will constantly find yourself reusing the same handlers multiple times. For instance, a handler used to restart MySQL is going to look the same everywhere. To make this easier, Ansible allows you to include other files in the handlers section. Handler includes look the same as task includes. You should make sure to include a name on each of your handlers; otherwise you will not be able to refer to them easily in your tasks. A handler include file looks similar to the following code: --- - name: config sendmail command: make -C /etc/mail notify: reload sendmail - name: config aliases command: newaliases notify: reload sendmail - name: reload sendmail service: name=sendmail state=reloaded - name: restart sendmail service: name=sendmail state=restarted This file provides several common tasks that you would want to handle after configuring sendmail . By including the following handlers in their own files, you can easily reuse them whenever you need to change the sendmail configuration: • The first handler regenerates the sendmail database's config file and triggers a reload file of sendmail later • The second handler initializes the aliases database, and also schedules a reload file of sendmail The third handler reloads sendmail ; it may be triggered by the previous two jobs, or it may be triggered directly from a task • The fourth handler restarts sendmail when triggered; this is useful if you upgrade sendmail to a new version Handlers can trigger other handlers provided that they only trigger the ones specified later, instead of the triggered ones. This means, you can set up a series of cascading handlers that call each other. This saves you from having long lists of handlers in the notify section of tasks. Using the preceding handler file is easy now. We simply need to remember that if we change a sendmail configuration file, then we should trigger config sendmail , and if we change the aliases file, we should trigger config aliases . The following code shows us an example of this: --- hosts: mailers #1 tasks: #2 - name: update sendmail #3 yum: name=sendmail state=latest notify: restart sendmail #5 #4 - name: configure sendmail #6 template: src=templates/sendmail.mc.j2 dest=/etc/mail/sendmail.mc #7 notify: config sendmail #8 handlers: #9 - include: sendmailhandlers.yml #10 This playbook makes sure sendmail is installed. If it isn't installed or if it isn't running the latest version, then it installs it. After it is updated, it schedules a restart so that we can be confident that the latest version will be running once the playbook is done. In the next step, we replace the sendmail configuration file with our template. If the config file was changed by the template then the sendmail configuration files will be regenerated, and finally sendmail will be reloaded.
Handler 处理程序包括
当我们编写playbooks时。Handler也是常常被重用的。
比方。重新启动MYSQL的handler到处能够见。我们能够在Handler选项中包括他们。和任务包括一样。你要确定包括了每个你须要的Handler的名字，否则在引用的时候就不那么方便了。Handler包括的文件类似例如以下代码：
---
- name: config sendmail
command: make -C /etc/mail
notify: reload sendmail
- name: config aliases
command: newaliases
notify: reload sendmail
- name: reload sendmail
service: name=sendmail state=reloaded
- name: restart sendmail
service: name=sendmail state=restarted
这个文件包括了很多在配置完sendmail之后须要的做的handler操作。假设我们在任务文件本身包括他们，在你须要改变sendmail配置的时候将非常easy被重用。
- 第一个handler在又一次生成配置文件之后，又一次载入了配置文件
- 第二个handler在配置玩aliases之后，又一次载入了配置文件
- 第三个handler又一次载入配置文件，它能够是被前面2个任务触发，也能够在包括他的任务中直接调用他们
- 第四个handler重新启动了sendmail服务。假设你升级了sendmail版本号，你可能就要用到了
注意：Handlers 也能够被其它的Handlers触发，当中会有反复的Handlers，可是仅仅有最后一个被指定的Handlers会被运行。
这样在你的任务中的notify选项就不须要一串长长的Handlers列表了。
使用这个Handlers文件非常easy，我们仅仅要记住：假设我们改变了配置文件，我们就触发config sendmai。假设我们该了aliases，我们就触发config aliases。代码例如以下:
---
hosts: mailers
tasks：
- name: update sendmail
yum: name=sendmail state=latest
notify: restart sendmail
- name: configure sendmail
template: src=templates/sendmail.mc.j2
dest=/etc/mail/sendmail.mc
notify: config sendmail
handlers:
- include: sendmailhandlers.yml
假设sendmail没安装或者不是最新版本号。这个palybook会安装并更新它，之后须要重新启动；使用模板文件之后，还须要又一次生成sendmail配置文件。而这2个处理程序都被包括在sendmailhandlers.yml文件里。
Playbook includes Playbook includes should be used when you want to include a whole set of tasks designated for a set of machines. For example, you may have a play that gathers the host keys of several machines and builds a known_hosts file to copy to all the machines. While task includes allows you to include tasks, playbook includes allows you to include whole plays. This allows you to select the hosts you wish to run on, and provide handlers for notify events. Because you are including whole playbook files, you can also include multiple plays. Playbook includes allows you to embed fully self-contained files. It is for this reason that you should provide any variables that it requires. If they depend on any particular set of hosts or groups, this should be noted in a comment at the top of the file. This is handy when you wish to run multiple different actions at once. For example, let's say we have a playbook that switches to our DR site, named drfailover. yml , another named upgradeapp.yml that upgrades the app, another named drfailback.yml that fails back, and finally drupgrade.yml . All these playbooks might be valid to use separately, but when performing a site upgrade, you will probably want to perform them all at once. You can do this as shown in the following code: --- - include "drfailover.yml" - include "upgradeapp.yml" - include "drfailback.yml" #1 #2 #3 - name: Notify management #4 hosts: local #5 tasks: #6 - local_action: mail to="mgmt-team@example.com" msg='The application has been upgraded and is now live' #7 - include "drupgrade.yml" #8 As you can see, you can put full plays in the playbooks that you are including other playbooks into.
Playbook 包括
当你须要为一批机器设计一系列任务的时候，你能够使用playbooks包括。比方，你可能想要收集一批机器的host key合并到known_hosts中。然后分发给全部机器。
playbook包括同意你选择执行的主机、handler处理程序。
另外，除了包括一个playbook。你还能够包括多个playbook。
playbook包括同意您嵌入全然自包括的文件,因此你应该提供不论什么须要的变量。假设它依赖某些特殊的主机或组，那你应该在文件顶部中做好凝视。当你要一次性执行多个actions操作的时候，使用playbook包括很方便。
比方：我们有一个文件叫drfailover.yml用来切换我们的dr（dr是负载均衡配置的名词，一般有一主一备2个dr，这里不多做解释啦，同学们能够百度之）。一个叫upgradeapp.yml的文件用来更新应用程序，一个叫drfailback.yml的文件用来切换回原来的dr。另一个drupgrade.yml用来升级dr。
这些文件都是独立的，当我们想升级应用程序的时候，我们能够一次性使用它们。代码例如以下：
---
- include "drfailover.yml"
- include "upgradeapp.yml"
- include "drfailback.yml"
- name: Notify management
hosts: local
tasks:
- local_action: mail to="mgmt-team@example.com" msg='The
application has been upgraded and is now live'
- include "drupgrade.yml"
使用playbook之后，你能够把全部操作都放在一个playbook中了。