Depuis que Microsoft joue avec Linux dans Windows 10 et ses suites, on nous sert du Docker à toutes les sauces pour à peu près tout et n’importe quoi. Voici ce que j’en pense et pourquoi Docker existe au départ (de mon point de vue). Avant l’invention des cgroups Linux, on multipliait les machines virtuelles. Il était assez délicat pour un hébergeur de fournir du mutualisé “ouvert” (où il est possible d’être root mais en étant sur un unique système). Avec les cgroups, Docker est apparu. On peut alors créer des sandboxes bien isolées tout en conservant un seul système d’exploitation Linux (le recours aux machines virtuelles devient de moins en moins nécessaire).

Docker et les machines virtuelles

Aujourd’hui, je constate quelques absurdités. Par exemple, le fait d’utiliser Docker dans une machine virtuelle, quand justement l’objectif est de s’en passer.

Il vaut mieux supprimer complètement les machines virtuelles et créer des conteneurs Docker sur le système d’exploitation de base. En effet, avec les machines virtuelles, vous avez un hyperviseur dans lequel vous les installez. Avec Docker, le superviseur devient l’hôte qui héberge Docker et les machines virtuelles deviennent les conteneurs.

Ceci m’amène à l’aberration que je constate en pratique. On y voit autant de conteneurs que de services quand tous ces services appartiennent au même domaine. Par exemple, on y trouve le serveur nginx dans un conteneur, un service métier quelconque dans un second conteneur et un moteur de base de données dans un troisième conteneur.

Qu’est-ce que cela donne avec l’analogie sous forme de machines virtuelles ? Eh bien, vous installez un hyperviseur dans lequel vous créez trois machines virtuelles, et dans chacune de ces machines virtuelles, vous installez un système d’exploitation afin d’y faire tourner un seul service par déploiement. C’est absurde, non ?

Mais ça n’a rien à voir, avec Docker je n’installe pas plusieurs systèmes d’exploitations et en plus j’ai de l’isolation entre les processes.

Mais sérieusement, m’avez-vous compris ? Je ne crois pas. Ici, on parle d’un seul et même domaine. Les services communiquent forcément entre eux car ils sont destinés à travailler ensemble. Quand vous installez tous vos services dans un système, vous créez un compte pour chaque service et donnez les droits appropriés. Il y a forcément de l’isolation entre vos processes selon comment vous attribuez ceux-ci (je parle des droits). Tout système d’exploitation qui se respecte le fait déjà depuis bien avant l’apparition de Docker. Pourquoi remettre en cause les gestionnaires de services des systèmes d’exploitation sachant que de toute façon votre hyperviseur en utilise un et que vous lui faites confiance.

Le mutualisé

Selon moi, c’est simplement parce que vous n’avez pas compris ce que vous faites. Vous suivez la mode Docker où on y installe n’importe quoi et surtout n’importe comment (il suffit d’étudier les fichiers Dockerfile). L’isolation qu’offre Docker a du sens au même titre que l’isolation que font les hyperviseurs de machines virtuelles. Prenez le cas des hébergeurs mutualisés. Vous ne pouvez pas dilapider vos ressources avec une machine virtuelle par entreprise (client), alors, vous fournissez des solutions mutualisées. Le mutualiser Windows est une catastrophe car (par exemple) il vous est impossible d’isoler l’interface loopback que ce soit par utilisateur ou groupe d’utilisateur. Il suffit qu’un service écoute en loopback pour que n’importe quels utilisateurs du serveur mutualisé puisse y accéder (et Microsoft arrive à donner l’appellation “Server” à ce genre d’installation).

Maintenant passons à Docker pour cet hébergeur. Dans ce cas, vous créez un conteneur par client. Chaque conteneur bénéficie d’une vraie isolation (donc également l’interface loopback), vous ne risquez pas de mélanger les services des différents clients comme ce serait le cas avec un modèle plus simpliste comme celui de Windows exprimé ci-dessus. Le client qui loue ce conteneur, n’a pas besoin de savoir qu’il est dans un conteneur. Il peut sans autre installer ses services avec le service manager de son choix et gérer son infrastructure logicielle de manière tout à fait classique. Pour l’hébergeur, c’est extrêmement intéressant, car les conteneurs sont beaucoup moins gourmands en ressource que des machines virtuelles.

Un gestionnaire de services

En conclusion, utilisez Docker comme vous utiliseriez des machines virtuelles. Mais surtout, n’utilisez pas Docker pour gérer vos services, ce n’est pas un gestionnaire de services. Laissez les vrais gestionnaire de services faire ce job.