本篇主要是根据官方翻译而来，从而使简单的翻译，并没有相关的实验步骤，以后文章会补充为实验步骤，此篇主要是相关理论的说明，可以称之为中文手册之一，具体内容如下：
Ansible playbooks最佳实践
本文档主要阐述如何来写最好的playbook，在如下网址中能找到相关的例子，如下：
在使用playbooks的最佳路径中，最好的方法是使用roles，这是最好的方法，在官方文档中，至少强调了三篇，从而在使用playbooks的时候，最好就是使用roles来进行组织playbook。
1、 目录结构
| production # 生产环境服务器的列表（inventory file） staging # 测试环境服务器列表（inventory file）
group_vars/ group1 # 对特定的组分配变量 group2 # "" host_vars/ hostname1 # 主机特定变量 hostname2 # ""
library/ # 客户端模块（可选） filter_plugins/ # 客户端过滤模块（可选）
site.yml # master playbook webservers.yml # webserver 的playbook dbservers.yml # dbserver 的playbook
roles/ common/ # 此层表示为一个 "role" tasks/ # main.yml # <-- 任务文件 handlers/ # main.yml # <-- handlers文件 templates/ # <-- 模板文件位置 ntp.conf.j2 # <------- 模板后缀符 .j2 files/ # bar.txt # <-- 拷贝文件资源 foo.sh # <-- script文件脚本资源 vars/ # main.yml # <-- 本role相关联的变量 defaults/ # main.yml # <-- 默认情况下优先级比较低的变量 meta/ # main.yml # <-- role的依赖
webtier/ # webtier的role，和comman的role结构相同 monitoring/ # "" fooapp/ # ""
|
2、 使用动态inventory
在使用云的时候，可以不使用静态的inventory文件，可以使用动态的inventory文件。
3、 如何区分测试环境和生产环境
在测试环境和生产环境的管理中，主要用不同的inventory文件来进行区分。
在进行使用playbook的时候，最好在测试环境中进行测试，然后再在生产环境中进行执行。
在管理静态的inventory文件的时候，如果来区分生产环境和测试环境，主要就是使用前缀名，如下所示
# file: production [atlanta-webservers] www-atl-1.example.com www-atl-2.example.com [boston-webservers] www-bos-1.example.com www-bos-2.example.com [atlanta-dbservers] db-atl-1.example.com db-atl-2.example.com [boston-dbservers] db-bos-1.example.com # webservers in all geos [webservers:children] atlanta-webservers boston-webservers # dbservers in all geos [dbservers:children] atlanta-dbservers boston-dbservers # everything in the atlanta geo [atlanta:children] atlanta-webservers atlanta-dbservers # everything in the boston geo [boston:children] boston-webservers boston-dbservers
|
在上图中，都使用相同的前缀名，从而来区分各个主机。
在进行管理不同环境的主机的时候，推荐的做法是使用不同的前缀名来进行区分主机环境，从而做到可读性比较强
4、 组和主机变量
组是比较容易管理的，但是并不是所有组都是这样的，同样可以对组的变量进行设置，在下面例子中，atlanta有其自己的变量，从而定义如下：
--- # file: group_vars/atlanta ntp: ntp-atlanta.example.com backup: backup-atlanta.example.com
|
--- # file: group_vars/all ntp: ntp-boston.example.com backup: backup-boston.example.com
|
--- # file: host_vars/db-bos-1.example.com foo_agent_port: 86 bar_agent_port: 99
|
5、 最高层的playbook划分为role
在site.yml中，可以使用include一个playbook来表述一个整体的结构，注意在整个里面是很简短的，如下所示，playbooks是包含一系列的playbook：
--- # file: site.yml - include: webservers.yml - include: dbservers.yml
|
在文件webserver.yml中，也就是配置这个组所对应的role，如下所示：
--- # file: webservers.yml - hosts: webservers roles: - common - webtier
|
在进行运行的时候，我们可以使用site.yml来进行或者使用单独的webserver.yml来运行，如下就是来进行明确运行哪个playbook：
ansible-playbook site.yml --limit webservers ansible-playbook webservers.yml
|
6、 在role中来组织task和handler
以下例子中演示如何使用一个role来进行工作，在这里可以做很多，如下所示：
--- # file: roles/common/tasks/main.yml - name: be sure ntp is installed yum: name=ntp state=installed tags: ntp - name: be sure ntp is configured template: src=ntp.conf.j2 dest=/etc/ntp.conf notify: - restart ntpd tags: ntp - name: be sure ntpd is running and enabled service: name=ntpd state=running enabled=yes tags: ntp |
下面的例子中，表示为一个handler，如下所示：
--- # file: roles/common/handlers/main.yml - name: restart ntpd service: name=ntpd state=restarted
|
7、 组织结构如何启用
在上面的roles组织中，如何开启这种布局结构
如果要重新配置组织架构，只要执行下面的命令即可：
ansible-playbook -i production site.yml
|
如果要重新配置NTP，执行下面命令即可：
ansible-playbook -i production site.yml --tags ntp
|
如果要重新配置webservers，如下：
ansible-playbook -i production webservers.yml
|
如果要重新配置boston的webservsers，如下：
ansible-playbook -i production webservers.yml --limit boston
|
如果要重新配置前十个和下十个，如下：
ansible-playbook -i production webservers.yml --limit boston[0-10] ansible-playbook -i production webservers.yml --limit boston[10-20]
|
如果要执行临时任务，如下：
ansible boston -i production -m ping ansible boston -i production -m command -a '/sbin/reboot'
|
比较有用的指令如下：
# confirm what task names would be run if I ran this command and said "just ntp tasks" ansible-playbook -i production webservers.yml --tags ntp --list-tasks # confirm what hostnames might be communicated with if I said "limit to boston" ansible-playbook -i production webservers.yml --limit boston --list-hosts |
8、 使用state
在有的模块中，state是有默认值得，但是在playbook中最好是明确的标示state的状态是present还是absent，并且在state还有其他值得时候，明确指定state的值有利于可读性。
9、 操作系统和发行版变量
如果是针对的是不同操作系统的变量，最好的方法是使用group_by模块。这样会对动态的主机进行确认，虽然不在inventory文件中，如下：
--- # talk to all hosts just so we can learn about them - hosts: all tasks: - group_by: key=os_{{ ansible_distribution }} # now just on the CentOS hosts... - hosts: os_CentOS gather_facts: False tasks: - # tasks that only happen on CentOS go here
|
这样会形成将所有的系统形成一个动态组，基于操作系统的名称。
如果需要特殊的设置组，那么如下所示：
--- # file: group_vars/all asdf: 10 --- # file: group_vars/os_CentOS asdf: 42
|
上例中，表示出了centos的机器获得的值为10，centos的机器获得值为42
也可以设置以下的变量：
- hosts: all tasks: - include_vars: "os_{{ansible_distribution}}.yml" - debug: var=asdf
|
此种变量是基于操作系统的名称
10、 其他
在使用的时候，注意用空格来进行分割不同的内容；
使用#来进行注释；
在书写playbook的时候，name最好是写上，从而表明相关的目的；
尽量保持playbook的简洁性；
控制版本。