13. Réseau, sauvegardes et premier service

Il reste à relier le conteneur au réseau, à le protéger avant toute manipulation risquée, puis à y faire tourner un premier vrai service. Cette dernière section du chapitre enchaîne les trois, jusqu'à une page web servie par nginx.

13.1 Réseau des conteneurs LXC

13.1.1 Le bridge vmbr0 et les paires veth

Proxmox configure automatiquement un bridge Linux — vmbr0 — lors de l'installation. Ce bridge fonctionne comme un commutateur virtuel : il connecte les interfaces réseau des conteneurs (et des VM) au réseau physique de l'hôte.

Chaque interface réseau d'un conteneur LXC est en réalité une paire veth (virtual Ethernet) : deux interfaces virtuelles reliées comme les deux extrémités d'un câble. L'une est dans le namespace réseau du conteneur, vue comme eth0 ; l'autre est sur l'hôte, nommée vethXXXi0, et connectée au bridge vmbr0.

Le chemin d'un paquet, du conteneur 200 au réseau physique. eth0 et veth200i0 sont les deux bouts d'un même câble virtuel ; vmbr0 les relie à la carte du nœud. Cliquez sur un élément pour la commande qui le montre.

Dans le Shell du nœud (interface web → votre nœud → Shell) :

# Voir les paires veth créées par les conteneurs actifs
# (veth200i0 = conteneur 200, interface net0)
ip link show type veth

# Vérifier quel bridge est associé à cette interface veth
bridge link show | grep veth200

# Voir tous les conteneurs connectés à vmbr0
brctl show vmbr0

Résultat attendu de brctl show vmbr0 (nœud pxe211 du lab, CT 200 démarré ; vos noms de cartes et d'autres conteneurs peuvent différer). Si la case Firewall de la carte du conteneur est décochée (firewall=0), la paire veth est branchée directement sur le pont :

bridge name bridge id       STP enabled interfaces
vmbr0       8000.bc241101a111   no      ens18
                            veth200i0

Chaque vethXXXi0 est l'extrémité hôte de la paire veth d'un conteneur actif : le nombre est l'identifiant du conteneur, i0 le numéro de son interface (net0). ens18 est la carte du nœud reliée à vmbr0.

ip link show type veth affiche de son côté veth200i0@if2 : le @if2 est le numéro de l'autre extrémité, l'eth0 vu de l'intérieur du conteneur.

Avec le pare-feu activé sur la carte (firewall=1, la case cochée par défaut), Proxmox intercale un petit pont par conteneur, sur lequel le pare-feu filtre. Sur le même nœud.

Dans le Shell du nœud :

# Tous les ponts du nœud, ceux du pare-feu compris
brctl show

bridge name bridge id       STP enabled interfaces
vmbr0       8000.bc241101a111   no      ens18
                            fwpr200p0
fwbr200i0       8000.1ac7a959441a   no      fwln200i0
                            veth200i0

Le chemin devient : veth200i0 → pont fwbr200i0 → paire fwln200i0/fwpr200p0 → vmbr0. C'est pour cela qu'on voit des interfaces fwpr… sur vmbr0 et des ponts fwbr… dans brctl show : elles appartiennent au pare-feu Proxmox, pas au conteneur.

13.1.2 IP statique et DHCP

La configuration réseau se précise à la création du conteneur dans l'option --net0. Deux modes sont disponibles.

En IP statique, on spécifie l'adresse et le masque en notation CIDR (Classless Inter-Domain Routing : l'adresse suivie de la longueur du masque), plus la passerelle.

Dans le Shell du nœud, l'option de pct create :

# Configuration réseau en IP statique
--net0 name=eth0,bridge=vmbr0,ip=<ip-libre>/24,gw=<ip-de-la-passerelle>

En DHCP, le conteneur obtiendra une adresse automatiquement depuis le serveur DHCP du réseau.

Dans le Shell du nœud, l'option de pct create :

# Configuration réseau en DHCP (hors lab : ici, adresses fixes uniquement)
--net0 name=eth0,bridge=vmbr0,ip=dhcp

13.1.3 Vérifier la connectivité depuis le conteneur

Une fois le conteneur démarré, on entre dedans pour vérifier que la configuration réseau est correcte :

Dans le Shell du nœud (interface web → votre nœud → Shell) :

# Depuis l'hôte Proxmox, entrer dans le conteneur
pct enter 200

# Vérifier les interfaces et l'IP attribuée
ip addr show eth0

# Tester la connectivité vers la passerelle
ping -c 3 <ip-de-la-passerelle>

# Tester la connectivite sur le reseau local
ping -c 3 <ip-de-votre-noeud>

Résultat de ip addr show eth0 :

2: eth0@if7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
    link/ether bc:24:11:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet 10.44.1.50/24 brd 10.44.1.255 scope global eth0
       valid_lft forever preferred_lft forever

L'interface eth0@if7 indique que cette interface est un veth pair — une paire d'interfaces virtuelles reliées, dont une extrémité (if7) se trouve côté hôte, connectée au bridge vmbr0.

13.2 Sauvegardes et snapshots

13.2.1 Les snapshots

Un snapshot capture l'état complet d'un conteneur à un instant donné — son système de fichiers, sa configuration, et si on le demande sa mémoire vive. C'est un filet de sécurité précieux avant toute opération risquée : mise à jour majeure, modification de configuration critique, installation d'un nouveau service.

Depuis l'interface graphique, on navigue vers le conteneur, puis Snapshots → Take Snapshot. On donne un nom explicite au snapshot (par exemple avant-upgrade-nginx) et une description facultative.

