通用提示

这些概念适用于所有 Ansible 活动和工件。

保持简单

只要有可能，就简单地做事。

仅在必要时使用高级功能，并选择最符合您的用例的功能。例如，您可能不会同时需要 vars、vars_files、vars_prompt 和 --extra-vars，同时还使用外部清单文件。

如果某些事情看起来很复杂，那么它很可能确实很复杂。花时间寻找更简单的解决方案。

使用版本控制

将您的剧本、角色、清单和变量文件保存在 git 或其他版本控制系统中，并在您进行更改时，对存储库进行有意义的注释的提交。版本控制可以为您提供一个审计跟踪，描述您何时以及为何更改了自动化基础设施的规则。

自定义 CLI 输出

您可以使用回调插件来更改 Ansible CLI 命令的输出。

避免配置依赖的内容

为了确保您的自动化项目易于理解、修改和与他人共享，您应该避免配置依赖的内容。例如，与其将 ansible.cfg 作为项目的根目录，不如使用诸如 playbook_dir 或 role_name 这样的魔术变量来确定相对于项目目录中已知位置的路径。这有助于保持自动化内容的灵活、可重用和易于维护。有关更多信息，请参阅特殊变量。

剧本提示

这些提示有助于使剧本和角色更易于阅读、维护和调试。

使用空格

大量使用空格（例如，每个块或任务之前有一行空白）使剧本易于扫描。

始终命名剧本、任务和块

剧本、任务和块的 - name: 是可选的，但非常有用。在输出中，Ansible 会向您显示它运行的每个命名实体的名称。选择描述每个剧本、任务和块的功能以及原因的名称。

始终提及状态

对于许多模块，state 参数是可选的。

不同的模块对 state 具有不同的默认设置，并且某些模块支持多个 state 设置。显式设置 state: present 或 state: absent 使剧本和角色更清晰。

使用注释

即使使用任务名称和显式状态，有时也需要对剧本或角色（或清单/变量文件）的一部分进行更多解释。添加注释（任何以 # 开头的行）可以帮助其他人（以及将来可能帮助您自己）理解剧本或任务（或变量设置）的功能、实现方式以及原因。

使用完全限定的集合名称

使用完全限定的集合名称 (FQCN) 可以避免在哪个集合中搜索每个任务的正确模块或插件的歧义。

对于内置模块和插件，请使用 ansible.builtin 集合名称作为前缀，例如，ansible.builtin.copy。

清单提示

这些提示有助于保持清单井井有条。

将动态清单与云一起使用

对于维护基础设施规范列表的云提供商和其他系统，请使用动态清单来检索这些列表，而不是手动更新静态清单文件。对于云资源，您可以使用标签来区分生产和登台环境。

按功能对清单进行分组

一个系统可以属于多个组。请参阅如何构建清单和模式：定位主机和组。如果您创建以组中节点的功能命名的组（例如，webservers 或 dbservers），那么您的剧本可以根据功能定位机器。您可以使用组变量系统分配特定于功能的变量，并设计 Ansible 角色来处理特定于功能的用例。请参阅角色。

分离生产和登台清单

您可以通过为每个环境使用单独的清单文件或目录，将生产环境与开发、测试和登台环境分开。这样，您就可以使用 -i 选择要定位的内容。将所有环境保存在一个文件中会导致意外情况！例如，使用该清单时，该清单中使用的所有保管密码都需要可用。如果清单包含生产和开发环境，那么使用该清单的开发人员将能够访问生产机密。

保持保管的变量安全可见

您应该使用 Ansible Vault 对敏感或机密变量进行加密。但是，对变量名称和变量值都进行加密会使查找值的来源变得困难。为了避免这种情况，您可以使用 ansible-vault encrypt_string 对变量进行单独加密，或者添加以下间接层以使变量名称可访问（例如，通过 grep），而不会暴露任何机密

创建一个名为组的 group_vars/ 子目录。
在这个子目录中，创建两个名为 vars 和 vault 的文件。
在 vars 文件中，定义所有需要的变量，包括任何敏感变量。
将所有敏感变量复制到 vault 文件中，并将这些变量加上 vault_ 前缀。
使用 jinja2 语法调整 vars 文件中的变量，使其指向匹配的 vault_ 变量：db_password: "{{ vault_db_password }}"。
加密 vault 文件以保护其内容。
在你的 playbook 中使用 vars 文件中的变量名。

运行 playbook 时，Ansible 会在未加密的文件中查找变量，然后从加密文件中提取敏感变量值。变量文件和 vault 文件的数量以及它们的名称没有限制。

请注意，在你的清单中使用此策略仍然需要所有 vault 密码可用（例如，对于 ansible-playbook 或 AWX/Ansible Tower），以便在使用该清单运行时。

执行技巧

这些技巧适用于使用 Ansible，而不是 Ansible 工件。

使用执行环境

使用称为执行环境的可移植容器镜像简化复杂性。

先在预发布环境中尝试

在生产环境中推出更改之前，先在预发布环境中测试更改始终是一个好主意。你的环境不需要相同的大小，你可以使用组变量来控制环境之间的差异。你也可以使用标志 --syntax-check（如以下示例所示）在预发布环境中检查语法错误

ansible-playbook --syntax-check

分批更新

使用 serial 关键字来控制在批处理中一次更新多少台机器。参见控制任务运行的位置：委派和本地操作。

处理操作系统和发行版差异

组变量文件和 group_by 模块协同工作，帮助 Ansible 在需要不同设置、软件包和工具的各种操作系统和发行版上执行。group_by 模块创建一个匹配特定条件的主机动态组。此组不需要在清单文件中定义。此方法使你可以在不同的操作系统或发行版上执行不同的任务。

例如，以下 playbook 根据操作系统名称将所有系统归类为动态组

- name: Talk to all hosts just so we can learn about them
  hosts: all
  tasks:

    - name: Classify hosts depending on their OS distribution
      ansible.builtin.group_by:
        key: os_{{ ansible_facts['distribution'] }}

后续 playbook 可以使用这些组作为 hosts 行上的模式，如下所示

- hosts: os_CentOS
  gather_facts: False
  tasks:

    # Tasks for CentOS hosts only go in this play.
    - name: Ping my CentOS hosts
      ansible.builtin.ping:

你也可以在组变量文件中添加特定于组的设置。在以下示例中，CentOS 机器为 asdf 获取值“42”，而其他机器获取值“10”。你也可以使用组变量文件将角色应用于系统以及设置变量。

---
# file: group_vars/all
asdf: 10

---
# file: group_vars/os_CentOS.yml
asdf: 42

注意

所有三个名称必须匹配：由 group_by 任务创建的名称、后续 playbook 中模式的名称以及组变量文件的名称。

当你只需要特定于操作系统的变量（而不是任务）时，可以使用相同的设置与 include_vars 一同使用

- name: Use include_vars to include OS-specific variables and print them
  hosts: all
  tasks:

    - name: Set OS distribution dependent variables
      ansible.builtin.include_vars: "os_{{ ansible_facts['distribution'] }}.yml"

    - name: Print the variable
      ansible.builtin.debug:
        var: asdf

这会从 group_vars/os_CentOS.yml 文件中提取变量。

另请参见

YAML 语法: 了解 YAML 语法
使用 playbook: 回顾基本的 playbook 功能
集合索引: 浏览现有的集合、模块和插件
是否应该开发一个模块？: 学习如何通过编写自己的模块来扩展 Ansible
模式：定位主机和组: 了解如何选择主机
交流: 有问题吗？需要帮助吗？想分享你的想法吗？访问 Ansible 交流指南