创建新集合
从 Ansible 2.10 开始，相关模块应在集合（collection）中开发。Ansible 核心团队和社区汇编了这些模块开发技巧，旨在帮助为自有产品开发 Ansible 模块的公司，以及为第三方产品开发 Ansible 模块的用户。有关集合格式的详细描述和额外的开发指南，请参阅 开发集合。
注意
许可要求 Ansible 执行以下许可要求
- 实用程序（
lib/ansible/module_utils/中的文件）可以采用两种许可之一 在
module_utils中仅用于特定供应商的硬件、提供商或服务的文件可以使用 GPLv3+ 许可。在module_utils下添加使用 GPLv3+ 的新文件需要经过核心团队的批准。所有其他
module_utils必须在 BSD 许可下，以便 GPL 许可的第三方和 Galaxy 模块可以使用它们。如果对
module_utils中文件的适当许可有疑问，Ansible Core 团队将在 Ansible Core 社区会议期间决定。
- 实用程序（
随 Ansible 发行地所有其他文件（包括所有模块）必须在 GPL 许可（GPLv3 或更高版本）下。
现有的许可要求仍然适用于 ansible/ansible (ansible-core) 中的内容。
之前在 ansible/ansible 或某个集合中且现已移至新集合的内容，必须保留其在先前存储库中所持有的许可。
先前提交者的版权条目也必须保留在任何移动的文件中。
在开始编码之前
这份先决条件清单旨在确保您开发出高质量的模块，使其能与 ansible-core 良好协作并提供无缝的用户体验。
请阅读 开发模块 中链接的所有页面；特别关注 将您的模块贡献给现有的 Ansible 集合。
我们鼓励遵守 PEP 8 规范。更多信息请参阅 pep8。
我们鼓励支持 Python 2.6+ 和 Python 3.5+。
查看 Ansible Galaxy 并审查您所属功能领域（如云、网络、数据库）的命名约定。
能力越大，责任越大：Ansible 集合维护者有责任帮助保持内容更新，并定期发布其负责的集合。与所有成功的社区项目一样，集合维护者应密切关注报告的问题和贡献。
我们强烈建议进行单元测试和/或集成测试。当需要外部资源（如云或网络设备）时，单元测试尤为重要。更多信息请参阅 测试 Ansible。
命名约定
插件和模块的完全限定集合名称 (FQCN) 包含三个元素：
Galaxy 命名空间，通常代表公司或组织
集合名称，通常代表产品或操作系统
- 插件或模块名称
始终使用小写
单词之间用下划线 (
_) 字符分隔使用单数而非复数，例如，使用
command而非commands
例如，community.mongodb.mongodb_linux 或 cisco.meraki.meraki_device。
如果 GitHub（或其他平台）上的组织和仓库名称与您在 Ansible Galaxy 上的命名空间和集合名称一致会很方便，但这并非强制要求。不过，您选择的插件名称在代码仓库和 Galaxy 上的集合产物中必须始终保持一致。
与我们沟通
在编码前交流您的想法有助于您采用良好实践并避免常见错误。在阅读“在开始编码之前”部分后，您应该对模块的结构有一个大致的构思。列出您建议的插件和/或模块名称，并简要描述每个模块的功能。将该列表发布在 Ansible 论坛 上，以便 Ansible 社区审查您的想法是否具有一致性和熟悉度。一致、可预测且熟悉的名字和功能会让您的集合更易于使用。
在哪里获取支持
Ansible 拥有一个充满活力且知识渊博的模块开发人员社区，是解决您疑问的绝佳资源。详情请访问 Ansible 沟通指南。
必需文件
您的集合应包含以下文件才能正常使用：
一个
__init__.py文件 —— 一个用于初始化命名空间并允许 Python 导入文件的空文件。必需至少一个插件，例如
/plugins/modules/$your_first_module.py。必需如果需要，一个或多个
/plugins/doc_fragments/$topic.py文件 —— 代码文档，例如关于通用参数的详情。可选如果需要，一个或多个
/plugins/module_utils/$topic.py文件 —— 多个模块之间共享的代码，例如通用参数。可选
当这些文件准备就绪后，请再次审查 将您的模块贡献给现有的 Ansible 集合。如果您是在创建新集合，您将负责与仓库相关的所有流程，包括制定贡献规则、寻找评审员以及测试和维护集合中的代码。
Git 或 GitHub 新手
我们意识到这可能是您第一次使用 Git 或 GitHub。以下指南可能会有所帮助：