Jak hostować Shlink samodzielnie w 2026 roku: domeny, klucze API i statystyki

Samodzielne hostowanie Shlink staje się interesujące przy pierwszym ponownym wdrożeniu, a nie przy pierwszym docker run. Jeśli generowane linki używają HTTP albo migracje nie mogą połączyć się z bazą danych, Docker nadal może raportować całkowicie zdrowy proces. Poniższe wdrożenie koncentruje się na obserwowalnym działaniu: utworzeniu krótkiego adresu URL przez API, przejściu przez jego przekierowanie, zarejestrowaniu wizyt i sprawdzeniu statystyk w kliencie webowym.

Przeznaczenie Shlink jest jasno określone: skracacz linków oparty przede wszystkim na API i oferujący statystyki. Ten opis mówi nam, co musi pozostać publiczne, co powinno być prywatne oraz co backup musi odtworzyć.

Od czego zależy Shlink

Zdrowie procesu i zdrowie produktu to w przypadku Shlink dwie różne kwestie. Port 8080 może odpowiadać, podczas gdy transakcja widoczna dla użytkownika nadal kończy się niepowodzeniem. Kontrakt sieciowy Shlink obejmuje Postgres lub MariaDB oraz opcjonalnie Redis w środowisku produkcyjnym. Prywatne endpointy umieszczaj w wewnętrznym DNS, zezwalaj tylko na wymagane połączenia wychodzące i nadaj Shlink ograniczone uprawnienia konta serwisowego.

Po istotnych zmianach konfiguracji wykonuj następujący test gotowości: utwórz krótki adres URL przez API, przejdź przez jego przekierowanie, zarejestruj wizyty i sprawdź statystyki w kliencie webowym. Nie umieszczaj kosztownych testów zewnętrznych w sondach liveness, aby awaria dostawcy nie powodowała pętli restartów. Prace nad wydajnością powinny uwzględniać przepustowość przekierowań, zapisy do bazy danych, pobieranie danych geolokalizacyjnych i działanie cache, ponieważ lepiej odzwierciedla to rzeczywiste obciążenie Shlink niż żądania stron.

Wolumeny to dopiero pierwsza warstwa odzyskiwania

Standardowy obraz Shlink nie zakłada zapisywania stanu aplikacji. Zachowaj bazę danych, klucze API i wszelkie zaimportowane dane o wizytach, a także przypięty digest i zweryfikowaną konfigurację tras, zamiast wykonywać backup pustego systemu plików kontenera.

Utwórz Shlink od podstaw na innym hoście i sprawdź, czy domeny, kody skrócone, tagi oraz rekordy wizyt zostały przywrócone, a każdy przetestowany krótki adres URL przekierowuje dokładnie tak samo. Jeśli dodasz osobną bazę danych, serwer room lub warstwę uwierzytelniania, przypisz każdemu z tych komponentów osobnego, jasno określonego właściciela procesu odtwarzania. Poradnik przejścia z repozytorium Git do produkcji pokazuje, jak powtarzalny artefakt zastępuje backup kontenera.

Dołącz do wydania polecenie odbudowy oraz test z oczekiwanym wynikiem. Plan odzyskiwania bezstanowej usługi działa dzięki odtworzeniu zachowania na podstawie zaufanych danych wejściowych; nie powinien zależeć od kopiowania nieprzejrzystego, uruchomionego kontenera.

Chroń najcenniejszą część Shlink

Bezpieczne wdrożenie Shlink zaczyna się od odebrania zbędnych uprawnień. Nie udostępniaj klucza API REST ani nie zmieniaj publicznej domeny po opublikowaniu linków. Zamiast tego trzymaj klucze API poza kodem przeglądarkowym, używaj HTTPS i ogranicz dostęp administracyjny, pozostawiając przekierowania publiczne.

DEFAULT_DOMAIN jest konfiguracją, a nie sekretem; zachowaj jego jawną wartość, chroniąc jednocześnie osobne dane uwierzytelniające używane przez Shlink. Ogranicz trasy administracyjne, używaj prywatnego DNS dla zależności i sprawdzaj każde montowanie. Gdy logi są wysyłane centralnie, filtruj sekrety i prywatne treści, zanim opuszczą serwer.

Zamień smoke test Shlink w kontrolę wydania

W przypadku Shlink zdefiniuj przed uruchomieniem transakcję oznaczającą poprawne działanie: utwórz krótki adres URL przez API, przejdź przez jego przekierowanie, zarejestruj wizyty i sprawdź statystyki w kliencie webowym. Umieść jej wymagania wstępne, oczekiwaną odpowiedź i kroki czyszczenia w systemie kontroli wersji, bez wartości sekretów. Przypnij obraz użyty do ustanowienia tego punktu odniesienia.

Użyj transakcji do zweryfikowania zamiennika i niezależnego odtworzenia. Przywrócona usługa jest akceptowalna wyłącznie wtedy, gdy domeny, kody skrócone, tagi i rekordy wizyt zostaną odtworzone, a każdy przetestowany krótki adres URL będzie przekierowywać dokładnie tak samo. Jednocześnie obserwuj przepustowość przekierowań, zapisy do bazy danych, pobieranie danych geolokalizacyjnych i działanie cache, a następnie zamień najwolniejszy lub najbardziej ograniczony element w alert service-level.

Bramka musi uwzględniać również przypadek negatywny: tymczasowo odbierz testowej tożsamości dostęp do Postgres lub MariaDB oraz opcjonalnego Redis w środowisku produkcyjnym. Potwierdź, że Shlink generuje konkretny, możliwy do wykorzystania błąd, zachowując dane, przywróć prawidłowy stan i ponownie wykonaj transakcję oznaczającą poprawne działanie. Przechowywanie obu wyników zapobiega temu, aby powierzchowny endpoint health stał się jedynym dowodem działania produkcji.

