Jak samodzielnie hostować CloudBeaver w 2026 roku: drivery baz danych, workspace i dostęp
Samodzielnie hostuj CloudBeaver z poprawnymi portami, trwałym storage, HTTPS, sekretami, backupami i kontrolą upgrade’ów. Dowiedz się, jak naprawić problem z uprawnieniami workspace.
Najkrótsze demo CloudBeaver potwierdza, że proces nasłuchuje na porcie 8978. Środowisko produkcyjne wymaga mocniejszych dowodów. Musi przejść ten scenariusz nawet po wymianie kontenera: zakończyć konfigurację administratora, zainstalować wymagany driver, połączyć się przez prywatny hostname i wykonać zapytanie tylko do odczytu.
CloudBeaver jest wdrażany w konkretnym celu: jako przeglądarkowy klient baz danych dla Postgres, MySQL i innych baz. Najczęstsza pułapka wdrożeniowa polega na tym, że uprawnienia workspace nie działają albo DNS kontenera nie może rozwiązać hostów baz danych. Dlatego obsługa publicznego URL-a i trwałość stanu wymagają takiej samej uwagi jak uruchomienie obrazu.
Odtwórz CloudBeaver na pustym hoście
Zanim utworzysz pierwszy rzeczywisty rekord, wypisz elementy stanu: workspace, użytkowników, definicje połączeń i storage danych uwierzytelniających. Zamontuj /opt/cloudbeaver/workspace przed bootstrapem, zapisz nieszkodliwe dane testowe i wymień kontener, aby potwierdzić, że ta ścieżka jest rzeczywiście trwała. Potwierdź montowanie, zapisując nieszkodliwe dane, wymieniając CloudBeaver i odczytując je ponownie.
Snapshoty są przydatne do szybkiego rollbacku, ale potrzebny jest niezależny backup na wypadek utraty hosta lub wolumenu. Odtwórz środowisko w pustym środowisku z przypiętym obrazem i sprawdź, czy workspace, użytkownicy, drivery i połączenia wracają, podczas gdy każda bazowa baza danych korzysta z własnego planu backupu. Użyj trwałych wolumenów i snapshotów, aby zachować rozdzielenie tych dwóch mechanizmów odtwarzania.
Uruchom CloudBeaver z domyślnymi ustawieniami zapewniającymi obserwowalność
Poniższe polecenie uwidacznia granicę kontenera bez udawania, że konfiguruje każdą zewnętrzną usługę.
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
Zanim otworzysz ingress, sprawdź rozwiązaną konfigurację środowiska, mounty i listener. Dodaj zweryfikowane ustawienia połączeń dla prywatnych tras oraz drivery baz danych dla każdej docelowej bazy; dla prywatnych usług używaj prywatnych nazw. Pomyślne uruchomienie kończy się dopiero wtedy, gdy możesz zakończyć konfigurację administratora, zainstalować wymagany driver, połączyć się przez prywatny hostname i wykonać zapytanie tylko do odczytu — a nie wtedy, gdy docker ps wyświetla Up.
Od czego zależy CloudBeaver
Proces HTTP CloudBeaver nasłuchuje na porcie 8978; pozostaw ten port w sieci aplikacji i publikuj wyłącznie trasę platformy. Kontrakt sieciowy CloudBeaver obejmuje prywatne trasy i drivery baz danych dla każdej docelowej bazy. Prywatne endpointy trzymaj w wewnętrznym DNS, zezwalaj tylko na wymagane połączenia wychodzące i przydziel CloudBeaver ograniczone uprawnieniami dane uwierzytelniające usługi.
Zapisz granicę w formie krótkiego kontraktu: kto odpowiada za wymaganie, jakie dane uwierzytelniające są używane, jaki timeout jest akceptowalny i jak objawia się awaria. Następnie uruchom tę transakcję: zakończ konfigurację administratora, zainstaluj wymagany driver, połącz się przez prywatny hostname i wykonaj zapytanie tylko do odczytu. Podczas uruchomienia obserwuj stan workspace, pobieranie driverów, liczbę równoczesnych sesji i opóźnienie sieciowe do każdej bazy, ponieważ takie obciążenie daje lepszy punkt wyjścia do określenia rozmiaru niż bezczynny kontener.
Rozdziel adresy wewnętrzne i zewnętrzne
Publiczna granica CloudBeaver powinna obejmować jeden kanoniczny hostname, automatyczny TLS i jeden wewnętrzny cel na porcie 8978. Ustaw URL serwera i nagłówki proxy dla publicznego źródła HTTPS, aby klienci wracali pod adres rozpoznawany przez usługę.
Jeśli transakcja akceptacyjna zakończy się niepowodzeniem, sklasyfikuj pierwszy błąd. Problemy z DNS, certyfikatem i 502 należą do checklisty weryfikacji TLS. Warunek „uprawnienia workspace nie działają albo DNS kontenera nie może rozwiązać hostów baz danych” należy do warstwy aplikacji, gdy żądanie poprawnie dotarło już do CloudBeaver.
Produkcyjny test akceptacyjny dla CloudBeaver
Nie używaj ruchu pierwszego użytkownika jako testu akceptacyjnego CloudBeaver. Przygotuj nieszkodliwy stan testowy i uruchom pełną czynność: „zakończ konfigurację administratora, zainstaluj wymagany driver, połącz się przez prywatny hostname i wykonaj zapytanie tylko do odczytu”. Zanotuj dokładny publiczny URL, wynik, referencję obrazu i przedział logów powiązany z uruchomieniem.
Wymień kontener i powtórz test bez przebudowywania danych. Następnie odtwórz środowisko na pustym hoście; warunkiem odtworzenia jest powrót workspace, użytkowników, driverów i połączeń, podczas gdy każda bazowa baza danych korzysta z własnego planu backupu. Przy każdym podejściu obserwuj stan workspace, pobieranie driverów, liczbę równoczesnych sesji i opóźnienie sieciowe do każdej bazy. Zdefiniuj alert dotyczący pogorszenia transakcji, a nie metryk bezczynnego kontenera.
Jeden końcowy test powinien celowo zakończyć się niepowodzeniem: tymczasowo odbierz tożsamości testowej dostęp do prywatnych tras i driverów baz danych dla każdej docelowej bazy. Sprawdź, czy wynikający z tego komunikat CloudBeaver wskazuje odpowiednią granicę, zamiast uruchamiać usuwanie danych lub niekończący się restart. Przywróć prawidłowy stan i potwierdź, że ta sama transakcja testowa kończy się powodzeniem. Zachowaj to krótkie ćwiczenie na checkliście wydania.
Diagnozowanie CloudBeaver, który wygląda na zdrowy
Pierwszą użyteczną metryką operacyjną dla CloudBeaver jest to, czy może zakończyć konfigurację administratora, zainstalować wymagany driver, połączyć się przez prywatny hostname i wykonać zapytanie tylko do odczytu. Połącz ją z sygnałami nasycenia dotyczącymi stanu workspace, pobierania driverów, liczby równoczesnych sesji i opóźnienia sieciowego do każdej bazy. Probe sprawdzający wyłącznie proces nie powinien wywoływać kosztownych zależności ani restartować kontenera tylko dlatego, że upstream jest chwilowo niedostępny.
Traktuj upgrade’y jak zmiany danych, ponieważ migracje workspace CloudBeaver i kompatybilność driverów powinny zostać przetestowane przed zmianą wersji obrazu. Przypinaj wersje, ćwicz procedurę na odtworzonym stanie i zachowaj poprzedni obraz do czasu, aż rollback nadal będzie możliwy. Gdy uprawnienia workspace nie działają albo DNS kontenera nie może rozwiązać hostów baz danych, zachowaj logi sprzed restartu; zwykle zawierają komunikat wskazujący przyczynę.
Decyzje dotyczące bezpieczeństwa specyficzne dla CloudBeaver
Nie dziedzicz założeń bezpieczeństwa z lokalnego tutoriala. Specyficznym zagrożeniem CloudBeaver jest dopuszczenie anonimowego dostępu do produkcyjnych połączeń z bazami danych. Dlatego środowisko produkcyjne powinno wyłączać anonimową administrację, używać indywidualnych użytkowników i przyznawać kontom baz danych wyłącznie uprawnienia wymagane przez dane połączenie.
CB_SERVER_NAME steruje zachowaniem, a nie poufnością; sprawdź jego typ i wartość, a prawdziwe dane uwierzytelniające CloudBeaver przechowuj osobno. Ogranicz dostęp do systemu plików i sieci, chroń endpointy konfiguracji i zdefiniuj limity uploadu, żądań lub wykonywania operacji wokół stanu workspace, pobierania driverów, liczby równoczesnych sesji i opóźnienia sieciowego do każdej bazy.
Wdrożenie w Dockup nadal wymaga testu akceptacyjnego CloudBeaver
Jednoprzyciskowe wdrożenie CloudBeaver w Dockup powinno zapewniać bezpieczną wymianę: trasa nadal kieruje na port 8978, sekrety nie są wbudowane w obraz, a trwałe ścieżki wracają w nowym kontenerze. To samo wdrożenie może działać na infrastrukturze obliczeniowej Dockup lub na dołączonej maszynie.
Wykonaj prace specyficzne dla aplikacji, łącząc się i testując prywatne trasy oraz drivery baz danych dla każdej docelowej bazy, ustawiając kanoniczny adres publiczny i uruchamiając ten test akceptacyjny: zakończ konfigurację administratora, zainstaluj wymagany driver, połącz się przez prywatny hostname i wykonaj zapytanie tylko do odczytu. Dodaj wynik odtwarzania do runbooka, zanim pojawią się prawdziwi użytkownicy.
Najczęściej zadawane pytania
Czego CloudBeaver potrzebuje w środowisku produkcyjnym?
Skieruj kontener CloudBeaver na porcie 8978 przez jeden origin HTTPS. Wymaganie sieciowe obejmuje prywatne trasy i drivery baz danych dla każdej docelowej bazy. Nie uznawaj CloudBeaver za gotowy, dopóki nie możesz zakończyć konfiguracji administratora, zainstalować wymaganego drivera, połączyć się przez prywatny hostname i wykonać zapytania tylko do odczytu.
Które dane CloudBeaver powinny znaleźć się w backupie?
Utrwal /opt/cloudbeaver/workspace i uwzględnij workspace, użytkowników, definicje połączeń oraz storage danych uwierzytelniających w tym samym manifeście odtwarzania. Czyste odtworzenie CloudBeaver kończy się powodzeniem tylko wtedy, gdy wracają workspace, użytkownicy, drivery i połączenia, podczas gdy każda bazowa baza danych korzysta z własnego planu backupu.
Czy CloudBeaver wymaga HTTPS za reverse proxy?
Używaj HTTPS dla publicznego originu CloudBeaver i pozostaw port 8978 na trasie wewnętrznej. Poprawnie zastosuj ustawienia CloudBeaver: ustaw URL serwera i nagłówki proxy dla publicznego originu HTTPS. W przypadku CloudBeaver HTTPS chroni dane uwierzytelniające lub treści użytkowników podczas transmisji i zapewnia spójność zachowania klientów zależnego od originu.
Jak testować upgrade CloudBeaver?
Odtwórz bieżący stan CloudBeaver w odizolowanym wdrożeniu, zastosuj wersję kandydującą i powtórz jego transakcję akceptacyjną. Zwróć szczególną uwagę na to, że migracje workspace CloudBeaver i kompatybilność driverów powinny zostać przetestowane przed zmianą wersji obrazu. Zachowaj poprzedni obraz CloudBeaver do czasu zrozumienia granic migracji danych i rollbacku.