Docker Compose

Importez une fois un fichier compose. Nodion en fait une app, des processus et des services managés.

Guides de déploiement pas à pas : Docker Compose.

Cette méthode est expérimentale. Ce n'est pas docker compose up. Nodion n'exécute pas Compose en continu, n'applique pas les réseaux et ne relit pas le fichier lors des déploiements suivants.

Dans Applications → New, connectez un dépôt Gitet, si l'analyse trouve un fichier compose avec au moins un service applicatif, l'option Docker Compose apparaît. Elle n'est jamais présélectionnée. Cliquez dessus pour vérifier le plan, puis créez l'app.

Fichier sélectionné

Parmi ces noms, le fichier le plus proche de la racine l'emporte :

• docker-compose.yml / docker-compose.yaml
• compose.yml / compose.yaml

Un fichier qui ne contient que des bases de données ou des caches (aucun service applicatif) est ignoré. Un fichier qui ne peut pas être analysé est aussi ignoré. Un fichier compose situé loin dans l'arborescence d'un gros dépôt peut passer inaperçu si l'analyse est tronquée.

Ce qui est créé

Une seule application, et non une app par service. Les autres services deviennent des processus de cette app. L'assistant vous permet de choisir le package et le nombre de réplicas (1-16) avant la création. deploy.replicas dans le fichier est ignoré.

Les tags d'image comme postgres:16 ne déterminent pas la version du moteur managé. Nodion utilise la version actuellement définie par défaut pour ce moteur. Les noms d'utilisateur et mots de passe de la base de données sont générés par Nodion ; ils ne proviennent pas des variables d'environnement Compose du service de base de données.

Si une variable d'environnement d'un service applicatif désigne un autre service comme hôte (postgres://…@db:5432/…, redis://cache:6379), elle devient une liaison de rattachement (attach binding) et est injectée au déploiement. Sinon, les bases de données de type Postgres sont liées via DATABASE_URL, Valkey via REDIS_URL et MinIO via les clés AWS/S3 habituelles.

Seul le reste de l'environnement du service applicatif principal est copié sur l'app. Les clés qui ressemblent à des secrets sont marquées comme secrètes dans le formulaire.

Volumes

Les volumes nommés deviennent des volumes (5 Go par défaut, taille modifiable dans l'assistant) et sont montés sur les processus correspondants. Les bind mounts (./data:/data) et les volumes anonymes sont ignorés.

Le build de l'app par la suite

La stratégie de l'app reste Dockerfile ou Buildpacks, selon la même analyse du dépôt. Les champs Compose build.context et build.dockerfile ne sont pas copiés dans ces paramètres. Il y a un seul build Git par app. Un deuxième service avec son propre build: partage cette image.

Un service qui n'a que image: (et qui n'est pas une base de données mappée) conserve cette image et l'exécute comme processus. Le service principal avec build: est renommé web.

Le premier déploiement attend que les bases de données et les buckets rattachés soient prêts. Après la création, modifiez les processus, les variables d'environnement et les ressources dans le dashboard. Modifier le fichier compose dans Git ne met pas le plan à jour.

Ce qui est ignoré

• Réseaux, profils et health checks Compose
• depends_on comme ordre de démarrage (un conteneur auxiliaire qui ne sert qu'à attendre est ignoré)
• Bind mounts
• Builds par service au-delà de l'unique image de l'app

Si un moteur managé ou le stockage objet n'est pas disponible dans la région, cette ressource est ignorée et l'app est quand même créée.