Où Docker a sa place sur Proxmox : la décision de placement et le piège de compose

Proxmox est installé et vous voulez faire tourner des conteneurs. La question n’est pas « comment l’installer », c’est où le mettre. Et ce n’est pas affaire de goût, c’est affaire du nombre de choses qui cassent quand une chose casse.

Trois placements

Directement sur l’hôte. Le plus facile, et précisément ce qu’il ne faut pas faire. L’hôte est la couche sur laquelle repose tout le reste. Tout ce que vous y installez se trouve désormais dans le rayon d’impact de chaque machine virtuelle : un conflit de dépendances, un disque rempli ou une mauvaise mise à jour n’emporte pas seulement vos conteneurs, mais tout d’un coup.

Dans un conteneur système. Léger et rapide à mettre en place. En échange, vous faites tourner des conteneurs dans un conteneur, et ce montage a ses propres arêtes vives : le modèle de droits, les couches de système de fichiers, le noyau partagé. Choisi délibérément, il est raisonnable ; choisi parce que « c’était plus simple », il produit des surprises.

Dans une machine virtuelle. Le plus lourd sur le papier et le plus propre en pratique. Quand le montage à conteneurs s’écroule, ce qui s’écroule est une machine virtuelle, pas votre serveur. Et quand vous voulez le reconstruire, vous reconstruisez une machine.

La seule question qui décide

« Si ça casse, qu’arrive-t-il à tout le reste ? » Sur l’hôte la réponse est « tout », dans une machine virtuelle la réponse est « une seule ». La consommation de ressources, la facilité d’installation, tout cela devient secondaire à côté de cette réponse.

La seconde moitié : compose est un programme

Un fichier compose ressemble à de la configuration. Il n’en est pas. L’exécuter c’est exécuter du code, et cela tourne avec vos droits. Deux lignes à l’intérieur peuvent donner au conteneur la machine entière.

Quand les gens copient un fichier compose depuis internet, ils ne ressentent pas la gêne qu’ils ressentent en copiant une commande. La différence n’est pas dans le danger, elle est dans l’apparence : une commande ressemble à une commande, tandis que compose ressemble à un fichier de réglages. Y ressembler ne le rend pas sûr.

Quatre lignes à regarder avant de l’exécuter

Est-ce qu’il monte le système de fichiers de l’hôte à l’intérieur. Est-ce qu’il demande le mode privilégié. Est-ce qu’il passe à l’intérieur la socket propre de la gestion des conteneurs. Est-ce qu’il utilise directement le réseau de l’hôte.

Ces quatre-là sont les lignes qui percent la frontière du conteneur : si l’une d’elles est présente, ce conteneur n’est plus un conteneur, c’est l’hôte lui-même. Les lire prend dix secondes, et ces dix secondes valent plus que tout le reste de cette fiche.

Ce que fait Atlas

Atlas analyse les fichiers compose et les scripts d’installation avant l’installation, et cette analyse se tient sur le serveur et non dans l’interface. Quoi que l’interface envoie, le contrôle ne peut donc pas être sauté.

Les constats se rangent en deux niveaux. Rouge signifie quelque chose qui fait sortir le conteneur de la frontière du conteneur, c’est-à-dire des droits équivalents à ceux de l’hôte ; dans ce cas une approbation explicite est demandée. Jaune signifie quelque chose qui peut être fait délibérément mais dont vous devez être informé. Du côté du catalogue d’applications, le rouge n’est pas accepté du tout.

Un dernier détail, et il compte : l’analyseur ne donne pas d’avis, il rapporte un fait. Il ne dit pas « c’est dangereux », il dit « cette ligne fait ceci ». C’est le lecteur qui décide, car la même ligne peut être acceptable dans une installation et inacceptable dans une autre.