Conteneurs · Glossaire Linux

Cycle de vie d'un conteneur

Lancer, lister, inspecter, entrer dedans, arrêter, supprimer. Le quotidien d'un container engine.

`podman run · ps · exec · logs · stop · rm`

Démarrer un conteneur et le piloter au quotidien

Un conteneur = un processus isolé du reste du système (réseau, FS, namespaces utilisateur) démarré à partir d'une image. podman run télécharge l'image si nécessaire, crée le conteneur et le démarre. podman est rootless par défaut : un utilisateur normal peut lancer un conteneur sans sudo, contrairement à Docker historiquement.

Flags de podman run essentiels

-d	Detached : tourne en arrière-plan, renvoie l'ID. Sans `-d`, on est attaché à stdout.
--name NOM	Nom symbolique (sinon nom aléatoire type `quirky_einstein`).
-p HOTE:CONTAINER	Publie un port. `-p 8080:80` = port 80 du conteneur exposé sur le 8080 de l'hôte.
-v CHEMIN:CHEMIN[:ro]	Monte un volume. `:Z` ou `:z` ajoutent un label SELinux (RHEL/Fedora).
-e VAR=VAL	Variable d'environnement passée au conteneur.
--rm	Supprime automatiquement le conteneur quand il s'arrête (idéal pour les tests éphémères).
-it	Mode interactif + TTY — pour ouvrir un shell ou lancer une commande qui attend de l'input.
--network=host	Conteneur sur la pile réseau de l'hôte (pas d'isolation), équivalent `ip a` de l'hôte visible dedans.
--restart=always	Redémarre tout seul s'il crash. `unless-stopped` = sauf si on l'a arrêté volontairement.

$ podman run --rm -it docker.io/library/alpine sh

Lance un shell dans un conteneur Alpine éphémère. Le nom qualifié docker.io/library/alpine évite la résolution des noms courts, qui dépend des alias et de registries.conf. --rm supprime le conteneur à sa sortie, pas l'image.

$ podman run -d --name web -p 8080:80 docker.io/library/nginx

Publie le port TCP 80 du conteneur sur le port 8080 de toutes les adresses de l'hôte, pas seulement localhost. Pour un accès local uniquement : -p 127.0.0.1:8080:80. En rootless, les ports autorisés dépendent notamment de net.ipv4.ip_unprivileged_port_start ; 8080 évite les ports bas habituels.

$ podman ps

CONTAINER ID  IMAGE                          STATUS         PORTS                  NAMES
7a3f1c2e8b4d  docker.io/library/nginx:latest Up 2 minutes   0.0.0.0:8080->80/tcp   web

Liste les conteneurs en cours ; -a inclut ceux arrêtés et -q n'affiche que les identifiants. Pour arrêter tous les conteneurs de cet utilisateur, podman stop --all évite une substitution vide si aucun conteneur ne tourne.

$ podman logs -f web

Suit les logs (stdout/stderr) du conteneur en temps réel — équivalent tail -f. Sans -f, dump tout puis sort. --tail 100 limite aux 100 dernières lignes.

$ podman exec -it web sh

Ouvre un shell dans un conteneur déjà en cours. Indispensable pour déboguer : on inspecte le système de fichiers, on lit la config telle qu'elle est vue par l'application. À la sortie, le conteneur continue de tourner.

$ podman stop web
podman rm web
podman stop -a && podman rm -a    # tout d'un coup

Arrêt propre (SIGTERM puis SIGKILL après 10 s) puis suppression. -a = all. Les conteneurs supprimés ne sont pas récupérables, mais l'image elle reste — pour la supprimer aussi : podman rmi IMAGE.

Compatibilité Docker : La syntaxe des commandes de base est proche de Docker, mais un alias docker=podman ne garantit pas leur compatibilité complète. Pour Compose, podman compose délègue à un fournisseur externe tel que podman-compose ou docker-compose ; podman kube play prend en charge un sous-ensemble du format Kubernetes, qui est un autre format de description.

