Manuel pratique Comp’Assist · Révision : 2 octobre 2026. Exemples pédagogiques, à adapter. Les fonctions visibles dépendent de la version, des droits et des paquets installés.
Télécharger un template pris en charge depuis un stockage de modèles, puis créer le CT. Un template est une base de système, pas une application entièrement durcie. Un CT partage le noyau de l’hôte ; choisir une VM si l’application réclame un noyau différent, une forte séparation ou des privilèges difficiles à limiter.
Node doit avoir le bon stockage et le bon bridge. CT ID est libre et unique ; Hostname est un nom fonctionnel. Fournir un secret initial protégé ou une clé SSH publique appropriée, jamais la clé privée. Conserver Unprivileged container pour les cas compatibles. Nesting s’active seulement pour un besoin démontré ; cela élargit certaines possibilités et ne doit pas être la réponse automatique à chaque erreur.
Sélectionner le template exact : distribution, version et architecture. Vérifier fin de support et compatibilité avec l’application. Après création, les paquets doivent encore être mis à jour et configurés.
| Champ | Comment remplir | Pourquoi |
|---|---|---|
| Storage | Support destiné au système du CT | Différencier système et gros volumes de données |
| Disk size | Taille de rootfs avec marge paquets/logs | Un rootfs trop petit peut bloquer les mises à jour |
| Cores | Nombre adapté à la concurrence réelle | Un petit service n’a pas besoin de tous les cœurs |
| CPU limit / units, si exposés | Plafond et poids selon besoin | Ne pas confondre plafond et priorité relative |
| Memory | Limite permettant l’usage et ses pics | Prévenir OOM en mesurant l’application |
| Swap | Politique supportée par l’hôte | Ne remplace pas une RAM suffisante |
Name est le nom de l’interface dans le CT, souvent eth0. Bridge détermine le segment virtuel ; VLAN tag doit être transporté sur le lien physique. IPv4 choisit DHCP ou adresse statique avec préfixe ; Gateway doit être cohérente avec le réseau. Pour IPv6, choisir la méthode réellement déployée, pas une adresse aléatoire. Firewall dépend de la politique définie aux niveaux concernés.
Dans DNS, renseigner le domaine de recherche et le résolveur de la zone, ou l’héritage prévu. Si la gestion doit résoudre des noms privés, vérifier le DNS depuis le CT ; l’hôte qui résout correctement ne prouve pas que l’invité reçoit le même service.
Dans Resources → Add → Mount Point, choisir un stockage géré, une taille et le chemin interne absolu, par exemple /srv/donnees. Préparer l’application pour ce chemin. Un point de montage sur un dossier déjà rempli peut masquer les fichiers précédents sans les supprimer ; inventorier et déplacer avec une procédure applicative cohérente avant bascule.
| Option | Effet | Contrôle |
|---|---|---|
| Mount point | Chemin vu dans le CT | Existe et correspond à la configuration applicative |
| Backup | Inclusion du volume géré quand supportée | Lire le log du backup, puis restaurer les données |
| Read-only | Empêche les écritures via ce montage | Utile pour certaines sources, incompatible avec données modifiées |
| Quota / ACL selon backend | Gestion de capacité ou droits | Vérifier disponibilité et effet dans l’invité |
| Replicate selon support | Inclusion dans la réplication | Ne transforme pas un montage externe en copie indépendante |
Un bind mount expose un chemin de l’hôte : il doit être documenté séparément, son contenu n’étant pas automatiquement sauvegardé par le backup CT. Un device mount donne accès à un périphérique et accroît les conséquences d’une erreur. Ne pas les employer pour contourner une conception de stockage non résolue.
Dans un CT non privilégié, l’UID vu dans le CT peut correspondre à un UID décalé sur l’hôte. Examiner utilisateur du service, propriétaire du répertoire, ACL et mapping effectif. Le fait que « root » du CT ne puisse pas tout modifier sur un chemin hôte est parfois le comportement attendu. Ne pas faire chmod -R 777 ni changer récursivement le propriétaire d’un partage utilisé par d’autres applications.
Pour transférer des données, conserver attributs nécessaires, vérifier nombre/taille et permissions, puis tester en tant qu’utilisateur du service. Ne pas supprimer l’ancienne copie tant que la validation et le backup ne sont pas terminés.
Configurer démarrage automatique, ordre et délai selon dépendances : réseau/DNS, base, application. Lire les fonctionnalités optionnelles avant activation ; FUSE, nesting ou périphériques ont chacun un impact. Certains services système peuvent être inapplicables en conteneur : distinguer une unité inutile d’un service métier réellement en panne.
Tester systemctl --failed, les montages, l’espace, les ports et la fonctionnalité réelle. Effectuer un backup puis une restauration isolée. Vérifier que les données du volume supplémentaire sont présentes. Une restauration qui retrouve seulement le système est insuffisante pour un cloud ou un serveur de fichiers.