Jak self-hostovat Shlink v roce 2026: domény, API klíče a statistiky

Self-hostování Shlinku začíná být zajímavé při prvním redeployi, ne při prvním docker run. Pokud generované odkazy používají HTTP nebo migrace nemohou dosáhnout na databázi, Docker může stále hlásit dokonale zdravý proces. Níže uvedené nasazení je postavené na pozorovatelném chování: vytvořte krátkou URL přes API, následujte její redirect, zaznamenejte návštěvy a prohlédněte si statistiky z webového klienta.

Účel Shlinku je jasný: API-first zkracovač odkazů se statistikami. Tento popis nám říká, co musí zůstat veřejné, co má zůstat privátní a co musí záloha obnovit.

Na čem Shlink závisí

Stav procesu a stav produktu jsou u Shlinku dvě odlišné věci. Port 8080 může odpovídat, zatímco transakce viditelná pro uživatele stále selhává. Síťový kontrakt pro Shlink tvoří Postgres nebo MariaDB a volitelně Redis pro produkci. Privátní endpointy ponechte na interním DNS, povolte pouze potřebná odchozí spojení a Shlinku přidělte omezený service credential.

Tento test připravenosti použijte po významných změnách konfigurace: vytvořte krátkou URL přes API, následujte její redirect, zaznamenejte návštěvy a prohlédněte si statistiky z webového klienta. Nákladné externí kontroly ponechte mimo liveness probes, aby výpadek poskytovatele nezpůsobil restartovací smyčku. Při plánování kapacity sledujte propustnost redirectů, zápisy do databáze, stahování geolokačních dat a chování cache — to lépe odpovídá skutečnému zatížení Shlinku než požadavky na stránky.

Volumes jsou pouze první vrstvou obnovy

Ve standardním image Shlinku se neočekává žádný zapisovatelný stav aplikace. Uchovávejte databázi, API klíče a veškerá importovaná data o návštěvách včetně připnutého digestu a zkontrolované konfigurace rout, místo abyste zálohovali prázdný filesystem kontejneru.

Vytvořte Shlink od začátku na jiném hostiteli a ověřte, že se vrátí domény, short codes, tagy a záznamy o návštěvách a že každá vybraná krátká URL redirectuje identicky. Pokud přidáte samostatnou databázi, room server nebo autentizační vrstvu, určete pro každou z těchto komponent vlastního explicitního vlastníka obnovy. Průvodce od Gitu do produkce ukazuje, jak reprodukovatelný artefakt nahrazuje zálohu kontejneru.

Příkaz pro rebuild a test s očekávaným výstupem zaznamenejte společně s releasem. Stateless plán obnovy uspěje reprodukcí chování z důvěryhodných vstupů; neměl by záviset na kopírování neprůhledného běžícího kontejneru.

Chraňte cennou část Shlinku

Bezpečné nasazení Shlinku začíná odebráním oprávnění. Nevystavujte REST API key a po publikování odkazů neměňte veřejnou doménu; místo toho držte API klíče mimo kód prohlížeče, používejte HTTPS a omezte administraci, zatímco redirecty ponecháte veřejné.

DEFAULT_DOMAIN je konfigurace, nikoli secret; jeho hodnotu udržujte explicitní a chraňte oddělené credentials používané Shlinkem. Omezte administrativní routy, pro závislosti používejte privátní DNS a zkontrolujte každý bind mount. Pokud logy odesíláte centrálně, odfiltrujte secrets a privátní obsah ještě před jejich opuštěním serveru.

Proměňte smoke test Shlinku v release check

Pro Shlink definujte před spuštěním známou správnou transakci: vytvořte krátkou URL přes API, následujte její redirect, zaznamenejte návštěvy a prohlédněte si statistiky z webového klienta. Její prerequisites, očekávanou response a kroky úklidu uložte do version control bez secret values. Image použitý pro vytvoření této reference připněte na konkrétní verzi.

Transakci použijte k ověření náhrady i nezávislé obnovy. Obnovená služba je přijatelná pouze tehdy, když se vrátí domény, short codes, tagy a záznamy o návštěvách a každá vybraná krátká URL redirectuje identicky. Současně sledujte propustnost redirectů, zápisy do databáze, stahování geolokačních dat a chování cache a nejpomalejší nebo nejvíce omezenou část proměňte v service-level alert.

Gate potřebuje také negativní případ: dočasně odeberte testovací identitě přístup k Postgresu nebo MariaDB a volitelnému Redisu pro produkci. Ověřte, že Shlink vytvoří použitelnou chybovou zprávu a přitom zachová data, obnovte správný stav a zopakujte transakci se známým správným výsledkem. Uchování obou výsledků zabrání tomu, aby se povrchní health endpoint stal jediným důkazem funkčnosti v produkci.

Spusťte Shlink bez skrývání pohyblivých částí

