Slik drifter du CloudBeaver selv i 2026: database-drivere, workspace og tilgang

Den korteste CloudBeaver-demoen beviser at en prosess lytter på port 8978. I produksjon trengs det sterkere bevis. Den må bestå dette scenarioet selv etter at containeren er erstattet: fullfør administratoroppsettet, installer den nødvendige driveren, koble til via et privat hostname og kjør en skrivebeskyttet spørring.

CloudBeaver distribueres med et tydelig formål: en databaseklient i nettleseren for Postgres, MySQL og mer. Den vanligste fellen ved distribusjon er at workspace-tillatelser feiler eller at containerens DNS ikke klarer å slå opp databaseverter. Derfor må håndtering av offentlige URL-er og varig state få like mye oppmerksomhet som oppstart av imaget.

Gjenopprett CloudBeaver på en tom host

Kartlegg state før den første reelle posten opprettes: workspace, brukere, tilkoblingsdefinisjoner og lagring av credentials. Mount /opt/cloudbeaver/workspace før bootstrap, skriv ufarlige eksempeldata og erstatt containeren for å bevise at banen faktisk er persistent. Bekreft mountet ved å skrive ufarlige data, erstatte CloudBeaver og lese dataene tilbake.

Snapshots er nyttige for rask rollback, men du trenger en uavhengig backup når hosten eller volumet forsvinner. Gjenopprett til et tomt miljø med det pinnede imaget, og bekreft at workspace, brukere, drivere og tilkoblinger kommer tilbake, mens hver underliggende database følger sin egen backup-plan. Bruk persistent volumes og snapshots for å holde disse to gjenopprettingsmekanismene adskilt.

Start CloudBeaver med observerbare standardverdier

Følgende kommando synliggjør containergrensen uten å late som om den provisionerer alle eksterne tjenester.

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

Før du åpner ingress, bør du kontrollere det evaluerte miljøet, mountene og lytteren. Legg til de gjennomgåtte tilkoblingsinnstillingene for private ruter og database-drivere for hver måldatabase; bruk private navn for private tjenester. En vellykket oppstart er først fullført når du kan fullføre administratoroppsettet, installere den nødvendige driveren, koble til via et privat hostname og kjøre en skrivebeskyttet spørring – ikke når docker ps skriver ut Up.

Hva CloudBeaver er avhengig av

CloudBeaver HTTP-prosessen lytter på 8978. Behold denne porten på applikasjonsnettverket, og publiser bare plattformruten. Nettverkskontrakten for CloudBeaver er private ruter og database-drivere for hver måldatabase. Hold private endepunkter på intern DNS, tillat bare nødvendige utgående kall og gi CloudBeaver en avgrenset service credential.

Skriv ned grensen som en kort kontrakt: hvem som eier kravet, hvilken credential som brukes, hvilken timeout som er akseptabel og hvordan en feil vises. Kjør deretter denne transaksjonen: fullfør administratoroppsettet, installer den nødvendige driveren, koble til via et privat hostname og kjør en skrivebeskyttet spørring. Overvåk workspace-state, driver-nedlastinger, samtidige sesjoner og nettverkslatens til hver database under kjøringen, fordi denne arbeidsbelastningen gir et mer nyttig utgangspunkt for dimensjonering enn en inaktiv container.

Hold interne og eksterne URL-er adskilt

Den offentlige grensen for CloudBeaver bør være ett kanonisk hostname, automatisk TLS og ett internt mål på 8978. Angi server-URL-en og proxy-headerne for den offentlige HTTPS-opprinnelsen, slik at klienter returnerer til en adresse tjenesten kjenner igjen.

Hvis akseptansetransaksjonen feiler, må du klassifisere den første feilen. DNS-, sertifikat- og 502-problemer hører hjemme i sjekklisten for TLS-validering. Tilstanden «workspace-tillatelser feiler eller containerens DNS ikke klarer å slå opp databaseverter» hører hjemme på applikasjonssiden etter at en request har nådd CloudBeaver.

En akseptansekjøring for CloudBeaver i produksjon

Ikke bruk trafikk fra den første brukeren som akseptansetest for CloudBeaver. Forbered ufarlig eksempel-state og kjør hele handlingen «fullfør administratoroppsettet, installer den nødvendige driveren, koble til via et privat hostname og kjør en skrivebeskyttet spørring». Noter den nøyaktige offentlige URL-en, resultatet, imagereferansen og loggintervallet som er knyttet til kjøringen.

Erstatt containeren og gjenta uten å bygge dataene på nytt. Gjenopprett deretter til en tom host. Gjenopprettingskravet er at workspace, brukere, drivere og tilkoblinger kommer tilbake, mens hver underliggende database følger sin egen backup-plan. Overvåk workspace-state, driver-nedlastinger, samtidige sesjoner og nettverkslatens til hver database i hver gjennomgang, og definer et alert rundt svekkelse av transaksjonen i stedet for rundt målinger av en inaktiv container.

