L’écosystème Docker : aperçu de l’outil

Nel giro di pochi anni il nome “Docker” è praticamente diventato un sinonimo per la tecnologia container nell’ambito dei software. All’azienda è riuscito di ravvivare le funzioni centrali di Linux che servono come fondamenta per la virtualizzazione a livello di sistema operativo e, grazie ad uno standard multipiattaforma sviluppato autonomamente, a stabilirsi come alternativa per gli hardware di virtualizzazione capaci di supportare l’hypervisor.

Note

Docker utilise l’interface auto-développée LibContainer, qui combine un driver et une bibliothèque, pour gérer les fonctions du noyau Linux et fournir un ensemble de technologies d’isolation telles que des espaces de nom, des groupes de contrôle, des applications Armor, des profils de sécurité, des interfaces de réseaux et des règles de pare-feu pour l’exploitation des conteneurs de programmes. Le logiciel open-source est la base de l’environnement d’exécution pour Docker RunC, et du programme démon ContainerD, qui sont tous deux basés sur les standards industriels de l’OCI (Open Container Initiative) et qui, en tant que projets open-source, continuent d’être développés.

Docker marque des points grâce à un niveau d‘entrée très accessible. Avec ses services en ligne tels que Docker Hub ou Docker Cloud, il propose aux développeurs et aux administrateurs une solution parfaite et complètement intégrée pour tester les logiciels, et déployer des solutions multi-plateformes et des applications basées sur des conteneurs.

L’objectif du projet open-source est d’établir le conteneur comme technologie standard pour tout ce qui concerne la mise à disposition d’applications et de systèmes productifs. Ce projet comporte toutefois de nombreux obstacles que le moteur Docker ne peut surmonter à lui seul. Ceci inclut l’exploitation d’applications multi-conteneurs, l’orchestration de conteneurs dans des systèmes distribués et dans des environnements cloud, ainsi que l’évolutivité d’applications basées sur des conteneurs.

Au fil du temps, de nombreux projets latéraux ont donc éclos au sein du concept initial et enrichissent le moteur Docker de fonctionnalités puissantes pour le développement du produit. Il existe en outre un important écosystème d’outils et de plateformes externes sur une base open-source, qui fournissent des interfaces à Docker et offrent aux utilisateurs la possibilité de distribuer des applications basées sur des conteneurs à travers différentes infrastructures du cloud, sous formes d’applications locales (on-premises) ou dans des environnements hybrides.

Nous vous présentons les extensions les plus importants de la plateforme de conteneur, et vous proposons un aperçu des projets tiers les plus populaires avec lesquels les outils Docker sont développés sur une base open-source.

Les extensions et services en ligne de Docker

Docker est aujourd’hui bien plus qu’une simple plateforme pour l’exploitation de programmes basés sur des conteneurs. Pour simplifier le déploiement des applications vers des infrastructures distribuées et des environnements cloud, l’équipe de développeurs au cœur du programme y a ajouté plusieurs extensions et services en ligne. Outre la gestion des clusters et l’orchestration, ils proposent aux utilisateurs une plateforme commerciale centralisée et un outil de gestion des ressources du cloud.

Le moteur Docker

Lorsque les utilisateurs parlent de Docker, il s’agit en général de l’application client-serveur open-source, qui constitue la base de la plateforme de conteneur. Dans la terminologie Docker, ceci est communément appelé le « moteur Docker ». Le moteur Docker est basé sur le démon Docker, un REST API et un CLI (Command Line Interface) pour l’interface utilisateur. Cette construction vous permet de traiter avec le moteur grâce à la ligne de commande et de gérer facilement les images, les fichiers Docker et les conteneurs depuis le terminal.

Une description détaillée du moteur Docker est disponible dans notre tutoriel Docker pour les débutants.

Le Docker Hub

Avec le Docker Hub, le projet open-source fournit aux utilisateurs un registre basé sur le cloud qui permet de télécharger des images Docker, mais aussi de les gérer de façon centralisée et de les partager avec d’autres utilisateurs de Docker, de façon publique ou grâce à des registres privés. Pour partager des images, il est nécessaire de disposer d’un compte Docker. En revanche, télécharger (pull, dans la terminologie Docker) des images publiques est possible sans inscription. Il est ensuite possible de les visionner grâce à un mécanisme de tag intégré.

Outre les registres publics des autres utilisateurs, vous trouverez sur le hub de nombreuses ressources correspondant aux images d’archives officielles de l’équipe de développeurs et de célèbres projets open-source. Les images les plus populaires de Docker sont le serveur Web léger NGINX, la base de données Redis, la boîte à outils BusyBox d’Unix et la distribution Linux Ubuntu.

Le Docker hub présente également une autre fonctionnalité, appelée Organizations : ce sont des groupes de travail qui permettent aux utilisateurs de la plateforme de conteneurs de créer des registres privés seulement accessibles à un groupe de personnes.

La machine Docker

La machine Docker permet aux hôtes Docker de se déployer et de se gérer depuis presque n’importe quelle infrastructure. L’outil automatise la mise en œuvre de Docker et facilite considérablement le déploiement des hôtes Docker.

Les termes Docker host ou dockerized host désignent, pour l’équipe de développement, un hôte virtuel sur lequel fonctionne le moteur Docker. Si l’utilisation de Docker a toujours été native avec toutes les distributions Linux, elle requérait sous les systèmes Windows et MacOS une couche d’abstraction, qui prend la forme d’une machine Docker. Ceci a fondamentalement changé depuis la publication de v1.12, et Docker est aujourd’hui disponible en multi-plateformes aussi bien que sur Windows et MacOS. Ce champ d’application central de la machine Docker s’est donc déplacé vers les scenarii à distance et la gestion d’hôtes Docker dans un environnement cloud.

Si un grand nombre de nœuds sont utilisés sur un réseau ou une infrastructure cloud telle qu’Amazon Web Services (AWS) ou DigitalOcean, les utilisateurs retournent tôt ou tard à la machine Docker. L’outil permet de diminuer l’effort nécessaire pour créer de nouveaux hôtes Docker sur une simple ligne de commande (docker-machine create), et de contrôler de nombreux nœuds Docker depuis le terminal. La machine Docker prend en charge la création de SSL-PKI ainsi que la distribution des certificats requis pour l’authentification utilisateur. En combinaison avec Docker Swarm, le programme est utilisé pour la mise en place des clusters Docker.      

En général, la machine Docker est utilisée sur le système local. L’outil Docker crée automatiquement de nouveaux hôtes, installe le moteur Docker, et configure la ligne de commande installée localement pour un contrôle à distance. Ceci permet de traiter avec les hôtes dans le cloud grâce au système local, afin de gérer ces commandes Docker à distance.

Docker Swarm

Depuis la version 1.12, le moteur Docker contient une fonction native qui permet de gérer les hôtes Docker dans les clusters et qui est appelée Swarm. La gestion des clusters et l’orchestration des fonctions basées dans le moteur Docker reposent sur la boîte à outils Swarmkit. Dans les versions antérieures de la plateforme de conteneurs, Swarm est disponible sous forme d’application autonome.

Note

un cluster est un ensemble d’hôtes Dockers hébergés sur l’infrastructure d’un fournisseur laaS externe ou sur son propre centre de données.

L’outil natif de gestion des clusters Swarm regroupe plusieurs hôtes Docker en un seul hôte virtuel, et fonctionne avec le Docker REST API. Par conséquent, chaque outil relié au démon Docker peut avoir accès à Swarm, et évoluer parmi un grand nombre d’hôtes Docker. Pour créer des clusters, distribuer les applications dans le cluster et contrôler le comportement du groupe, les utilisateurs ont recours au moteur Docker CLI. Aucun programme d’orchestration supplémentaire n’est nécessaire.

