Présentation de Molecule
Comment tester un playbook Ansible sur sa machine à l’aide de Molecule.
Molécule est présent dans les playbook de Neutrinet. Il permet de tester un rôle Ansible. On ne teste pas directement un playbook mais un rôle. Ça teste le cœur : la logique avec laquelle les choses sont appliquées.
Il y a plusieurs étapes :
molecule create
La création d’une VM sur sa machine (ça peut être un conteneur LXC ou Docker).
HgO l’utilise surtout dans une VM lancée via Vagrant qui est prévu pour les développeurs, pour tester leur code dans une VM. Avec Vagrant, on peut choisir si on lance avec virtualbox ou autre chose. VirtualBox est plus user friendly.
On installe Ansible et Molécule. Neutrinet a un fichier requirements.txt contenant toutes les dépendances nécessaires à installer. Ça créé un virtualenv. Une fois dans cet environnement, on a molécule et Ansible. On a plusieurs commandes, pour créer, lancer le playbook, détruire la VM. Attention : lorsqu’on redémarre son ordinateur, ça coupe la VM. Donc après, si on veut connecter la VM, elle est coupée. Du coup, pour être sûr, on peut commencer par faire un destroy pour être sûr de repartir d’un environnement vide.
Lorsque la VM est créée, elle apparait dans VirtualBox. On peut les supprimer manuellement depuis VirtualBox aussi.
Dans Molecule, on peut choisir le type de machine. Là c’est du Debian. C’est le fichier molecule.yml qui définit la machine a créer. Le driver est important, ici Vagrant. Et provider, VirtualBox (mais on pourrait en mettre un autre). Name : on peut mettre la distribution et molécule. C’est pas obligatoire mais ça permet de se repérer dans VirtualBox. Le provisionner : comment on crée la machine et avec quelle config. Config option : permet de définir les options propres à Ansible. En fait, cela permet de définir les options qui sont dans ansible.cfg. Ça regarde quelle version de python, quels secrets, etc, on va utiliser. On ne va pas s’y attarder mais c’est important pour définir la version de python à utiliser. Configuration réseau. Il y a une configuration standard (par défaut il fait du NAT) → comme la config standard de VirtualBox.
Pour le Nextcloud de Neutrinet, HgO a créé une interface virtuelle supplémentaire pour contacter la VM en interne. → réseau privé hôte dans VirtualBox.
molecule converge
Une fois la machine créée, on fait le converge.
Le converge, c’est exécuter le rôle qu’on veut tester sur la VM. En général, le converge, ça va juste être : s’autoriser à se connecter comme sudoer, et exécuter le rôle qu’on teste (par ex. le rôle commun). Note : si la machine n’existe pas, molecule va la créer automatiquement.
On parle plutôt de tester un rôle qu’un playbook car on va en général tester un rôle à la fois. Mais une fois que toutes les briques sont testées, on peut considérer que ça fonctionne.
Config réseau : il peut y avoir des soucis avec certaines cartes Wifi (c’est lié à Virtualbox).
molecule prepare
prepare.yml : juste après la création de la VM, ça installe une première fois les dépendences nécessaires au fonctionnement du rôle, comme par exemple avahi ou docker. Ça ne sera plus fait dans les converge suivant.
Commande idempotence : permet de vérifier que c’est idempotent. En principe, on peut le lancer à la place d’un converge et il lance deux converge. L’idempotence, pour rappel, c’est le fait qu’on lance les commandes mais que rien n’est modifié. On peut le lancer autant de fois qu’on veut et ça ne change plus rien.
Utilisateur neutrinet : défini par défaut dans les valeurs par défaut du playbook commun.
Une bonne pratique c’est que les options par default d’un playbook suffisent pour faire les test dans molécule. Car molecule ne charge pas les variable du playbook. Du coup si une variable est utilisées dans un role et qu’elle n’as pas de valeur par default, molecule va raler.
Dans molécule, on peut utiliser des variables propres à molécule. Un groupe_var comme pour les machines mais on peut aussi créer des fichiers propre aux playbook. Par exemple, HgO a créé la clé publique / privée de l’utilisateur neutrinet. Au cas où vagrant ne permet pas de se connecter aux machines, il y a moyen de le faire par ce biais là. Cela permet de tester si les utilisateurs créés par le rôle commun peuvent se connecter à la machine.
molecule login
Molecule avec sa commande login va utiliser le vagrant login qui lors de la création de la vm va injecter dans l’utilisateur vagrant la clés ssh qu’il a créer pour l’occasion.
La question pour nous est de savoir si on a nos propre cles est-ce que molecule login marche … en fait non. Mais quand on ce connect directement avec la commande ssh cela marche.
molecule test
verify.yml : pas encore utilisé, mais c’est une fonctionnalité qui permet de vérifier qu’un rôle a été bien fait en exécutant des tests sur la machine après le converge. Par ex que le port 80 répond bien, qu’un tel utilisateur a bien été créé.
Vérification syntaxique
En parallèle à Molecule, nous avons rajouté des outils pour vérifier que les playbooks sont correctement écrits.
Pre-commit (?) : Cela va faire des check de syntaxe, et ça va dire si la syntaxe n’est pas bonne avant de commiter. Ca va regarder s’il y a un espace à la fin de la ligne par exemple (et le corriger si cela se produit).
Commande ansible-lint → c’est une commande supplémentaire mais dans les playbook de Neutrinet, on l’installe comme un requierment.
Gestion des secrets
Comment gérer les secrets dans un dépôt git accessible à tout le monde ?
Vault : une suite de chiffre incompréhensibles qui utilisent un algorithme de chiffrement AES. C’est basé sur une clé privée placée dans vault.key. Ansible l’utilise pour chiffrer et déchiffrer les secret (avec du chiffrement symétrique).
Une commande, ansible-vault permet de créer un fichier vault, déchiffrer ou rechiffrer un fichier vault. Cela peut aussi être édité en nano ou vim. Les secrets vault peuvent être mis comme une variable ou comme un fichier.
Comment faire alors que vault.key est visible sur git pour ne pas que la clé privée soit vue ? On utilise un outil qui s’appelle git-crypt. C’est dans .gitattributes qu’on définit que pour ce fichier on va utiliser git crypt lorsqu’on fait un commit. Ca chiffre le fichier vault.key avec les clés gpg. Donc il faut que ce soit chiffré pour sa clé gpg si on veut utiliser le playbook.
On a donc du chiffrement symétrique et assymétrique (avec les clés GPG de chacun).
(en retard)