创建新的集合
从 Ansible 2.10 开始，相关的模块应该在一个集合中开发。Ansible Core 团队和社区汇编了这些模块开发技巧和诀窍，以帮助公司为其产品开发 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。以下指南可能有用