PostgreSQL gestito su Dockup: guida completa

PostgreSQL gestito fornisce all’applicazione un database con operazioni sul ciclo di vita separate dal container del servizio. Dockup supporta la creazione, l’avvio e l’arresto, i log, il controllo delle dimensioni, i backup, il ripristino tramite la piattaforma, gli utenti in sola lettura, la migrazione dei nodi e il networking privato.

Il principio operativo fondamentale è la separazione: l’immagine dell’applicazione è usa e getta, i dati PostgreSQL sono persistenti, le credenziali sono segreti e il ripristino del database deve essere testato indipendentemente dal rollback dell’applicazione.

Come si crea un database PostgreSQL gestito?

Seleziona il workspace desiderato, quindi crea il database:

dockup db create \
  --name main-db \
  --type postgresql \
  --json

Elenca i database per confermare lo slug e lo stato esatti:

dockup db list --json

Le operazioni sui database usano target nel formato project/db:

dockup db size production/main-db --json

Attendi il completamento del provisioning prima di collegare un’applicazione. Non dedurre hostname, porta, username o password dal nome del database.

Il piano Free consente di avere tre database in un workspace e include un credito iniziale di 10 $. I piani a pagamento—Hobby a 5 $, Pro a 20 $ al mese—consentono database, workspace e deployment illimitati. Il consumo di CPU, RAM e disco viene misurato al minuto rispetto al saldo di utilizzo incluso.

Come si collega un’applicazione in sicurezza?

Recupera i dati di connessione al database dall’interfaccia del database di Dockup e tratta la stringa di connessione come un segreto. Non inserirla nel repository o nella trascrizione dell’agent.

Impostala sul servizio:

dockup env set DATABASE_URL="$DATABASE_URL" \
  --secret \
  -s production/api \
  --json

dockup deploy production/api --wait --json

Il redeploy è necessario perché il processo in esecuzione riceve il proprio ambiente all’avvio. Il valore memorizzato viene mascherato quando si legge la configurazione dell’ambiente.

Configura con attenzione il connection pooling dell’applicazione. Un numero eccessivo di worker con pool grandi può esaurire le connessioni al database anche quando CPU e memoria sembrano nella norma. Imposta la dimensione del pool in base al carico di lavoro e alla capacità del database, non in base al numero massimo accettato da un framework.

Testa una nuova connessione dopo il deployment. Un health endpoint può confermare che il processo HTTP è attivo senza dimostrare che sia possibile stabilire una nuova sessione del database.

La guida variabili d’ambiente e segreti illustra la rotazione delle credenziali e l’output mascherato.

In che modo il networking privato protegge il traffico PostgreSQL?

Abilita una rete privata del progetto:

dockup network enable production --json

I servizi e i database gestiti del progetto ricevono hostname stabili nel formato <slug>.internal. Esegui il redeploy dell’applicazione per ricevere le variabili di connessione interne iniettate.

Per rimuovere il listener pubblico del database e renderlo accessibile solo privatamente:

dockup db private production/main-db --json

Ripristina l’accesso pubblico oltre a quello privato quando necessario:

dockup db private production/main-db --off --json

Rendere il database accessibile solo privatamente ricrea il relativo container preservando i dati. Pianifica e verifica la modifica come un’operazione sul database, non come una modifica DNS innocua.

Il networking privato controlla il percorso, mentre le credenziali PostgreSQL controllano identità e autorizzazioni. Mantienili entrambi. I progetti separati non possono raggiungersi perché ogni progetto dispone della propria rete.

L’articolo networking privato e domini interni descrive la topologia completa.

Come funzionano backup e ripristino di PostgreSQL?

Elenca i backup esistenti:

dockup db backups production/main-db --json

Avvia un backup lato server:

dockup db backup production/main-db --json

Il comando di backup crea un backup consapevole della struttura del database, non una copia a caldo del volume grezzo. Registra l’ID del backup, l’ora di creazione, la versione del database e il motivo.

Dockup supporta il ripristino dei backup dei database gestiti tramite la piattaforma. Il riferimento CLI corrente non documenta un comando dockup db restore, quindi questa guida non ne inventa uno. Esegui il ripristino dall’interfaccia Dockup supportata, seleziona il backup esatto, ottieni l’approvazione per la produzione e verifica il risultato.

