Tools Docker : aperçu des outils de l’éco­sys­tème Docker

Le vaste éco­sys­tème Docker offre aux dé­ve­lop­peurs de nom­breuses pos­si­bi­li­tés de déployer leurs ap­pli­ca­tions, d’or­ches­trer des con­te­neurs et bien plus encore. Nous vous pré­sen­tons les prin­ci­paux tools Docker, ainsi qu’un aperçu de projets po­pu­laires dans lesquels des outils Docker sont dé­ve­lop­pés sur une base open source.

Tools Docker : les outils et com­po­sants Docker les plus es­sen­tiels

Docker est aujourd’hui bien plus qu’une simple pla­te­forme pour l’ex­ploi­ta­tion de pro­grammes basés sur des con­te­neurs. Pour sim­pli­fier le dé­ploie­ment des ap­pli­ca­tions vers des in­fras­truc­tures dis­tri­buées et des en­vi­ron­ne­ments Cloud, l’équipe de dé­ve­lop­peurs au cœur du programme y a ajouté plusieurs ex­ten­sions et services en ligne. Outre la gestion des clusters et l’or­ches­tra­tion, ils proposent aux uti­li­sa­teurs une pla­te­forme com­mer­ciale cen­tra­li­sée et un outil de gestion des res­sources du Cloud.

Le moteur Docker

Lorsque les uti­li­sa­teurs parlent de Docker, il s’agit en général de l’ap­pli­ca­tion client-serveur open source, qui constitue la base de la pla­te­forme de conteneur. Dans la ter­mi­no­lo­gie Docker, ceci est com­mu­né­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 uti­li­sa­teur. Cette cons­truc­tion vous permet de traiter avec le moteur grâce à la ligne de commande et de gérer fa­ci­le­ment les images, les fichiers Docker et les con­te­neurs depuis le terminal. Le client et le démon peuvent éven­tuel­le­ment se trouver sur des systèmes dif­fé­rents. Vous trouverez un aperçu des prin­ci­pales commandes Docker dans notre article com­plé­men­taire.

Le Docker Hub

Avec le Docker Hub, le projet open source fournit aux uti­li­sa­teurs un registre basé sur le Cloud qui permet de té­lé­char­ger des images Docker, mais aussi de les gérer de façon cen­tra­li­sée et de les partager avec d’autres uti­li­sa­teurs de Docker, de façon publique ou grâce à des registres privés. Pour partager des images, il est né­ces­saire 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 uti­li­sa­teurs, vous trouverez sur le hub de nom­breuses res­sources cor­res­pon­dant aux images d’archives of­fi­cielles de l’équipe de dé­ve­lop­peurs et de célèbres projets open source. Les images les plus po­pu­laires 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 dis­tri­bu­tion Linux Ubuntu.

Le Docker hub présente également une autre fonc­tion­na­lité, appelée « Or­ga­ni­za­tions » : ce sont des groupes de travail qui per­met­tent aux uti­li­sa­teurs de la pla­te­forme de con­te­neurs de créer des registres privés seulement ac­ces­sibles à 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’or­ches­tra­tion 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 fonc­tionne avec le Docker REST API. Par con­sé­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, dis­tri­buer les ap­pli­ca­tions dans le cluster et contrôler le com­por­te­ment du groupe, les uti­li­sa­teurs ont recours au moteur Docker CLI. Aucun programme d’or­ches­tra­tion sup­plé­men­taire n’est né­ces­saire.

Les moteurs Docker, qui ont été regroupés en cluster, fonc­tion­nent en mode Swarm. C’est celui qu’il faut sé­lec­tion­ner pour créer un nouveau cluster ou ajouter un hôte Docker à un cluster déjà existant. Chaque hôte Docker in­di­vi­duel est appelé un « nœud ». Les nœuds d’un cluster peuvent fonc­tion­ner 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 in­di­vi­duels de chaque cluster sont dis­tri­bués à travers dif­fé­rents systèmes et in­fras­truc­tures.

Le programme repose sur une ar­chi­tec­ture maître-esclave. Si les tâches doivent être dis­tri­buées dans le cluster, les uti­li­sa­teurs ont recours à un service de gestion des nœuds, qui se comporte comme le maître du cluster. Ce maître est res­pon­sable de l’or­ga­ni­sa­tion des con­te­neurs dans le cluster, et sert de première interface uti­li­sa­teur pour accéder aux autres res­sources du cluster.

Le nœud maître envoie des actions à accomplir, appelées tâches (task), aux esclaves qui lui sont su­bor­don­nés, appelés nœuds esclaves (worker nodes) dans la ter­mi­no­lo­gie Docker.

