Skip to content

Podman

Podman

Configuration post installation (debian 11)

ajouter le registre docker et rootless session

sudo loginctl enable-linger 1000
cat <<EOF | sudo tee /etc/containers/registries.conf
[registries.search]
registries = ['docker.io']
EOF

Mise a jour automatique

Tout ce qui doit être fait est d’activer le service suivant podman-auto-update

Exemple de commande générique

Executer un manifest k8s: 

podman play kube nomdumanifest.yaml

Supprimer un manifest k8s: 

podman play kube --down

Podman-compose / Docker Compose avec Podman

Pour installer podman-compose (alternative python) et sa documentation, voir ici.

Configurer Docker Compose (v2) dans l'espace utilisateur pour Podman

Si vous préférez utiliser la commande native podman compose en s'appuyant sur le binaire officiel de Docker Compose (ce qui résout de nombreux problèmes de compatibilité), vous pouvez l'installer en mode rootless (dans l'espace utilisateur) :

1. Créer le dossier des plugins CLI et télécharger docker-compose

Téléchargez le binaire officiel de Docker Compose et placez-le dans le dossier de configuration utilisateur : 

mkdir -p ~/.docker/cli-plugins
curl -SL https://github.com/docker/compose/releases/download/v2.29.1/docker-compose-linux-x86_64 -o ~/.docker/cli-plugins/docker-compose
chmod +x ~/.docker/cli-plugins/docker-compose

2. Activer le socket système utilisateur de Podman

Pour que docker-compose puisse communiquer avec Podman, vous devez activer le socket utilisateur géré par systemd : 

systemctl --user enable --now podman.socket

3. Vérifier le fonctionnement

Vous pouvez maintenant lancer des commandes compose avec podman compose : 

podman compose version
podman compose up -d

Commandes associées usage desktop :

Lancer un conteneur isolé en arrière-plan (détaché) et s'y connecter

Pour lancer le conteneur en arrière-plan de façon permanente sans qu'il ne s'arrête immédiatement (car un conteneur s'arrête si son processus principal se termine), on utilise la commande sleep infinity avec l'argument -d (detached) :

# 1. Lancer le conteneur en arrière-plan
podman run -d --name sandbox \
  --userns keep-id \
  -v /home/user/Documents/volume/sandbox:/home/user \
  -w /home/user \
  quay.io/toolbx-images/debian-toolbox:12 sleep infinity

Ensuite, on s'y connecte:

# Connexion en tant qu'utilisateur standard (user)
podman exec -it sandbox bash

# Connexion en tant que root (pour installer des paquets)
podman exec -it -u root sandbox bash

Exécuter une application graphique (GUI) depuis le conteneur

Il est tout à fait possible de lancer des applications graphiques (via X11 ou Wayland) depuis un conteneur Podman rootless en partageant les sockets graphiques de l'hôte :

Pour X11 (je pense):
# 1. Autoriser les connexions locales au serveur X11 de l'hôte
xhost +local:root

# 2. Lancer le conteneur avec l'accès au socket X11
podman run -it --name sandbox-gui \
  --userns keep-id \
  -v /tmp/.X11-unix:/tmp/.X11-unix:ro \
  -e DISPLAY=$DISPLAY \
  -v /home/user/Documents/volume/sandbox:/home/user \
  -w /home/user \
  quay.io/toolbx-images/debian-toolbox:12 bash
Pour Wayland :
podman run -it --name sandbox-wayland \
  --userns keep-id \
  -v $XDG_RUNTIME_DIR/$WAYLAND_DISPLAY:$XDG_RUNTIME_DIR/$WAYLAND_DISPLAY:ro \
  -e WAYLAND_DISPLAY=$WAYLAND_DISPLAY \
  -e XDG_RUNTIME_DIR=$XDG_RUNTIME_DIR \
  -v /home/user/Documents/volume/sandbox:/home/user \
  -w /home/user \
  quay.io/toolbx-images/debian-toolbox:12 bash

Avoir un système d'init (comme Systemd dans LXC)

Exécuter un véritable système d'initialisation (systemd) à l'intérieur du conteneur en utilisant l'option --systemd=always :

podman run -d --name sandbox-init \
  --systemd=always \
  --userns keep-id \
  -v /home/user/Documents/volume/sandbox:/home/user \
  -w /home/user \
  quay.io/toolbx-images/debian-toolbox:12

Une fois démarré, entrer avec podman exec -it sandbox-init bash et utiliser systemctl pour démarrer ou arrêter des services en arrière-plan, exactement comme dans un conteneur LXC.

Lancer le conteneur via un manifest Kubernetes (YAML)

Podman a la capacité native de lire et d'exécuter des fichiers de spécification Kubernetes (YAML) grâce à la commande podman play kube sandbox-kube.yaml.

Un fichier manifest minimaliste nommé sandbox-kube.yaml a été créé dans le dossier /home/user/Documents/volume/sandbox/sandbox-kube.yaml :

apiVersion: v1
kind: Pod
metadata:
  name: sandbox
  annotations:
    io.podman.annotations.userns: "keep-id"
spec:
  containers:
  - name: debian-box
    image: quay.io/toolbx-images/debian-toolbox:12
    command: ["sleep", "infinity"]
    workingDir: /home/user
    volumeMounts:
    - name: home-sandbox
      mountPath: /home/user
    securityContext:
      runAsUser: 1000
      runAsGroup: 1000
  volumes:
  - name: home-sandbox
    hostPath:
      path: /home/user/Documents/volume/sandbox
      type: Directory

Commandes associées usage K8S :

# Lancer le pod à partir du manifest
podman play kube /home/user/Documents/volume/sandbox/sandbox-kube.yaml

# Arrêter et supprimer le pod
podman play kube --down /home/user/Documents/volume/sandbox/sandbox-kube.yaml

résolution de problème

Permission insufisante

Problème

Lors de l'exécution d'un conteneur avec Podman, vous rencontrez l'erreur suivante :

Error: copying system image from manifest list: writing blob: adding layer with blob "sha256:...": processing tar file(potentially insufficient UIDs or GIDs available in user namespace (requested...): Check /etc/subuid and /etc/subgid if configured locally and run "podman system migrate": lchown ...: invalid argument): exit status1

Cause

Le problème est lié à la configuration des IDs subordonnés pour l'utilisateur qui exécute le conteneur. Les fichiers /etc/subuid et /etc/subgid ne sont pas correctement configurés pour cet utilisateur.

(peut être cotre shell est sanboxé attention)

Résolution

  1. Vérifiez les fichiers /etc/subuid et /etc/subgid :
cat /etc/subuid /etc/subgid

Vérifiez si votre utilisateur est présent dans ces fichiers. Si ce n'est pas le cas, vous devez ajouter une entrée pour votre utilisateur.

  1. Ajoutez une entrée pour votre utilisateur :

Déterminez une plage d'IDs subordonnés qui ne chevauche pas les IDs existants sur votre système. Vous pouvez utiliser une valeur élevée comme 231072 (ou une autre valeur qui n'est pas déjà utilisée).

echo "votre_utilisateur:231072:65536" | sudo tee -a /etc/subuid /etc/subgid

Remplacez votre_utilisateur par votre nom d'utilisateur réel.

  1. Exécutez la commande de migration :
podman system migrate

Cette commande met à jour la configuration de Podman pour utiliser les nouvelles entrées dans /etc/subuid et /etc/subgid.

  1. Vérifiez que le problème est résolu :

Essayez d'exécuter à nouveau le conteneur qui a provoqué l'erreur. Si tout se passe bien, le conteneur devrait s'exécuter sans problème.

Conseils

  • Assurez-vous de choisir une plage d'IDs subordonnés qui ne chevauche pas les IDs existants sur votre système.
  • Si vous avez déjà utilisé une plage d'IDs subordonnés pour un autre utilisateur, assurez-vous de choisir une nouvelle plage qui ne chevauche pas la précédente.

Notes

  • Les IDs subordonnés sont utilisés pour mapper les IDs d'utilisateur et de groupe à l'intérieur d'un conteneur vers des IDs différents sur le système hôte.
  • Les fichiers /etc/subuid et /etc/subgid sont utilisés pour définir ces mappings.

En suivant ces étapes, vous devriez être en mesure de résoudre le problème lié à Podman et aux IDs subordonnés.

Erreur sd-bus call: Operation not permitted (OCI permission denied)

Problème

Lors du démarrage d'un conteneur, vous obtenez l'erreur : Error: crun: sd-bus call: Operation not permitted: Permission denied: OCI permission denied

Cause

Podman tente d'utiliser systemd comme gestionnaire de cgroups (cgroup_manager). Dans certains environnements (notamment sur Debian ou des sessions gérées), le runtime crun n'arrive pas à communiquer avec le bus utilisateur de systemd pour créer un "scope" de contrôle.

Résolution

Forcer l'utilisation de cgroupfs au lieu de systemd.

  1. Créez ou modifiez le fichier ~/.config/containers/containers.conf : 

    [engine]
cgroup_manager = "cgroupfs"

  2. Note importante : Les conteneurs existants conservent le paramètre utilisé lors de leur création. Si un conteneur a été créé avant cette modification, il doit être supprimé et recréé pour prendre en compte le nouveau gestionnaire.

Erreur open .../merged: Permission denied avec --userns=keep-id

Problème

Le conteneur refuse de démarrer avec une erreur de permission sur le répertoire merged de l'overlay, alors que vous êtes propriétaire des fichiers.

Cause

C'est une subtilité du mode rootless combiné à --userns=keep-id (utilisé par défaut par Distrobox). - En mode rootless classique, l'utilisateur interne root est mappé sur votre utilisateur hôte (UID 1000). - Avec keep-id, votre UID 1000 reste 1000 à l'intérieur du conteneur. Par conséquent, le root interne est mappé sur un UID secondaire (défini dans /etc/subuid). - Si votre répertoire personnel ou les sous-répertoires de ~/.local/share/containers/storage ont des permissions trop restrictives (ex: 700), cet UID secondaire ne peut pas traverser les dossiers pour accéder au système de fichiers du conteneur.

Résolution

Il faut autoriser la traversée des répertoires (exécution +x) pour les "autres" (ou via des ACLs) sur toute la chaîne menant au stockage.

# Rendre le home et les dossiers parents traversables
chmod 711 /home/$USER
chmod 711 ~/.local
chmod 711 ~/.local/share
chmod 711 ~/.local/share/containers

# Rendre le stockage lui-même accessible
chmod 755 ~/.local/share/containers/storage
chmod 755 ~/.local/share/containers/storage/overlay