Docker Compose auf Nodion deployen

Docker Compose Schritt für Schritt deployen

1. Compose-Datei prüfen Nodion liest docker-compose.yml, docker-compose.yaml, compose.yml oder compose.yaml, und zwar die Datei, die am nächsten an der Wurzel des Repositorys liegt. Sie braucht neben Datenbanken und Caches mindestens einen App-Service; eine Datei nur mit Datenbanken und Caches wird ignoriert. 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. Beim Anlegen Docker Compose wählen Lege eine Application aus deinem Repository in der Region EU Central an. Findet der Scan eine passende Compose-Datei, erscheint die Option Docker Compose; vorausgewählt ist sie nie. Wähl sie aus und prüf den Plan: Vor dem Anlegen kannst du Größe und Instanzen pro Prozess noch wählen und die Größe der Volumes anpassen.
3. Sehen, was zum Managed Service wird Nodion richtet sich nach dem Image-Namen: Aus postgres und postgis wird Managed PostgreSQL, aus pgvector pgvector, aus redis und valkey Valkey, aus mysql und mariadb MySQL, aus clickhouse ClickHouse und aus minio ein Bucket. Jeder andere Service läuft mit seinem Image als Prozess der einen App. Der Image-Tag bestimmt nicht die Datenbankversion, und Benutzer und Passwörter kommen von Nodion. Managed PostgreSQL hat keine PostGIS-Erweiterung, eine App, die PostGIS braucht, verliert nach dem Import also ihre räumlichen Funktionen; lass eine solche Datenbank aus der Compose-Datei heraus.
4. Verbindungsvariablen prüfen Eine Variable des App-Service, die einen anderen Service beim Namen nennt, wie oben @db:5432, wird zur Verknüpfung: Nodion setzt beim Deploy die echte Adresse ein. Sonst kommen Datenbanken als DATABASE_URL und Valkey als REDIS_URL an. Von den übrigen Variablen übernimmt Nodion nur die des Haupt-App-Service, und Werte, die nach Secrets aussehen, werden als Secret markiert.
5. Danach die App im Dashboard pflegen Der erste Deploy wartet, bis die Datenbanken bereit sind. Danach liest Nodion die Compose-Datei nicht mehr: Jeder Push baut die App mit der Strategie Dockerfile oder Buildpacks, die im selben Repository gefunden wurde, und Prozesse, Variablen und Größen änderst du im Dashboard.

Gut zu wissen

• Experimentell und einmaligDer Import ist eine Abkürzung für das erste Setup, keine Compose-Laufzeit. Lässt sich deine Datei nicht sauber übertragen, baust du dasselbe Setup von Hand: eine App, eine Datenbank, angehängt auf dem Tab Environment, und weitere Prozesse auf dem Tab Processes.
• Was Nodion ignoriertNetworks, Profiles, Compose-Healthchecks, depends_on als Startreihenfolge, deploy.replicas, Bind Mounts und anonyme Volumes. Ein zweiter Service mit eigenem build: nutzt das eine App-Image mit.
• VolumesBenannte Volumes werden zu Nodion-Volumes, standardmäßig 5 GB und im Plan änderbar, eingehängt in die Prozesse, die sie nutzen.

Was Nodion für dich betreibt

• Deploys ohne Downtime Push auf deinen Branch und Nodion baut ein neues Release. Der Traffic wechselt erst, wenn die neuen Instanzen ihren Health Check bestehen; ein fehlgeschlagenes Release lässt das laufende stehen. Apps mit lokalem Volume starten stattdessen neu, weil die Disk zu einer Instanz gehört.
• Datenbanken neben der App Managed PostgreSQL, pgvector, MySQL, Valkey und ClickHouse in derselben Region. Angehängte Datenbanken kommen als DATABASE_URL, REDIS_URL oder CLICKHOUSE_URL in die App.
• Previews pro Pull Request Schalte Previews ein, und Pull Requests aus deinem Repository bekommen eine eigene App mit eigener URL und frischen, leeren Datenbanken, automatisch oder per Hand angelegt. Forks und Bot-Pull-Requests werden übersprungen.
• Worker, Cron Jobs und Skalierung Worker laufen als weitere Prozesse derselben App, Jobs planst du auf dem Tab Cron, und jeden Prozess skalierst du auf bis zu 16 Instanzen.
• Release-Schritt Mit Buildpacks läuft eine release:-Zeile in der Procfile bei jedem neuen Build. Dockerfile-Apps sowie Redeploys und Rollbacks auf ein früheres Image nutzen einen Release Command, der an der App selbst gesetzt ist; er hat auch Vorrang vor der Procfile-Zeile. Bei statischen Sites läuft ein Release-Schritt in einem Image, das nur die gebauten Dateien enthält.
• Logs und Metriken Build-, Release- und Laufzeit-Logs sowie CPU-, Speicher-, Disk- und Netzwerk-Metriken für jede Instanz im Dashboard.
• Domains und HTTPS Ein Default-Hostname mit HTTPS ab dem ersten Deploy; deine eigenen Domains bekommen automatisch Zertifikate.

Weiterlesen

• Dockerfile vs Buildpacks: was solltest du nutzen? Beide machen aus deinem Code ein Container-Image. Der Unterschied ist, wer die Build-Schritte schreibt, und das entscheidet über Kontrolle, Wartung und Security-Updates.
• Railway-Alternativen in Europa: 5 Optionen im Vergleich Container und Datenbanken nach Verbrauch, mit Unternehmen oder Region in der EU: fünf Railway-Alternativen nach Abrechnung, Datenbanken und Standort.

Docker Compose auf Nodion: Fragen und Antworten