Zarządzany PostgreSQL w Dockup: kompletny przewodnik

Zarządzany PostgreSQL udostępnia aplikacji przygotowaną bazę danych, której operacje związane z cyklem życia są niezależne od kontenera usługi. Dockup obsługuje tworzenie, uruchamianie i zatrzymywanie, logi, sprawdzanie rozmiaru, kopie zapasowe, przywracanie za pośrednictwem platformy, użytkowników tylko do odczytu, migrację między węzłami oraz prywatną sieć.

Najważniejsza zasada operacyjna to rozdzielenie odpowiedzialności: obraz aplikacji jest nietrwały, dane PostgreSQL są trwałe, dane uwierzytelniające są sekretami, a odzyskiwanie bazy danych trzeba testować niezależnie od wycofywania wersji aplikacji.

Jak utworzyć zarządzaną bazę PostgreSQL?

Wybierz odpowiedni workspace, a następnie utwórz bazę danych:

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

Wyświetl listę baz danych, aby potwierdzić dokładny slug i status:

dockup db list --json

Operacje na bazach danych używają celów w formacie project/db:

dockup db size production/main-db --json

Przed podłączeniem aplikacji poczekaj na zakończenie provisioningu. Nie zgaduj hosta, portu, nazwy użytkownika ani hasła na podstawie nazwy bazy danych.

Plan Free pozwala na trzy bazy danych w jednym workspace i obejmuje kredyt początkowy w wysokości 10 USD. Płatne plany — Hobby za 5 USD, Pro za 20 USD miesięcznie — pozwalają na nieograniczoną liczbę baz danych, workspace’ów i deploymentów. Zużycie CPU, RAM-u i miejsca na dysku jest mierzone co minutę i pomniejsza dostępny pakiet użycia.

Jak bezpiecznie połączyć aplikację?

Pobierz dane połączenia z bazą danych z interfejsu Dockup i traktuj connection string jak sekret. Nie wklejaj go do repozytorium ani do transkryptu agenta.

Ustaw go w usłudze:

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

dockup deploy production/api --wait --json

Ponowne wdrożenie jest wymagane, ponieważ uruchomiony proces otrzymał swoje zmienne środowiskowe podczas startu. Zapisana wartość jest maskowana podczas odczytu konfiguracji środowiska.

Świadomie skonfiguruj connection pooling w aplikacji. Zbyt wielu workerów aplikacji z dużymi pulami może wyczerpać limity połączeń z bazą danych, nawet jeśli użycie CPU i pamięci wygląda prawidłowo. Ustal rozmiar puli na podstawie obciążenia i możliwości bazy danych, a nie maksymalnej liczby akceptowanej przez framework.

Po wdrożeniu przetestuj nowe połączenie. Endpoint health może potwierdzić, że proces HTTP działa, ale nie dowodzi, że można ustanowić nową sesję z bazą danych.

Przewodnik zmienne środowiskowe i sekrety omawia rotację danych uwierzytelniających i maskowane dane wyjściowe.

Jak prywatna sieć chroni ruch PostgreSQL?

Włącz prywatną sieć projektu:

dockup network enable production --json

Usługi i zarządzane bazy danych w tym projekcie otrzymują stabilne hosty w formacie <slug>.internal. Wdróż aplikację ponownie, aby otrzymała wstrzyknięte wewnętrzne zmienne połączenia.

Aby usunąć publiczny listener bazy danych i pozostawić wyłącznie dostęp prywatny:

dockup db private production/main-db --json

W razie potrzeby przywróć dostęp publiczny i prywatny:

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

Ustawienie bazy danych jako dostępnej wyłącznie prywatnie powoduje ponowne utworzenie jej kontenera przy zachowaniu danych. Zaplanuj i zweryfikuj tę zmianę jako operację na bazie danych, a nie niegroźną edycję DNS.

Prywatna sieć kontroluje trasę, natomiast dane uwierzytelniające PostgreSQL kontrolują tożsamość i uprawnienia. Potrzebujesz obu mechanizmów. Oddzielne projekty nie mogą komunikować się ze sobą, ponieważ każdy projekt ma własną sieć.

Artykuł prywatna sieć i domeny wewnętrzne przedstawia pełną topologię.

Jak działają kopie zapasowe i przywracanie PostgreSQL?

Wyświetl istniejące kopie zapasowe:

dockup db backups production/main-db --json

Uruchom kopię zapasową po stronie serwera:

dockup db backup production/main-db --json

Polecenie tworzy kopię zapasową uwzględniającą strukturę bazy danych, a nie kopię surowego wolumenu wykonaną podczas pracy systemu. Zapisz identyfikator kopii, czas utworzenia, wersję bazy danych i powód jej utworzenia.

Dockup obsługuje przywracanie kopii zarządzanych baz danych za pośrednictwem platformy. Aktualna dokumentacja CLI nie opisuje polecenia dockup db restore, dlatego ten przewodnik go nie wymyśla. Wykonaj przywracanie z obsługiwanego interfejsu Dockup, wybierz dokładną kopię, uzyskaj zgodę osoby odpowiedzialnej za produkcję i zweryfikuj wynik.