Les moteurs Docker, qui ont été regroupés en cluster, fonctionnent en mode Swarm. C’est celui qu’il faut sélectionner pour créer un nouveau cluster ou ajouter un hôte Docker à un cluster déjà existant. Chaque hôte Docker individuel est appelé un « nœud ». Les nœuds d’un cluster peuvent fonctionner en tant qu’hôtes virtuels sur le même système local, mais il est plus efficace d’utiliser un système basé sur le cloud, grâce auquel les nœuds individuels de chaque cluster sont distribués à travers différents systèmes et infrastructures.

Le programme repose sur une architecture maître-esclave. Si les tâches doivent être distribuées dans le cluster, les utilisateurs ont recours à un service de gestion des nœuds, qui se comporte comme le maître du cluster. Ce maître est responsable de l’organisation des conteneurs dans le cluster, et sert de première interface utilisateur pour accéder aux autres ressources du cluster.

Le nœud maître envoie des actions à accomplir, appelées tâches (task), aux esclaves qui lui sont subordonnés, appelés nœuds esclaves worker nodes dans la terminologie Docker. 

  • Services : les services constituent la structure centrale des clusters dans Docker. Un service est un groupe de conteneurs basés dans la même image. Un service définit les tâches qui sont exécutées dans le cluster. L’utilisateur qui crée un service spécifie quelles images et quelles commandes doivent être utilisées. En outre, les services permettent d’échelonner les applications. Les utilisateurs de la plateforme Docker déterminent simplement combien de conteneurs doivent démarrer pour un service.
  • Tâches : pour pouvoir être distribués dans le cluster, les services sont divisés en tâches de travail individuelles par le nœud maître.

En plus de gérer le cluster et l’orchestration des conteneurs, le nœud maître (manager) fournit également aux nœuds esclaves des fonctionnalités par défaut, sauf si l’on décide de restreindre ses attributions aux tâches de gestion.

Un programme agent fonctionne sur chaque nœud worker. Celui-ci accepte les tâches et délivre des rapports aux nœuds maîtres respectifs à propos de l’état de progression de la tâche en cours. Le graphique ci-dessous propose une explication schématique de la structure d’un cluster Docker :

Pour la mise en œuvre d’un cluster Docker, les utilisateurs ont en général recours à la machine Docker.

Docker Compose

Compose est la solution Docker pour les applications multi-conteneurs. Développé à l’origine par l’entreprise de logiciels Orchard, cet outil d’orchestration léger fait aujourd’hui partie du portfolio de Docker.

Docker Compose vous permet de relier plusieurs conteneurs et de les contrôler grâce à une seule commande. Cet outil open-source est écrit en langage Python. L’élément essentiel de Compose est le fichier de contrôle central écrit dans le langage de programmation YAML. La syntaxe des fichiers Compose est similaire à celle du logiciel open-source Vagrant, utilisé pour créer et approvisionner des machines virtuelles.

Dans le fichier docker-compose.yml, vous pouvez définir le nombre de programmes de conteneurs, y compris les dépendances, ainsi que leurs interactions. Les applications multi-conteneurs de ce type sont contrôlées selon le même schéma que les conteneurs individuels. Pour gérer le cycle de vie d’une application dans son ensemble, il suffit d’utiliser la commande Compose de Docker ainsi que la commande subordonnée correspondante.

L’outil Docker est facile à intégrer sur un cluster basé sur Swarm. Ceci vous permet d’exploiter très facilement des applications multi-conteneurs créées avec Compose, aussi bien sur des systèmes distribués que sur un hôte Docker individuel.

Docker Compose présente une autre caractéristique intéressante, un mécanisme d’extensibilité intégré. Grâce à l’outil d’orchestration, vous pouvez facilement choisir combien de conteneurs vous souhaitez démarrer pour un service en particulier, en utilisant une seule ligne de commande.

Docker-Cloud (anciennement Tutum)

Fin 2015, Docker a repris Tutum, un outil de déploiement de conteneurs et d’administration et l’a intégré au Docker-Cloud. Si le docker hub sert de plateforme de stockage centrale pour les images, le cloud docker fournit une plateforme basée sur le Web, grâce à laquelle vous pouvez créer, tester, surveiller et distribuer des conteneurs Docker dans diverses infrastructures.

Le cloud Docker propose une intégration native avec tous les services Docker, et il est compatible avec de nombreux autres services de Cloud, tels que Microsoft Azure, Amazon Web Services, DigitalOcean, IBM Softlayer, Packet.net ou Google Container Engine. De plus, les utilisateurs ont la possibilité de lier le cloud Docker à leur propre infrastructure.

Il faut toutefois prêter attention à un point : le cloud Docker ne propose pas de service d‘hébergement. Toutes les ressources pour les nœuds, les services et les stacks (voir explication ci-dessous) que vous créez à travers la plateforme doivent être déployés sur des services externes ou sur leur propre centre de données.

Note

un stack est un ensemble de plusieurs services Docker qui constituent une application.

La connexion native pour établir des infrastructures en tant que services (IaaS) vous offre la possibilité de distribuer des applications à travers différentes plateformes d’hébergement ou en combinaison avec des architectures hybrides et des nœuds locaux. La gestion des nœuds Docker à travers de multiples infrastructures est centralisée grâce à l’interface utilisateur graphique, le tableau de bord (dashboard) du cloud Docker. À partir de là, vous pouvez vous connecter au centre de données ou à un fournisseur d’hébergement externe et créer des nœuds Docker individuels (nodes), ou même des clusters entiers. 

Note

les nœuds Cluster basés sur des fournisseurs d’hébergement externes ne peuvent pas être implémentés dans le cloud Docker.

Outre le déploiement sur des plateformes croisées et l’évolutivité des applications dans le cloud, la plateforme de déploiement fournit des interfaces à plusieurs registres, tels que le hub Docker et la fonction de tests automatiques. La vidéo suivante, réalisée par l’équipe de développeurs, propose un aperçu des fonctionnalités essentielles et des possibilités d’application proposées par le cloud Docker :

La boîte à outils Docker

Depuis la publication de v1.12, Docker est également disponible pour les dernières versions de macOS et Windows en tant qu’application de bureau native. Les utilisateurs de systèmes plus anciens devront, eux, s’appuyer sur la boîte à outils de Docker pour installer la plateforme de conteneurs sur leur ordinateur.

La boîte à outils Docker est un driver qui automatise l’installation d’un environnement Docker sur les anciens systèmes d’exploitation macOS et Windows. Le programme contient les composants suivants :

  • Le moteur Docker
  • La machine Docker
  • Docker Compose
  • Oracle VirtualBox
  • Le Kitematic Docker-GUI
  • Une interface de ligne de commande configurée pour Docker

Le cœur de la boîte à outils Docker est le programme open-source Kitematic. Il s’intègre à la machine Docker pour fournir une machine virtuelle basée sur l’Oracle VirtualBox, afin d’installer la plateforme sur Windows et Mac. Les utilisateurs de Docker ont accès à une interface graphique permettant de créer, démarrer et arrêter des conteneurs en quelques clics. Le docker hub est également pourvu d’une interface permettant de rechercher des registres directement depuis l’application de bureau et de télécharger des images.

En plus du GUI, il existe une interface de ligne de commande préconfigurée. Tous les changements effectués par les utilisateurs via des saisies sont également appliqués sur les autres modes. Par ailleurs, les utilisateurs peuvent facilement passer de GUI à CLI pour exploiter et contrôler les conteneurs. Kitematic fournit enfin des fonctionnalités permettant d’assigner des ports, de définir des environnements variables et de configurer des lecteurs (volumes).

