distrobox-images

Dockerfiles pour les softs lourds (Houdini, ...) lancés via distrobox, buildés une fois et poussés sur un registry privé plutôt que rebuild à chaque distrobox create.

Convention

Un dossier par soft, autonome :

<soft>/
  Dockerfile          # souvent multi-stage: base commune + variante amd / nvidia
  build-and-push.sh   # build + push vers le registry
  <soft>-run          # launcher installé dans l'image (entrypoint applicatif)
  README.md           # specifics: prérequis, licence, distrobox create, gotchas

Pas de base image partagée entre softs différents — chacun a ses propres dépendances système, ça n'apporte rien de mutualiser au-delà du dossier.

Deux variantes GPU par soft quand le rendu OpenGL/Vulkan compte (viewport, préview) :

• <soft>-amd — Mesa embarqué dans l'image (radeonsi / RADV), marche aussi pour Intel.
• <soft>-nvidia — rien embarqué; le driver NVIDIA de l'hôte est monté au runtime par distrobox --nvidia.

Si le rendu GPU n'a pas d'importance pour un soft donné, une seule image suffit — ne pas dupliquer par principe.

Registry privé

podman run -d --name registry --restart=always \
  -p 5000:5000 -v registry-data:/var/lib/registry \
  registry:2

HTTP en clair, donc à déclarer en "insecure" côté moteur de conteneurs.

podman — /etc/containers/registries.conf.d/local.conf :

[[registry]]
location = "registry.lan:5000"
insecure = true

docker — /etc/docker/daemon.json, puis restart docker :

{ "insecure-registries": ["registry.lan:5000"] }

Au-delà d'un LAN de confiance, mettre TLS + auth devant plutôt que insecure.

Licences / EULA

Plusieurs de ces softs (Houdini compris) sont installés depuis un binaire propriétaire téléchargé avec un compte perso, et l'EULA interdit en général la redistribution. Le registry doit rester privé — jamais de push d'une image contenant un de ces binaires vers un registry public.

Softs

• houdini/ — Houdini Apprentice