Voir aussi : podman build · image podman pod · systemd ps

`docker compose`

Décrire et piloter une application multi-conteneurs

docker compose lit un fichier compose.yaml pour gérer plusieurs services, leurs réseaux et leurs volumes. Compose v2 s'utilise comme sous-commande du CLI Docker. Avec Podman, podman compose accepte les mêmes commandes mais délègue le travail à un fournisseur installé à part (docker-compose ou podman-compose) ; podman kube play lance aussi des pods décrits en YAML Kubernetes. La compatibilité n'est pas toujours complète.

$ docker compose config

Valide et affiche la configuration fusionnée sans démarrer les services.

$ docker compose up -d

Crée et démarre les services en arrière-plan à partir du fichier Compose du répertoire courant.

$ docker compose ps
docker compose logs --tail 100 web
docker compose exec web sh

Liste les services, affiche les 100 dernières lignes de logs puis ouvre un shell du service web. Pour un suivi continu, exécuter séparément docker compose logs -f web ; cette commande bloque jusqu'à son interruption.

$ docker compose down

Arrête et supprime les conteneurs et réseaux créés par le projet. Les volumes nommés sont conservés sauf si l'on ajoute --volumes.

Attention aux volumes : docker compose down --volumes supprime aussi les volumes déclarés par le projet et peut donc effacer des données persistantes. Vérifier la configuration avant de l'utiliser.

Voir aussi : podman run podman pod systemctl

`podman inspect · stats · top · cp`

Diagnostiquer un conteneur : configuration réelle, ressources, processus, fichiers

Quand un conteneur ne se comporte pas comme prévu, ces commandes répondent aux premières questions : avec quelle configuration tourne-t-il vraiment, que consomme-t-il, quels processus contient-il, et que contient tel fichier à l'intérieur.

Commandes principales

inspect NOM	Toute la configuration en JSON ; `--format` extrait un champ précis.
stats [--no-stream]	Consommation CPU, mémoire et réseau, en direct ou en une seule lecture.
top NOM	Processus en cours dans le conteneur, avec leur utilisateur.
cp SOURCE DESTINATION	Copie un fichier entre l'hôte et le conteneur, dans les deux sens (`NOM:/chemin`).
port NOM	Ports publiés et leur correspondance sur l'hôte.

$ podman inspect web --format '{{.State.Status}}'

running

Extrait un seul champ au lieu de parcourir des centaines de lignes de JSON.

$ podman inspect web --format '{{json .Config.Env}}'

Variables d'environnement réellement passées au conteneur, utile quand une option de -e semble ignorée.

$ podman top web user pid args

USER        PID         COMMAND
root        1           nginx: master process nginx -g daemon off;
nginx       25          nginx: worker process

Sous quel compte tourne chaque processus à l'intérieur du conteneur.

$ podman cp web:/etc/nginx/conf.d/default.conf .
podman cp default.conf web:/etc/nginx/conf.d/

Récupère un fichier de configuration pour l'étudier, puis renvoie la version corrigée.

Un fichier copié ne survit pas à la recréation : podman cp modifie le conteneur en place. S'il est supprimé puis recréé, la modification disparaît. Pour un changement durable, utiliser un volume ou reconstruire l'image.

Voir aussi : podman run · ps · exec podman volume ps

`podman healthcheck · auto-update`

Surveiller l'état d'un conteneur, le redémarrer et le mettre à jour

Un conteneur peut tourner sans fonctionner : processus vivant mais service bloqué. Une vérification de santé lance régulièrement une commande de test et marque le conteneur healthy ou unhealthy. Une politique de redémarrage le relance s'il s'arrête, et podman auto-update le recrée quand une nouvelle version de son image est publiée.

Options et commandes principales

