创建新的集合
从 Ansible 2.10 开始,相关的模块应该在集合中开发。Ansible 核心团队和社区编制了这些模块开发技巧和窍门,以帮助开发其产品 Ansible 模块的公司以及为第三方产品开发 Ansible 模块的用户。请参阅 开发集合,以更详细地了解集合格式和额外的开发指南。
注意
**许可要求** Ansible 实施以下许可要求
- 实用程序(
lib/ansible/module_utils/
中的文件)可能具有以下两种许可证之一 module_utils
中仅用于特定供应商的硬件、提供商或服务的文件可以使用 GPLv3+ 许可。在module_utils
下添加使用 GPLv3+ 的新文件需要核心团队批准。所有其他
module_utils
必须使用 BSD 许可,以便 GPL 许可的第三方和 Galaxy 模块可以使用它们。如果对
module_utils
中文件的适当许可证有任何疑问,Ansible 核心团队将在 Ansible 核心社区会议期间做出决定。
- 实用程序(
与 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。以下指南可能对您有所帮助