Sådan self-hoster du CloudBeaver i 2026: Databasedrivere, workspace og adgang

Den korteste CloudBeaver-demo beviser, at en proces lytter på port 8978. Produktion kræver stærkere dokumentation. Den skal kunne gennemføre dette scenarie, også efter at containeren er blevet udskiftet: afslut administratoropsætningen, installér den nødvendige driver, opret forbindelse via et privat hostname, og kør en read-only query.

CloudBeaver deployes med et klart formål: som browserbaseret databaseklient til Postgres, MySQL og mere. Den mest almindelige deployment-fælde er, at workspace-tilladelser fejler, eller at container-DNS ikke kan resolve databaseværter. Derfor skal håndteringen af den offentlige URL og persistent state have samme opmærksomhed som opstart af imaget.

Gendan CloudBeaver på en tom host

Oplist state, før den første rigtige post oprettes: workspace, brugere, forbindelsesdefinitioner og storage til credentials. Mount /opt/cloudbeaver/workspace før bootstrap, skriv ufarlige eksempeldata, og udskift containeren for at bevise, at stien faktisk er persistent. Bekræft mountet ved at skrive ufarlige data, udskifte CloudBeaver og læse dem tilbage.

Snapshots er værdifulde til hurtig rollback, men der kræves en uafhængig backup, hvis hosten eller volumen forsvinder. Gendan i et tomt miljø med det pinnede image, og verificér, at workspace, brugere, drivere og forbindelser kommer tilbage, mens hver underliggende database følger sin egen backup-plan. Brug persistent volumes og snapshots for at holde de to recovery-mekanismer adskilt.

Start CloudBeaver med observerbare standardindstillinger

Følgende kommando synliggør containergrænsen uden at foregive, at alle eksterne services bliver provisioneret.

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 åbner for ingress, skal du inspicere det resolvede miljø, mounts og listeneren. Tilføj de godkendte connection settings for private routes og databasedrivere til hver target-database; brug private navne til private services. En vellykket opstart er først afsluttet, når du kan færdiggøre administratoropsætningen, installere den nødvendige driver, oprette forbindelse via et privat hostname og køre en read-only query – ikke når docker ps viser Up.

Hvad CloudBeaver afhænger af

CloudBeavers HTTP-proces lytter på 8978. Behold den port på application-netværket, og publicér kun platformens route. Netværkskontrakten for CloudBeaver er private routes og databasedrivere til hver target-database. Behold private endpoints på intern DNS, tillad kun nødvendige outbound-kald, og giv CloudBeaver en afgrænset service credential.

Skriv grænsen ned som en kort kontrakt: hvem ejer kravet, hvilken credential bruges, hvilken timeout er acceptabel, og hvordan viser en fejl sig. Kør derefter denne transaktion: færdiggør administratoropsætningen, installér den nødvendige driver, opret forbindelse via et privat hostname, og kør en read-only query. Observer workspace-state, driver-downloads, samtidige sessions og netværkslatens til hver database under kørslen, fordi den workload giver et mere nyttigt udgangspunkt for størrelsen end en inaktiv container.

Hold interne og eksterne URL’er adskilt

Den offentlige grænse for CloudBeaver bør være ét kanonisk hostname, automatisk TLS og ét internt target på 8978. Indstil server-URL’en og proxy headers til den offentlige HTTPS-origin, så clients vender tilbage til en adresse, som servicen genkender.

Hvis acceptance-transaktionen fejler, skal du klassificere den første fejl. DNS-, certifikat- og 502-problemer hører til i tjeklisten til TLS-validering. Betingelsen “workspace-tilladelser fejler, eller container-DNS kan ikke resolve databaseværter” hører til på applikationssiden, efter at en request er nået frem til CloudBeaver.

En production acceptance-kørsel for CloudBeaver

Brug ikke trafik fra den første bruger som acceptance-test for CloudBeaver. Forbered ufarlig eksempel-state, og kør den komplette handling: “færdiggør administratoropsætningen, installér den nødvendige driver, opret forbindelse via et privat hostname, og kør en read-only query”. Notér den nøjagtige offentlige URL, resultatet, image-referencen og det loginterval, der er knyttet til kørslen.

Udskift containeren, og gentag uden at rebuild’e data. Gendan derefter på en tom host. Recovery-betingelsen er, at workspace, brugere, drivere og forbindelser kommer tilbage, mens hver underliggende database følger sin egen backup-plan. Observer workspace-state, driver-downloads, samtidige sessions og netværkslatens til hver database ved hver gennemgang, og definér en alert omkring forringelse af transaktionen i stedet for omkring metrics for en inaktiv container.