Même s’il est indiqué dans la documentation Docker que la boîte à outils Docker est désuète (legacy), elle est encore compatible avec le logiciel. L’équipe de développeurs recommande toutefois d’utiliser les applications de bureau natives Docker for Windows ou Docker for Mac, lorsqu’ils sont déjà installés sur votre système d’exploitation.

Les outils Docker des fournisseurs extérieurs

Outre les propres extensions de Docker Inc., il existe de nombreux programmes et plateformes de fournisseurs extérieurs, disponibles pour les interfaces des moteurs Docker ou développés spécifiquement pour la plateforme de conteneurs. Parmi les projets open-source les plus populaires de l’écosystème Docker, on compte l’outil d’orchestration Kubernetes, l’outil de gestion des clusters Shipyard, la solution d’envoi multi-conteneurs Panamax, la plateforme d’intégration continue Drone, le système d’exploitation basé sur le cloud OpenStack, et le système d’exploitation Mesosphere DC/OS basé sur le gestionnaire de clusters Mesos.

Kubernetes

Docker n’a pas toujours disposé de ses propres outils d’orchestration tels que Swarm et Compose. Pour cette raison, de nombreuses entreprises ont investi depuis plusieurs années dans des outils de développement conçus sur mesure pour faciliter l’exploitation de la plateforme de conteneurs sur de grandes infrastructures distribuées. L’une des solutions de ce type les plus célèbres, en plus de la plateforme d’orchestration open-source de Spotify, Helios, est le projet open-source Kubernetes.

Kubernetes est un gestionnaire de cluster pour les applications basées sur conteneurs, dont la majeure partie a été développée par Google, et qui est aujourd’hui sous la houlette de la Cloud Native Computing Foundation (CNCF).

Note

la Cloud Native Computing Foundation (CNCF) est une sous-organisation de la Fondation Linux (LF). En 2015, la coopération de Linux avec Google a été déterminante dans la création de la fondation la même année, puisque Google a fait don de Kubernetes à la CNCF. L’objectif de l’organisation est de développer des technologies de conteneurs dans le cadre de projets open-source. Outre Google, elle compte parmi ses membres Docker, Twitter, Huawei, Intel, Cisco, IBM, Univa et VMware.    

Depuis le milieu de l’année 2015, Kubernetes 1.0 est donc disponible pour des systèmes de production et est notamment utilisé dans le Google-Container-Engine (GKE).
L’objectif de Kubernetes est d’automatiser les applications dans le cluster. L’outil d’orchestration utilise l’API REST, le programme de ligne de commande, et une interface Web graphique de contrôle, grâce auxquels il est possible d’activer des automatismes et de demander des rapports d’exécution. Les utilisateurs ont recours à Kubernetes pour les raisons suivantes : 

  • exploiter des applications basées sur des conteneurs dans un cluster
  • établir et gérer des applications dans des systèmes distribués
  • rendre des applications évolutives
  • utiliser le matériel disponible de la meilleure façon possible

Pour ce faire, Kubernetes rassemble les conteneurs en parts logiques, que l’on appelle des pods. Les pods représentent les unités de base du gestionnaire de cluster, qui peuvent être distribuées dans le cluster selon un plan d’organisation.
Tout comme le Swarm de Docker, Kubernetes est basé sur une architecture maître-esclave. Un cluster est composé du maître Kubernetes, ainsi que de plusieurs esclaves, qui sont appelés les nœuds Kubernetes (parfois également workers ou minions). Le maître Kubernetes se comporte dans le cluster comme l’unité de contrôle centrale (control plane). Il est composé de quatre éléments essentiels, qui permettent de contrôler la communication entre le cluster et les tâches distribuées. Un maître Kubernetes est constitué d’un serveur API, une mémoire de configuration etcd, un organiseur et un gestionnaire de contrôle.

  • Serveur API : tous les automatismes d’un cluster Kubernetes sont activés par un serveur API via REST API. Ceci fonctionne comme l’interface d’administration centrale du cluster.
  • etcd : la mémoire de configuration open-source etcd correspond à la mémoire du cluster. Le Key value Store, développé par CoreOS spécialement pour les systèmes distribués, sauvegarde les données de configuration et les met à disposition de chaque nœud du cluster.
  • Organiseur : l’organiseur est responsable de la distribution des groupes de conteneurs (les pods) dans le cluster. Pour ce faire, il détermine les ressources dont ont besoin les pods, et attribue les ressources disponibles à chaque nœud du cluster.
  • Gestionnaire de contrôle : le gestionnaire de contrôle est un service du maître Kubernetes, qui régit l’état du cluster, des tâches de routine et donc l’orchestration. La tâche principale du gestionnaire de contrôle est de s’assurer que l’état du cluster corresponde à l’état défini dans les objectifs.

Tous les composants du maître Kubernetes peuvent être hébergés sur un seul et même hôte, ou distribués sur plusieurs hôtes maîtres dans le cadre d’un cluster haute disponibilité.
Si le maître Kubernetes est responsable de l’orchestration, les pods distribués dans le cluster sont exécutés sur les hôtes, c’est-à-dire les nœuds Kubernetes, qui sont subordonnés au maître. C’est la raison pour laquelle un moteur de conteneur doit être exécuté sur chaque nœud Kubernetes. Docker est parfaitement adapté à cette fin, même si Kubernetes n’est défini par aucun moteur de conteneur en particulier.
Outre le moteur de conteneurs, les nœuds Kubernetes comprennent les composants suivants :

  • Kubelet : kubelet est un agent qui est exécuté sur chaque nœud Kubernetes et qui sert à contrôler et gérer les nœuds. En tant que point de contact central avec chaque nœud, Kubelet est connecté au maître Kubernetes, et s’assure que les informations soient bien transmises au centre de contrôle. L’agent reçoit les commandes et les ordres du maître Kubernetes et conduit leur exécution sur chaque nœud respectif.

Kube-proxy : outre le moteur de conteneur et l’agent kubelet, chaque nœud Kubernetes exécute également un service proxy, kube-proxy. Celui-ci s’assure que les requêtes sont transmises depuis l’extérieur vers les conteneurs respectifs, et fournit aux utilisateurs les services d’applications basées sur des conteneurs. Kube-proxy offre en outre une forme basique de load-balancing.

Le schéma ci-dessous représente l’architecture maître-esclave sur laquelle est basée la plateforme d’orchestration Kubernetes.

Outre le projet central Kubernetes, il existe de nombreux outils et extensions qui permettent, grâce à des fonctionnalités supplémentaires, de mieux appréhender la plateforme d’orchestration. Parmi les plus connus, on compte l’outil de surveillance et de diagnostic des erreurs Prometheus, Weave Scope et sysdig, ainsi que le gestionnaire de paquets Helm. Par ailleurs, il existe des plugins pour Apache Maven et Gradle, ainsi qu’un API Java pour le contrôle de Kubernetes à distance.

Shipyard

Shipyard est une solution de gestion basée sur Swarm et développée par la communauté d’utilisateurs de Docker. Grâce à une interface utilisateur graphique, elle permet aux utilisateurs de gérer les ressources de Docker, comme les conteneurs, les images, les hôtes, et les registres privés. Cet outil est disponible en tant qu’application Web dans un navigateur, et diffère en ce sens de l’application de bureau Kitematic.

Le programme est entièrement compatible avec Docker à distance, API, et utilise la base de données open-source NoSQL RethinkDB pour le stockage des données des comptes utilisateurs, les adresses et les évènements.

Outre la gestion du cluster grâce à son interface centrale, Shipyard offre aux utilisateurs la possibilité de s’identifier ainsi qu’un accès de contrôle basé sur la distribution des rôles.

