Sådan self-hoster du Shiori i 2026: Arkiver, konti og persistent storage

En mislykket Shiori-deployment crasher ikke altid. Den kan godt vise en login-side, selvom arkivering mislykkes, fordi Chromium-afhængigheder eller filsystemrettigheder er forkerte. Start i stedet med et end-to-end-tjek: Gem et bogmærke med arkiveret indhold, søg efter det, redigér tags, og kontrollér, at arkivet stadig er tilgængeligt, efter kildesiden er ændret.

Det tjek stemmer overens med Shioris dokumenterede formål: en bogmærkehåndtering, der arkiverer sideindhold. Det afslører også manglende afhængigheder, forkerte antagelser om proxyen og ephemeral data tidligere, end en uptime-probe kan.

Afgræns Shioris runtime

Proceshealth og produkthealth er to forskellige ting for Shiori. Port 8080 kan svare, selvom den brugerrettede transaktion stadig fejler. Shioris eksterne krav er en skrivbar data volume og outbound-adgang til de sider, der skal arkiveres. Test outbound DNS, TLS og provider-adfærd uden at publicere endnu en inbound-service.

Brug denne readiness-øvelse efter væsentlige konfigurationsændringer: Gem et bogmærke med arkiveret indhold, søg efter det, redigér tags, og kontrollér, at arkivet stadig er tilgængeligt, efter kildesiden er ændret. Hold dyre eksterne tjek ude af liveness-probes, så et provider-nedbrud ikke udløser en restart-loop. Kapacitetsarbejdet bør følge browserbaseret sidecapture, arkivstørrelse, thumbnails og outbound-fetching, fordi det ligger tættere på Shioris reelle belastning end sideforespørgsler gør.

Gendan Shiori på en tom host

Kortlæg state, før den første rigtige post oprettes: database, arkiveret sideindhold, thumbnails og konfiguration. Mount /shiori før bootstrap, skriv harmløse eksempeldata, og erstat containeren for at bevise, at stien faktisk er persistent. Bekræft mountet ved at skrive harmløse data, erstatte Shiori og læse dataene tilbage.

Snapshots er værdifulde til hurtig rollback, men der er brug for en uafhængig backup, hvis hosten eller volumen forsvinder. Gendan i et tomt miljø med det pinnede image, og kontrollér, at bogmærker, tags, arkivfiler og konti kommer tilbage, og at et dødt kildelink stadig åbner det gemte indhold. Brug persistent volumes og snapshots for at holde de to recovery-mekanismer adskilt.

Sikkerhedsbeslutninger, der er specifikke for Shiori

Den applikationsspecifikke sikkerhedsrisiko er at lade den oprindelige konto være uændret på en offentlig instans. Den operationelle løsning er at udskifte den oprindelige konto, begrænse offentlig deling og behandle arkiverede private URL'er som følsomt indhold. Afslut bootstrap via en begrænset route, og fjern midlertidig setup-adgang med det samme bagefter.

SHIORI_DIR styrer adfærd, ikke fortrolighed; validér dens type og værdi, og opbevar ægte Shiori-legitimationsoplysninger separat. Giv kun Shiori-processen de dokumenterede mounts og dependency-routes; undgå adgang til hostens root og Docker-socket. Log mislykkede authentication-forsøg og konfigurationsfejl, men redigér tokens, connection strings og brugerindhold væk.

En production acceptance-test for Shiori

En release candidate til Shiori får trafik ved at gennemføre et fast scenarie: Gem et bogmærke med arkiveret indhold, søg efter det, redigér tags, og kontrollér, at arkivet stadig er tilgængeligt, efter kildesiden er ændret. Registrér image digest, den effektive ikke-hemmelige konfiguration, public origin og timestamps for scenariet. Testdataene skal kunne bortskaffes, men være realistiske nok til at udøve den samme sti som brugerne.

Kør testen efter at have erstattet runtime, og genopbyg derefter servicen fra database, arkiveret sideindhold, thumbnails og konfiguration. Recovery består, når bogmærker, tags, arkivfiler og konti kommer tilbage, og et dødt kildelink stadig åbner det gemte indhold. Sammenlign resourcemålinger for browserbaseret sidecapture, arkivstørrelse, thumbnails og outbound-fetching med den tidligere release, og undersøg væsentlige afvigelser, før du promoverer releasen.

Afprøv til sidst denne kontrollerede fejl: Afvis midlertidigt den teststi, der bruges af en skrivbar data volume, samt outbound-adgang til de sider, der skal arkiveres. Kontrollér, at Shiori forklarer fejlen, ikke beskadiger eksisterende state og genoptager driften, når den gyldige tilstand vender tilbage. Gem et redigeret logudsnit og recovery-tiden. Tilsammen dækker disse tjek adfærd, persistence og driftsegenskaber i stedet for kun proces-uptime.

