Déployez Docker Compose sur Nodion

Déployez Docker Compose étape par étape

1. Vérifiez votre fichier Compose Nodion lit docker-compose.yml, docker-compose.yaml, compose.yml ou compose.yaml, en prenant le fichier le plus proche de la racine du dépôt. Il faut au moins un service applicatif en plus des bases de données et des caches ; un fichier qui ne contient que des bases de données et des caches est ignoré. docker-compose.yml

   services:
     web:
       build: .
       environment:
         DATABASE_URL: postgres://app:app@db:5432/app
         REDIS_URL: redis://cache:6379
     db:
       image: postgres:17
     cache:
       image: valkey/valkey:8

2. Choisissez Docker Compose à la création de l'app Créez une application depuis votre dépôt dans la région EU Central. Quand l'analyse trouve un fichier Compose exploitable, une option Docker Compose apparaît ; elle n'est jamais présélectionnée. Choisissez-la et vérifiez le plan : avant la création, vous pouvez encore choisir la taille et le nombre d'instances par processus et ajuster la taille des volumes.
3. Vérifiez quels services deviennent managés Nodion se fie au nom de l'image : postgres et postgis deviennent Managed PostgreSQL, pgvector devient pgvector, redis et valkey deviennent Valkey, mysql et mariadb deviennent MySQL, clickhouse devient ClickHouse et minio devient un bucket. Tout autre service exécute son image comme processus de cette app unique. Le tag de l'image ne détermine pas la version de la base de données, et les utilisateurs et mots de passe sont fournis par Nodion. Managed PostgreSQL n'a pas l'extension PostGIS : une app qui a besoin de PostGIS perd donc ses fonctions spatiales après l'import ; laissez une telle base de données en dehors du fichier Compose.
4. Vérifiez les variables de connexion Une variable du service applicatif qui désigne un autre service par son nom, comme @db:5432 ci-dessus, devient un rattachement : Nodion injecte la vraie adresse au déploiement. Sinon, les bases de données arrivent en tant que DATABASE_URL et Valkey en tant que REDIS_URL. Parmi les autres variables, seules celles du service applicatif principal sont copiées, et les valeurs qui ressemblent à des secrets sont marquées comme secrets.
5. Gérez ensuite l'app dans le dashboard Le premier déploiement attend que les bases de données soient prêtes. Ensuite, le fichier Compose n'est plus lu : chaque push construit l'app avec la stratégie Dockerfile ou buildpacks trouvée dans le même dépôt, et vous modifiez les processus, les variables et les tailles dans le dashboard.

Bon à savoir

• Expérimental et ponctuelL'import est un raccourci pour la première mise en place, pas un runtime Compose. Si votre fichier ne se convertit pas proprement, recréez la même configuration à la main : une app, une base de données rattachée dans l'onglet Environment et des processus supplémentaires dans l'onglet Processes.
• Ce que Nodion ignoreLes réseaux, les profils, les healthchecks Compose, depends_on comme ordre de démarrage, deploy.replicas, les bind mounts et les volumes anonymes. Un deuxième service avec son propre build: partage l'unique image de l'app.
• VolumesLes volumes nommés deviennent des volumes Nodion, de 5 Go par défaut et modifiables dans le plan, montés sur les processus qui les utilisent.

Ce que Nodion gère pour vous

• Déploiements sans interruption Faites un push sur votre branche : Nodion construit une nouvelle release. Le trafic bascule lorsque les nouvelles instances réussissent leur health check ; si la release échoue, celle en cours reste active. Les apps avec un volume local redémarrent, car le disque appartient à une seule instance.
• Bases de données à côté de l'app PostgreSQL, pgvector, MySQL, Valkey et ClickHouse managés, dans la même région. Les bases de données rattachées arrivent sous forme de DATABASE_URL, REDIS_URL ou CLICKHOUSE_URL.
• Previews par pull request Activez les previews, et les pull requests de votre dépôt obtiennent leur propre app, avec sa propre URL et des bases de données neuves et vides, créées automatiquement ou à la main. Les pull requests issues de forks ou de bots sont ignorées.
• Workers, cron jobs et mise à l'échelle Exécutez les workers comme processus supplémentaires de la même app, planifiez des tâches dans l'onglet Cron et mettez chaque processus à l'échelle jusqu'à 16 instances.
• Étape de release Avec les buildpacks, une ligne release: du Procfile s'exécute à chaque nouveau build. Les apps Dockerfile, ainsi que les redéploiements ou les rollbacks vers une image antérieure, utilisent une commande de release définie sur l'app elle-même, qui prime aussi sur la ligne du Procfile. Sur les sites statiques, l'étape de release s'exécute dans une image qui ne contient que les fichiers générés par le build.
• Logs et métriques Logs de build, de release et d'exécution, ainsi que les métriques CPU, mémoire, disque et réseau de chaque instance, dans le dashboard.
• Domaines et HTTPS Un nom d'hôte par défaut avec HTTPS dès le premier déploiement, et des certificats automatiques pour vos propres domaines.

Pour aller plus loin

• Dockerfile vs buildpacks : lequel choisir ? Les deux transforment votre code en image de conteneur. La différence, c'est qui écrit les étapes du build, et cela détermine le contrôle, la maintenance et les mises à jour de sécurité.
• Alternatives à Railway en Europe : 5 options comparées Conteneurs et bases de données facturés à l'usage, avec une entreprise ou une région dans l'UE : cinq alternatives à Railway comparées par facturation, bases de données et localisation.

Docker Compose sur Nodion : questions et réponses