Neutrition - Bascule des VMs, 12 juin 2021

[event start=« 2021-06-12 08:00 » status=« public » name=« Neutriton - Bascule des VMs » end=« 2021-06-12 15:00 » allowedGroups=« trust_level_0 »]
[/event]

2021-06-12 (Neutriton) : Bascule des VMs

Présences :

  • Liberfix
  • HgO
  • Célo
  • Tharyrok
  • Channel :cat2: (en retard)

Jitsi : https://jitsi.belnet.be/neutriton
Caldarium : https://caldarium.be/fr:contact

Météo

Moment informel durant lequel on exprime en peu de mots comment on se sent et si on a une attente forte pour la réunion.
Ce n’est pas un moment de discussion mais d’expression individuelle et ce n’est pas obligatoire :slight_smile:

Attente(s) forte(s)

Si l’une ou l’autre personne exprime une attente forte, merci de vous en occuper en priorité ou de la noter dans le hub ou dans un point approprié.

Ordre du jour

La journée sera divisée en deux parties:

Prochaine réunion

Prochain Neutriton : 04/07 à 14h

Sujet : Monitoring

Lieu : Jitsi et/ou Caldarium

Météo de fin

Moment informel durant lequel on exprime en peu de mots comment, à titre personnel, la réunion a été vécue que ce soit positif ou négatif.
Si une ou plusieurs tension est née durant la réunion, il est peut-être nécessaire d’envisager l’une ou l’autre réunion pour y remédier.

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 :

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

  1. 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).

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

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

  1. 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).

Bascule de la VM web vers HAProxy

Pour le moment, neutrinet.be (et tous nos services web) arrivent directement sur la VM web. L’idée est de rediriger le flux pour que les requêtes tombent sur nos haproxy. Cela nous facilitera la vie à l’avenir pour rajouter de nouveaux services web.

Playbook HAProxy

Il faut simplifier le playbook haproxy et enlever les healthcheck. Finalement déjà fait, ça ne fait pas les healthcheck si on ne le demande pas :slight_smile:

Ensuite, s’assurer que tous les hosts soient bien listés :

  • admin.neutrinet.be → cube.neutrinet.be
  • api.neutrinet.be → vpn.patata.louise.neutri.net:8443
  • apps.neutrinet.be
  • auth.neutrinet.be
  • beta.neutrinet.be → neutrinet.be
  • beta-wiki.neutrinet.be → wiki.neutrinet.be
  • chat.neutrinet.be → localhost:8065
  • cube.neutrinet.be → localhost:5005
  • doku.neutrinet.be → wiki.neutrinet.be
  • http://ffdnapi.neutrinet.be
    → localhost:5005 si /isp.json
    → neutrinet.be sinon
  • files.neutrinet.be
  • forum.neutrinet.be
  • matomo.neutrinet.be
  • METTAAAAAAAAaaaAA (dans le meta il y a le meta)
  • neutrinet.be
    → si /apps.json alors apps.neutrinet.be
    → si /apps.dev.json alors apps.neutrinet.be
    → si /neutrinet_ynh_apps.json alors apps.neutrinet.be
  • stats.neutrinet.be
  • user.neutrinet.be
  • wikijs.neutrinet.be → VM web-static
  • wiki.neutrinet.be
  • wiki-old.neutrinet.be → mediawiki.neutrinet.be (VM web-static)
  • www.neutrinet.be → neutrinet.be

Oups on sait pas quoi en faire :

TODO: Faire une 404 pour ffdnapi.neutrinet.be au lieu d’une redirection vers neutrinet.be

On retire la partie SSL pour Nginx (meta, web et vpn). On n’oublie pas de désactiver les cron job (renew let’s encrypt certificates)

TODO: Vérifier le cron job de hackeragenda :

cd /var/www/hackeragenda-be && ve/bin/python manage.py fetch_events --quiet

Puis on change les règles NAT du pfsense pour pointer vers haproxy

Et pour terminer, on vérifie chacun des services web:

  • admin.neutrinet.be → ok
  • cube.neutrinet.be → ok
  • api.neutrinet.be → ouiiii
  • beta.neutrinet.be → ok
  • beta-wiki.neutrinet.be → ok
  • chat.neutrinet.be → ok
  • doku.neutrinet.be → ok
  • ffdnapi.neutrinet.be → ok
  • files.neutrinet.be → ok
  • meta.neutrinet.be → ok
  • neutrinet.be → ok
  • www.neutrinet.be → ok
  • user.neutrinet.be → ok
  • wikijs.neutrinet.be → ok
  • realms-wiki.neutrinet.be → ok
  • wiki-old.neutrinet.be → ok
  • mediawiki.neutrinet.be → ok