Domena niestandardowa i automatyczny TLS w Dockup

Konfiguracja domeny niestandardowej i automatycznego TLS składa się z trzech niezależnych warstw: usługa Dockup musi działać prawidłowo, DNS musi wskazywać hostname na platformę, a hostname musi przejść weryfikację, zanim będzie można wystawić certyfikat. Rozdzielenie tych warstw sprawia, że przełączenie jest przewidywalne, a błędy DNS nie wyglądają jak awarie aplikacji.

Dockup udostępnia również każdej usłudze adres *.dockup.tech. Zachowaj ten adres dostępny podczas propagacji DNS, aby móc testować aplikację niezależnie od niestandardowego hosta.

Co powinno być gotowe przed dodaniem domeny niestandardowej Dockup?

Zacznij od usługi, która już działa i przechodzi kontrolę gotowości:

dockup status production/web --json
dockup health production/web --json

Otwórz lub przetestuj istniejący adres URL *.dockup.tech. Jeśli aplikacja nie działa pod tym adresem, dodanie domeny tego nie naprawi. Najpierw przejrzyj logi środowiska uruchomieniowego.

Zbierz następujące informacje:

Element	Przykład	Dlaczego ma znaczenie
Dokładny cel	production/web	Zapobiega podpięciu domeny do niewłaściwej usługi
Hostname	app.example.com	Nazwa DNS, którą będą odwiedzać użytkownicy
Dostęp do DNS	Rejestrator lub dostawca DNS	Wymagany do utworzenia rekordu
Bieżący TTL	300 sekund	Określa szybkość propagacji i wycofania zmian
Kanoniczny URL aplikacji	https://app.example.com	Może wpływać na przekierowania i cookies
Ścieżka health check	/health	Potwierdza działanie usługi przed przełączeniem

Z wyprzedzeniem obniż bieżący TTL DNS, jeśli zastępujesz działającego dostawcę. Nie usuwaj starego rekordu, dopóki nie znasz celu Dockup, konfiguracji aplikacji i planu rollbacku.

Sprawdź działanie aplikacji zależne od hosta. Nowy hostname HTTPS może wymagać aktualizacji callbacków uwierzytelniania, allowlist CORS, domen cookies, adresów przekierowań OAuth, miejsc docelowych webhooków i generowanych linków absolutnych.

Jak dodać i zweryfikować domenę?

Najpierw wyświetl bieżące domeny:

dockup domain list production/web --json

Dodaj hostname:

dockup domain add app.example.com production/web --json

Odpowiedź zawiera cel DNS, który należy skonfigurować. Utwórz wskazany rekord CNAME u dostawcy DNS. Nie wymyślaj adresu IP ani nie kopiuj wartości z innej usługi — użyj celu zwróconego dla tej domeny.

Po propagacji DNS zweryfikuj domenę za pomocą zwróconego identyfikatora domeny:

dockup domain verify <domainId> production/web --json

Weryfikacja potwierdza, że publiczny rekord DNS rozwiązuje się zgodnie z wymaganiami. Niepowodzenie zwykle oznacza jedną z czterech przyczyn:

1. Nieprawidłowa nazwa rekordu.
2. Nieprawidłowy cel CNAME.
3. Nadal istnieje stary, kolidujący rekord A, AAAA lub CNAME.
4. Cache resolverów nie otrzymał jeszcze nowej wartości.

Sprawdź autorytatywny DNS zamiast wielokrotnie usuwać i ponownie tworzyć domenę. Propagacja jest rozproszonym procesem cache, a nie procesem buildowania Dockup.

Jak wystawiany i utrzymywany jest certyfikat HTTPS?

Po pomyślnej weryfikacji zamów certyfikat:

dockup domain ssl <domainId> production/web --json

Dockup obsługuje wystawianie certyfikatu dla zweryfikowanego hosta i udostępnia niestandardową domenę przez HTTPS. Platforma zarządza cyklem życia TLS, więc kontener aplikacji nie musi przechowywać plików certyfikatu ani uruchamiać procesu jego odnawiania.

Zweryfikuj wynik spoza platformy:

curl -I https://app.example.com

Potwierdź, że:

• Certyfikat pasuje do hosta.
• Odpowiedź jest dostarczana przez HTTPS.
• Przekierowania nie tworzą pętli.
• Aplikacja zwraca oczekiwany status.
• Uwierzytelnianie i przepływy callbacków korzystają z nowego originu.
• Zasoby statyczne ładują się bez błędów mixed content.

Wystawianie certyfikatu może nie powieść się nawet wtedy, gdy sama aplikacja działa prawidłowo. Diagnostykę DNS i usługi prowadź oddzielnie. Do weryfikacji własności DNS używaj domain verify, a do sprawdzania działania aplikacji — logów usługi.