Plan przywracania powinien obejmować:

1. Punkt odzyskiwania i przewidywane okno utraty zapisów.
2. Wstrzymanie zapisów przez aplikację lub sposób obsługi trybu maintenance.
3. Zgodność bazy danych i rozszerzeń.
4. Nową kopię bieżącego stanu, jeśli jest przydatna.
5. Osobę odpowiedzialną za przywracanie i zatwierdzenie operacji.
6. Ponowne połączenie aplikacji i smoke test.
7. Rejestr audytowy i rejestr incydentu.

Kopie zapasowe nie są sprawdzone, dopóki ćwiczenie przywracania nie zakończy się powodzeniem. Testuj procedurę na bazie nieprodukcyjnej lub zatwierdzonym środowisku odzyskiwania.

Przechowuj kopie zgodnie z zatwierdzoną polityką. Usuwaj nieaktualne punkty odzyskiwania wyłącznie za pośrednictwem obsługiwanego interfejsu bazy danych, po potwierdzeniu, że żadne wymaganie dotyczące odzyskiwania ani zgodności nie jest już od nich zależne.

Jak działają użytkownicy PostgreSQL tylko do odczytu?

Dodatkowi użytkownicy tylko do odczytu są przydatni w analityce, podczas analizy problemów przez support, w preview deployments oraz w narzędziach, które muszą wykonywać zapytania bez zapisu.

Wyświetl użytkowników:

dockup db users production/main-db --json

Utwórz użytkownika z etykietą:

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

Podczas tworzenia bezpiecznie zapisz wygenerowane dane uwierzytelniające i nie umieszczaj ich w odpowiedzi agenta. Gdy dodatkowy użytkownik nie jest już potrzebny, odbierz mu dostęp za pośrednictwem obsługiwanego interfejsu zarządzania użytkownikami bazy danych.

Uprawnienia tylko do odczytu na poziomie bazy danych są skuteczniejszym zabezpieczeniem niż poinstruowanie narzędzia do wykonywania zapytań, aby „nie zapisywało”. Nadal umożliwiają dostęp do możliwych do odczytu danych produkcyjnych, dlatego obowiązują zasady prywatności i najmniejszych uprawnień.

Dockup automatycznie tworzy użytkownika bazy danych tylko do odczytu dla preview PR-a lub brancha w projekcie z prywatną siecią. Preview może łączyć się z tą samą produkcyjną bazą danych pod adresem <slug>.internal i odczytywać dane bez uprawnień do zapisu.

Jak monitorować rozmiar, logi i rozmieszczenie?

Sprawdź rozmiar na dysku:

dockup db size production/main-db --json

Przejrzyj logi aplikacji z runtime pod kątem błędów połączenia, nie ujawniając haseł ani pełnych connection stringów:

dockup logs production/api --json

Konserwacja bazy danych może spowodować niedostępność zależnych usług. Planuj operacje zmieniające stan, wymagaj wyraźnej zgody operacyjnej i przed działaniem komunikuj jego wpływ.

Przenieś bazę danych między węzłami, podając identyfikator docelowego węzła:

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

Migracja jest operacją na danych trwałych. Potwierdź status kopii zapasowych, oczekiwania dotyczące maintenance, połączenia przez prywatną sieć oraz kontrole aplikacji po przeniesieniu.

Lista kontrolna zarządzanego PostgreSQL na produkcji

Kompletny runbook powinien zawierać:

Obszar	Wymagane potwierdzenie
Tożsamość	Dokładny cel project/db
Łączność	Sekretny connection string i przetestowana nowa sesja
Sieć	Polityka dostępu publicznego, prywatnego lub wyłącznie prywatnego
Dostęp	Rola aplikacji i użytkownicy tylko do odczytu z etykietami
Pojemność	Bieżący rozmiar i analiza wzrostu
Kopie zapasowe	Ostatnie identyfikatory kopii i retencja
Odzyskiwanie	Pomyślnie przeprowadzone ćwiczenie przywracania
Operacje	Zatwierdzenie uruchamiania, zatrzymywania, restartu i migracji
Audyt	Zmiany w bazie danych możliwe do przypisania konkretnej osobie lub usłudze

Wycofanie wdrożenia aplikacji nie przywraca PostgreSQL. Przywrócenie bazy danych nie wycofuje automatycznie kodu aplikacji. Koordynuj obie operacje tylko wtedy, gdy wymaga tego zgodność schematu.

Aby poznać szersze podejście do skalowania, przeczytaj strategie skalowania baz danych. Dokładne polecenia znajdziesz w dokumentacji Dockup CLI.

Projektuj migracje schematu z myślą o wdrażaniu i wycofywaniu zmian

Wdrożenie aplikacji i zmiana schematu bazy danych odbywają się w różnym tempie. Bezpieczna migracja jest zwykle wstecznie kompatybilna przez co najmniej jedno okno wydania: najpierw dodaj nullable column, następnie wdróż kod obsługujący oba schematy, wykonaj backfill w kontrolowany sposób, a starą strukturę usuń później.

