Présences :
Escusé :
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é.
FIN: 17h-18h
Tharyrok a remplacé Prometheus par VictoriaMetrics.
Le playbook Ansible est à jour.
Un gros changement : avant on avait des Prometheus locaux dans chaque cluster et ça envoyait les metrics vers le prometheus sur la vm storage-01.
Avec VictoriaMetrics, chaque telegraf utilise le protocole influxdb pour envoyer ses metrics sur storage-01. On a dû tricher : certains labels ne sont plus présents par défaut (job, monitor, instance, …), et du coup il a fallu les rajouter dans la config telegraf. C'est juste pour la rétrocompatibilité, mais c'est pas tellement nécessaire.
Une variable hostname reprend le fqdn (au lieu de instance) et c'est avec celle-ci qu'on devrait faire par la suite, mais pour le moment on garde la rétrocompatibilité. Il faudra modifier les dashboards et les alertes pour ne pas avoir de problème quand on supprimera ces labels.
## Prometheus compatibility job = "telegraf-{{ ansible_fqdn | replace('.', '-') }}" instance = "{{ ansible_fqdn }}" monitor = "{{ ansible_fqdn }}"
Pour job, peut-être juste garder telegraf
pour faire la distinction avec d'autres jobs comme alertmanager
qui monitore directement Alertmanager sans passer par telegraf.
En termes de performances, c'est le jour et la nuit
Sur le graphe, le premier pic c'était Promscale, puis on repasse à Prometheus sans Promscale, et fin juin c'est lorsqu'on a mis en place VictoriaMetrics (le pic correspond à la migration des données vers VictoriaMetrics). En terme de stockage, on en a pour 100 ans avant de tout remplir, donc ça devrait aller.
Attention a la prochaine version (v1.79.0) ils ont changé le pattern des binaires du coup il faudra update le playbook.
Au niveau de l'utilisation, il y a deux urls intéressantes :
Dans grafana on peux voir les alertes configuré dans altermanager : https://grafana.neutrinet.be/alerting/list.
Atelier Keycloak du 2 juin s'est bien passé, mais il faut une suite.
Le compte-rendu: https://wiki.neutrinet.be/fr/rapports/2022/07-02
Tharyrok est en train de faire le playbook Ansible. Il en est à la partie tests en local (molecule).
Il faut aussi un playbook pour oauth2-proxy
L'idée serait de l'installer sur chaque VM qui en a besoin.
Caddy semble pouvoir faire de l'Oauth2, mais c'est un peu mystique. On dirait qu'il faut recompiler Caddy pour rajouter le plugin… Et puis on n'aura pas toujours l'occasion de pouvoir utiliser Caddy…
Pour le prochain atelier, on pense attendre d'avoir mis en place Keycloak, donc ce serait pas avant octobre. Comme ça on pourra se faire la main sur la config des clients, et donc s'entraîner un peu avant la suite.
Le NeutriCamp va sans doute influencer la config Keycloak, en fonction de comment on voit la cooptation dans un groupe / hub.
: Décider de la date après la prochaine réunion hub infra (ou dans 2 mois)…
: Créer le playbook Ansible pour Keycloak
: Créer le playbook Ansible pour oauth2-proxy
Tharyrok avance plus vite sur Netbox à son boulot qu'à Neutrinet, honte à lui !
L'outil va servir d'inventaire pour Ansible.
Il y a un chouette plugin, appelé ProxBox qui permet de le connecter à Proxmox et crée tous les éléments (les VMs) dans Netbox.
Coupler Netbox PowerDNS pour la gestion des reverse dns.
: Créer le playbook Ansible pour Netbox (dépend de Keycloak)
Pas d'avancée pour le moment. Il faut voir comment utiliser l'API dans Ansible pour provisionner les configurations BGP.
: Créer le playbook Ansible pour Peering Manager (dépend de Keycloak)
https://mitogen.networkgenomics.com/
Mitogen est un strategy plugin pour Ansible : https://mitogen.networkgenomics.com/ansible_detailed.html
Permet de multiplier par beaucoup trop la vitesse d'exécution d'Ansible.
Pour l'instant, on ne l'avait pas mis en place car pas compatible avec Ansible 2.9 et plus. Maintenant c'est compatible mais pas encore de paquet, il faut donc l'installer avec pip et prendre la branche main/master
Il faut mettre le chemin vers le plugin, ce qui est un peu embêtant puisque la version de Python se trouve dans le chemin:
[defaults] strategy_plugins = ./.env/lib/python3.10/site-packages/ansible_mitogen strategy = mitogen_linear
Mais on pourra aussi le mettre dans la conf de l'environnement de variable, ce qui permettra de l'activer ou non selon ce qu'on veut.
ANSIBLE_STRATEGY ANSIBLE_STRATEGY_PLUGIN
Pour l'installer :
pip install git+https://github.com/mitogen-hq/mitogen
Globalement, on gagne en rapidité, genre vraiment, quelque chose comme x10.
La v7.1 est sortie (c'est la nouvelle LTS), HgO va mettre à jour dans les prochains jours.
Il faut faire attention, il y a un gros warning quand on met à jour depuis < v7.0 https://docs.mattermost.com/install/self-managed-changelog.html#release-v7-1--extended-support-release
Vérifier que les playbooks Mattermost sont bien désactivés : https://docs.mattermost.com/guides/playbooks.html
À voir si les boards seront plus facilement déplaçable vers un autre channel, parce que pour l'instant c'est juste pas possible.
DONE: Agresser à nouveau le support pour avoir la licence sur 3 ans et pas 1 ans
: Mettre à jour Mattermost vers v7.1.2
: Créer le message de bienvenue
Comment qu'on fait ? C'est une bonne question…
HgO a mis au point un version tracker au boulot qui se base https://release-monitoring.org et qui va créer une issue dans Gitlab avec la nouvelle version de l'outil.
Tharyrok se cale un jour par mois pour faire les mises à jour des logiciels à son boulot en ce basant aussi sur https://release-monitoring.org.
Mises à jour des logiciels, mais il y a aussi la mise à jour des machines qui doit être faite, donc il faut de toute manière passer de temps en temps sur les machines.
Parallèlement, un outil qui fait hook apt :
https://github.com/liske/needrestart
Mais ça ne répond pas au problème initial
Dans un premier temps, on peut se réunir un jour pour vérifier si les outils qu'on utilise doivent être mis à jour (par ex Mattermost, Hedgedoc, etc.), et donc faire le boulot d'un version tracker. Et ensuite, appliquer ces màj.
: Créer un Neutriton sur la question
https://doc.neutrinet.be/hib-dc-2022-06-11# qui retrace nos péripécies \o/
En bref, c'était très épuisant, ça a même duré deux jours au lieu d'un…
Il n'est pas encore wikifié, il faudrait le remettre au propre. On avait aussi parlé d'en faire un article de blog…
Sur les deux serveur il y a un disque de 1To pour faire des backup local, qu'il faudrait chiffré.
On pourrait ne pas avoir assez de place sur nos espaces de stockage pour les backups car CEPH a beaucoup grossi (2To pour Ceph, mais nos disques de backups font 1 To). Pour l'instant, on consomme 537,18 Go, donc ça passe, mais après…
Mais il faut voir la pertinence de backuper les VM sur es disques locaux.
En attendant, Tharyrok a désactivé les backups en local, parce qu'ils n'étaient pas chiffrés.
Par contre, on a des VMs qui ne sont pas backupées sur le PBS, par exemple celle pfsense, edge, core, … bref toutes celles qui sont sur le storage local (sauf pfsense mais bon). Pourquoi ? Parce que si on utilisait PBS, on devrait interrompre la VM quelques instants ce qui fait perdre le reseau ce qui a comme conséquences la perte de lien avec le PBS et ça fait échouer le backup #oups
Donc c'est pertinent de garder ces disques de backups locaux, mais il faudrait les chiffrer et n'y backuper que les machines réseau (donc on ne s'inquiète plus de l'espace disque).
De toute manière, ces VMs seront aussi backupée via Borgmatic, sauf peut-être pfsense. Mais pour pfsense, il faudra exporter la config et la backuper.
: Faire l'article de blog
: Wikifié le pad
: Chiffré les disques de 1To de Backup
: Voir comment backuper les pfsense
Dans l'iLo on n'a juste un reset… Et c'est fait depuis le iLo, et sans login oO
On va bouger les machines réseau qui sont sur bour sur nam pour qu'il ait les machines master.
La persistence des logs est activée sur bour, mais à vérifier si c'est activé sur les autres VMs
: Ajouter dans ansible la persistance des logs systemd
Il faut réveiller spyou pour avoir un vlan au NL-IX et ensuite avoir du transit de SCANI
ping spyou From spyou icmp_seq=1 Destination Host Unreachable From spyou icmp_seq=2 Destination Host Unreachable From spyou icmp_seq=3 Destination Host Unreachable
DONE: Harceler spyou
C'est juste pour Tharyrok, il comprendra.
Dans un cas on va mettre une préférence sur une route, dans l'autre on va dire à quelle distance est cette route.
En gros c'est plus propre de le faire comme ça, et ça nous sera utile lorsqu'on aura notre lien de transit avec Scani.
Verixi a trouvé un moyen de router nos IP directement sur la collecte. Un POC sera fait demain \o/
Ca va nous éviter de devoir faire des tunnels dans tous les sens.
https://git.domainepublic.net/Neutrinet/matrix-alertbot
L'idée est d'avoir un bot matrix pour annoncer les alert de alertmanager. Nous en avons un mais il ne support pas l'acknowledge.
Il faut donc aller sur le serveur et lui dire de se taire. L'idée est donc d'avoir une commande pour lui dire “la ferme”
> Ma super alert !alert ack
Il y a l'idée de le faire avec des émojis. Thayrok demande aussi de pouvoir le silence via les réaction.
HgO est parti d'un template Nio. Nio est un framwork pour créer des bot matrix qui utilise aiosync. aiosync est en gros une librairie python qui permet de faire de l'asynchronisme.
Le bot va utiliser aiosync mais il faut aussi un serveur http qui recevra les alerte de altermanager pour publier sur matrix ensuite.
Il existe aiohttp comme server http.
On a un POC qui marche. Il faut voir les foncitonnalités qu'on veut avoir.
Les questions techniques :
- Combien de temps il faut silence ?
- Maintenance gérée via Grafana / VictoriaMetrics - Séparer les notifications pour avoir qu'une notification à la fois (ce qui permet de simplifier le code).
Idée de l'avoir en paralèlle avec l'autre bot matrix-goneb pendant un temps au cas où on a oublié de gérer une exception.
Décomission fin septembre.
HgO aurait besoin d'une VM pour migrer son Nextcloud : 2GB x 2 vCPU + 100Gb pour les données (note: ne pas partitionner le disque des données, pour pouvoir le resize facilement, à chaud)
Pour le moment, on fait les VMs à la main car l'ID est en deux partie, une partie fixe et une partie qui est aléatoire, mais pour le moment il faut le faire manuellement. Aussi pour l'IP qui doit avoir une partie aléatoire.
Même chose pour l'assigne des IP en plus il faut reconfig les serveur core-03 & core-04
On pourra modifier la config de la VM en allant dans Proxmox, il faudra juste ne pas toucher à la partie réseau (IP, VLan). Tharyrok est en train de faire un script pour gérer tout ça, mais il doit encore le terminer.
DONE: Créer le board pour les demandes de VM/Support
: Créer le haproxy pour accédeer au proxmox pour utilisateur normaux
Prochaine réunion hub infra : samedi 10/09/2022 à 14:00
Lieu : Jitsi & 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.