Docker Compose

Eine Compose-Datei einmal importieren. Nodion macht daraus eine App, Prozesse und managed Dienste.

Dieser Weg ist experimentell. Das ist nicht docker compose up. Nodion führt Compose nicht weiter aus, wendet keine Networks an und liest die Datei bei späteren Deploys nicht neu.

Unter Applications → New ein GitRepo verbinden. Findet der Scan eine Compose-Datei mit mindestens einem App-Service, erscheint die Wahl Docker Compose. Sie ist nie vorausgewählt. Draufklicken, den Plan prüfen, dann anlegen.

Welche Datei

Die flachste dieser Namen gewinnt:

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

Eine Datei nur mit Datenbanken oder Caches (kein App-Service) wird ignoriert. Ein Parse-Fehler wird ignoriert. Eine Compose-Datei tief in einem großen Repo kann fehlen, wenn der Scan abgeschnitten wird.

Was angelegt wird

Eine Application, nicht eine App pro Service. Extra-Services werden extra Prozesse auf dieser App. Der Wizard lässt dich Package und Replicas (1–16) vor dem Anlegen wählen. deploy.replicas in der Datei wird ignoriert.

Image-Tags wie postgres:16 wählen nicht die managed Engine-Version. Nodion nimmt den aktuellen Default für diese Engine. Datenbank-User und Passwörter kommen von Nodion, nicht aus der Compose-Env am Datenbank-Service.

Zeigt ein App-Service-Env-Wert auf einen anderen Service als Host (postgres://…@db:5432/…, redis://cache:6379), wird dieser Key ein Attach-Binding und kommt beim Deploy. Sonst binden Postgres-artige Datenbanken als DATABASE_URL, Valkey als REDIS_URL und MinIO als die üblichen AWS/S3-Keys.

Nur die restliche Environment des primären App-Service wird auf die App kopiert. Keys, die nach Secrets aussehen, sind im Formular als Secret markiert.

Volumes

Named Volumes werden Volumes (Default 5 GB, im Wizard änderbar) und mounten auf die passenden Prozesse. Bind-Mounts (./data:/data) und anonyme Volumes werden übersprungen.

Wie die App danach baut

Die Strategie der App bleibt Dockerfile oder Buildpacks, aus demselben Repo-Scan. Compose build.context und build.dockerfile werden nicht in diese Settings kopiert. Es gibt einen Git-Build pro App. Ein zweiter Service mit eigenem build: teilt sich dieses Image.

Ein Service, der nur image: hat (und keine gemappte Datenbank ist), behält dieses Image und läuft als Prozess. Der primäre Service mit build: heißt web.

Das erste Deploy wartet, bis angehängte Datenbanken und Buckets bereit sind. Nach dem Anlegen Prozesse, Env und Ressourcen im Dashboard ändern. Die Compose-Datei in Git zu editieren aktualisiert den Plan nicht.

Was ignoriert wird

• Networks, Profiles und Compose-Healthchecks
• depends_on als Startreihenfolge (ein Wait-only-Helper-Container wird übersprungen)
• Bind-Mounts
• Builds pro Service über das eine App-Image hinaus

Ist eine managed Engine oder Object Storage in der Region nicht verfügbar, wird diese Ressource übersprungen und die App trotzdem angelegt.