DockerCon Europe: du conteneur au cluster
La première DockerCon européenne vient de se terminer et l’on peut dire que ces quelques jours passés dans un froid polaire à Amsterdam ont été riches en annonces! Âgé de seulement 20 mois, Docker confirme sa croissance prodigieuse avec plus 700 contributeurs actifs, 3500 forks, 5200 pull requests! Docker a réussi à s’imposer comme LE système de conteneurisation, quelles sont maintenant les nouvelles ambitions de l’équipe Docker?
Docker avait jusqu’à maintenant réussi à s’imposer chez les développeurs, en leur permettant de gérer leurs environnements de manière incroyablement rapide et simplifiée. Mais il faut bien se rendre à l’évidence que le passage en production et la mise en cluster de conteneurs Docker manquaient de maturité. L’étape suivante pour Docker était donc de faire une percée dans la simplification de la mise en place d’un cluster.
Docker machine: provisioning
Jusqu’à aujourd’hui, Docker pouvait être soit exécuté en natif sous Linux, soit dans une VM minimaliste sous OSX et Windows: boot2docker. Docker veut généraliser cela grâce à Machine, une version musclée de boot2docker qui va permettre de démarrer une instance docker sur n’importe quelle infra.
La première étape de la mise en place d’un cluster est le provisioning, en français, l’allocation des ressources. Docker Machine va grandement nous simplifier la tâche en nous permettant de créer des “machines” Docker prêtes à l’emploi en une ligne de commande. Par exemple pour créer une machine locale sous virtualbox:
$ machine create -d virtualbox dev [info] Downloading boot2docker... [info] Creating SSH key... [info] Creating VirtualBox VM... [info] Starting VirtualBox VM... [info] Waiting for VM to start... [info] "dev" has been created and is now the active host. Docker commands will now run against that host.
Analysons ce que machine a fait ici. Machine commence par créer une clé SSH qui va nous permettre de nous connecter de façon sécurisée sur le nouveau host. Ensuite, Machine va installer le deamon Docker sur la machine distante et mettre en place une connexion TLS entre le client local et le daemon distant. L’authentification TLS est une nouvelle feature dans Docker. Une fois cette machine créée, on ajoute seulement quelques variables d’environnement:
$ export DOCKER_HOST=`machine url` DOCKER_AUTH=identity
Et en route pour la magie!
$ docker run busybox echo hello world Unable to find image 'busybox' locally Pulling repository busybox e72ac664f4f0: Download complete 511136ea3c5a: Download complete df7546f9f060: Download complete e433a6c5b276: Download complete hello world
On peut exécuter n’importe quelle commande Docker habituelle, de manière transparente sur l’instance créée.
Là où cela devient intéressant, c’est qu’il est possible d’utiliser un autre driver pour créer une machine chez Digital Ocean par exemple:
$ machine create -d digitalocean --digitalocean-access-token=... staging [info] Creating SSH key... [info] Creating Digital Ocean droplet... [info] Waiting for SSH... [info] "staging" has been created and is now the active host. Docker commands will now run against that host.
De nouveaux drivers sont sortis dans la foulée: Rackspace, VMWare, GCE, Exoscale, Concerto mais surtout Amazon AWS! La couleur est annoncée d’emblée: Machine va être adoptée largement par les acteurs du cloud et va certainement s’imposer comme l’outils de provisioning parfait pour Docker.
L’outil est pour l’instant en version alpha et est disponible sur le repo github https://github.com/docker/machine.
Docker Swarm: scheduling
Une fois les machines Docker créées, il faut un nouvel outil pour gérer les conteneurs sur le cluster. C’est là qu’entre en scène Docker Swarm. Il faut voir Swarm comme un scheduler, les jobs étant des conteneurs Docker. Swarm demande tout d’abord de créer un cluster et d’y ajouter des noeuds:
$ swarm create 275938151891743513fcf8dd6f4d3f9c
Démarrer l’agent swarm sur chaque noeud (ici 192.168.0.2 et 192.168.0.3):
$ swarm join --token=275938151891743513fcf8dd6f4d3f9c --addr=192.168.0.2:2375 $ swarm join --token=275938151891743513fcf8dd6f4d3f9c --addr=192.168.0.3:2375
Démarrer le manager (n’importe où, ici 192.168.0.1):
$ swarm manage --token=275938151891743513fcf8dd6f4d3f9c --addr=192.168.0.1:2375
Une fois cette configuration créée, le sheduling des jobs se fait grâce aux commandes Docker habituelles.
$ docker run -d -P -m 1g -c 1 -p 9200:9200 dockerfile/elasticsearch
Cette simple ligne de code va télécharger l’image Docker elasticsearch sur un des noeuds du cluster et lui allouer 1Go de RAM, 1 CPU et le port 9200. L’allocation ne va pas être faite au hasard mais en utilisant un algorithme Bin Packing. C’est à dire que le remplissage des machines se fera l’une après l’autre (la première est pleine, je passe à la seconde).
Des contraintes permettront également une gestion plus fine de la répartition. Il y aura plusieurs types de contraintes, tout d’abord les contraintes standards, basées sur les informations remontées par la commande docker info. Par exemple pour ne démarrer un conteneur que sur un host Ubuntu:
$ docker run -e "constraint:operatingsystem=ubuntu"...
Des contraintes plus spécifiques pourront êtres utilisées grâce à des labels personnalisés. De plus, il sera possible de gérer des affinités, c’est à dire par exemple de dire à Swarm de mettre préférentiellement telles images sur le même host.
TL;DR: Swarm est l’outil qui va permettre de scaler une application docker en quelques lignes de commandes, la version alpha se trouve ici.
Docker Compose
Fig faisant maintenant partie de la maison, Docker s’est dit que ça serait mieux de l’intégrer nativement. Docker Compose est donc l’intégration de Fig à Docker. Il sera possible d’écrire des fichiers de configuration en YAML permettant de décrire des configurations de lancements, à la manière de Fig:
name: rails_example
containers:
db:
image: postgres:latest
web:
build: .
command: bundle exec rackup -p 3000
volumes:
- .:/myapp
ports:
- "3000:3000"
links:
- db
Dans ce fichier, deux conteneurs liés sont décrits. Un simple
$ docker up
va permettre de builder et démarrer ces deux conteneurs.
Bref, pour qui utilisait Fig, on reste en terrain connu. Pour en savoir plus, une pull request est ouverte sur ce sujet.
Docker Hub Enterprise: il y a une image Docker pour ça
La mise en place de Docker Hub a permis à Docker de devenir l’AppStore des développeurs avec plus de 60000 images publiques. Après les développeurs, Docker veut aller plus loin, au sein même des entreprises. Docker sort donc son premier produit payant: Docker Hub Enterprise.
Docker Hub Enterprise va permettre aux entreprises d’acheter et d’installer directement le Hub Docker chez elles. Plus besoin d’uploader les images sur Internet, celles-ci pourront rester en interne, dans le lan de l’entreprise. Ce produit permettra évidement d’accéder à du support. Docker travaille également avec Microsoft et Amazon afin de fournir des images clé en mains pour un déploiement rapide.
Pour conclure
On voit bien que la stratégie de Docker est en train d’évoluer. Du simple outil de gestion de conteneur, Docker ambitionne de devenir un des outils principaux pour mettre en place des applications distribuées au sens large du terme. En fournissant des outils de provisioning et de scheduling, Docker vient marcher sur les plates-bande
s des solutions d’orchestrations comme Mesos (pourtant partenaire), Helios, Consul ou même CoreOs. Les micro-services ont de beaux jours devant eux et semblent avoir trouvé une plate-forme toute indiquée.