--health-cmd CMD	Commande de test : un code de sortie 0 signifie que le service va bien.
--health-interval DURÉE	Fréquence du test, par exemple `30s`.
healthcheck run NOM	Lance le test immédiatement.
--restart POLITIQUE	`no`, `on-failure`, `always` ou `unless-stopped`.
auto-update [--dry-run]	Met à jour les conteneurs marqués pour cela ; `--dry-run` affiche ce qui serait fait.

$ podman run -d --name web --health-cmd 'wget -qO- http://localhost/ > /dev/null || exit 1' --health-interval 30s docker.io/library/nginx:alpine

Vérifie toutes les 30 secondes que la page d'accueil répond. La commande de test s'exécute dans le conteneur : l'outil utilisé (ici wget) doit exister dans l'image.

$ podman healthcheck run web
podman ps

CONTAINER ID  IMAGE                           COMMAND               CREATED        STATUS                  PORTS  NAMES
4f1c2a9b8d3e  docker.io/library/nginx:alpine  nginx -g daemon o...  2 minutes ago  Up 2 minutes (healthy)         web

L'état de santé apparaît dans la colonne STATUS.

$ podman auto-update --dry-run

Liste les conteneurs gérés par systemd qui seraient mis à jour. Un conteneur Quadlet s'y inscrit avec la ligne AutoUpdate=registry dans sa section [Container], et une image désignée par son nom complet.

Après un redémarrage de la machine : sans démon, podman ne relance pas seul les conteneurs en --restart=always au démarrage : il faut activer podman-restart.service (systemctl --user enable podman-restart en rootless). Pour un service durable, préférer Quadlet.

Voir aussi : podman pod · Quadlet · rootless Containerfile systemctl

Volumes et réseaux

Conserver les données au-delà de la vie d'un conteneur, partager des fichiers avec l'hôte et relier les conteneurs entre eux.

`podman volume`

Conserver les données d'un conteneur et partager des fichiers avec l'hôte

Tout ce qu'un conteneur écrit disparaît avec lui. Pour garder des données, on monte un volume nommé, géré par podman, ou un répertoire de l'hôte (bind mount). Le volume nommé est le choix par défaut pour une base de données ; le répertoire de l'hôte sert quand on veut éditer les fichiers directement, comme le contenu d'un site.

Commandes et options principales