Uruchom Shlink bez ukrywania elementów infrastruktury

Poniższe polecenie uwidacznia granicę kontenera, nie udając przy tym, że konfiguruje wszystkie zewnętrzne usługi.

docker run -d \
  --name shlink \
  --restart unless-stopped \
  -p 127.0.0.1:8080:8080 \
  -e DEFAULT_DOMAIN=go.example.com \
  shlinkio/shlink:stable

Przed otwarciem ingressu sprawdź rozwiązaną konfigurację środowiska, montowania i nasłuchujący port. Dodaj zweryfikowane ustawienia połączenia z Postgres lub MariaDB oraz opcjonalnym Redis w środowisku produkcyjnym; używaj prywatnych nazw dla prywatnych usług. Pomyślne uruchomienie kończy się dopiero wtedy, gdy możesz utworzyć krótki adres URL przez API, przejść przez jego przekierowanie, zarejestrować wizyty i sprawdzić statystyki w kliencie webowym, a nie wtedy, gdy docker ps wyświetli Up.

Nadaj Shlink jeden kanoniczny adres

Publiczna granica Shlink powinna obejmować jedną kanoniczną nazwę hosta, automatyczny TLS i jeden wewnętrzny cel na porcie 8080. Ustaw DEFAULT_DOMAIN i IS_HTTPS_ENABLED przed utworzeniem krótkich adresów URL, aby klienci wracali do adresu rozpoznawanego przez usługę.

Jeśli transakcja akceptacyjna zakończy się niepowodzeniem, sklasyfikuj pierwszy błąd. Problemy z DNS, certyfikatem i 502 należą do listy kontrolnej walidacji TLS. Warunek „generowane linki używają HTTP albo migracje nie mogą połączyć się z bazą danych” dotyczy warstwy aplikacji po tym, jak żądanie skutecznie dotarło do Shlink.

Diagnozuj Shlink, który wygląda na zdrowy

W przypadku Shlink monitoruj transakcję, a nie proces: utwórz krótki adres URL przez API, przejdź przez jego przekierowanie, zarejestruj wizyty i sprawdź statystyki w kliencie webowym. Połącz jej opóźnienie i współczynnik błędów z przepustowością przekierowań, zapisami do bazy danych, pobieraniem danych geolokalizacyjnych i działaniem cache, aby alert wskazywał ograniczony komponent.

Próba aktualizacji musi uwzględniać etapowanie migracji bazy danych i zgodności API, ponieważ opublikowane krótkie linki nie mogą czekać na ręczną naprawę. Odtwórz dane, wykonaj migrację i uruchom transakcję przed zastąpieniem wersji produkcyjnej. Jeśli generowane linki używają HTTP albo migracje nie mogą połączyć się z bazą danych, nie usuwaj danych tylko po to, aby uzyskać poprawny start; w tej kolejności porównaj wersję, zmienne, montowania i osiągalność zależności.

Zachowaj jawność Shlink, a routing powierz Dockup

Jednoprzyciskowe wdrożenie Shlink w Dockup powinno zapewniać bezpieczną wymianę: trasa nadal wskazuje port 8080, 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.

Zakończ prace właściwe dla aplikacji, łącząc i testując Postgres lub MariaDB oraz opcjonalny Redis w środowisku produkcyjnym, ustawiając kanoniczny adres publiczny i wykonując ten test akceptacyjny: utwórz krótki adres URL przez API, przejdź przez jego przekierowanie, zarejestruj wizyty i sprawdź statystyki w kliencie webowym. Dodaj wynik odtworzenia do runbooka, zanim pojawią się prawdziwi użytkownicy.

Najczęściej zadawane pytania

Czego Shlink potrzebuje do wdrożenia produkcyjnego?

Przekieruj kontener Shlink na porcie 8080 przez jeden origin HTTPS. Wymaganie sieciowe dla usług wspierających to Postgres lub MariaDB oraz opcjonalnie Redis w środowisku produkcyjnym. Nie uznawaj Shlink za gotowy, dopóki nie możesz utworzyć krótkiego adresu URL przez API, przejść przez jego przekierowanie, zarejestrować wizyt i sprawdzić statystyk w kliencie webowym.

Które dane Shlink należy uwzględnić w backupie?

Standardowy obraz Shlink nie ma wymaganego mountu z danymi aplikacji. Zachowaj konfigurację wdrożenia i wykonuj backup każdego podłączonego stanu osobno; odzyskiwanie kończy się powodzeniem, gdy domeny, kody skrócone, tagi i rekordy wizyt zostaną przywrócone, a każdy przetestowany krótki adres URL będzie przekierowywać dokładnie tak samo.

Czy Shlink wymaga HTTPS za reverse proxy?

Używaj HTTPS dla publicznego originu Shlink, a port 8080 pozostaw na wewnętrznej trasie. Zastosuj poprawnie ustawienie Shlink: ustaw DEFAULT_DOMAIN i IS_HTTPS_ENABLED przed utworzeniem krótkich adresów URL. W przypadku Shlink HTTPS chroni dane uwierzytelniające lub treści użytkowników podczas transmisji i zapewnia spójne działanie klienta zależne od originu.

Jak testować aktualizację Shlink?

Odtwórz bieżący stan Shlink w odizolowanym wdrożeniu, zastosuj wersję kandydującą i ponownie wykonaj transakcję akceptacyjną. Zwróć szczególną uwagę na etapowanie migracji bazy danych i zgodności API, ponieważ opublikowane krótkie linki nie mogą czekać na ręczną naprawę. Zachowaj poprzedni obraz Shlink, dopóki nie poznasz granic migracji danych i wycofywania zmian.