Nie uruchamiaj długiej migracji w ramach health checka. Jeśli aplikacja uruchamia kilka replik, zapewnij, że zmianę może wykonywać tylko jeden migration runner. Polecenie PRO exec dla kontenera może uruchomić jednorazowe polecenie i przekazać jego rzeczywisty exit code:

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

Używaj go tylko wtedy, gdy polecenie migracji zostało sprawdzone, a usługa działa na obsługiwanym serwerze głównym. Zapisuj stdout, stderr i exit code. Pomyślne wdrożenie aplikacji nie oznacza, że można zignorować nieudaną migrację.

Rotuj dane uwierzytelniające bazy danych bez przestoju

Utwórz nowe dane uwierzytelniające lub użytkownika tylko do odczytu, zaktualizuj sekret usługi korzystającej z tych danych, wdróż ją ponownie i potwierdź nowe połączenie przed odebraniem dostępu staremu użytkownikowi. Istniejące pule połączeń mogą ukryć nieprawidłowe nowe hasło do czasu ponownego nawiązania połączenia.

W przypadku głównych danych uwierzytelniających aplikacji korzystaj z obsługiwanego interfejsu Dockup i polityki bazy danych. W przypadku dodatkowego użytkownika analitycznego utwórz oznaczone konto tylko do odczytu i udostępnij je wyłącznie zatwierdzonemu odbiorcy.

Rejestr rotacji powinien zawierać etykietę użytkownika, korzystające z niego usługi, identyfikatory wdrożeń, zapytanie weryfikacyjne, czas odebrania dostępu i zdarzenie audytowe — nigdy hasło.

Obserwuj wzrost przed skalowaniem

Rozmiar bazy danych jest jednym z sygnałów:

dockup db size production/main-db --json

Połącz go z czasem odpowiedzi zapytań aplikacji, liczbą połączeń, zachowaniem cache, czasem tworzenia kopii zapasowej i wzrostem zajętości miejsca. Większa alokacja CPU lub pamięci może nie rozwiązać problemu brakujących indeksów ani nieograniczonych zapytań.

Przed przeniesieniem węzłów lub zwiększeniem zasobów zapoznaj się ze strategiami skalowania baz danych. Zarządzany PostgreSQL ogranicza nakład pracy związany z provisioningiem, ale projektowanie schematu i zapytań nadal pozostaje odpowiedzialnością aplikacji.

Oddziel dostępność od poprawności

Działający kontener bazy danych dowodzi, że PostgreSQL jest dostępny, ale nie tego, że zapytania aplikacji są poprawne. Weryfikacja po wdrożeniu powinna obejmować bezpieczne nowe połączenie i reprezentatywny odczyt. W przypadku testu zapisu użyj dedykowanej transakcji lub rekordu testowego, który można bezpiecznie usunąć.

Runbook zarządzanego PostgreSQL powinien również określać, czy repliki, użytkownicy analityczni, preview deployments lub background workers powodują dodatkowe obciążenie połączeń.

Regularnie przeglądaj dostęp do PostgreSQL

Wyświetl dodatkowych użytkowników, potwierdź, że każda etykieta ma aktywnego właściciela, i usuń nieaktualne konta. Ten prosty przegląd zapobiega narastaniu dostępu tylko do odczytu w zarządzanym PostgreSQL po zakończeniu działania preview, projektów analitycznych lub analiz przeprowadzanych przez support.

Zacznij od wdrożenia, które można zweryfikować

Utwórz nieprodukcyjną bazę PostgreSQL, połącz z nią usługę testową za pomocą maskowanego sekretu, wykonaj kopię zapasową i przeprowadź ćwiczenie przywracania przed przełączeniem na produkcję.

Zacznij bezpłatnie na app.dockup.ai. Plan Free kosztuje 0 USD miesięcznie, obejmuje kredyt początkowy w wysokości 10 USD i obsługuje jeden workspace, trzy bazy danych oraz trzy deploymenty.

FAQ

Jakie typy zarządzanych baz danych obsługuje Dockup?

Dockup obsługuje zarządzane bazy danych PostgreSQL, MySQL, MongoDB i Redis.

Jak aplikacja powinna otrzymać connection string PostgreSQL?

Traktuj connection string jako sekretną zmienną środowiskową, ustaw go w konkretnej usłudze i wdróż ją ponownie, aby nowy kontener go otrzymał.

Czy Dockup może utworzyć użytkownika PostgreSQL tylko do odczytu?

Tak. Polecenie user-add dla bazy danych tworzy dodatkowego użytkownika tylko do odczytu i zwraca jego hasło jednokrotnie podczas tworzenia.

Czy istnieje udokumentowane polecenie CLI dockup db restore?

Aktualna dokumentacja CLI nie opisuje takiego polecenia. Dockup obsługuje przywracanie kopii zapasowych za pośrednictwem interfejsu platformy, dlatego użyj tej obsługiwanej ścieżki zamiast wymyślać flagę lub polecenie.

Czy wycofanie wdrożenia aplikacji przywraca bazę PostgreSQL?

Nie. Historia wdrożeń aplikacji i historia kopii zapasowych bazy danych to odrębne systemy odzyskiwania i należy je koordynować, gdy zmiany schematu wymagają obu operacji.