DOCKER - Vers la démocratisation du cluster management

Docker ne sera définitivement pas spectateur de la montée en puissance de nouvelles solutions d'orchestration conteneurs comme Kubernetes, developpé par Google .


La version 1.12 simplifie ainsi tout ce qu'on a pu trouver non nécessaire, voire complexe dans l'ancien swarm mode.

Mise en place simplifiée

Consul, Etcd, ou ZooKeeper, si vous ne savez pas quoi choisir, peu importe, Docker intégre maintenant de base un KV store distribué.

Un simple `docker swarm init` lancé sur le node fondateur de votre cluster initialise le swarm mode.

```
docker $(docker-machine config m01) swarm init
```

Ce premier node est maintenant appelé manager et non plus master.

La nuance est importante puisque vous pouvez avoir plusieurs managers, ce qui renforce la haute disponibiité de votre cluster, qui non seulement peut survivre la perte d'un worker, mais egalement celui d'un manager.

Rescheduling automatique

Une seule commande suffit pour rattacher un worker ou manager à votre cluster

```
docker $(docker-machine config m01) swarm join \
    --token XXXXXX-Y-ZZZZZZZZZZZZZZZZZZZZZZZZ-ZZZZZ \
    Y.Y.Y.Y:2377
```

Pour supprimer un worker, un simple `swarm leave` suffira.

Notez que tout containeur qui tourne sur le worker à supprimer sera automatiquement reschedulé sur les autres nodes du cluster.

Magique !


On peut visualiser le composition de son cluster à tout instant avec la commande suivante:

```
docker $(docker-machine config m01) node ls
```

Manager utile

Avec le nouveau swarm mode le manager gagne en responsabilités.

Toute commande importante passera par lui.

Par exemple, pour créer un réseau overlay sur toute machine existante ou future de votre cluster, il suffit de le faire sur le manager:

```
docker $(docker-machine config m01) network create -d overlay dcnet
```

Plus besoin de le repeter à la main sur chaque nouveau node, le manager s'en occupe automatiquement.

Scaaaaaaaaalable

A l'instar des services declarés dans votre docker-compose.yml, le nouveau swarm mode propose une serie de nouvelles commandes pour gérer le cycle de vie de vos services.

Lancer un nouveau service sur votre cluster est aussi simple que celà:

```
docker $(docker-machine config m01) service create \
    --replicas 1 \
    --name helloworld  \
    --network dcnet  \
    mon_image_sur_dockerhub
```

Rien de trés excitant vous allez me dire... jusqu'à ce qu'on découvre la commande scale !

```
docker $(docker-machine config m01) service scale helloworld=10
```

Cette ligne crée 10 instances de votre service `helloworld` et les repartit automatiquement et équitablement entre les differentes machines de votre cluster.

Notez que le résultat n'est pas immédiat. Cette commande ne fait que definir un but à atteindre pour le cluster. En l'occurence: "toujours avoir 10 instances de helloworld"....quoi qu'il arrive.

Si par exemple vous perdez un worker qui hébérge 3 instances de helloworld, le manager va créer 3 instances supplementaires et les repartir sur les autres workers du cluster.

Pour surveiller l'etat de deploiement de votre service:

```
watch docker $(docker-machine config m01) service ps helloworld -f "desired-state=Running"
```

Notez le -f qui permet de filtrer la sortie de la commande. Si on ommet ce filtre, on retrouvera tous les etats historiques de ce service.

Load balancing natif & Routing Mesh

Si vous avez essayé de gérer la regeneration automatique de votre config nginx/haproxy en fonction de l'evolution des nodes dans votre cluster, vous savez que c'est un sujet compléxe.

Il n'est plus obligatoire (bien que recommandé) d'avoir un load balancer nginx ou haproxy devant vos nodes.

Pour simplifier ce processus, Docker a implementé un load balancer natif qui dispatche automatiquement le traffic entre vos containeurs docker.

Pour activer le loadbalancing global, il faut declarer des ports à ouvrir sur votre service comme ceci:

```
docker $(docker-machine config m01) service update \
    --publish-add 8080:8080/tcp \
    helloworld
```

Maintenant admettons que vous avez 3 nodes donc 3 IPs dans votre cluster.

Et bien, notre service helloworld sera desormais accessible depuis n'importe quelle IP via le port 8080.

