Cp-ansible: Prise en charge d'Ansible Galaxy

Une mise à jour là-dessus ? Il sera beaucoup plus facile d'utiliser ces playbooks

Actuellement, il n'est pas prévu de publier sur ansible galaxy. Je vais déposer un jira interne pour voir comment enquêter sur cela pour une future version.

L'attente générale est de cloner le référentiel, puis d'exécuter le playbook requis pour la configuration donnée.

Ansible 2.9 a introduit un nouveau format de distribution appelé Collections. Cela semble être un meilleur moyen de résoudre ce problème, car une collection peut inclure des playbooks, des rôles, des modules et des plugins.

Quelques repères :

• 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

J'ai essayé de restructurer une collection de galaxies, j'ai essayé de travailler avec le playbook all.yml et certaines configurations principalement basiques (auditeurs SSL et sasl/plain). Certaines parties sont très maladroites, principalement que pour autant que je sache, pour référencer tous les filtres et modules, vous devez référencer l'ensemble de l'espace de noms de la galaxie. Cela fonctionne cependant pour mon cas d'utilisation, et je suis heureux d'ouvrir un PR si l'équipe pense que cela vaut la peine d'être ajouté.

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

@aig787 J'aime ça ! J'ai toujours pensé que les playbooks de mise à niveau devraient être dans un répertoire "playbook"
Les rôles ont accès à ce qui se trouve dans le répertoire des plugins, n'est-ce pas ?
Le répertoire confluentinc_cp est-il également nécessaire ?

Une pièce délicate est le fichier ansible.cfg, j'ai toujours aimé l'avoir juste à côté des playbooks, car il faut que la configuration ansible dans ce fichier soit utilisée lors de l'installation

