A Shiori saját üzemeltetése 2026-ban: archívumok, fiókok és tartós tárolás

Egy hibás Shiori-deployment nem feltétlenül áll le. Előfordulhat, hogy a bejelentkezési oldalt kiszolgálja, miközben az archiválás meghiúsul, mert a Chromium-függőségek vagy a fájlrendszer jogosultságai hibásak. Ehelyett kezdj end-to-end ellenőrzéssel: ments el egy könyvjelzőt archivált tartalommal, keress rá, módosítsd a tageket, majd ellenőrizd, hogy az archívum akkor is elérhető marad-e, amikor a forrásoldal megváltozik.

Ez az ellenőrzés megfelel a Shiori dokumentált céljának: olyan bookmark manager, amely archiválja az oldalak tartalmát. Emellett hamarabb feltárja a hiányzó függőségeket, a hibás proxy-feltételezéseket és az ephemeral adatokat, mint egy uptime probe.

A Shiori runtime-határainak kijelölése

A process health és a product health különválik a Shiori esetében. A 8080-as port válaszolhat úgy is, hogy a felhasználói tranzakció még mindig sikertelen. A Shiori külső követelménye egy írható data volume, valamint a hozzáférés az archiválandó oldalakhoz. Teszteld a kimenő DNS-t, a TLS-t és a provider működését anélkül, hogy újabb bejövő service-t publikálnál.

Használd ezt a readiness-ellenőrzést minden jelentős konfigurációmódosítás után: ments el egy könyvjelzőt archivált tartalommal, keress rá, módosítsd a tageket, majd ellenőrizd, hogy az archívum akkor is elérhető marad-e, amikor a forrásoldal megváltozik. Az expensive external checkeket hagyd ki a liveness probe-okból, hogy egy provider kiesése ne okozzon restart loopot. A kapacitástervezés során kövesd a browser-based page capture, az archívum mérete, a thumbnailök és a kimenő lekérések erőforrásigényét, mert ezek közelebb állnak a Shiori tényleges terheléséhez, mint az oldallekérések.

A Shiori visszaállítása üres hoston

Még az első valódi rekord létrehozása előtt listázd az állapotot: adatbázis, archivált oldaltartalom, thumbnailök és konfiguráció. A bootstrap előtt mountold a /shiori útvonalat, írj bele ártalmatlan mintaadatokat, majd cseréld le a containert annak bizonyítására, hogy az adott útvonal valóban persistent. Erősítsd meg a mountot ártalmatlan adatok írásával, a Shiori lecserélésével és az adatok visszaolvasásával.

A snapshotok hasznosak a gyors rollbackhez, de külön backupra is szükség van, ha a host vagy a volume eltűnik. Állítsd vissza az adatokat egy üres környezetbe a rögzített image használatával, majd ellenőrizd, hogy a könyvjelzők, a tagek, az archívumfájlok és a fiókok visszatérnek-e, illetve hogy egy már nem elérhető forráslink továbbra is megnyitja-e a mentett tartalmat. Használd a persistent volume-okat és snapshotokat, hogy a két recovery-mechanizmus elkülönüljön.

A Shiorihoz kapcsolódó biztonsági döntések

Az alkalmazásspecifikus biztonsági kockázat az, ha a kezdeti fiók változatlanul marad egy publikus instance-on. Az operatív megoldás a kezdeti fiók lecserélése, a publikus megosztás korlátozása, valamint annak kezelése, hogy az archivált privát URL-ek érzékeny tartalomnak minősülnek. A bootstrapet korlátozott route-on fejezd be, majd azonnal távolítsd el az ideiglenes setup-hozzáférést.

A SHIORI_DIR a működést, nem pedig a bizalmasságot szabályozza; ellenőrizd a típusát és az értékét, a valódi Shiori-credentialöket pedig külön tárold. A Shiori process csak a dokumentált mountokhoz és dependency route-okhoz férjen hozzá; kerüld a host root- és a Docker socket-hozzáférést. Naplózd a sikertelen hitelesítési kísérleteket és a konfigurációs hibákat, de redaktáld a tokeneket, a connection stringeket és a felhasználói tartalmat.

