Première conférence en présentiel de 2021 !
Ca fait quelque chose…
Revenir… IRL… dans une conférence !
Et quelle conférence ! Pour la première fois, je participais à l’Open Source Experience (que vous connaissez peut être sous son ancien nom, le Paris Open Source Summit, voire Solution Linux pour les plus vieux 😉).
Ca se passait au palais des congrès de Paris, porte Maillot, et je vous avais déjà dit que j’étais (en plus !) speaker.
L’occasion de voir des conférences, mais aussi de rencontrer pas mal de gens, que je “connaissais d’Internet” ou pas du tout.
API != REST – procmail à la rescousse
Dans un talk vraiment détendu, Bruno CORNEC et Frédéric PASSERON nous ont présenté la façon dont était câblé l’API de la plateforme de Workshops on Demand sur le site https://hackshack.hpedev.io/workshops
L’idée était que, pour les besoins de leur outil de Workshops on demand, l’utilisation d’une API de type REST était totalement surdimensionnée et que le SMTP (certes protocole vénérable) dispose by design d’un traitement de message par file / asynchrone.
Une façon fun de montrer, selon eux, que ce n’est pas parce qu’une technologie n’est pas récente et/ou à la mode qu’elle n’est pas fonctionnelle.
Les environnements sont ensuite provisionnés avec un mélange de scripts bash mais surtout d’Ansible et je ne peux donc qu’approuver leur travail 😉.
Ciel mon Kubernetes mine des bitcoins
Bon, je ne vais pas vous refaire le match, c’était ma conférence et si vous souhaitez relire les slides, elles sont disponibles ici ;-)
Construction d’images de containers à l’aide de Kaniko
Yannig PERRE nous a présenté l’outil Kaniko, poussé par GoogleContainerTools, qui permet de construire des images de container Docker sans Docker.
Le talk commence sur un constat : si l’écosystème Kubernetes repose très majoritairement sur l’utilisation d’image de container Docker pour exécuter les runtime, Docker, lui, est de moins en moins disponible sur les serveurs Kubernetes eux même (débrayable depuis 2016 et le CRI, officiellement déprécié en 1.20).
Kaniko est donc un container qui va nous servir à construire des images docker, qu’on poussera ensuite sur notre registry, le tout sans démon/binaire Docker.
Grosso modo, le fonctionnement de base n’est que peu changé, avec le support de l’API v2 et des multistage build. Seuls petits bémols, de par sa conception Kaniko est un container qui nécessite d’être lancé avec root (mais sans privilèges particuliers) et Kaniko ne permet pas de builder une image sans la push.
Kaniko nécessite également de réfléchir un peu à la façon dont vous allez gérer vos caches pour la constructions des images. Au delà de ces points d’attention, l’outil semble assez mature.
Construire un outil de CLI userfriendly
Nicolas LEPAGE a commencé ce talk par une anecdote qui m’a bien fait sourire : il a raconté qu’un jour, on lui a dit que pour rechercher des informations sur un processus, on lui avait dit de faire un ps aux et qu’il n’avait pas pendant des années, cherché à savoir à quoi correspondaient “aux”.
Le fait qu’on connaisse tous cette commande, sans pour autant tous être au courant du rôle de chaque “flag” est assez évocateur de l’UX parfois discutable de certaines commandes UNIX.
Nicolas a donc profité de ce talk pour faire un tour des bonnes pratiques et conventions pour que les utilisateurs de vos futures CLI ne mangent pas leur chapeau. Je vous en donne quelques unes pelle mêle :
- Avoir des options longues (débutant par --, avec des mots séparés par un tiret)
- éventuellement des options courtes (1 tiret 1 lettre, éventuellement groupable avec d’autres lettres)
- Des options usuelles qu’on s’attend à trouver (ex. –help, –version)
- Une convention différente pour les commandes et les options
- éventuellement des groupes de commandes voire des hiérarchies de “groupes + sous groupes” de commandes
Nicolas nous a rappelé qu’il ne fallait pas oublier qu’une CLI a parfois vocation à être lancée dans un script ou par un processus (ajouter des options avec des valeurs par défaut qu’on peut surcharger si besoin, par exemple pour celles nécessitant un terminal), permettre d’ajouter de la configuration.
Les slides sont disponibles ici
Infrastructure As Code : quelles tendances ? De l’automatisation à l’orchestration multicloud !
Comme le titre du talk de Pierre VILLARD le laisse penser, c’était un état de l’art de l’automatisation et de l’orchestration.
Après un rapide tour d’horizon des différents types d’outils qui existent (Génération de template / Orchestration / Gestion de configuration), Pierre nous a donné quelques exemples des outils les plus connus, avec des alternatives.
Pour la partie templating, on peut citer Packer, buildpacks.io et Kaniko, chacun avec leurs usages et leurs faiblesses.
Si tous les grands providers de cloud disposent de leur propre manière de déployer des ressources, quand on fait du multi-cloud, Pulumi est une alternative intéressante.
Gestion de configuration pure, Ansible reste sans conteste l’outil le plus populaire.
Pierre nous a également parlé d’une dernière catégorie d’outils : le Policy as code. Ces outils nous permettent de vérifier que le code IaC qui est produit est conforme aux politiques de sécurité et de conformité de l’entreprise. Dans cette catégorie, on peut citer évidemment Open Policy Agent et Kyverno, deux outils de la CNCF.
Exposants, visiteurs et village associatif
Au delà des conférences, cet événement était l’occasion rêvée de rencontrer des gens qu’on avait pas pu voir “en vrai” depuis quasiment 2 ans.
J’ai eu une discussion passionnante avec les business model des entreprises éditant des logiciels open sources avec Ludovic DUBOST de XWiki et Cryptpad.
J’ai également pu parler avec l’équipe de développement de XCP-NG, une alternative libre à XenServer (lui même basé sur Xen) assez prometteuse. La communauté est assez active, a ajouté le support de terraform et travaille pour écrire une API pour piloter XCP-NG avec Kubernetes (de la même manière qu’on peut le faire avec kubevirt).
J’ai assisté à une présentation de la dernière beta de Rudder que je ne connaissais pas du tout (au delà du nom). Même si le produit ne s’adresse pas prioritairement à des admins systèmes
J’ai eu une discussion passionnante avec les gens de Centreon sur le monitoring et l’observabilité en général. On a aussi beaucoup parlé de haute disponibilité des brokers/pollers 😏.
J’ai également pas mal discuté Genma, AtaxyaNetwork (& une partie de la team Aquaray), Rémi VERCHERE, Nicolas LEPAGE, la team de LinuxFR.
De très belles rencontres :).