Come fare self-hosting di CloudBeaver nel 2026: driver dei database, workspace e accesso

La demo più semplice di CloudBeaver dimostra che un processo è in ascolto sulla porta 8978. In produzione servono prove più solide. Il sistema deve superare questo scenario anche dopo la sostituzione del container: completare la configurazione dell'amministratore, installare il driver necessario, connettersi tramite hostname privato ed eseguire una query di sola lettura.

CloudBeaver viene distribuito per uno scopo preciso: offrire un client per database via browser, compatibile con Postgres, MySQL e altri database. Il problema più comune nella sua distribuzione è che le autorizzazioni del workspace non funzionino o che il DNS del container non riesca a risolvere gli host dei database; per questo la gestione dell'URL pubblico e dello stato persistente richiede la stessa attenzione dell'avvio dell'immagine.

Ripristinare CloudBeaver su un host vuoto

Elenca lo stato prima di creare il primo record reale: workspace, utenti, definizioni delle connessioni e storage delle credenziali. Monta /opt/cloudbeaver/workspace prima del bootstrap, scrivi dati di esempio innocui e sostituisci il container per dimostrare che quel percorso è realmente persistente. Verifica il mount scrivendo dati innocui, sostituendo CloudBeaver e rileggendoli.

Gli snapshot sono utili per un rollback rapido, ma serve un backup indipendente quando l'host o il volume scompaiono. Esegui il ripristino in un ambiente vuoto con l'immagine fissata a una versione specifica e verifica che workspace, utenti, driver e connessioni vengano ripristinati, mentre ogni database sottostante segue il proprio piano di backup. Usa volumi persistenti e snapshot per mantenere distinti questi due meccanismi di ripristino.

Avviare CloudBeaver con impostazioni predefinite osservabili

Il comando seguente rende visibile il confine del container senza fingere di eseguire il provisioning di ogni servizio esterno.

docker run -d \
  --name cloudbeaver \
  --restart unless-stopped \
  -p 127.0.0.1:8978:8978 \
  -v cloudbeaver-data:/opt/cloudbeaver/workspace \
  -e CB_SERVER_NAME=CloudBeaver \
  dbeaver/cloudbeaver:latest

Prima di aprire l'ingress, controlla l'ambiente risolto, i mount e il listener. Aggiungi le impostazioni di connessione verificate per i percorsi privati e i driver del database per ogni database di destinazione; usa nomi privati per i servizi privati. Un avvio corretto si conclude quando puoi completare la configurazione dell'amministratore, installare il driver necessario, connetterti tramite hostname privato ed eseguire una query di sola lettura, non quando docker ps stampa Up.

Da cosa dipende CloudBeaver

Il processo HTTP di CloudBeaver è in ascolto sulla porta 8978; mantieni questa porta sulla rete applicativa e pubblica solo il percorso della piattaforma. Il contratto di rete per CloudBeaver è costituito da percorsi privati e driver del database per ogni database di destinazione. Mantieni gli endpoint privati sul DNS interno, consenti solo le chiamate outbound necessarie e assegna a CloudBeaver una service credential con privilegi limitati.

Metti per iscritto il confine in un breve contratto: chi è responsabile del requisito, quale credential viene usata, quale timeout è accettabile e come si manifesta un errore. Esegui quindi questa transazione: completa la configurazione dell'amministratore, installa il driver necessario, connettiti tramite hostname privato ed esegui una query di sola lettura. Durante l'esecuzione osserva lo stato del workspace, i download dei driver, le sessioni concorrenti e la latenza di rete verso ogni database, perché questo carico di lavoro fornisce una dimensione iniziale più utile rispetto a un container inattivo.

Distinguere correttamente gli URL interni da quelli esterni

Il confine pubblico di CloudBeaver dovrebbe essere costituito da un unico hostname canonico, TLS automatico e un unico target interno sulla porta 8978. Imposta il server URL e gli header del proxy per l'origine HTTPS pubblica, in modo che i client tornino a un indirizzo riconosciuto dal servizio.

Se la transazione di accettazione non riesce, classifica il primo errore. I problemi di DNS, certificati e 502 rientrano nella checklist di validazione TLS. La condizione “le autorizzazioni del workspace non funzionano o il DNS del container non riesce a risolvere gli host dei database” riguarda il lato applicativo, dopo che una richiesta ha raggiunto correttamente CloudBeaver.

Un test di accettazione di produzione per CloudBeaver

Non usare il traffico del primo utente come test di accettazione per CloudBeaver. Prepara uno stato di esempio innocuo ed esegui l'azione completa “completare la configurazione dell'amministratore, installare il driver necessario, connettersi tramite hostname privato ed eseguire una query di sola lettura”. Annota l'URL pubblico esatto, il risultato, il riferimento dell'immagine e l'intervallo dei log associati all'esecuzione.

Sostituisci il container e ripeti il test senza ricostruire i dati. Poi esegui il ripristino su un host vuoto; la condizione di recupero è che workspace, utenti, driver e connessioni vengano ripristinati, mentre ogni database sottostante segue il proprio piano di backup. Osserva lo stato del workspace, i download dei driver, le sessioni concorrenti e la latenza di rete verso ogni database a ogni passaggio e definisci un alert sul degrado della transazione, anziché sulle metriche di un container inattivo.

