Cp-ansible: AnsibleGalaxyのサポート

更新はありますか？ これらのプレイブックを使用する方がはるかに簡単になります

現在、ansible銀河に公開する予定はありません。 将来のリリースのためにこれを調査することについて確認するために、内部jiraを提出します。

一般的な期待は、リポジトリのクローンを作成してから、特定のセットアップに必要なプレイブックを実行することです。

Ansible 2.9では、コレクションと呼ばれる新しい配布形式が導入されました。 コレクションにはプレイブック、役割、モジュール、プラグインを含めることができるため、この問題を解決するのに適しているようです。

いくつかの指針：

• 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リスナー）での作業をテストしました。 その一部は非常に不格好です。主に、フィルターとモジュールを参照するように指示できる限り、銀河の名前空間全体を参照する必要があります。 ただし、これは私のユースケースでは機能します。チームが追加する価値があると判断した場合は、PRを開いて喜んでいます。

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

@ aig787私はそれが好きです！ アップグレードプレイブックは「プレイブック」ディレクトリにあるべきだといつも感じていました
ロールはプラグインディレクトリの内容にアクセスできますか？
また、confluentinc_cpディレクトリは必要ですか？

トリッキーな部分の1つは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ディレクトリに移動できなかった理由はありますか？ プレイブックを使用するには、リポジトリのクローンを作成して、現在と同じように実行する必要があると思います。 銀河系でそれを持っていることの利点は、プレイブックを簡単にするよりも、人々が自分のセットアップで役割にアクセスできるようにすることです。 それはとにかく私の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 -ファイルとhttps://docs.ansible.com/ansible/latest/user_guide/collections_using.html#install-multiple-collections-with-a-requirements-file）。 バージョン管理のオーバーヘッドの量については同意しますが、少し重いようです。

私は個人的にGalaxyにあるかどうかは気にしませんが、要件ファイル内のさまざまな役割を簡単に参照できることは本当にありがたいです：smile：

新しい号を登録しようとしていましたが、私の号はどういうわけかこの号に関連していると思います。 そこで、ここでコメントから始めて、メンテナや他の人から最初のフィードバックを得てください。

このリポジトリのロールを使用したいのですが、カスタムロール（ロール拡張）のロール依存関係として使用したいと思います。 プレイブック（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.

詳細を見ると、一般的な問題は、役割が現在自己完結型ではないということだと思います。 これを修正することは、最終的にロールまたはロールコレクションをAnsibleGalaxyに公開するための必須のステップになります。 そして、これは、ロール内からの次のトップレベルディレクトリ/filter_pluginsおよび/tasksへの参照に要約されるため、非常に簡単に修正できると思います。

プルリクエストとしての次のタスクについてどう思いますか。

1. /filter_pluginsフォルダーをconfluent.variablesロールに移動します-それをそのロールの一部にしますか？ フィルタプラグインは、少なくともこの役割で使用されています。

2. 再利用可能なタスク- /tasks内のファイルを既存の役割の1つに移動します。おそらく、 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
これは、次のリリースを対象として、マスターブランチに入るのに十分な大きさのようです。

@domenicbove次のメジャーリリースで機能することに同意しました。 @erikgbこれを追跡し、次のリリースのロードマップで取得できるかどうかを確認するために、内部JIRAを追加します。

または@erikgbブランチに作業を配置している場合は、PRをマスターブランチに作成してください。レビューします。 それでこの問題が完全に解決するとは思いませんが、それでも銀河を作る必要があります。

次のメジャーリリース？ それはConfluentPlatform 7でしょうか？ この変更は、主要なエントリポイントがプレイブックと役割であると見なす限り、下位互換性を持たせることができると思います。 CP7の前にこれを修正したいと思います。😄

@erikgb CP 6.1の場合、特に古いリリースへの大規模なリファクタリングが含まれる場合は、新しい機能を追加しない傾向があります。 既存のバージョンのリポジトリを変更しすぎると、ポリシーや問題を抱えている企業顧客がたくさんいます。バグ修正のみを維持するようにしています。

@domenicbove @JumaX CP6.1の方が理にかなっています。 今週後半にプルリクエストに取り組む時間ができるかどうかを確認します。 リファクタリングを意味のある部分に分割することをお勧めします。 WDYT？

@erikgb複数のPRに分割する場合は、追加のPRがなくても各PRを実行できると仮定すると問題ありません。 私がそれを非常にうまく述べたかどうかはわかりません。 :)。 マスターブランチを目指す必要があります。