Následující příkaz zviditelní hranici kontejneru, aniž by předstíral provisioning všech externích služeb.

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

Před otevřením ingressu zkontrolujte vyřešené hodnoty prostředí, mounty a listener. Přidejte zkontrolované connection settings pro Postgres nebo MariaDB a volitelný Redis pro produkci; pro privátní služby používejte privátní názvy. Úspěšné spuštění je dokončeno ve chvíli, kdy můžete vytvořit krátkou URL přes API, následujte její redirect, zaznamenat návštěvy a prohlédnout si statistiky z webového klienta — nikoli ve chvíli, kdy docker ps vypíše Up.

Dejte Shlinku jednu kanonickou adresu

Veřejná hranice Shlinku by měla být tvořena jedním kanonickým hostname, automatickým TLS a jedním interním targetem na portu 8080. Před vytvořením krátkých URL nastavte DEFAULT_DOMAIN a IS_HTTPS_ENABLED, aby klienti odkazovali na adresu, kterou služba rozpoznává.

Pokud acceptance transaction selže, klasifikujte první chybu. Problémy s DNS, certifikátem a chybou 502 patří do checklistu validace TLS. Stav „generované odkazy používají HTTP nebo migrace nemohou dosáhnout na databázi“ patří na stranu aplikace poté, co požadavek úspěšně dorazil do Shlinku.

Diagnostikujte Shlink, který vypadá zdravě

U Shlinku monitorujte transakci, nikoli proces: vytvořte krátkou URL přes API, následujte její redirect, zaznamenejte návštěvy a prohlédněte si statistiky z webového klienta. Její latenci a chybovost kombinujte s propustností redirectů, zápisy do databáze, stahováním geolokačních dat a chováním cache, aby alert identifikoval omezenou komponentu.

Rehearsal upgradu musí pokrývat skutečnost, že databázové migrace a API compatibility je nutné provádět postupně, protože publikované krátké odkazy nemohou čekat na manuální opravu. Před nahrazením v produkci proveďte restore, migraci a transakci. Pokud generované odkazy používají HTTP nebo migrace nemohou dosáhnout na databázi, nemažte data jen proto, aby startup skončil zeleně; porovnejte v tomto pořadí verzi, proměnné, mounty a dostupnost závislostí.

Udržujte Shlink explicitní, zatímco Dockup řeší routing

One-click nasazení Shlinku v Dockupu by mělo zajistit bezpečnou náhradu: route bude nadále mířit na port 8080, secrets nebudou zapečené v image a persistentní cesty se vrátí v novém kontejneru. Stejné nasazení může běžet na Dockup compute nebo na připojeném stroji.

Dokončete práci specifickou pro aplikaci připojením a otestováním Postgresu nebo MariaDB a volitelného Redisu pro produkci, použitím kanonické veřejné adresy a spuštěním tohoto acceptance checku: vytvořte krátkou URL přes API, následujte její redirect, zaznamenejte návštěvy a prohlédněte si statistiky z webového klienta. Výsledek obnovy přidejte do runbooku ještě před příchodem skutečných uživatelů.

Často kladené otázky

Co Shlink potřebuje pro produkční nasazení?

Veďte kontejner Shlinku na portu 8080 přes jeden HTTPS origin. Požadavek na podpůrnou síť tvoří Postgres nebo MariaDB a volitelně Redis pro produkci. Shlink neoznačujte za připravený, dokud nemůžete vytvořit krátkou URL přes API, následujte její redirect, zaznamenejte návštěvy a prohlédněte si statistiky z webového klienta.

Která data Shlinku patří do zálohy?

Standardní image Shlinku nemá žádný povinný mount s daty aplikace. Uchovávejte jeho konfiguraci nasazení a veškerý připojený stav zálohujte samostatně; obnova je úspěšná, když se vrátí domény, short codes, tagy a záznamy o návštěvách a každá vybraná krátká URL redirectuje identicky.

Vyžaduje Shlink HTTPS za reverse proxy?

Pro veřejný origin Shlinku používejte HTTPS a port 8080 ponechte na interní route. Nastavení Shlinku aplikujte správně: před vytvořením krátkých URL nastavte DEFAULT_DOMAIN a IS_HTTPS_ENABLED. HTTPS u Shlinku chrání credentials nebo uživatelský obsah při přenosu a udržuje konzistentní chování klienta závislé na originu.

Jak testovat upgrade Shlinku?

Obnovte aktuální stav Shlinku do izolovaného nasazení, aplikujte kandidátní verzi a zopakujte acceptance transaction. Věnujte tomu zvláštní pozornost, protože databázové migrace a API compatibility je nutné provádět postupně, protože publikované krátké odkazy nemohou čekat na manuální opravu. Předchozí image Shlinku ponechte k dispozici, dokud nebudete rozumět hranici migrace dat a rollbacku.