• Services : les services cons­ti­tuent la structure centrale des clusters dans Docker. Un service est un groupe de con­te­neurs basés dans la même image. Un service définit les tâches qui sont exécutées dans le cluster. L’uti­li­sa­teur qui crée un service spécifie quelles images et quelles commandes doivent être utilisées. De plus, les services per­met­tent d’éche­lon­ner les ap­pli­ca­tions. Les uti­li­sa­teurs de la pla­te­forme Docker dé­ter­mi­nent sim­ple­ment combien de con­te­neurs doivent démarrer pour un service.
• Tâches : pour pouvoir être dis­tri­bués dans le cluster, les services sont divisés en tâches de travail in­di­vi­duelles par le nœud maître.

En plus de gérer le cluster et l’or­ches­tra­tion des con­te­neurs, le nœud maître (manager nodes) fournit également aux nœuds esclaves des fonc­tion­na­li­tés par défaut, sauf si l’on décide de res­treindre ses at­tri­bu­tions aux tâches de gestion.

Un programme agent fonc­tionne sur chaque nœud worker. Celui-ci accepte les tâches et délivre des rapports aux nœuds maîtres res­pec­tifs à propos de l’état de pro­gres­sion de la tâche en cours. Le graphique ci-dessous propose une ex­pli­ca­tion sché­ma­tique de la structure d’un cluster Docker :

Pour la mise en œuvre d’un cluster Docker, les uti­li­sa­teurs ont en général recours à la machine Docker.

Docker Compose

Docker Compose vous permet de relier plusieurs con­te­neurs 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 pro­gram­ma­tion YAML. La syntaxe des fichiers Compose est similaire à celle du logiciel open source Vagrant, utilisé pour créer et ap­pro­vi­sion­ner des machines vir­tuelles. Dans le fichier docker-compose.yml, vous pouvez définir le nombre de pro­grammes de con­te­neurs, y compris les dé­pen­dances, ainsi que leurs in­te­rac­tions. Les ap­pli­ca­tions multi-con­te­neurs de ce type sont con­trô­lées selon le même schéma que les con­te­neurs in­di­vi­duels. Pour gérer le cycle de vie d’une ap­pli­ca­tion dans son ensemble, il suffit d’utiliser la commande Compose de Docker ainsi que la commande su­bor­don­née cor­res­pon­dante.

L’outil Docker est facile à intégrer sur un cluster basé sur Swarm. Ceci vous permet d’exploiter très fa­ci­le­ment des ap­pli­ca­tions multi-con­te­neurs créées avec Compose, aussi bien sur des systèmes dis­tri­bués que sur un hôte Docker in­di­vi­duel.

Docker Compose présente une autre ca­rac­té­ris­tique in­té­res­sante, un mécanisme d’ex­ten­si­bi­lité intégré. Grâce à l’outil d’or­ches­tra­tion, vous pouvez fa­ci­le­ment choisir combien de con­te­neurs vous souhaitez démarrer pour un service en par­ti­cu­lier, en utilisant une seule ligne de commande.

Tools Docker : les outils des four­nis­seurs ex­té­rieurs

Outre les propres ex­ten­sions de Docker Inc., il existe de nombreux pro­grammes et pla­te­formes de four­nis­seurs ex­té­rieurs, dis­po­nibles pour les in­ter­faces des moteurs Docker ou dé­ve­lop­pés spé­ci­fi­que­ment pour la pla­te­forme de con­te­neurs. Parmi les projets open source les plus po­pu­laires de l’éco­sys­tème Docker, on compte l’outil d’or­ches­tra­tion Ku­ber­netes, l’outil de gestion des clusters Shipyard, la solution d’envoi multi-con­te­neurs Panamax, la pla­te­forme d’in­té­gra­tion continue Drone, le système d’ex­ploi­ta­tion basé sur le Cloud OpenStack, et le système d’ex­ploi­ta­tion D2iQ DC/OS basé sur le ges­tion­naire de clusters Mesos.

Ku­ber­netes

Docker n’a pas toujours disposé de ses propres outils d’or­ches­tra­tion tels que Swarm et Compose. Pour cette raison, de nom­breuses en­tre­prises ont investi depuis plusieurs années dans des outils de dé­ve­lop­pe­ment conçus sur mesure pour faciliter l’ex­ploi­ta­tion de la pla­te­forme de con­te­neurs sur de grandes in­fras­truc­tures dis­tri­buées. L’une des solutions de ce type les plus célèbres est le projet open source Ku­ber­netes.

Ku­ber­netes est un ges­tion­naire de cluster pour les ap­pli­ca­tions basées sur con­te­neurs.

L’objectif de Ku­ber­netes est d’au­to­ma­ti­ser les ap­pli­ca­tions dans le cluster. L’outil d’or­ches­tra­tion 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 au­to­ma­tismes et de demander des rapports d’exécution. Les uti­li­sa­teurs ont recours à Ku­ber­netes pour les raisons suivantes :

