2026'da Shiori'yi Self-Host Etme: Arşivler, Hesaplar ve Kalıcı Depolama
Docker, portlar, kalıcı veriler, TLS, güvenlik, yedeklemeler ve production kullanımını engelleyen sorunları kapsayan pratik bir Shiori self-hosting rehberi. Adım adım.
Başarısız bir Shiori deployment'ı her zaman çökmeyebilir. Chromium bağımlılıkları veya filesystem izinleri hatalı olduğu için arşivleme çalışmazken login sayfası sunulabilir. Bunun yerine uçtan uca bir kontrolle başlayın: arşivlenmiş içerikle bir bookmark kaydedin, arayın, etiketlerini düzenleyin ve kaynak sayfa değiştikten sonra arşivin hâlâ erişilebilir olduğunu doğrulayın.
Bu kontrol, Shiori'nin kataloglanmış kullanım amacıyla örtüşür: sayfa içeriğini arşivleyen bir bookmark manager. Ayrıca eksik bağımlılıkları, hatalı proxy varsayımlarını ve ephemeral verileri bir uptime probe'dan daha erken ortaya çıkarır.
Shiori runtime sınırını belirleyin
Shiori için process health ile product health birbirinden ayrıdır. Port 8080 yanıt verirken kullanıcıya sunulan işlem yine de başarısız olabilir. Shiori'nin dış gereksinimi, yazılabilir bir data volume ve arşivlenen sayfalara outbound erişimdir. Başka bir inbound service yayınlamadan outbound DNS, TLS ve provider davranışını test edin.
Anlamlı configuration değişikliklerinden sonra bu readiness çalışmasını kullanın: arşivlenmiş içerikle bir bookmark kaydedin, arayın, etiketlerini düzenleyin ve kaynak sayfa değiştikten sonra arşivin hâlâ erişilebilir olduğunu doğrulayın. Bir provider kesintisinin restart loop oluşturmasını önlemek için maliyetli external kontrolleri liveness probe'larından uzak tutun. Capacity çalışmaları; page capture için browser kullanımını, arşiv boyutunu, thumbnail'ları ve outbound fetching'i izlemelidir. Bunlar, Shiori'nin gerçek yükünü page request'lerinden daha iyi yansıtır.
Shiori'yi boş bir host üzerinde geri yükleyin
İlk gerçek kayıt oluşturulmadan önce state'i listeleyin: database, arşivlenmiş sayfa içeriği, thumbnail'lar ve configuration. Bootstrap işleminden önce /shiori yolunu mount edin, zararsız örnek veriler yazın ve bu yolun gerçekten kalıcı olduğunu kanıtlamak için container'ı değiştirin. Mount'u zararsız veriler yazarak, Shiori'yi değiştirerek ve verileri yeniden okuyarak doğrulayın.
Snapshots hızlı rollback için değerlidir; ancak host veya volume kaybolduğunda bağımsız bir backup gerekir. Pinned image ile boş bir ortama restore edin ve bookmark'ların, etiketlerin, archive dosyalarının ve hesapların geri geldiğini; artık erişilemeyen bir source link'in ise kaydedilmiş içeriğini hâlâ açtığını doğrulayın. Bu iki recovery mekanizmasını birbirinden ayrı tutmak için persistent volume'lar ve snapshot'lar yaklaşımını kullanın.
Shiori'ye özgü güvenlik kararları
Uygulamaya özgü güvenlik riski, başlangıç hesabını public instance üzerinde değiştirmeden bırakmaktır. Operasyonel çözüm; başlangıç hesabını değiştirmek, public sharing'i sınırlandırmak ve arşivlenmiş private URL'leri hassas içerik olarak ele almaktır. Bootstrap işlemini kısıtlı bir route üzerinden tamamlayın ve geçici setup erişimini hemen ardından kaldırın.
SHIORI_DIR, gizlilikten çok davranışı kontrol eder; türünü ve değerini doğrulayın, gerçek Shiori kimlik bilgilerini ayrı yerde saklayın. Shiori process'ine yalnızca belgelenmiş mount'ları ve dependency route'larını verin; host root ve Docker socket erişiminden kaçının. Başarısız authentication denemelerini ve configuration hatalarını log'layın; ancak token'ları, connection string'leri ve kullanıcı içeriğini redact edin.
Shiori için production kabul testi
Shiori için release candidate, sabit bir senaryoyu tamamlayarak traffic almaya hak kazanır: arşivlenmiş içerikle bir bookmark kaydedin, arayın, etiketlerini düzenleyin ve kaynak sayfa değiştikten sonra arşivin hâlâ erişilebilir olduğunu doğrulayın. Bu senaryo için image digest'ini, secret içermeyen etkin configuration'ı, public origin'i ve timestamp'leri kaydedin. Test verileri disposable olmalı; ancak kullanıcıların izlediği akışı çalıştıracak kadar gerçekçi olmalıdır.
Runtime'ı değiştirdikten sonra testi çalıştırın, ardından service'i database, arşivlenmiş sayfa içeriği, thumbnail'lar ve configuration'dan yeniden build edin. Bookmark'lar, etiketler, archive dosyaları ve hesaplar geri geldiğinde ve artık erişilemeyen bir source link kaydedilmiş içeriğini hâlâ açtığında recovery başarılıdır. Browser tabanlı page capture, arşiv boyutu, thumbnail'lar ve outbound fetching için resource ölçümlerini önceki release ile karşılaştırın; promotion öncesinde anlamlı sapmaları araştırın.
Son olarak şu kontrollü arızayı test edin: yazılabilir bir data volume ve arşivlenen sayfalara outbound erişim için kullanılan test path'ini geçici olarak engelleyin. Shiori'nin hatayı açıklayabildiğini, mevcut state'e zarar vermediğini ve geçerli koşul geri geldiğinde devam ettiğini doğrulayın. Redact edilmiş bir log alıntısını ve recovery süresini kaydedin. Bu kontroller birlikte yalnızca process uptime'ını değil, davranışı, dayanıklılığı ve operability'yi kapsar.
Shiori'yi gözlemlenebilir varsayılanlarla başlatın
İlk Shiori invocation'ını pull request içinde incelenebilecek kadar reproducible tutun.
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
Gerçek veriler oluştuktan sonra latest sürümüne güvenmeyin. Çalışan digest'i, container user'ını ve mount ownership'ini kaydedin. Uygulama log'unu eksiksiz bir test boyunca takip edin — arşivlenmiş içerikle bir bookmark kaydedin, arayın, etiketlerini düzenleyin ve kaynak sayfa değiştikten sonra arşivin hâlâ erişilebilir olduğunu doğrulayın — ve route'u production traffic'inin arkasına almadan önce varsa migration'ları not edin.
Domain'ler, proxy header'ları ve port 8080
External Shiori URL'sini redeploy'lar arasında korunacak bir configuration olarak ele alın. Önce UI ve API'yi sabit bir HTTPS origin üzerinden route edin; ardından hostname'i, original host ve scheme korunacak şekilde port 8080'e yönlendirin.
Deployment erişilebilirlik checklist'i, request'lerin container'a girdiğini kanıtlayabilir. Bu noktadan sonra bilinen hata — Chromium bağımlılıkları veya filesystem izinleri hatalı olduğu için arşivleme başarısız oluyor — certificate automation'da değil, Shiori'de, state'inde veya workload'unda araştırılmalıdır.
Shiori'yi tahmin yürütmeden upgrade edin
Shiori için ilk yararlı operational metric; arşivlenmiş içerikle bir bookmark kaydedip kaydedemediği, bu bookmark'ı arayıp arayamadığı, etiketlerini düzenleyip düzenleyemediği ve kaynak sayfa değiştikten sonra arşivin hâlâ erişilebilir olup olmadığıdır. Bunu browser tabanlı page capture, arşiv boyutu, thumbnail'lar ve outbound fetching için saturation sinyalleriyle birlikte değerlendirin. Yalnızca process'i kontrol eden bir probe, pahalı dependency'leri çağırmamalı veya upstream kısa süreliğine erişilemez olduğunda container'ı restart etmemelidir.
Shiori database migration'ları ve page-capture dependency'leri arşiv davranışını değiştirebileceği için upgrade'leri data change olarak ele alın. Sürümleri pin'leyin, restore edilmiş state üzerinde prova yapın ve rollback geçerli kaldığı sürece önceki image'ı hazır tutun. Chromium bağımlılıkları veya filesystem izinleri hatalı olduğu için arşivleme başarısız olduğunda restart öncesindeki log'ları koruyun; causal message çoğunlukla bu log'larda bulunur.
Dockup, Shiori için neleri otomatikleştirmeli?
Shiori için platform katmanı; port 8080, ingress, TLS, runtime configuration, storage ve dependency reachability'den oluşur. Dockup bu bileşenleri kendi infrastructure'ı veya müşterinin bağladığı bir server için yeniden oluşturabilir.
Ardından product layer'ı operator tamamlar: UI ve API'yi sabit bir HTTPS origin üzerinden route edin; şu access rule'u uygulayın — başlangıç hesabını değiştirin, public sharing'i sınırlandırın ve arşivlenmiş private URL'leri hassas içerik olarak ele alın — ve “arşivlenmiş içerikle bir bookmark kaydedin, arayın, etiketlerini düzenleyin ve kaynak sayfa değiştikten sonra arşivin hâlâ erişilebilir olduğunu doğrulayın” akışını çalıştırın. Bu testi deployment ile birlikte kaydetmek, automated provisioning ile application readiness'in birbirine karıştırılmasını önler.
Sık sorulan sorular
Production deployment için Shiori'nin neye ihtiyacı var?
Shiori container'ını port 8080 üzerinden tek bir HTTPS origin'e route edin. Dışarıya sunum için gerekenler, yazılabilir bir data volume ve arşivlenen sayfalara outbound erişimdir. Arşivlenmiş içerikle bir bookmark kaydedene, arayana, etiketlerini düzenleyene ve kaynak sayfa değiştikten sonra arşivin hâlâ erişilebilir olduğunu doğrulayana kadar Shiori'yi ready kabul etmeyin.
Hangi Shiori verileri backup'a dahil edilmeli?
/shiori yolunu persist edin ve database'i, arşivlenmiş sayfa içeriğini, thumbnail'ları ve configuration'ı aynı recovery manifest'ine dahil edin. Temiz bir Shiori restore'u yalnızca bookmark'lar, etiketler, archive dosyaları ve hesaplar geri geldiğinde ve artık erişilemeyen bir source link kaydedilmiş içeriğini hâlâ açtığında başarılıdır.
Reverse proxy arkasında Shiori için HTTPS gerekir mi?
Public Shiori origin'i için HTTPS kullanın ve port 8080'i internal route üzerinde tutun. Shiori ayarını doğru uygulayın: UI ve API'yi sabit bir HTTPS origin üzerinden route edin. Shiori için HTTPS, credentials veya kullanıcı içeriğinin aktarım sırasında korunmasını sağlar ve origin'e duyarlı client davranışının tutarlı kalmasına yardımcı olur.
Shiori upgrade'i nasıl test edilmeli?
Mevcut Shiori state'ini isolated bir deployment'a restore edin, candidate sürümü uygulayın ve acceptance transaction'ını tekrarlayın. Shiori database migration'ları ve page-capture dependency'leri arşiv davranışını değiştirebileceğinden özellikle bu noktaya dikkat edin. Data migration ve rollback sınırı anlaşılana kadar önceki Shiori image'ını hazır tutun.