JournalindeksDockup / feltnotat
Note / self-host-shiori

Slik selvhoster du Shiori i 2026: arkiver, kontoer og persistent lagring

En praktisk veiledning til selvhosting av Shiori med Docker, porter, persistent data, TLS, sikkerhet, sikkerhetskopier og feilene som hindrer produksjonsbruk. Steg for steg.

En mislykket Shiori-deployment krasjer ikke alltid. Den kan vise en påloggingsside selv om arkivering mislykkes fordi Chromium-avhengigheter eller filsystemtillatelser er feil. Start heller med en ende-til-ende-sjekk: lagre et bokmerke med arkivert innhold, søk etter det, rediger tagger og bekreft at arkivet fortsatt er tilgjengelig etter at kildesiden er endret.

Denne sjekken samsvarer med det katalogiserte formålet til Shiori: en bokmerkehåndterer som arkiverer sideinnhold. Den avdekker også manglende avhengigheter, feil antakelser om proxyen og ephemeral data tidligere enn en ren uptime-sjekk kan.

Tegn grensen for Shioris runtime

Prosesshelse og produkthelse er separate ting for Shiori. Port 8080 kan svare selv om den brukerrettede transaksjonen fortsatt mislykkes. Det eksterne kravet for Shiori er et skrivbart datavolum og utgående tilgang til sider som skal arkiveres. Test utgående DNS, TLS og leverandørens oppførsel uten å eksponere en ny innkommende tjeneste.

Bruk denne readiness-øvelsen etter vesentlige konfigurasjonsendringer: lagre et bokmerke med arkivert innhold, søk etter det, rediger tagger og bekreft at arkivet fortsatt er tilgjengelig etter at kildesiden er endret. Hold kostbare eksterne sjekker utenfor liveness-prober, slik at et leverandørutfall ikke fører til en restart-loop. Kapasitetsarbeidet bør følge med på nettleserbasert sidefangst, arkivstørrelse, miniatyrbilder og utgående henting, som ligger nærmere Shioris reelle belastning enn sideforespørsler gjør.

Gjenopprett Shiori på en tom vert

Kartlegg tilstanden før den første reelle posten opprettes: database, arkivert sideinnhold, miniatyrbilder og konfigurasjon. Monter /shiori før bootstrap, skriv ufarlige eksempeldata og erstatt containeren for å bevise at banen faktisk er persistent. Bekreft monteringen ved å skrive ufarlige data, erstatte Shiori og lese dataene tilbake.

Snapshots er nyttige for rask rollback, men du trenger en uavhengig sikkerhetskopi hvis verten eller volumet forsvinner. Gjenopprett til et tomt miljø med det pinnede imaget, og bekreft at bokmerker, tagger, arkivfiler og kontoer kommer tilbake, og at en død kildelenke fortsatt åpner det lagrede innholdet. Bruk persistente volumer og snapshots for å holde disse to gjenopprettingsmekanismene adskilt.

Sikkerhetsvalg som gjelder spesielt for Shiori

Den applikasjonsspesifikke sikkerhetsrisikoen er å la den opprinnelige kontoen stå uendret på en offentlig instans. Det operative svaret er å bytte ut den opprinnelige kontoen, begrense offentlig deling og behandle arkiverte private URL-er som sensitivt innhold. Fullfør bootstrap via en begrenset rute, og fjern midlertidig oppsettstilgang umiddelbart etterpå.

SHIORI_DIR styrer oppførsel, ikke konfidensialitet; valider typen og verdien, og lagre ekte Shiori-legitimasjon separat. Gi Shiori-prosessen bare de dokumenterte monteringene og avhengighetsrutene; unngå tilgang til vertens root og Docker-socket. Logg mislykkede autentiseringsforsøk og konfigurasjonsfeil, men rediger bort tokens, connection strings og brukerinnhold.

En produksjonsgodkjenningstest for Shiori

En releasekandidat for Shiori fortjener trafikk ved å fullføre et fast scenario: lagre et bokmerke med arkivert innhold, søk etter det, rediger tagger og bekreft at arkivet fortsatt er tilgjengelig etter at kildesiden er endret. Registrer image-digest, effektiv ikke-hemmelig konfigurasjon, offentlig origin og tidsstempler for dette scenarioet. Testdataene bør kunne slettes, men samtidig være realistiske nok til å teste den samme banen som brukerne benytter.

Kjør testen etter at runtime-miljøet er erstattet, og bygg deretter tjenesten på nytt fra database, arkivert sideinnhold, miniatyrbilder og konfigurasjon. Gjenoppretting er vellykket når bokmerker, tagger, arkivfiler og kontoer kommer tilbake, og en død kildelenke fortsatt åpner det lagrede innholdet. Sammenlign ressursmålinger for nettleserbasert sidefangst, arkivstørrelse, miniatyrbilder og utgående henting med forrige release, og undersøk vesentlige avvik før utrulling.

Til slutt tester du denne kontrollerte feilen: nekt midlertidig testen tilgang til banen som brukes av et skrivbart datavolum, og til utgående tilgang til sider som skal arkiveres. Bekreft at Shiori forklarer feilen, ikke skader eksisterende tilstand og gjenopptar driften når den gyldige betingelsen er tilbake. Lagre et redigert loggutdrag og gjenopprettingstiden. Til sammen dekker disse sjekkene oppførsel, datavarighet og driftbarhet, ikke bare prosessens uptime.