Un piano di ripristino dovrebbe includere:

1. Punto di ripristino e finestra prevista di perdita delle scritture.
2. Blocco delle scritture dell’applicazione o comportamento durante la manutenzione.
3. Compatibilità del database e delle estensioni.
4. Nuovo backup dello stato corrente, quando utile.
5. Responsabile del ripristino e approvazione.
6. Riconnessione dell’applicazione e smoke test.
7. Audit e registrazione dell’incidente.

I backup non sono verificati finché un’esercitazione di ripristino non ha esito positivo. Usa un database non di produzione o un ambiente di recovery approvato per testare la procedura.

Conserva i backup secondo una policy approvata. Rimuovi i punti di ripristino obsoleti solo tramite l’interfaccia del database supportata, dopo aver verificato che nessun requisito di recovery o di compliance dipenda ancora da essi.

Come funzionano gli utenti PostgreSQL in sola lettura?

Gli utenti aggiuntivi in sola lettura sono utili per analytics, indagini del supporto, preview deployment e strumenti che devono eseguire query senza scrivere.

Elenca gli utenti:

dockup db users production/main-db --json

Creane uno con un’etichetta:

dockup db user-add production/main-db \
  --label analytics \
  --json

Acquisisci la credenziale generata in modo sicuro durante la creazione e non riprodurla in una risposta dell’agent. Revoca l’utente aggiuntivo tramite l’interfaccia supportata per la gestione degli utenti del database quando termina la sua utilità.

La sola lettura a livello di permessi del database è più sicura del dire a uno strumento per query “non scrivere”. Consente comunque di accedere ai dati di produzione leggibili, quindi si applicano le regole di privacy e del least privilege.

Dockup crea automaticamente un utente del database in sola lettura per una preview di PR o di branch in un progetto con networking privato. La preview può raggiungere lo stesso database di produzione all’indirizzo <slug>.internal e leggere i dati senza ottenere permessi di scrittura.

Come si controllano dimensioni, log e posizionamento?

Controlla le dimensioni su disco:

dockup db size production/main-db --json

Esamina i log runtime dell’applicazione per individuare errori di connessione senza esporre password o stringhe di connessione complete:

dockup logs production/api --json

La manutenzione del database può rendere non disponibili i servizi dipendenti. Pianifica le operazioni che modificano lo stato, richiedi un’approvazione operativa esplicita e comunica l’impatto prima di procedere.

Sposta un database tra i nodi indicando l’ID del nodo di destinazione:

dockup db migrate production/main-db \
  --node <nodeId> \
  --json

La migrazione è un’operazione stateful. Conferma lo stato dei backup, le aspettative di manutenzione, le connessioni alla rete privata e i controlli dell’applicazione dopo lo spostamento.

Checklist di produzione per PostgreSQL gestito

Un runbook completo registra:

Area	Evidenza richiesta
Identità	Target project/db esatto
Connettività	Stringa di connessione segreta e nuova sessione testata
Rete	Policy pubblica, privata o solo privata
Accesso	Ruolo dell’applicazione e utenti in sola lettura con etichetta
Capacità	Dimensioni correnti e analisi della crescita
Backup	ID dei backup recenti e retention
Recovery	Esercitazione di ripristino completata con successo
Operazioni	Approvazione per avvio, arresto, riavvio e migrazione
Audit	Modifiche al database riconducibili a un attore

Il rollback del deployment dell’applicazione non ripristina PostgreSQL. Il ripristino del database non esegue automaticamente il rollback del codice dell’applicazione. Coordina entrambe le operazioni solo quando la compatibilità dello schema lo richiede.

Per decisioni di scaling più ampie, leggi strategie di scaling dei database. Per i comandi esatti, consulta il riferimento CLI di Dockup.

Progetta le migrazioni dello schema per deployment e rollback

Il deployment dell’applicazione e la modifica dello schema del database avvengono su timeline diverse. In genere, una migrazione sicura è backward compatible per almeno una finestra di release: aggiungi una colonna nullable prima di renderla obbligatoria, esegui il deployment di codice in grado di gestire entrambi gli schemi, completa il backfill con una procedura controllata e rimuovi la struttura precedente in seguito.

Non fare eseguire a un health check una migrazione lunga. Se l’applicazione avvia diverse replica, assicurati che un solo migration runner possa gestire la modifica. Il comando exec del container PRO può eseguire un comando una tantum e propagare il relativo exit code reale:

dockup exec "npm run migrate" \
  -s production/api \
  --json

Usalo solo quando il comando di migrazione è stato verificato e il servizio è in esecuzione sul main server supportato. Acquisisci stdout, stderr ed exit code. Un deployment dell’applicazione completato con successo non significa che si possa ignorare una migrazione fallita.

Ruota le credenziali del database senza interruzioni

Crea la nuova credenziale o il nuovo utente in sola lettura, aggiorna il secret del servizio che lo utilizza, esegui il redeploy e verifica una nuova connessione prima di revocare la vecchia credenziale. I connection pool esistenti possono nascondere una nuova password errata finché non effettuano una riconnessione.

Per la credenziale principale dell’applicazione, usa l’interfaccia Dockup supportata e la policy del database. Per un utente analitico aggiuntivo, crea un account in sola lettura con un’etichetta e distribuiscilo solo al consumer approvato.

Il record della rotazione dovrebbe elencare l’etichetta dell’utente, i servizi che lo utilizzano, gli ID dei deployment, la query di verifica, l’ora di revoca e l’evento di audit—mai la password.

Osserva la crescita prima di fare scaling

Le dimensioni del database sono uno degli indicatori:

dockup db size production/main-db --json

Combinale con la latenza delle query dell’applicazione, il numero di connessioni, il comportamento della cache, la durata dei backup e la crescita dello storage. Un’allocazione maggiore di CPU o memoria potrebbe non risolvere la mancanza di indici o query senza limiti.

Consulta strategie di scaling dei database prima di spostare i nodi o aumentare le risorse. PostgreSQL gestito riduce il lavoro di provisioning, ma la progettazione dello schema e delle query resta una responsabilità dell’applicazione.

Separa disponibilità e correttezza

Un container del database in esecuzione dimostra che PostgreSQL è disponibile, non che le query dell’applicazione siano corrette. Includi nella verifica post-deployment una nuova connessione a basso rischio e una lettura rappresentativa. Per un test di scrittura, usa una transazione dedicata o un record di test che possa essere rimosso in sicurezza.

Il runbook di PostgreSQL gestito dovrebbe inoltre indicare se replica, utenti analitici, preview o background worker generano ulteriore pressione sulle connessioni.

Riesamina regolarmente gli accessi a PostgreSQL

Elenca gli utenti aggiuntivi, conferma che ogni etichetta abbia un responsabile attivo e rimuovi gli account obsoleti. Questa semplice revisione impedisce che gli accessi in lettura di PostgreSQL gestito si accumulino al termine di preview, progetti di analytics o indagini del supporto.

Inizia con un deployment verificabile

Crea un database PostgreSQL non di produzione, collega un servizio di test tramite un secret mascherato, esegui un backup e completa un’esercitazione di ripristino prima del passaggio in produzione.

Inizia gratis su app.dockup.ai. Il piano Free costa 0 $ al mese, include un credito iniziale di 10 $ e supporta un workspace, tre database e tre deployment.

FAQ

Quali tipi di database gestiti supporta Dockup?

Dockup supporta database gestiti PostgreSQL, MySQL, MongoDB e Redis.

Come dovrebbe ricevere un’applicazione la stringa di connessione PostgreSQL?

Tratta la stringa di connessione come una variabile d’ambiente segreta, impostala sul servizio esatto ed esegui il redeploy affinché il nuovo container la riceva.

Dockup può creare un utente PostgreSQL in sola lettura?

Sì. Il comando database user-add crea un utente aggiuntivo in sola lettura e restituisce la relativa password una sola volta, durante la creazione.

Esiste un comando CLI documentato dockup db restore?

Il riferimento CLI corrente non ne documenta uno. Dockup supporta il ripristino dei backup tramite l’interfaccia della piattaforma, quindi usa il percorso supportato invece di inventare un flag o un comando.

Il rollback dell’applicazione ripristina il database PostgreSQL?

No. La cronologia dei deployment dell’applicazione e quella dei backup del database sono sistemi di recovery separati e devono essere coordinati quando le modifiche allo schema richiedono entrambe le operazioni.