Én siste kontroll bør feile med vilje: nekt testidentiteten midlertidig tilgang til private ruter og database-drivere for hver måldatabase. Bekreft at CloudBeaver-meldingen som oppstår identifiserer den relevante grensen, i stedet for å utløse sletting av data eller en endeløs restart. Gjenopprett den gyldige tilstanden og bekreft at den samme eksempeltransaksjonen lykkes. Ta med denne korte øvelsen i release-sjekklisten.

Feilsøk en CloudBeaver som ser frisk ut

Den første nyttige driftsmålingen for CloudBeaver er om den kan fullføre administratoroppsettet, installere den nødvendige driveren, koble til via et privat hostname og kjøre en skrivebeskyttet spørring. Kombiner dette med metning-signaler for workspace-state, driver-nedlastinger, samtidige sesjoner og nettverkslatens til hver database. En probe som bare kontrollerer prosessen, bør ikke kalle kostbare avhengigheter eller restarte containeren fordi en upstream-tjeneste midlertidig er utilgjengelig.

Betrakt oppgraderinger som dataendringer, fordi CloudBeaver workspace-migreringer og driverkompatibilitet bør testes før du endrer image-versjoner. Pin versjoner, øv på gjenopprettet state og behold det forrige imaget tilgjengelig til rollback fortsatt er gyldig. Når workspace-tillatelser feiler eller containerens DNS ikke klarer å slå opp databaseverter, må du ta vare på logger fra før restarten. De inneholder vanligvis den utløsende feilmeldingen.

Sikkerhetsvalg som gjelder spesifikt for CloudBeaver

Ikke ta sikkerhetsforutsetninger fra en lokal tutorial. CloudBeavers spesifikke bekymring er å tillate anonym tilgang til database-tilkoblinger i produksjon. I produksjon bør du derfor deaktivere anonym administrasjon, bruke individuelle brukere og bare gi databasekontoene tillatelsene hver tilkobling trenger.

CB_SERVER_NAME styrer atferd, ikke konfidensialitet. Valider typen og verdien, og lagre faktiske CloudBeaver-credentials separat. Begrens filsystem- og nettverkstilgang, beskytt setup-endepunkter og definer grenser for opplasting, requests eller kjøring rundt workspace-state, driver-nedlastinger, samtidige sesjoner og nettverkslatens til hver database.

En Dockup-distribusjon trenger fortsatt en akseptansetest for CloudBeaver

Dockups ettklikksdistribusjon av CloudBeaver bør gjøre det trygt å erstatte en container: ruten fortsetter å peke mot 8978, secrets bygges ikke inn i imaget, og persistente baner kommer tilbake i den nye containeren. Den samme distribusjonen kan kjøres på Dockup compute eller en tilkoblet maskin.

Fullfør det applikasjonsspesifikke arbeidet ved å koble til og teste private ruter og database-drivere for hver måldatabase, bruke den kanoniske offentlige adressen og kjøre denne akseptansekontrollen: fullfør administratoroppsettet, installer den nødvendige driveren, koble til via et privat hostname og kjør en skrivebeskyttet spørring. Legg til gjenopprettingsresultatet i runbooken før de reelle brukerne kommer.

Vanlige spørsmål

Hva trenger CloudBeaver for en produksjonsdistribusjon?

Rout CloudBeaver-containeren på port 8978 gjennom én HTTPS-opprinnelse. Det støttende nettverkskravet er private ruter og database-drivere for hver måldatabase. Ikke betrakt CloudBeaver som klar før du kan fullføre administratoroppsettet, installere den nødvendige driveren, koble til via et privat hostname og kjøre en skrivebeskyttet spørring.

Hvilke CloudBeaver-data hører hjemme i en backup?

Gjør /opt/cloudbeaver/workspace persistent, og inkluder workspace, brukere, tilkoblingsdefinisjoner og lagring av credentials i det samme gjenopprettingsmanifestet. En ren CloudBeaver-gjenoppretting er først vellykket når workspace, brukere, drivere og tilkoblinger kommer tilbake, mens hver underliggende database følger sin egen backup-plan.

Krever CloudBeaver HTTPS bak en reverse proxy?

Bruk HTTPS for den offentlige CloudBeaver-opprinnelsen, og behold port 8978 på den interne ruten. Konfigurer CloudBeaver-innstillingen riktig: angi server-URL-en og proxy-headerne for den offentlige HTTPS-opprinnelsen. For CloudBeaver beskytter HTTPS credentials eller brukerinnhold under overføring og sørger for at klientatferd som er avhengig av opprinnelsen, forblir konsistent.

Hvordan bør en CloudBeaver-oppgradering testes?

Gjenopprett gjeldende CloudBeaver-state til en isolert distribusjon, bruk kandidatversjonen og gjenta akseptansetransaksjonen. Vær spesielt oppmerksom på dette, fordi CloudBeaver workspace-migreringer og driverkompatibilitet bør testes før image-versjoner endres. Behold det forrige CloudBeaver-imaget til grensen for datamigrering og rollback er forstått.