• exploiter des ap­pli­ca­tions basées sur des con­te­neurs dans un cluster
• établir et gérer des ap­pli­ca­tions dans des systèmes dis­tri­bués
• rendre des ap­pli­ca­tions évo­lu­tives
• utiliser le matériel dis­po­nible de la meilleure façon possible

Pour ce faire, Ku­ber­netes rassemble les con­te­neurs en parts logiques, que l’on appelle des pods. Les pods re­pré­sen­tent les unités de base du ges­tion­naire de cluster, qui peuvent être dis­tri­buées dans le cluster selon un plan d’or­ga­ni­sa­tion.

Tout comme le Swarm de Docker, Ku­ber­netes est basé sur une ar­chi­tec­ture maître-esclave. Un cluster est composé du maître Ku­ber­netes, ainsi que de plusieurs esclaves, qui sont appelés les nœuds Ku­ber­netes (parfois également workers ou minions). Le maître Ku­ber­netes se comporte dans le cluster comme l’unité de contrôle centrale (control plane). Il est composé de quatre éléments es­sen­tiels, qui per­met­tent de contrôler la com­mu­ni­ca­tion entre le cluster et les tâches dis­tri­buées. Un maître Ku­ber­netes est constitué d’un serveur API, une mémoire de con­fi­gu­ra­tion etcd, un or­ga­ni­seur et un ges­tion­naire de contrôle.

• Serveur API : tous les au­to­ma­tismes d’un cluster Ku­ber­netes sont activés par un serveur API via REST API. Ceci fonc­tionne comme l’interface d’ad­mi­nis­tra­tion centrale du cluster.
• etcd : la mémoire de con­fi­gu­ra­tion open source etcd cor­res­pond à la mémoire du cluster. Le Key value Store, développé par CoreOS spé­cia­le­ment pour les systèmes dis­tri­bués, sau­ve­garde les données de con­fi­gu­ra­tion et les met à dis­po­si­tion de chaque nœud du cluster.
• Or­ga­ni­seur : l’or­ga­ni­seur est res­pon­sable de la dis­tri­bu­tion des groupes de con­te­neurs (les pods) dans le cluster. Pour ce faire, il détermine les res­sources dont ont besoin les pods, et attribue les res­sources dis­po­nibles à chaque nœud du cluster.
• Ges­tion­naire de contrôle : le ges­tion­naire de contrôle est un service du maître Ku­ber­netes, qui régit l’état du cluster, des tâches de routine et donc l’or­ches­tra­tion. La tâche prin­ci­pale du ges­tion­naire de contrôle est de s’assurer que l’état du cluster cor­res­ponde à l’état défini dans les objectifs.

Tous les com­po­sants du maître Ku­ber­netes peuvent être hébergés sur un seul et même hôte, ou dis­tri­bués sur plusieurs hôtes maîtres dans le cadre d’un cluster haute dis­po­ni­bi­lité.

Si le maître Ku­ber­netes est res­pon­sable de l’or­ches­tra­tion, les pods dis­tri­bués dans le cluster sont exécutés sur les hôtes, c’est-à-dire les nœuds Ku­ber­netes, qui sont su­bor­don­nés au maître. C’est la raison pour laquelle un moteur de conteneur doit être exécuté sur chaque nœud Ku­ber­netes. Docker est par­fai­te­ment adapté à cette fin, même si Ku­ber­netes n’est défini par aucun moteur de conteneur en par­ti­cu­lier.

Outre le moteur de con­te­neurs, les nœuds Ku­ber­netes com­pren­nent les com­po­sants suivants :

• kubelet : kubelet est un agent qui est exécuté sur chaque nœud Ku­ber­netes 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 Ku­ber­netes, et s’assure que les in­for­ma­tions soient bien trans­mises au centre de contrôle.
• kube-proxy : chaque nœud Ku­ber­netes exécute également un service proxy, kube-proxy. Celui-ci s’assure que les requêtes sont trans­mises depuis l’extérieur vers les con­te­neurs res­pec­tifs, et fournit aux uti­li­sa­teurs les services d’ap­pli­ca­tions basées sur des con­te­neurs. kube-proxy offre en outre une forme basique de load-balancing.

Le schéma ci-dessous re­pré­sente l’ar­chi­tec­ture maître-esclave sur laquelle est basée la pla­te­forme d’or­ches­tra­tion Ku­ber­netes.

