Docker Compose

Importeer een compose-bestand één keer. Nodion maakt er een app, processen en managed services van.

Stapsgewijze deployhandleidingen: Docker Compose.

Deze route is experimenteel. Nodion voert hierbij geen docker compose up uit, blijft Compose niet draaien, past geen networks toe en leest het bestand bij latere deploys niet opnieuw in.

Koppel op Applications → New een Git-repository. Als de scan een compose-bestand vindt met minstens één app-service, verschijnt de keuze Docker Compose. Die is nooit vooraf geselecteerd. Klik erop om het plan te controleren en maak daarna de app aan.

Welk bestand

Van bestanden met deze namen krijgt het bestand het dichtst bij de root voorrang:

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

Een bestand met alleen databases of caches (geen app-service) wordt genegeerd. Ook een bestand met een parsefout wordt genegeerd. Een compose-bestand diep in een grote repository kan worden gemist als de scan wordt afgekapt.

Wat er wordt aangemaakt

Eén applicatie, niet één app per service. Extra services worden extra processen van die app. In de wizard kies je vóór het aanmaken het pakket en het aantal replica's (1-16). deploy.replicas in het bestand wordt genegeerd.

Image-tags zoals postgres:16 bepalen niet de versie van de managed engine. Nodion gebruikt de huidige standaardversie voor die engine. Databasegebruikers en wachtwoorden komen van Nodion, niet uit de omgevingsvariabelen van de databaseservice in Compose.

Verwijst een env-waarde van een app-service naar een andere service als host (postgres://…@db:5432/…, redis://cache:6379), dan wordt die sleutel een koppeling die bij de deploy wordt geïnjecteerd. Anders worden databases in Postgres-stijl gekoppeld als DATABASE_URL, Valkey als REDIS_URL en MinIO als de gebruikelijke AWS/S3-sleutels.

Alleen de overige omgevingsvariabelen van de primaire app-service worden naar de app gekopieerd. Variabelen met namen die op secrets duiden, worden in het formulier als secret gemarkeerd.

Volumes

Benoemde volumes worden volumes (standaard 5 GB, aan te passen in de wizard) en worden gemount op de bijbehorende processen. Bind mounts (./data:/data) en anonieme volumes worden overgeslagen.

Hoe de app daarna wordt gebouwd

De strategie van de app blijft Dockerfile of Buildpacks, op basis van dezelfde repositoryscan. build.context en build.dockerfile uit Compose worden niet naar die instellingen gekopieerd. Er is één Git-build per app. Een tweede service met een eigen build: gebruikt dezelfde image.

Een service met alleen image: (die geen gemapte database is) houdt die image en draait die als proces. De primaire service met build: wordt hernoemd naar web.

De eerste deploy wacht tot gekoppelde databases en buckets klaar zijn. Na het aanmaken wijzig je processen, env en resources in het dashboard. Als je het compose-bestand in Git aanpast, wordt het plan niet bijgewerkt.

Wat wordt genegeerd

• Networks, profiles en Compose-healthchecks
• depends_on als startvolgorde (een hulpcontainer die alleen wacht, wordt overgeslagen)
• Bind mounts
• Builds per service naast de ene app-image

Is een managed engine of objectopslag niet beschikbaar in de regio, dan wordt die resource overgeslagen en wordt de app toch aangemaakt.