20 mai 2021 - Le collectif IndieHosters

Cela faisait un petit moment que l’envie de vous écrire des articles orientés technique nous titillait, commençons donc par le choix technologique au coeur de l’infrastructure de Liiibre : Kubernetes.

Kubernetes est une technologie, sous licence Apache 2, qui émane de Google et RedHat. Originellement taillée pour répondre aux besoins de rationalisation de leur infrastructure d’hébergement, elle est en passe de devenir un standard à travers le monde du cloud.

Nous allons ici tenter d’expliquer en quoi elle constitue à ce jour une excellente option à nos yeux pour vous offrir une grande qualité de service et in fine se libérer des GAFAM (intéressant retournement de situation, n’est-ce pas ? :)).

Adapté pour proposer un hébergement professionnel

Grâce à votre soutien grandissant, les demandes continuent d’affluer et il ne se passe pas une semaine de notre côté sans rencontrer des personnes en quête d’outils libres pour leur organisation.

Cette encourageante évolution pour le commun que nous tentons de faire émerger ensemble entraîne néanmoins certaines adaptations. Nous devons ainsi faire des choix technologiques adéquats tout en conservant une infrastructure solide et optimisée en cohérence avec nos engagements de pérennité de la ressource que nous mettons à disposition.

Dans ce contexte là, Kubernetes entre en jeu notamment pour réduire notre stress, gagner du temps que l’on peut passer à l’écoute des contributeur.trice.s et héberger suivant les principes de la haute disponibilité.

Kubernetes et son api, un standard en devenir

L’histoire de l’informatique a déjà pris le tournant du cloud depuis plus d’une décennie. Pour mettre un peu les choses en perspective, les premiers services S3 et EC2 proposés par Amazon AWS datent de 2006 (15ans!) et l’an dernier la même entreprise engrangeait 46 milliards de chiffre d’affaire. source

Et dans cet univers du cloud où l’on constate l’adoption de l’API de Kubernetes par des acteurs de toutes tailles allant de Mattermost à SAP en passant par Zalando, on peut raisonnablement avancer l’idée que Kubernetes est en passe de devenir un standard d’API Cloud. Et parallèlement, les images de conteneurs deviennent les artéfacts standards de déploiement.

Haute-disponibilité et résilience par défaut

En tant qu’administrateur.trice système, le problème à résoudre (décrit crûment) est de faire tourner des binaires. La voie traditionnelle est de demander à son init system de son UNIX favoris de s’en charger. On pourrait presque dire que l’API Kubernetes permet de faire la même chose.

Sauf que, la subtilité dans le monde des clusters Kubernetes réside dans le fait que l’orchestrateur va aussi vérifier la santé du service associé au binaire et lorsque le service ou la machine hôte présente un dysfonctionnement, l’orchestrateur se charge de trouver une autre machine pour relancer ce binaire. Et si on respecte les 12 facteurs, il est aussi possible de demander à l’orchestrateur de gérer plusieurs replicas de ce binaires, ce qui a pour effet de réduire drastiquement la fenêtre de maintenance non planifiée.

Un autre aspect intéressant réside dans le fait que lorsqu’on déploie un Rocketchat, un Nextcloud ou autre il n’est plus vraiment nécessaire de savoir si c’est du nodejs ou du php. Cette abstration permet de manipuler avec plus de souplesse différentes versions de la même application ou alors de déployer suivant le même modèle des serveurs d’application, des serveurs web ou de base de données.

Des applications libres pour tous.tes

On comprend mieux en quoi ces atouts, entres autres, participent ainsi à permettre à de plus en plus d’acteurs de toutes tailles comme Greenhost, Fairkom et des CHATONS comme nous, de proposer des outils libres dotés d’une haute qualité de service, de garanties en terme de sauvegarde et ce au plus grand monde.

Et ça, c’est très encourageant pour remettre la technologie dans les mains des citoyen.nes et soutenir l’internet (re)décentralisé que nous souhaitons voir advenir et auquel nous participons ensemble.

