最佳实践方案
这里有一些关于如何充分利用Ansible和Ansible playbooks。
您可以在我们的示例资源库中找到说明这些最佳实践的一些示例手册。
目录布局
目录的顶层将包含文件和目录，如下所示：
production # inventory file for production servers
staging # inventory file for staging environment
group_vars/
group1 # here we assign variables to particular groups
group2 # ""
host_vars/
hostname1 # if systems need specific variables, put them here
hostname2 # ""
library/ # if any custom modules, put them here (optional)
module_utils/ # if any custom module_utils to support modules, put them here (optional)
filter_plugins/ # if any custom filter plugins, put them here (optional)
site.yml # master playbook
webservers.yml # playbook for webserver tier
dbservers.yml # playbook for dbserver tier
roles/
common/ # this hierarchy represents a "role"
tasks/ #
main.yml # <-- tasks file can include smaller files if warranted
handlers/ #
main.yml # <-- handlers file
templates/ # <-- files for use with the template resource
ntp.conf.j2 # <------- templates end in .j2
files/ #
bar.txt # <-- files for use with the copy resource
foo.sh # <-- script files for use with the script resource
vars/ #
main.yml # <-- variables associated with this role
defaults/ #
main.yml # <-- default lower priority variables for this role
meta/ #
main.yml # <-- role dependencies
library/ # roles can also include custom modules
module_utils/ # roles can also include custom module_utils
lookup_plugins/ # or other types of plugins, like lookup in this case
webtier/ # same kind of structure as "common" was above, done for the webtier role
monitoring/ # ""
fooapp/ # ""
替代布局
或者，您可以将每个库存文件与其group_vars / host_vars放在一个单独的目录中。 如果你的group_vars / host_vars在不同的环境中没有那么多共同点，这是特别有用的。 布局可能看起来像这样：
inventories/
production/
hosts # inventory file for production servers
group_vars/
group1 # here we assign variables to particular groups
group2 # ""
host_vars/
hostname1 # if systems need specific variables, put them here
hostname2 # ""
staging/
hosts # inventory file for staging environment
group_vars/
group1 # here we assign variables to particular groups
group2 # ""
host_vars/
stagehost1 # if systems need specific variables, put them here
stagehost2 # ""
library/
module_utils/
filter_plugins/
site.yml
webservers.yml
dbservers.yml
roles/
common/
webtier/
monitoring/
fooapp/
这种布局可为更大的环境提供更大的灵活性，以及不同环境之间库存变量的完全分离。 缺点是难以维护，因为有更多的文件。
区分Staging和Production
如果管理静态库存，经常会问如何区分不同类型的环境。下面的例子显示了一个很好的方法来做到这一点。类似的分组方法可以适用于动态库存（例如，应用AWS标记”environment:production”，您将得到一组自动发现名为“ec2_tag_environment_production”）。
让我们来看一个静态库存的例子。 在下面，生产文件包含所有生产主机的清单。
建议您根据主机（角色）的用途以及地理位置或数据中心位置（如果适用）来定义组：
# 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
组和主机变量
继续上面的例子。
Groups对组织很好，但这不是所有groups都适合的。 你也可以给它们分配变量！ 例如，亚特兰大拥有自己的NTP服务器，因此在设置ntp.conf时，我们应该使用它们。 现在我们来设置它们：
--- # file: group_vars/atlanta ntp: ntp-atlanta.example.com backup: backup-atlanta.example.com
变量不仅仅是使用地理信息！ 也许Web服务器有一些对数据库服务器没有意义的配置：
--- # file: group_vars/webservers apacheMaxRequestsPerChild: 3000 apacheMaxClients: 900
如果我们有任何默认值或通用的值，我们会将它们放在名为group_vars / all的文件中：
--- # file: group_vars/all ntp: ntp-boston.example.com backup: backup-boston.example.com
我们可以在host_vars文件的系统中定义特定的差异，但要避免这样做，除非您需要：
--- # file: host_vars/db-bos-1.example.com foo_agent_port: 86 bar_agent_port: 99
同样，如果我们使用动态库存来源，则会自动创建许多动态组。 所以像“class：webserver”这样的标签会自动加载文件“group_vars / ec2_tag_class_webserver”中的变量。
顶级剧本按角色分隔
在site.yml中，我们导入一个定义我们整个基础架构的剧本。 这是一个很短的例子，因为它只是导入一些其他的剧本：
--- # file: site.yml - import_playbook: webservers.yml - import_playbook: dbservers.yml
在像webservers.yml（也在顶层）的文件中，我们将webservers组的配置映射到webservers组执行的角色：
---
# file: webservers.yml
- hosts: webservers
roles:
- common
- webtier
这里的想法是，我们可以选择通过“运行”site.yml来配置整个基础架构，或者我们可以选择通过运行webservers.yml来运行子集。 这与“–limit”参数类似，但是更加明确：
ansible-playbook site.yml --limit webservers ansible-playbook webservers.yml
组织角色的任务和处理程序
以下是解释角色如何工作的示例任务文件。 我们在这里的common角色只是设置NTP，但如果我们想,它可以做更多的事情：
---
# 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: started
enabled: yes
tags: ntp
下面是一个处理程序的示例文件。 作为展示，处理程序仅在某些任务报告更改时触发，并在每次剧本结束时运行：
---
# file: roles/common/handlers/main.yml
- name: restart ntpd
service:
name: ntpd
state: restarted
组织实施的内容（示例）
上面我们分享了基本组织的结构。
现在介绍这种布局能有什么样的用例？很多！ 如果想重新配置所有主机，那只用：
ansible-playbook -i production site.yml
重新配置所有NTP：
ansible-playbook -i production site.yml --tags ntp
仅重新配置webservers：
ansible-playbook -i production webservers.yml
对于在波士顿的Web服务器：
ansible-playbook -i production webservers.yml --limit boston
前10个，和接下来的10个：
ansible-playbook -i production webservers.yml --limit boston[0:9] ansible-playbook -i production webservers.yml --limit boston[10:19]
当然，基本的临时任务也是可能的：
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
部署与配置组织
以上设置模拟了典型的配置拓扑。 在进行多层部署时，将会有一些额外的剧本可以在各层之间跳转以推出应用程序。 在这种情况下，’site.yml’可能会增加像’deploy_exampledotcom.yml’这样的剧本，但一般的概念仍然可以应用。
将“playbooks”比喻为体育 – 你不必一直都有一套剧本用来对付你的基础设施 – 你可以有不同时间和不同目的的情景剧。
Ansible允许您使用相同的工具进行部署和配置，因此您可能会重复使用组，并将操作系统配置保存在单独的应用部署中。
Staging vs Production
如上所述，保持分段staging（或测试）和生产production环境分离的好方法是使用单独的库存文件。 这样你就可以用 -i 选择你的目标。 将它们全部保存在一个文件中可能会导致意外！
在尝试进行生产之前在暂存环境中测试事物总是一个好主意。 您的环境不需要具有相同的大小，您可以使用组变量来控制这些环境之间的差异。
滚动更新
了解’serial’关键字。 如果更新Web服务器场，您会想用它来控制批次中一次更新的机器数量。