Ansible Playbook使用

最佳实践方案

这里有一些关于如何充分利用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服务器场，您会想用它来控制批次中一次更新的机器数量。

请参阅委派，滚动更新和本地操作。

打赏赞

页码： 1 2 3 4