Le programme est basé sur l’outil de gestion des clusters Citadel, et il est formé de trois composants essentiels : Controller, API et UI.

  • Shipyard Controller : le contrôleur est le composant-clé de l’outil de gestion Shipyard. Il interagit avec le Rethink DB dans le cadre de la sauvegarde des données, et permet d’être en contact avec chaque hôte et de contrôler les actions.
  • Shipyard API : l’API Shipyard est un API basé sur REST. Toutes les fonctionnalités de l’outil de gestion sont contrôlées depuis l’API Shipyard.
  • Shipyard User Interface (UI) : l’interface utilisateur UI Shipyard est une application AngularJS. Elle offre aux utilisateurs une interface graphique pour gérer les clusters Docker dans un navigateur Web. Toutes les interactions avec l’interface sont conduites par l’API Shipyard.

Plus d’informations sont disponibles sur le site officiel du projet open-source.

Panamax

Les développeurs du programme open-source Panamax se sont fixés pour objectif de simplifier la mise à disposition des applications multi-conteneurs. L’outil gratuit comprend une interface utilisateur graphique, grâce à laquelle des applications complexes basées sur Docker peuvent être développées, déployées et distribuées par un simple glisser-déposer.

Panamax permet de sauvegarder des applications multi-conteneurs complexes grâce à des templates d’application, et de les distribuer dans les architectures clusters d’un simple clic. Avec une application marketplace intégrée et hébergée sur GitHub, il est possible de sauvegarder dans Git des templates pour des applications personnalisées, qui peuvent ensuite être disponibles pour d’autres utilisateurs. L’animation suivante illustre bien le concept de Panamax, qui se base sur la devise Docker Management for Humans : 

Panamax a été publié par CenturyLink en tant que programme open-source sous la licence 2 Apache. Les composants de base de l’architecture de Panamax se divisent en deux groupes : le client local Panamax et un grand nombre de cibles de déploiement à distance.

Le client local Paramax est au cœur de l’outil Docker. Il est exécuté sur le système local et permet de créer des applications complexes basées sur des conteneurs. Il est constitué des composants suivants :

  • CoreOS : l’installation du client local Panamax requiert une distribution Linux CoreOS, spécialement conçue pour l’hébergement des programmes de conteneurs. L’équipe de développeurs recommande d’installer CoreOS sur le système local via Vagrant et Oracle Vitualbox. La structure classique de l’installation Panamax fonctionne selon un principe de base : un ordinateur local avec un système d’exploitation. C’est sur cette base que les utilisateurs installent CoreOS, à l’aide de l’outil de visualisation VirtualBox. Panamax est ensuite exécuté en tant que client du conteneur Docker à travers CoreOS. Le programme a spécifiquement été développé en tant que client Docker pour les distributions Linux légères. Outre les fonctionnalités spécifiques à Docker, Panamax propose aux utilisateurs plusieurs fonctions CoreOS. On compte notamment parmi elles Fleet et Journalctl :

    • Fleet : au lieu d’interagir directement avec Docker, le client Panamax utilise le gestionnaire de clusters Fleet pour orchestrer les conteneurs. Fleet est un gestionnaire qui contrôle le systemd du démon Linux.

    • Journalctl : e client Panamax utilise Journalctl pour extraire des messages depuis le gestionnaire de système Linux systemd vers le journal.
  • Local client installer : le programme d’installation du client local comprend tous les composants nécessaires à l’installation du client Panama sur un système local.
  • Panamax Local Agent : le composant central du client local est l’agent local. Il est relié à l’API Panamax grâce à de nombreux autres composants et dépendances. Parmi eux on compte l’hôte Docker local, le Panamax UI, les registres externes ainsi que les agents à distance pour les cibles de déploiement dans le cluster. L’agent local interagit avec l’API Panamax sur le système local pour échanger des informations à propos des applications en cours d’exécution, grâce aux interfaces de programmation suivantes :

    • Docker-Remote-API : grâce à Docker-Remote-API, Panamax recherche des images et des systèmes locaux, et extrait des informations concernant le statut des conteneurs en cours d’exécution.

    • etcd-API : avec l‘API etcd, les données sont transférées au démon Fleet CoreOS.

    • systemd-journal-gatewayd.services :  grâce au systemd-journal-gatewayd.services, Panamax transfère les productions du journal aux différents services en cours d’exécution.

    De plus, l’API Panamax permet des interactions avec divers API externes.

    • Docker-Registry-API : grâce à l’API Docker Registry, Panamax récupère les tags des images à partir des registres Docker.

    • GitHub-API : grâce l’API GitHUb, les templates Panamax peuvenet être téléchargés dans les registres GitHub.

    • KissMetrics-API : les API KissMetrics collectent des données sur les templates que les utilisateurs exécutent.
  • Panamax-UI : l’UI Panamax agit comme l’interface utilisateur sur le système local et permet à l’utilisateur de contrôler l’outil Docker grâce à une interface utilisateur graphique. À travers l’API Panamax, les données de l’utilisateur sont transférées directement à l’agent local. L’UI Panama est basé sur le kit CTL UI, une bibliothèque contenant des composants UI pour les projets Web CenturyLink.

Dans la terminologie Panamax, chaque nœud d’un cluster Docker auquel n’est attribuée aucune tâche de gestion est appelé une cible de déploiement à distance (remote deployment target). Les cibles de déploiement sont composées d’un hôte Docker configuré pour déployer des templates Panamax en utilisant les composants suivants :

  • Deployment-Target-Installer : l’installateur de cible de déploiement démarre un hôte Docker en utilisant un agent à distance Panamax et un adaptateur d’orchestration.
  • Panamax-Remote-Agent : lorsque l’agent à distance Panamax est installé, les applications peuvent être distribuées vers n’importe quel point du cluster à l’aide du client local Panamax. L’agent à distance Panamax s’exécute en tant que conteneur Docker sur chacune des cibles de déploiement dans le cluster.
  • Panamax-Orchestration-Adapter : l’adaptateur d’orchestration fournit une logique de programme à chaque outil d’orchestration disponible pour Panamax dans une couche indépendante d’adaptateur. Ceci permet aux utilisateurs de sélectionner précisément la technologie d’orchestration compatible avec l’environnement de leur cible. Les adaptateurs préconfigurés incluent Kubernetes et Fleet :

    • Panamax-Kubernetes-Adapter : en combinaison avec l’agent à distance Panamax, l’adaptateur Panamax Kubernetes permet de partager des templates Panamax dans le cluster Kubernetes.

    • Panamax-Fleet-Adapter : en combinaison avec l’agent à distance Panamax, l’adaptateur Panamax Fleet permet de partager des templates Panamax dans le cluster, contrôlés grâce au gestionnaire de clusters Fleet.

Le diagramme suivant illustre le rôle coordonné de chaque composant Panamax dans le cluster Docker :

Panamax, l’outil de gestion de conteneurs basé sur CoreOS, propose aux utilisateurs plusieurs technologies standard pour l’orchestration de conteneurs grâce à une interface utilisateur graphique, ainsi que l’option confortable de créer des applications multi-conteneurs dans une architecture de clusters grâce à n’importe quel système, y compris leur propre ordinateur. 

Avec le public template repository, Panamax offre aux utilisateurs, via GitHub, un accès libre et gratuit à une bibliothèque de templates et de nombreuses autres ressources.

Drone