Artykuł wdrażanie bez przestoju wyjaśnia niezależny mechanizm kontroli gotowości do wydania.

Jak przełączyć ruch bez przestoju?

Bezpieczne przełączenie zachowuje starą ścieżkę do czasu potwierdzenia działania nowego hosta.

1. Wdróż usługę Dockup i zweryfikuj ją pod adresem URL platformy.
2. Dodaj domenę niestandardową w Dockup.
3. Utwórz rekord DNS.
4. Zweryfikuj DNS.
5. Wystaw certyfikat TLS.
6. Przetestuj bezpośrednio HTTPS.
7. Zaktualizuj callbacki, kanoniczne URL-e i monitoring.
8. Jeśli konfiguracja DNS na to pozwala, skieruj niewielką część ruchu operacyjnego.
9. Obserwuj logi i uptime.
10. Wyłącz starego dostawcę dopiero po ustabilizowaniu nowej ścieżki.

Checki uptime Dockup uruchamiają się co minutę i raportują statystyki czasu odpowiedzi, w tym p95:

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

W przypadku krytycznych domen zachowaj niezależny monitoring zewnętrzny. Probe platformy potwierdza publiczną dostępność, natomiast zewnętrzny monitor weryfikuje ścieżkę użytkownika z innego systemu.

Jeśli domena niestandardowa zastępuje obecny host produkcyjny, zachowaj informacje potrzebne do rollbacku: poprzednią wartość DNS, poprzedni TTL, status starego dostawcy oraz warunek, który spowoduje wycofanie zmiany.

Jak działają domeny dodatkowych portów?

Usługa może udostępniać drugi port HTTP na potrzeby panelu administracyjnego, endpointu metryk lub innego procesu webowego. Dockup może utworzyć dodatkową domenę platformy bez niestandardowego DNS:

dockup port list production/web --json
dockup port add 8080 production/web --name admin --json

Zwrócona domena kieruje ruch do wybranego portu kontenera. Jest to niezależne od głównej domeny niestandardowej.

Nie udostępniaj portu tylko dlatego, że nasłuchuje na nim jakiś proces. Zastanów się, czy endpoint ma uwierzytelnianie, czy zawiera dane produkcyjne i czy w ogóle powinien być publiczny. Wewnętrzny interfejs administracyjny nie powinien stawać się dostępny z internetu wyłącznie dla wygody.

Usuń nieużywaną domenę portu za pośrednictwem obsługiwanego interfejsu domen dopiero po potwierdzeniu, że nie korzysta z niej już żaden monitor, callback ani workflow operatora. Zmiany domen portów są mutacjami i pojawiają się w logu audytowym.

Jak rozwiązywać problemy z DNS, TLS i aplikacją?

Stosuj diagnostykę warstwową:

Objaw	Pierwsze sprawdzenie	Polecenie Dockup
Domena się nie rozwiązuje	Rekord DNS i propagacja	domain verify
Certyfikat nie został wystawiony	Status weryfikacji domeny	domain list, domain ssl
HTTPS działa, ale aplikacja zgłasza błędy	Logi środowiska uruchomieniowego	logs --json
Pętla przekierowań	Ustawienia proxy/hosta aplikacji	env list, logi środowiska uruchomieniowego
URL platformy działa, ale niestandardowy host nie	Warstwa DNS/TLS	Polecenia domen
Nie działają oba adresy URL	Wdrożenie i środowisko uruchomieniowe	status, logi build/runtime
Nie działa port dodatkowy	Mapowanie domeny portu i proces	port list, logi środowiska uruchomieniowego

Sprawdzaj dane wyjściowe usługi bez mieszania ich z wnioskami dotyczącymi DNS:

dockup logs production/web --json
dockup status production/web --json

Jeśli niedawna zmiana środowiska dodała kanoniczny URL, pamiętaj, że wymaga ona ponownego wdrożenia:

dockup env set APP_URL=https://app.example.com \
  -s production/web \
  --json

dockup deploy production/web --wait --json

Cykl życia tych ustawień opisuje poradnik dotyczący zmiennych środowiskowych i sekretów.

Usuwanie domeny i rollback

Usunięcie powiązania z Dockup jest destrukcyjne dla routingu, dlatego najpierw przenieś lub usuń publiczny rekord DNS i potwierdź planowane zastępstwo. Następnie usuń powiązanie za pośrednictwem obsługiwanego interfejsu domen, używając dokładnego identyfikatora domeny.

Nie usuwaj domeny podczas tymczasowego problemu z certyfikatem lub propagacją, chyba że wymaga tego plan odzyskiwania. Pozostawienie konfiguracji umożliwia pomyślną weryfikację po zaktualizowaniu cache.

Przejrzyj mutacje za pomocą:

