Voyage au pays des Containers

Voyage au pays des Containers : embarquement

Intéressons-nous dans un premier temps aux concepts, paradigme et principaux composants des Containers. Antonin D’Enfert, Consultant Infrastructure et Cloud chez Avanade France, nous éclaire sur le sujet et partage son expertise. Un voyage qui mérite toute votre attention.

Containers : Un peu de perspective 

En prenant un peu de recul sur l’évolution du Datacenter, on peut identifier des moments clés où un ensemble d’avancées technologiques ont créé, ou au moins accompagné, un point d’inflexion de cette évolution.

Si l’on considère que le Mainframe représente l’antiquité, l’âge du « tout centralisé », alors l’apparition du couple ordinateur personnel (PC) et serveur représente l’ère moderne, celle d’un modèle de ressources distribuées mais toujours limitées par l’adhérence entre physique et logique impliquant des lourdeurs de déploiement, de gestion de la disponibilité et de la « scalabilité » mais aussi une quasi absence d’optimisation des ressources.

Bien que nous vivions encore partiellement dans ce modèle, la révolution industrielle l’a beaucoup fait évoluer grâce à la virtualisation sous diverses formes : virtualisation de machine, de réseau, de stockage, d’application… Cette révolution a permis de s’affranchir des adhérences diverses entre matériel et logiciel particulièrement grâce à la virtualisation de machine pour distribuer, redonder, migrer et surtout optimiser les ressources de la couche physique en densifiant et consolidant la couche logique. C’est l’âge de la flexibilité, de l’automatisation et de l’orchestration.

Sur les bases solides et matures de cette révolution industrielle, émerge depuis quelques années une nouvelle ère, celle des services IAAS, PAAS et SAAS offerts par le cloud privé ou public. C’est l’avènement de l’abstraction et de la transparence.

Une histoire de conjoncture 

Que l’on soit IT pro ou à fortiori développeur, « Windowsien » ou « linuxien », difficile d’éviter le sujet des Containers depuis ces deux dernières années. Pourquoi ce succès fulgurant ?

Les Containers ne sont en réalité pas nouveaux. Il en existe diverses implémentations dans l’univers Unix/Linux depuis les années 80, Chroot sur Unix (1982), Jail sur BSD (2000), Containers sur Solaris (2004), LXC sur Linux (2008) pour n’en citer que quelques-unes. Leur succès soudain peut s’expliquer par la convergence de plusieurs facteurs, d’une part l’apparition de mouvements, de pratiques et de concepts tel que le DevOps, le « Continuous Integration/delivery », l’Infrastructure as Code… qui s’inscrivent dans cette ère du service et d’autre part l’émergence d’une compagnie, Docker Inc. qui a développé un logiciel éponyme afin d’amener les Containers à un niveau de maturité suffisant pour qu’ils constituent un outil incontournable de cette nouvelle symphonie. Depuis, des services Docker PAAS (ou CAAS pour Container As A Service) se sont multipliés sur de grandes plateformes de Cloud public tel que Microsoft Azure, Amazon AWS, Google Cloud Platform, Digital Ocean…

Mais l’histoire ne s’arrête pas là, car un autre élément conjoncturel difficilement prévisible il y a encore quelques années s’est produit en Octobre 2014. Dans la veine d’une stratégie toujours plus ouverte, Microsoft annonçait travailler sur une intégration de Docker à son cloud public Azure mais aussi et surtout à la prochaine mouture de son OS server, Windows Server 2016, impliquant une contribution active au développement ‘open source’ du moteur Docker pour Windows ainsi qu’une modification en profondeur de son noyau !

Avec l’arrivée des Containers sous Windows, Docker deviendra donc une plateforme agnostique pour prendre en charge des applications et des services dont les composants mixtes Linux/Windows sont distribués de manière transparente (individuellement déployé sur l’OS pour lequel il a été respectivement développé).

Docker, la baleine dans l’ère du temps 

La promesse de Docker s’inscrit dans le mouvement DevOps en proposant un langage et des outils communs d’une part aux développeurs pour créer, tester, packager et mettre à disposition des applications et services containerisés, et d’autre part aux IT opérationnels pour fournir une infrastructure standardisée sur laquelle déployer, exécuter et manager ces applications et services.

Les applications containerisées sont légères, portables, indépendantes et isolées. Leur déploiement est rapide et flexible, leur exécution en grande partie indépendante de l’environnement et les ressources consommées sont maîtrisées. Les développeurs se concentrent donc sur le développement sans se soucier des problématiques d’environnement cible et les IT opérationnels ne se soucient plus des problématiques de dépendances, d’adhérences et de compatibilités.

Voyage au pays des Containers, Docker, les points essentiels :

• Développement en itération rapide

• Séparation entre état désiré et exécution

