一般提示
这些概念适用于所有 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文件以保护其内容。在剧本中使用
vars文件中的变量名称。
运行剧本时，Ansible 会在未加密文件中找到变量，这些变量会从加密文件中提取敏感变量值。变量和保险箱文件的数量以及名称没有限制。
请注意，在您的清单中使用此策略仍然需要所有保险箱密码可用（例如，用于 ansible-playbook 或 AWX/Ansible Tower），以便使用该清单运行。
执行技巧
这些技巧适用于使用 Ansible，而不是 Ansible 工件。
使用执行环境
使用称为 执行环境 的可移植容器映像来降低复杂性。
先在暂存环境中尝试
在生产环境中推出更改之前，在暂存环境中测试更改始终是一个好主意。你的环境不必相同大小，你可以使用组变量来控制不同环境之间的差异。你也可以使用标志 --syntax-check 在暂存环境中检查语法错误，例如以下示例
ansible-playbook --syntax-check
分批更新
使用 serial 关键字来控制你在批次中一次更新多少台机器。参见 控制任务运行的位置：委托和本地操作.
处理操作系统和发行版的差异
组变量文件和 group_by 模块协同工作，帮助 Ansible 在需要不同设置、软件包和工具的各种操作系统和发行版中执行。 group_by 模块创建与特定条件匹配的主机动态组。此组不需要在清单文件中定义。这种方法允许你在不同的操作系统或发行版上执行不同的任务。
例如，以下剧本根据操作系统的名称将所有系统分类到动态组中
- 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'] }}
随后的剧本可以使用这些组作为 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 任务创建的名称，后续剧本中模式的名称，以及组变量文件的名称。
当你只需要特定于操作系统的变量，而不是任务时，你可以使用相同的设置与 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 文件中提取变量。