Drone est une plateforme d’intégration continue légère et peu exigeante. Écrit en Go, l’outil s’utilise pour télécharger automatiquement des builds (les développements individuels d’un nouveau logiciel) à partir de registres Git tels que GitHub, GitLab ou Bitbucket, mais aussi pour conduire des tests sur des conteneurs Docker isolés. Il est possible d’effectuer toutes sortes de tests et d’envoyer des rapports et informations de statut par email. Pour chaque test de programme, un nouveau conteneur basé sur une image du registre public Docker est créé. Par conséquent, toute image disponible publiquement sur Docker peut être utilisée comme environnement du code à tester.

Note

le terme intégration continue (continuous integration en anglais) désigne un procédé de développement de programmes, dans lequel des composants nouvellement développés, que l’on appelle des builds (de l’anglais build, qui signifie construire), sont intégrés au programme à intervalles réguliers (en général une fois par jour au minimum) dans un environnement de test. Les applications complexes étant souvent développées par des équipes nombreuses, l’intégration continue est une stratégie mise au point pour identifier et supprimer les erreurs d’intégration qui peuvent survenir lorsque plusieurs développeurs travaillent ensemble. Drone offre aux développeurs la possibilité d’implémenter différents environnements de tests en utilisant les conteneurs Docker.

Drone est intégré à Docker et compatible avec plusieurs langages de programmation tels que PHP, Node.js, Ruby, Go ou Python. La plateforme de conteneurs est conçue pour être la seule dépendance. Avec Drone, vous pouvez installer votre propre plateforme d’intégration continue sur n’importe quel système compatible avec Docker. Drone est compatible avec plusieurs registres de contrôle de version. Vous trouverez un guide pour une installation standard et l’intégration GitHub dans la documentation du projet open-source readme.drone.io.

La plateforme d’intégration continue est contrôlée grâce à une interface Web, à partir de laquelle il est possible de télécharger les builds depuis n’importe quel registre Git, d’ajouter des applications et d’effectuer des tests dans un environnement de test défini au préalable. Pour ce faire, un fichier .drone.yml est défini pour chaque test de programme, et indique comment créer et exécuter l’application.

Dans la vidéo suivante, Brad Rydzewski, co-auteur de Drone, donne un bon aperçu de la plateforme d’intégration continue :

Selon le développeur, Drone offre aux utilisateurs une solution CI open-source qui combine les avantages de produits tels que de Travis et Jenkins dans une interface utilisateur conviviale.

OpenStack

Lorsqu’il s’agit de construire et d’exécuter des structures open-source basées dans le cloud, OpenStack est une solution de premier choix. Le système d’exploitation open-source basé dans le cloud est né en 2010 suite à la collaboration entre l’hébergeur américain Rackspace et la NASA. Le projet, gratuit et soumis à une licence Apache, est soutenu par des entreprises telles qu’AT&T, SUSE, Canonical, HP, Intel Red Hat et IBM.

OpenStack permet de gérer des ressources d’ordinateur, de mémoire et de réseau via un tableau de bord centralisé, accessible aux utilisateurs grâce à une interface Web.

Le système d’exploitation basé dans le cloud est construit selon une architecture modulaire. Il est composé de six composants essentiels : 

  • Nova (composant central de la grille) : le composant central de calcul (compute) d’OpenStack est surnommé Nova. C’est quasiment le cerveau de l’architecture du programme. Nova est en charge de gérer toutes les instances de calcul du système, et permet aux utilisateurs de démarrer les machines virtuelles (VM) basées sur des images, de les exécuter dans un environnement Cloud et de les gérer dans le cluster. Les VM peuvent être distribuées dans n’importe quelle quantité de nœuds. En tant que contrôleur de structure basé dans le cloud (Cloud computing fabric controller), OpenStack est un composant essentiel pour les services IasS basés dans OpenStack. Nova est compatible avec plusieurs hyperviseurs et technologies de virtualisation, ainsi que des architectures bare-metal, dans lesquelles les VM sont directement installées sur le hardware. En général, on utilise KVM, VMware, Xen, Hyper-V ou la technologie de conteneurs Linux LXC.
  • Neutron (composant de réseau) : Neutron (anciennement Quantum) est un composant de système portable, évolutif et basé sur API, utilisé par le contrôleur de réseau. Le module fournit une interface pour les topologies de réseaux complexes, et il est compatible avec de nombreux plugins, qui peuvent être utilisés pour intégrer des fonctions réseaux avancées.
  • Cinder (Block-Speicher): Cinder est le surnom du composant de l’architecture OpenStack qui fournit un bloc de mémoire persistant pour l’exécution des machines virtuelles. Le module fournit une mémoire virtuelle via un auto-service API. De cette façon, les utilisateurs peuvent utiliser les ressources de stockage sans avoir à se demander sur quel appareil sont sauvegardées leurs ressources.
  • Keystone (service d’identité) : avec Keystone, les utilisateurs d’OpenStack disposent d’un service d’identité central à portée de main. Le module agit comme un système d’authentification et de droit entre chaque composant d’OpenStack. L’accès aux projets dans le cloud est régulé par des éléments appelés tenants. Chaque tenant représente un utilisateur individuel. Pour chaque utilisateur, il est possible de définir plusieurs accès avec des droits différents.
  • Glance (Image-Service) : le module Glance est un service d’OpenStack qui permet de stocker et de transférer les images des machines virtuelles. Le composant de calcul Nova utilise les images fournies par Glance comme des templates pour créer des exemples de machines virtuelles.
  • Swift (enregistreur d’objet) : le module Swift d’OpenStack est utilisé par le composant de calcul Nova pour sauvegarder des données non structurées et les transférer via API. Swift se distingue par une architecture redondante et évolutive et une haute tolérance aux erreurs.

Depuis la publication de Havana en 2013, le composant Nova propose un driver hyperviseur pour le moteur Docker. Il comprend un client HTTP au sein de l’architecture OpenStack, qui permet d’envoyer l’API Docker interne via un socket Unix.

Le driver Docker pour Nova permet de transférer les images à partir du service d’images Glance, et de les télécharger directement dans le fichier système Docker. De plus, les images peuvent être exportées de la plateforme de conteneurs vers la commande standard Docker (docker save) et sauvegardées dans Glance. Il existe un guide expliquant pas à pas comment intégrer Docker dans une architecture OpenStack déjà existante, disponible dans le wiki d’OpenStack.

Par ailleurs, la fondation OpenStack a mis en ligne sur YouTube un tutoriel de 90 minutes sur l’intégration Docker :

