Contexte
Il y a quelques jours, la dev team de Proxmox VE a annoncé une nouvelle version (la 9.1) dont la nouvelle fonctionnalité majeure est l’ajout du support des artefacts OCI comme base pour créer des containers LXC.
Une fonctionnalité attendue depuis TREEEEES longtemps, puisqu’en théorie cela ouvre enfin la porte au lancement de containers de type “Docker” dans Proxmox, ce que les devs de Proxmox avaient toujours refusé.
C’est d’ailleurs la raison pour laquelle un de mes articles de blog cartonne le plus sur Google (snif, bientôt la fin de la gloire) :
Create LXC containers from OCI images
Proxmox VE 9.1 integrates support for Open Container Initiative (OCI) images, a standard format for container distribution. Users can now download widely-adopted OCI images directly from registries or upload them manually to use as templates for LXC containers. Depending on the image, these containers are provisioned as full system containers or lean application containers.
On teste ? D’abord les prérequis
Du coup, je suis curieux, comment ça fonctionne ?
D’abord, il faut aller pré-télécharger l’image qui vous intéresse dans votre stockage (pouvant accueillir des “CT Templates”).
Truc fun, il y a un bouton qui s’appelle “Query tags”, qui j’imagine permet de récupérer une liste des tags. Bon ben, ça commence mal, ça ne fonctionne pas (en tout cas pas sur docker.io…).
command 'skopeo list-tags docker://docker.io/zwindler/prime-calculator' failed: exit code 1 (500)
D’ailleurs, skopeo est justement une des dépendances utilisées dans mon article “hack proxmox+docker” et qui permet de manipuler (télécharger surtout) des containers depuis des registries distantes.
On ne perd pas de temps et on essaie de pull en mettant le tag manuellement, ça fonctionne :
Création du container LXC
Maintenant que le template (l’image OCI) est disponible sur notre stockage, on peut créer un container LXC comme d’habitude. On clique sur “Create CT”, on donne un CT ID, un password :
Pour le template, on choisit notre artefact OCI :
Et on valide. Proxmox devrait créer notre container :
Ça ne marche pas (encore)
Au-delà du premier petit bug pas grave, je n’ai pas encore réussi à démarrer un container LXC sur base OCI avec Proxmox VE 9.1 car je suis tombé sur 2 bugs.
Premier bug : image “from scratch”
D’abord, mon image prime-calculator n’est même pas créée.
TASK ERROR: unable to create CT 106 - Error while extracting OCI image: Unknown layer digest sha256:2bc4d17e1eb16f6b52acbafeb6d86c8f3eaf9588a5e2a7a245b6bb1d85e93396 found in rootfs.diff_ids: Unknown layer digest sha256:2bc4d17e1eb16f6b52acbafeb6d86c8f3eaf9588a5e2a7a245b6bb1d85e93396 found in rootfs.diff_ids
Bon, admettons. Mon image, c’est un binaire “from scratch”, sans rien à part le binaire, et je me suis peut-être trompé quelque part…
Deuxième bug : impossible de démarrer
Cependant, même avec des images connues, le container est bien créé :
Mais impossible de le démarrer :
problem with monitor socket, but continuing anyway: got timeout
TASK ERROR: unable to get PID for CT 104 (not running?)
Même erreur avec la ligne de commande
pct start 151 --debug
problem with monitor socket, but continuing anyway: got timeout
lxc_start_main: 257 Container is already running
- Read uid map: type u nsid 0 hostid 100000 range 65536
INFO confile - ../src/lxc/confile.c:set_config_idmaps:2295 - Read uid map: type g nsid 0 hostid 100000 range 65536
ERROR lxc_start - ../src/lxc/tools/lxc_start.c:lxc_start_main:257 - Container is already running
unable to get PID for CT 151 (not running?)
Après investigation (laborieuse), il se trouve que c’est un problème AppArmor. Je ne sais pas si c’est moi qui l’ai causé avec mes bidouilles ou si c’est un bug plus généralisé pour l’instant (probablement l’option 1, mais 2 n’est pas impossible non plus…)
Nov 23 10:37:26 beauharnois01 systemd[1]: Started pve-container-debug@151.service - PVE LXC Container: 151.
Nov 23 10:37:27 beauharnois01 kernel: audit: type=1400 audit(1764067047.008:175): apparmor="DENIED" operation="create" class="net"
Nov 23 10:37:27 beauharnois01 kernel: audit: type=1400 audit(1764067047.008:176): apparmor="DENIED" operation="create" class="net"
Nov 23 10:37:27 beauharnois01 systemd[1]: pve-container-debug@151.service: Deactivated successfully.
Nov 23 10:37:37 beauharnois01 pct[21369]: unable to get PID for CT 151 (not running?)
Le workaround temporaire (et cracra) est de désactiver le profil appArmor pour lxc-start, et supprimer les éventuels fichiers / process zombies.
apparmor_parser -R /etc/apparmor.d/usr.bin.lxc-start
ps aux | grep "lxc-start" | grep "151" | awk '{print $2}' | xargs -r kill -9
rm -f /var/lib/lxc/151/config.lock
rm -f /run/lxc/lock/var/lib/lxc/151
Note : On peut aussi le désactiver de manière permanente, mais c’est évidemment quelque chose à ne pas faire.
À partir de là, le container est accessible, parfois en console (ça dépend du container)
Conclusion
À voir si les problèmes que j’ai rencontrés venaient uniquement de mes serveurs, ou si d’autres utilisateurs rencontrent les mêmes.
En bonus, un autre article en anglais qui m’a fait persévérer quand j’ai compris que ça marchait chez certains :
Note : l’article m’a permis de redécouvrir la commande pct enter CTID qui permet de se logger au container.
En attendant, vous avez toujours mon hack ;-)