đł Podman & LXD â Conteneurs (Rootless & SystĂšme)
Guide complet IDEOâLab sur les alternatives Ă Docker (sans daemon, sĂ©curitĂ©, conteneurs systĂšme).
Podman : Vue d'ensemble
L'alternative "Rootless" Ă Docker. Sans daemon.
Podman Rootless DaemonlessInstallation Podman
apt (Debian/Ubuntu) & dnf (RHEL/Rocky/Fedora).
Commandes Podman
alias docker=podman, podman run, podman ps, podman build.
Concept : Rootless
User Namespaces, subuid/subgid, sécurité.
Concept : Pods
podman pod create (similaire Ă Kubernetes).
Podman Compose
podman-compose (alternative Ă docker compose).
Intégration Systemd
podman generate systemd (services "rootless").
LXD : Vue d'ensemble
Conteneurs SystĂšme (OS complet) vs Docker (App).
LXD Conteneur SystĂšmeInstallation LXD (snap)
snap install lxd, lxd init (storage pools).
Commandes LXD (lxc)
lxc launch, lxc list, lxc exec, lxc file.
Comparaison
Docker vs Podman vs LXD (cas d'usage).
Comparaison Cas d'usageCheat-sheet Podman
Commandes (run, ps, images, pod).
Qu'est-ce que Podman ?
Podman (Pod Manager) est un moteur de conteneurs open-source (Red Hat) conçu pour ĂȘtre une alternative directe Ă Docker. Son objectif principal est la **sĂ©curitĂ©**.
Compatibilité (alias docker=podman) :
Podman utilise les mĂȘmes commandes que Docker (podman run, podman build, podman ps). La transition est transparente pour un dĂ©veloppeur.
1. Daemonless (Sans Daemon)
Docker : Utilise un daemon (dockerd) qui tourne en tant que root. Le client (docker) parle au daemon. Si le daemon plante, tous les conteneurs plantent.
Podman : N'a **pas de daemon** central. podman run lance le conteneur comme un processus enfant direct du shell (via fork/exec). C'est plus simple, plus stable et s'intĂšgre mieux avec systemd.
2. Rootless (Sans Root)
Docker (par défaut) : Le daemon dockerd tourne en root. Si un conteneur "s'échappe" (exploit), il obtient les privilÚges root sur l'hÎte. (C'est un risque de sécurité majeur).
Podman (par dĂ©faut) : Conçu pour ĂȘtre "Rootless". Un utilisateur normal (non-root) peut lancer des conteneurs. Si un conteneur s'Ă©chappe, il n'a que les privilĂšges de l'utilisateur (ex: ideo_user). (Voir 1.4).
RHEL / Rocky / AlmaLinux / Fedora
Podman est l'outil par défaut sur l'écosystÚme RHEL (il remplace docker).
sudo dnf install -y podman
Ubuntu / Debian
sudo apt update sudo apt install -y podman
Setup "Rootless" (subuid/subgid)
Pour que le mode "rootless" fonctionne, l'utilisateur (ex: ideo_user) doit avoir des UID/GID "subordonnés" (une plage d'ID qu'il peut gérer dans ses namespaces).
C'est souvent configuré automatiquement à la premiÚre exécution de podman (ou à l'installation de podman sur certaines distros).
Vérification :
# Doit retourner une ligne pour votre user cat /etc/subuid # ideo_user:100000:65536 cat /etc/subgid # ideo_user:100000:65536
Si absent, ajoutez-les (RHEL) : sudo usermod --add-subuids 100000-165535 ideo_user
alias docker=podman)Les commandes sont identiques à Docker. Il est courant de créer un alias.
# (Ajouter Ă .bashrc / .zshrc) alias docker=podman
| Commande Docker | Commande Podman (Rootless) | Notes |
|---|---|---|
docker run ... | podman run ... | Identique. |
docker ps | podman ps | Identique. |
docker build ... | podman build ... | Identique. (Utilise buildah en interne). |
docker images | podman images | Identique. |
docker pull | podman pull | Identique. |
docker stop | podman stop | Identique. |
docker rm | podman rm | Identique. |
docker exec ... | podman exec ... | Identique. |
Comment ça marche ? (User Namespaces)
Podman utilise les User Namespaces du noyau Linux. Cela permet à un processus (le conteneur) de *penser* qu'il s'exécute en tant que root (UID 0) *à l'intérieur* du conteneur, alors qu'il s'exécute en tant qu'utilisateur normal *à l'extérieur* (sur l'hÎte).
C'est un "mapping" d'ID.
Exemple de Mapping (/etc/subuid)
ideo_user:100000:65536
(L'hÎte donne 65536 IDs à ideo_user, commençant à 100000).
(Ă l'intĂ©rieur du conteneur) Utilisateur | UID ------------|---- root | 0 www-data | 33 (Mapping) | ⌠(Sur le serveur HĂŽte) Utilisateur | UID ------------|---- ideo_user | 100000 (MappĂ© Ă 'root') ideo_user | 100033 (MappĂ© Ă 'www-data')
Si le conteneur est compromis (en tant que root), l'attaquant n'est que ideo_user (UID 100000) sur l'hĂŽte, sans aucun privilĂšge.
Pods (Kubernetes)
Podman apporte le concept de "Pod" (de Kubernetes) directement, sans docker compose.
Un Pod est un groupe de conteneurs qui partagent le **mĂȘme espace rĂ©seau** (la mĂȘme IP, localhost) et les mĂȘmes volumes (optionnel).
Cas d'usage : Une application (ex: WordPress) et son "sidecar" (ex: un exporteur de métriques).
Exemple (App + Sidecar)
# 1. Créer un pod (il crée un conteneur 'infra' pause) podman pod create --name mon-app-pod -p 8080:80 # 2. Lancer l'app DANS le pod podman run -d --pod mon-app-pod --name mon-app nginx # 3. Lancer le sidecar DANS le pod # (Il peut 'curl localhost:80' pour parler à nginx) podman run -d --pod mon-app-pod --name mon-sidecar alpine ... # 4. Lister les pods et les conteneurs podman pod ps podman ps -a --pod
podman-compose
podman-compose est un script Python tiers (pas de Red Hat) qui implémente l'API docker-compose en utilisant podman en backend.
Installation
# (Via pip) pip install podman-compose # (Ou via dnf/apt) sudo dnf install podman-compose
Utilisation
Il utilise exactement les mĂȘmes fichiers docker-compose.yml.
# (Au lieu de 'docker compose up') podman-compose up -d podman-compose down podman-compose logs
Note : podman-compose crée un "Pod" pour chaque docker-compose.yml.
Générer des fichiers .service
L'intégration systemd est la force de Podman (grùce à son modÚle sans daemon).
Vous n'avez pas besoin d'écrire des fichiers .service complexes. Vous lancez votre conteneur (ou pod) et Podman le génÚre pour vous.
# 1. Créer un conteneur (ex: Nginx) podman run -d --name nginx_web -p 8080:80 nginx # 2. Générer le .service podman generate systemd --name nginx_web --files # (Crée 'container-nginx_web.service') # 3. (Optionnel) Générer pour un Pod podman generate systemd --name mon-app-pod --files # (Crée 'pod-mon-app-pod.service' qui gÚre tous les conteneurs)
Services "Rootless" (Utilisateur)
Pour gérer un service systemd en tant qu'utilisateur (sans sudo), on le place dans ~/.config/systemd/user/.
# (Exécuté en tant que 'ideo_user')
# 1. Créer le dossier (si absent)
mkdir -p ~/.config/systemd/user/
# 2. Générer le service dans ce dossier
podman generate systemd --name nginx_web --files \
--new \
--destdir ~/.config/systemd/user/
# 3. Utiliser 'systemctl --user' (sans sudo)
systemctl --user daemon-reload
systemctl --user enable --now container-nginx_web.service
# 4. (Pour que le service tourne aprÚs déconnexion)
sudo loginctl enable-linger ideo_userConteneurs SystĂšme (LXC)
LXD n'est PAS un concurrent de Docker/Podman. Il ne gĂšre pas le mĂȘme *type* de conteneur.
LXD est un "hyperviseur" de conteneurs (basé sur LXC) qui lance des **Conteneurs SystÚme**.
Conteneur d'Application (Docker/Podman)
- But : Lancer UN SEUL processus (ex:
nginx,python app.py). - Contenu : Minimaliste (juste l'app et ses libs).
- PID 1 : L'application.
- Analogie : Un "exécutable" portable.
Conteneur SystĂšme (LXD)
- But : Lancer un **OS complet** (ex: Ubuntu 22.04).
- Contenu : Complet (
systemd,sshd,cron,apt...). - PID 1 :
/sbin/init(systemd). - Analogie : Une **VM ultra-légÚre** (démarre en 1s, utilise 20Mo de RAM).
Cas d'usage LXD
Idéal pour les développeurs ou admins qui veulent isoler des environnements complets (ex: un serveur de staging, un lab de test) sans la lourdeur des VMs.
1. Installation (snap)
LXD (par Canonical) est distribué via snap.
# (Installer snapd si absent) sudo apt install snapd # Installer LXD sudo snap install lxd
2. Initialisation (lxd init)
lxd init est l'assistant de configuration. Pour une utilisation locale, les défauts sont souvent suffisants.
sudo lxd init # (Accepter les défauts, sauf pour :) # -> Create a new storage pool? (yes) # -> Name of the new storage pool: default # -> What backend to use (zfs, btrfs, dir)? dir # (Choisir 'dir' si vous n'avez pas ZFS/BTRFS)
lxc)Lancer & Lister
# (Ajouter l'utilisateur au groupe lxd) sudo usermod -aG lxd $USER newgrp lxd # Lancer un conteneur Ubuntu 22.04 lxc launch images:ubuntu/22.04 mon-ubuntu # Lister les conteneurs lxc list +-----------+---------+-------------------+ | NAME | STATE | IPV4 | +-----------+---------+-------------------+ | mon-ubuntu| RUNNING | 10.x.x.x (eth0) | +-----------+---------+-------------------+
Interagir
# Obtenir un shell (root) dans le conteneur lxc exec mon-ubuntu -- /bin/bash # (Dans le conteneur) root@mon-ubuntu:~# apt update root@mon-ubuntu:~# systemctl status # Copier des fichiers (HĂŽte -> Conteneur) lxc file push ./mon_fichier.txt mon-ubuntu/root/ # Copier (Conteneur -> HĂŽte) lxc file pull mon-ubuntu/root/test.txt . # ArrĂȘter / Supprimer lxc stop mon-ubuntu lxc delete mon-ubuntu
| CritĂšre | Docker | Podman (Rootless) | LXD |
|---|---|---|---|
| Analogie | Exécutable d'App | Exécutable d'App (Sécurisé) | VM ultra-légÚre |
| But | Conteneur d'Application | Conteneur d'Application | Conteneur SystĂšme (OS) |
| PID 1 | L'application (ex: nginx) | L'application (ex: nginx) | /sbin/init (systemd) |
| Daemon | Oui (root) | Non (Daemonless) | Oui (lxd, root ou non) |
| SĂ©curitĂ© (DĂ©faut) | Faible (Daemon root) | ĂlevĂ©e (Rootless) | ĂlevĂ©e (Rootless) |
| Intégration | Docker Compose | Systemd, Pods, Podman Compose | lxc CLI |
| Cas d'usage | Déployer 1 app (Django, Node) | Déployer 1 app (si root est un risque) | Créer 10 VMs Ubuntu/Rocky isolées |
Commandes (alias docker=podman)
# (Toutes les commandes Docker marchent...) podman run -d --name web -p 8080:80 nginx podman ps podman images podman build -t mon-app . podman stop web podman rm web podman exec -it web /bin/bash podman logs -f web podman system prune
Commandes (Spécifiques Podman)
# --- Pods --- podman pod create --name mon-pod -p 80:80 podman pod ps podman pod list podman run -d --pod mon-pod nginx podman pod stop mon-pod podman pod rm mon-pod # --- Systemd --- podman generate systemd --name web --files # (Crée container-web.service) # --- Compose --- podman-compose up -d podman-compose down