volume create NOM	Crée un volume nommé.
volume ls / inspect NOM	Liste les volumes ou affiche le détail d'un volume, dont son emplacement sur l'hôte.
volume rm NOM	Supprime un volume et ses données.
-v NOM:/chemin	Monte un volume nommé dans le conteneur.
-v /hôte:/chemin:Z	Monte un répertoire de l'hôte ; `:Z` l'étiquette pour SELinux (`:z` s'il est partagé entre conteneurs), `:ro` le passe en lecture seule.

$ podman volume create pgdata
podman run -d --name db -v pgdata:/var/lib/postgresql/data -e POSTGRES_PASSWORD=change-moi docker.io/library/postgres:16

Les données de la base vivent dans le volume pgdata : supprimer et recréer le conteneur, par exemple pour changer de version mineure, ne les efface pas.

$ podman run -d --name site -p 8080:80 -v ~/site:/usr/share/nginx/html:ro,Z docker.io/library/nginx:alpine

Sert le contenu de ~/site en lecture seule. Sans Z, sur Fedora ou RHEL, nginx répondrait 403 : SELinux interdit au conteneur de lire le répertoire.

$ podman volume inspect pgdata --format '{{.Mountpoint}}'

/home/alice/.local/share/containers/storage/volumes/pgdata/_data

Emplacement réel des données sur l'hôte, à inclure dans les sauvegardes.

Permission denied dans le conteneur : sur une distribution avec SELinux, un répertoire de l'hôte monté sans :Z ou :z est illisible depuis le conteneur, même avec des droits Unix corrects. Ne jamais ajouter :Z sur /home, /etc ou /usr : le réétiquetage s'applique aussi sur l'hôte et peut casser le système.

Propriétaires étranges en rootless : les fichiers créés par root dans le conteneur appartiennent, sur l'hôte, à un identifiant de la plage /etc/subuid. podman unshare chown permet de les modifier depuis l'hôte, avec la même correspondance d'identifiants que le conteneur.

Voir aussi : podman network SELinux podman pod · Quadlet · rootless

`podman network`

Relier des conteneurs entre eux et les joindre par leur nom

Sur le réseau par défaut, les conteneurs ne se trouvent pas par leur nom. Sur un réseau créé avec podman network create, chacun est joignable par le nom de son conteneur : une application atteint sa base de données à l'adresse db au lieu d'une IP qui change à chaque recréation.

Commandes principales

network create NOM	Crée un réseau avec résolution des noms entre conteneurs.
network ls / inspect NOM	Liste les réseaux, ou affiche le sous-réseau et les conteneurs d'un réseau.
network connect NOM CONTENEUR	Ajoute un conteneur déjà lancé à un réseau ; `disconnect` l'en retire.
network rm NOM	Supprime un réseau inutilisé.
--network NOM	Option de `podman run` qui place le conteneur sur ce réseau.

$ podman network create app
podman run -d --name db --network app -e POSTGRES_PASSWORD=change-moi docker.io/library/postgres:16
podman run -d --name web --network app -p 8080:80 docker.io/library/nginx:alpine

Les deux conteneurs partagent le réseau app : depuis web, la base est joignable à db:5432. Seul le port de web est publié sur l'hôte.

$ podman run --rm --network app docker.io/library/alpine wget -qO- http://web/

Teste la résolution par nom depuis un conteneur jetable sur le même réseau. Le même test sur le réseau par défaut échoue avec bad address.

Réseau ou pod : les conteneurs d'un même pod partagent leur réseau et se joignent par localhost. Un réseau dédié convient mieux pour des services indépendants qui doivent seulement communiquer.

Voir aussi : podman volume podman pod · Quadlet · rootless ss

Images

Une image est un <em>template</em> en lecture seule. On en télécharge depuis un registre (Docker Hub, Quay, GHCR…) ou on en construit avec un <code>Containerfile</code> (=<code>Dockerfile</code>, même syntaxe).

`podman build · pull · images · rmi`

Récupérer, construire, lister, supprimer des images

Trois sources d'image : un registre public (docker.io, quay.io, ghcr.io…) avec pull, un Containerfile local avec build, ou un export d'un autre hôte avec load. Les images sont stockées dans ~/.local/share/containers/ (rootless) ou /var/lib/containers/ (root).

$ podman pull docker.io/library/postgres:16

Télécharge l'image Postgres 16 depuis Docker Hub. library/ est le namespace des images officielles. Le tag :16 fige une version majeure ; sans tag, :latest est sous-entendu (instable, à éviter en production).

$ podman images

REPOSITORY                       TAG     IMAGE ID      SIZE
docker.io/library/nginx          latest  a8758716bb6a  192 MB
docker.io/library/postgres       16      bb91eaf69b91  450 MB
docker.io/library/alpine         latest  9c6f07244728  7.34 MB

Affiche les images locales et leur taille. Des images peuvent partager des couches : la somme des tailles affichées n'est pas l'espace supplémentaire réellement consommé. Examiner podman system df -v pour détailler le stockage partagé et récupérable.

Syntaxe

# Containerfile
FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
CMD ["python", "app.py"]

Les instructions : recette minimaliste pour une app Python. FROM = image de base, WORKDIR = répertoire de travail dans le conteneur, COPY = depuis le contexte de build (le répertoire courant), RUN = commande à l'exécution du build, CMD = commande par défaut au démarrage du conteneur.

$ podman build -t monapp:1.0 .

Construit l'image depuis le Containerfile dans le répertoire courant (. = contexte de build). -t monapp:1.0 donne un nom et un tag. podman détecte Containerfile en priorité, puis Dockerfile en fallback — les deux ont la même syntaxe.

$ podman rmi monapp:1.0

Supprime une image (les conteneurs basés dessus doivent être supprimés d'abord, sinon --force). podman image prune nettoie les images dangling (sans tag, résultats de builds intermédiaires). podman system prune -a nettoie agressivement tout ce qui n'est pas utilisé — à manier avec précaution.

$ podman login docker.io
podman tag monapp:1.0 docker.io/alice/monapp:1.0
podman push docker.io/alice/monapp:1.0

Publie une image : login authentifie, tag ajoute un nom à l'image locale sans supprimer le précédent et push l'envoie. Sous Linux, le fichier d'authentification par défaut est ${XDG_RUNTIME_DIR}/containers/auth.json, souvent temporaire ; pour une persistance explicite, utiliser --authfile avec un fichier protégé, par exemple ~/.config/containers/auth.json.

Réduire la taille : les images Python/Node officielles existent en variantes -slim et -alpine beaucoup plus petites. Sur du Go ou du Rust statiquement compilé, on peut même partir de scratch (image vide) — image finale qui pèse parfois 10 Mo au lieu de 500 Mo.

Voir aussi : podman run · ps · exec tar

`Instructions du Containerfile`

Écrire la recette d'une image : FROM, RUN, COPY, USER, CMD…

Un Containerfile (même syntaxe qu'un Dockerfile) décrit pas à pas comment construire une image : l'image de départ, les commandes à exécuter, les fichiers à copier et la commande lancée au démarrage. Chaque instruction crée une couche, mise en cache tant que ce qui la précède ne change pas.

Syntaxe

# Containerfile — exemple à adapter
FROM docker.io/library/alpine:3.20
RUN adduser -D app
WORKDIR /app
COPY app.sh .
USER app
EXPOSE 8080
HEALTHCHECK --interval=30s CMD wget -qO- http://localhost:8080/ || exit 1
ENTRYPOINT ["/app/app.sh"]
CMD ["--aide"]

Instructions principales

FROM IMAGE	Image de départ, idéalement avec une version précise plutôt que `latest`.
RUN COMMANDE	Exécute une commande pendant la construction (installer des paquets, compiler).
COPY SOURCE DEST	Copie des fichiers depuis le contexte de construction ; préférer `COPY` à `ADD`, qui décompresse et télécharge.
WORKDIR CHEMIN	Répertoire de travail des instructions suivantes et du conteneur.
ENV / ARG	Variable disponible dans le conteneur (`ENV`) ou seulement pendant la construction (`ARG`).
USER COMPTE	Compte sous lequel tournent les instructions suivantes et le conteneur.
EXPOSE PORT	Documente le port écouté ; ne publie rien, c'est `-p` qui le fait.
ENTRYPOINT [...]	Programme toujours lancé au démarrage.
CMD [...]	Arguments par défaut d'`ENTRYPOINT`, ou commande par défaut s'il n'y en a pas ; remplacé par ce qui suit le nom de l'image dans `podman run`.
HEALTHCHECK CMD ...	Vérification de santé intégrée à l'image.

$ podman build --format docker -t monapp:1.0 .

Construit l'image. --format docker est nécessaire pour conserver HEALTHCHECK : avec le format OCI utilisé par défaut, podman l'ignore et affiche seulement un avertissement.

$ podman run --rm monapp:1.0
podman run --rm monapp:1.0 --version

args: --aide
args: --version

Sans argument, l'image lance ENTRYPOINT avec le CMD par défaut ; un argument remplace seulement le CMD.

$ podman run --rm -it --entrypoint sh monapp:1.0

Remplace l'ENTRYPOINT pour ouvrir un shell dans l'image et l'explorer.

Ne pas tourner en root : sans instruction USER, le processus du conteneur tourne en root dans le conteneur. Créer un compte dédié et passer dessus après les étapes qui ont besoin de root, comme l'installation des paquets.

Voir aussi : podman build · pull · images podman healthcheck · auto-update useradd

`podman tag · push · skopeo`

Publier une image dans un registre et inspecter des images distantes

Une image se publie dans un registre (Docker Hub, Quay, GitHub, ou un registre interne) sous un nom complet : registre/espace/image:tag. podman tag lui donne ce nom, podman push l'envoie. skopeo interroge ou copie des images directement dans les registres, sans les télécharger en local.

Commandes principales

podman tag SOURCE NOM	Ajoute un nom à une image locale, sans la dupliquer.
podman push NOM	Envoie l'image vers le registre indiqué dans son nom (après `podman login`).
skopeo inspect docker://IMAGE	Métadonnées d'une image distante : digest, architecture, date, étiquettes.
skopeo list-tags docker://IMAGE	Liste les tags disponibles.
skopeo copy SOURCE DEST	Copie une image entre registres ou vers une archive, sans passer par le stockage local.

$ podman tag monapp:1.0 registry.exemple.fr/equipe/monapp:1.0
podman push registry.exemple.fr/equipe/monapp:1.0

Publie l'image construite localement dans un registre interne.

$ skopeo inspect docker://docker.io/library/nginx:alpine | jq -r .Digest

sha256:d9e853e87e55526f6b2917df91a2115c36dd7c696a35be12163d44e6e2a4b6bc

Le digest identifie exactement le contenu de l'image. nginx:alpine peut désigner demain une autre image ; nginx@sha256:… désigne toujours la même.

$ skopeo list-tags docker://docker.io/library/postgres | jq -r '.Tags[]' | grep '^16' | tail -3

Vérifie les versions disponibles avant de choisir un tag précis.

Épingler les versions : latest change sans prévenir. En production, utiliser un tag précis (postgres:16.4) ou un digest, pour qu'un redéploiement redonne exactement la même image.

Voir aussi : podman build · pull · images Containerfile jq

Spécificités podman

Ce qui distingue podman de Docker : pods (groupes de conteneurs partagés), intégration native avec systemd pour démarrer des conteneurs au boot sans démon, et mode rootless par défaut.

`podman pod · Quadlet · rootless`

Groupes de conteneurs, démarrage au boot, mode utilisateur

Pod est un concept emprunté à Kubernetes : un groupe de conteneurs qui partagent la même pile réseau (localhost commun, ports exposés une fois pour tout le pod). Quadlet permet de décrire les conteneurs et pods dans des fichiers dédiés que systemd transforme en unités. Rootless : tout tourne dans les namespaces utilisateur, aucun privilège root requis.

$ podman pod create --name app -p 8080:80
podman run -d --pod app --name front docker.io/library/nginx
podman run -d --pod app --name api  monapp:1.0

Crée un pod et deux conteneurs partageant le même réseau. Ils peuvent communiquer via localhost si l'application écoute sur le port attendu. L'image nginx standard ne configure pas automatiquement un reverse proxy : monter un nginx.conf adapté pour transmettre à une API sur localhost:3000. Les deux applications ne peuvent pas écouter sur le même port du pod.

$ podman kube generate app > app.yaml

Exporte le pod existant. Pour le recréer sur un autre hôte préparé, utiliser podman kube play app.yaml après y avoir copié le manifeste, les données et les images nécessaires. Sur le même hôte, les noms et les ports du pod initial peuvent entrer en conflit. Les objets Kubernetes et les volumes pris en charge dépendent de Podman et de sa version.

Syntaxe

# ~/.config/containers/systemd/web.container
[Container]
Image=docker.io/library/nginx:latest
PublishPort=8080:80

[Install]
WantedBy=default.target

Mise en service : Quadlet (Podman 4.4+) décrit le conteneur dans un fichier systemd généré. Après création ou modification : systemctl --user daemon-reload, puis démarrer avec systemctl --user start web.service. Le bloc [Install] rattache le service à default.target au prochain démarrage du générateur ; les unités Quadlet ne s'activent pas avec systemctl enable. La disponibilité et le chemin de recherche dépendent de la version de Podman et du mode rootless/rootful.

$ podman generate systemd --new --name web --files
mkdir -p ~/.config/systemd/user
mv container-web.service ~/.config/systemd/user/
systemctl --user daemon-reload
systemctl --user enable container-web.service
loginctl enable-linger $USER

Compatibilité ancienne : podman generate systemd est déprécié au profit de Quadlet. Copier le fichier généré dans ~/.config/systemd/user/ avant daemon-reload et enable. Garder cette procédure pour comprendre ou migrer des unités existantes. loginctl enable-linger permet au service utilisateur de tourner même sans session ouverte.

$ cat /etc/subuid
cat /etc/subgid
podman unshare cat /proc/self/uid_map

Le mappage dépend de /etc/subuid, /etc/subgid et de --userns. Exemple par défaut avec un utilisateur hôte 1000 et une plage commençant à 100000 : UID 0 du conteneur correspond à 1000 sur l'hôte ; UID 1 à 100000 ; UID 100 à 100099. Inspecter les tables uid_map et gid_map plutôt que supposer ces nombres.

Limites du rootless : Le seuil des ports accessibles sans privilèges est configurable via net.ipv4.ip_unprivileged_port_start (souvent 1024). Le modifier affecte tous les processus concernés du namespace réseau, pas seulement Podman. Utiliser un port haut ou un reverse proxy constitue une solution courante ; la transmission d'un socket systemd exige une application et une configuration compatibles.

Migration depuis Docker : En rootless, un bind mount reste soumis aux permissions de l'utilisateur hôte, aux mappages UID/GID et à SELinux. Un chemin sous /var peut être accessible s'il a été préparé avec les bons droits ; il n'est pas interdit par son emplacement. Choisir un dossier accessible ou un volume géré, puis adapter les droits et labels sans basculer automatiquement en root.

Voir aussi : podman run · ps · exec systemctl loginctl sysctl

Entretien

Surveiller et récupérer l'espace disque occupé par les images, les conteneurs et les volumes.

`podman system df · prune`

Voir et récupérer l'espace disque occupé par podman

Images anciennes, conteneurs arrêtés, volumes orphelins et cache de construction s'accumulent vite. podman system df montre ce qui occupe la place et ce qui peut être récupéré ; les commandes prune suppriment ce qui n'est plus utilisé.

Commandes principales

system df [-v]	Espace occupé par les images, conteneurs et volumes, et part récupérable ; `-v` détaille chaque élément.
container prune	Supprime les conteneurs arrêtés.
image prune [-a]	Supprime les images sans nom ; `-a` toutes celles qu'aucun conteneur n'utilise.
volume prune	Supprime les volumes qu'aucun conteneur n'utilise.
system prune [--all] [--volumes]	Tout ce qui précède en une commande, volumes compris avec `--volumes`.

$ podman system df

TYPE           TOTAL       ACTIVE      SIZE        RECLAIMABLE
Images         12          3           4.21GB      3.08GB (73%)
Containers     5           3           18.4MB      2.1MB (11%)
Local Volumes  4           2           1.12GB      310MB (27%)

La colonne RECLAIMABLE indique ce qu'un nettoyage libérerait.

$ podman image prune -a

Libère la place prise par les images inutilisées, après confirmation. Elles seront retéléchargées si on en a de nouveau besoin.

--volumes efface des données : un volume inutilisé peut être la base de données d'un conteneur supprimé en attendant d'être recréé. Lister avec podman volume ls avant un system prune --volumes.

Voir aussi : podman volume df du