Docker 1.3 et son écosystème

Le 16 octobre dernier, Docker est passé en version 1.3. C'est une bonne occasion de faire un point sur ce qu'apportent les mises à jour qui sont sorties depuis la 1.0. Nous allons également en profiter pour regarder les news importantes de l'écosystème Docker.

Rappel très rapide, Docker est une plate-forme ouverte à destination des développeurs et administrateurs systèmes visant à faciliter la construction et le déploiement d'applications distribuées. De manière moins marketing, l'idée derrière Docker est d'automatiser le déploiement d'environnements sous forme de conteneurs légers, portables et auto-suffisants ; les conteneurs permettant d'isoler l'exécution des applications dans des contextes d'exécution. Pour ce faire, Docker, écris en Go, reprend les bases de LXC, utilise les fonctionnalités du noyau Linux (CGroups, Namespaces, …) et se base initialement sur un système de fichier "en oignons" AUFS ; D'autres backend sont supportés également comme BTRFS ou devicemapper (LVM).

Depuis le 9 juin 2014 et la release de la version 1.0 "production-read", l'équipe derrière Docker n'a pas chomé et 3 nouvelles mises à jour sont sorties depuis ; à savoir que les releases de Docker se font à un rythme pré-défini, "à-la" Linux, tout ce qui est prêt et testé est intégré à la release qui suit. Voyons, de façon non-exhaustive, quelles sont les princiales améliorations apportées par ces différentes versions.

Hub : Images officielles et language stack

Le Hub, tel qu'il a été nommé après la sortie de Docker 1.0 est un dépôt des images Docker de tout-un-chacun qui souhaite les partager.

Au début de l'été, Docker Inc. a annoncé l'apparition des dépots officiels. L'idée est d'estampiller des images Docker comme officielles, c'est à dire vérifiées et garanties comme étant issues et supportées par les mainteneurs des projets. De nombreuses images officielles existent déjà pour les principaux projets open-source, comme Ubuntu, MongoDB, etc. Toute communauté open-source ou même tout éditeur logiciel peut entrer en contact avec l'équipe Docker pour voir son/ses images estampillées "officielles", après validation. Cette étiquette vient se rajouter à l'étiquette "automated build repository", précédement appelée verified (ce qui prétait à confusion) qui donne la garantie à l'utilisateur que l'image a été construite de manière automatique par l'infrastructure de Docker Inc. Il est également à noter que la version 1.3.0 de Docker apporte la vérification de la provenance et de l'intégrité des images officielles via signature électronique ; même si pour l'instant c'est en work-in-progress.

Un autre ajout récent au Docker Hub, datant de fin septembre, vaut le détour : les language stack, des images de bases pre-construites avec tous les outils nécessaires pour faire tourner une application dans un langage donné. Un développeur souhaitant rapidement construire un conteneur avec, par exemple, une application Clojure, n'a plus besoin de réinventer la roue (i.e. partir d'une image de base, installer le JDK, installer lein, etc.). Il lui suffit de partir d'une des language stack, ici clojure.

FROM clojure
COPY . /usr/src/app
WORKDIR /usr/src/app
CMD ["lein", "run"]

Restart policies (1.2.0)

Docker 1.2 a apporté une option en plus à la commande run : --restart. Il permet de définir une politique de redémarrage dans le cas où le conteneurs viendrait à mourrir, que ce soit de manière normale (code de retour à 0) ou inattendue (failure, code de retour différent de 0). Trois options sont disponibles pour l'instant :

• no : pas de redémarrage, fonctionnement par défaut.
• on-failure: redémarrage automatique si le conteneur s'est terminé de façon anormale. Il est possible d'ajouter un nombre maximum de redémarrage ; avec --restart=on-failure:3 docker essaiera de redémarrer 3 fois avant d'abandonner.
• always : redémarrage automatique, tout le temps, erreurs ou pas.

Injection de processus (1.3.0)

La possibilité de voir ce qui se passe dans le container, et par conséquent de s'en servir pour debugger, s'est averé longtemps complexe. Dans les premiers jours de Docker, l'installation d'un démon ssh était une solution commune. Cependant, celà complexifiait la création d'un conteneur ; en effet, Docker est fait pour lancer et isoler une seule commande, l'ajout d'un démon sshd imposait alors de mettre en place une solution du type init comme supervisord, runit, ou autres. Un article de Jérôme Petazonni, employé Docker Inc, a mis les choses au point : If you run SSHD in your Docker containers, you're doing it wrong!, littéralement "Si vous faites tourner SSHD dans vos container Docker, vous vous trompez". Jérôme avait créé à l'époque un outil, nsenter, qui était (et est toujours) installable en passant par un container, histoire de montrer un peu de magie.

La version 1.3 de Docker intègre un nouvelle commande, exec qui n'est autre que nsenter, en mieux, directement intégré à Docker, plus besoin de passer par un outil externe. Il devient donc possible d'executer n'importe quelle process à l'intérieur donc container, qui est en cours d'exécution. Ainsi un simple docker exec -it ubuntu_bash bash et nous voici dans une session bash à l'intérieur du conteneur. Bien entendu, comme pour nsenter, cela ne change pas l'idée derrière Docker qui est "une application par conteneur" ; la commande exec est surtout présente pour répondre à des problématiques de debug et de developpement.

Cycle de vie d’un container (1.3.0)

