Prywatna sieć i domeny .internal w Dockup

Prywatna sieć umożliwia komunikację usług i zarządzanych baz danych w ramach jednego projektu Dockup bez przesyłania ruchu między zasobami tego samego projektu przez publiczny internet. Każdy zasób otrzymuje stabilną nazwę hosta <slug>.internal, a osobne projekty pozostają od siebie odizolowane.

Sieć jest włączana opcjonalnie. Jej aktywacja łączy istniejące zasoby projektu bez konieczności natychmiastowego przełączania ruchu aplikacji, a usługi otrzymują wewnętrzne zmienne połączeń po ponownym wdrożeniu.

Jak sieć service-to-service ogranicza ekspozycję publiczną?

Publiczny endpoint bazy danych jest osiągalny z internetu, nawet jeśli uwierzytelnianie blokuje nieautoryzowany dostęp. Prywatna trasa usuwa tę ekspozycję dla ruchu aplikacji i zapewnia usługom stabilną nazwę wewnętrzną, która nie zależy od publicznego adresu.

Ta sama zasada dotyczy wywołań service-to-service. API może wywoływać workera, wewnętrzną usługę administracyjną lub backend przez sieć projektu, zamiast korzystać z publicznej domeny niestandardowej.

Ścieżka ruchu	Trasa publiczna	Trasa prywatna
API do PostgreSQL	Publiczny host i port	main-db.internal
Web do API	Publiczna domena niestandardowa	api.internal
Worker do Redis	Publiczny host i port	app-redis.internal
Preview do produkcyjnej bazy danych	Publiczne dane uwierzytelniające bazy	Wewnętrzny użytkownik tylko do odczytu
Wywołanie między projektami	Wymagany publiczny endpoint	Zablokowane przez izolację projektów

Prywatny nie znaczy nieuwierzytelniony. Nadal używaj użytkowników baz danych, autoryzacji usług i secrets. Sieć określa osiągalność, a dane uwierzytelniające — uprawnienia.

Jak włączyć prywatną sieć projektu?

Włącz sieć dla sluga projektu:

dockup network enable production --json

Operacja łączy usługi i zarządzane bazy danych z siecią projektu. Istniejące publiczne listenery pozostają domyślnie dostępne, więc migrację można przeprowadzić stopniowo.

Wdróż ponownie każdą usługę aplikacji, która powinna otrzymać wewnętrzne zmienne środowiskowe:

dockup deploy production/api --wait --json
dockup deploy production/worker --wait --json

Dockup wstrzykuje dane połączenia, takie jak DATABASE_URL_INTERNAL, specyficzne dla bazy wewnętrzne zmienne URL i hosta oraz wartości hosta/portu usług. Wyświetl klucze zmiennych środowiskowych usługi bez ujawniania secrets:

dockup env list -s production/api --json

Nie twórz ręcznie URL-a na podstawie nazwy wyświetlanej w interfejsie. O tym, jaki będzie hostname <slug>.internal, decydują slugi zasobów.

Przed zmianą konfiguracji aplikacji sprawdź, czy każda zależność znajduje się w tym samym projekcie. Osobne projekty mają osobne sieci i nie mogą rozpoznawać siebie nawzajem ani łączyć się przez ścieżkę wewnętrzną.

Jak domeny .internal zmieniają konfigurację usług?

Internal DNS zapewnia stabilną nazwę, podczas gdy kontenery i nody zmieniają się w tle. Usługa API o slugu api jest osiągalna jako api.internal z usług należących do tego samego projektu, a baza danych o slugu main-db jest osiągalna jako main-db.internal.

Jeśli to możliwe, wybieraj wstrzykiwane zmienne połączeń. Zawierają one poprawny protokół, dane uwierzytelniające, nazwę bazy danych i format hosta. Ręcznie zbudowany string może pomijać TLS, kodowanie hasła lub parametry bazy danych.

Migruj po jednej zależności naraz:

1. Włącz sieć.
2. Wdróż ponownie usługę korzystającą z zależności.
3. Potwierdź, że wewnętrzna zmienna istnieje.
4. Zmień aplikację tak, aby z niej korzystała.
5. Wdróż z opcją --wait.
6. Zweryfikuj nowe połączenia.
7. Obserwuj logi runtime i czas odpowiedzi.
8. Przejdź do następnej zależności.

Usługa może zachować publiczną domenę niestandardową dla ruchu użytkowników, korzystając jednocześnie z prywatnych nazw hostów podczas wywołań backendowych. Ścieżki publiczne i prywatne obsługują różne granice zaufania.

W przewodniku zmienne środowiskowe i secrets wyjaśniono, dlaczego zmiany połączeń wymagają ponownego wdrożenia.

Jak skonfigurować zarządzaną bazę danych wyłącznie prywatnie?

Gdy każda wymagana usługa korzystająca z bazy używa już ścieżki wewnętrznej, usuń publiczny listener:

dockup db private production/main-db --json

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

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