Én sidste kontrol bør med vilje fejle: Afvis midlertidigt testidentitetens adgang til private routes og databasedrivere for hver target-database. Verificér, at den resulterende CloudBeaver-meddelelse identificerer den relevante grænse i stedet for at udløse datasletning eller en endeløs restart. Gendan den gyldige tilstand, og bekræft, at den samme eksempeltransaktion lykkes. Behold denne korte øvelse i release-checklisten.

Fejlsøg en CloudBeaver, der ser sund ud

Den første nyttige operationelle metric for CloudBeaver er, om den kan færdiggøre administratoropsætningen, installere den nødvendige driver, oprette forbindelse via et privat hostname og køre en read-only query. Kombinér den med saturation-signaler for workspace-state, driver-downloads, samtidige sessions og netværkslatens til hver database. En probe, der kun kontrollerer processen, bør ikke kalde dyre dependencies eller restarte containeren, fordi en upstream kortvarigt er utilgængelig.

Betragt upgrades som dataændringer, fordi CloudBeaver-workspace-migreringer og driverkompatibilitet bør testes, før image-versioner ændres. Pin versioner, øv dig på restored state, og behold det tidligere image tilgængeligt, indtil en rollback fortsat er gyldig. Når workspace-tilladelser fejler, eller container-DNS ikke kan resolve databaseværter, skal du gemme logs fra før restarten. De indeholder som regel den udløsende fejlmeddelelse.

Sikkerhedsbeslutninger, der er specifikke for CloudBeaver

Overtag ikke sikkerhedsantagelser fra en lokal tutorial. CloudBeavers specifikke problem er at tillade anonym adgang til production-databaseforbindelser. Production bør derfor deaktivere anonym administration, bruge individuelle brugere og kun give databasekonti de tilladelser, som hver forbindelse har brug for.

CB_SERVER_NAME styrer adfærd, ikke fortrolighed. Validér derfor typen og værdien, og opbevar ægte CloudBeaver-credentials separat. Afgræns filesystem- og netværksadgang, beskyt setup-endpoints, og definér grænser for upload, requests eller execution omkring workspace-state, driver-downloads, samtidige sessions og netværkslatens til hver database.

En Dockup-deployment kræver stadig en acceptance-test af CloudBeaver

Dockups one-click CloudBeaver-deployment bør gøre udskiftning sikker: Routen fortsætter med at pege på 8978, secrets er ikke baked ind i imaget, og persistente stier kommer tilbage i den nye container. Den samme deployment kan køre på Dockup compute eller på en tilknyttet maskine.

Færdiggør det appspecifikke arbejde ved at oprette forbindelse og teste private routes og databasedrivere for hver target-database, anvende den kanoniske offentlige adresse og køre denne acceptance-kontrol: færdiggør administratoropsætningen, installér den nødvendige driver, opret forbindelse via et privat hostname, og kør en read-only query. Tilføj resultatet af restore til runbooken, før de rigtige brugere ankommer.

Ofte stillede spørgsmål

Hvad kræver CloudBeaver til en production-deployment?

Route CloudBeaver-containeren på port 8978 gennem én HTTPS-origin. Det understøttende netværkskrav er private routes og databasedrivere til hver target-database. Erklær ikke CloudBeaver klar, før du kan færdiggøre administratoropsætningen, installere den nødvendige driver, oprette forbindelse via et privat hostname og køre en read-only query.

Hvilke CloudBeaver-data skal med i en backup?

Persistér /opt/cloudbeaver/workspace, og inkludér workspace, brugere, forbindelsesdefinitioner og credentials storage i det samme recovery-manifest. En ren CloudBeaver-restore er kun vellykket, når workspace, brugere, drivere og forbindelser kommer tilbage, mens hver underliggende database følger sin egen backup-plan.

Kræver CloudBeaver HTTPS bag en reverse proxy?

Brug HTTPS til den offentlige CloudBeaver-origin, og behold port 8978 på den interne route. Anvend CloudBeaver-indstillingen korrekt: Indstil server-URL’en og proxy headers til den offentlige HTTPS-origin. For CloudBeaver beskytter HTTPS credentials eller brugerindhold under transport og sikrer ensartet client-adfærd, der afhænger af origin.

Hvordan bør en CloudBeaver-upgrade testes?

Gendan den aktuelle CloudBeaver-state i en isoleret deployment, anvend kandidatversionen, og gentag dens acceptance-transaktion. Vær særligt opmærksom, fordi CloudBeaver-workspace-migreringer og driverkompatibilitet bør testes, før image-versioner ændres. Behold det tidligere CloudBeaver-image, indtil dets grænser for data-migrering og rollback er forstået.