Les rôles ont tous accès à ce qui se trouve dans le répertoire des plugins (https://docs.ansible.com/ansible/devel/dev_guide/developing_collections.html#plugins-directory). Je pense que vous n'avez qu'à utiliser le nom complet pour y accéder, par exemple, j'ai dû changer KAFKA_OPTS: "{{ kafka_broker_final_java_args | java_arg_build_out }}" en KAFKA_OPTS: "{{ kafka_broker_final_java_args | aig787.confluent_cp.java_arg_build_out }}" pour que le filtre fonctionne pour moi. Il y a peut-être un moyen de contourner cela, mais je n'ai pas pu le trouver.

Je viens d'essayer avec le répertoire confluentinc_cp supprimé et cela a très bien fonctionné, donc je suppose que ce n'est pas nécessaire. Je l'ai d'abord amorcé avec ansible-galaxy collection init et j'ai utilisé la structure qui a été créée.

Y a-t-il une raison pour laquelle ansible.cfg ne peut pas simplement être déplacé dans le répertoire playbooks avec le reste ? Je pense que pour utiliser les playbooks, les gens auraient toujours besoin de cloner le référentiel et de l'exécuter comme ils le font maintenant. L'avantage de l'avoir dans galaxy serait plus de donner aux gens l'accès aux rôles dans leurs propres configurations que de rendre les playbooks plus faciles. C'est mes 2 cents de toute façon.

Personnellement, je me fiche de l'emplacement de l'ansible.cfg, je sais simplement que si vous exécutez le playbook et que votre répertoire actuel n'est pas là où se trouve ansible.cfg, il y a alors des problèmes.

Je peux voir l'intérêt d'adhérer aux meilleures pratiques ansible et de suivre la structure des répertoires des collections, mais je suis curieux de savoir quels sont les avantages de la publication de cette collection dans Galaxy. Plus de visibilité ?

Pour moi, gérer la gestion des versions dans Galaxy et dans nos succursales me semble beaucoup de frais généraux.

Ce serait un gain de facilité d'utilisation. Si j'ai un playbook qui effectue une configuration de base sur tous mes nœuds, je pourrais l'ajouter à un fichier d'exigences et exécuter `ansible-galaxy install -r requirements.yml' et référencer le rôle kafka dans mon playbook existant plutôt que d'avoir à cloner le référentiel et étendez le playbook ou copiez les répertoires de rôles.

Quant à savoir pourquoi vous devez réellement le publier, je ne pense pas que les collections prennent en charge les références git comme le font les rôles (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). Je suis d'accord sur la quantité de frais généraux pour le versioning, cela semble un peu lourd.

Personnellement, je ne me soucie pas de l'avoir dans Galaxy ou non, mais pouvoir référencer facilement les différents rôles dans un fichier d'exigences serait vraiment apprécié :sourire:

J'étais sur le point d'enregistrer un nouveau problème, mais je pense que mon problème est en quelque sorte lié à ce problème. Commençons donc par un commentaire ici pour obtenir les premiers retours des responsables et des autres observateurs.

Je souhaite utiliser les rôles dans ce référentiel, mais je souhaite les utiliser comme dépendances de rôle dans mes rôles personnalisés (extensions de rôle). Nous avons commencé par utiliser le playbook (all.yml), mais nous avons eu beaucoup de mal à appliquer nos extensions avec le bon timing. Mon premier problème (bloquant) avec cette approche a été résolu avec https://github.com/confluentinc/cp-ansible/pull/442. Mais après avoir examiné de près nos journaux pour l'exécution du playbook, je me rends compte que nous pourrions avoir des problèmes supplémentaires :

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

En regardant les détails, je pense que le problème général est que les rôles ne sont actuellement pas autonomes. Corriger cela serait une étape obligatoire vers la publication éventuelle des rôles ou de la collection de rôles sur Ansible Galaxy. Et je pense que cela peut être corrigé assez facilement, car cela se résume à des références aux répertoires de niveau supérieur suivants /filter_plugins et /tasks partir des rôles.

Que pensez-vous des tâches suivantes en tant que demandes d'extraction :

1. Déplacez le dossier /filter_plugins dans le rôle confluent.variables - en l'intégrant à ce rôle ? Les plugins de filtrage sont au moins utilisés dans ce rôle.

2. Déplacez les fichiers de tâches réutilisables dans /tasks dans l'un des rôles existants, probablement confluent.common est le meilleur ajustement des rôles existants, ou créez un nouveau rôle dédié pour eux ( confluent.common_tasks ) ? Et mettez à jour les références aux fichiers de tâches réutilisés avec include_role#tasks_from . Exemple:

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 C'est quelque chose dont nous avons discuté en interne dans le passé. En particulier, il y a eu beaucoup de discussions sur les rôles autonomes, par rapport à la réduction de la duplication de code. Il semble que nous devrons changer cela pour la 2.12. version d'Ansible, sur la base de l'avertissement, donc je pense qu'il peut être plus logique de déplacer à la fois /filter_plugins et /tasks dans le rôle confluent.common , puis d'utiliser le bon importer des instructions dans tous les autres rôles.

@domenicbove qu'en

Je n'ai aucun problème avec le déplacement des emplacements de fichiers tant que la fonctionnalité reste cohérente @erikgb @JumaX.
Cela semble être un travail suffisamment important pour être transféré dans la branche master, en ciblant cependant notre prochaine version.

@domenicbove D'accord pour que ce soit un travail pour notre prochaine version majeure. @erikgb Nous ajouterons un JIRA interne pour suivre cela et voir si nous pouvons l'

Ou @erikgb Si vous avez le travail dans une branche, vous êtes invités à faire un PR dans la branche principale et nous passerons en revue. Je ne pense pas que cela résoudra ce problème dans son intégralité, nous devons encore créer la galaxie.

Prochaine version majeure ? Serait-ce la plate-forme Confluent 7 ? Ce changement pourrait être rendu rétrocompatible, je pense - tant que l'on considère que les principaux points d'entrée sont les playbooks et les rôles. Je préférerais que cela soit réglé avant le CP 7. 😄

@erikgb ce serait pour CP 6.1, nous avons tendance à ne pas mettre de nouvelles fonctionnalités, surtout si cela implique une refactorisation majeure dans les anciennes versions. Nous avons beaucoup de clients d'entreprise qui ont des politiques/problèmes lorsque nous modifions trop le référentiel pour la version existante, nous essayons de le garder uniquement pour les corrections de bogues.

@domenicbove @JumaX CP 6.1 a plus de sens. Je verrai si j'ai le temps de travailler sur les demandes d'extraction plus tard cette semaine. Je recommanderais de diviser la refactorisation en parties significatives. WDYT ?

@erikgb Si vous souhaitez le diviser en plusieurs PR, c'est bien en supposant que chaque PR peut toujours fonctionner sans PR supplémentaire. Je ne suis pas sûr de l'avoir très bien dit. :). Devrait viser la branche Master.