Start Shiori med observerbare standarder

Hold den innledende Shiori-invokeringen tilstrekkelig reproduserbar til at den kan gjennomgås 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

Ikke stol på latest etter at ekte data finnes. Registrer det fungerende digest-et, container-brukeren og eierskapet til monteringen. Følg applikasjonsloggen gjennom en fullstendig test — lagre et bokmerke med arkivert innhold, søk etter det, rediger tagger og bekreft at arkivet fortsatt er tilgjengelig etter at kildesiden er endret — og noter eventuelle migreringer før du legger ruten bak produksjonstrafikk.

Domener, proxy-headere og port 8080

Behandle den eksterne Shiori-URL-en som konfigurasjon som skal overleve redeployments. Først ruter du brukergrensesnittet og API-et via en stabil HTTPS-origin; deretter ruter du hostname-et til port 8080 med opprinnelig host og scheme intakt.

Kontrollisten for deployment-rekkevidde kan bevise at forespørsler kommer inn i containeren. Etter dette bør den kjente feilen — at arkivering mislykkes fordi Chromium-avhengigheter eller filsystemtillatelser er feil — undersøkes i Shiori, tilstanden eller arbeidsbelastningen, ikke i sertifikatautomatiseringen.

Oppgrader Shiori uten gjetting

Den første nyttige driftsmålingen for Shiori er om den kan lagre et bokmerke med arkivert innhold, søke etter det, redigere tagger og bekrefte at arkivet fortsatt er tilgjengelig etter at kildesiden er endret. Kombiner dette med metningssignaler for nettleserbasert sidefangst, arkivstørrelse, miniatyrbilder og utgående henting. En probe som bare sjekker prosessen, bør ikke kalle kostbare avhengigheter eller restarte containeren fordi en upstream-tjeneste er utilgjengelig en kort stund.

Behandle oppgraderinger som dataendringer, fordi Shioris databasemigreringer og avhengigheter for sidefangst kan endre arkivoppførselen. Pinn versjoner, øv på gjenopprettet tilstand og behold det forrige imaget tilgjengelig til rollback fortsatt er gyldig. Når arkivering mislykkes fordi Chromium-avhengigheter eller filsystemtillatelser er feil, bør du ta vare på logger fra før restart; de inneholder vanligvis den utløsende feilmeldingen.

Dette bør Dockup automatisere for Shiori

Plattformlaget for Shiori består av port 8080, ingress, TLS, runtime-konfigurasjon, lagring og tilgjengelighet til avhengigheter. Dockup kan reprodusere disse delene for sin egen infrastruktur eller en server kunden kobler til.

Deretter fullfører operatøren produktlaget: rut brukergrensesnittet og API-et via en stabil HTTPS-origin; håndhev denne tilgangsregelen — bytt ut den opprinnelige kontoen, begrens offentlig deling og behandle arkiverte private URL-er som sensitivt innhold — og kjør «lagre et bokmerke med arkivert innhold, søk etter det, rediger tagger og bekreft at arkivet fortsatt er tilgjengelig etter at kildesiden er endret». Ved å registrere denne testen sammen med deploymenten unngår du å forveksle automatisert klargjøring med at applikasjonen er klar.

Vanlige spørsmål

Hva trenger Shiori for en produksjonsdeployment?

Ruter Shiori-containeren på port 8080 gjennom én HTTPS-origin. Det eksterne leveringskravet er et skrivbart datavolum og utgående tilgang til sider som skal arkiveres. Ikke erklær Shiori som klar før du kan lagre et bokmerke med arkivert innhold, søke etter det, redigere tagger og bekrefte at arkivet fortsatt er tilgjengelig etter at kildesiden er endret.

Hvilke Shiori-data bør inngå i en sikkerhetskopi?

Gjør /shiori persistent, og inkluder database, arkivert sideinnhold, miniatyrbilder og konfigurasjon i det samme gjenopprettingsmanifestet. En ren Shiori-gjenoppretting er bare vellykket når bokmerker, tagger, arkivfiler og kontoer kommer tilbake, og en død kildelenke fortsatt åpner det lagrede innholdet.

Krever Shiori HTTPS bak en reverse proxy?

Bruk HTTPS for den offentlige Shiori-originen, og behold port 8080 på den interne ruten. Bruk Shiori-innstillingen korrekt: ruter brukergrensesnittet og API-et via en stabil HTTPS-origin. For Shiori beskytter HTTPS legitimasjon eller brukerinnhold under overføring og sørger for konsistent klientoppførsel som er avhengig av origin.

Hvordan bør en Shiori-oppgradering testes?

Gjenopprett gjeldende Shiori-tilstand i en isolert deployment, bruk kandidatversjonen og gjenta godkjenningstransaksjonen. Vær spesielt oppmerksom på at Shioris databasemigreringer og avhengigheter for sidefangst kan endre arkivoppførselen. Behold det forrige Shiori-imaget til grensen for datamigrering og rollback er forstått.