Cp-ansible: Поддержка Ansible Galaxy

Есть какие-нибудь обновления по этому поводу? Будет намного проще использовать эти пьесы.

В настоящее время нет планов публиковать в ansible galaxy. Я запрошу внутреннюю jira, чтобы изучить это в будущем выпуске.

Обычно ожидается клонирование репо, а затем запуск playbook, необходимый для данной настройки.

Ansible 2.9 представил новый формат распространения под названием Коллекции. Кажется, это лучше подходит для решения этой проблемы, поскольку коллекция может включать в себя playbooks, роли, модули и плагины.

Некоторые указатели:

• https://www.ansible.com/blog/getting-started-with-ansible-collections
• https://docs.ansible.com/ansible/latest/user_guide/collections_using.html
• https://docs.ansible.com/ansible/latest/dev_guide/developing_collections.html

Я предпринял попытку реструктуризации как коллекции галактик, протестировал работу с плейбуком all.yml и некоторыми в основном базовой конфигурацией (ssl и sasl / plain listeners). Его части очень неуклюжи, в первую очередь из-за того, что, насколько я могу судить, для ссылки на любые фильтры и модули вы должны ссылаться на все пространство имен галактики. Тем не менее, это работает для моего варианта использования, и я рад открыть PR, если команда сочтет, что стоит добавить.

https://github.com/aig787/cp-ansible/tree/agriffin/5.4.1-repack

@ aig787 Мне это нравится! Я всегда считал, что инструкции по обновлению должны быть в каталоге "playbook".
У ролей есть доступ к тому, что находится в каталоге плагинов, верно?
Также нужен ли каталог 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 вместе с остальными? Я _think_, что для использования playbooks людям все равно нужно будет клонировать репо и работать так, как они это делают сейчас. Преимущество наличия его в галактике было бы больше в том, чтобы дать людям доступ к ролям в их собственных настройках, чем облегчить игровые книги. В любом случае это мои 2 цента.

Мне лично все равно, где находится ansible.cfg, я просто знаю, если вы запустите playbook и ваш текущий каталог находится не там, где находится ansible.cfg, тогда возникнут проблемы.

Я вижу ценность соблюдения лучших практик и следования структуре каталогов коллекций, но мне любопытно, какие преимущества дает нам публикация этой коллекции в галактике. Больше видимости?

Мне кажется, что управление версиями в галактике и в наших ветках - это слишком много накладных расходов.

Это было бы выигрышем от простоты использования. Если у меня есть playbook, который выполняет некоторую базовую конфигурацию для всех моих узлов, я мог бы добавить это в файл требований и запустить `ansible-galaxy install -r requirements.yml 'и ссылаться на роль kafka в моем существующем playbook вместо того, чтобы клонировать репо и расширьте playbook или скопируйте каталоги ролей вокруг.

Что касается того, почему вы действительно должны его публиковать, я не верю, что коллекции поддерживают ссылки git, как это делают роли (https://galaxy.ansible.com/docs/using/installing.html#installing-multiple-roles-from-a -file vs. 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. Но внимательно посмотрев наши журналы для запуска playbook, я понял, что у нас могут быть дополнительные проблемы:

[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. И я думаю, что это можно исправить довольно легко, поскольку это сводится к ссылкам на следующие каталоги верхнего уровня /filter_plugins и /tasks внутри ролей.

Что вы думаете о следующих задачах как о запросах на вытягивание:

1. Перемещение /filter_plugins папки в confluent.variables роли - что делает его частью этой роли? Плагины фильтров, по крайней мере, используются в этой роли.

2. Переместите повторно используемые файлы задач в /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}}"

@erikgb Это то, что мы обсуждали внутри компании в прошлом. В частности, было довольно много дискуссий по поводу автономных ролей и минимизации дублирования кода. Похоже, нам придется изменить это для версии 2.12. выпуск Ansible, основанный на предупреждении, поэтому я думаю, что имеет смысл переместить как /filter_plugins и /tasks в роль confluent.common , а затем использовать правильные операторы импорта во всех других ролях.

@domenicbove, что ты

У меня нет проблем с перемещением файлов, пока функциональность остается неизменной @erikgb @JumaX.
Это кажется достаточно большой работой, чтобы перейти в основную ветку, хотя и нацеленную на наш следующий выпуск.

@domenicbove Согласен, что это работа над нашим следующим крупным выпуском. @erikgb Мы добавим внутреннюю JIRA, чтобы отслеживать это и посмотреть, сможем ли мы включить это в дорожную карту для нашей следующей версии.

Или @erikgb. Если у вас есть работа в ветке, вы можете сделать PR в главной ветке, и мы рассмотрим. Я не думаю, что это решит проблему полностью, нам еще нужно сделать галактику.

Следующий крупный выпуск? Будет ли это Confluent Platform 7? Я думаю, это изменение можно сделать обратно совместимым, если считать, что основными точками входа являются сценарии и роли. Я бы предпочел исправить это до CP 7. 😄

@erikgb это будет для CP 6.1, мы стараемся не

@domenicbove @JumaX CP 6.1 имеет больше смысла. Я посмотрю, получится ли у меня время поработать над запросами на вытягивание позже на этой неделе. Я бы рекомендовал разбить рефакторинг на значимые части. WDYT?

@erikgb Если вы хотите разделить его на несколько PR, это нормально, если предположить, что каждый PR может работать без дополнительных PR. Не уверен, что я это очень хорошо сказал. :). Следует стремиться к Главной ветви.