Kako samostalno hostati Shiori u 2026.: arhive, računi i trajna pohrana
Praktičan vodič za samostalno hostanje Shiorija koji obuhvaća Docker, portove, trajne podatke, TLS, sigurnost, sigurnosne kopije i probleme koji onemogućuju produkcijsku upotrebu. Korak po korak.
Neuspjela implementacija Shiorija ne mora uvijek uzrokovati rušenje. Može posluživati stranicu za prijavu dok arhiviranje ne uspijeva zato što Chromium dependencies ili dozvole datotečnog sustava nisu ispravno postavljene. Umjesto toga najprije provedite end-to-end provjeru: spremite bookmark s arhiviranim sadržajem, pretražite ga, uredite tagove i provjerite da je arhiva i dalje dostupna nakon što se izvorna stranica promijeni.
Ta provjera odgovara katalogiziranoj namjeni Shiorija: bookmark manageru koji arhivira sadržaj stranica. Osim toga, ranije otkriva nedostajuće dependencies, pogrešne pretpostavke o proxyju i efemerne podatke nego što to može učiniti uptime probe.
Odredite granice Shiori runtimea
Stanje procesa i stanje proizvoda dvije su odvojene stvari za Shiori. Port 8080 može odgovarati dok transakcija iz korisničke perspektive i dalje ne uspijeva. Vanjski zahtjev za Shiori je writable data volume i outbound access do arhiviranih stranica. Testirajte outbound DNS, TLS i ponašanje providera bez objavljivanja dodatnog inbound servisa.
Ovu provjeru spremnosti provedite nakon značajnih promjena konfiguracije: spremite bookmark s arhiviranim sadržajem, pretražite ga, uredite tagove i provjerite da je arhiva i dalje dostupna nakon što se izvorna stranica promijeni. Za liveness probes nemojte koristiti skupe vanjske provjere kako ispad providera ne bi uzrokovao restart loop. Pri planiranju kapaciteta pratite browser-based page capture, veličinu arhive, thumbnails i outbound fetching jer to bolje odražava stvarno opterećenje Shiorija nego zahtjevi za stranicama.
Vratite Shiori na prazan host
Prije stvaranja prvog stvarnog zapisa navedite stanje: bazu podataka, arhivirani sadržaj stranica, thumbnails i konfiguraciju. Mountajte /shiori prije bootstrapa, upišite bezopasne ogledne podatke i zamijenite container kako biste dokazali da je ta putanja doista trajna. Potvrdite mount upisivanjem bezopasnih podataka, zamijenite Shiori i ponovno ih pročitajte.
Snapshots su vrijedni za brzi rollback, ali potrebna je neovisna sigurnosna kopija kada host ili volume nestane. Vratite podatke u prazno okruženje s pinanom image verzijom i provjerite da se bookmarkovi, tagovi, arhivske datoteke i računi vraćaju te da se mrtva izvorna poveznica i dalje otvara sa spremljenim sadržajem. Upotrijebite persistent volumes and snapshots kako biste ta dva mehanizma oporavka zadržali odvojenima.
Sigurnosne odluke specifične za Shiori
Sigurnosni rizik specifičan za aplikaciju jest ostavljanje početnog računa nepromijenjenim na javnoj instanci. Operativni odgovor je zamijeniti početni račun, ograničiti javno dijeljenje i tretirati arhivirane privatne URL-ove kao osjetljiv sadržaj. Završite bootstrap putem ograničene rute i odmah nakon toga uklonite privremeni pristup za postavljanje.
SHIORI_DIR određuje ponašanje, a ne povjerljivost; provjerite njegov tip i vrijednost te stvarne Shiori credentials pohranite zasebno. Shiori procesu dodijelite samo dokumentirane mountove i dependency routes; izbjegavajte pristup rootu hosta i Docker socketu. Bilježite neuspjele autentikacije i pogreške konfiguracije, ali redigirajte tokene, connection stringove i korisnički sadržaj.
Produkcijska acceptance provjera za Shiori
Release candidate za Shiori zaslužuje promet tek kada dovrši fiksni scenarij: spremite bookmark s arhiviranim sadržajem, pretražite ga, uredite tagove i provjerite da je arhiva i dalje dostupna nakon što se izvorna stranica promijeni. Zabilježite image digest, efektivnu konfiguraciju bez tajni, javni origin i vremenske oznake za taj scenarij. Testni podaci trebaju biti privremeni, ali dovoljno realistični da prođu istom putanjom kojom se koriste korisnici.
Pokrenite ga nakon zamjene runtimea, a zatim ponovno izgradite servis iz baze podataka, arhiviranog sadržaja stranica, thumbnails i konfiguracije. Oporavak je uspješan kada se bookmarkovi, tagovi, arhivske datoteke i računi vrate te se mrtva izvorna poveznica i dalje otvara sa spremljenim sadržajem. Usporedite mjerenja resursa za browser-based page capture, veličinu arhive, thumbnails i outbound fetching s prethodnim releaseom te istražite značajna odstupanja prije promocije.
Na kraju provedite ovaj kontrolirani kvar: privremeno onemogućite testnu putanju koju koriste writable data volume i outbound access do arhiviranih stranica. Provjerite objašnjava li Shiori problem, oštećuje li postojeće stanje i nastavlja li s radom nakon što se valjani uvjet vrati. Spremite redigirani isječak loga i vrijeme oporavka. Zajedno, ove provjere obuhvaćaju ponašanje, trajnost i operativnost, a ne samo uptime procesa.
Pokrenite Shiori s promatranim zadanim postavkama
Početni poziv Shiorija neka bude dovoljno reproducibilan za pregled u pull requestu.
docker run -d \
--name shiori \
--restart unless-stopped \
-p 127.0.0.1:8080:8080 \
-v shiori-data:/shiori \
-e SHIORI_DIR=/shiori \
ghcr.io/go-shiori/shiori:latest
Nemojte se oslanjati na latest nakon što postoje stvarni podaci. Zabilježite radni digest, korisnika containera i vlasništvo nad mountovima. Pratite application log kroz potpunu provjeru — spremite bookmark s arhiviranim sadržajem, pretražite ga, uredite tagove i provjerite da je arhiva i dalje dostupna nakon što se izvorna stranica promijeni — te zabilježite sve migracije prije usmjeravanja rute prema produkcijskom prometu.
Domene, proxy headeri i port 8080
Vanjski Shiori URL tretirajte kao konfiguraciju koja preživljava redeploy. Najprije usmjerite UI i API kroz stabilan HTTPS origin, a zatim hostname usmjerite na port 8080 uz očuvanje izvornog hosta i sheme.
Deployment reachability checklist može dokazati da zahtjevi ulaze u container. Nakon toga poznati kvar — arhiviranje ne uspijeva zato što Chromium dependencies ili dozvole datotečnog sustava nisu ispravno postavljene — treba istražiti u Shioriju, njegovom stanju ili workloadu, a ne u automatizaciji certifikata.
Nadogradite Shiori bez nagađanja
Prva korisna operativna metrika za Shiori jest može li spremiti bookmark s arhiviranim sadržajem, pretražiti ga, urediti tagove i potvrditi da je arhiva i dalje dostupna nakon što se izvorna stranica promijeni. Uparite to sa signalima zasićenja za browser-based page capture, veličinu arhive, thumbnails i outbound fetching. Probe koja provjerava samo proces ne bi trebala pozivati skupe dependencies ni ponovno pokretati container zato što je upstream nakratko nedostupan.
Nadogradnje tretirajte kao promjene podataka jer Shiori database migrations i page-capture dependencies mogu promijeniti ponašanje arhive. Pinajte verzije, uvježbajte postupak na vraćenom stanju i zadržite prethodnu image verziju dostupnom dok rollback ne bude potvrđeno valjan. Kada arhiviranje ne uspijeva zato što Chromium dependencies ili dozvole datotečnog sustava nisu ispravno postavljene, sačuvajte logove nastale prije restarta; oni obično sadrže poruku koja objašnjava uzrok.
Što bi Dockup trebao automatizirati za Shiori
Platformski sloj za Shiori čine port 8080, ingress, TLS, runtime konfiguracija, storage i dependency reachability. Dockup te dijelove može reproducirati za vlastitu infrastrukturu ili server koji korisnik poveže.
Operater zatim dovršava produktni sloj: usmjerava UI i API kroz stabilan HTTPS origin; primjenjuje ovo pravilo pristupa — zamijeniti početni račun, ograničiti javno dijeljenje i tretirati arhivirane privatne URL-ove kao osjetljiv sadržaj; te pokreće „spremi bookmark s arhiviranim sadržajem, pretraži ga, uredi tagove i provjeri da je arhiva i dalje dostupna nakon što se izvorna stranica promijeni”. Bilježenje tog testa uz deployment sprječava miješanje automatiziranog provisioninga sa spremnošću aplikacije.
Često postavljana pitanja
Što je Shioriju potrebno za produkcijsku implementaciju?
Usmjerite Shiori container na portu 8080 kroz jedan HTTPS origin. Vanjski zahtjev za isporuku jest writable data volume i outbound access do arhiviranih stranica. Nemojte Shiori smatrati spremnim dok ne možete spremiti bookmark s arhiviranim sadržajem, pretražiti ga, urediti tagove i provjeriti da je arhiva i dalje dostupna nakon što se izvorna stranica promijeni.
Koji Shiori podaci pripadaju sigurnosnoj kopiji?
Ustrajno pohranite /shiori i uključite bazu podataka, arhivirani sadržaj stranica, thumbnails i konfiguraciju u isti recovery manifest. Uspješni Shiori restore moguć je tek kada se vrate bookmarkovi, tagovi, arhivske datoteke i računi te se mrtva izvorna poveznica i dalje otvara sa spremljenim sadržajem.
Zahtijeva li Shiori HTTPS iza reverse proxyja?
Za javni Shiori origin koristite HTTPS, a port 8080 zadržite na internoj ruti. Ispravno primijenite Shiori postavku: usmjerite UI i API kroz stabilan HTTPS origin. Za Shiori HTTPS štiti credentials ili korisnički sadržaj tijekom prijenosa i održava dosljedno ponašanje klijenta ovisno o originu.
Kako treba testirati nadogradnju Shiorija?
Vratite trenutačno Shiori stanje u izolirani deployment, primijenite kandidatsku verziju i ponovite acceptance transakciju. Obratite posebnu pozornost jer Shiori database migrations i page-capture dependencies mogu promijeniti ponašanje arhive. Zadržite prethodnu Shiori image verziju dok ne budete razumjeli granice migracije podataka i rollbacka.