Clusters de containers Docker

Une fois déployée une infrastructure de containers Docker, se pose la question de savoir comment optimiser l’utilisation des ressources du serveur hôte par la fourniture de services de failover et de distribution. Il existe plusieurs solutions offrant ce type de mécanisme.

Docker Swarm

Docker Swarm (« Essaim ») est la technologie proposée nativement par Docker pour gérer le clustering de containers Docker. Plus précisément, Docker Swarm permet aux utilisateurs de créer des pools de serveurs hôtes exécutant les services de Docker, de les exposer comme un seul hôte Docker virtuel, puis de configurer des containers Docker en gérant automatiquement la répartition de la charge et la gestion de l’état du cluster.

Docker Swarm utilise l’API standard de Docker, donc n’importe quel outil qui communique déjà avec un démon de Docker peut utiliser Swarm pour réaliser les mêmes actions sur de multiples hôtes Docker de manière transparente.

Comme d’autres projets de Docker, Swarm suit le principe de «batteries included but removable ». Il est donc fourni nativement avec un mécanisme simple d’orchestration complété par des points d’extensibilité permettant de le remplacer par des solutions pour les déploiements de production à grande échelle, comme Mesos, que je présenterai dans la section suivante.

Pour installer un cluster swarm, il faut commencer par obtenir l’image officielle proposée dans le référentiel Docker Hub.

docker pull swarm

Une fois téléchargée l’image de l’application swarm, on peut alors l’exécuter dans un container pour générer le jeton qui permettra d’identifier ensuite le cluster Swarm.

docker run –rm swarm create

Une première approche pour déployer un cluster Swarm consiste à utiliser une série de commandes docker, comme l’illustre le script suivant :

# on each of your nodes, start the swarm agent

# <node_ip> doesn’t have to be public (eg. 192.168.0.X),

# as long as the swarm manager can access it.

$ docker run -d swarm join –addr=<node_ip:2375> token://<cluster_id>

# start the manager on any machine or your laptop

$ docker run -d -p <swarm_port>:2375 swarm manage token://<cluster_id>

# use the regular docker cli

$ docker -H tcp://<swarm_ip:swarm_port> info

$ docker -H tcp://<swarm_ip:swarm_port> run …

$ docker -H tcp://<swarm_ip:swarm_port> ps

$ docker -H tcp://<swarm_ip:swarm_port> logs …

# list nodes in your cluster

$ docker run –rm swarm list token://<cluster_id> <node_ip:2375>

L’article de mon collègue Steve Squillace décrit dans le détail une configuration de Swarm fondée sur cette approche. Une autre démarche, plus rapide, est d’utiliser Docker Machine. En effet, cet outil offre des paramètres spécifiques à Swarm…

La première étape est de créer le serveur Docker qui hébergera le rôle « Swarm-master ».

docker-machine -D create -d azure \

–azure-subscription-id= »<identifiant de la souscription> » \

–azure-publish-settings-file= »<fichier de parametres de publication> » \

–azure-location « West Europe » \

–swarm \

–swarm-master \

–swarm-discovery token://<token généré avec Swarm> \

swarm-master-qa-stephgou

On peut alors créer les nœuds du cluster.

docker-machine -D create -d azure \

–azure-subscription-id= »<identifiant de la souscription> » \

–azure-publish-settings-file= »<fichier de parametres de publication> » \

–azure-location « West Europe » \

–swarm \

–swarm-discovery token://<token généré avec Swarm> \

swarm-node-qa-stephgou-0

En utilisant ces commandes, il est ainsi extrêmement simple de monter son cluster et d’afficher la liste des nœuds avec la commande :

docker-machine env –swarm swarm-master-qa-stephgou

On remarque que dans le cas du cluster Swarm, le DOCKER_HOST écoute sur le port 3376, alors que les URLs qui sont affichées lorsque l’on exécute la commande docker-machine env sont à l’écoute sur le port 2376. Le port 3376 est celui qui est utilisé pour les communications s’inscrivant dans le contexte du cluster Swarm, tandis que le port 2376 est utilisé pour une communication directe avec le serveur hôte Docker cible. Or, si le driver Azure pour Docker Machine crée automatiquement les points de terminaison pour autoriser les flux d’échange sur le port 2376, il ne crée pas celui correspondant au cluster Swarm. Il faut donc ajouter ce point de terminaison afin de finaliser la configuration du cluster, comme le montre la copie d’écran suivante.

ll devient alors possible d’interroger Docker pour connaître la configuration du cluster avec la commande :

docker info

Pour obtenir des informations filtrées sur la liste des nœuds du cluster Swarm, on peut utiliser la commande :

docker run –rm swarm list token://<token généré avec Swarm>

Pour tester le comportement de ce cluster Swarm, il suffit de déployer un serveur Web. On peut alors interroger le Docker Hub pour choisir une image de serveur http avec la commande :