Un'ultima verifica dovrebbe fallire intenzionalmente: nega temporaneamente all'identità di test l'accesso ai percorsi privati e ai driver del database per ogni database di destinazione. Verifica che il messaggio risultante di CloudBeaver identifichi il confine rilevante, invece di avviare la cancellazione dei dati o un riavvio continuo. Ripristina la condizione valida e conferma che la stessa transazione di esempio vada a buon fine. Mantieni questo breve test nella checklist di release.

Diagnosticare un CloudBeaver che sembra funzionare

La prima metrica operativa utile per CloudBeaver è la capacità di completare la configurazione dell'amministratore, installare il driver necessario, connettersi tramite hostname privato ed eseguire una query di sola lettura. Affiancala ai segnali di saturazione relativi allo stato del workspace, ai download dei driver, alle sessioni concorrenti e alla latenza di rete verso ogni database. Un probe limitato al processo non dovrebbe chiamare dipendenze costose né riavviare il container perché un servizio upstream è temporaneamente non disponibile.

Considera gli aggiornamenti come modifiche ai dati, perché le migrazioni del workspace di CloudBeaver e la compatibilità dei driver devono essere testate prima di cambiare versione dell'immagine. Fissa le versioni, prova la procedura su uno stato ripristinato e mantieni disponibile l'immagine precedente finché il rollback non resta valido. Quando le autorizzazioni del workspace non funzionano o il DNS del container non riesce a risolvere gli host dei database, conserva i log precedenti al riavvio: di solito contengono il messaggio che identifica la causa.

Decisioni di sicurezza specifiche per CloudBeaver

Non ereditare le assunzioni di sicurezza di un tutorial locale. Il problema specifico di CloudBeaver è consentire l'accesso anonimo alle connessioni ai database di produzione. In produzione dovresti quindi disabilitare l'amministrazione anonima, usare utenti individuali e assegnare agli account dei database solo i permessi necessari per ciascuna connessione.

CB_SERVER_NAME controlla il comportamento, non la riservatezza; convalida tipo e valore e conserva separatamente le credenziali effettive di CloudBeaver. Limita l'accesso al filesystem e alla rete, proteggi gli endpoint di setup e definisci limiti di upload, richiesta o esecuzione attorno allo stato del workspace, ai download dei driver, alle sessioni concorrenti e alla latenza di rete verso ogni database.

Anche una distribuzione Dockup richiede un test di accettazione per CloudBeaver

La distribuzione CloudBeaver one-click di Dockup dovrebbe rendere sicura la sostituzione: il percorso continua a puntare alla porta 8978, i secrets non sono incorporati nell'immagine e i percorsi persistenti vengono ripristinati nel nuovo container. La stessa distribuzione può essere eseguita sul compute di Dockup o su una macchina collegata.

Completa le attività specifiche dell'app connettendoti e testando i percorsi privati e i driver del database per ogni database di destinazione, applicando l'indirizzo pubblico canonico ed eseguendo questa verifica di accettazione: completare la configurazione dell'amministratore, installare il driver necessario, connettersi tramite hostname privato ed eseguire una query di sola lettura. Aggiungi il risultato del ripristino al runbook prima dell'arrivo degli utenti reali.

Domande frequenti

Di cosa ha bisogno CloudBeaver per una distribuzione in produzione?

Instrada il container CloudBeaver sulla porta 8978 attraverso un'unica origine HTTPS. Il requisito di rete di supporto è costituito da percorsi privati e driver del database per ogni database di destinazione. Non considerare CloudBeaver pronto finché non puoi completare la configurazione dell'amministratore, installare il driver necessario, connetterti tramite hostname privato ed eseguire una query di sola lettura.

Quali dati di CloudBeaver devono essere inclusi in un backup?

Rendi persistente /opt/cloudbeaver/workspace e includi workspace, utenti, definizioni delle connessioni e storage delle credenziali nello stesso manifest di ripristino. Un ripristino pulito di CloudBeaver è riuscito solo quando workspace, utenti, driver e connessioni vengono ripristinati, mentre ogni database sottostante segue il proprio piano di backup.

CloudBeaver richiede HTTPS dietro un reverse proxy?

Usa HTTPS per l'origine pubblica di CloudBeaver e mantieni la porta 8978 sul percorso interno. Applica correttamente l'impostazione di CloudBeaver: imposta il server URL e gli header del proxy per l'origine HTTPS pubblica. Per CloudBeaver, HTTPS protegge le credenziali o i contenuti degli utenti durante il transito e mantiene coerente il comportamento dei client sensibile all'origine.

Come si deve testare un aggiornamento di CloudBeaver?

Ripristina lo stato corrente di CloudBeaver in una distribuzione isolata, applica la versione candidata e ripeti la relativa transazione di accettazione. Presta particolare attenzione a questo aspetto, perché le migrazioni del workspace di CloudBeaver e la compatibilità dei driver devono essere testate prima di cambiare versione dell'immagine. Mantieni l'immagine precedente di CloudBeaver finché non avrai compreso i confini della migrazione dei dati e del rollback.