Mais alors, pourquoi tout le monde ne s’y est pas encore mis ?

Un technologie complexe à mettre en oeuvre…

Comme toute technologie, Kubernetes comporte des limitations, la plus grande étant sa complexité comme l’a récemment reconnu Google.

Bien que Kubernetes facilite le travail d’hébergement de son utilisateur.trice, l’important niveau d’abstraction qui l’accompagne peut vite lui donner un aspect “boîte noire”. Cela a notamment pour effet de complexifier le travail de debug lors d’incidents.

C’est pourquoi de nombreux fournisseurs de solutions cloud proposent des offres “as a Service” permettant ainsi d’éviter d’avoir à architecturer sa propre infrastructure. Et même dans ce cas, la courbe d’apprentissage reste non négligeable pour qui souhaite manipuler avec aise l’API Kubernetes. Bref, déployer un simple serveur nginx peut devenir une tâche fastidueuse :).

… et potentiellement plus gourmande en ressources

Un autre aspect qu’il convient d’aborder réside du côté du caractère assez gourmand en ressources lié à l’approche haute-disponibilité de Kubernetes. En effet la meilleure qualité de service et la réduction du temps d’indisponibilité sont liés en bonne partie à la réplication des containeurs.

Plus concrètement, si dans le cas de IndieHosters qui doit gérer une demande croissante d’outils à destinations d’usages professionnels nous voyons que Kubernetes est approprié, cela ne constitue pas nécessairement une règle générale.

Prenons le cas d’une solution de cloud pour partager vos photos de famille par exemple. Si vous ne craigniez pas de subir quelques indisponibilités ou une réactivité un peu plus capricieuse de temps en temps, un bon raspberry pi à la maison opéré avec la distribution des copain.ine.s de chez Yunohost puis un Nextcloud installé peut tout à fait convenir. Branchez-y de temps en temps un disque dur pour effectuer une sauvegarde à froid et ne l’allumez qu’en journée et vous aurez une installation dont l’impact écologique sera potentiellement moindre comparé à un cluster répliqué sur plusieurs machines virtuelles dans un datacenter.

Pour ce qui est de notre cas, il est encore difficile de dire si ce choix technologique va a l’encontre de nos engagements en terme d’écologie. Car s’il est vrai qu’elle pousse à la réplication des ressources, elle facilite aussi grandement leur optimisation.

Pour l’affirmer plus précisément et mieux agir, nous avons besoin de quantifier cet impact car « On ne peut améliorer que ce que l’on sait mesurer » (dixit Kelvin). Nous avons ainsi initié dernièrement un projet d’analyse de cycle de vie de nos services avec la participation de très chouettes personnes spécialisées dans ce domaine. Nous prévoyons de vous les présenter et vous en dire plus dans un article accompagné de chiffres concrets tout prochainement :)

Contribuer au mouvement

Il s’agit donc dans un premier temps de parvenir à réduire cette complexité. Et en s’y mettant ensemble, nous croyons que l’on peut contribuer à favoriser le mouvement des CHATONS et plus largement des personnes engagées pour un internet (re)décentralisé.

Cette démarche nous tient à coeur depuis le début de l’aventure IndieHosters. Comment mutualiser la partie opérationnelle des logiciels libres ? Comment héberger en haute dispo avec des sauvegardes et des restaurations ? Comment mutualiser ce savoir-faire sous forme de code en plus de la documentation déjà bien fournie sur le sujet ?

Nous contribuons à l’écosysteme docker, et dernièrement nous souhaitons relancer cette initiative sur Kubernetes. Ce projet s’appelle k8s.libre.sh, il est pour l’instant embryonaire, mais si vous voulez nous rejoindre pour développer cette aventure ensemble, parlons-en sur notre chat!

Dans notre prochain article technique, nous vous présenterons l’opérateur Kubernetes que nous avons développé pour la solution de visioconférence Jitsi à l’occasion de leur dernier hackaton. (spoiler, nous avons fini 5ième ! 🍾)