Menu

Pourquoi je n’aime pas Docker

6 août 2016 - Informatique
Pourquoi je n’aime pas Docker

Introduction

Alors que tout le monde issu de la communauté open source s’émoustille pour le système de conteneurs applicatifs Docker ces dernières années, jusqu’à maintenant, ce logiciel ne m’impressionne pas tellement. Étant utilisateur de conteneurs depuis longtemps, d’abord avec les zones sous Oracle Solaris, puis avec les jails sous FreeBSD et, plus récemment, avec LXC sous Linux, les avantages des conteneurs m’apparaissent très clairs: Isolation, sécurité, performance et facilité de gestion. J’en oublie sans doute. Or, même si Docker amène quelques valeurs ajoutées à tout cela, certains choix philosophiques faits par ses concepteurs viennent miner sa pertinence.

Un conteneur = un processus

Le premier et, de loin, le plus important est de limiter chaque conteneur à un seul processus. Bien qu’il soit techniquement possible d’en rouler davantage, tout est pensé en fonction de ce mono processus. D’abord, on doit définir lors du lancement du conteneur le processus duquel dépend son existence. D’autres processus qui seraient par la suite lancés se trouveraient à la merci de ce processus principal même s’ils ne sont pas liés (ex: Apache et SSH). Dans les autres systèmes de conteneurs, habituellement, le conteneur s’auto-éteint lorsque tous les processus ont été tués, peu importe l’ordre dans lequel ça se passe, ce qui me semble plus flexible.

Également, ce mono processus doit s’exécuter en avant-plan. Cette particularité a pour conséquence que le gestionnaire de services de la distribution Linux du conteneur ne peut pas être utilisé pour lancer le processus. On doit plutôt identifier puis lancer la commande directement en utilisant possiblement une option de ligne de commande supplémentaire pour qu’elle s’exécute en avant-plan. Voilà encore une différence irritante qui n’était pas nécessaire et qui est inexistante avec les trois autres systèmes de conteneurs mentionnés en introduction.

En outre, parfois, c’est tout simplement naturel de vouloir rouler plus d’un processus par instance. Par exemple, lors d’une récente fin de semaine, je me suis fait la main avec Let’s Encrypt, un service gratuit d’automatisation de la gestion de certificats SSL pour serveurs web. Il suffit de rouler une certaine commande dans une tâche planifiée et le tour est joué: plus besoin de renouveler manuellement son certificat lorsqu’il vient à échéance (et le certificat lui-même est gratuit en plus!!). Donc, ici, on a besoin d’avoir à la fois le service “cron” et le service web (ex: Apache) d’actifs. Autre exemple: un conteneur roulant MariaDB pour lequel on veut surveiller les mises-à-jour de sécurité disponibles. Pour mes serveurs physiques et machines virtuelles, j’utilise Icinga 1.x pour faire cette surveillance. Icinga communique par SSH avec le serveur puis exécute un “plugin” dédié à cette tâche. Encore ici, on a besoin d’avoir deux services en simultané. Pour ce cas précis, les fans de Docker vous diront qu’on a pas besoin de SSH puisque un service de scan des vulnérabilités des images Docker à même Docker hub est disponible. C’est vrai, mais ce service est payant depuis août 2016 et, encore une fois, vient créer une différence dans la manière de gérer les conteneurs versus les autres types de serveurs. Parenthèse: Envoyer les journaux d’activités (logs) d’un conteneur vers un serveur syslog centralisé est une autre action qui oblige à utiliser une façon non “standard” ou très propre à Docker.

Enfin, bien qu’il soit généralement indiqué d’isoler les différents services informatiques rendus par un ensemble de systèmes (pour des raisons de sécurité surtout), il peut s’avérer lourd de systématiquement les cloisonner individuellement, surtout lorsque certains services vont naturellement bien ensemble tel que je l’ai mentionné ci-dessus. On vient alors multiplier le nombre d’instances, et donc les coûts, pour rien.

Éphémère

Un autre soi-disant avantage de Docker, l’éphémérité des conteneurs, peut paraître séduisant au premier abord, mais beaucoup moins si on l’applique à certains scénarios le moindrement compliqués.