docker search -s=10 http

Dans ce contexte, il est alors possible de monter jusqu’à 3 serveurs http (déployés respectivement sur le master et sur les deux nœuds du cluster) à l’écoute sur le port 80. La quatrième commande échoue car aucun des nœuds Swarm ne dispose d’un port 80 disponible.

docker run –d –p 80:80 –name stephgou-A httpd

docker run –d –p 80:80 –name stephgou-B httpd

docker run –d –p 80:80 –name stephgou-C httpd

docker run –d –p 80:80 –name stephgou-D httpd

Les 3 serveurs HTTP sont bien démarrés.

Il est possible d’explorer la configuration de l’un des containers (par exemple le containerabef948edf3e ) avec la commande :

docker inspect abef948edf3e

Pour le requêter en HTTP, il ne reste donc plus qu’à ajouter un endpoint sur la VM hébergeant le node swarm dans Azure.

On peut alors vérifier que le serveur HTTP répond bien sur cette url.

Apache Mesos

Apache Mesos est une solution open source de gestion de cluster conçue pour déployer et optimiser des systèmes distribués. Mesos est construit selon les mêmes principes que le noyau Linux, mais offre un niveau d’abstraction différent : en fait, Mesos se comporte comme le noyau d’un système d’exploitation à l’échelle d’un datacenter. Mesos propose des API permettant de gérer les caractéristiques (mémoire, CPU, disque et ports) de machines (physiques ou virtuelles) et de planifier leur utilisation en donnant à des applications comme Hadoop, Spark, Kafka, Elastic Search, la possibilité de manipuler ces ressources au sein d’un pool unique alloué dynamiquement.

Concrètement, Mesos permet ainsi d’exécuter plusieurs systèmes distribués sur le même cluster en isolant et en partageant des ressources. Testée en production, la capacité de dimensionnement de Mesos pourrait prendre en charge des milliers de nœuds. Cette solution est  d’ailleurs utilisée par des services comme Twitter, eBay et NetFlix. Enfin, Mesos supporte Docker…

Mesosphere

La startup Mesosphere propose une technologie de système d’exploitation de DataCenter (DCOS), fondée sur Apache Mesos, pour les plateformes Cloud comme Microsoft Azure. DCOS propose donc une solution axée sur un mécanisme à base de container permettant de traiter tous les serveurs et les ressources d’un Datacenter comme une seule entité de gestion d’infrastructure. L’objectif est de simplifier le déploiement de l’infrastructure, des composants associés et la construction des applications par la mise à disposition d’une version consolidée de Mesos intégrant un langage de commandes et un portail.

Mesosphere utilise le framework Open Source Marathon : il permet de provisionner un environnement PaaS opérationnel en l’espace de quelques minutes. Lors de la récente conférence Build de Microsoft, Mark Russinovich a démontré la bêta de Mesosphere sur Azure. Il a d’abord expliqué comment configurer un quelques clics un cluster Mesosphere (grâce au mécanisme de publication en ligne d’un template DCOS proposé par Corey Sanders).  Puis il a lancé, sur un cluster DCOS préconfiguré de 212 ressources (103 VMs, 103 Nic + 2*3 masters Mesosphere), 1000 containers Marathon et 1000 containers Spark avec les quatre lignes de commande suivantes :

dcos marathon app add marathon.json

dcos marathon app add spark.json

dcos marathon app update marathon instances=1000

dcos marathon app update spark instances=1000

Voici l’affichage du portail Mesosphere au cours de cette présentation.

Cette démonstration illustre également les possibilités qu’offrent le principe d’extension d’Azure Resource Manager, qui a permis, dans ce contexte, de déclarer des boucles d’instanciations de machines virtuelles au sein du template décrivant le cluster…

Apache Hadoop YARN

Apache Hadoop YARN (« Yet Another Resource Negotiator ») est la technologie de gestion de cluster incluse dans la version 2 de Hadoop offrant un système d’exploitation distribué à grande échelle pour les applications Big Data. Egalement appelé MapReduce 2.0, ce logiciel permet de dissocier les capacités de gestion et de planification des ressources qu’offre MapReduce, du composant de traitement des données.

A la différence de la première version de MapReduce qui ne permettait que du traitement orienté batch, cette nouvelle approche permet ainsi à Hadoop de supporter de multiples modèles de traitement et un plus large éventail d’applications, comme par exemple l’analyse de données en temps réel. YARN délègue les tâches correspondantes à des containers et ces containers peuvent être des containers Docker…

Kubernetes

Kubernetes (timonier en grec) est un projet OpenSource de Google pour gérer des containers Linux à grande échelle. Kubernetes supporte Docker et permet d’intégrer chaque hôte de Docker au sein d’un cluster auquel il distribue les informations de configuration. Microsoft supporte Kubernetes dans Azure et propose un outil Open Source de visualisation des clusters Kubernetes.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *