Come migrare da Heroku al tuo VPS

Heroku rendeva il deployment semplice, e ora andarsene sembra come aprire un armadio che non avresti mai dovuto vedere.

Versione breve: per migrare da Heroku al tuo server, devi spostare codice dell’app, runtime, variabili d’ambiente, database, worker in background, job programmati, dominio e configurazione HTTPS. Ricostruisci questi pezzi sul server, testa la nuova copia prima che la vedano i visitatori, poi cambia il DNS — la rubrica degli indirizzi del dominio — quando sei sicuro che funzioni.

Perché spostarsi da Heroku sembra così diverso?

Heroku è come un appartamento servito. Tu porti la tua app, e Heroku gestisce in sottofondo riscaldamento, serrature, pulizie, portineria e riparazioni.

Il tuo server è più come ricevere le chiavi dell’intero edificio. Hai più controllo, ma devi anche sapere dov’è il quadro elettrico.

Su Heroku, un dyno è la piccola unità in esecuzione che ospita la tua app. Un Procfile dice a Heroku quale processo avviare, per esempio “esegui l’app web” o “esegui il worker”. Heroku nasconde anche molto lavoro di routine: riavviare processi andati in crash, raccogliere log, collegare database, gestire HTTPS e instradare il traffico web.

Quando te ne vai, quei lavori non spariscono. Diventano solo visibili.

Questo non significa che la migrazione debba fare paura. Significa che dovresti trattarla meno come “copiare un sito” e più come traslocare un piccolo negozio: scaffali, merce, insegne, chiavi, POS, orari di apertura e l’elenco delle persone che sanno dove trovarti.

Cosa devi spostare prima di deviare il traffico?

Parti dal pezzo più ovvio: il codice della tua app. Ma non fermarti lì.

Un’app Heroku di solito dipende da varie cose che vivono attorno al codice:

• Runtime: la versione del linguaggio e il gestore di pacchetti che la tua app si aspetta, come Node.js, Python, Ruby o PHP.
• Variabili d’ambiente: Heroku le chiama Config Vars. Sono valori segreti o specifici dell’app, come indirizzi del database, chiavi API e impostazioni email.
• Database: per esempio Heroku Postgres. Spesso è la parte più importante dello spostamento, perché contiene utenti, ordini, post o impostazioni.
• Add-on: email, Redis, ricerca, logging, monitoraggio, storage a oggetti o code.
• Worker in background: processi separati che inviano email, ridimensionano immagini, elaborano pagamenti o svolgono lavori lenti fuori dal sito principale.
• Job programmati: attività di Heroku Scheduler, attività in stile cron o lavori di manutenzione ricorrenti.
• Upload e file: il filesystem locale di Heroku è temporaneo, quindi molte app salvano i file altrove. Controlla dove vivono davvero gli upload degli utenti.
• Dominio e HTTPS: il tuo dominio deve puntare al nuovo server, e il browser deve fidarsi del certificato.

L’errore più grande è spostare solo il processo web e dimenticare gli aiutanti silenziosi. Un negozio può aprire la porta d’ingresso, ma se mancano magazzino, terminale per le carte e corriere, i clienti avranno comunque una brutta giornata.

Prima di toccare il dominio in produzione, prepara un piano di backup. Un backup non è solo un file che speri funzioni; è qualcosa che sai di poter ripristinare. Se non ci hai ancora pensato bene, leggi come fare il backup del server prima della migrazione.

Dovresti usare Docker, uno strumento di piattaforma o una configurazione server semplice?

Non esiste un’unica strada giusta. La scelta corretta dipende da quanto vuoi che resti nascosto.

Docker è uno strumento di packaging. Pensalo come una schiscetta per la tua app: l’app, l’ambiente che si aspetta e le sue dipendenze viaggiano insieme. Questo può rendere più facile una migrazione da Heroku, perché anche Heroku ti abitua a ragionare in termini di processi dell’app.

Uno strumento in stile piattaforma ti dà pulsanti e schermate attorno al deployment. Una configurazione server semplice ha meno parti mobili, ma devi capirne di più.

Se Docker è una novità per te, parti da Docker su un server per principianti. Se il tuo obiettivo è semplicemente mettere online una piccola app senza diventare sysadmin a tempo pieno, pubblicare una web app senza DevOps offre una panoramica più graduale.

Come fai il passaggio senza rompere il sito?

Non rendere la prima versione del nuovo server quella live.

Per prima cosa, costruisci la nuova configurazione su un indirizzo temporaneo, per esempio un sottodominio di test. Così puoi controllare homepage, login, letture dal database, scritture sul database, invio email, job in background, upload di file e pagine di amministrazione senza chiedere subito agli utenti reali di fidarsi.

Poi copia il database con attenzione. Se la tua app accetta modifiche dagli utenti — ordini, commenti, prenotazioni, messaggi — decidi come gestirai la finestra finale. Alcuni team mettono brevemente in pausa le scritture sulla vecchia app. Altri fanno una copia completa, la testano, poi fanno una copia finale più piccola appena prima del cambio.

Poi cambia il DNS. Il DNS è la rubrica degli indirizzi di internet: dice ai browser dove si trova il tuo dominio. Per un po’, alcuni visitatori potrebbero ancora raggiungere Heroku mentre altri raggiungono il nuovo server, quindi tieni disponibile la vecchia app finché il traffico non si è chiaramente spostato.

Infine, guarda i segnali noiosi: log degli errori, consegna delle email, code dei worker, spazio su disco, uso della memoria e tempi di risposta. Una migrazione non è finita quando la homepage si carica una volta. È finita quando tutta l’app si comporta normalmente nell’uso reale.

FAQ

Posso migrare da Heroku senza downtime? Spesso sì, o quasi. La chiave è testare prima il nuovo server, pianificare la copia finale del database e cambiare DNS solo quando la nuova app è pronta.

Che fine fanno le Config Vars di Heroku? Devi ricrearle come variabili d’ambiente sul nuovo server. Valori mancanti o scritti male sono una causa comune di login rotti, email fallite ed errori di connessione al database.

Devo per forza usare Docker? No. Docker può rendere la configurazione più facile da spostare e ripetere, ma un’app semplice può anche girare direttamente su un server se l’ambiente è chiaro e documentato.

Qual è la parte più rischiosa nel lasciare Heroku? Di solito il database e i job in background. Se uno dei due viene dimenticato o copiato nel momento sbagliato, l’app può sembrare a posto mentre perde lavoro in silenzio.

La scorciatoia

Server Manager aiuta mantenendo lo spostamento comprensibile, invece di trasformarlo in un mucchio di decisioni server dimenticate. Il risultato che vuoi è semplice: l’app gira, il dominio punta al posto giusto, HTTPS resta valido e ogni progetto è separato abbastanza da impedire che un’app ne rompa accidentalmente un’altra.

Aiuta anche con le trappole specifiche che tendono a comparire dopo l’uscita da Heroku: una variabile d’ambiente mancante, una connessione al database sbagliata, un certificato scaduto, un worker mai avviato o una configurazione che nessuno sa spiegare tre mesi dopo. Il vero vantaggio non è evitare ogni dettaglio tecnico; è mantenere i dettagli importanti visibili e leggibili.

Quando la migrazione è fatta bene, Heroku smette di essere la rete di sicurezza che hai paura di rimuovere. Sai dove vive l’app, da cosa dipende, come viene raggiunta e cosa controllare se qualcosa va storto.