Start Shiori med observerbare defaults

Hold den indledende Shiori-kørsel reproducerbar nok til at kunne gennemgås i et 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

Stol ikke på latest, når der først findes rigtige data. Registrér det fungerende digest, container-brugeren og ejerskabet for mountet. Følg applikationsloggen gennem en komplet test — gem et bogmærke med arkiveret indhold, søg efter det, redigér tags, og kontrollér, at arkivet stadig er tilgængeligt, efter kildesiden er ændret — og notér eventuelle migrations, før du lægger routen bag produktions-trafik.

Domæner, proxy-headers og port 8080

Betragt den eksterne Shiori-URL som konfiguration, der skal overleve redeployments. Rout først UI'et og API'et gennem en stabil HTTPS-origin, og rout derefter hostnavnet til port 8080 med den oprindelige host og scheme intakt.

Tjeklisten for deployment-reachability kan bevise, at requests når ind i containeren. Derefter bør den kendte fejl — arkivering mislykkes, fordi Chromium-afhængigheder eller filsystemrettigheder er forkerte — undersøges i Shiori, dens state eller dens workload i stedet for i certifikatautomatiseringen.

Opgradér Shiori uden at gætte

Den første nyttige operationelle måling for Shiori er, om den kan gemme et bogmærke med arkiveret indhold, søge efter det, redigere tags og kontrollere, at arkivet stadig er tilgængeligt, efter kildesiden er ændret. Kombinér det med saturation-signaler for browserbaseret sidecapture, arkivstørrelse, thumbnails og outbound-fetching. En procesbaseret probe bør ikke kalde dyre afhængigheder eller genstarte containeren, fordi en upstream-tjeneste kortvarigt er utilgængelig.

Betragt upgrades som dataændringer, fordi Shioris databasemigrations og page-capture-afhængigheder kan ændre arkiveringsadfærden. Pin versioner, gennemfør en rehearsal på gendannet state, og behold det tidligere image tilgængeligt, indtil en rollback stadig er gyldig. Når arkivering mislykkes, fordi Chromium-afhængigheder eller filsystemrettigheder er forkerte, skal du gemme logs fra før genstarten; de indeholder normalt den meddelelse, der forklarer årsagen.

Hvad Dockup bør automatisere for Shiori

Platformlaget for Shiori består af port 8080, ingress, TLS, runtime-konfiguration, storage og dependency-reachability. Dockup kan reproducere disse dele i sin egen infrastruktur eller på en server, som kunden forbinder.

Derefter færdiggør operatøren produktlaget: Rout UI'et og API'et gennem en stabil HTTPS-origin; håndhæv denne adgangsregel — udskift den oprindelige konto, begræns offentlig deling, og behandl arkiverede private URL'er som følsomt indhold; og kør “gem et bogmærke med arkiveret indhold, søg efter det, redigér tags, og kontrollér, at arkivet stadig er tilgængeligt, efter kildesiden er ændret”. Ved at registrere testen sammen med deploymenten undgår man at forveksle automatiseret provisioning med applikations-readiness.

Ofte stillede spørgsmål

Hvad skal Shiori bruge til en production deployment?

Rout Shiori-containeren på port 8080 gennem én HTTPS-origin. Det eksterne leveringskrav er en skrivbar data volume og outbound-adgang til de sider, der skal arkiveres. Erklær ikke Shiori for klar, før du kan gemme et bogmærke med arkiveret indhold, søge efter det, redigere tags og kontrollere, at arkivet stadig er tilgængeligt, efter kildesiden er ændret.

Hvilke Shiori-data hører til i en backup?

Persistér /shiori, og medtag database, arkiveret sideindhold, thumbnails og konfiguration i det samme recovery-manifest. En ren Shiori-restore består kun, når bogmærker, tags, arkivfiler og konti kommer tilbage, og et dødt kildelink stadig åbner det gemte indhold.

Kræver Shiori HTTPS bag en reverse proxy?

Brug HTTPS til den offentlige Shiori-origin, og behold port 8080 på den interne route. Anvend Shiori-indstillingen korrekt: Rout UI'et og API'et gennem en stabil HTTPS-origin. For Shiori beskytter HTTPS legitimationsoplysninger eller brugerindhold under transport og sikrer ensartet client-adfærd, der afhænger af origin.

Hvordan bør en Shiori-upgrade testes?

Gendan den aktuelle Shiori-state i en isoleret deployment, anvend kandidatversionen, og gentag dens acceptance-transaktion. Vær særligt opmærksom, fordi Shioris databasemigrations og page-capture-afhængigheder kan ændre arkiveringsadfærden. Behold det tidligere Shiori-image, indtil dets grænser for datamigration og rollback er forstået.