• Liste des sujets neutritons
• liste des pads
• Pad de la réunion

Présences :

• HgO
• Tharyrok
• Célo
• Liberfix

Jitsi : https://jitsi.belnet.be/neutriton

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

Fin vers 17h30

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

Par ordre plus ou moins chronologique:

• YOLO
• butterflies
• terminator
• pssh
• bash / python / c# / ruby / pascal / cobol / haskell / lisp
• git (pour synchroniser les fichiers de config)
• CFEngine (https://cfengine.com/)
• puppet (https://puppet.com/)
• saltstack (https://www.saltstack.com/)
• ansible (https://www.ansible.com/) (on a déjà des playbooks à nous : https://git.domainepublic.net/Neutrinet/infra)

Avec l'arrivée des outils de config management, on commence à avoir un trade-off entre le temps passé à configurer manuellement les serveurs et le temps passé à automatiser tout ça. Après il y a d'autres avantages, mais spoilers.

Un exemple : devoir mettre les clés SSH sur chaque machines, même quand il y en a 4-5, devoir configurer le header de connexion, etc. Ben c'est amusant au début, mais c'est vite pénible et répétitif.

On peut aussi plus facilement créer des environnements séparés et bien isolés. Dans l'environnement de tests, on fait nos changements, et quand tout est bon, on les passe en production. Et on est sûr que la production est toujours stable.

On va avoir aussi pouvoir mettre en place des tests, comme par exemple avec Molecule. Les tests vont permettre de décrire le comportement désiré. C'est test peuvent le faire sur une machine local, avec quemu ou virtualbox. C'est possible avec Docker mais cela n'a pas le même comportement qu'une vm. https://molecule.readthedocs.io/en/latest/

Certains outils de config management viennent avec leur propre langage (DSL https://en.wikipedia.org/wiki/Domain-specific_language), mais cela implique une courbe d'apprentissage assez longue. C'est le cas par exemple de Puppet ou CFEngine.

Ca n'est pas le cas avec Ansible. Ansible se base sur du Yaml, donc en connaissant le Yaml c'est bon. Il a des mots cles qui représente les modules. La structure du fichier est aussi importante. Il ne faut plus apprendre de langage, juste savoir quels modules utiliser et comment utiliser la structure.

Dans Salt, la structure des fichiers n'a pas d'importance. En fait, la structure doit être apportée par les personnes qui utilisent l'outil, ce qui demande pas mal d'organisation au sein de l'équipe. Ansible impose déjà une forme d'organisation, mais reste quand même assez flexible dans la mesure où il permet de faire la même chose de différentes manières.

Par contre, puppet est très rigide. L'inconvénient est qu'il y a énormément de fonctionnalités qui ne sont pas présentes dans la version open source, et la version pro coûte deux bras.

Une autre différence entre ces outils, c'est la manière dont sont appliquées les configs. Dans le cas de puppet et salt, on va avoir un agent qui va être installé sur les machines à configurer, et un serveur principal qui va orchestrer les agents.

À l'inverse, Ansible, mais salt aussi a ce mode, va se connecter en ssh pour installer la configuration. Il n'y a pas de serveur centralisé (agentless).

Le fait d'avoir des agents (et donc un serveur central) permet de contacter une API pour piloter les agents.

Ansible n'a pas besoin que Ansible soit installé sur les serveurs à configurer, puisqu'il se connecte en ssh pour effectuer ses commandes. Il faut juste que python soit installé, ainsi que divers modules python (et dans tous les cas, il retourne une erreur quand il manque des librairies). Salt a le même comportement en mode ssh.

AWX (https://github.com/ansible/awx) (la version payante c'est Ansible Tower) c'est un outil qui permet d'avoir un serveur principal avec une interface web. Cette interface permet de configurer des template et lancer des playbook sur ou un groupe de serveur, de maniere automatique ou en declanchement manuelle. C'est intéressant pour automatiser le deployement automatique. Typiquement avec gitlab ou peut créer un pipeline et déclencher un jobs via AWX. Pas forcément intéressant pour une petite structure comme Neutrinet mais intéressant de savoir que ça existe.

Pour le petit equipe IT c'est compliquer de suivre les changements appliqué par RedHat.

Nous avons un repos de playbook : https://git.domainepublic.net/Neutrinet/infra

L'état actuellement est vieux et on ne la plus run depuis longtemps sur les serveurs. Mais du travail a été fait récemment par HgO pour actualiser certaine choses.

Il y a donc eu un travail là-dessus. Pour se décider à changer, il faudrait des arguments solides. Une politique actuelle de Red Hat pourrait être une raison : ils retirent un certian nombre de modules qui sont gérés par la communauté. Ceux-ci ne sont plus installés directement lorsqu'on installe Ansible. Aussi, il y a la possibilité de télécharger certains playbook mais qui ne soit pas toujours bien écrit, souvent trop généraux ou prenant en compte trop d'exceptions. Mais cette collection de module est aussi plus simple. RedHat a aussi l'habitude de changer des choses sans trop se préoccuper de la rétro-compatibilité.

Le choix d'un config management est assez crucial, parce qu'on va passer énormément de temps à le configurer pour nos besoins. C'est donc difficile de revenir en arrière ou d'en changer plus tard.

Malgré tout, Ansible possède une courbe d'apprentissage vraiment faible. En effet, Ansible se base sur du YAML, qui est un langage assez descriptif. On peut très vite détecter ses erreurs. Et les modules sont suffisamment bien documentés écrits pour ne pas devoir chercher 30min avant de trouver comment l'utiliser. Dans la doc, chaque module est accompagné d'exemples.

À l'inverse, avec Salt on passe beaucoup de temps de test essais-erreur retest car tout n'est pas clair dans la config et parfois on se retrouve dans le code source pour connaitre les arguments des modules. Aussi quand il y a une erreur, c'est pas évident de comprendre la raison.

Sans agent ou serveur principal il est difficile de garder une configuration ISO. Un environement ISO est un environement ou si on run l'outil de config management les modifications sont faites en quick fix (donc d'abord l'avoir mis dans un playbook).

AWX a comme désavantage a sa propre version d'ansible que l'on peut pas choisir et donc avoir des comportements étranges. Un autre point c'est récemment ils ont refait l'interface de AWX avec comme warning ne pas installer la toute dernière version car il manquait encore des fonctionnalités.

Utiliser quand même Ansible mais en gardant à l'esprit qu'il va être nécessaire de suivre ce que fait Red Hat.

Un Workshop sur Ansible (après le pfsense NAT) quand il fera plus chaud

Prochain Neutriton : 23/01/2021 @ 14H Lieu : https://jitsi.belnet.be/neutriton

TODO: voir avec nino si cela lui convient, s'il veut faire un petit input pour les reverseproxy, et si la fréquence des Neutriton lui convient ou si on doit ralentir

loadbalancing (si necessaire)? Une alternative à ha-proxy (gpl2) pourrait être https://envoyproxy.io (apache) (cf. nino)

• apache mod_proxy
• nginx
• traefik
• caddy2

• patroni
• autres?

• minio
• ceph

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.