Outre ses six composants de base, l’architecture OpenStack peut être complétée par différents modules et extensions :

  • Horizon (tableau de bord): Horizon, le tableau de bord d’OpenStack, propose aux utilisateurs une interface graphique basée sur le Web, grâce à laquelle ils peuvent contrôler les autres composants tels que Nova ou Neutron.
  • Heat (orchestration) : le module optionnel Heat fournit un service permettant d’orchestrer des applications cloud via des templates. Il propose par défaut un API REST natif et un format HOT pour les templates. Il est également compatible avec des formats alternatifs tels qu’AWS Cloud Formation et Query API.
  • Ceilometer (service de télémetrie) : Ceilometer est un service de télémétrie centralisé pour OpenStack, qui collecte des données pour des études statistiques dans le cadre de la comptabilité et des analyses comparatives.
  • Trove (base de données en tant que service) : Trove est un composant base de données en tant que service, qui fournit des bases de données relationnelles ou non.
  • Zaqar (messagerie) : le module optionnel Zagar (anciennement Marconi) est une extension d’OpenStack qui fournit aux développeurs une messagerie multi-clients basée dans le cloud. Le programme propose un API REST, grâce auquel les développeurs peuvent envoyer des messages entre différents composants d’un SaaS ou d’une application mobile.
  • Designate (service DNS) : Designate propose un service DNS pour OpenStack. Les données de domaines sont gérées grâce à un API REST. Le module est multi-clients et utilise des fonctions d’authentification via une intégration Keystone.
  • Barbican (outil de gestion): le module Barbican apporte à OpenStack un API REST grâce auquel il est possible de créer, gérer et sauvegarder des mots de passe, des clés et des certificats de façon sécurisée.
  • Sahara (Map reduce élastique) : le composant optionnel Sahara permet aux utilisateurs de créer et de gérer un cluster Hadoop à partir d’OpenStack.
  • Ironic (driver bare metal) : le module additionnel Ironic est une branche de l’installateur bare metal du composant de calcul Nova. Il offre aux utilisateurs d’OpenStack la possibilité de créer des machines bare metal au lieu de machines virtuelles.
  • Murano (catalogue d’applications) : Murano offre aux développeurs et aux administrateurs du Cloud la possibilité de rechercher des applications classées par catégories dans un catalogue. 
  • Manila (système de fichiers partagés) : Manila est un module complémentaire pour OpenStack, qui permet d’étendre l’architecture du système d’exploitation basé sur le cloud par un système de fichiers commun et distribué.
  • Magnum (service de conteneur API) : Magnum est un plugin important, qui permet d’utiliser des outils d’orchestration de conteneurs tels que Docker Swarm, Kubernetes ou Apache Mesos en tant que composants OpenStack.

Grâce à son évolutivité modulaire, OpenStack est devenu l’un des systèmes d’exploitation les plus appréciés pour la construction et l’exploitation de structures open-source basées dans le cloud. Pour les utilisateurs de Docker, le driver docker Nova est une plateforme puissante qui permet de gérer à la fois les conteneurs et les systèmes distribués complexes.

Mesosphere DC/OS

DC/OS (Data Center Operating System) est un programme open-source développé par Mesosphere Inc., qui permet d’exploiter des systèmes distribués. Le projet est basé sur le gestionnaire de clusters open-source Apache Mesos, et constitue un système d’exploitation pour centre de calcul. Le code source soumis à la licence Apache version 2 est en accès libre pour les utilisateurs sur GitHub. Par ailleurs, les développeurs commercialisent une version d’entreprise du programme sur mesosphere.com. La documentation du projet et des guides sont disponibles sur dcos.io.

Il faut considérer que DC/OS est en quelque sorte une distribution de Mesos, qui vous offre toutes les fonctionnalités d’un gestionnaire de clusters à travers une interface utilisateur centrale, et qui complète Mesos grâce à une infrastructure exhaustive et de nombreux composants. Ces derniers rendent l’exploitation des applications bien plus facile sur les systèmes distribués, dans le cloud ou dans les logiciels sur site. La vidéo suivante, créée par l’équipe de développeurs, contient une courte démonstration des fonctions de base de DC/OS :

DC/OS utilise le système distribué de la plateforme Mesos. Ceci permet de regrouper les ressources d’un centre de données entier en paquets, et de les gérer en système agrégé de la même façon qu’un unique système logique. C’est ce qui permet de contrôler des clusters entiers de machines physiques ou virtuelles aussi simplement que si vous opériez sur un seul ordinateur.

Le programme facilite l’installation et l’administration d’applications distribuées et de tâches automatisées telles que la gestion des ressources, l’organisation et la communication entre processus. L’administration d’un cluster basé sur Mesosphere DC/OS  ainsi que l’exploitation de tous les services sont gérés de façon centralisée grâce à un programme de ligne de commande (CLI) ou une interface Web (GUI).

DC/OS abstrait les ressources du cluster et fournit des services partagés comme un service de découverte ou une fonctionnalité de gestion des paquets. Les composants-clés du programme s’exécutent dans un espace protégé, l’espace noyau. Dans cet espace on trouve également les programmes maîtres et agents de la plateforme Mesos, qui sont en charge d’organiser les ressources, d’isoler les processus et d’assurer les fonctions de sécurité.

  • Le maître Mesos : le maître Mesos est un processus maître qui s’exécute sur un nœud maître dans le cluster. La tâche du maître Mesos est de contrôler la gestion des ressources et d’orchestrer les tâches (unités de travail abstraites) qui sont exécutées sur un nœud agent. Le maître Mesos distribue les ressources aux services DC/OS enregistrés, et accepte les rapports de ressources des agents Mesos.
  • Les agents Mesos : les agents Mesos sont des processus esclaves qui s’exécutent sur les comptes agents et sont responsables de l’exécution des tâches distribuées par le maître. Ils fournissent au maître des rapports réguliers sur les ressources disponibles dans le cluster. Ces rapports sont ensuite transférés par le maître à un organisateur (par exemple Marathon, Chronos ou Cassandra), qui décide quelle tâche est exécutée sur quel nœud. Pour réaliser une tâche, les agents Mesos démarrent un processus d’exécution, géré de façon isolée dans un conteneur. La séparation des processus se fait soit via la mémoire d’exécution de Mesos soit par la plateforme de conteneurs Docker.

Tous les autres composants et applications du système fonctionnent grâce à des agents Mesos via Executor dans l’espace utilisateur. Les composants de base d’une installation standard DC/OS sont un routeur administrateur, le DNS Mesos, un DNS proxy distribué, l’équilibreur de charge Minuteman, l’organisateur Marathon, Apache ZooKeeper, et Exhibitor.

  • Le routeur administrateur : il s’agit d’un serveur Web spécialement configuré et basé sur NGINX, qui fournit des services DC/OS tels qu’une authentification centralisée et des fonctionnalités proxy.
  • Le DNS Mesos : le DNS Mesos est un composant du système qui propose des fonctionnalités de découverte de service, ce qui permet à chacun des services et des applications du cluster de s’identifier respectivement grâce à un nom de domaine centralisé (DNS).
  • Le DNS Proxy distribué : il s’agit un DNS distributeur (dispatcher) interne.
  • Minuteman : le composant système Minuteman fonctionne comme un équilibreur de charge interne, qui travaille sur les transports de couche selon le modèle OSI (couche 4).
  • DC/OS Marathon:  Marathon est un composant central de la plateforme Mesos, qui fonctionne dans Mesosphere DC/OS en tant que système init (similaire à systemd). Marathon démarre et contrôle les services et applications DC/OS dans un environnement cluster. De plus, le programme fournit des caractéristiques en haute disponibilité, des services de découverte, un équilibrage des charges, des rapports d’état et une interface Web graphique.
  • Apache ZooKeeper: Apache ZooKeeper est un composant open-source qui offre des fonctionnalités de coordination pour le contrôle et l’exploitation des applications dans les systèmes distribués. Dans le cadre de Mesosphere DC/OS, ZooKeeper est utilisé pour coordonner tous les services installés sur le système.
  • Exhibitor: Exhibitor est un composant du système permettant d’installer et de configurer automatiquement ZooKeeper sur chaque nœud maître du cluster. De plus, Exhibitor fournit une interface graphique aux utilisateurs de ZooKeeper.

Grâce à DC/OS, plusieurs charges de travail peuvent être exécutées simultanément sur les ressources du cluster. Par exemple, le système d’exploitation du cluster permet des opérations parallèles relatives aux systèmes de données, aux micro-services ou aux plateformes de conteneurs telles que Hadoop, Spark et Docker.

Mesosphere Universe met à disposition un catalogue d’applications en libre accès pour DC/OS. C’est grâce à lui que les utilisateurs peuvent installer des applications telles que Spark, Cassandra, Chronos, Jenkins ou Kafka, de façon simple et confortable sur l’interface utilisateur graphique.

Les conteneurs Docker comme composants d’une plateforme d’infrastructure digitale