Outre le projet central Ku­ber­netes, il existe de nombreux outils et ex­ten­sions qui per­met­tent, grâce à des fonc­tion­na­li­tés sup­plé­men­taires, de mieux ap­pré­hen­der la pla­te­forme d’or­ches­tra­tion. Parmi les plus connus, on compte l’outil de sur­veil­lance et de diag­nos­tic des erreurs Pro­me­theus, Weave Scope et Sysdig, ainsi que le ges­tion­naire de paquets Helm. Par ailleurs, il existe des plugins pour Apache Maven et Gradle, et également un API Java pour le contrôle de Ku­ber­netes à distance.

Shipyard

Shipyard est une solution de gestion basée sur Swarm et dé­ve­lop­pée par la com­mu­nauté d’uti­li­sa­teurs de Docker. Grâce à une interface uti­li­sa­teur graphique, elle permet aux uti­li­sa­teurs de gérer les res­sources de Docker, comme les con­te­neurs, les images, les hôtes, et les registres privés. Cet outil est dis­po­nible en tant qu’ap­pli­ca­tion Web dans un na­vi­ga­teur.

Le programme est en­tiè­re­ment com­pa­tible avec Docker à distance, API, et utilise la base de données open source NoSQL RethinkDB pour le stockage des données des comptes uti­li­sa­teurs, les adresses et les évè­ne­ments.

Outre la gestion du cluster grâce à son interface centrale, Shipyard offre aux uti­li­sa­teurs la pos­si­bi­lité de s’iden­ti­fier ainsi qu’un accès de contrôle basé sur la dis­tri­bu­tion des rôles.

Le programme est basé sur l’outil de gestion des clusters Citadel, et il est formé de trois com­po­sants es­sen­tiels : Con­trol­ler, API et UI.

• Shipyard Con­trol­ler : le con­trô­leur est le composant-clé de l’outil de gestion Shipyard. Il interagit avec le Rethink DB dans le cadre de la sau­ve­garde 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 fonc­tion­na­li­tés de l’outil de gestion sont con­trô­lées depuis l’API Shipyard.
• Shipyard User Interface (UI) : l’interface uti­li­sa­teur UI Shipyard est une ap­pli­ca­tion AngularJS. Elle offre aux uti­li­sa­teurs une interface graphique pour gérer les clusters Docker dans un na­vi­ga­teur Web. Toutes les in­te­rac­tions avec l’interface sont conduites par l’API Shipyard.

Plus d’in­for­ma­tions sont dis­po­nibles sur le site officiel du projet open source Shipyard“).

Panamax

L’équipe de dé­ve­lop­peurs du programme open source Panamax se sont fixés pour objectif de sim­pli­fier la mise à dis­po­si­tion des ap­pli­ca­tions multi-con­te­neurs. L’outil gratuit comprend une interface uti­li­sa­teur graphique, grâce à laquelle des ap­pli­ca­tions complexes basées sur Docker peuvent être dé­ve­lop­pées, déployées et dis­tri­buées par un simple glisser-déposer.

Panamax permet de sau­ve­gar­der des ap­pli­ca­tions multi-con­te­neurs complexes grâce à des templates d’ap­pli­ca­tion, et de les dis­tri­buer dans les ar­chi­tec­tures clusters d’un simple clic. Avec une ap­pli­ca­tion mar­ket­place intégrée et hébergée sur GitHub, il est possible de sau­ve­gar­der dans Git des templates pour des ap­pli­ca­tions per­son­na­li­sées, qui peuvent ensuite être dis­po­nibles pour d’autres uti­li­sa­teurs.

Les com­po­sants de base de l’ar­chi­tec­ture de Panamax se divisent en deux groupes : le client local Panamax et un grand nombre de cibles de dé­ploie­ment à 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 ap­pli­ca­tions complexes basées sur des con­te­neurs. Il est constitué des com­po­sants suivants :

• CoreOS : l’ins­tal­la­tion du client local Panamax requiert une dis­tri­bu­tion Linux CoreOS, spé­cia­le­ment conçue pour l’hé­ber­ge­ment des pro­grammes de con­te­neurs. Le client Panamax est ensuite exécuté en tant que client du conteneur Docker à travers CoreOS. Outre les fonc­tion­na­li­tés spé­ci­fiques à Docker, Panamax propose aux uti­li­sa­teurs plusieurs fonctions CoreOS. On compte notamment parmi elles Fleet et Jour­nalctl :

  • Fleet : au lieu d’interagir di­rec­te­ment avec Docker, le client Panamax utilise le ges­tion­naire de clusters Fleet pour or­ches­trer les con­te­neurs. Fleet est un ges­tion­naire qui contrôle le systemd du démon Linux.
  • Jour­nalctl : le client Panamax utilise Jour­nalctl pour extraire des messages depuis le ges­tion­naire de système Linux systemd vers le journal.

