Cp-ansible: Ansible Galaxy-Unterstützung

Irgendein Update dazu? Es wird viel einfacher sein, diese Playbooks zu verwenden

Derzeit ist keine Veröffentlichung in Ansible Galaxy geplant. Ich werde eine interne Jira einreichen, um dies für eine zukünftige Version zu untersuchen.

Die allgemeine Erwartung besteht darin, das Repository zu klonen und dann das für das gegebene Setup erforderliche Playbook auszuführen.

Ansible 2.9 führte ein neues Distributionsformat namens Collections ein. Es scheint besser geeignet zu sein, dieses Problem zu lösen, da eine Sammlung Playbooks, Rollen, Module und Plugins enthalten kann.

Einige Hinweise:

• 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

Ich habe mich an der Umstrukturierung als Galaxie-Sammlung versucht, die Arbeit mit dem all.yml Playbook und einigen hauptsächlich grundlegenden Konfigurationen (SSL und Sasl/Plain-Listenern) getestet. Teile davon sind sehr klobig, vor allem, dass man, soweit ich das beurteilen kann, um auf Filter und Module zu verweisen, auf den gesamten Galaxien-Namensraum verweisen muss. Es funktioniert jedoch für meinen Anwendungsfall, und ich freue mich, eine PR zu eröffnen, wenn das Team der Meinung ist, dass es sich lohnt, es hinzuzufügen.

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

@aig787 Ich mag es! Ich war immer der Meinung, dass sich die Upgrade-Playbooks in einem "Playbook"-Verzeichnis befinden sollten
Die Rollen haben Zugriff auf das, was sich im Plugin-Verzeichnis befindet, oder?
Ist auch das confluentinc_cp dir notwendig?

Ein kniffliges Stück ist die ansible.cfg, die ich immer gerne direkt neben den Playbooks hatte, weil die ansible-Konfiguration in dieser Datei während der Installation verwendet werden muss

