Migrare da Render
Migra i servizi Render con Postgres, variabili d'ambiente e domini.
Su Render ogni parte di un'applicazione è un servizio a sé: web service, background worker, private service, cron job. Su
Nodion fai la build di un'unica immagine e da questa esegui più processi in un'unica applicazione; i cron job appartengono all'app.
Nodion non legge un render.yaml, quindi devi trasferire le impostazioni manualmente.
Corrispondenze tra Render e Nodion
| Render | Nodion |
|---|---|
| Web service | Application con il processo web |
| Background worker | Un altro processo dell'app, per esempio worker |
| Private service | Processo con una porta, raggiungibile internamente su <app>-<process>.app.internal (riceve anche un hostname pubblico, vedi il passaggio 3) |
| Cron job (servizio a sé) | Cron job dell'app |
| Static site | Buildpack per siti statici |
| Build command e start command | Rilevamento del buildpack e Procfile, oppure il comando del processo |
| Pre-deploy command | Release command o voce release: del Procfile |
| Render Postgres | Postgres gestito, collegato come DATABASE_URL |
| Render Key Value | Valkey, collegato come REDIS_URL |
| Persistent disk | Volume |
| Preview environments, service previews | Ambienti di anteprima |
1. Crea il progetto e il database
Crea un progetto e, al suo interno, un database PostgreSQL nella regione in cui deve girare l'app. L'app e il suo database devono stare nella stessa regione. Scegli una versione di Postgres non precedente a quella su Render. Maggiori dettagli in Database.
2. Copia il database
L'URL del database per le connessioni esterne si trova nella pagina Info del database Render; Render accetta connessioni esterne solo con TLS
(documentazione Render). Blocca le scritture
dai tuoi servizi, poi crea il dump come indicato nella documentazione sui backup
di Render. -n public include solo lo schema public; omettilo se la tua app usa altri schemi.
bashpg_dump --dbname="RENDER_EXTERNAL_DATABASE_URL" -n public --no-owner \
--format=directory --jobs=4 --compress=0 -f render.dump/ In Nodion apri la scheda Overview del database e clicca Enable public access. Quando l'endpoint non mostra più Provisioning, copia l'URL di connessione (sempre TLS) e aggiungi il tuo IP in Allowed sources. Poi esegui il restore:
bashpg_restore --verbose --no-owner --no-privileges --jobs=4 --format=directory \
--dbname="postgresql://nodion:PASSWORD@HOST:PORT/DATABASE?sslmode=require" \
render.dump/
Usa un pg_restore almeno recente quanto il più recente dei due server. Controlla il numero di righe nella scheda Browse,
poi disattiva di nuovo l'accesso pubblico; il database continua a funzionare internamente.
3. Crea l'applicazione e i suoi processi
Crea un'applicazione dal repository Git del web service. Se Render faceva la build da build command e start command, usa la strategia
Buildpacks (Buildpack); un Procfile definisce i comandi, altrimenti valgono le impostazioni predefinite del linguaggio.
Se il servizio girava su Docker, usa la strategia Dockerfile.
Render imposta PORT a 10000 per impostazione predefinita. Nodion imposta PORT per il processo web delle app con buildpack
(valore predefinito: 8080); se la tua app legge PORT, non cambia nulla. Se 10000 è scritto nel codice, sostituiscilo. Sulle app Dockerfile
Nodion non imposta PORT; l'app resta in ascolto sulla porta del processo web.
Aggiungi ogni background worker dello stesso repo in Processes, New process come ulteriore processo e inserisci il suo start command.
Anche un private service diventa un processo, con una porta. Attenzione: ogni processo con una porta riceve un hostname pubblico
predefinito oltre al suo indirizzo interno; non esiste un servizio solo privato. Proteggi una porta di questo tipo nell'app (per esempio
con l'autenticazione). Gli hostname Nodion si possono disattivare solo per l'intera app, una volta attivo un dominio personalizzato. Un
worker che consuma solo una coda non ha bisogno di una porta. Sposta un pre-deploy command in una riga release: del
Procfile (buildpack) o nel release command dell'app (Settings, nel riquadro Preview environments, dove il campo compare una
volta attivate le anteprime, oppure release_command tramite l'API). Viene eseguito una volta per ogni deploy prima di
web; se fallisce, resta attiva la release precedente.
4. Trasferisci le variabili d'ambiente
Render non documenta un'esportazione delle variabili d'ambiente dalla dashboard; l'API di Render restituisce le variabili di un servizio,
ma non quelle degli environment group
(riferimento API di Render, GET /services/{serviceId}/env-vars;
sugli environment group vedi la documentazione Render).
Raccoglile come righe KEY=value, inclusi i valori degli environment group, e incollale in Environment, Add many.
Imposta i secret con nodion env set KEY=value --secret e i valori su più righe tramite CLI o API. Nodion non ha secret
file: salva il loro contenuto come variabile segreta (--secret) e fai in modo che l'app lo legga dalla variabile o scriva
il file da sola all'avvio. I secret non vanno nell'immagine, come avverte anche Render.
Elimina di nuovo DATABASE_URL e REDIS_URL di Render: una variabile impostata da te sovrascrive il valore di un
database collegato. Collega i database con Attach database. All'interno di Nodion la connessione passa senza TLS
(sslmode=disable); se il tuo codice forza SSL, disattivalo per questo URL, e lo stesso vale per rediss:// verso Valkey.
5. Trasferisci i cron job
Un cron job di Render è un servizio a sé con una pianificazione in UTC (documentazione Render). Su Nodion lo aggiungi nella scheda Cron dell'app di cui gli serve il codice: pianificazione a cinque campi in UTC, il comando, un timeout fino a 30 minuti, fino a 8 job per app. Se un'esecuzione è ancora in corso, quella successiva viene saltata.
6. Fai il deploy, trasferisci il dominio ed elimina i servizi Render
Fai il deploy e controlla la scheda Logs. Poi aggiungi il dominio nella scheda Domains e imposta i due record che mostra Nodion: TXT
_nodion-challenge.your-domain e un CNAME (un ALIAS sull'apex) verso l'hostname predefinito dell'app. Nodion non offre un
record A come destinazione, quindi sull'apex il tuo provider DNS deve supportare ALIAS, ANAME o CNAME flattening. Il certificato arriva
appena il CNAME punta a Nodion; metti in conto qualche minuto senza un certificato valido e abbassa prima il TTL.
Quando tutto funziona, elimina i servizi Render (Render CLI). Render non conserva backup di un database eliminato, quindi tieni il tuo dump.
bashrender services delete my-service --confirm Eliminare il servizio non elimina il database né un'istanza Key Value. Nelle istanze a pagamento, Render salva per impostazione predefinita i dati di Key Value su disco (documentazione Render): un Valkey vuoto basta solo per cache o code che prima lasci svuotare; se ti servono le chiavi, spostale prima di eliminare l'istanza. Elimina poi tu stesso il database Render Postgres, con Delete Database in fondo alla sua pagina Info (documentazione Render), e allo stesso modo l'eventuale istanza Key Value; i comandi CLI per entrambi sono nel riferimento della Render CLI.
Cosa funziona diversamente
- Non esistono environment group né secret file; ogni variabile appartiene a una sola app.
- Worker e private service sono processi di un'app, non servizi a sé.
- I cron job girano su un'app esistente con la sua release attiva.
- La CLI recupera i log ma non può seguirli; per vederli in tempo reale usa la scheda Logs.
Prossimi passi
Nodion e Render a confronto, Prezzi, Applicazioni e Database.