Ansible-role-nginx-config: Valeurs par défaut manquantes pour nginx_main_template.*

Tout à fait d'accord @alexsegura. L'option de définir des paramètres uniques se trouve dans le backlog. Le développement du rôle a été un peu plus lent que je ne le souhaiterais ces derniers temps, mais les choses devraient recommencer à s'accélérer dans les prochains mois. Cela étant dit, n'hésitez pas à soumettre un PR si vous le souhaitez 😄

Merci pour votre message.
Oui, je peux contribuer à une pull request 🙂

Le problème que je vois ici et là dans ce rôle, c'est que les valeurs par défaut sont codées en dur.
Donc, si les valeurs par défaut changent, vous devez vous rappeler de les changer à la fois dans defaults/main.yml , et dans les modèles.

https://github.com/nginxinc/ansible-role-nginx/blob/a92d424bdb5dc51b143c702754bed761e919a576/tasks/conf/upload-config.yml#L8 -L14

Je suppose que c'est parce que lorsque vous utilisez des dicts pour les valeurs par défaut, ils sont remplacés. Il y a un paramètre hash_behavior mais c'est global je pense.

Connaissez-vous un moyen de récupérer les variables par défaut « intactes » pour un rôle ?
Quelque chose comme role_defaults['var_name'] ?

@alexsegura Je ne connais pas un excellent moyen d'accomplir ce comportement. Idéalement, vous voudriez une configuration où le rôle peut déployer une configuration utile sans utiliser aucune des valeurs de defaults/main.yml .

La principale idée qui me vient à l'esprit serait d'utiliser vars/main.yml pour coder en dur certaines des valeurs par défaut, puis de faire quelque chose comme | default(var_main_upload_src) , mais je ne suis pas sûr que ce soit la meilleure voie à suivre.

La seule façon de le faire est probablement dans le modèle lui-même avec le filtre par défaut.

D'accord, c'est une bonne solution pour les paramètres liés aux modèles (et si vous regardez les fichiers de modèles, le filtre par défaut est déjà utilisé à quelques endroits). Et certes, cela résoudrait le problème initial. Ce serait une tâche assez longue mais c'est faisable.

Cependant, la question demeure de savoir quelle est la meilleure approche pour les variables non liées au modèle, et plus encore, existe-t-il une meilleure approche ?

D'après ce que je vois ici et là, la meilleure approche pour les valeurs par défaut est d'éviter d'utiliser des dicts, par exemple

nginx_main_template_user: www-data

à la place de

nginx_main_template:
  user: www-data

Cela résoudrait en partie le problème, et au départ, c'était ainsi que le rôle était structuré. Mais lorsque j'ai commencé à introduire des options de modèles plus complexes (par exemple, plusieurs blocs d'emplacement), les dictionnaires et les listes ont commencé à avoir plus de sens.

Ou vous pouvez utiliser des dictionnaires séparés pour la configuration par défaut et utilisateur et les fusionner avec le filtre combine . J'ai utilisé un rôle pour déployer un flux d'air où cette méthode est utilisée :
airflow_config: "{{ airflow_defaults_config | combine(airflow_user_config, recursive=True) }}"
Je suppose que cela supprimerait également le besoin d'avoir des valeurs par défaut codées en dur dans les modèles ?

Le rôle auquel je fais référence peut être consulté ici .

Hm, c'est une approche intéressante, et je peux la voir fonctionner. Cela vaudrait peut-être la peine de créer un petit PoC avec l'un des plus petits dictionnaires (je pense aux modèles main ou stream ) pour voir à quel point cela fonctionnerait bien dans la pratique.

J'ai déjà essayé cela pour le modèle principal et cela fonctionnait comme prévu. Cependant, parce que j'ai emprunté le chemin du moindre effort, j'ai fusionné deux dictionnaires nginx_default_main_template partir des valeurs par défaut et nginx_user_main_template du playbook des utilisateurs dans nginx_main_template .
Cela introduirait un changement décisif, je vais donc remanier le rôle pour utiliser le dictionnaire fusionné sous un nouveau nom et soumettre un PR.

Le modèle http est beaucoup plus difficile car il existe éventuellement plusieurs dictionnaires utilisateur à fusionner. Les ancres et les alias combinés à l' opérateur de fusion pourraient être une alternative, mais l'utilisateur est alors responsable de la fusion.
Je passerai du temps sur ce front aussi.

BTW : Y a-t-il une raison pour laquelle vous avez choisi d'utiliser un dictionnaire au lieu d'une liste pour définir plusieurs modèles http ? D'après ce que j'ai trouvé, la clé n'est jamais vraiment utilisée.

BTW : Y a-t-il une raison pour laquelle vous avez choisi d'utiliser un dictionnaire au lieu d'une liste pour définir plusieurs modèles http ? D'après ce que j'ai trouvé, la clé n'est jamais vraiment utilisée.

Non, pas vraiment. Avec le recul, je pense que cela peut améliorer la lisibilité d'avoir une clé pour chaque modèle HTTP que vous définissez, mais je ne suis pas opposé à la changer en une liste si cela facilite les choses.

Je suis tombé sur un problème similaire et par la suite sur ce problème. Je voudrais offrir une perspective alternative :

Les valeurs par défaut d'une configuration ne doivent pas du tout être codées en dur et être laissées au logiciel en cours d'installation.

Comme @alexsegura l'a déjà souligné, le problème est que vous devez garder les valeurs synchronisées, ce qui par nature ne sera pas toujours le cas (les humains sont sujets aux erreurs).

Si vous pensez que vous devez fournir une configuration par défaut, je suggérerais de conserver les sous-sections dans des répertoires séparés et de les combiner au niveau le plus bas si l'utilisateur spécifie une valeur, puis de les fusionner dans la configuration.

Mais même cela, imo, n'entre pas dans le cadre d'un rôle - il doit copier la configuration sur la cible et ne pas s'assurer que ses valeurs sont correctes ; Tout au plus, je donnerais une erreur si le logiciel ne pouvait pas démarrer en raison d'une erreur de configuration (ou utiliser la fonction de validation du logiciel, si disponible).

Curieusement, je travaille actuellement sur des moyens d'améliorer le fonctionnement des modèles dans le rôle. Cela a été un processus très lent (j'ai une bande passante plutôt limitée à consacrer au rôle pour le moment), mais je pense avoir trouvé une solution correcte qui résoudrait ces problèmes. En espérant que les changements soient en direct dans une branche séparée dans quelques mois maximum

Des progrès avec ce problème?

Nan. Il est toujours prévu d'y revenir dans un avenir "proche", mais quelques autres tâches ont été prioritaires.