Docker est parvenu à bousculer toute l’industrie informatique. En consultant les statistiques du projet open-source il semble difficile de concevoir que la plateforme de conteneurs a été lancée seulement le 13 mars 2013, c’est-à-dire il y a quatre ans.

Depuis lors, les utilisateurs de Docker y ont téléchargé plus de 8 milliards d’images conteneur, et près d’un million d’applications Docker sont disponibles dans les registres. Le projet est soutenu par une communauté de développeurs qui compte près de 3000 contributeurs. De nos jours, l’écosystème Docker comprend une large gamme d’outils, d’extensions et de plateformes de programmes qui facilitent considérablement le travail avec les conteneurs Docker. Selon ses propres données, la technologie de conteneurs Docker est actuellement impliquée dans plus de 100 000 projets tiers. Alors qu’en est-il du succès de la plateforme Docker et de ses projets parallèles ?

À l’heure où de plus en plus d’utilisateurs de programmes font appel au cloud, la valeur d’une application augmente proportionnellement à son niveau de connexion et de dissémination. Cette tendance se reflète aussi dans la façon dont un logiciel est développé, testé et exécuté de nos jours. Pour les entreprises, les infrastructures du cloud constituent une façon séduisante de gérer ses ressources informatiques de façon centralisée, et fournissent un accès quel que soit l’endroit où l’on se trouve. Des concepts tels que IaaS (Infrastructure as a service) rendent les processus d’entreprises indépendants de leurs ressources matérielles sur leurs propres serveurs, et offrent un maximum de flexibilité et d’évolutivité grâce à des modèles de facturation à la demande. 

Par ailleurs, les centres de données des grands fournisseurs d’hébergement, opérés par des professionnels, offrent des stratégies en cas de panne de sécurité, une grande disponibilité ainsi qu’un suivi, que les petites et moyennes entreprises peuvent rarement mettre en œuvre elles-mêmes. Ce système compte aussi une technologie de virtualisation légère, qui permet de transférer les applications dans un format portable et indépendant de tout support. Elles peuvent ainsi être distribuées avec une seule ligne de commande dans les infrastructures du cloud et des environnements hybrides. 

Docker se sert de cette tendance des plateformes d’infrastructures numériques en tant qu’infrastructure basée dans le cloud comme peu d’autres technologies. L’écosystème Docker permet de diviser des applications complexes en unités appelées micro-services qui, à travers les API, peuvent être distribués aux différents nœuds d’un cluster. Ceci permet aux entreprises d’assurer plus de flexibilité, mais aussi plus de stabilité. Les applications multi-conteneurs dont les processus s’exécutent sur différents hôtes d’un système distribué peuvent être échelonnées de façon horizontale et intégrer une redondance. La grande indépendance des conteneurs de micro-services encapsulés permet également que les mises à jour et les ajouts d’une application n’affectent que la partie concernée et n’interfèrent jamais avec l’ensemble de l’application. Les erreurs peuvent ainsi être éliminées beaucoup plus facilement.

Les technologies de conteneurs jouent également un rôle essentiel quand il s’agit de basculer des infrastructures traditionnelles vers des plateformes d’infrastructure digitale : c’est surtout la possibilité de grouper les applications, en incluant toutes les dépendances, sur des conteneurs portables et de les distribuer à travers différentes plateformes (déploiement) qui permettent aux administrateurs de transférer des systèmes anciens d’un modèle statique (static IT) à un modèle dynamique (dynamic IT).

Note

les environnements informatiques peuvent être divisés en deux grands espaces au regard de la popularité grandissante des infrastructures basées dans le cloud : le modèle statique inclut des entreprises et des applications backend qui s’exécutent sur une infrastructure traditionnelle, c’est-à-dire sur site ou sur un cloud privé. À mesure que les entreprises créent de nouveaux systèmes et de nouvelles applications, ceux-ci sont de plus en plus déployés sur des infrastructures basées dans le cloud public, ce qui assure davantage d’évolutivité, de flexibilité et d’autonomie par rapport à la localisation géographique. Pour ces systèmes on parle de modèle dynamique.

De plus, l’utilisation d’une plateforme de conteneurs telle que Docker permet d’optimiser ses applications en ce qui concerne la vitesse, la performance et le changement de gestion. Les incertitudes qui demeurent sont celles concernant la sécurité des technologies de conteneurs.

Le déploiement

Une fois que vous avez installé un moteur de conteneur, vous pouvez exécuter des applications basées sur des conteneurs depuis n’importe quel système. Outre le code correspondant à l’application, les conteneurs comportent tous les fichiers binaires et les librairies nécessaires pour exécuter l’application. Ceci permet de simplifier le déploiement, c’est-à-dire la distribution du programme sur différents systèmes, et pas uniquement pour les applications nouvellement créées. En effet la technologie de conteneurs peut aussi être utilisée efficacement pour transférer dans le cloud des applications anciennes ou désuètes mais indispensables au quotidien.

Les composants de softwares anciens sont souvent difficiles à intégrer dans le cloud car ils dépendent de systèmes d’exploitation, de frameworks ou de classes. C’est ici qu’intervient un moteur léger tel que Docker, qui fournit une couche d’abstraction afin de compenser les dépendances du code, sans pour autant forcer un système d’exploitation virtuel.

Vitesse et performance

Lorsque l’on compare une technologie de conteneurs comprenant la plateforme Docker avec du matériel classique de virtualisation via VM, il en ressort des différences claires concernant la vitesse et la performance. 

Puisque les applications encapsulées ont un accès direct au noyau du système hôte, il n’est pas nécessaire de démarrer un système invité pour ce type de virtualisation. Docker utilise un moteur de conteneur léger à la place d’un hyperviseur. De cette façon, on supprime non seulement le temps nécessaire au démarrage de la machine virtuelle, mais on réduit également la consommation de ressources d’un second système d’exploitation. Les applications de conteneurs peuvent être déployées plus rapidement et plus efficacement que des applications basées sur des machines virtuelles. Ceci permet aux administrateurs de démarrer considérablement plus de conteneurs sur un système d’hébergement qu’en hébergeant des systèmes invités sur une plateforme matérielle comparable. Par exemple, si un serveur peut héberger 10 à 100 machines virtuelles, il est possible de faire démarrer plus de 1000 conteneurs.

Par ailleurs, les conteneurs comprenant seulement des fichiers binaires et des librairies en plus du code d’application ont besoin de beaucoup moins d’espace qu’une machine virtuelle, qui inclut l’application et le système d’exploitation.

DevOps et gestion des changements

La numérisation et l’essor de l’Internet mobile ont considérablement accéléré le cycle de vie d’une application. Non seulement il faut fournir le plus vite possible des mises à jour, des extensions et des solutions aux bugs, mais en plus les différentes versions d’une application se succèdent de plus en plus rapidement.

Le déploiement des mises à jour constitue quant à lui un défi pour les développeurs et les administrateurs. Si les entreprises commercialisant des applications souhaitent ajouter rapidement de nouvelles caractéristiques pour leurs clients, les développeurs doivent faire preuve de beaucoup de prudence face aux risques de bugs que les changements d’infrastructures et de composants impliquent. Des solutions stratégiques permettant de parer ces difficultés sont développées autour du mot-clé DevOps. Les DevOpsDays, lancés en 2009, ont permis pour la première fois de discuter de ces thèmes dans le cadre d’une conférence internationale, et d’aborder les questions d’amélioration des procédés et de coopération des services d’informatique et de développement.

