Stacks Docker Compose

Une stack déploie une application composée de plusieurs conteneurs à partir d’un fichier docker-compose.yaml (Airbyte, Plausible, Sentry, n8n en mode file d’attente…). Contrairement à un service — qui vaut un conteneur — une stack regroupe tous ses conteneurs sous une seule application : ils démarrent ensemble, partagent un réseau privé et communiquent par leurs noms de service compose (depends_on, healthcheck et volumes nommés sont respectés tels quels).

La stack apparaît dans le projet comme une carte-groupe : un statut agrégé en entête, puis le statut de chaque conteneur à l’intérieur. On voit immédiatement que N conteneurs forment une application.

Déployer une stack

Une stack se déploie depuis un dépôt git qui contient un docker-compose.yaml, et elle se crée au même endroit qu’un service : le bouton « Nouveau service » de votre projet, onglet Dépôt Git. Il n’y a pas d’écran séparé, et il n’est pas possible de coller un compose : la plateforme le lit dans votre dépôt, ce qui lui permet aussi de le revalider à chaque déploiement (voir Déployer depuis un repo git).

1. Indiquez le dépôt et la branche, comme pour un service.
2. Basculez « Déployer » sur « Une stack ». Le dépôt et la branche déjà saisis sont conservés.
3. Le chemin du compose est prérempli s’il a été trouvé à la racine du dépôt ; sinon, saisissez-le (/apps/docker-compose.yaml, par exemple).
4. L’analyse part toute seule après une seconde d’inactivité — aucun bouton à cliquer. Le récapitulatif liste les conteneurs, leur image, les volumes nommés et le conteneur qui sera exposé. Aucune écriture, aucun quota consommé à ce stade.
5. Renseignez les variables que le compose référence sans les définir (${VAR}). Ce sont les seules valeurs qui vous sont demandées : sans elles, les conteneurs concernés ne démarreraient pas, donc la création reste bloquée tant qu’elles sont vides. Elles sont chiffrées avant enregistrement, jamais renvoyées ni affichées ensuite.
6. Déployer la stack — c’est le bouton du formulaire, en bas.

Tout le reste est déduit du compose, sans vous le faire ressaisir :

Ce qui est déduit	D’où ça vient
vCPU / RAM par conteneur	deploy.resources.limits du compose, sinon un défaut prudent (0,25 vCPU / 256 Mo)
Taille des volumes	la taille déclarée pour chaque volume nommé (défaut 1 Go : sur le disque de la machine ; à partir de 10 Go : volume bloc dédié)
Conteneur exposé et port	le conteneur applicatif qui déclare un port (expose: / ports:)

Ces valeurs se modifient après le déploiement, sur la stack — plutôt que de les faire trancher avant d’avoir rien vu tourner.

Une jauge temps réel compare la somme des capacités demandées au footprint restant de votre plan (vCPU / RAM / stockage). Si la demande dépasse le plan, la création est bloquée et un raccourci de montée en gamme est proposé.

Note

Un dépôt qui contient un docker-compose.yaml vous le signale dès que vous l’avez saisi, avec le chemin trouvé. Si ce compose ne peut pas devenir une stack (publication de ports hôtes, montage de l’hôte… — typiquement un compose de développement local), le message vous le dit à ce moment-là, avec le motif : inutile d’aller plus loin, continuez en service unique.

Limites de votre plan

Une stack peut être créée sur tous les plans, tant que la somme des capacités demandées tient dans le footprint restant de votre plan. Trois dimensions sont plafonnées :

Dimension	Ce qui est compté
vCPU	somme des vCPU choisis pour chaque conteneur
RAM	somme de la RAM choisie pour chaque conteneur
Stockage	somme des tailles déclarées des volumes nommés de la stack

Ces plafonds bornent l’empreinte simultanée de votre compte, tous services, add-ons et stacks confondus. Un plan free (1 vCPU / 1 Go / 6 Go) accueille de façon réaliste deux micro-conteneurs.

Attention

Le stockage est compté déclarativement à partir des tailles annoncées. Un conteneur qui écrit au-delà de sa taille déclarée n’est pas bloqué au niveau du système de fichiers au lancement : respectez les tailles annoncées et surveillez vos volumes.

Vos deux stockages

Une stack, comme un service, dispose de deux espaces de stockage bien différents. Les confondre est la première cause de perte de données.

Le disque applicatif est l’espace de travail des conteneurs, taillé dans la machine qui les héberge. Il est éphémère : tout ce qu’un conteneur écrit ailleurs que dans un volume nommé — dans /tmp, dans son répertoire de travail, dans un chemin que le compose ne déclare pas — repart vide au redéploiement suivant, sans avertissement. Il est inclus dans le prix de la machine et n’ajoute pas de ligne à votre facture.

Les volumes persistants sont les volumes nommés que déclare votre compose.yml, avec la taille qu’il annonce. Chacun est un disque commandé séparément : il survit aux redéploiements, aux redémarrages et à la destruction de la machine. Il est facturé à part, tant qu’il existe, occupé ou non, et il est détruit avec la stack.

	Disque applicatif	Volumes nommés (persistants)
Survit à un redéploiement	Non	Oui
Survit à la destruction de la machine	Non	Oui
Facturation	Inclus dans la machine	Ligne séparée, tant qu’il existe
Fin de vie	Avec la machine	Avec la stack

La conséquence pratique tient en une phrase : ce qui doit durer s’écrit dans un chemin couvert par un volume nommé de votre compose, jamais ailleurs.

Une stack avec volumes ne peut pas être mise en veille

La veille détruit la machine, et un volume ne peut pas rester rattaché à une machine qui n’existe plus. Cassiope refuse donc la mise en veille d’une stack qui porte des volumes persistants, plutôt que de risquer vos données. Le détachement d’un volume, qui lèvera cette limite, fera l’objet d’un écran dédié.