Production acceptance run a Shiorihoz

A Shiori release candidate-je akkor kaphat forgalmat, ha teljesít egy rögzített forgatókönyvet: ments el egy könyvjelzőt archivált tartalommal, keress rá, módosítsd a tageket, majd ellenőrizd, hogy az archívum akkor is elérhető marad-e, amikor a forrásoldal megváltozik. Rögzítsd ehhez a forgatókönyvhöz az image digestjét, a tényleges, nem titkos konfigurációt, a publikus origint és az időbélyegeket. A tesztadatok legyenek törölhetők, de legyenek elég életszerűek ahhoz, hogy ugyanazt az útvonalat járják be, mint a felhasználói műveletek.

Futtasd le ezt a runtime lecserélése után, majd építsd újra a service-t az adatbázisból, az archivált oldaltartalomból, a thumbnailökből és a konfigurációból. A recovery akkor sikeres, ha a könyvjelzők, a tagek, az archívumfájlok és a fiókok visszatérnek, és egy már nem elérhető forráslink továbbra is megnyitja a mentett tartalmat. Hasonlítsd össze a browser-based page capture, az archívum mérete, a thumbnailök és a kimenő lekérések erőforrásméréseit az előző release értékeivel, és a promotion előtt vizsgáld ki a jelentős eltéréseket.

Végül hajtsd végre ezt a kontrollált hibatesztet: ideiglenesen tiltsd le az írható data volume által használt tesztútvonalat és az archiválandó oldalakhoz szükséges kimenő hozzáférést. Ellenőrizd, hogy a Shiori érthetően jelzi a hibát, nem károsítja a meglévő állapotot, és a helyes feltétel visszaállásakor folytatja a működést. Ments el egy redaktált logrészletet és a helyreállítási időt. Ezek az ellenőrzések együtt a viselkedést, a tartósságot és az üzemeltethetőséget fedik le, nem csupán a process uptime-ját.

A Shiori indítása megfigyelhető alapbeállításokkal

Tartsd a kezdeti Shiori-indítást annyira reprodukálhatónak, hogy pull requestben is felülvizsgálható legyen.

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

Valódi adatok megjelenése után ne hagyatkozz a latest tagre. Rögzítsd a működő digestet, a container usert és a mount tulajdonosát. Kövesd végig az alkalmazás logját egy teljes teszt során — ments el egy könyvjelzőt archivált tartalommal, keress rá, módosítsd a tageket, majd ellenőrizd, hogy az archívum akkor is elérhető marad-e, amikor a forrásoldal megváltozik —, és jegyezd fel az esetleges migrationöket, mielőtt a route production forgalmat kap.

Domainek, proxy headerek és a 8080-as port

Kezeld a külső Shiori-URL-t olyan konfigurációként, amely redeploy után is megmarad. Először egy stabil HTTPS originen keresztül route-old az UI-t és az API-t, majd irányítsd a hostnevet a 8080-as portra úgy, hogy az eredeti host és scheme változatlan maradjon.

A deployment reachability checklist bizonyíthatja, hogy a kérések belépnek a containerbe. Ezt követően a jól ismert hibát — az archiválás meghiúsul, mert a Chromium-függőségek vagy a fájlrendszer jogosultságai hibásak — a Shioriban, annak állapotában vagy workloadjában kell vizsgálni, nem pedig a certificate automationben.

A Shiori frissítése találgatás nélkül

A Shiori első hasznos operatív metrikája az, hogy képes-e elmenteni egy könyvjelzőt archivált tartalommal, rákeresni, módosítani a tageket, majd ellenőrizni, hogy az archívum akkor is elérhető marad, amikor a forrásoldal megváltozik. Ezt egészítsd ki a browser-based page capture, az archívum mérete, a thumbnailök és a kimenő lekérések saturation signaljaival. Egy kizárólag a processzt ellenőrző probe ne hívjon drága függőségeket, és ne indítsa újra a containert azért, mert egy upstream rövid időre elérhetetlenné vált.

