yourlabs.remember

`````````````````

Rôle méta pour les architectes d'automatisation Ansible.

Ce rôle apporte la magie pour améliorer les flux de travail des rôles Ansible :

• accélération massive : nécessite un rôle de dépendance une seule fois
• sans inventaire : se souvient des variables injectées depuis la ligne de commande sur l'hôte
• invite de variable CLI : questionnement interactif de l'utilisateur pour les faits

.. note:: Ce rôle ne télécharge pas automatiquement les rôles de dépendance : c'est le travail de la commande bigsudo <https://pypi.org/project/bigsudo/>_.

Démo

La manière la plus simple de l'essayer ::

pip install --user bigsudo ~/.local/bin/bigsudo yourlabs.fqdn user@somehost

Ou si vous vous sentez audacieux (skip hostname pour appliquer sur localhost)

~/.local/bin/bigsudo yourlabs.traefik

Bien sûr, vous pourriez aussi utiliser des commandes ansible, mais cela demanderait plus de commandes et d'options. Nous nous inspirons de la pratique de kubectl, pour les petits serveurs, les services non-HA, et les équipes de pizza. Même si, personnellement, je continuerais à utiliser bigsudo yourlabs.k8s pour configurer des instances k8s si je devais…

Utilisation

Ce rôle vous permet de définir quelles variables sont nécessaires dans votre propre rôle, ainsi que des éléments comme la description qui sera affichée à l'utilisateur, les valeurs par défaut, la validation par expression régulière, etc.

Injection de dépendance de rôle OAOO

Je vais prendre l'exemple de ce qui se passe avec yourlabs.traefik (un équilibreur de charge basé sur Docker) qui nécessite yourlabs.docker qui, à son tour, installe simplement Docker.

Cependant, pour l'exemple, j'utiliserai your.parent et your.child pour représenter les cas d'utilisation de yourlabs.docker et yourlabs.traefik respectivement.

Dans your.child/requirements.yml ::

• your.parent

Dans your.parent/requirements.yml ::

• yourlabs.remember

Ainsi, your.child dépend de your.parent, et your.parent dépend de yourlabs.remember.

.. note:: bigsudo veille à ce que les exigences soient installées de manière récursive lorsque vous exécutez bigsudo your.child.

Sans le rôle remember, vous incluriez normalement le rôle your.parent comme ceci en haut de your.child/tasks/main.yml ::

• name: Installer your.parent avant d'exécuter nos tâches include_role: name=your.parent

Cependant, cela jouera le rôle à chaque fois, ce qui rallonge l'exécution. Si vous ne voulez pas attendre que your.parent s'exécute complètement à chaque fois que vous exécutez your.child, vous pouvez transformer la tâche ci-dessus comme ceci en haut de your.child/tasks/main.yml :

.. code-block:: yaml

• name: Installer your.parent si jamais fait sur cet hôte include_role: name=your.parent when: ansible_facts['ansible_local']['your_parent']['state']|default('') != 'success'

Pour que cela fonctionne, vous devrez ajouter ce qui suit à la fin de your.parent/tasks/main.yml :

.. code-block:: yaml

• include_role: name=yourlabs.remember tasks_from=success

De cette façon, exécuter bigsudo your.parent (fonctionne aussi avec ansible) créera /etc/ansible/facts.d/your_parent.fact avec ce contenu ::

#!/bin/sh echo '{ "state": "success" }'

C'est ainsi que vous pouvez éviter d'inclure le rôle la prochaine fois.

Poursuivez la lecture pour ajouter vos variables de rôle personnalisées persistantes avec une configuration interactive.

Configuration interactive du rôle

Dans your.parent/vars/main.yml, définissez remember_fact qui est le namespace pour cette variable de déploiement de rôle ainsi que les variables dont votre rôle dépend comme ceci ::

remember_fact: your_parent remember:

• name: email_enable question: Activer un email personnalisé ? default: false type: bool
• name: email question: Quel email utiliser ? type: email default: '{{ lookup("env", "USER") }}@{{ inventory_hostname }}' when: email_enable

Ensuite, dans your.parent/tasks/main.yml, vous pouvez inclure yourlabs.remember et il chargera les variables et demandera à l'utilisateur de nouvelles variables de manière interactive, assez rapidement grâce au Plugin d'Action ::

• include_role: name=yourlabs.remember

Vous pouvez faire plus, référez-vous au playbook test.yml, que j'exécute avec ansible-playbook -c local -i localhost, test.yml -v --become :

.. include:: test.yml

Déploiements multiples : espace de noms pour les variables

Pour permettre plusieurs déploiements d'un rôle sur le même hôte, c'est-à-dire pour activer eXtreme DevOps, vous devrez faire dépendre votre remember_fact d'une variable.

Par exemple, vous voulez déployer un docker-compose dans différents répertoires sur votre hôte. Vous aurez besoin d'une variable home :

.. code-block:: yaml

remember:
- name: home
  question: Quel répertoire personnel déployer ? (doit commencer par /home pour l'exemple de regexp)
  default: /home/test
  type: path
  regexp: /home.*

Cela signifie que si l'utilisateur ne passe pas de variable home dans la ligne de commande (c'est-à-dire avec -e home=/home/bar), il sera invité à entrer le répertoire personnel. Maintenant, tout ce que nous avons à faire est de réutiliser cette variable home dans le remember_fact afin qu'elle espace les variables par répertoire personnel :

.. code-black:: yaml

remember_fact: your_role_j2((home))

Comme vous pouvez le voir, nous utilisons j2(( )) au lieu de {{ }}, cela permet d'empêcher Ansible de rendre cela avant d'obtenir une valeur pour la variable home. En fait, le plugin d'action remember va :

• essayer de rendre remember_fact pour charger les variables existantes, le cas échéant,
• attraper les exceptions AnsibleUndefinedVariable,
• trouver les définitions des variables indéfinies dont il a besoin dans remember,
• les demander sans les sauvegarder
• charger les variables existantes
• et demander toutes nouvelles variables

Conclusion

Enfin, nous arrivons à un point où nous avons un moyen clair et relativement simple de :

• injecter dynamiquement des rôles de dépendance pour accélérer les exécutions suivantes d'un rôle, empêchant ainsi l'exécution inutile de rôles de dépendance (comme Docker, équilibreur de charge, automatisation de bas niveau…)
• supprimer l'inventaire car chaque serveur conserve ses variables, c'est aussi DRY d'ailleurs, donc c'est encore un dépôt de moins dont vous devrez vous soucier !
• invite interactive de faits plus besoin de lire la documentation avant d'exécuter un rôle trouvé sur Internet en tant que root !

Crédits

Merci à totakoko de beta.gouv.fr pour les longues discussions et pour démontrer que mon inventaire était excessif et qu'il était possible de faire sans ;)

Merci à #ansible@irc.freenode.net, l’un des meilleurs canaux IRC, notamment :

• agaffney
• mackerman
• jborean93

Et merci à vous d'avoir lu ma petite aventure !