Fai il deploy di Docker su Nodion

Deploy di Docker passo dopo passo

1. Ascolta su 0.0.0.0 e indica la porta con EXPOSE Nodion fa la build del tuo Dockerfile così com'è e avvia il CMD o l'ENTRYPOINT dell'immagine. Non imposta PORT: il tuo server ascolta su tutte le interfacce su una porta fissa, e EXPOSE indica al modulo di creazione quale. Le build multi-stage funzionano; viene eseguito lo stage finale. Dockerfile

   FROM python:3.13-slim
   WORKDIR /app
   COPY requirements.txt .
   RUN pip install --no-cache-dir -r requirements.txt
   COPY . .
   EXPOSE 8000
   CMD ["gunicorn", "app:app", "--bind", "0.0.0.0:8000"]

2. Crea l'app Nella dashboard, crea un'applicazione dal tuo repository GitHub, GitLab, Bitbucket o Gitea, scegli il branch e la regione EU Central. Con un Dockerfile nel repository, il modulo preseleziona la strategia Dockerfile e prende la porta da EXPOSE. In un monorepo, imposta la base directory (il contesto di build) e il nome del Dockerfile.
3. Passa i valori di build come build arg Le variabili con il flag Build nella scheda Environment arrivano alla build come build arg di Docker, quindi dichiarale con ARG nello stage che le legge. Tutte le altre variabili, e i database collegati come DATABASE_URL, esistono solo quando il container è in esecuzione. Dockerfile

   FROM node:24-slim AS build
   ARG VITE_API_URL
   WORKDIR /app
   COPY . .
   RUN npm ci && npm run build

4. Esegui le migrazioni una volta per deploy Imposta il comando delle migrazioni come comando di release dell'app: viene eseguito una volta per deploy dalla nuova immagine, prima che parta la nuova versione, e se fallisce il deploy si ferma mentre la versione in esecuzione resta online. Impostalo con il campo API release_command; nella dashboard, per ora il campo compare nelle impostazioni dell'app solo quando gli ambienti di anteprima sono attivi. Puoi anche eseguire le migrazioni nell'entrypoint o nel comando di avvio, ma in quel caso ogni istanza le esegue a ogni avvio.
5. Push e deploy Ogni push sul branch avvia la build di una nuova immagine a Francoforte. Il traffico passa alla nuova immagine appena il processo web risponde con 2xx o 3xx sul percorso dell'health check (predefinito /). Un HEALTHCHECK Docker nell'immagine viene ignorato.

Da sapere

• Nessuna variabile PORTSe il tuo server legge PORT, impostala tu, con ENV PORT=8000 nel Dockerfile o come variabile nella scheda Environment, e tienila uguale alla porta del processo web.
• Immagini già pronteSalta la build da Git e fai il deploy di un'immagine da Docker Hub, dal GitHub Container Registry, dal registry di Nodion o da un registry privato di cui hai salvato le credenziali in Nodion. Valgono le stesse regole per porta e health check.
• USER, .dockerignore e il commitL'istruzione USER dell'immagine viene rispettata, un .dockerignore nel contesto di build viene applicato e .git non viene mai inviato alla build. Dichiara ARG NODION_GIT_SHA per scrivere l'hash del commit nell'immagine.

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 su Nodion: domande e risposte