常规提示
这些概念适用于所有 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文件中提取变量。