Tools Docker : aperçu des outils de l’écosystème Docker

Le vaste écosystème Docker offre aux développeurs de nombreuses possibilités de déployer leurs applications, d’orchestrer des conteneurs et bien plus encore. Nous vous présentons les principaux tools Docker, ainsi qu’un aperçu de projets populaires dans lesquels des outils Docker sont développés sur une base open source.

Tools Docker : les outils et composants Docker les plus essentiels¶

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. Le client et le démon peuvent éventuellement se trouver sur des systèmes différents. Vous trouverez un aperçu des principales commandes Docker dans notre article complémentaire.

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. 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 in memory 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.

Docker Swarm¶

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.

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. De plus, 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 nodes) 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¶

Docker Compose vous permet de relier plusieurs conteneurs et de les contrôler grâce à une seule commande. 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.

Tools Docker : les outils 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 D2iQ 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 est le projet open source Kubernetes.

Kubernetes est un gestionnaire de cluster pour les applications basées sur conteneurs.

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.
• kube-proxy : 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, et également 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.

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 Shipyard“).

Panamax¶

L’équipe de 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.

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. Le client Panamax est ensuite exécuté en tant que client du conteneur Docker à travers CoreOS. 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 : le 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. L’outil Docker permet de charger automatiquement la dernière version depuis un dépôt Git comme GitHub et de l’exécuter dans des conteneurs Docker isolés à des fins de test.

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.

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.

Drone offre aux utilisateurs une solution CI open source qui combine les avantages de produits tels que 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, le système d’exploitation open source basé dans le Cloud OpenStack est une solution de premier choix.

OpenStack permet de gérer les ressources de calcul, de stockage et de réseau dans un data center via un tableau de bord central et de les mettre à la disposition des utilisateurs finaux via une interface Web.

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

• Zun (service de conteneurs) : Zun est le service de conteneurs d’OpenStack qui permet de déployer et de gérer facilement des applications containerisées dans le Cloud OpenStack. L’objectif de Zun est de permettre aux utilisateurs de gérer des conteneurs via une API REST, sans avoir à gérer de serveurs ou de clusters. Zun nécessite trois autres services OpenStack pour fonctionner : Keystone, Neutron et kuryr-libnetwork. En option, la fonctionnalité de Zun peut être étendue par d’autres services OpenStack tels que Cinder et Glance.
• 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.
• kuryr-libnetwork (pilote Docker) : kuryr-libnetwork est un pilote pour Docker qui fait office d’interface entre Docker et Neutron.
• 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.
• 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.
• Glance (Image-Service) : le module Glance est un service d’OpenStack qui permet de stocker et de transférer les images des machines virtuelles.

Pour plus d’informations sur les composants ou les services OpenStack, consultez notre article complémentaire sur OpenStack.

Outre les composants de base, l’architecture OpenStack peut être complétée par différents modules et extensions. Pour plus de détails, consultez le site Web OpenStack.

D2iQ DC/OS¶

DC/OS (Distributed Cloud Operating System) est un programme open source développé par D2iQ Inc. (auparavant Mesophere), 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 d2iq.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.

DC/OS utilise le système distribué de la plateforme Mesos. Ceci permet de regrouper les ressources d’un data center 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 D2iQ DC/OS ainsi que l’exploitation de tous les services sont gérées 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 ont la 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. Les tâches sont exécutées de manière isolée dans un conteneur.

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.

D2iQ 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.

Tools Docker : les outils pour la 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.

Toutefois, les conteneurs n’offrent pas le même niveau d’isolation que les machines virtuelles.

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.

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.

Au-delà de ces outils, 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.

Docker propose à cet effet un programme de certification, grâce auquel les fournisseurs de logiciels peuvent faire vérifier et marquer leurs images Docker. Avec ce programme de certification, Docker veut faciliter aux développeurs la mise en place de chaînes d’approvisionnement logicielles sûres pour leurs projets. En plus d’un gain de sécurité pour les utilisateurs, le programme permet également aux développeurs de logiciels de se démarquer parmi les nombreuses ressources disponibles. Les images certifiées obtiennent un meilleur classement dans les résultats de recherche de Docker Hub et sont signalées par un badge Verified Publisher.