ClusterOne
ClusterOne est la troisième version du projet TheRedUnicorn, lancée en 2019. Elle représente un tournant majeur dans le projet ainsi qu’un travail de maintenance et déploiement considérable. Ou plutôt de re-déploiement.
Nom de code
Cluster One est le premier titre de l’album The Division Bell de Pink Floyd. On retrouve dans ce nom le côté “cluster” de conteneurs que représente Docker. C’est le premier “cluster” du genre que connaît le projet depuis sa création. Le renouveau incarné par cette nouvelle version du projet, sur des bases plus stables et plus sécurisées, est bien représenté par ce titre et par cet album pour les plus connaisseurs.
Objectifs
Cette nouvelle version est basée sur un but premier qui est la conteneurisation des services TheRedUnicorn. Cela permet d’assurer en cas de panne, un re-déploiement rapide à partir des conteneurs sauvegardés. De plus, l’isolation des services permet d’augmenter la disponibilité au niveau applicatif avec des instances en failover.
Un autre objectif de cette version est d’améliorer la sécurité du système et l’ergonomie ainsi que la stabilité des applications. De nouveaux services seront aussi développés ou mis en ligne à ces fins. En effet, la consolidation de l’existant et sa sécurisation sont des éléments primordiaux pour la suite du projet et maintenir une haute disponibilité et une redondance avec la conteneurisation ne peut être viable sans un système stable et sécurisé.
Étude de faisabilité
Docker
Docker est actuellement sur le marché la solution gratuite et open source la plus utilisée et la plus en vogue de l’année 2018((Selon l’enquête auprès des développeurs StackOverflow 2019, https://insights.stackoverflow.com/survey/2019)). Il présente l’avantage d’être léger, flexible, portable et évolutif. En effet, les conteneurs((https://www.docker.com/resources/what-container)) peuvent partager le noyau de l’OS hôte tout en isolant chaque application. De plus, ces conteneurs peuvent être exportés et déployés n’importe où. Il est possible de modifier l’état du conteneur sans affecter son état en production avant de le redéployer ainsi modifié.((https://docs.docker.com/get-started/))
Dans notre cas, Docker représente une solution viable et intéressante. Le caractère portable permet d’assurer des sauvegardes et un redéploiement si besoin aisé et rapide. Les caractères léger et évolutif permettent l’installation d’une telle architecture sur un serveur ayant des ressources moyennes, contrairement à l’emploi de VMs avec hyperviseur par exemple. Enfin, la possibilité de faire des modifications sur les conteneurs en pré-intégration et donc n’affectant pas immédiatement la production est un atout indéniable et inattendu. Cela représente une possibilité de travail sur l’environnement de production en toute sérénité.
En revanche, Docker ne présente pas de technologie de partage de charge.((Dans le cas de Docker CE (Community Edition) contrairement à Docker EE (Entreprise Edition). Cette dernière version étant néanmoins payante et non adaptée au besoin. https://www.docker.com/products/kubernetes))
Kubernetes
Kubernetes est une technologie issue de Google puis offerte aux communautés publiques. C’est désormais un projet de la Fondation Linux.((https://fr.wikipedia.org/wiki/Kubernetes)) De plus en plus populaire, en particularité sur les systèmes Ubuntu (avec snap et le support Canonical), il permet de gérer des conteneurs sur une ou plusieurs machines physique ou bien virtuelles. C’est un système d’orchestration qui supporte le partage de charges, y compris à travers le réseau pour la communication entre nœuds distants.((https://ubuntu.com/kubernetes))
Kubernetes s’emploie généralement avec une technologie de conteneurisation telle que Docker. Dans l’immédiat, Kubernetes ne représente que peu d’intérêt concernant la phase ClusterOne. En revanche, on peut y voir une utilité concernant la version suivante TwoOfUs. En effet, cette version aura pour but de partager les charges entre deux serveurs, comprenant un failover en cas de dysfonctionnement. Ceci confirme l’intérêt pouvant être porté à une solution de conteneurisation telle que Docker dans un premier temps, dont Kubernetes pourra être complémentaire.
Solutions IaaS
IaaS((https://en.wikipedia.org/wiki/Infrastructure_as_a_service)), pour Infrastructure as a Service, est une offre de cloud computing basée sur la virtualisation. Un fournisseur d’IaaS comme Amazon EC2 (AWS) ou Google Compute Engine fournit des machines virtuelles ainsi que du stockage et de la virtualisation de réseaux administrés via des APIs ((https://www.bmc.com/blogs/saas-vs-paas-vs-iaas-whats-the-difference-and-how-to-choose/))((https://www.ibm.com/cloud/learn/iaas-paas-saas)). Cela offre une grande flexibilité, un prix s’adaptant au besoin ou à l’utilisation temps réel et une très haute disponibilité. Cette solution séduisante permettrait de migrer rapidement en s’affranchissant des problématiques systèmes et du maintien en condition opérationnel du système. De plus, aucune panne matérielle ne peut être subie.
Cependant, l’hébergement des services et des données peut se trouver n’importe où dans le monde. Il est parfois possible de restreindre la localisation dans une certaine partie du monde (West Europe par exemple) afin de bénéficier d’une certaine règlementation. De plus, l’infrastructure étant gérée par le fournisseur, on perd l’intérêt de l’administration système en étant presque réduit à de l’administration de services. On perd également la main sur les données.
Les solutions de type IaaS ne sont donc pas compatibles avec la philosophie du projet, ce qui constitue un caractère rédhibitoire au bénéfice des utilisateurs.
LXD
LXD est un gestionnaire de conteneurs Linux basé sur LXC.((https://linuxcontainers.org/lxd/introduction/)) On y retrouve des images incluant un large nombre de distributions Linux telles que Debian, Ubuntu, Arch, etc.((https://images.linuxcontainers.org/)) Cette solution présente de nombreux avantages en termes de sécurité, de mise à l’échelle et de facilité d’utilisation. Une API fournie par LXD permet de gérer localement comme à distance les ressources et les conteneurs. L’interface en ligne de commande est similaire à celle fournie par Docker.((https://linuxcontainers.org/lxd/getting-started-cli/))
À travers cette seule solution, on trouve alors la réalisation possible des deux prochaines versions – étroitement liées – du projet, à savoir la conteneurisation des services puis le partage de ressources à travers deux machines. On peut en effet gérer différents nœuds LXD à travers le réseau, chacun gérant ses conteneurs, par la création d’un cluster ((https://ubuntu.com/blog/lxd-clusters-a-primer)). LXD est donc un sérieux candidat dans la mesure où aucune autre installation ne sera requise lors du passage à la version TwoOfUs.
Choix techniques
Docker
Malgré l’inconnu que représente le passage à la version ultérieure TwoOfUs avec Docker, c’est bien cette solution qui a été retenue. En effet, après quelques essais lors de la phase de choix et de réflexion, LXD s’est avéré être une solution plus coûteuse en temps et réalisation. Seul, la tâche étant déjà importante en termes d’ampleur, l’avantage que représente Docker avec son API complète et ses images a pris le pas sur LXD. Docker devrait tout de même permettre le passage à la version supérieure sans la nécessité de changer l’infrastructure, via Docker Swarm((Docker Swarm est à étudier mais il semble jouer pleinement le rôle d’orchestrateur recherché https://docs.docker.com/engine/swarm/key-concepts/)) par exemple.
Architecture
Feuille de route
La clé de voûte de cette version étant la conteneurisation, son point de départ est la maintenance #19-062.