Premièrement, lorsqu’il est question de données, avant même de penser à déployer un conteneur Docker, il est impératif de faire l’inventaire de ce qu’on voudra conserver une fois ce conteneur détruit.. car détruit il sera étant donné que sa moindre modification doit se faire en amont, soit dans son dépôt Git ou sur Docker hub, plutôt que dans le conteneur lui-même, ce qui engendre sa destruction puis sa recréation de façon régulière. Pour parer à cela donc, l’inventaire des données à conserver s’avère essentiel. À chacun des répertoires correspondants à ces données, /var/log et /var/lib/mysql par exemple, on associe un point de montage dans lequel on connecte un “volume“, entité extérieure au conteneur qui peut en fait être, entre autres, un répertoire de l’hôte du conteneur. Alors que cette planification est totalement inutile dans le cas d’un conteneur classique parce que son état plus “permanent” permet de décider bien après son déploiement des données à conserver, elle peut s’avérer lourde avec Docker, en particulier si on ne connait pas à priori très exactement la nature et l’emplacement des composantes à l’intérieur du conteneur.

Autre aspect touchant le caractère éphémère des conteneurs Docker: leur “hostname”. J’utilise le terme anglais car bien qu’il faille donner un nom aux conteneurs, les concepteurs du logiciel ont décidé que ce nom allait devoir être différent du “host id” qui est en fait son “hostname”. De base, il est suggéré de ne pas définir un “host id” explicitement. Ce dernier étant alors généré de façon aléatoire, un “prompt” bash à l’intérieur du conteneur aura cette allure:

[user@4d24c285eb28 ~]#

Ok, ok, c’est peut-être juste de l’esthétique dans le cas de “bash”, mais, pour reprendre un cas énoncé précédemment, quant est-il si on veut centraliser les journaux d’activités du conteneur sur un serveur tiers? Il faut tout de même convenir qu’une ligne de “logs” contenant “4d24c285eb28” comme “hostname” de provenance ne nous informe pas beaucoup sur l’entité visée par cette ligne. Encore une fois, il est possible de passer outre cela en forçant un “host id” (ou “hostname”) explicitement, mais on se retrouve alors un peu en contradiction avec la mentalité de Docker.

Autres points

Dans les systèmes de conteneurs “classiques”, il est possible d’accéder directement au système de fichiers d’un conteneur à partir de son hôte. Vu de l’hôte, il s’agit en fait d’un simple sous-répertoire. Cela rend plus facile sa gestion en permettant, entre autres, de modifier son contenu sans qu’il soit démarré, advenant le cas qu’il soit “brisé” par exemple, ou encore de copier un fichier d’un conteneur à un autre rapidement avec la commande “cp” du système d’exploitation. Avec Docker, parce qu’on a à faire à un système de fichiers “par couche”, il n’est pas possible d’y accéder directement à partir de l’hôte. Certes, Docker rend possible certaines opérations comme la copie de fichiers à partir ou à destination de l’hôte, mais il faut alors passer par la commande Docker encore une fois.. pas très sexy, pour le moins.. surtout que si on reprend mon exemple de la copie d’un fichier d’un conteneur à un autre, Docker fait en deux commandes ce que je fais en une seule avec mes trois “vieux” systèmes de conteneurs.

Dans les “nouvelles” fonctionnalités apportées par Docker, on note la possibilité de revenir à une version antérieure du conteneur et le déploiement rapide d’un second conteneur identique au premier. J’utilise les guillemets pour désigner le mot “nouvelles” car j’obtiens les mêmes avantages avec les jails sous FreeBSD. En effet, “zfs rollback” et “zfs clone” sont respectivement plus ou moins leur équivalent considérant que je dédie toujours un “dataset” ZFS à chaque conteneur. On a simplement transféré des fonctions assumées par le système de fichiers hébergeant les conteneurs vers le système de conteneurs lui-même et/ou certains services “cloud” (dans le cas de l’utilisation conjointe de Docker avec Github par exemple).

Mea culpa

Je dois l’avouer: L’unanimité extatique envers Docker m’énerve. À entendre certains, c’est comme si les conteneurs étaient nés avec ce logiciel et que ça allait remplacer complètement les autres façons d’implanter des services informatiques. J’ai donc joué à l’avocat du diable au cours de cet article pour relever certains points négatifs dont on entend parler moins souvent à propos de Docker et qui ne doivent servir qu’à nuancer l’opinion publique. En effet, je concède que Docker apporte des gains tangibles dans certains cas. Je suis peut-être juste moins enthousiaste que d’autres dans ma façon de l’exprimer.

7 réflexions sur “ Pourquoi je n’aime pas Docker ”

Kevin

Bon texte Dom 🙂

Répondre
    Dominique

    Merci d’avoir lu.. Oh yes, un premier commentaire sur mon blog, c’est historique!!

    Répondre
Pascal Pilotte

Très intéressant ton article. Fais en d’autre, ça m’a appris certain point d’architecture sur Docker. Merci!

Répondre
    Dominique

    Wow, merci Pascal. Je serais en effet dû pour un autre article.

    Répondre
Sakr LIMEM

Merci d’avoir partager ta vision! C’est très intéressant!

Répondre

Laisser un commentaire

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