• Local client installer : le programme d’ins­tal­la­tion du client local comprend tous les com­po­sants né­ces­saires à l’ins­tal­la­tion 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 com­po­sants et dé­pen­dances. 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é­ploie­ment dans le cluster. L’agent local interagit avec l’API Panamax sur le système local pour échanger des in­for­ma­tions à propos des ap­pli­ca­tions en cours d’exécution, grâce aux in­ter­faces de pro­gram­ma­tion suivantes :

  • Docker-Remote-API : grâce à Docker-Remote-API, Panamax recherche des images et des systèmes locaux, et extrait des in­for­ma­tions con­cer­nant le statut des con­te­neurs en cours d’exécution.
  • etcd-API : avec l’API etcd, les données sont trans­fé­rées au démon Fleet CoreOS.
  • systemd-journal-gatewayd.services : grâce au systemd-journal-gatewayd.services, Panamax transfère les pro­duc­tions du journal aux dif­fé­rents services en cours d’exécution.

De plus, l’API Panamax permet des in­te­rac­tions 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é­char­gés dans les registres GitHub.
• Kiss­Me­trics-API : les API Kiss­Me­trics col­lec­tent des données sur les templates que les uti­li­sa­teurs exécutent.
• Panamax-UI : l’UI Panamax agit comme l’interface uti­li­sa­teur sur le système local et permet à l’uti­li­sa­teur de contrôler l’outil Docker grâce à une interface uti­li­sa­teur graphique. À travers l’API Panamax, les données de l’uti­li­sa­teur sont trans­fé­rées di­rec­te­ment à l’agent local. L’UI Panama est basé sur le kit CTL UI, une bi­blio­thèque contenant des com­po­sants UI pour les projets Web Cen­tu­ry­Link.

Dans la ter­mi­no­lo­gie Panamax, chaque nœud d’un cluster Docker auquel n’est attribuée aucune tâche de gestion est appelé une cible de dé­ploie­ment à distance (remote de­ploy­ment target). Les cibles de dé­ploie­ment sont composées d’un hôte Docker configuré pour déployer des templates Panamax en utilisant les com­po­sants suivants :

• De­ploy­ment-Target-Installer : l’ins­tal­la­teur de cible de dé­ploie­ment démarre un hôte Docker en utilisant un agent à distance Panamax et un adap­ta­teur d’or­ches­tra­tion.
• Panamax-Remote-Agent : lorsque l’agent à distance Panamax est installé, les ap­pli­ca­tions peuvent être dis­tri­bué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é­ploie­ment dans le cluster.
• Panamax-Or­ches­tra­tion-Adapter : l’adap­ta­teur d’or­ches­tra­tion fournit une logique de programme à chaque outil d’or­ches­tra­tion dis­po­nible pour Panamax dans une couche in­dé­pen­dante d’adap­ta­teur. Ceci permet aux uti­li­sa­teurs de sé­lec­tion­ner pré­ci­sé­ment la tech­no­lo­gie d’or­ches­tra­tion com­pa­tible avec l’en­vi­ron­ne­ment de leur cible. Les adap­ta­teurs pré­con­fi­gu­rés incluent Ku­ber­netes et Fleet :
  • Panamax-Ku­ber­netes-Adapter : en com­bi­nai­son avec l’agent à distance Panamax, l’adap­ta­teur Panamax Ku­ber­netes permet de partager des templates Panamax dans le cluster Ku­ber­netes.
  • Panamax-Fleet-Adapter : en com­bi­nai­son avec l’agent à distance Panamax, l’adap­ta­teur Panamax Fleet permet de partager des templates Panamax dans le cluster, contrôlés grâce au ges­tion­naire 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 con­te­neurs basé sur CoreOS, propose aux uti­li­sa­teurs plusieurs tech­no­lo­gies standard pour l’or­ches­tra­tion de con­te­neurs grâce à une interface uti­li­sa­teur graphique, ainsi que l’option con­for­table de créer des ap­pli­ca­tions multi-con­te­neurs dans une ar­chi­tec­ture de clusters grâce à n’importe quel système, y compris leur propre or­di­na­teur.

Avec le public template re­po­si­tory, Panamax offre aux uti­li­sa­teurs, via GitHub, un accès libre et gratuit à une bi­blio­thèque de templates et de nom­breuses autres res­sources.

Drone

Drone est une pla­te­forme d’in­té­gra­tion continue légère et peu exigeante. L’outil Docker permet de charger au­to­ma­ti­que­ment la dernière version depuis un dépôt Git comme GitHub et de l’exécuter dans des con­te­neurs Docker isolés à des fins de test.

Il est possible d’effectuer toutes sortes de tests et d’envoyer des rapports et in­for­ma­tions de statut par email. Pour chaque test de programme, un nouveau conteneur basé sur une image du registre public Docker est créé. Par con­sé­quent, toute image dis­po­nible pu­bli­que­ment sur Docker peut être utilisée comme en­vi­ron­ne­ment du code à tester.

