Skywalker13

Diary of an ex-GeeXboX developer…

Docker ~ 🇫🇷

Posted at — Jul 17, 2022

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 (de mon point de vue) au départ. 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 totale de ce que je constate en pratique. On y voit autant de conteneurs que de services quand tous ces services appartiennent au même client. Par exemple, on y trouve nginx dans un conteneur, un service métier quelconque dans un second conteneur, 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 installation. 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, vous m’avez lu et compris ? Je ne crois pas. Ici, on parle d’un seul et même client. 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 services managers 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 de regarder 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 mĂŞme 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 service manager. Laissez les vrais gestionnaire de services faire ce job.