A l’ère des applications distribuées, l’étape du déploiement est devenu un véritable cauchemar pour les équipes projets. Entre les différentes briques utilisant un stack technique spécifique (framework, dépendances, os, …), et les environnements hétérogènes, la mise en production est une étape semée d’embuches.
Mon stack frontend basé sur Node.js dernière version sera t’il compatible avec la plateforme cloud cible ? Mon API REST sous ASP.NET Core 3.1 pourra être hébergée sur le cluster interne ? La communication entre mes différentes briques utilisent des ports autorisés par les policies de l’entreprise ? Autant de questions que le développeur se pose la plupart du temps… à la fin de son développement. Le résultat ? Dans le meilleur des cas, quelques modifications seront à apporter. Dans le pire des cas, une refonte du socle technique est à prévoir.
Il existe bien évidement les machines virtuelles qui permettent de déployer à la demande des systèmes pré-configurés rapidement, mais côté préservation des ressources (CPU, RAM, …) ce n’est pas optimal. La solution serait donc de supprimer l’OS guest d’une VM, consommateur de ressources, tout en conservant la flexibilité des VMs (Scalabilité, maintenance, etc.), mais aussi d’assurer une meilleur portabilité des applications (migrations de versions d’OS) et simplifier les déploiements. La solution à toutes ces problématiques existe, la gestion des applications en tant que container.
Un container est un package qui contient un exécutable, ses dépendances, sa configuration, eventuellement un systeme de fichiers. Les ressources d’un container sont isolées, aucun accés exterieur n’est possible si non spécifiquement décrit (accés fichiers, ouverture de ports, …). Pour le système d’exploitation, c’est un “processus” ! Plus de Guest OS, les ressources utilisées sont celles de la machine, et non d’une VM.
Dès lors, les problématiques citées plus haut n’existent plus. En effet, à partir du moment ou le container à été validé fonctionnellement et techniquement, il peut être déployé sur n’importe quelle plateforme, pour peu qu’elle soit compatible avec les gestionnaire de containers choisi (que le gestionnaire soit installé et fonctionnel). Chaque brique sera donc encapsulée dans son propre container et déployable à la demande.
Dans ce contexte, les architectures microservices prennent tout leur sens, avec un déploiement de 1 à x instances de chacune des briques applicatives sur l’infrastructure cible (quelque soit le serveur). Terminé les déploiements monolithiques, chaque service est indépendant et peut-etre mis à jour à la demande. Le release management devient “simple” et dans l’ère DevOps. Chaque nouvelle fonctionnalité pouvant être déployée plus rapidement (et individuellement) pour répondre au plus tôt aux demandes utilisateurs.
Un container étant un système normalisé et intermodal, il permet une séparation des responsabilités entre les Devs et les Ops. En effet, les développeurs ont la charge du bon fonctionnement de l'application encapsulée dans le container, tandis que les administrateurs système sont en charge de la bonne exécution du container sur l'infrastructure.
Une des solutions les plus connues est bien évidement Docker, solution intégrée de gestion de containers imaginée par Solomon Hykes, dont la première version est sortie en 2013. Le nom Docker est issu de l’idée même du concept, à savoir encapsuler toutes les ressources nécessaires dans un container normalisé et compatible avec le host. Le transport de marchandise transposé à l’informatique.
Docker est un véritable écosystème :
Docker Daemon est installé sur la machine hôte et gère les containers
Docker Client se charge de la communication entre l’utilisateur et le Docker Daemon
Docker Image est un Template de container qui décrit comment le construire
Docker Container est… un container
Docker Hub est un annuaire centralisé d’images
Docker File est un fichier décrivant couche par couche la construction d’une image
Docker Swarm est une solution d’administration d’un cluster d’hôtes Docker
Docker Registry est une solution de stockage/distribution d’images Docker. (Docker Volume, Docker Network, Docker Compose, …)
Sans entrer plus en détails dans la mise en oeuvre d’une application containérisée Docker (ce sera l’objet de prochains articles), nous pouvons faire un rapide tour d’horizon sur le contenu d’une image Docker. Comme nous pouvons le voir sur la représentation ci-dessous, la structuration de celle-ci est faite en couches. Chacune d’elle apporte un élément qui est nécessaire au bon fonctionnement de votre application (système d’exploitation, application serveur, …).
Mieux encore, chacune de ces couches dispose d’un id unique. Grâce à cet id, votre daemon Docker est capable d’identifier les images qui contiennent des couches communes et ne stockera donc physiquement qu’une seule version de cette couche. Le gain en espace disque est non négligeable, en particulier si vous disposez de votre propre registry privé et que chacune de vos applications est stockée sur un grand nombre de version. Dans la pratique, si votre application ne subit pas de changements profond (sous-entendu, pas de dépendance supplémentaire), seule la couche la plus haute (les binaires ou le code source de votre application) fera l’objet d’un stockage supplémentaire lors de la publication d’une nouvelle version.
Pour conclure, nous avons pu voir que l’utilisation des containers apporte un certain nombre d’avantages dans le développement de nos applications moderne. Outre l’aspect financier certain (par la préservation des ressources systèmes existantes), elle permet également d’améliorer la qualité de la chaine de production, terminé les déploiements en production qui ne fonctionnent pas pour des causes diverses et variées (problème de dépendance, …).
A l’ère des applications distribuées, l’étape du déploiement est devenu un véritable cauchemar pour les équipes projets. Entre les différentes briques utilisant un stack technique spécifique (framework, dépendances, os, …), et les environnements hétérogènes, la mise en production est une étape semée d’embuches.
Mon stack frontend basé sur Node.js dernière version sera t’il compatible avec la plateforme cloud cible ? Mon API REST sous ASP.NET Core 3.1 pourra être hébergée sur le cluster interne ? La communication entre mes différentes briques utilisent des ports autorisés par les policies de l’entreprise ? Autant de questions que le développeur se pose la plupart du temps… à la fin de son développement. Le résultat ? Dans le meilleur des cas, quelques modifications seront à apporter. Dans le pire des cas, une refonte du socle technique est à prévoir.
Il existe bien évidement les machines virtuelles qui permettent de déployer à la demande des systèmes pré-configurés rapidement, mais côté préservation des ressources (CPU, RAM, …) ce n’est pas optimal. La solution serait donc de supprimer l’OS guest d’une VM, consommateur de ressources, tout en conservant la flexibilité des VMs (Scalabilité, maintenance, etc.), mais aussi d’assurer une meilleur portabilité des applications (migrations de versions d’OS) et simplifier les déploiements. La solution à toutes ces problématiques existe, la gestion des applications en tant que container.
Un container est un package qui contient un exécutable, ses dépendances, sa configuration, eventuellement un systeme de fichiers. Les ressources d’un container sont isolées, aucun accés exterieur n’est possible si non spécifiquement décrit (accés fichiers, ouverture de ports, …). Pour le système d’exploitation, c’est un “processus” ! Plus de Guest OS, les ressources utilisées sont celles de la machine, et non d’une VM.
Dès lors, les problématiques citées plus haut n’existent plus. En effet, à partir du moment ou le container à été validé fonctionnellement et techniquement, il peut être déployé sur n’importe quelle plateforme, pour peu qu’elle soit compatible avec les gestionnaire de containers choisi (que le gestionnaire soit installé et fonctionnel). Chaque brique sera donc encapsulée dans son propre container et déployable à la demande.
Dans ce contexte, les architectures microservices prennent tout leur sens, avec un déploiement de 1 à x instances de chacune des briques applicatives sur l’infrastructure cible (quelque soit le serveur). Terminé les déploiements monolithiques, chaque service est indépendant et peut-etre mis à jour à la demande. Le release management devient “simple” et dans l’ère DevOps. Chaque nouvelle fonctionnalité pouvant être déployée plus rapidement (et individuellement) pour répondre au plus tôt aux demandes utilisateurs.
Un container étant un système normalisé et intermodal, il permet une séparation des responsabilités entre les Devs et les Ops. En effet, les développeurs ont la charge du bon fonctionnement de l'application encapsulée dans le container, tandis que les administrateurs système sont en charge de la bonne exécution du container sur l'infrastructure.
Une des solutions les plus connues est bien évidement Docker, solution intégrée de gestion de containers imaginée par Solomon Hykes, dont la première version est sortie en 2013. Le nom Docker est issu de l’idée même du concept, à savoir encapsuler toutes les ressources nécessaires dans un container normalisé et compatible avec le host. Le transport de marchandise transposé à l’informatique.
Docker est un véritable écosystème :
Docker Daemon est installé sur la machine hôte et gère les containers
Docker Client se charge de la communication entre l’utilisateur et le Docker Daemon
Docker Image est un Template de container qui décrit comment le construire
Docker Container est… un container
Docker Hub est un annuaire centralisé d’images
Docker File est un fichier décrivant couche par couche la construction d’une image
Docker Swarm est une solution d’administration d’un cluster d’hôtes Docker
Docker Registry est une solution de stockage/distribution d’images Docker. (Docker Volume, Docker Network, Docker Compose, …)
Sans entrer plus en détails dans la mise en oeuvre d’une application containérisée Docker (ce sera l’objet de prochains articles), nous pouvons faire un rapide tour d’horizon sur le contenu d’une image Docker. Comme nous pouvons le voir sur la représentation ci-dessous, la structuration de celle-ci est faite en couches. Chacune d’elle apporte un élément qui est nécessaire au bon fonctionnement de votre application (système d’exploitation, application serveur, …).
Mieux encore, chacune de ces couches dispose d’un id unique. Grâce à cet id, votre daemon Docker est capable d’identifier les images qui contiennent des couches communes et ne stockera donc physiquement qu’une seule version de cette couche. Le gain en espace disque est non négligeable, en particulier si vous disposez de votre propre registry privé et que chacune de vos applications est stockée sur un grand nombre de version. Dans la pratique, si votre application ne subit pas de changements profond (sous-entendu, pas de dépendance supplémentaire), seule la couche la plus haute (les binaires ou le code source de votre application) fera l’objet d’un stockage supplémentaire lors de la publication d’une nouvelle version.
Pour conclure, nous avons pu voir que l’utilisation des containers apporte un certain nombre d’avantages dans le développement de nos applications moderne. Outre l’aspect financier certain (par la préservation des ressources systèmes existantes), elle permet également d’améliorer la qualité de la chaine de production, terminé les déploiements en production qui ne fonctionnent pas pour des causes diverses et variées (problème de dépendance, …).
Share Dialog
Share Dialog
Subscribe to Vincent CIBELLI
Subscribe to Vincent CIBELLI
<100 subscribers
<100 subscribers
No activity yet