L’objectif de DevOps est d‘améliorer la qualité des nouvelles versions des applications, comme la rapidité, la livraison et l’implémentation, à travers une collaboration plus efficace de tous les acteurs et une automatisation croissante. Il est possible d’automatiser les tâches de DevOps grâce aux processus de construction des registres et des analyses de code statique et dynamique tels que des modules, des systèmes d’intégrations et des tests de performance. L’intégration continue (CI) et la livraison continue (CD), deux champs d’application essentiels de Docker, sont au cœur de l’approche de DevOps.

Note

la livraison continue est une approche permettant d’optimiser la livraison des applications en utilisant divers outils et techniques. Elle s’appuie essentiellement sur l’automatisation du pipeline de déploiement.

Docker offre des solutions d‘intégration pour des outils CI/CD bien établis, tels que Jenkins, Travis ou Drone, et permet de télécharger automatiquement le code à partir du hub Docker ou de registres de versions de contrôle comme GitHub, GitLab ou Bitbucket. La plateforme de conteneurs constitue une base pour le flux de travail sur DevOps, dans laquelle les développeurs peuvent travailler ensemble pour créer de nouveaux composants d’applications ainsi qu’un environnement de tests.

Par ailleurs, Docker est également compatible avec des systèmes d’exploitation sur site ou basés dans le cloud, des environnements virtuels ainsi que diverses distributions. Une architecture CI/CD basée sur Docker présente enfin un avantage essentiel, puisque les entreprises ne sont plus freinées par des incohérences dues à des environnements informatiques différents.

Sécurité

Même si les processus encapsulés s’exécutent sur le même noyau, Docker utilise toute une gamme de techniques d’isolation pour les protéger les uns des autres. L’accent est mis sur des fonctions du noyau Linux, tel que Cgroups et Namespaces. Chaque conteneur dispose de son propre nom, ses propres identifiants de processus, et sa propre interface réseau. De plus, chaque conteneur voit seulement la partie du fichier qui lui est assignée. Les ressources système telles que la mémoire, le processeur et la bande passante sont distribués grâce à un mécanisme Cgroup. Celui-ci s’assure que chaque conteneur puisse seulement prétendre à la partie qui lui est due.

Toutefois, les conteneurs n’offrent pas le même niveau d’isolation que les machines virtuelles. Si un attaquant rencontre une machine virtuelle, il a peu de chance d’interagir avec le noyau du système d’hébergement sous-jacent. Les conteneurs, en tant qu’unités encapsulées d’un noyau hébergeur commun, laissent beaucoup plus de liberté aux attaquants.

En dépit des techniques d’isolation décrites, d’importants sous-systèmes de noyaux, tels que les Cgroups et les interfaces de noyaux en /sys et /proc dans les registres peuvent être obtenus à partir des conteneurs. Ceci permet aux attaquants de surmonter les barrières de sécurité de l’hébergeur. De plus, tous les conteneurs tournent sur un système d‘hébergement dans le même espace de nom. Par conséquent, un conteneur qui bénéficie de privilèges root les retient même lorsqu’il interagit avec le noyau hébergeur.

Le démon Docker, qui est responsable de la gestion des conteneurs sur le système d’hébergement, dispose également de privilèges root. Un utilisateur qui a accès au démon Docker accède automatiquement à tous les registres accessibles par ce démon, et est également capable de communiquer en HTTP via un API REST. Par conséquent, la documentation Docker recommande d’autoriser uniquement les utilisateurs de confiance à accéder au démon. 

L’équipe de développement de Docker a admis que ces failles de sécurité constituent un frein à l’établissement des technologies de conteneurs sur les systèmes de production. Outre les techniques d’isolation basiques du noyau Linux, les nouvelles versions du moteur Docker sont donc compatibles avec les frameworks AppArmor, SELinux et Seccomp, qui agissent comme une sorte de pare-feu pour les ressources du noyau. 

  • AppArmor : AppArmor peut être utilisé pour réguler les droits d‘accès des conteneurs au fichier système.
  • SELinux : SELinux propose un système de règles complexe, pouvant être utilisé pour l’implémentation des contrôles d’accès aux ressources du noyau.
  • Seccomp : Seccomp (Secure Computing Mode) permet d’activer et de contrôler Systemcalls.

Docker utilise en outre les capacités de Linux, qui peuvent servir à restreindre les privilèges root avec lesquels le moteur Docker démarre les conteneurs.

Il existe d’autres problèmes de sécurité, relatifs à la vulnérabilité de l’application dans le cadre de la distribution des composants à travers le registre Docker. Puisqu’en principe chacun peut créer des images Docker et les rendre accessibles à la communauté grâce au Docker hub, il existe un danger d’intégrer, à travers ces images, du code malveillant qui endommagerait le système. Les utilisateurs de Docker doivent donc s’assurer, avant de déployer une application, que l’intégralité du code fourni avec une image provient d’une source sûre. Avec son édition d’entreprise (EE), Docker offre depuis début 2017 un programme de certification, grâce à laquelle les fournisseurs d’infrastructures, de conteneurs et de plugins peuvent tester et récompenser votre application. Pour obtenir le certificat, il faut remplir les conditions suivantes : 

  • Certification d’infrastructure : les développeurs d’applications qui souhaitent fournir des composants d’infrastructure certifiés pour l’écosystème Docker doivent prouver, grâce aux tests adaptés, que leur produit est optimisé pour un travail en équipe sur la plateforme Docker.
  • Certification de conteneur : un conteneur reçoit la certification officielle de Docker uniquement s’il a été conçu selon les meilleures méthodes et a réussi tous les tests de vulnérabilité et de sécurité.
  • Plugins : un plugin pour Docker EE n’est éligible au certificat Docker que s’il a été développé selon les meilleurs pratiques et a réussi les tests de conformité API et de vulnérabilité.

Les certificats Docker sont conçus pour renforcer la sécurité des utilisateurs, et offrent aux développeurs la possibilité de faire remarquer leur projet parmi la multitude de ressources disponibles sur le marché.

Conclusion : Docker est-il sécurisé ?

La technologie de conteneurs est une alternative à la virtualisation matérielle traditionnelle, qui permet d’économiser des ressources. Elle est particulièrement adaptée à des entreprises qui ont besoin de créer des applications Web interactives ou de gérer un grand nombre de données. Une augmentation de la demande est prévue pour les prochaines années, en particulier dans le domaine du commerce en ligne. Si les leaders du secteur, tels qu’eBay et Amazon, ont déjà adopté la technologie de conteneurs qui fait maintenant partie de leur équipement standard, les plus petites entreprises de commerce en ligne vont progressivement devoir s’aligner.

Pour l’heure, l’entreprise Docker est encore jeune mais s’est déjà fait une réputation de choix dans le secteur des systèmes de virtualisation. Ce succès s’explique par ses concepts open-source et ses efforts pour standardiser ses offres en l’espace de seulement quelques années. Toutefois, il existe déjà une forte concurrence dans le secteur des technologies de conteneurs. La compétition qui s’intensifie entraîne une innovation rapide et permet aux utilisateurs de bénéficier de solutions et d’outils performants.

Par le passé, les questions de sécurité ont constitué un obstacle majeur au développement des technologies de conteneurs. Le défi majeur pour les développeurs de techniques de virtualisation basées sur les conteneurs consiste à améliorer les procédés d’isolation du noyau Linux. Ce domaine a connu plusieurs progrès ces dernières années, notamment grâce à des projets comme SELinux, AppArmor ou Seccomp.

En observant le taux d’assimilation élevé des conteneurs, il semble probable que la virtualisation basée sur les systèmes d’exploitation va s’imposer comme une alternative aux machines virtuelles à long terme. Le projet Docker et son écosystème en pleine croissance offrent aux entreprises une solution particulièrement sûre pour développer et gérer leurs activités grâce aux technologies de conteneurs.