Salut à toi jeune padawan, toi qui utilise docker parce que c’est à la mode, que ça a l’air facile et que tu as du temps à perdre. Cet article est pour toi.

Cet article est tiré de mon expérience personnelle avec Docker.

En boîte !

L’installation

Installer Docker est assez simple à condition d’avoir un Kernel compatible (coucou openvz), et je ne vous recommande pas de rester en 3.16 sous peine d’avoir des Kernel Panic. Pour ma part, je tourne avec Debian 8.3 (Jessie) et un Kernel 4.3

L’absence de convention

Docker est relativement jeune et la communauté n’est pas encore assez stable pour proposer du contenu de qualité. Docker n’est peut-être pas non plus la solution miracle, mais trop de personnes la considèrent comme tel. À tort ?

Ce manque de convention se fait surtout ressentir sur trois points :

  • L’abondance de templates “parents” alpine, debian, ubuntu, java8, golang qui rend compliquée la gestion des projets avec plusieurs dépendances (PHP+NodeJS par exemple)
  • La gestion des versions, qui est aléatoire (voire absente ?) : il n’y a aucune garantie que votre version téléchargée il y a un mois soit compatible avec la latest. Pire encore, il se peut qu’elle n’existe même plus !
  • La gestion des packages/dépendances, absolument aléatoire : elle dépend complètement du template parent choisi, et au contraire, il n’est pas rare de voir des Dockerfile basés sur ubuntu JUSTE pour apt-get install un package.
  • Les différents niveaux de qualité. Les templates gérés par Docker (namespace _) sont d’excellente qualité. Pour tout le reste, c’est moins sûr.

La qualité des templates

C’est pourtant ce qui fait la force de Docker : sa simplicité d’utilisation. Vous allez sur le hub docker et vous dénichez la perle rare. Parfait ! On peut le mettre en production. Dans la réalité, ce n’est pas aussi simple : tous ne sont pas de la même qualité. Il faut toujours vérifier le Dockerfile avant d’utiliser le template : parfois l’application sera lancée en root, les permissions seront inadaptées (777 sans raison, car c’est plus facile ™) … ou alors les dépendances seront démultipliées sans raison visible.

La gestion du réseau

Assez jeune, rencontre parfois quelques soucis … et devient vite compliqué à gérer entre le bridge, l’ipv6 et le réseau privé avec plusieurs machines.

La configuration avec des Dockerfile

Le format défini par Docker est bien, souvent suffisant. Son seul inconvénient, je trouve, c’est qu’il n’est pas Turing-Complete. Ce que j’entends par là, c’est qu’il n’est pas possible d’utiliser de variables dans la configuration des containers. Serait-ce réellement utile ? Pourquoi pas. Ajouter de la souplesse, c’est toujours mieux.

Exemple concret : une application qui respecte le Twelve-Factor App et écoute sur un port déterminé par une variable d’environnement passée en argument ne peut pas bénéficier de EXPOSE. On verra donc un port disponible selon Docker, mais non utilisé. Certes, c’est discutable : doit-on respecter ce point du Twelve Factor App ou donner le port en variable d’environnement ? Libre à vous. Rien n’est imposé.

Docker : la virtualisation jetable

Selon moi, et cet avis est peut-être uniquement le mien, les containers sont vus comme des machines virtuelles jetables. En effet, pourquoi s’embêter à créer des templates de qualité si leur durée de vie est courte ?

D’un côté, ce n’est pas faux. Les containers sont prévus pour être interchangeables, donc autant en profiter. Le soucis, c’est que si vous faites tourner votre production dessus, vous risquez d’avoir des surprises. Certes, il suffit de redémarrer le container pour le remettre à zéro et repartir sur une base saine. Mais autant ne pas la polluer dès le début, vous ne trouvez pas ?

Docker VS des machines virtuelles

  • Docker est plus léger !
    • Pas tout à fait. Il gère des couches (layers) de données, et ça prend de la place pour rien, et tout particulièrement si vos templates ne sont pas propres.
  • Docker fait de l’isolation, pas de la virtualisation. Il n’y a pas de perte en performance !
    • Encore une fois, ça se discute. La configuration de base de Docker est tout sauf optimale.
  • Docker est sécurisé !
    • Bien sûr. On en reparle quand un exploit sera trouvé ? ;-)

Les projets liés à Docker

Point positif, Docker a lancé la mode des containers et est à l’origine de l’Open Container Initiative qui cherche à uniformiser les containers.

  • Les OS basés sur Docker : CoreOS et RancherOS, pour ne citer qu’eux. Je vous les recommande si vous aimez Docker (et systemd).
  • Le PaaS basé sur Docker : deis, Flynn. Personnellement, je ne vous les recommande pas. Le principe même du as a service, c’est d’être hébergé et de ne s’occuper que de son application. Le PaaS self-hosted, c’est juste un syllogisme.
  • Docker Compose. Trop jeune. Est intéressant dans le concept, mais au moindre bug c’est toute votre architecture qui s’envole. Je ne miserais pas là dessus, personnellement.

Pour conclure, Docker est bien, mais le contenu qui vit autour est assez hétérogène … un peu comme avec les vrais conteneurs : il faudra passer par une étape de standardisation avant qu’il ne soit trop tard.