Créer une CT¶

1. Choisir le numéro et l'IP¶

Le numéro dépend du rôle, et l'IP en découle :

Plage	Rôle	Exemple
`100`–`109`	infrastructure (proxy, déploiement, VPN…)	104 → `10.0.0.4`
`110`–`119`	médias	111 → `10.0.0.11`
`120`–`139`	serveurs de jeu	127 → `10.0.0.27`
`140`–`199`	applications et sites	148 → `10.0.0.48`
`2xx`	machines virtuelles
`9xx`	tests, ou en attente de suppression

L'IP est 10.0.0. suivi des deux derniers chiffres du numéro. La plage 10.0.0.100–254 est réservée au DHCP du routeur, il n'y a donc pas de collision.

Vérifier que le numéro est libre :

pct list; qm list

2. Récupérer le modèle Debian 13¶

pveam update
pveam available --section system | grep debian-13
pveam download local debian-13-standard_<version>_amd64.tar.zst

3. Créer la CT¶

pct create <CTID> local:vztmpl/debian-13-standard_<version>_amd64.tar.zst \
  --hostname <nom> \
  --unprivileged 1 --features nesting=1 \
  --cores 1 --memory 1024 --swap 512 \
  --rootfs local-lvm:8 \
  --net0 name=eth0,bridge=vmbr0,firewall=1,gw=10.0.0.1,ip=10.0.0.<XX>/24,type=veth \
  --nameserver 10.0.0.1 \
  --onboot 1 \
  --tags <role> \
  --description "<à quoi elle sert, qui s'en occupe, lien du repo>"
pct start <CTID>

Pourquoi ces options :

--unprivileged 1: Dans une CT privilégiée, root dans la CT est quasiment root sur l'hôte. On ne le fait que s'il n'y a vraiment pas d'autre solution.
--features nesting=1: Nécessaire au systemd de Debian 13 (sinon Proxmox affiche un avertissement et certains services échouent). Aussi requis pour Docker.
--rootfs local-lvm:8: Le stockage des CT est partagé et déjà surréservé : on part petit. Agrandir plus tard est facile (pct resize <CTID> rootfs +4G), réduire est impossible.
--onboot: 1 pour un service qui doit toujours tourner, 0 pour un serveur de jeu qu'on allume à la demande.
--description et --tags: Visibles dans l'interface Proxmox : c'est la première chose que lira la personne qui tombe sur la CT dans six mois.

4. Premiers réglages dans la CT¶

pct enter <CTID>
apt update && apt -y full-upgrade
# eth0 est géré par ifupdown : ce service échoue et retarde le démarrage de 2 minutes
systemctl mask systemd-networkd-wait-online.service

5. Si l'appli a beaucoup de données¶

Ne pas tout mettre dans le disque système de la CT : on crée un dataset ZFS sur un des pools de données et on le monte dans la CT.

zfs create -o compression=zstd -o atime=off <pool>/<projet>
pct set <CTID> -mp0 /<pool>/<projet>,mp=/data,backup=0

backup=0 exclut ces données des sauvegardes de la CT : à réserver aux données qu'on sait reconstruire (téléchargées, générées…).

Droits dans une CT non privilégiée

Les utilisateurs de la CT sont décalés de 100000 sur l'hôte : root dans la CT = uid 100000 sur l'hôte. Pour que la CT puisse écrire dans le dataset : chown -R 100000:100000 /<pool>/<projet> (ou 100000 + l'uid de l'utilisateur de l'appli).

Avant de considérer la CT comme finie¶

description et tags renseignés
onboot réglé selon l'usage
l'appli tourne en service systemd, et redémarre après pct reboot <CTID>
déploiement branché sur deploy-hub si le code est sur GitHub
CT ajoutée aux sauvegardes planifiées
CT documentée dans le repo privé de l'infra