• Contrôle et limitation des ressources utilisées

• Isolation des applications/services les uns des autres

• Densification importante grâce à une empreinte réduite (stockage, mémoire, CPU)

• Portabilité avec la gestion des dépendances afin d’être indépendant vis-à-vis des environnements cibles : machine de développement, d’intégration, de production, Cloud public/privé, VM ou physique…

• Automatisation/orchestration de déploiements complexes et distribués

• Démarrage quasi instantané et « scalabilité » accrue

• Facilitation du « Continuous Integration/delivery » pour une accélération du Time-To-Market

Containerisation ou la virtualisation d’OS 

Lorsque l’on aborde pour la première fois les concepts de « containerisation », il est naturellement tentant de faire un parallèle avec la « virtualisation d’application » telle qu’on la connaît avec App-V ou encore ThinApp, dans la mesure où il s’agit d’ajouter une enveloppe autour de l’application qui devient un bac à sable désolidarisé de l’OS dans lequel cette dernière est déployée et exécutée.

Cependant, si comparaison il doit y avoir, il est plus pertinent de comparer la « containerisation » d’application à une forme plus légère de « virtualisation de machine » car même si la technologie utilisée est bien différente, ces deux formes de virtualisation partagent des caractéristiques clés et répondent à des cas d’usages similaires :

• Densification et le haut rendement qui permettent de rationaliser les ressources physiques mais aussi d’en limiter la consommation.

• Portabilité, la haute compatibilité et la disponibilité

• Orientation application serveur et service par opposition à application desktop et cliente

Une définition juste de la « containerisation », qui a l’avantage de la replacer parmi les autres formes de virtualisation, est « virtualisation de Système d’exploitation » ou « virtualisation d’OS ». Son mécanisme repose sur des fonctions dites primitives du noyau de l’OS hôte (physique ou virtuel) permettant d’exposer à chaque Container en cours d’exécution une vue dédiée du système d’exploitation et des ressources physiques tout en partageant ce même noyau.

Bien qu’ils n’apportent pas le même degré d’isolation que les machines virtuelles (à l’exception des Containers Hyper-V, cf. composants), les principaux avantages des Containers vis-à-vis de ces dernières sont :

* D’une part, le fait de n’embarquer que ce dont ils ont besoin en termes de dépendances, ce qui réduit grandement leur emprunte en matière de stockage et permet donc à la fois d’augmenter drastiquement la capacité de densification des applications ainsi que leur rapidité de déploiement.

* D’autre part, le fait de partager le noyau d’un système déjà en cours d’exécution, permet de réduire, là aussi, drastiquement le temps de démarrage passant de quelques minutes à quelques secondes.

Les Containers ne sont pour autant pas là pour remplacer les machines virtuelles, toujours utiles notamment pour constituer des machines hôte pour les containers dans le cloud ou on-premise.

Composants essentiels

Au cœur de la mécanique Docker, il y a tout logiquement… Docker, le manager de Container autrement appelé « Docker Engine » ou « Docker Daemon ». Comme son nom l’indique, le démon Docker est responsable de l’exécution des Containers et de l’abstraction du système d’exploitation. C’est lui qui en s’appuyant sur les fonctions intégrées du noyau, va exposer à chacun des Containers exécutés, une vue dédiée et isolée des ressources sous forme de « namespaces ». Les principaux « namespaces » sont l’arborescence de process, la stack réseau et le système de fichier comprenant l’arborescence racine (/ ou C:\), l’arborescence propre à chaque container contenant leur fichiers (binaires, librairies, fichiers de configuration) et l’arborescence de leur dépendances (ex: C:\nodejs). C’est aussi le démon qui contrôle et limite l’accès à ces ressources (disque, réseau, mémoire, CPU, device…).

Le Container est quant à lui l’environnement d’exécution ou « run-time », créé par le démon et caractérisé :

• Par son isolation vis-à-vis des autres Containers avec lesquels il ne partage que le noyau
• Par sa non persistance dans la mesure où son état n’est par défaut pas conservé au-delà de son exécution.

En effet le Container est avant tout pensé pour contenir une logique à exécuter sans conserver les états liés à cette exécution, ce qui en fait un consommable remplaçable par un autre Container contenant la même logique.

Enfin, l’application ou service « containerisé » qui s’exécute au sein d’un Container a été au préalable packagé sous forme d’un « Container Image », ou Image, pour s’exécuter de cette manière. Un Container est donc une instance d’un Container Image qui, à l’inverse du premier, contient de manière persistante et inaltérable un état particulier, celui d’une application ou d’un service installé et de sa configuration. Une Image référence aussi ses dépendances sous forme de lien vers une Image parente, assurant ainsi son indépendance vis-à-vis de l’environnement cible pour garantir sa portabilité. Le déploiement de l’Image enfant entraîne le déploiement de l’image parente, à moins que cette dernière ne soit déjà présente en local sur l’hôte cible. Un avantage essentiel des Images consiste à les mutualiser pour réduire d’autant plus leur empreinte sur le stockage. En effet, une image parente commune à plusieurs Containers ou Images enfant seront partagées par ces derniers.