dockup audit --search domains --json

Ścieżka audytu powinna wskazywać, kto dodał, zweryfikował, zabezpieczył lub usunął hostname.

Checklista przekazania do produkcji

Kompletne przekazanie domeny niestandardowej i automatycznego TLS obejmuje cel usługi, hostname, identyfikator domeny, typ i cel rekordu DNS, wynik weryfikacji, wynik wystawienia certyfikatu, zmiany callbacków aplikacji, URL monitoringu oraz wartość DNS potrzebną do rollbacku.

Nie przechowuj prywatnego klucza certyfikatu w repozytorium ani w kontenerze. Zarządzana warstwa TLS Dockup istnieje właśnie po to, aby zespół aplikacji mógł obsługiwać hostname bez rozpowszechniania materiałów certyfikatu.

Aktualne flagi znajdziesz w dokumentacji Dockup CLI. Aby wykonać początkowe wdrożenie przed pracą nad domeną, skorzystaj z repozytorium Git do wdrożenia produkcyjnego.

Zaplanuj wybór domeny głównej i subdomeny

Subdomena taka jak app.example.com jest zwykle najprostszym hostem aplikacji, ponieważ dostawcy DNS mogą reprezentować ją za pomocą CNAME. Domena główna, taka jak example.com, może wymagać obsługi provider-specific flattening lub aliasów. Postępuj zgodnie z celem DNS zwróconym przez Dockup oraz możliwościami autorytatywnego dostawcy DNS.

Wybierz jeden kanoniczny host i przekierowuj alternatywy na poziomie aplikacji lub routingu. Udostępnianie jednocześnie www i domeny głównej bez ustalonej polityki kanonicznej może rozdzielać cookies, analitykę, wpisy cache i indeksowanie w wyszukiwarkach.

Przetestuj założenia dotyczące odnawiania certyfikatu

Zarządzany TLS eliminuje potrzebę uruchamiania klienta odnawiania wewnątrz kontenera, ale hostname musi nadal poprawnie się rozwiązywać. Późniejsza migracja DNS, zmiana proxy lub usunięcie rekordu może przerwać walidację.

Uwzględniaj status domeny w rutynowych przeglądach:

dockup domain list production/web --json
dockup uptime production/web --hours 24 --json

Runbook domeny niestandardowej i automatycznego TLS powinien wskazywać właściciela DNS, osobę kontaktową odpowiedzialną za odnowienia oraz datę ostatniego zewnętrznego sprawdzenia certyfikatu. Dzięki temu nie trzeba ustalać właściciela dopiero podczas incydentu z certyfikatem.

Chroń hosty nieprodukcyjne

Hosty stagingowe i preview mogą ujawniać niedokończone funkcje oraz dane przypominające dane produkcyjne. W razie potrzeby stosuj uwierzytelnianie aplikacji, określaj politykę indeksowania na poziomie aplikacji i ograniczaj rozpowszechnianie URL-i środowisk nieprodukcyjnych.

Dyrektywy dla wyszukiwarek nie są mechanizmem kontroli dostępu. Chronione środowisko nadal wymaga uwierzytelniania i odpowiedniego przetwarzania danych.

Sprawdź ponownie po propagacji

Powtórz zewnętrzne testy HTTPS i callbacków po upływie pełnego czasu określonego przez początkowy TTL DNS.

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

Najpierw podepnij niekrytyczny hostname, zachowaj URL platformy podczas propagacji i zapisz dokładną wartość DNS potrzebną do rollbacku.

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

FAQ

Jakiego rekordu DNS wymaga domena niestandardowa Dockup?

Uruchom dockup domain add i utwórz rekord DNS pokazany w odpowiedzi. Użyj zwróconego celu zamiast kopiować wartość z innej usługi.

Kiedy Dockup może wystawić TLS dla domeny niestandardowej?

Po pomyślnej weryfikacji rekordu DNS hosta przez Dockup uruchom wystawianie certyfikatu za pomocą udokumentowanego polecenia domain ssl.

Czy mój kontener musi przechowywać certyfikaty TLS?

Nie. Dockup zarządza TLS dla zweryfikowanej domeny niestandardowej, więc kontener aplikacji nie potrzebuje plików certyfikatu ani procesu ich odnawiania.

Czy Dockup może udostępnić dodatkowy port kontenera?

Tak. Polecenia port mogą utworzyć osobną, automatycznie wygenerowaną domenę dla dodatkowego publicznego portu bez konieczności konfigurowania niestandardowego DNS.

Co sprawdzić, gdy URL platformy działa, ale domena niestandardowa nie?

Skup się na rekordach DNS, propagacji, weryfikacji domeny i statusie certyfikatu. Działający URL platformy wskazuje, że warstwa aplikacji prawdopodobnie działa.