首先,感谢这份了不起的工作。
我正在使用这些食谱,我不是 ansible 专家,所以我只是克隆了所有存储库内容并使用了角色,但我不知道是否是最好的使用方式。
我有点困惑,我可以使用其他方式而不是仅仅复制吗?
有没有打算让这个项目与星系兼容?
谢谢
有任何更新吗? 使用这些剧本会容易得多
目前没有发布到 ansible Galaxy 的计划。 我将提交内部 jira 以查看有关在未来版本中对此进行调查的情况。
一般的期望是克隆 repo,然后运行给定设置所需的剧本。
Ansible 2.9 引入了一种称为集合的新分发格式。 这似乎更适合解决这个问题,因为一个集合可以包括剧本、角色、模块和插件。
一些提示:
我尝试将重组作为一个星系集合,测试使用all.yml
剧本和一些基本的配置(ssl 和 sasl/plain listeners)。 它的一部分非常笨重,主要是据我所知,要引用任何过滤器和模块,您必须引用整个星系命名空间。 不过,它适用于我的用例,如果团队认为值得添加,我很高兴打开 PR。
https://github.com/aig787/cp-ansible/tree/agriffin/5.4.1-repack
@aig787我喜欢它! 我一直觉得升级剧本应该在“剧本”目录中
角色可以访问插件目录中的内容,对吗?
还需要 confluentinc_cp 目录吗?
一个棘手的部分是 ansible.cfg,我一直喜欢把它放在剧本旁边,因为要求在安装过程中使用该文件中的 ansible 配置
这些角色都可以访问插件目录 (https://docs.ansible.com/ansible/devel/dev_guide/developing_collections.html#plugins-directory) 中的内容。 我认为您只需要使用全名即可访问它,例如,我必须将KAFKA_OPTS: "{{ kafka_broker_final_java_args | java_arg_build_out }}"
更改KAFKA_OPTS: "{{ kafka_broker_final_java_args | aig787.confluent_cp.java_arg_build_out }}"
才能使过滤器为我工作。 可能有一些方法可以解决,但我找不到它。
刚刚尝试删除 confluentinc_cp 目录,它工作得很好,所以我想没有必要。 我最初用ansible-galaxy collection init
引导它并使用创建的结构。
是否有理由不能将 ansible.cfg 与其余部分一起移到 playbooks 目录中? 我_认为_为了使用剧本,人们仍然需要克隆 repo 并像现在一样运行。 在星系中使用它的好处更多是让人们可以在自己的设置中访问角色,而不是让剧本更容易。 反正那是我的 2 美分。
我个人并不关心 ansible.cfg 的放置位置,我只知道如果您运行剧本并且您当前的目录不在 ansible.cfg 的位置,那么就会出现问题。
我可以看到坚持 ansible 最佳实践和遵循集合目录结构的价值,但我很好奇将这个集合发布到星系中能给我们带来什么好处。 更能见度?
对我来说,在星系和我们的分支中管理版本控制似乎有很多开销。
这将是一个易于使用的增益。 如果我有一个对所有节点进行一些基本配置的剧本,我可以将其添加到需求文件中并运行“ansible-galaxy install -r requirements.yml”并在我现有的剧本中引用 kafka 角色,而不必克隆回购并扩展剧本或复制角色目录。
至于为什么你真的必须发布它,我不相信集合像角色一样支持 git 引用(https://galaxy.ansible.com/docs/using/installing.html#installing-multiple-roles-from-a -file 与 https://docs.ansible.com/ansible/latest/user_guide/collections_using.html#install-multiple-collections-with-a-requirements-file)。 我确实同意版本控制的开销量,这似乎有点沉重。
我个人并不关心是否在 Galaxy 中使用它,但是,能够轻松引用需求文件中的不同角色将非常感激 :smile:
即将注册一个新问题,但我认为我的问题与此问题有某种关系。 因此,从这里的评论开始,从维护者和其他观看者那里获得一些初步反馈。
我想使用此存储库中的角色,但我想将它们用作自定义角色(角色扩展)中的角色依赖项。 我们开始使用 playbook (all.yml),但是在正确的时间应用我们的扩展时遇到了很多麻烦。 我使用这种方法的第一个(阻塞)问题已通过https://github.com/confluentinc/cp-ansible/pull/442修复
[DEPRECATION WARNING]: Included file
'/builds/kafka/provisioner/tasks/failure_handling.yml' not found, however since
this include is not explicitly marked as 'static: yes', we will try and
include it dynamically later. In the future, this will be an error unless
'static: no' is used on the include task. If you do not want missing includes
to be considered dynamic, use 'static: yes' on the include or set the global
ansible.cfg options to make all includes static for tasks and/or handlers. This
feature will be removed from ansible-base in version 2.12. Deprecation
warnings can be disabled by setting deprecation_warnings=False in ansible.cfg.
看细节,我认为普遍的问题是角色目前不是独立的。 解决这个问题将是最终将角色或角色集合发布到 Ansible Galaxy 的强制性步骤。 而且我认为这可以很容易地修复,因为它归结/tasks
从角色内部引用以下顶级目录/filter_plugins
和/tasks
。
您如何看待以下任务作为拉取请求:
将/filter_plugins
文件夹移动到confluent.variables
角色 - 使其成为该角色的一部分? 过滤器插件至少在这个角色中使用。
将/tasks
的可重用任务文件移动到现有角色之一,可能confluent.common
是现有角色中最适合的,或者为它们创建一个新的专用角色( confluent.common_tasks
)? 并使用include_role#tasks_from更新对重用任务文件的
Index: roles/confluent.zookeeper/tasks/health_check.yml
<+>UTF-8
===================================================================
--- roles/confluent.zookeeper/tasks/health_check.yml (revision 0d369ae20c8215dd2ec469f269dc804539f58190)
+++ roles/confluent.zookeeper/tasks/health_check.yml (date 1602793473938)
@@ -25,7 +25,9 @@
ignore_errors: true
- name: Fetch Files for Debugging Failure
- include: tasks/failure_handling.yml
+ include_role:
+ name: confluent.common
+ tasks_from: failure_handling.yml
vars:
service_name: "{{zookeeper_service_name}}"
config_file: "{{zookeeper.config_file}}"
@erikbb这是我们过去在内部讨论过的问题。 特别是,有很多关于自包含角色与最小化代码重复的讨论。 看起来我们将不得不为 2.12 更改此设置。 Ansible 的发布,基于警告,所以我认为将/filter_plugins
和/tasks
到confluent.common
角色可能是最有意义的,然后使用适当的所有其他角色中的 import 语句。
@domenicbove你有什么想法?
只要功能保持一致@erikb @JumaX,我移动文件位置就没有问题。
这似乎是足够大的工作,它应该进入主分支,但针对我们的下一个版本。
@domenicbove同意它适用于我们的下一个主要版本。 @erikb我们将添加一个内部 JIRA 来跟踪这一点,看看我们是否可以将其
或者@erikb如果你有工作坐在一个分支,欢迎你在master分支做一个PR,我们会审核。 我认为这不会完全解决这个问题,我们仍然需要制作星系。
下一个主要版本? 那会是 Confluent Platform 7 吗? 我认为,这种更改可以向后兼容 - 只要将主要入口点视为剧本和角色。 我更愿意在 CP 7 之前解决这个问题。😄
@erikgb是 CP 6.1,我们倾向于不添加新功能,特别是如果它涉及到旧版本的重大重构。 我们有很多企业客户在我们为现有版本更改太多存储库时遇到策略/问题,我们尝试仅将其保留为错误修复。
@domenicbove @JumaX CP 6.1 更有意义。 本周晚些时候我会看看我是否有时间处理拉取请求。 我建议将重构拆分为有意义的部分。 WDYT?
@erikb如果您想将其拆分为多个 PR,假设每个 PR 仍然能够在没有额外 PR 的情况下运行,那很好。 不确定我说得很好。 :)。 应该瞄准主分支。
最有用的评论
Ansible 2.9 引入了一种称为集合的新分发格式。 这似乎更适合解决这个问题,因为一个集合可以包括剧本、角色、模块和插件。
一些提示: