Kako samostalno hostati Shlink u 2026.: domene, API ključevi i statistika

Samostalno hostanje Shlinka postaje zanimljivo pri prvom ponovnom deployu, a ne pri prvom docker run. Ako generirani linkovi koriste HTTP ili migracije ne mogu dosegnuti bazu podataka, Docker i dalje može prijaviti potpuno zdrav proces. Deployment u nastavku organiziran je oko ponašanja koje se može promatrati: izradite short URL putem API-ja, slijedite njegov redirect, zabilježite posjete i pregledajte statistiku iz web-klijenta.

Namjena Shlinka jasno je definirana: link shortener s API-first pristupom i statistikama. Taj opis govori što mora ostati javno, što treba ostati privatno i što sigurnosna kopija mora moći rekonstruirati.

O čemu Shlink ovisi

Zdravlje procesa i zdravlje proizvoda dvije su odvojene stvari kod Shlinka. Port 8080 može odgovarati iako transakcija vidljiva korisniku i dalje ne uspijeva. Mrežni ugovor za Shlink čine Postgres ili MariaDB te opcionalni Redis za produkciju. Privatne endpointove zadržite na internom DNS-u, dopustite samo potrebne izlazne pozive i Shlinku dodijelite servisne vjerodajnice ograničenog opsega.

Ovu provjeru spremnosti koristite nakon značajnih promjena konfiguracije: izradite short URL putem API-ja, slijedite njegov redirect, zabilježite posjete i pregledajte statistiku iz web-klijenta. Skupocjene vanjske provjere nemojte uključivati u liveness probe kako prekid rada pružatelja usluge ne bi uzrokovao restart loop. Pri planiranju kapaciteta pratite propusnost redirecta, upise u bazu podataka, preuzimanja geolokacijskih podataka i ponašanje cachea jer to bolje odražava stvarno opterećenje Shlinka nego zahtjevi za stranicama.

Volumei su samo prvi sloj oporavka

Unutar standardne Shlink image ne očekuje se zapisivanje stanja aplikacije. Sačuvajte bazu podataka, API ključeve i sve uvezene podatke o posjetama, uključujući pinned digest i provjerenu konfiguraciju ruta, umjesto da sigurnosno kopirate prazan filesystem containera.

Izradite Shlink ispočetka na drugom hostu i provjerite vraćaju li se domene, short codeovi, tagovi i zapisi o posjetama te preusmjerava li svaki testirani short URL identično. Ako dodate zasebnu bazu podataka, room server ili authentication layer, toj komponenti dodijelite vlastitog, jasno određenog vlasnika oporavka. Vodič od Git repozitorija do produkcije pokazuje kako reproducibilni artifact zamjenjuje backup containera.

Uz release zabilježite naredbu za ponovnu izgradnju i test očekivanog izlaza. Stateless plan oporavka uspješan je kada reproducira ponašanje iz pouzdanih ulaza; ne smije ovisiti o kopiranju neprozirnog pokrenutog containera.

Zaštitite ono što je vrijedno u Shlinku

Siguran deployment Shlinka počinje uklanjanjem ovlasti. Izbjegavajte izlaganje REST API ključa ili promjenu javne domene nakon objave linkova; umjesto toga API ključeve držite izvan browser koda, koristite HTTPS i ograničite administraciju, a redirecte ostavite javnima.

DEFAULT_DOMAIN je konfiguracija, a ne tajna; njegovu vrijednost držite eksplicitnom, a zasebne vjerodajnice koje koristi Shlink zaštitite. Ograničite administrativne rute, za dependencyje koristite privatni DNS i pregledajte svaki bind mount. Kada se logovi šalju u centralni sustav, filtrirajte tajne i privatni sadržaj prije nego napuste server.

Pretvorite smoke test Shlinka u provjeru za release

Za Shlink prije pokretanja definirajte transakciju za koju znate da radi: izradite short URL putem API-ja, slijedite njegov redirect, zabilježite posjete i pregledajte statistiku iz web-klijenta. Preduvjete, očekivani response i korake čišćenja držite u version controlu, bez vrijednosti tajni. Pinajte image koji se koristi za uspostavljanje te reference.

Transakciju koristite za validaciju zamjene i neovisnog restorea. Restored servis prihvatljiv je samo kada se vrate domene, short codeovi, tagovi i zapisi o posjetama te svaki testirani short URL preusmjerava identično. Istodobno promatrajte propusnost redirecta, upise u bazu podataka, preuzimanja geolokacijskih podataka i ponašanje cachea te najsporiji ili najograničeniji dio pretvorite u service-level alert.

Gate mora imati i negativan slučaj: privremeno uskratite testnom identitetu pristup Postgresu ili MariaDB-u te opcionalnom Redisu za produkciju. Potvrdite da Shlink generira korisnu poruku o pogrešci uz očuvanje podataka, vratite valjano stanje i ponovite transakciju za koju znate da radi. Čuvanje oba rezultata sprječava da površan health endpoint postane jedini produkcijski dokaz.

Pokrenite Shlink bez skrivanja pokretnih dijelova

Sljedeća naredba čini granicu containera vidljivom, bez pretvaranja da osigurava svaki vanjski servis.

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

Prije otvaranja ingressiona pregledajte resolved environment, mountove i listener. Dodajte provjerene postavke konekcije za Postgres ili MariaDB te opcionalni Redis za produkciju; za privatne servise koristite privatna imena. Uspješan launch završava tek kada možete izraditi short URL putem API-ja, slijediti njegov redirect, zabilježiti posjete i pregledati statistiku iz web-klijenta, a ne kada docker ps ispiše Up.

Dodijelite Shlinku jednu kanonsku adresu

Javna granica Shlinka trebala bi biti jedan kanonski hostname, automatski TLS i jedan interni target na portu 8080. Postavite DEFAULT_DOMAIN i IS_HTTPS_ENABLED prije izrade short URL-ova kako bi klijenti vraćali adresu koju servis prepoznaje.

Ako acceptance transakcija ne uspije, klasificirajte prvu pogrešku. Problemi s DNS-om, certifikatom i 502 pripadaju checklisti za provjeru TLS-a. Uvjet „generirani linkovi koriste HTTP ili migracije ne mogu dosegnuti bazu podataka” pripada aplikacijskoj strani nakon što je zahtjev uspješno stigao do Shlinka.

Otklanjanje problema sa Shlinkom koji izgleda zdravo

Kod Shlinka pratite transakciju, a ne proces: izradite short URL putem API-ja, slijedite njegov redirect, zabilježite posjete i pregledajte statistiku iz web-klijenta. Njegovu latenciju i stopu pogrešaka kombinirajte s propusnošću redirecta, upisima u bazu podataka, preuzimanjima geolokacijskih podataka i ponašanjem cachea kako bi alert identificirao ograničenu komponentu.

Rehearsal nadogradnje mora obuhvatiti činjenicu da migracije baze podataka i kompatibilnost API-ja treba provoditi postupno jer objavljeni short linkovi ne mogu čekati ručni popravak. Prije zamjene u produkciji napravite restore, provedite migraciju i pokrenite transakciju. Ako generirani linkovi koriste HTTP ili migracije ne mogu dosegnuti bazu podataka, nemojte brisati podatke kako biste pozivanje pokretanja učinili uspješnim; tim redoslijedom usporedite verziju, varijable, mountove i dostupnost dependencyja.

Neka Shlink bude eksplicitan dok Dockup upravlja routingom

One-click deployment Shlinka na Dockupu trebao bi učiniti zamjenu sigurnom: ruta i dalje pokazuje na port 8080, tajne nisu ugrađene u image, a trajne putanje vraćaju se u novi container. Isti deployment može raditi na Dockup computeu ili priključenom stroju.

Dovršite rad specifičan za aplikaciju povezivanjem i testiranjem Postgresa ili MariaDB-a te opcionalnog Redisa za produkciju, primjenom kanonske javne adrese i pokretanjem ove acceptance provjere: izradite short URL putem API-ja, slijedite njegov redirect, zabilježite posjete i pregledajte statistiku iz web-klijenta. Rezultat restorea dodajte u runbook prije dolaska stvarnih korisnika.

Često postavljana pitanja

Što je Shlinku potrebno za produkcijski deployment?

Usmjerite Shlink container na portu 8080 kroz jedan HTTPS origin. Prateći mrežni zahtjev čine Postgres ili MariaDB te opcionalni Redis za produkciju. Nemojte smatrati Shlink spremnim dok ne možete izraditi short URL putem API-ja, slijediti njegov redirect, zabilježiti posjete i pregledati statistiku iz web-klijenta.

Koji Shlinkovi podaci pripadaju sigurnosnoj kopiji?

Standardna Shlink image nema obavezan mount za podatke aplikacije. Sačuvajte konfiguraciju deploymenta i zasebno sigurnosno kopirajte svako povezano stanje; oporavak je uspješan kada se vrate domene, short codeovi, tagovi i zapisi o posjetama te svaki testirani short URL preusmjerava identično.

Zahtijeva li Shlink HTTPS iza reverse proxya?

Za javni Shlink origin koristite HTTPS, a port 8080 zadržite na internoj ruti. Ispravno primijenite Shlinkovu postavku: postavite DEFAULT_DOMAIN i IS_HTTPS_ENABLED prije izrade short URL-ova. Kod Shlinka HTTPS štiti vjerodajnice ili korisnički sadržaj tijekom prijenosa i osigurava dosljedno ponašanje klijenta osjetljivo na origin.

Kako testirati nadogradnju Shlinka?

Vratite trenutno stanje Shlinka u izolirani deployment, primijenite kandidatsku verziju i ponovite njegovu acceptance transakciju. Obratite posebnu pozornost jer migracije baze podataka i kompatibilnost API-ja treba provoditi postupno jer objavljeni short linkovi ne mogu čekati ručni popravak. Prethodnu Shlink image zadržite dok ne razumijete granice migracije podataka i rollbacka.