Ta operacja na bazie danych odtwarza kontener, zachowując dane. Zaplanuj okno serwisowe odpowiednie do obciążenia, potwierdź istnienie aktualnej kopii zapasowej i przetestuj ponowne nawiązywanie połączeń przez aplikację.

Przed przełączeniem na tryb wyłącznie prywatny sprawdź:

• Każda usługa produkcyjna korzystająca z bazy znajduje się w tym samym projekcie.
• Narzędzia operacyjne nie wymagają publicznego endpointu.
• Dostęp preview korzysta z obsługiwanej ścieżki prywatnej.
• Istnieje kopia zapasowa, a sposób odtwarzania jest znany.
• Connection pools bezpiecznie ponawiają próby.
• Dokładny cel project/db został zapisany.

Do bazy wyłącznie prywatnej nie można połączyć się bezpośrednio z laptopa operatora przez publiczny internet. Korzystaj z obsługiwanego dostępu platformy i diagnostyki na poziomie aplikacji, zamiast pochopnie ponownie otwierać listener.

Informacje o operacjach na bazach danych znajdziesz w przewodniku zarządzany PostgreSQL.

Jak bezpiecznie zapewnić PR preview dostęp do danych produkcyjnych?

Każdy preview PR lub gałęzi w Dockup otrzymuje własne odizolowane wdrożenie i URL. W projekcie z prywatną siecią preview dołącza do sieci projektu i może rozpoznawać <slug>.internal.

Dockup automatycznie tworzy użytkownika tylko do odczytu dla produkcyjnej zarządzanej bazy danych używanej przez preview. Preview może wykonywać zapytania na danych o strukturze produkcyjnej, ale za pomocą tego użytkownika nie może ich modyfikować.

Takie rozwiązanie ogranicza ryzyko, że gałąź z funkcją zmodyfikuje dane klientów, jednak dostęp do odczytu nadal wiąże się z konsekwencjami:

• Dane osobowe lub wrażliwe mogą pojawić się w preview.
• Nowy kod aplikacji może zapisywać odczytane dane w logach.
• Podatny URL preview może ujawnić wyniki zapytań.
• Kosztowne zapytania mogą wpływać na obciążenie produkcji.
• Założenia dotyczące schematu mogą różnić się między gałęzią a produkcją.

Włącz wdrożenia preview wyłącznie zgodnie z zatwierdzoną polityką:

dockup pr-preview production/api --on --json
dockup preview branch feature/search production/api --json

Używaj odizolowanego środowiska preview dla feature flags i secrets niezwiązanych z bazą danych. Nie zastępuj automatycznych danych uwierzytelniających tylko do odczytu produkcyjnymi danymi uwierzytelniającymi z uprawnieniami do zapisu.

Jak monitorować i diagnozować prywatną sieć?

Zacznij od topologii i konfiguracji, zamiast zakładać awarię platformy.

Objaw	Prawdopodobny obszar	Sprawdzenie
Nie znaleziono nazwy	Nieprawidłowy slug/projekt lub brak ponownego wdrożenia usługi	Lista usług i klucze zmiennych środowiskowych
Odrzucono połączenie	Zatrzymany zasób lub nieprawidłowy port	Status oraz logi bazy/usługi
Uwierzytelnianie nie powiodło się	Nieprawidłowe dane uwierzytelniające	Rotacja secretu i użytkownik
Publiczna ścieżka działa, prywatna nie	Wewnętrzna zmienna lub migracja do sieci	Włączenie sieci i ponowne wdrożenie
Preview może odczytywać, ale nie zapisywać	Oczekiwana polityka tylko do odczytu	Nie zastępuj danych uwierzytelniających
Wywołanie między projektami nie działa	Oczekiwana izolacja	Użyj publicznego, uwierzytelnionego API

Sprawdź logi runtime aplikacji:

dockup logs production/api --json

Sprawdź rozmiar bazy danych i błędy połączeń aplikacji:

dockup db size production/main-db --json
dockup logs production/api --json

Nie umieszczaj pełnych wewnętrznych URL-i połączeń w notatkach dotyczących incydentu. Mogą zawierać dane uwierzytelniające, nawet jeśli sama nazwa hosta nie jest sekretem.

Plan migracji i rollbacku

W pierwszej fazie pozostaw publiczny listener. Jeśli wdrożenie wewnętrzne się nie powiedzie, przywróć poprzednią konfigurację aplikacji i wdróż ją ponownie. Bazę danych przełączaj na tryb wyłącznie prywatny dopiero po ustabilizowaniu ścieżki wewnętrznej.

Aby wyłączyć całą sieć projektu:

dockup network disable production --json

Powinna to być świadoma decyzja dotycząca rollbacku, a nie pierwszy krok diagnostyki. Wyłączenie sieci wpływa na każdy połączony zasób w projekcie.

Rejestruj zmiany sieci w audit logu:

dockup audit --writes --json

Lista kontrolna prywatnej sieci w produkcji

