Deploy Docker Compose op Nodion

Docker Compose stap voor stap deployen

1. Controleer je Compose-bestand Nodion leest docker-compose.yml, docker-compose.yaml, compose.yml of compose.yaml en neemt het bestand dat het dichtst bij de root van de repository staat. Naast de databases en caches is minstens één app-service nodig; een bestand met alleen databases en caches wordt genegeerd. 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. Kies Docker Compose bij het aanmaken van de app Maak een applicatie aan vanuit je repository in de regio EU Central. Vindt de scan een bruikbaar Compose-bestand, dan verschijnt de optie Docker Compose; die is nooit vooraf geselecteerd. Kies die optie en controleer het plan: voordat je de app aanmaakt, kun je per proces nog grootte en aantal instanties kiezen en de grootte van volumes aanpassen.
3. Bekijk wat een managed service wordt Nodion gaat uit van de naam van de image: postgres en postgis worden Managed PostgreSQL, pgvector wordt pgvector, redis en valkey worden Valkey, mysql en mariadb worden MySQL, clickhouse wordt ClickHouse en minio wordt een bucket. Elke andere service draait zijn image als proces van die ene app. De image-tag bepaalt niet de databaseversie, en gebruikers en wachtwoorden komen van Nodion. Managed PostgreSQL heeft geen PostGIS-extensie, dus een app die PostGIS nodig heeft, verliest na de import de ruimtelijke functies; laat zo'n database weg uit het Compose-bestand.
4. Controleer de verbindingsvariabelen Een variabele van de app-service die een andere service bij naam noemt, zoals @db:5432 hierboven, wordt een koppeling: Nodion vult bij de deployment het echte adres in. Anders komen databases binnen als DATABASE_URL en Valkey als REDIS_URL. Van de overige variabelen worden alleen die van de hoofd-app-service overgenomen, en waarden die op secrets lijken, worden als secret gemarkeerd.
5. Beheer de app daarna in het dashboard De eerste deployment wacht tot de databases klaar zijn. Daarna wordt het Compose-bestand niet meer gelezen: elke push bouwt de app met de strategie Dockerfile of buildpacks die in dezelfde repository is gevonden, en processen, variabelen en groottes wijzig je in het dashboard.

Goed om te weten

• Experimenteel en eenmaligDe import is een snelle manier om de app voor het eerst in te richten; het is geen Compose-runtime. Werkt de omzetting van je bestand niet goed, richt de app dan zelf zo in: één app, een database gekoppeld op het tabblad Environment en extra processen op het tabblad Processes.
• Wat Nodion negeertNetwerken, profielen, Compose-healthchecks, depends_on als startvolgorde, deploy.replicas, bind mounts en anonieme volumes. Een tweede service met een eigen build: deelt de ene image van de app.
• VolumesBenoemde volumes worden Nodion-volumes, standaard 5 GB en aan te passen in het plan, gemount op de processen die ze gebruiken.

Wat Nodion voor je regelt

• Deploys zonder downtime Push naar je branch en Nodion bouwt een nieuwe release. Het verkeer schakelt over zodra de nieuwe instanties hun health check doorstaan; een mislukte release laat de draaiende versie staan. Apps met een lokaal volume herstarten in plaats daarvan, omdat de schijf bij één instantie hoort.
• Databases naast de app Managed PostgreSQL, pgvector, MySQL, Valkey en ClickHouse in dezelfde regio. Gekoppelde databases komen binnen als DATABASE_URL, REDIS_URL of CLICKHOUSE_URL.
• Previews per pull request Zet previews aan en pull requests uit je repository krijgen een eigen app met een eigen URL en nieuwe, lege databases, automatisch of handmatig aangemaakt. Forks en pull requests van bots worden overgeslagen.
• Workers, cronjobs en schalen Draai workers als extra processen van dezelfde app, plan jobs op het tabblad Cron en schaal elk proces naar maximaal 16 instanties.
• Releasestap Met buildpacks draait een release:-regel in het Procfile bij elke nieuwe build. Dockerfile-apps, en redeploys of rollbacks naar een eerdere image, gebruiken een releasecommando dat op de app zelf is ingesteld en dat ook voorrang heeft op de Procfile-regel. Bij statische sites draait een releasestap in een image die alleen de gebouwde bestanden bevat.
• Logs en metrics Build-, release- en runtimelogs plus metrics voor CPU, geheugen, schijf en netwerk van elke instantie in het dashboard.
• Domeinen en HTTPS Een standaardhostnaam met HTTPS vanaf de eerste deploy; je eigen domeinen krijgen automatisch certificaten.

Verder lezen

• Dockerfile vs buildpacks: welke moet je gebruiken? Allebei maken ze van je code een containerimage. Het verschil is wie de buildstappen schrijft, en dat bepaalt controle, onderhoud en beveiligingsupdates.
• Alternatieven voor Railway in Europa: 5 opties vergeleken Containers en databases op basis van verbruik, bij een bedrijf in de EU of in een EU-regio: vijf alternatieven voor Railway vergeleken op facturatie, databases en locatie.

Docker Compose op Nodion: vragen en antwoorden