Open Source Experience 2021 – Récap’ du premier jour

Wed, 10 Nov 2021 08:00:00 +0000

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 hackshack.hpedev.io/workshops (lien mort)

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.

github.com/GoogleContainerTools/kaniko

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 (lien mort, pas dispo sur Internet Archive)

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

Configurer DataProtector pour l’envoi de rapports via SMTP

Sat, 11 Jul 2015 12:00:07 +0000

Une des fonctionnalités vitales d’un système de sauvegarde est sa capacité à présenter de manière claire et concise des informations sur l’état des sauvegardes et de l’utilisation de l’outil en général. Même si c’est peut être un peu « old school », j’ai croisé de nombreux contextes professionnels dans lesquels le « team leader » reçoit quotidiennement les alertes de la veille sur les sauvegardes, sous forme d’indicateurs simples (ce que DataProtector sait bien entendu faire).

Le reporting chez DataProtector

DataProtector propose cette fonctionnalité depuis des années via le menu sobrement nommé « rapports » du Manager. De la même manière que les spécifications de sauvegarde, les groupes de rapports peuvent être ordonnancés pour s’exécuter à horaire fixé ou bien lancés à la main.

Il existe un certain nombre de rapports fournissant ce que je qualifierai du minimum syndical en terme de reporting pour un outil de sauvegarde, et leur nombre et leurs fonctionnalités n’a guère évolué depuis la v6.x.

Ces rapports ainsi que les autres outils de reporting qu’a rajouté HP en périphérie pour enrichir la relative pauvreté des indicateurs existant feront peut être l’objet d’articles futurs.

Le vif du sujet, configurer un SMTP dans DP

Ici, je vous présenterai simplement comment configurer DP pour que les mails des rapports puissent arriver à bon port.

Depuis la v8 (il me semble), il est possible d’éditer les paramètres Globaux de DP directement depuis la GUI, au lieu de passer par le fichier « global » comme auparavant.

Cependant pour y arriver, le cheminement n’est pas forcément intuitif ;-). En effet, il faut ouvrir le menu « Base de données interne », puis aller dans « Option Globale ».

Sincèrement, je n’aurai pas cherché ce dossier dans « Base de données interne », sachant que c’est là où toutes les informations des sessions ainsi que le contenu des médias sont stockés (dans un base de données, justement).

Au contraire, les options globales sont définies « de tout temps » dans un fichier de configuration, à part. Mais bon …

Il faut quand même louer les efforts d’HP sur ce coup là. L’interface, bien que mal rangée, est assez intuitive. Les différents paramètres sont clairement classés par type, avec une description et une valeur par défaut annoncée.

Les valeurs à modifier sont donc Cell Manager : SMTPServer et Cell Manager : SMTPSenderAddress

A chaque modification, il faut cliquer sur « Save » qui passe la ligne en rouge pour indiquer qu’une modification est en cours.

Attention elle n’est cependant pas totalement prise en compte :-/ Il faut remonter tout en haut pour valider la sauvegarde une fois pour toute. Dommage HP ! Bel effort… mais ce n’est pas encore ça comme UI intuitive.

Un bandeau vert s’affiche pour nous demander de redémarrer les services de DP pour prise en compte (lesquels?).

Une fois que c’est fait, l’ensemble des rapports utilisera ces valeurs pour envoyer les rapports sous forme d’email.

SMTP on Zwindler's Reflection