Fai il deploy di Docker Compose su Nodion

Deploy di Docker Compose passo dopo passo

1. Controlla il tuo file Compose Nodion legge docker-compose.yml, docker-compose.yaml, compose.yml o compose.yaml, prendendo il file più vicino alla root del repository. Oltre a database e cache serve almeno un servizio applicativo; un file con solo database e cache viene ignorato. 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. Scegli Docker Compose quando crei l'app Crea un'applicazione dal tuo repository nella regione EU Central. Quando la scansione trova un file Compose utilizzabile, compare l'opzione Docker Compose; non è mai preselezionata. Selezionala e controlla il piano: prima di creare l'app puoi ancora scegliere dimensione e istanze per processo e modificare le dimensioni dei volumi.
3. Guarda cosa diventa un servizio gestito Nodion si basa sul nome dell'immagine: postgres e postgis diventano Managed PostgreSQL, pgvector diventa pgvector, redis e valkey diventano Valkey, mysql e mariadb diventano MySQL, clickhouse diventa ClickHouse e minio diventa un bucket. Ogni altro servizio esegue la sua immagine come processo dell'unica app. Il tag dell'immagine non determina la versione del database, e utenti e password li fornisce Nodion. Managed PostgreSQL non ha l'estensione PostGIS, quindi un'app che ha bisogno di PostGIS perde le sue funzioni spaziali dopo l'importazione; lascia un database del genere fuori dal file Compose.
4. Controlla le variabili di connessione Una variabile del servizio applicativo che punta a un altro servizio per nome, come @db:5432 qui sopra, diventa un collegamento: Nodion inserisce l'indirizzo reale al momento del deploy. Altrimenti i database arrivano come DATABASE_URL e Valkey come REDIS_URL. Tra le altre variabili, Nodion copia solo quelle del servizio applicativo principale, e i valori che sembrano segreti vengono contrassegnati come tali.
5. Da lì in poi gestisci l'app nella dashboard Il primo deploy aspetta che i database siano pronti. Dopo, il file Compose non viene più letto: ogni push fa la build dell'app con la strategia Dockerfile o Buildpacks trovata nello stesso repository, e processi, variabili e dimensioni li modifichi nella dashboard.

Da sapere

• Sperimentale e una tantumL'importazione è una scorciatoia per la prima configurazione, non un runtime Compose. Se il file non viene convertito correttamente, ricrea la stessa configurazione a mano: un'app, un database collegato nella scheda Environment e processi aggiuntivi nella scheda Processes.
• Cosa ignora NodionReti, profili, healthcheck di Compose, depends_on come ordine di avvio, deploy.replicas, bind mount e volumi anonimi. Un secondo servizio con un proprio build: condivide l'unica immagine dell'app.
• VolumiI volumi con nome diventano volumi Nodion, da 5 GB come impostazione predefinita e modificabili nel piano, montati sui processi che li usano.

Cosa gestisce Nodion per te

• Deploy senza downtime Fai push sul tuo branch e Nodion crea una nuova release. Il traffico passa alle nuove istanze solo quando superano l'health check; una release fallita lascia attiva quella in esecuzione. Le app con un volume locale invece si riavviano, perché il disco appartiene a una sola istanza.
• Database accanto all'app PostgreSQL, pgvector, MySQL, Valkey e ClickHouse gestiti, nella stessa regione. I database collegati arrivano come DATABASE_URL, REDIS_URL o CLICKHOUSE_URL.
• Anteprime per ogni pull request Attiva le anteprime: ogni pull request del tuo repository riceve un'app dedicata, con un proprio URL e database nuovi e vuoti, creata automaticamente o manualmente. Le pull request dai fork e quelle dei bot vengono ignorate.
• Worker, cron job e scalabilità Esegui i worker come processi aggiuntivi della stessa app, pianifica i job nella scheda Cron e scala ogni processo fino a 16 istanze.
• Fase di release Con i buildpack, la riga release: del Procfile viene eseguita a ogni nuova build. Le app con Dockerfile, così come i redeploy e i rollback a un'immagine precedente, usano un comando di release impostato sull'app stessa, che ha anche la precedenza sulla riga del Procfile. Nei siti statici, la fase di release gira in un'immagine che contiene solo i file generati dalla build.
• Log e metriche Nella dashboard trovi log di build, release e runtime, oltre alle metriche di CPU, memoria, disco e rete per ogni istanza.
• Domini e HTTPS Un hostname predefinito con HTTPS dal primo deploy; i tuoi domini ricevono i certificati in automatico.

Per approfondire

• Dockerfile vs buildpack: quale dovresti usare? Entrambi trasformano il tuo codice in un'immagine container. Cambia chi scrive i passaggi della build, e questo determina controllo, manutenzione e aggiornamenti di sicurezza.
• Alternative a Railway in Europa: 5 opzioni a confronto Container e database fatturati a consumo, con un'azienda o una regione nell'UE: cinque alternative a Railway confrontate per fatturazione, database e sede.

Docker Compose su Nodion: domande e risposte