Toute application « containerisée » est donc basée sur une Image parente souvent elle-même basée sur une autre Image parente etc. Si l’on prend l’exemple d’une Image contenant une application développée pour Node.js, elle aura pour parent une Image contenant le framework Node.js qui aura elle-même pour parent une Image contenant la distribution Linux Debian. D’ailleurs, les Images contenant un Système d’exploitation sont des Images particulières appelées « OS Image » ou « Base Image » car elles constituent la première couche de tout empilement d’Images. Il existe un nombre important de Base Images officielles de distributions Linux disponibles, ainsi que deux de Windows 2016, Core et Nano (nouvelle version du Windows extrêmement légère optimisée pour supporter des VM, des applications et des services « born-in-the-cloud » et bien entendu des Containers).

Les images une fois créées sont stockées et mises à disposition de manière centralisée au sein d’un service appelé « Registry » et dont il existe deux formes : l’une publique, le Registry officiel de Docker Inc. appelé Docker HUB, et l’autre privée qui peut être installé on-premise en fonction des contraintes. Chaque Registry est divisé en « Repository » qui correspond à un compte associé à un éditeur ou à un utilisateur. Chaque Repository peut être publié de manière publique ou privée.

D’autre part, avec l’arrivée de Docker sur Windows, Microsoft a mis à profit son expérience sur Azure en introduisant un nouveau type de Container doté d’un niveau d’isolation plus élevé afin de répondre aux situations de multi-tenant des plateformes cloud ainsi qu’à des besoins de sécurité, d’intégrité et de confidentialité plus contraignants.

Appelés Containers Hyper-V, ils reposent sur de la virtualisation de machine afin notamment de ne pas partager le noyau. Et bien que l’OS invité utilisé soit une version particulièrement optimisée de Windows, les Containers Hyper-V ont une emprunte plus importante que les Containers standards. Cela implique des performances et une densification moindres ainsi qu’un déploiement et une exécution légèrement moins rapides. En revanche les mêmes images sont utilisées pour ce type de Container et il s’agit donc d’une décision à prendre lors du déploiement. C’est en somme un mode d’exécution optionnel utilisant les mêmes Containers Image standards n’impliquant donc aucun changement lors de la phase de build d’une application « containerisée ».

Voyage au pays des Containers : Résumons !

Images

• Sorte de template persistant et inaltérable (read-only) dont l’instanciation s’exécute sous forme d’un Container
• Contient la logique d’une application (binaire, librairie, configuration…) ainsi qu’une instruction d’exécution (process par défaut du Container).
• Référence ses dépendances sous forme de lien vers une autre Image à partir de laquelle elle a été créée.
• Se compose d’un empilement de plusieurs Images parents dont une Base Image contenant un Système d’exploitation.
• Permet la portabilité des applications/services grâce à la gestion des dépendances.
• En cas de dépendances communes pour plusieurs Containers sur le même hôte, les images parents sont automatiquement partagées.

Containers 

• Instance d’une Image
• Environnement d’exécution non persistant et isolé qui possède sa vue dédiée de l’OS
• Partage le noyau avec les autres Containers et processus du système hôte
• Possède un accès dédié et contrôlé aux ressources du système

Hyper-V Containers

• Instance d’une Container Image
• Environnement d’exécution non persistant et isolé qui possède sa vue dédiée de l’OS
• Isolation plus importante pour des scénarios multi-tenant ou aux contraintes de sécurité fortes
• Repose sur de la virtualisation de machine pour garantir cette isolation, ce qui implique une empreinte plus importante et donc des performances et une densification moindre.

Docker Daemon

• Exécute les containers
• Expose une vue dédiée des ressources système à chaque container
• Contrôle et limite l’accès à ces ressources
• Gère/mutualise les dépendances des containers et des images

Registry

• Service de stockage des images
• Peut être public (Docker Hub) ou privé (Docker Trusted Registry)
• Segmenté en « Registry » public ou privé, qui correspondent à des comptes

Nous verrons dans la prochaine étape que bien que les Containers et les composants clés ci-dessous répondent à un certain nombre de promesses (isolation, portabilité, densification et haut rendement) ils ne sont en fait que les fondations d’un écosystème plus complet sans cesse en évolution pour l’orchestration et l’automatisation d’applications et de services « born-in-the-cloud » étant, par essence, multi-tiers, distribués, « scalable » et hautement disponible pour répondre aux besoins de notre ère, celle du service.