Ansible: Plusieurs fichiers dans le répertoire par défaut du rôle

vous pouvez avoir un main.yml dans tasks , qui inclut d'autres fichiers, même dans des sous-répertoires de tasks , par exemple pour configurer vos deux principaux composants foo et bar de ce grand rôle :

- include: foo/main.yml
- include: bar/main.yml

L'utilisation d'un module include_vars pour les variables de rôle par défaut va à l'encontre de la raison pour laquelle les variables par défaut existent en premier lieu, à savoir être utilisées pour fournir des "valeurs par défaut de dernier recours" qui peuvent être facilement écrasées par d'autres parties du rôle/playbook.

L'idée de plusieurs fichiers dans le répertoire defaults/ avait déjà été discutée sur IRC, nous avons conclu que l'analyse du répertoire defaults/ même manière que les répertoires inventory/group_vars/ et inventory/host_vars/ serait bon d'avoir. Le code nécessaire existe déjà et, espérons-le, peut être facilement adapté pour les rôles par défaut.

+1

+1

Ce serait bien de l'avoir !

+1

Oui, je suppose que les valeurs par défaut/* ont été trouvées et chargées automatiquement comme mentionné ci-dessus. Il semble que la solution de contournement suggérée (y compris les fichiers de valeurs par défaut supplémentaires dans les tâches) remplacera les variables d'inventaire en raison de la priorité des variables , il semble donc que nous devions peut-être regrouper dans 1 fichier pour éviter ce problème jusqu'à ce qu'il soit résolu.

Priorité des variables Ansible 2.x

    role defaults [1] (loading all role defaults here critical)
    inventory vars [2]
    inventory group_vars
    inventory host_vars
    playbook group_vars
    playbook host_vars
    host facts
    registered vars
    set_facts
    play vars
    play vars_prompt
    play vars_files
    role and include vars (hack coming in here will override everything above)
    block vars (only for tasks in block)
    task vars (only for the task)
    extra vars (always win precedence)

Cela peut être lié à #8121

+1

+1

Certainement une fonctionnalité indispensable en raison des contraintes de priorité variables.
Cela permet également de définir un fichier de valeurs par défaut par classe de variables et de garder une séparation nette ; par exemple, en réseau, cela me permettrait de définir un fichier par défaut pour IPv4, un pour IPv6, un pour SNMP et ainsi de suite...
Enfin, il semble nécessaire de pouvoir mettre ces fichiers dans différents dossiers sous "defaults".

Je viens de frapper celui-ci moi-même, donc, définitivement +1

C'est vraiment un PITA.
Si je pouvais suggérer une solution, ce serait d'ajouter une option, similaire à include_vars , mais en meta/main.yml , pour spécifier load-order.

- dependencies: []
- default_vars:
  - "main.yml"
  - "{{ ansible_os_family }}-{{ ansible_distribution_major_version }}.yml"

Cela permettrait à l'option de définir par défaut ["main.yml"] et de ne pas casser le code existant, tout en donnant aux développeurs la possibilité de définir des variables granulaires en fonction des contextes de leur choix.

Bizarre. Je me doutais totalement que cela fonctionnerait hors de la boîte. L'une des rares fois où ansible enfreint en fait un peu le principe de la moindre surprise...

Certainement +1

Pour vars/ la même chose, mais il semble que #2958 se soit prononcé contre cela

L'exemple de @cornfeedhobo correspond exactement à mon cas d'utilisation. En utilisant include_vars, j'empêche les remplacements faciles de toutes les variables individuelles par les jeux.

Une autre option d'interface serait :

• Ajoutez une option au module include_vars, 'as_default', qui traite le fichier inclus comme s'il était par défaut.

Pour moi, il semble vraiment étrange/contre-intuitif qu'il y ait un répertoire "defaults" avec un seul fichier dedans.
Je veux dire, avez-vous déjà vu un module python contenant un seul fichier __main__.py ?

C'est précisément pourquoi je pensais intuitivement que la fonctionnalité dont il était question sur ce ticket était déjà présente. "Bien sûr, je peux avoir plusieurs fichiers par défaut, il y a un répertoire pour ça"

include_role vous permet de spécifier des fichiers « alternatifs » maintenant http://docs.ansible.com/ansible/include_role_module.html via l'option defaults_from

Je viens de me retrouver dans une situation où la division defaults/main.yml est souhaitée. J'ai ajouté mon 👍 au problème.

Pareil ici, j'en ai besoin aussi
+1

+1

@bcoca c'est un ajout intéressant et ajoute de la flexibilité, mais ne résout pas le problème ici, et met la responsabilité sur l'auteur du playbook, alors que l'intention est de permettre au rôle de définir facilement des valeurs par défaut saines.

Veuillez revoir mon commentaire ci-dessus

Oui, c'est une fonctionnalité très utile pour éviter les fichiers avec 2k lignes.
+1

+1

+1

??

+1

+1

+1
Même problème ici. main.yml trop volumineux, divisé en plusieurs fichiers. Nous avons supposé que cela "fonctionnerait simplement" et chargerait toutes les variables dans les fichiers sous defaults/ puisqu'il s'agit d'un répertoire. pas de joie.

+1

+1

+1

??

+1

+1

??

Vous pouvez rejeter chaque commentaire +1, mais je doute fortement que vous puissiez suivre le nombre d'abonnés, donc ajouter +1 est toujours un moyen décent de montrer le soutien souhaité.

Jusqu'à ce que l'attention du problème soit clairement liée au nombre d'abonnés à un problème, attendez-vous toujours à voir +1 commentaires.

Ce à quoi vous pouvez vous attendre, c'est que l'équipe ansible verrouille les commentaires du problème à la place, alors ne soyez pas un spammeur et ne les défendez pas s'il vous plaît.

Ce à quoi vous pouvez vous attendre, c'est que l'équipe ansible verrouille les commentaires du problème à la place, alors ne soyez pas un spammeur et ne les défendez pas s'il vous plaît.

Ils pourraient le faire, mais c'est un problème essentiel pour pouvoir développer correctement les rôles, surtout depuis l'introduction de include_role dans 2.x aux côtés de l'ancienne méthode d'inclusion roles . Si vous concevez votre rôle pour qu'il soit compatible avec include_role , ce qui est préférable car cela rend le développement beaucoup plus modulaire et flexible qu'avec l'ancienne méthode roles seule, alors il vous reste pour suivre soit l'inclusion des valeurs par défaut en tant que tâches dans vos playbooks, soit passer la responsabilité à l'utilisateur final qui ne devrait pas avoir à savoir comment faire cela pour que votre rôle fonctionne correctement, soit suivre la plate-forme/distro/version en tant que niveau imbriqué de votre variables de rôle qui compliquent énormément le développement (bien que cela fonctionne car j'ai créé un rôle qui peut prendre en charge 20 versions de plate-forme différentes ici ). Avez-vous réellement essayé d'écrire un rôle qui prend en charge plusieurs plates-formes ? Il n'est pas surprenant que la plupart des rôles sur Ansible Galaxy ne le soient pas, ce problème est probablement le numéro un sur cette liste IMO.

Donc, s'ils allaient verrouiller cela, ne pas répondre du tout à un problème vieux d'un an et signaler à la communauté qu'ils ne sont pas intéressés à discuter de problèmes critiques qui empêchent les gens de créer de vraies solutions, alors ils peuvent certainement s'attendre à ce que les gens ne collent pas autour et continuer à utiliser le produit. S'ils répondent et donnent une idée s'ils sont d'accord pour dire que c'est un problème, alors peut-être que les gens cesseront de lui attribuer un +1 afin d'attirer l'attention sur le problème.

Ce n'est qu'un problème car ils ont publié include_role sans réfléchir à la manière dont l'utiliser dans la pratique affecterait les valeurs par défaut. Forcer quelqu'un à choisir entre utiliser roles et include_role afin de faire fonctionner correctement un rôle ou d'ajouter du travail supplémentaire pour permettre aux deux de fonctionner simultanément est au cœur du problème ici.

Mes 2 cents.

PS Si vous votez contre les +1 parce que vous ne voulez pas les notifications... appuyez sur le bouton de désabonnement en haut à droite et vous ne les recevrez plus.

OK, cette question est importante pour vous. Je comprends. Pour moi aussi. C'est pourquoi je suis abonné, BTW, et c'est pourquoi je ne veux pas me désabonner, et c'est pourquoi je vote contre les spammeurs, et c'est pourquoi je vote pour le commentaire d'origine , qui est la manière civilisée de montrer le soutien _lazy_ pour cela.

J'aimerais ajouter ma voix à la demande de cette capacité et détailler mon cas d'utilisation. En plus de la simple possibilité de décomposer un grand fichier main.yml, la possibilité de faire quelque chose comme ceci serait formidable :

- name: Some name
  include_default_vars:
  with_first_found:
    - "{{ ansible_os_family }}-{{ ansible_distribution_major_version }}.yml"
   - main.yml

Ce que j'espère accomplir avec ceci est [à titre d'exemple] un rôle openssh qui prend en charge toutes les options ssh_config et sshd_config, et prend en charge plusieurs systèmes d'exploitation et versions [c'est-à-dire. Debian 8/9, EL6/7, etc] mais qui, s'il est appelé sans var défini par l'utilisateur, construira en toute sécurité la configuration avec les paramètres par défaut OS_majorversion, mais qui peut avoir N'IMPORTE QUELLE option disponible surchargée par l'utilisateur.

Dans l'état actuel des choses, si je mets ces valeurs par défaut du système d'exploitation dans include_vars, la priorité est trop élevée et l'utilisateur ne peut pas remplacer ces paramètres dans l'inventaire, ou dans group_vars/all ou dans group_vars/groupname ou dans host_vars, etc.

Je suis sûr qu'il existe un moyen de le faire maintenant, mais tout ce à quoi je peux penser est extrêmement disgracieux et laid et serait difficile à maintenir. De plus, au moins jusqu'à présent, personne que j'ai rencontré #ansible n'a de meilleure idée sur la façon de le faire d'une manière gracieuse et maintenable.

L'ajout de cette fonctionnalité permettrait cela et pourrait aider à rendre disponibles des rôles de meilleure qualité dans github/galaxy.

@ ralphie02 non, ce n'est pas du tout une solution à ce sujet. Ce ne sont que des variables normales basées sur l'hôte, ce qui est différent de l'exigence de définir des valeurs par défaut pour un rôle multi-plateforme.

Vars / feature_idea similaires : https://github.com/ansible/ansible/issues/11639

C'est vraiment un PITA.
Si je pouvais suggérer une solution, ce serait d'ajouter une option, similaire à include_vars , mais en meta/main.yml , pour spécifier load-order.

- dependencies: []
- default_vars:
  - "main.yml"
  - "{{ ansible_os_family }}-{{ ansible_distribution_major_version }}.yml"

Cela permettrait à l'option de définir par défaut ["main.yml"] et de ne pas casser le code existant, tout en donnant aux développeurs la possibilité de définir des variables granulaires en fonction des contextes de leur choix.

Je pense vraiment que c'est une bonne solution, il n'y a pas de moyen vraiment simple pour le moment d'avoir un ensemble différent de valeurs par défaut par os/version/etc. Cette implémentation conserve également la compatibilité descendante, c'est donc aussi un bon choix.

En ligne avec @abedwardsw (commentez avant):
La proposition datant de plus de 2 ans de @doubletwist13 ) serait vraiment utile pour de nombreux rôles que je connais, en particulier le assez complexe :
https://github.com/hortonworks/ansible-hortonworks

Références directes à leurs commentaires :

• https://github.com/ansible/ansible/issues/14248#issuecomment-254059046
• https://github.com/ansible/ansible/issues/14248#issuecomment-329027052

Voir aussi la proposition de » @geerlingguy, et mon commentaire là (qui tente de rassembler les questions connexes) ( à partir de 2016!): Https://github.com/ansible/proposals/pull/21#issuecomment -470048538