Så självhostar du Shiori 2026: arkiv, konton och persistent lagring
En praktisk guide till att självhosta Shiori med Docker, portar, persistent data, TLS, säkerhet, säkerhetskopior och de problem som hindrar produktionsanvändning. Steg för steg.
En misslyckad Shiori-deployment kraschar inte alltid. Den kan visa en inloggningssida samtidigt som arkivering misslyckas eftersom Chromium-beroenden eller filsystemsbehörigheter är felaktiga. Börja i stället med en end-to-end-kontroll: spara ett bokmärke med arkiverat innehåll, sök efter det, redigera taggarna och verifiera att arkivet fortfarande är tillgängligt efter att källsidan har ändrats.
Den kontrollen motsvarar Shioris dokumenterade syfte: en bokmärkeshanterare som arkiverar sidinnehåll. Den avslöjar också saknade beroenden, felaktiga proxyantaganden och ephemeral data tidigare än vad en uptime-probe kan göra.
Avgränsa Shioris runtime
Processhälsa och produkthälsa är två separata saker i Shiori. Port 8080 kan svara samtidigt som den användarvända transaktionen fortfarande misslyckas. Det externa kravet för Shiori är en skrivbar datavolym och utgående åtkomst till sidor som ska arkiveras. Testa utgående DNS, TLS och leverantörens beteende utan att publicera ytterligare en inkommande tjänst.
Använd denna readiness-kontroll efter betydande konfigurationsändringar: spara ett bokmärke med arkiverat innehåll, sök efter det, redigera taggarna och verifiera att arkivet fortfarande är tillgängligt efter att källsidan har ändrats. Håll kostsamma externa kontroller utanför liveness-prober så att ett avbrott hos en leverantör inte orsakar en restart loop. Kapacitetsarbetet bör följa upp webbläsarbaserad sidinfångning, arkivstorlek, thumbnails och utgående hämtningar, eftersom det bättre speglar Shioris faktiska belastning än sidförfrågningar.
Återställ Shiori på en tom host
Lista tillståndet innan den första riktiga posten skapas: databas, arkiverat sidinnehåll, thumbnails och konfiguration. Montera /shiori före bootstrap, skriv ofarliga exempeldata och ersätt containern för att bevisa att sökvägen faktiskt är persistent. Bekräfta monteringen genom att skriva ofarliga data, ersätta Shiori och läsa tillbaka dem.
Snapshots är värdefulla för snabb rollback, men en fristående säkerhetskopia behövs om hosten eller volymen försvinner. Återställ till en tom miljö med den pinnade imagen och verifiera att bokmärken, taggar, arkivfiler och konton återkommer samt att en död källänk fortfarande öppnar det sparade innehållet. Använd persistenta volymer och snapshots för att hålla dessa två återställningsmekanismer åtskilda.
Säkerhetsbeslut som är specifika för Shiori
Den applikationsspecifika säkerhetsrisken är att behålla det ursprungliga kontot på en publik instans. Det operativa svaret är att byta ut det ursprungliga kontot, begränsa publik delning och behandla arkiverade privata URL:er som känsligt innehåll. Slutför bootstrap via en begränsad route och ta omedelbart bort tillfällig setup-åtkomst efteråt.
SHIORI_DIR styr beteendet snarare än konfidentialiteten; validera dess typ och värde och lagra riktiga Shiori-uppgifter separat. Ge Shiori-processen endast dess dokumenterade mounts och dependency routes; undvik åtkomst till hostens root och Docker socket. Logga misslyckade autentiseringsförsök och konfigurationsfel, men maskera tokens, connection strings och användarinnehåll.
Ett produktionsgodkännandetest för Shiori
En releasekandidat för Shiori förtjänar trafik genom att slutföra ett fast scenario: spara ett bokmärke med arkiverat innehåll, sök efter det, redigera taggarna och verifiera att arkivet fortfarande är tillgängligt efter att källsidan har ändrats. Dokumentera image digest, effektiv icke-hemlig konfiguration, publik origin och tidsstämplar för scenariot. Testdata ska kunna kasseras men vara tillräckligt realistiska för att använda samma flöde som användarna.
Kör testet efter att runtime har ersatts och bygg sedan om tjänsten från databas, arkiverat sidinnehåll, thumbnails och konfiguration. Återställningen är godkänd när bokmärken, taggar, arkivfiler och konton återkommer samt när en död källänk fortfarande öppnar det sparade innehållet. Jämför resursmätningar för webbläsarbaserad sidinfångning, arkivstorlek, thumbnails och utgående hämtningar med föregående release och utred betydande avvikelser före promotion.
Testa slutligen detta kontrollerade fel: neka tillfälligt den testväg som används av en skrivbar datavolym och utgående åtkomst till sidor som ska arkiveras. Verifiera att Shiori förklarar felet, inte skadar befintligt tillstånd och återupptar arbetet när det korrekta tillståndet återkommer. Spara ett maskerat loggutdrag och återställningstiden. Tillsammans täcker dessa kontroller beteende, hållbarhet och driftbarhet – inte bara processens uptime.
Starta Shiori med observerbara standardvärden
Se till att den initiala Shiori-starten är tillräckligt reproducerbar för att kunna granskas i en pull request.
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
Förlita dig inte på latest när riktiga data har skapats. Dokumentera den fungerande digest-en, containeranvändaren och mount-ägarskapet. Följ applikationsloggen genom ett komplett test – spara ett bokmärke med arkiverat innehåll, sök efter det, redigera taggarna och verifiera att arkivet fortfarande är tillgängligt efter att källsidan har ändrats – och notera eventuella migreringar innan routen placeras bakom produktionstrafik.
Domäner, proxyheaders och port 8080
Behandla Shioris externa URL som konfiguration som ska överleva redeployments. Dirigera först UI och API via en stabil HTTPS-origin och dirigera sedan hostname till port 8080 med ursprunglig host och scheme intakta.
Checklistan för deployment-reachability kan bevisa att requests når containern. Därefter ska det kända felet – att arkivering misslyckas eftersom Chromium-beroenden eller filsystemsbehörigheter är felaktiga – utredas i Shiori, dess tillstånd eller dess workload, inte i certifikatautomatiseringen.
Uppgradera Shiori utan att gissa
Det första användbara operativa måttet för Shiori är om tjänsten kan spara ett bokmärke med arkiverat innehåll, söka efter det, redigera taggarna och verifiera att arkivet fortfarande är tillgängligt efter att källsidan har ändrats. Kombinera det med saturation-signaler för webbläsarbaserad sidinfångning, arkivstorlek, thumbnails och utgående hämtningar. En probe som bara kontrollerar processen bör inte anropa kostsamma beroenden eller starta om containern för att en upstream-tjänst tillfälligt är otillgänglig.
Behandla uppgraderingar som dataändringar eftersom Shioris databas-migreringar och sidinfångningsberoenden kan ändra arkivbeteendet. Pinna versioner, öva på återställt tillstånd och behåll den tidigare imagen till dess att en rollback fortfarande är giltig. När arkivering misslyckas eftersom Chromium-beroenden eller filsystemsbehörigheter är felaktiga ska du spara loggarna från före omstarten; de innehåller vanligtvis det orsakande felmeddelandet.
Vad Dockup bör automatisera för Shiori
Plattformslagret för Shiori består av port 8080, ingress, TLS, runtime-konfiguration, lagring och dependency reachability. Dockup kan återskapa dessa delar för sin egen infrastruktur eller för en server som kunden ansluter.
Därefter slutför operatören produktlagret: dirigera UI och API via en stabil HTTPS-origin; tillämpa denna åtkomstregel – byt ut det ursprungliga kontot, begränsa publik delning och behandla arkiverade privata URL:er som känsligt innehåll – och kör ”spara ett bokmärke med arkiverat innehåll, sök efter det, redigera taggarna och verifiera att arkivet fortfarande är tillgängligt efter att källsidan har ändrats”. Genom att dokumentera testet tillsammans med deploymenten undviker man att blanda ihop automatiserad provisioning med applikationens readiness.
Vanliga frågor
Vad behöver Shiori för en produktionsdeployment?
Dirigera Shiori-containern på port 8080 via en enda HTTPS-origin. Det externa leveranskravet är en skrivbar datavolym och utgående åtkomst till sidor som ska arkiveras. Förklara inte Shiori som redo förrän du kan spara ett bokmärke med arkiverat innehåll, söka efter det, redigera taggarna och verifiera att arkivet fortfarande är tillgängligt efter att källsidan har ändrats.
Vilka Shiori-data ska ingå i en säkerhetskopia?
Persist the /shiori och inkludera databas, arkiverat sidinnehåll, thumbnails och konfiguration i samma återställningsmanifest. En ren Shiori-återställning är godkänd först när bokmärken, taggar, arkivfiler och konton återkommer samt när en död källänk fortfarande öppnar det sparade innehållet.
Kräver Shiori HTTPS bakom en reverse proxy?
Använd HTTPS för den publika Shiori-originen och behåll port 8080 på den interna routen. Tillämpa Shiori-inställningen korrekt: dirigera UI och API via en stabil HTTPS-origin. För Shiori skyddar HTTPS autentiseringsuppgifter och användarinnehåll under transport och gör klientbeteende som är känsligt för origin konsekvent.
Hur bör en Shiori-uppgradering testas?
Återställ det aktuella Shiori-tillståndet till en isolerad deployment, tillämpa kandidatversionen och upprepa dess godkännandetransaktion. Var särskilt uppmärksam eftersom Shioris databas-migreringar och sidinfångningsberoenden kan ändra arkivbeteendet. Behåll den tidigare Shiori-imagen tills gränserna för datamigrering och rollback är förstådda.