| Prochaine révision | Révision précédente |
| the_red_unicorn:cluster_one [2023-01-16 16:46] – Déplacement de page Edouard | the_red_unicorn:cluster_one [2023-01-25 22:01] (Version actuelle) – [Feuille de route] Edouard |
|---|
| [[fichier_division_bell.png|200px|vignette|droite|Couverture de l'album //The Division Bell// d'où est extrait //Cluster One// - © Pink Floyd]] | {{:fichier:division_bell.png?300|Couverture de l'album "The Division Bell" d'où est extrait "Cluster One" - © Pink Floyd}} |
| //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. | //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. |
| |
| |
| |
| [[fichier_docker_container_engine_logo.png|alt=Logo Docker|vignette|Logo Docker]] | fichier_docker_container_engine_logo.png|alt=Logo Docker|vignette|Logo Docker |
| |
| [[https://www.docker.com/|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/)) | [[https://www.docker.com/|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é. | 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''//)) | 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 ===== |
| |
| [[fichier_kubernetes_logo.svg|alt=Logo Kubernetes|vignette|Logo Kubernetes]] | fichier_kubernetes_logo.svg|alt=Logo Kubernetes|vignette|Logo Kubernetes |
| [[https://kubernetes.io/fr/|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)) | [[https://kubernetes.io/fr/|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 [[the_red_unicorn_cluster_one|//ClusterOne//]]. En revanche, on peut y voir une utilité concernant la version suivante [[the_red_unicorn_two_of_us|//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. | 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 [[the_red_unicorn:cluster_one|ClusterOne]]. En revanche, on peut y voir une utilité concernant la version suivante [[the_red_unicorn:two_of_us|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. |
| |
| |
| 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. | 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 (et celle d'[[hello_community]]), ce qui constitue un caractère rédhibitoire au bénéfice des utilisateurs. | 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 ===== |
| |
| [[fichier_linux_containers_logo.png|alt=Logo Linux Containers|vignette|200x200px|Logo Linux Containers]] | fichier_linux_containers_logo.png|alt=Logo Linux Containers|vignette|200x200px|Logo Linux Containers |
| 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 [[the_red_unicorn_two_of_us|//TwoOfUs//]]. | 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 [[the_red_unicorn:two_of_us|TwoOfUs]]. |
| |
| |
| ===== Docker ===== | ===== Docker ===== |
| |
| Malgré l'inconnu que représente le passage à la version ultérieure //[[the_red_unicorn_two_of_us|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. | Malgré l'inconnu que représente le passage à la version ultérieure [[the_red_unicorn:two_of_us|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. |
| |
| |
| ====== Feuille de route ====== | ====== Feuille de route ====== |
| |
| La clé de voûte de cette version étant la conteneurisation, son point de départ est la maintenance [[maintenance_19-062|19-062]]. | La clé de voûte de cette version étant la conteneurisation, son point de départ est la maintenance [[maintenance:19-062|19-062]]. |
| |
| |
| |
| |
| |
| ====== Notes et références ====== | |
| |
| {{Références}} | |