Sauvegardes

Un volume persistant survit à la machine, mais il n’est pas sauvegardé : il n’en existe qu’un seul exemplaire. Une base de données que vous ne voulez pas perdre vit dans un add-on, qui est sauvegardé et restaurable.

Les volumes d’une stack sont créés dans la zone de la stack et n’en bougent plus : c’est désormais le volume qui fixe l’emplacement, et un redéploiement ramène la stack là où vivent ses données.

Clés compose non supportées

Certaines clés compose sont refusées à la validation (la création échoue avec un message par clé), pour préserver l’isolation et la mutualisation :

Clé	Raison
ports: (publication sur l’hôte)	l’exposition est gérée par Cassiope : le conteneur applicatif reçoit un domaine, sans publication de port sur la machine
privileged, cap_add, security_opt, devices, sysctls	évasion de conteneur
montages hôte (/…, ./…, ~…, docker.sock)	accès à l’hôte interdit en environnement mutualisé
network_mode: host / pid / ipc	isolation
networks: externes, extends, volumes_from	hors périmètre
secrets: / configs: (fichiers)	remplacés par les variables chiffrées de la plateforme
deploy.replicas > 1	pas d’orchestration de réplicas
compose supérieur à 64 Ko	garde-fou de taille

D’autres clés sont acceptées mais ajustées (un avertissement s’affiche) : un tag d’image absent ou latest, un restart: forcé à unless-stopped, un container_name retiré (le nom est géré par la plateforme), les profiles: ignorés, et le préfixe de labels cassiope. réservé.

Enfin, ces clés sont conservées telles quelles : depends_on, healthcheck, expose, command / entrypoint, environment (interpolation ${VAR}), volumes nommés, user, working_dir.

Limitations assumées

• Épinglez vos tags d’image. Le rollback réapplique le compose et les variables d’un déploiement antérieur, mais ne re-télécharge pas une image identique bit à bit. Il n’est donc fiable qu’avec des tags épinglés (ex. postgres:15.6). Évitez latest et les tags mobiles : le résultat d’un rollback n’est alors pas garanti — un badge d’avertissement le signale dès la prévisualisation.
• 1 stack = 1 machine. Tous les conteneurs d’une stack sont co-localisés sur la même VM (c’est le modèle compose). La demande de placement est la somme des capacités par conteneur ; si aucune VM ne peut l’accueillir, la plateforme provisionne la capacité nécessaire.
• Volumes comptés déclarativement. La taille d’un volume est celle que déclare le compose, pas la consommation réelle (voir l’encart stockage ci-dessus).

Renommer une stack

Cliquez sur le crayon à côté du nom, en haut de la page de la stack, puis validez avec Entrée (Échap annule). Seul le nom affiché change : l’adresse, les domaines et les volumes restent identiques. Dans l’environnement de production, cette action est réservée aux propriétaires et administrateurs.

Cycle de vie

• Déployer — construit et démarre l’ensemble des conteneurs (asynchrone). Suivez le statut jusqu’à running.

• Arrêter / Démarrer — met en pause ou relance la stack entière en une opération. La stack garde sa place sur le serveur qui l’héberge.

• Mettre en veille — détruit les conteneurs et rend la capacité au pool ; sur un serveur dédié, la machine est détruite avec (c’est la seule façon d’arrêter d’en payer la réservation). Le réveil (Réveiller) est un redéploiement complet, pas un simple démarrage. Une stack depuis des images ne fait que les retirer ; une stack depuis un dépôt git est reconstruite au commit qui tournait au moment de la mise en veille — pas à la tête de la branche : les commits poussés pendant la veille attendent votre prochain déploiement.

  Trois points à connaître avant de cliquer :

  • une stack qui porte des volumes persistants ne peut pas être mise en veille : la veille détruirait la machine sous ses volumes. Le refus est explicite (voir Vos deux stockages) ;
  • tous les consommateurs liés seront coupés. Une stack sert souvent d’infrastructure à d’autres ressources — retirez les liens d’abord si vous voulez les garder en ligne ;
  • une stack qui consomme elle-même un add-on ne peut pas être mise en veille : sa connexion dépend d’être hébergée au même endroit que l’add-on. Retirez le lien d’abord.

• Redéployer — réapplique le compose et les variables courants, puis recrée les conteneurs (bref temps d’arrêt, façon compose down/up). Les volumes nommés sont préservés.

• Supprimer — action irréversible : les conteneurs, le réseau privé de la stack et ses volumes de données sont supprimés.

Le statut agrégé vaut running (tous les conteneurs sont up), degraded (partiellement up) ou crashed, en plus du statut individuel de chaque conteneur.

Vue par conteneur

Cliquez sur un conteneur dans la liste pour ouvrir sa vue détaillée, avec les mêmes onglets qu’un service : Aperçu, Déploiements, Variables, Connexions, Domaines, Logs, Métriques.

• Logs et Domaines (pour le conteneur exposé) sont propres à ce conteneur.
• Métriques et Déploiements affichent la consommation et l’historique de la stack entière — les conteneurs d’une stack partagent une seule VM et un seul cycle de déploiement, ils ne sont pas mesurés ni déployés séparément.
• Variables liste, en lecture seule, les clés du pool de la stack que ce conteneur référence ; leur valeur se gère depuis l’onglet Variables de la stack.
• Connexions — comme Métriques et Déploiements, à l’échelle de la stack : voir Connexions.

Attention

La suppression d’une stack efface ses volumes de données. Sauvegardez ce qui doit l’être avant de supprimer.

Captures d’écran à insérer.