Kezeld a frissítéseket adatváltozásként, mert a Shiori adatbázis-migrationjei és a page-capture függőségei módosíthatják az archiválás működését. Pineld a verziókat, gyakorold a folyamatot visszaállított állapoton, és tartsd elérhetően az előző image-et mindaddig, amíg a rollback érvényes marad. Ha az archiválás azért hiúsul meg, mert a Chromium-függőségek vagy a fájlrendszer jogosultságai hibásak, őrizd meg az újraindítás előtti logokat; ezek általában tartalmazzák a kiváltó hibaüzenetet.

Mit automatizáljon a Dockup a Shiorihoz?

A Shiori platformrétege a 8080-as portból, az ingressből, a TLS-ből, a runtime-konfigurációból, a storage-ból és a dependency reachabilityből áll. A Dockup ezeket a részeket reprodukálhatja a saját infrastruktúrájához vagy egy ügyfél által csatlakoztatott serverhez.

Ezután az üzemeltető befejezi a product layert: route-old az UI-t és az API-t stabil HTTPS originen keresztül; érvényesítsd ezt a hozzáférési szabályt — cseréld le a kezdeti fiókot, korlátozd a publikus megosztást, és kezeld az archivált privát URL-eket érzékeny tartalomként —; majd futtasd le a következőt: „ments el egy könyvjelzőt archivált tartalommal, keress rá, módosítsd a tageket, majd ellenőrizd, hogy az archívum akkor is elérhető marad-e, amikor a forrásoldal megváltozik”. Ha ezt a tesztet a deployment mellett rögzíted, nem kevered össze az automatizált provisioninget az alkalmazás readinessével.

Gyakran ismételt kérdések

Mire van szüksége a Shiorinak production deployment esetén?

Route-old a Shiori containert a 8080-as porton keresztül egyetlen HTTPS originen át. A külső kiszolgálás követelménye egy írható data volume és a hozzáférés az archiválandó oldalakhoz. Ne tekintsd késznek a Shiorit addig, amíg el nem tudsz menteni egy könyvjelzőt archivált tartalommal, rá nem tudsz keresni, nem tudod módosítani a tageket, és nem tudod ellenőrizni, hogy az archívum a forrásoldal megváltozása után is elérhető marad.

Mely Shiori-adatok kerüljenek backupba?

Tartsd persistent állapotban a /shiori útvonalat, és vedd fel az adatbázist, az archivált oldaltartalmat, a thumbnailöket és a konfigurációt ugyanabba a recovery manifestbe. A tiszta Shiori-restore csak akkor sikeres, ha a könyvjelzők, a tagek, az archívumfájlok és a fiókok visszatérnek, és egy már nem elérhető forráslink továbbra is megnyitja a mentett tartalmat.

Szüksége van a Shiorinak HTTPS-re reverse proxy mögött?

Használj HTTPS-t a publikus Shiori-originhez, a 8080-as portot pedig tartsd meg a belső route-on. Alkalmazd helyesen a Shiori-beállítást: route-old az UI-t és az API-t stabil HTTPS originen keresztül. A Shiori esetében a HTTPS védi a credentialöket és a felhasználói tartalmat az átvitel során, valamint egységesen kezeli az originfüggő kliensviselkedést.

Hogyan kell tesztelni egy Shiori-frissítést?

Állítsd vissza az aktuális Shiori-állapotot egy izolált deploymentbe, alkalmazd a candidate verziót, majd ismételd meg az acceptance tranzakciót. Különösen figyelj erre, mert a Shiori adatbázis-migrationjei és a page-capture függőségei módosíthatják az archiválás működését. Tartsd meg az előző Shiori image-et addig, amíg nem tisztázott az adatmigration és a rollback határa.