创建新集合

从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_linuxcisco.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。以下指南可能对您有所帮助