Une autre nouvelle commande arrive avec la version 1.3.0 de Docker, c'est create. Beaucoup d'utilisateur ont demandé d'être capable de séparer la création initiale de conteneur et son lancement ; auparavant il n'existait que la commande run qui faisait les deux d'un coup.

$ docker create -t -i fedora bash
6d8af538ec541dd581ebc2a24153a28329acb5268abe5ef868c1f1a261221752
$ docker start -a -i 6d8af538ec5
bash-4.2#

Options de sécurité (1.3.0)

Les utilisateurs de SELinux ou AppArmor vont être content, la commande --security-opt, arrivée avec la version 1.3.0, permet les labels et profiles de ces derniers, ce qui donne quelque chose comme :

docker run --security-opt label:type:svirt_apache -i -t centos bash

L'avantage principal de cette nouvelle commande, c'est, sur les systèmes qui sont configurés avec SELinux ou AppArmor, de pouvoir donner des privilèges de manière plus fine qu'avec l'option --privileged (qui donne tout) et ainsi diminuer les risques potentiels.

Boot2docker

Docker s'appuyant sur des fonctionnalitées de noyau Linux, son usage est limité à un système hôte avec un noyau Linux. Le projet boot2docker vise à enlever cette barrière en permettant d'avoir la commande docker sous Mac OS X et Windows. Il s'agit ni plus ni moins d'une machine virtuelle VirtualBox légère, basée sur la distribution Tiny Core Linux, pour avoir un overhead le plus faible possible. L'utilisation de boot2docker n'est pas encore totalement transparente, principalement pour la gestion des ports ou encore du montage des volumes du Host (OS X ou Windows) dans le conteneur Docker. La version 1.3 de docker, et la version correspondante de boot2docker, permettent maintenant aux utiliseurs de Mac OS X de monter leur dossier hôtes dans le conteneur.

Fig 1.0

Fig est un outil de développement basé sur Docker, écrit en Python. L'idée est de définir son environnement via un fichier YAML, que ce soit pour le code sur lequel nous travaillons mais également les services externes desquels notre application dépend (Base de données, ''Message queue'', etc.).

Nous avons donc, par exemple, un Dockerfile :

FROM clojure:lein-2.5.0
ADD . /code
WORKDIR /code
RUN lein run

Et un fig.yml :

[yaml]
web:
  build: .
  command: lein run
  links:
   - db
  ports:
   - "8000:8000"
db:
  image: postgres

Enfin un petit fig up et c'est gagné, nous obtenons notre base de données relationnelle qui tourne, notre appli qui a été construite et qui tourne aussi, et qui est lié à notre conteneur db. Il existe bien d'autres commandes (start, stop, destroy, etc.).

Fig était initialement développé par Orchard, qui a été acquis cette année par Docker Inc. Ce 17 octobre, l'équipe Docker a donc fait un release 1.0 de Fig en ajoutant le support à docker 1.3 et à boot2docker. Un certain nombre de commandes et de nouvelles fonctionnalitées ont étés ajoutées, notament :

• fig port, qui liste les ports par service,
• fig pull, qui récupère la dernière version d'un service,
• fig restart, qui redémarre les conteneurs (stop et start)
• le support de .dockerignore
• le support de connection en TLS au daemon Docker
• et pas mal d'autres options.

Mais l'annonce principale accompagnant cette version est que Fig ne recevra plus de mise à jour majeure à partir de cette version 1.0 puisque l'équipe Docker travaille pour intégrer les fonctionnalités que Fig apporte, directement dans Docker ; ce qui est une excellente nouvelle.

Partenariat avec Microsoft

Cela transpirait ces derniers mois, dans les différentes conférences et meetups, Microsoft s'intéressait de très prêt à Docker. C'est maintenant officiel, Docker Inc et Microsoft sont partenaires. Le partenariat couvre pour l'instant les sujets suivants :

• Ajouter le support de windows comme hôte Docker.
• Pour Microsoft, supporter les API open-orchestration de Docker.
• Intégration de Docker dans Microsoft Azure.
• Collaboration étroite sur les applications qui ont besoin de plusieurs conteneur (i.e. ce que Fig fait de mieux), et le support d'application qui sont composés de conteneurs Linux et Windows.

Le but ultime de Docker quand il a été distribué de façon libre était : "__Construire le 'bouton' qui permet à toutes applications d'être construites et déployées sur n'importe quel serveur, n'importe où.__" (C'est nettement plus classe en anglais : “''To build the ‘button’ that enables any application to be built and deployed on any server, anywhere.''”). Ce partenariat est donc une nouvelle marche en direction de ce dernier.

Conclusion

Un an et demi après la première release publique de Docker et près de 5 mois après la version 1.0, Docker et sa communauté avancent toujours aussi vite. Comme Solomon Hykes (CTO et co-fondateur de dotCould) avait dit lors de la dockerCon 14 : "la valeur réelle de docker n'est pas la technologie, mais le fait que les gens se mettent d'accord sur quelque chose" ; Docker Inc. pousse principalement dans le sens de la standardisation. Le développement de libcontainer, libchan et libswarm sont des projets qui vont dans ce sens. La communautée est toute aussi bouillante d'idées et chaque jour voit de nouveau projet plus intéressant les uns que les autres.

Enfin la dockerCon Europe, les 4 et 5 décembre 2014 viendra couronner une année très riche du côté de Docker et de son écosystème. Rendez-vous mi-décembre pour faire un petit retour sur la première conférence européenne Docker ;-).