Cum să găzduiești Shiori pe propriul server în 2026: arhive, conturi și stocare persistentă
Un ghid practic pentru găzduirea Shiori pe propriul server, care acoperă Docker, porturi, date persistente, TLS, securitate, backupuri și problemele care împiedică utilizarea în producție. Pas cu pas.
O implementare Shiori care a eșuat nu se oprește întotdeauna. Poate afișa pagina de autentificare, în timp ce arhivarea eșuează din cauza dependențelor Chromium sau a permisiunilor incorecte ale sistemului de fișiere. Începe, în schimb, cu o verificare end-to-end: salvează un bookmark cu conținut arhivat, caută-l, editează etichetele și verifică dacă arhiva rămâne disponibilă după modificarea paginii sursă.
Această verificare corespunde scopului documentat al Shiori: manager de bookmarkuri care arhivează conținutul paginilor. De asemenea, scoate la iveală mai devreme dependențele lipsă, presupunerile greșite despre proxy și datele efemere decât poate face o verificare de uptime.
Stabilește limitele runtime-ului Shiori
Sănătatea procesului și sănătatea produsului sunt lucruri separate pentru Shiori. Portul 8080 poate răspunde, în timp ce tranzacția destinată utilizatorului eșuează în continuare. Cerința externă pentru Shiori este un volum de date inscriptibil și acces de ieșire către paginile arhivate. Testează DNS-ul de ieșire, TLS-ul și comportamentul furnizorului fără să publici un alt serviciu inbound.
Folosește acest exercițiu de verificare a disponibilității după modificări importante de configurare: salvează un bookmark cu conținut arhivat, caută-l, editează etichetele și verifică dacă arhiva rămâne disponibilă după modificarea paginii sursă. Nu include verificările externe costisitoare în probele de liveness, pentru ca o întrerupere a furnizorului să nu provoace o buclă de restart. Planificarea capacității ar trebui să urmărească capturarea paginilor în browser, dimensiunea arhivei, thumbnailurile și preluarea conținutului din exterior — aspecte mai apropiate de presiunea reală asupra Shiori decât solicitările de pagini.
Restaurează Shiori pe un host gol
Enumeră starea înainte de crearea primei înregistrări reale: baza de date, conținutul paginilor arhivate, thumbnailurile și configurația. Montează /shiori înainte de bootstrap, scrie date de test inofensive și înlocuiește containerul pentru a demonstra că acea cale este într-adevăr persistentă. Confirmă montarea scriind date inofensive, înlocuind Shiori și citindu-le apoi.
Snapshoturile sunt utile pentru rollback rapid, dar ai nevoie de un backup independent atunci când hostul sau volumul dispare. Restaurează într-un mediu gol folosind imaginea fixată la o anumită versiune și verifică dacă bookmarkurile, etichetele, fișierele arhivate și conturile reapar, iar un link sursă mort încă deschide conținutul salvat. Folosește volume persistente și snapshoturi pentru a păstra distincte aceste două mecanisme de recuperare.
Decizii de securitate specifice pentru Shiori
Riscul de securitate specific aplicației este păstrarea contului inițial neschimbat pe o instanță publică. Soluția operațională este să înlocuiești contul inițial, să limitezi partajarea publică și să tratezi URL-urile private arhivate ca informații sensibile. Finalizează bootstrap-ul printr-o rută restricționată și elimină imediat accesul temporar la configurare.
SHIORI_DIR controlează comportamentul, nu confidențialitatea; validează-i tipul și valoarea și stochează separat credențialele reale Shiori. Acordă procesului Shiori doar montările și rutele către dependențe documentate; evită accesul la root-ul hostului și la socketul Docker. Înregistrează autentificările eșuate și erorile de configurare, dar elimină din loguri tokenurile, stringurile de conectare și conținutul utilizatorilor.
Un test de acceptanță pentru Shiori în producție
Un candidat de release pentru Shiori merită să primească trafic după ce finalizează un scenariu fix: salvează un bookmark cu conținut arhivat, caută-l, editează etichetele și verifică dacă arhiva rămâne disponibilă după modificarea paginii sursă. Capturează digestul imaginii, configurația efectivă care nu conține secrete, originea publică și marcajele de timp pentru acel scenariu. Datele de test ar trebui să poată fi eliminate, dar să fie suficient de realiste pentru a exercita aceeași cale folosită de utilizatori.
Rulează testul după înlocuirea runtime-ului, apoi reconstruiește serviciul pornind de la baza de date, conținutul paginilor arhivate, thumbnailuri și configurație. Recuperarea este reușită atunci când bookmarkurile, etichetele, fișierele arhivate și conturile reapar, iar un link sursă mort încă deschide conținutul salvat. Compară măsurătorile de resurse pentru capturarea paginilor în browser, dimensiunea arhivei, thumbnailuri și preluarea conținutului din exterior cu versiunea anterioară și investighează abaterile semnificative înainte de promovare.
În cele din urmă, simulează următoarea defecțiune controlată: blochează temporar calea de test utilizată de un volum de date inscriptibil și accesul de ieșire către paginile arhivate. Verifică dacă Shiori explică defecțiunea, nu deteriorează starea existentă și își reia funcționarea după restabilirea condiției valide. Salvează un fragment de log anonimizat și timpul de recuperare. Împreună, aceste verificări acoperă comportamentul, durabilitatea și operabilitatea, nu doar uptime-ul procesului.
Pornește Shiori cu valori implicite observabile
Păstrează comanda inițială de pornire a Shiori suficient de reproductibilă pentru a putea fi verificată într-un 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
Nu te baza pe latest după ce există date reale. Capturează digestul funcțional, utilizatorul containerului și proprietarul montării. Urmărește logul aplicației pe durata unui test complet — salvează un bookmark cu conținut arhivat, caută-l, editează etichetele și verifică dacă arhiva rămâne disponibilă după modificarea paginii sursă — și notează eventualele migrări înainte de a pune ruta în spatele traficului de producție.
Domenii, headere de proxy și portul 8080
Tratează URL-ul extern Shiori ca pe o configurație care trebuie să supraviețuiască redeploy-urilor. Mai întâi direcționează interfața și API-ul printr-o origine HTTPS stabilă; apoi direcționează hostname-ul către portul 8080, păstrând intacte hostul și schema originale.
Lista de verificare pentru accesibilitatea deploymentului poate demonstra că solicitările ajung în container. După acest punct, problema cunoscută — arhivarea eșuează din cauza dependențelor Chromium sau a permisiunilor incorecte ale sistemului de fișiere — ar trebui investigată în Shiori, în starea sa sau în workload, nu în automatizarea certificatelor.
Actualizează Shiori fără presupuneri
Prima metrică operațională utilă pentru Shiori este dacă poate salva un bookmark cu conținut arhivat, îl poate căuta, poate edita etichetele și poate verifica dacă arhiva rămâne disponibilă după modificarea paginii sursă. Asociază această metrică cu semnale de saturație pentru capturarea paginilor în browser, dimensiunea arhivei, thumbnailuri și preluarea conținutului din exterior. O probă care verifică doar procesul nu ar trebui să apeleze dependențe costisitoare sau să repornească containerul deoarece un upstream nu este disponibil temporar.
Tratează actualizările ca modificări ale datelor, deoarece migrările bazei de date Shiori și dependențele pentru capturarea paginilor pot schimba comportamentul arhivelor. Fixează versiunile, repetă procedura pe o stare restaurată și păstrează imaginea anterioară disponibilă până când rollback-ul rămâne valid. Atunci când arhivarea eșuează din cauza dependențelor Chromium sau a permisiunilor incorecte ale sistemului de fișiere, păstrează logurile de dinaintea restartului; de obicei, acestea conțin mesajul care indică cauza.
Ce ar trebui să automatizeze Dockup pentru Shiori
Stratul de platformă pentru Shiori constă în portul 8080, ingress, TLS, configurația runtime-ului, stocare și accesibilitatea dependențelor. Dockup poate reproduce aceste componente pentru propria infrastructură sau pentru un server conectat de client.
Apoi operatorul finalizează stratul produsului: direcționează interfața și API-ul printr-o origine HTTPS stabilă; aplică această regulă de acces — înlocuiește contul inițial, limitează partajarea publică și tratează URL-urile private arhivate ca informații sensibile; și rulează „salvează un bookmark cu conținut arhivat, caută-l, editează etichetele și verifică dacă arhiva rămâne disponibilă după modificarea paginii sursă”. Înregistrarea testului împreună cu deploymentul evită confundarea provisionării automate cu disponibilitatea aplicației.
Întrebări frecvente
De ce are nevoie Shiori pentru un deployment în producție?
Direcționează containerul Shiori de pe portul 8080 printr-o singură origine HTTPS. Cerința externă pentru livrare este un volum de date inscriptibil și acces de ieșire către paginile arhivate. Nu considera Shiori pregătit până când nu poți salva un bookmark cu conținut arhivat, îl poți căuta, poți edita etichetele și poți verifica dacă arhiva rămâne disponibilă după modificarea paginii sursă.
Ce date Shiori trebuie incluse într-un backup?
Persistă /shiori și include baza de date, conținutul paginilor arhivate, thumbnailurile și configurația în același manifest de recuperare. O restaurare Shiori curată este reușită doar atunci când bookmarkurile, etichetele, fișierele arhivate și conturile reapar, iar un link sursă mort încă deschide conținutul salvat.
Are Shiori nevoie de HTTPS în spatele unui reverse proxy?
Folosește HTTPS pentru originea publică Shiori și păstrează portul 8080 pe ruta internă. Aplică corect setarea Shiori: direcționează interfața și API-ul printr-o origine HTTPS stabilă. Pentru Shiori, HTTPS protejează credențialele sau conținutul utilizatorilor în tranzit și menține consecvent comportamentul clientului dependent de origine.
Cum ar trebui testat un upgrade Shiori?
Restaurează starea curentă Shiori într-un deployment izolat, aplică versiunea candidată și repetă tranzacția de acceptanță. Acordă o atenție deosebită acestui pas, deoarece migrările bazei de date Shiori și dependențele pentru capturarea paginilor pot schimba comportamentul arhivelor. Păstrează imaginea Shiori anterioară până când limitele migrării datelor și ale rollback-ului sunt clare.