Y compris, si le service ne tourne pas sur cette IP !!

Le routeur de traffic de docker est assez malin pour rediriger les requettes vers le containeur le plus proche, meme si aucun ne tourne sur la machine qui reçoit le traffic.

Ce qui m'ammène au 2éme point: Si vous voulez tout de même mettre un haproxy ou nginx devant vos nodes, vous n'avez pas besoin de regenérer votre config upstream aussi souvent qu'avec l'ancien swarm mode.

Le seul scénario ou vous devrez le faire c'est à l'ajout ou à la suppression d'une nouvelle machine physique dans votre cluster.

Rolling updates

Une fois vos services setup, comment les updater progressivement sans downtime ?


En reprenant notre exemple de service helloworld ci dessus, voici comment updater la version de l'image qu'il execute:

```
docker $(docker-machine config m01) service update \
    --image NOUVELLE_IMAGE:VERSION \
    hellonode
```

Le manager s'occupera alors d'updater vos 10 instances de helloworld un par un jusqu'à ce que tout le monde soit à la derniére version.

Contraintes & Affinités

Imaginons que vous avez un service qui a besoin d'une instance de type GPU.

Lors de la creation ou de l'update de votre service, vous avez respectivement un flag "constraint" et "constraint-add" qui permet de définir les affinités entre containeurs et leur emplacement/environnement.

Disons que vous avez 4 nodes dans votre cluster. Seul un node sur 4 est equipé d'un GPU. Vous pouvez alors labeller ce node comme "GPU_ENABLED":

```
docker $(docker-machine config m01) node update --label-add type=GPU_ENABLED my_worker_01
```

Ensuite, lors de la creation du service, vous passez la valeur "node.labels.type == GPU_ENABLED"

Votre service ne sera alors placé QUE sur les nodes ayant le label GPU_ENABLED.

D'autres types de contraintes sont egalement disponibles.

Pour plus d'info jetez un oeuil à la doc: https://docs.docker.com/engine/reference/commandline/service_create/#/specify-service-constraints

Quid des dépendances entre services ?

Il n'est pas encore clair quel est le plan pour l'intégration du format docker-compose avec le nouveau swarm mode.

Un format alternatif est actuellement en developpement: DAB, ou Distributes Application Bundle

Des commandes experimentales existent pour utiliser ce format: https://docs.docker.com/engine/reference/commandline/stack_config/

D'aprés Mike Goelzer, project manager sur Docker, un outils sera certainement développé pour convertir la syntaxe docker-compose.yml en syntaxe DAB

WIP

Toute startup le sait: pas d'innovation sans MVP ou bugs. Docker n'echape pas à la regle.

La commande scale par exemple a connu quelques problémes dans la premiére version stable. Un correctif est dejà en route pour la prochaine release.

Le rebalancing du cluster n'est pas encore supporté, mais ça arrive https://github.com/docker/docker/issues/25353

La gestion des logs multi conteneurs est inéxistante.

Le zero downtime n'est pas encore une realité pour certaines commandes (en partie du aux soucis avec scale).

Docker est un projet ambitieux, qui sans aucun doute saura corriger ces failles pour rapidement mûrir lors des prochaines versions.

La version 1.13 est prévue en septembre et devrait corriger les différents bugs constatés, ainsi qu'apporter une réponse stable à la spécification des dépendances entre services.

Ceci pour dire qu'à mon gout il faut encore attendre un peu avant de considérer le nouveau swarm mode comme stable et production-ready.

Autres nouveautés

L'orchestration est la partie la plus excitante de cette release.

Voici d'autres d'améliorations qu'on ne discutera pas en détails ici:
- nouvelles versions de docker pour windows & mac
- la communication entre nodes swarm d'un cluster est maintenant cryptée par defaut
- healthchecks
- plugins

Aller plus loin

Vous souhaitez en apprendre d'avantage sur la façon d'utiliser Docker en production ?

Ou vous êtes simplement curieux de connaitre les derniéres nouveautés et evolutions de Docker ?

Inscrivez vous à notre newsletter spéciale docker: http://eepurl.com/casBdL

Au programme, derniéres news docker decryptés par nos soins, mini tutoriels, case studies et un cours complet sur Docker en préparation pour la rentrée.

Dmitri Chapkine

CTO à DOERS
3 août 2016

PS: on recrute dmitri@doers.fr