Drone est intégré à Docker et com­pa­tible avec plusieurs langages de pro­gram­ma­tion tels que PHP, Node.js, Ruby, Go ou Python. La pla­te­forme de con­te­neurs est conçue pour être la seule dé­pen­dance. Avec Drone, vous pouvez installer votre propre pla­te­forme d’in­té­gra­tion continue sur n’importe quel système com­pa­tible avec Docker. Drone est com­pa­tible avec plusieurs registres de contrôle de version. Vous trouverez un guide pour une ins­tal­la­tion standard et l’in­té­gra­tion GitHub dans la do­cu­men­ta­tion du projet open source readme.drone.io.

La pla­te­forme d’in­té­gra­tion continue est contrôlée grâce à une interface Web, à partir de laquelle il est possible de té­lé­char­ger les builds depuis n’importe quel registre Git, d’ajouter des ap­pli­ca­tions et d’effectuer des tests dans un en­vi­ron­ne­ment 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’ap­pli­ca­tion.

Drone offre aux uti­li­sa­teurs une solution CI open source qui combine les avantages de produits tels que Travis et Jenkins dans une interface uti­li­sa­teur con­vi­viale.

OpenStack

Lorsqu’il s’agit de cons­truire et d’exécuter des struc­tures open source basées dans le Cloud, le système d’ex­ploi­ta­tion open source basé dans le Cloud OpenStack est une solution de premier choix.

OpenStack permet de gérer les res­sources de calcul, de stockage et de réseau dans un data center via un tableau de bord central et de les mettre à la dis­po­si­tion des uti­li­sa­teurs finaux via une interface Web.

Le système d’ex­ploi­ta­tion basé dans le Cloud est construit selon une ar­chi­tec­ture modulaire. Il est composé de plusieurs com­po­sants es­sen­tiels :

• Zun (service de con­te­neurs) : Zun est le service de con­te­neurs d’OpenStack qui permet de déployer et de gérer fa­ci­le­ment des ap­pli­ca­tions con­tai­ne­ri­sées dans le Cloud OpenStack. L’objectif de Zun est de permettre aux uti­li­sa­teurs de gérer des con­te­neurs via une API REST, sans avoir à gérer de serveurs ou de clusters. Zun nécessite trois autres services OpenStack pour fonc­tion­ner : Keystone, Neutron et kuryr-lib­net­work. En option, la fonc­tion­na­lité de Zun peut être étendue par d’autres services OpenStack tels que Cinder et Glance.
• Neutron (composant de réseau) : Neutron (an­cien­ne­ment Quantum) est un composant de système portable, évolutif et basé sur API, utilisé par le con­trô­leur de réseau. Le module fournit une interface pour les to­po­lo­gies de réseaux complexes, et il est com­pa­tible avec de nombreux plugins, qui peuvent être utilisés pour intégrer des fonctions réseaux avancées.
• kuryr-lib­net­work (pilote Docker) : kuryr-lib­net­work est un pilote pour Docker qui fait office d’interface entre Docker et Neutron.
• Keystone (service d’identité) : avec Keystone, les uti­li­sa­teurs d’OpenStack disposent d’un service d’identité central à portée de main. Le module agit comme un système d’au­then­ti­fi­ca­tion 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 re­pré­sente un uti­li­sa­teur in­di­vi­duel. Pour chaque uti­li­sa­teur, il est possible de définir plusieurs accès avec des droits dif­fé­rents.
• Cinder (Block-Speicher) : Cinder est le surnom du composant de l’ar­chi­tec­ture OpenStack qui fournit un bloc de mémoire per­sis­tant pour l’exécution des machines vir­tuelles. Le module fournit une mémoire virtuelle via un auto-service API. De cette façon, les uti­li­sa­teurs peuvent utiliser les res­sources de stockage sans avoir à se demander sur quel appareil sont sau­ve­gar­dées leurs res­sources.
• Glance (Image-Service) : le module Glance est un service d’OpenStack qui permet de stocker et de trans­fé­rer les images des machines vir­tuelles.

Pour plus d’in­for­ma­tions sur les com­po­sants ou les services OpenStack, consultez notre article com­plé­men­taire sur OpenStack.

Outre les com­po­sants de base, l’ar­chi­tec­ture OpenStack peut être complétée par dif­fé­rents modules et ex­ten­sions. Pour plus de détails, consultez le site Web OpenStack.

D2iQ DC/OS

DC/OS (Dis­tri­bu­ted Cloud Operating System) est un programme open source développé par D2iQ Inc. (au­pa­ra­vant Mesophere), qui permet d’exploiter des systèmes dis­tri­bués. Le projet est basé sur le ges­tion­naire de clusters open source Apache Mesos, et constitue un système d’ex­ploi­ta­tion pour centre de calcul. Le code source soumis à la licence Apache version 2 est en accès libre pour les uti­li­sa­teurs sur GitHub. Par ailleurs, les dé­ve­lop­peurs com­mer­cia­li­sent une version d’en­tre­prise du programme sur d2iq.com. La do­cu­men­ta­tion du projet et des guides sont dis­po­nibles sur dcos.io“). Il faut con­si­dé­rer que DC/OS est en quelque sorte une dis­tri­bu­tion de Mesos, qui vous offre toutes les fonc­tion­na­li­tés d’un ges­tion­naire de clusters à travers une interface uti­li­sa­teur centrale, et qui complète Mesos grâce à une in­fras­truc­ture ex­haus­tive et de nombreux com­po­sants.

DC/OS utilise le système distribué de la pla­te­forme Mesos. Ceci permet de regrouper les res­sources 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 vir­tuelles aussi sim­ple­ment que si vous opériez sur un seul or­di­na­teur.

Le programme facilite l’ins­tal­la­tion et l’ad­mi­nis­tra­tion d’ap­pli­ca­tions dis­tri­buées et de tâches au­to­ma­ti­sées telles que la gestion des res­sources, l’or­ga­ni­sa­tion et la com­mu­ni­ca­tion entre processus. L’ad­mi­nis­tra­tion d’un cluster basé sur D2iQ DC/OS ainsi que l’ex­ploi­ta­tion de tous les services sont gérées de façon cen­tra­li­sée grâce à un programme de ligne de commande (CLI) ou une interface Web (GUI).