Die Rollen haben alle Zugriff auf das, was sich im Plugin-Verzeichnis befindet (https://docs.ansible.com/ansible/devel/dev_guide/developing_collections.html#plugins-directory). Ich denke, Sie müssen nur den vollständigen Namen verwenden, um darauf zuzugreifen, zB musste ich KAFKA_OPTS: "{{ kafka_broker_final_java_args | java_arg_build_out }}" in KAFKA_OPTS: "{{ kafka_broker_final_java_args | aig787.confluent_cp.java_arg_build_out }}" ändern, damit der Filter für mich funktioniert. Es könnte einen Weg geben, aber ich konnte es nicht finden.

Habe es gerade mit entferntem confluentinc_cp-Verzeichnis versucht und es hat gut funktioniert, also denke ich, dass es nicht notwendig ist. Ich habe es zunächst mit ansible-galaxy collection init gebootet und bin mit der erstellten Struktur gegangen.

Gibt es einen Grund, warum die ansible.cfg nicht einfach mit dem Rest in das Playbooks-Verzeichnis verschoben werden konnte? Ich _glaube_, dass die Leute, um die Playbooks zu verwenden, immer noch das Repo klonen und so ausführen müssen, wie sie es jetzt tun. Der Vorteil, es in der Galaxie zu haben, wäre eher, den Leuten Zugang zu den Rollen in ihren eigenen Setups zu geben, als Playbooks einfacher zu machen. Das sind sowieso meine 2 Cent.

Mir persönlich ist es egal, wo die ansible.cfg platziert ist, ich weiß nur, wenn du das Playbook startest und dein aktuelles Verzeichnis nicht dort ist, wo die ansible.cfg ist, dann gibt es Probleme.

Ich kann den Wert der Einhaltung bewährter Vorgehensweisen und der Befolgung der Verzeichnisstruktur der Sammlungen erkennen, bin aber gespannt, welche Vorteile uns die Veröffentlichung dieser Sammlung in der Galaxie bringt. Mehr Sichtbarkeit?

Für mich scheint es eine Menge Overhead zu sein, die Versionierung in Galaxy und in unseren Zweigen zu verwalten.

Es wäre ein Gewinn für die Benutzerfreundlichkeit. Wenn ich ein Playbook habe, das eine Basiskonfiguration für alle meine Nodes vornimmt, könnte ich dies zu einer Anforderungsdatei hinzufügen und `ansible-galaxy install -r requirements.yml' ausführen und auf die kafka-Rolle in meinem bestehenden Playbook verweisen, anstatt klonen zu müssen das Repo und erweitern Sie das Playbook oder kopieren Sie Rollenverzeichnisse herum.

Was den Grund für die Veröffentlichung angeht, glaube ich nicht, dass Sammlungen Git-Referenzen wie Rollen unterstützen (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). Ich stimme dem Umfang des Overheads für die Versionierung zu, er scheint ein wenig schwer zu sein.

Mir persönlich ist es egal, ob es in Galaxy vorhanden ist oder nicht, aber es wäre wirklich wünschenswert, auf die verschiedenen Rollen in einer Anforderungsdatei verweisen zu können :smile:

Wollte gerade ein neues Problem registrieren, aber ich denke, mein Problem hängt irgendwie mit diesem Problem zusammen. Beginnen Sie also mit einem Kommentar hier, um ein erstes Feedback von den Betreuern und anderen Zuschauern zu erhalten.

Ich möchte die Rollen in diesem Repository verwenden, aber ich möchte sie als Rollenabhängigkeiten in meinen benutzerdefinierten Rollen (Rollenerweiterungen) verwenden. Wir begannen mit der Verwendung des Playbooks (all.yml), hatten jedoch große Probleme, unsere Erweiterungen mit dem richtigen Timing anzuwenden. Mein erstes (blockierendes) Problem mit diesem Ansatz wurde mit https://github.com/confluentinc/cp-ansible/pull/442 behoben

[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.

Im Detail sehe ich das generelle Problem, dass die Rollen derzeit nicht in sich geschlossen sind. Dies zu beheben, wäre ein obligatorischer Schritt, um die Rollen oder die Rollensammlung schließlich in Ansible Galaxy zu veröffentlichen. Und ich denke, dies kann ganz einfach behoben werden, da es sich auf Verweise auf die folgenden Top-Level-Verzeichnisse /filter_plugins und /tasks innerhalb der Rollen hinausläuft.

Was halten Sie von den folgenden Aufgaben als Pull-Requests:

1. Verschieben Sie den Ordner /filter_plugins in die Rolle confluent.variables - um ihn zu einem Teil dieser Rolle zu machen? Die Filter-Plugins werden zumindest in dieser Rolle verwendet.

2. Verschieben Sie die wiederverwendbaren Aufgabendateien in /tasks in eine der vorhandenen Rollen, wahrscheinlich ist confluent.common die beste Lösung für die vorhandenen Rollen, oder erstellen Sie eine neue dedizierte Rolle für sie ( confluent.common_tasks )? Und aktualisieren Sie die Verweise auf die wiederverwendeten Aufgabendateien mit include_role#tasks_from . Beispiel:

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 Es ist etwas, das wir in der Vergangenheit intern diskutiert haben. Insbesondere gab es viele Diskussionen über in sich geschlossene Rollen im Gegensatz zur Minimierung von Codeduplizierung. Es sieht so aus, als ob wir dies für den 2.12 ändern müssen. Release von Ansible, basierend auf der Warnung, daher denke ich, dass es am sinnvollsten ist, sowohl /filter_plugins als auch /tasks in die Rolle confluent.common zu verschieben und dann die richtige zu verwenden import-Anweisungen in allen anderen Rollen.

@domenicbove was

Ich habe kein Problem mit dem Verschieben von Dateispeicherorten, solange die Funktionalität @erikgg @JumaX konsistent bleibt.
Dies scheint groß genug zu sein, um in den Master-Zweig zu gehen, der jedoch auf unsere nächste Version abzielt.

@domenicbove Einverstanden, dass es für unsere nächste Hauptversion funktioniert. @erikgb Wir werden eine interne JIRA hinzufügen, um dies zu verfolgen und zu sehen, ob wir es in die Roadmap für unsere nächste Version aufnehmen können.

Oder @erikgb Wenn du die Arbeit in einer Filiale sitzen hast, kannst du gerne eine PR in die Meisterfiliale machen und wir prüfen sie. Ich glaube jedoch nicht, dass das dieses Problem vollständig lösen wird, wir müssen noch Galaxie machen.

Nächstes Major- Release? Wäre das Confluent Platform 7? Diese Änderung könnte abwärtskompatibel gemacht werden, denke ich - solange man die Haupteinstiegspunkte als die Playbooks und die Rollen betrachtet. Ich würde es vorziehen, dies vor CP 7 zu beheben. 😄

@erikgb es wäre für CP 6.1, wir neigen dazu, keine neuen Funktionen

@domenicbove @JumaX CP 6.1 macht mehr Sinn. Ich werde sehen, ob ich im Laufe dieser Woche etwas Zeit habe, um an Pull-Requests zu arbeiten. Ich würde empfehlen, das Refactoring in sinnvolle Teile aufzuteilen. WDYT?

@erikbb Wenn Sie es in mehrere