Pour revenir à un état précédent, on sélectionne le snapshot dans la liste et on clique Rollback.

13.2.2 Les sauvegardes avec vzdump

vzdump crée une archive complète du conteneur, restaurable sur n'importe quel nœud Proxmox. Il sert aussi aux VM, et Proxmox Backup Server en est la version dédiée.

Dans le Shell du nœud (interface web → votre nœud → Shell) :

# Sauvegarder le conteneur 200 en mode snapshot, sans l'arrêter
vzdump 200 --storage local --mode snapshot
# Restaurer l'archive sous un nouvel identifiant ; --unique 1 : nouvelle adresse MAC
pct restore 201 /var/lib/vz/dump/vzdump-lxc-200-<date>.tar.zst --storage local-lvm --unique 1

Résultat attendu : vzdump termine par INFO: Finished Backup of VM 200, et l'archive est dans /var/lib/vz/dump/. La restauration crée un volume neuf, vm-201-disk-0.

• 📖 Documentation Proxmox — Backup and Restore

13.3 Déployer nginx dans un conteneur — exemple complet

Pour conclure ce chapitre par un cas concret, voici le déploiement complet d'un serveur nginx dans notre conteneur. Cette séquence illustre le workflow typique qu'on retrouvera tout au long de la formation.

On commence par entrer dans le conteneur et mettre à jour la liste des paquets :

Dans le Shell du nœud (interface web → votre nœud → Shell) :

# Entrer dans le conteneur
pct enter 200

# Mettre à jour la liste des paquets
apt update

Résultat attendu :

Hit:1 http://deb.debian.org/debian trixie InRelease
Reading package lists... Done

On installe nginx et on l'active pour qu'il démarre automatiquement au prochain redémarrage :

Dans le conteneur (sa Console, ou pct enter <ctid> depuis le Shell du nœud) :

# Installer nginx
apt install -y nginx

# Activer le démarrage automatique au boot
systemctl enable nginx

# Vérifier que nginx est bien démarré
systemctl status nginx

Résultat de systemctl status nginx :

● nginx.service - A high performance web server and a reverse proxy server
     Loaded: loaded (/lib/systemd/system/nginx.service; enabled)
     Active: active (running) since Fri 2026-05-29 10:15:00 UTC; 3s ago
   Main PID: 312 (nginx)

Récupérez l'adresse du conteneur, puis interrogez le service depuis le Shell du nœud Proxmox :

Dans le Shell du nœud (interface web → votre nœud → Shell) :

# Depuis le Shell du noeud
pct exec 200 -- ip addr show eth0
curl -I http://<IP-du-conteneur>   # interroger nginx dans le conteneur, en-têtes seulement

Résultat attendu :

root@pxe211:~# pct exec 200 -- ip addr show eth0
2: eth0@if15: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
    link/ether ba:9c:1e:47:2f:08 brd ff:ff:ff:ff:ff:ff
    inet 10.44.1.50/24 brd 10.44.1.255 scope global eth0
       valid_lft forever preferred_lft forever

root@pxe211:~# curl -I http://10.44.1.50
HTTP/1.1 200 OK
Server: nginx
Content-Type: text/html

Deux confirmations en une : le conteneur porte bien l'adresse fixe qui lui a été assignée, et le service qu'il héberge répond depuis le nœud.

valid_lft forever est la signature d'une adresse fixe : une adresse obtenue en DHCP afficherait une durée de bail décomptée. Sur l'infrastructure de lab en 10.44.1.x, où chaque ressource créée doit porter une adresse fixe, c'est la vérification à faire.

pct exec 200 -- commande exécute dans le conteneur sans y ouvrir de session. Les deux tirets sont indispensables : ils marquent la fin des options de pct, faute de quoi ip addr show eth0 serait interprété comme des arguments de pct.

Vous devez obtenir HTTP/1.1 200 OK et l'en-tête Server: nginx. Si c'est le cas, votre conteneur LXC est correctement isolé, connecté au réseau, et héberge un service web fonctionnel.

À retenir : chaque conteneur rejoint le pont vmbr0 par une paire veth. Avant une opération risquée, un snapshot (retour immédiat) ; pour une vraie sauvegarde, vzdump vers un stockage, restaurée par pct restore. On vérifie un service depuis le Shell du nœud (curl), pas seulement depuis son poste.

Le service de l'atelier 6 : un cache de paquets APT. Le conteneur 200 cache-apt fait tourner apt-cacher-ng, un mandataire HTTP sur le port 3142.

Une machine réglée pour passer par lui demande ses paquets au cache. Le premier téléchargement d'un paquet va sur Internet, et le cache en garde une copie. Les demandes suivantes du même paquet sont servies par le cache, sans repasser par Internet.

L'intérêt est concret dès qu'on a plusieurs machines : dix VM qui installent les mêmes paquets ne les téléchargent qu'une fois. Les installations vont plus vite, et le lien Internet est moins chargé.

Le cache n'est pas indispensable : une VM ou un conteneur sans réglage de mandataire télécharge directement sur Internet. C'est le cas par défaut dans ce support. L'installateur Debian d'une VM propose un champ Mandataire HTTP : on peut y mettre l'adresse du cache, ou le laisser vide.

Mais une machine réglée sur le cache en dépend. Sur le lab, avec le service arrêté : apt-get update échoue sur Unable to connect to …:3142. Le conteneur 200 doit donc rester démarré, et démarrer avec le nœud.