• Réunion précédente
• Pad de la réunion

Présences :

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

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

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

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

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

• À partir de 10h :

  1. Présentation de Molecule (uniquement si des gens sont intéressés)
  2. Configuration des playbooks Ansible
  3. Création des VMs dans Proxmox
• À partir de 14h :
  • Bascule de la VM web derrière les HAProxy
  • Configuration des playbooks Ansible

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. Ca teste le coeur : la logique avec laquelle les choses sont appliquée.

IL y a plusieurs étapes :

1) La création d'une VM sur sa machine (ça peut être un conteneur LXC). 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 requierment : toutes les dépendances nécessaires à installer. Ca créé un virtual env. 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éé la machine et avec quelle config. Config option : permet de définir les options propres à Ansible. En fait, cela reprend ansible.cfg. Ca 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 pithon à utiliser. Configuration réseau. Il y a une configuration standart (par défaut il fait du NAT) → comme la config standart de VirtualBox.

Pour Ansible de Neutrinet, HgO a créé une interface virtuelle supplémentaire pour contacter la VM en interne. → réseau privé hôte dans VirtualBox.

2) Une fois la machine crée, on fait le converge. Le converge, c'est exécuter le rôle commun 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 commun.

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

prepare.yml : juste après la création de la VM, ça lance avahi ou docker une première fois. Ca ne sera plus fait dans les converge suivant.

Commande idempotence : permet de vérifier que c'est idempotent. En prinicpe, 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 option par default d'un playbook suffi pour faire les test dans molécule. Car molecule ne charge pas les variable du playbook. Du coup si une variable est utiliser 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à.

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 cles ssh qu'il a créer pour locasion. La queston c'est de savoir si on a nos propre cles es-ce que molecule login marche … en fait non. Mais quand on ce connect directement avec la commande ssh cela marche.

Pre-commit (?) : Cela va faire des check de syntaxe, et ça va dire si la synthaxe n'est pas bonne avant de commiter. Ca va regarder s'il y a un espace à la fin de la ligne par exple. Il a va aussi corriger si c'est des choses comme ça. Commande ansible-lint → c'ets une commande supplémentaire mais dans les playbook de Neutrinet, on l'installe comme un requierment.

Verify : pas encore utilisé, mais c'est une fonctionnalité qui permet de vérifier qu'un rôle a été bien fait, par ex que le port 80 répond bien, qu'un tel utilisateur a bien été créé.

Vault : une suite de chiffre incompréhensibles qui utiisent 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. Ca peut être mis comme une variable.

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 gitattribute qu'on défini 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).

On continue le travail effectué lors du précédent Neutriton. Les playbooks se trouvent sur notre dépôt Git : https://git.domainepublic.net/Neutrinet/infra

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.

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.

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

  1. > localhost:5005 si /isp.json
  2. > 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 /neutrinetynhapps.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 :

• www.hackeragenda.be → hackeragenda.be
• hackeragenda.urlab.be → hackeragenda.be
• hackeragenda.be → localhost:5013
• www.hackeragenda.fr → hackeragenda.fr
• hackeragenda.fr → localhost:50132
• vg.hackeragenda.be → localhost:50133

TODO: 404 pour ffdnapi.neutrinet.be

• Retirer la partie SSL pour Nginx (meta, web et vpn)
  • Supprimer renew cert
  • Vérifier les cron jobs

TODO: Vérifier hackeragenda :

snippet.bash

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

• Changer le pfsense pour pointer vers haproxy
• Vérifier 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

Prochain Neutriton : 04/07 à 14h

Sujet : Monitoring

Lieu : Jitsi et/ou Caldarium ?

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.