Kompletny runbook prywatnej sieci obejmuje slug projektu, slugi usług i baz danych, wewnętrzne nazwy hostów, nazwy wstrzykiwanych zmiennych, politykę publicznych listenerów, politykę dostępu preview, status kopii zapasowych, kolejność ponownych wdrożeń oraz ścieżkę rollbacku.

Zużycie CPU, RAM-u i dysku nadal jest rozliczane na podstawie użycia i mierzone co minutę; routing prywatny to decyzja architektoniczna, a nie stała klasa instancji. Do modelowania kosztów użyj przewodnika wyjaśnienie cen PaaS.

Aktualna dokumentacja Dockup CLI zawiera bieżące polecenia dotyczące sieci i baz danych. Ogólne informacje o izolacji wdrożeń znajdziesz w najlepszych praktykach bezpieczeństwa.

Modeluj autoryzację usług niezależnie od osiągalności

Wewnętrzna nazwa hosta potwierdza jedynie, że wywołujący znajduje się w sieci projektu. Nie potwierdza, która usługa wysłała żądanie ani czy ta usługa może wykonać daną operację. Zachowaj uwierzytelnianie aplikacji dla wrażliwych wewnętrznych API oraz dane uwierzytelniające baz danych do kontroli dostępu do danych.

Używaj secrets przypisanych do konkretnych usług zamiast jednego współdzielonego tokenu wewnętrznego. Jeśli preview otrzymuje dostęp do bazy danych tylko do odczytu, nie przekazuj mu jednocześnie produkcyjnego tokenu usługi, który może uruchamiać operacje zapisu przez API.

Zmierz efekt przełączenia

Porównaj opóźnienie połączeń, współczynnik błędów i czas odpowiedzi p95 przed przełączeniem na endpointy wewnętrzne i po nim. Głównym celem jest izolacja i stabilna prywatna ścieżka; każdą poprawę opóźnień należy zmierzyć, a nie obiecywać.

dockup uptime production/api --hours 24 --json

Zachowaj okno obserwacji i ID wdrożenia. Dzięki temu zmiana dotycząca prywatnej sieci ma mierzalne kryterium ukończenia, zamiast kończyć się na stwierdzeniu „DNS rozwiązał nazwę”.

Udokumentuj wyjątki korzystające ze ścieżki publicznej

Niektóre integracje zewnętrzne, narzędzia operatora lub usługi z innych projektów mogą nadal wymagać publicznego endpointu. Wymień każdy wyjątek, sposób jego uwierzytelniania, właściciela i warunek usunięcia. Zapobiega to sytuacji, w której publiczny listener pozostaje aktywny bezterminowo, ponieważ nikt nie pamięta, dlaczego został pozostawiony.

Kompletne wdrożenie prywatnej sieci może być częściowe, ale każda publiczna ścieżka powinna być utrzymywana celowo.

Przejrzyj wewnętrzne zależności po zmianie nazw

Zmiana nazwy zasobu lub jego zastąpienie może zmienić slug używany w adresowaniu .internal. Przed zmianą nazw zinwentaryzuj użytkowników, wdróż ich ponownie z aktualnymi wstrzykniętymi zmiennymi i zweryfikuj każde prywatne połączenie.

Dzięki temu prywatna sieć pozostaje stabilna w miarę rozwoju projektu.

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

Włącz sieć w projekcie innym niż produkcyjny, przeprowadź migrację jednej zależności na endpoint .internal i sprawdź ścieżkę rollbacku, zanim usuniesz dowolny publiczny listener.

Zacznij bezpłatnie w app.dockup.ai. Plan Free kosztuje 0 USD miesięcznie, obejmuje 10 USD kredytu początkowego oraz obsługuje jeden workspace, trzy bazy danych i trzy wdrożenia.

FAQ

Jakich nazw hostów używają zasoby Dockup w prywatnej sieci?

Każda usługa i zarządzana baza danych w tym samym projekcie jest osiągalna za pomocą stabilnej nazwy hosta w formacie <slug>.internal.

Czy włączenie prywatnej sieci usuwa publiczny dostęp do bazy danych?

Nie. Domyślnie sieć jest dodatkiem. Użyj osobnego polecenia database private, aby usunąć publiczny listener, gdy użytkownicy korzystający z bazy przejdą na ścieżkę wewnętrzną.

Czy różne projekty Dockup mogą łączyć się ze sobą prywatnie?

Nie. Każdy projekt ma odizolowaną sieć, dlatego komunikacja między projektami musi korzystać z odpowiedniego publicznego i uwierzytelnionego interfejsu.

Czy PR preview może zapisywać dane w produkcyjnej bazie?

W projekcie z prywatną siecią Dockup automatycznie tworzy dla preview użytkownika bazy danych tylko do odczytu, umożliwiając odczyt, ale blokując zapis przy użyciu tych danych uwierzytelniających.

Dlaczego po włączeniu sieci usługi muszą zostać wdrożone ponownie?

Ponowne wdrożenie przekazuje nowemu kontenerowi wewnętrzne zmienne połączeń i pozwala aplikacji uruchomić się z konfiguracją prywatnego endpointu.