Docker Compose

Importa un file compose una volta. Nodion lo trasforma in un'app, processi e servizi gestiti.

Guide passo passo al deploy: Docker Compose.

Questo percorso è sperimentale. Non è docker compose up. Dopo l'importazione Nodion non esegue Compose, non applica le reti e non rilegge il file nei deploy successivi.

In Applications → New collega un repo Gite, se la scansione trova un file Compose con almeno un servizio dell'app, compare l'opzione Docker Compose. Non è mai preselezionata. Cliccala, controlla il piano e poi crea l'app.

Quale file

Tra questi nomi vince il file meno annidato:

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

Un file con solo database o cache (nessun servizio app) viene ignorato. Anche un errore di parsing fa ignorare il file. Un file Compose in una sottocartella profonda di un repository grande può sfuggire se la scansione viene troncata.

Cosa viene creato

Una sola applicazione, non un'app per servizio. I servizi aggiuntivi diventano processi aggiuntivi su quell'app. Il wizard ti fa scegliere package e repliche (1-16) prima della creazione. deploy.replicas nel file viene ignorato.

I tag delle immagini come postgres:16 non scelgono la versione del motore gestito. Nodion usa la versione attualmente predefinita per quel motore. Utenti e password del database li genera Nodion, non provengono dalle variabili d'ambiente del servizio database in Compose.

Se il valore di una variabile d'ambiente di un servizio app punta a un altro servizio come host (postgres://…@db:5432/…, redis://cache:6379), quella chiave diventa un collegamento e viene iniettata al deploy. Altrimenti i database compatibili con Postgres vengono collegati come DATABASE_URL, Valkey come REDIS_URL e MinIO con le solite chiavi AWS/S3.

Sull'app vengono copiate solo le restanti variabili d'ambiente del servizio app principale. Le chiavi che sembrano segreti sono contrassegnate come secret nel modulo.

Volumi

I volumi con nome diventano volumi (5 GB per impostazione predefinita, modificabili nel wizard) e vengono montati sui processi corrispondenti. I bind mount (./data:/data) e i volumi anonimi vengono ignorati.

La build dell'app dopo l'importazione

La strategia dell'app resta Dockerfile o Buildpack, in base alla stessa scansione del repo. build.context e build.dockerfile di Compose non vengono copiati in quelle impostazioni. C'è una sola build Git per app. Un secondo servizio con un proprio build: condivide quell'immagine.

Un servizio che ha solo image: (e non è un database mappato) mantiene quell'immagine e la esegue come processo. Il servizio principale con build: viene rinominato in web.

Il primo deploy attende che i database e i bucket collegati siano pronti. Dopo la creazione, modifica processi, variabili d'ambiente e risorse nella dashboard. Modificare il file compose in Git non aggiorna il piano di importazione.

Cosa viene ignorato

• Reti, profili e health check di Compose
• depends_on come ordine di avvio (un container helper che serve solo ad attendere viene saltato)
• Bind mount
• Build per singolo servizio oltre all'unica immagine dell'app

Se un motore gestito o l'object storage non sono disponibili nella regione, quella risorsa viene saltata e l'app viene creata comunque.