DC/OS abstrait les res­sources du cluster et fournit des services partagés comme un service de dé­cou­verte ou une fonc­tion­na­lité de gestion des paquets. Les com­po­sants-clés du programme s’exécutent dans un espace protégé, l’espace noyau. Dans cet espace on trouve également les pro­grammes maîtres et agents de la pla­te­forme Mesos, qui ont la charge d’organiser les res­sources, 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 res­sources et d’or­ches­trer les tâches (unités de travail abs­traites) qui sont exécutées sur un nœud agent. Le maître Mesos distribue les res­sources aux services DC/OS en­re­gis­trés, et accepte les rapports de res­sources des agents Mesos.
• Les agents Mesos : les agents Mesos sont des processus esclaves qui s’exécutent sur les comptes agents et sont res­pon­sables de l’exécution des tâches dis­tri­buées par le maître. Ils four­nis­sent au maître des rapports réguliers sur les res­sources dis­po­nibles dans le cluster. Ces rapports sont ensuite trans­fé­rés par le maître à un or­ga­ni­sa­teur (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 com­po­sants et ap­pli­ca­tions du système fonc­tion­nent grâce à des agents Mesos via Executor dans l’espace uti­li­sa­teur. Les com­po­sants de base d’une ins­tal­la­tion standard DC/OS sont un routeur ad­mi­nis­tra­teur, le DNS Mesos, un DNS proxy distribué, l’équi­li­breur de charge Minuteman, l’or­ga­ni­sa­teur Marathon, Apache ZooKeeper, et Exhibitor.

• Le routeur ad­mi­nis­tra­teur : il s’agit d’un serveur Web spé­cia­le­ment configuré et basé sur NGINX, qui fournit des services DC/OS tels qu’une au­then­ti­fi­ca­tion cen­tra­li­sée et des fonc­tion­na­li­tés proxy.
• Le DNS Mesos : le DNS Mesos est un composant du système qui propose des fonc­tion­na­li­tés de dé­cou­verte de service, ce qui permet à chacun des services et des ap­pli­ca­tions du cluster de s’iden­ti­fier res­pec­ti­ve­ment grâce à un nom de domaine cen­tra­lisé (DNS).
• Le DNS Proxy distribué : il s’agit un DNS dis­tri­bu­teur (dis­pat­cher) interne.
• Minuteman : le composant système Minuteman fonc­tionne comme un équi­li­breur de charge interne, qui travaille sur les trans­ports de couche selon le modèle OSI (couche 4).
• DC/OS Marathon : Marathon est un composant central de la pla­te­forme Mesos, qui fonc­tionne dans Me­sos­phere DC/OS en tant que système init (similaire à systemd). Marathon démarre et contrôle les services et ap­pli­ca­tions DC/OS dans un en­vi­ron­ne­ment cluster. De plus, le programme fournit des ca­rac­té­ris­tiques en haute dis­po­ni­bi­lité, des services de dé­cou­verte, un équi­li­brage des charges, des rapports d’état et une interface Web graphique.
• Apache ZooKeeper : Apache ZooKeeper est un composant open source qui offre des fonc­tion­na­li­tés de coor­di­na­tion pour le contrôle et l’ex­ploi­ta­tion des ap­pli­ca­tions dans les systèmes dis­tri­bués. Dans le cadre de Me­sos­phere DC/OS, ZooKeeper est utilisé pour coor­don­ner tous les services installés sur le système.
• Exhibitor : Exhibitor est un composant du système per­met­tant d’installer et de con­fi­gu­rer au­to­ma­ti­que­ment ZooKeeper sur chaque nœud maître du cluster. De plus, Exhibitor fournit une interface graphique aux uti­li­sa­teurs de ZooKeeper.

Grâce à DC/OS, plusieurs charges de travail peuvent être exécutées si­mul­ta­né­ment sur les res­sources du cluster. Par exemple, le système d’ex­ploi­ta­tion du cluster permet des opé­ra­tions pa­ral­lèles relatives aux systèmes de données, aux micro-services ou aux pla­te­formes de con­te­neurs telles que Hadoop, Spark et Docker.

D2iQ Universe met à dis­po­si­tion un catalogue d’ap­pli­ca­tions en libre accès pour DC/OS. C’est grâce à lui que les uti­li­sa­teurs peuvent installer des ap­pli­ca­tions telles que Spark, Cassandra, Chronos, Jenkins ou Kafka, de façon simple et con­for­table sur l’interface uti­li­sa­teur graphique.

Tools Docker : les outils pour la sécurité

Même si les processus en­cap­su­lés s’exécutent sur le même noyau, Docker utilise toute une gamme de tech­niques d’isolation pour les protéger les uns des autres. L’accent est mis sur des fonctions du noyau Linux, tel que Cgroups et Na­mes­paces.

Toutefois, les con­te­neurs n’offrent pas le même niveau d’isolation que les machines vir­tuelles.

En dépit des tech­niques d’isolation décrites, d’im­por­tants sous-systèmes de noyaux, tels que les Cgroups et les in­ter­faces de noyaux en /sys et /proc dans les registres peuvent être obtenus à partir des con­te­neurs.

L’équipe de dé­ve­lop­pe­ment de Docker a admis que ces failles de sécurité cons­ti­tuent un frein à l’éta­blis­se­ment des tech­no­lo­gies de con­te­neurs sur les systèmes de pro­duc­tion. Outre les tech­niques d’isolation basiques du noyau Linux, les nouvelles versions du moteur Docker sont donc com­pa­tibles avec les fra­me­works AppArmor, SELinux et Seccomp, qui agissent comme une sorte de pare-feu pour les res­sources du noyau.

• AppArmor : AppArmor peut être utilisé pour réguler les droits d’accès des con­te­neurs au fichier système.
• SELinux : SELinux propose un système de règles complexe, pouvant être utilisé pour l’im­plé­men­ta­tion des contrôles d’accès aux res­sources du noyau.
• Seccomp : Seccomp (Secure Computing Mode) permet d’activer et de contrôler Sys­tem­calls.

Au-delà de ces outils, Docker utilise en outre les capacités de Linux, qui peuvent servir à res­treindre les pri­vi­lèges root avec lesquels le moteur Docker démarre les con­te­neurs.

Il existe d’autres problèmes de sécurité, relatifs à la vul­né­ra­bi­lité de l’ap­pli­ca­tion dans le cadre de la dis­tri­bu­tion des com­po­sants à travers le registre Docker. Puisqu’en principe chacun peut créer des images Docker et les rendre ac­ces­sibles à la com­mu­nauté grâce au Docker hub, il existe un danger d’intégrer, à travers ces images, du code mal­veil­lant qui en­dom­ma­ge­rait le système. Les uti­li­sa­teurs de Docker doivent donc s’assurer, avant de déployer une ap­pli­ca­tion, que l’in­té­gra­lité du code fourni avec une image provient d’une source sûre.

Docker propose à cet effet un programme de cer­ti­fi­ca­tion, grâce auquel les four­nis­seurs de logiciels peuvent faire vérifier et marquer leurs images Docker. Avec ce programme de cer­ti­fi­ca­tion, Docker veut faciliter aux dé­ve­lop­peurs la mise en place de chaînes d’ap­pro­vi­sion­ne­ment lo­gi­cielles sûres pour leurs projets. En plus d’un gain de sécurité pour les uti­li­sa­teurs, le programme permet également aux dé­ve­lop­peurs de logiciels de se démarquer parmi les nom­breuses res­sources dis­po­nibles. Les images cer­ti­fiées ob­tien­nent un meilleur clas­se­ment dans les résultats de recherche de Docker Hub et sont signalées par un badge Verified Publisher.