Как да хоствате Shiori самостоятелно през 2026 г.: архиви, акаунти и постоянно съхранение
Практическо ръководство за самостоятелно хостване на Shiori с Docker, портове, постоянно съхранение на данни, TLS, сигурност, архивиране и проблемите, които пречат на продукционната употреба. Стъпка по стъпка.
Неуспешното внедряване на Shiori невинаги води до срив. Възможно е приложението да показва страница за вход, докато архивирането не работи заради неправилни зависимости на Chromium или permissions на файловата система. Вместо това започнете с проверка от край до край: запазете bookmark с архивирано съдържание, потърсете го, редактирайте tags и проверете дали архивът остава достъпен след промяна на изходната страница.
Тази проверка съответства на описаното предназначение на Shiori: bookmark manager, който архивира съдържанието на страниците. Тя също така разкрива липсващи зависимости, неправилни допускания за proxy и ефимерни данни по-рано, отколкото може да го направи uptime проверка.
Определете границите на runtime средата на Shiori
Здравето на процеса и здравето на продукта са различни неща при Shiori. Порт 8080 може да отговаря, докато транзакцията, която потребителят реално изпълнява, все още е неуспешна. Външното изискване за Shiori е writable data volume и outbound достъп до архивираните страници. Тествайте outbound DNS, TLS и поведението на доставчика, без да публикувате друга inbound услуга.
Използвайте това упражнение за проверка на готовността след значими промени в конфигурацията: запазете bookmark с архивирано съдържание, потърсете го, редактирайте tags и проверете дали архивът остава достъпен след промяна на изходната страница. Не включвайте скъпи външни проверки в liveness probes, за да не предизвика прекъсване при доставчика цикъл от рестартирания. Работата по капацитета трябва да следи capture на страници чрез browser, размера на архивите, thumbnails и outbound fetching — това е по-близо до реалното натоварване на Shiori от заявките към страниците.
Възстановете Shiori на празен host
Опишете състоянието, преди да бъде създаден първият реален запис: database, архивирано съдържание на страниците, thumbnails и конфигурация. Монтирайте /shiori преди bootstrap, запишете безобидни примерни данни и заменете container-а, за да докажете, че този path наистина е persistent. Потвърдете mount-а, като запишете безобидни данни, замените Shiori и ги прочетете обратно.
Snapshots са ценни за бързо връщане назад, но е необходимо независимо backup копие, когато host-ът или volume-ът изчезнат. Възстановете в празна среда с pinned image и проверете дали bookmarks, tags, archive files и accounts се връщат и дали мъртва source link все още отваря запазеното си съдържание. Използвайте persistent volumes и snapshots, за да разграничавате ясно тези два механизма за възстановяване.
Решения за сигурност, специфични за Shiori
Рискът за сигурността, специфичен за приложението, е да оставите initial account непроменен в публична инстанция. Оперативното решение е да замените initial account, да ограничите public sharing и да третирате архивираните private URLs като чувствително съдържание. Завършете bootstrap-а през restricted route и незабавно премахнете временния setup достъп след това.
SHIORI_DIR управлява поведението, а не поверителността; проверете неговия type и value и съхранявайте реалните Shiori credentials отделно. Дайте на Shiori process-а достъп само до документираните му mounts и dependency routes; избягвайте достъп до host root и Docker socket. Записвайте неуспешните authentication опити и configuration errors, но заличавайте tokens, connection strings и потребителско съдържание.
Production acceptance run за Shiori
Release candidate за Shiori заслужава трафик, след като изпълни фиксиран сценарий: запазете bookmark с архивирано съдържание, потърсете го, редактирайте tags и проверете дали архивът остава достъпен след промяна на изходната страница. Запишете image digest-а, effective non-secret configuration, public origin и timestamps за този сценарий. Тестовите данни трябва да могат да бъдат изтрити, но да са достатъчно реалистични, за да упражняват същия path, който използват потребителите.
Изпълнете го след подмяна на runtime-а, след което изградете услугата отново от database, архивираното съдържание на страниците, thumbnails и конфигурацията. Възстановяването е успешно, когато bookmarks, tags, archive files и accounts се върнат и мъртва source link все още отваря запазеното си съдържание. Сравнете измерванията на ресурсите за capture на страници чрез browser, размера на архивите, thumbnails и outbound fetching с предишния release и проучете значимите отклонения, преди да го пуснете.
Накрая изпълнете този контролиран failure сценарий: временно забранете test path-а, използван от writable data volume, и outbound достъпа до архивираните страници. Проверете дали Shiori обяснява проблема, не поврежда съществуващото състояние и възобновява работа след връщане на валидното условие. Запазете redacted log excerpt и времето за възстановяване. Заедно тези проверки обхващат поведението, устойчивостта на данните и оперативната пригодност, а не само uptime-а на процеса.
Стартирайте Shiori с наблюдаеми настройки по подразбиране
Поддържайте initial invocation-а на Shiori достатъчно възпроизводим, за да може да бъде прегледан в 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
Не разчитайте на latest, след като вече има реални данни. Запишете работещия digest, container user и ownership-а на mount-а. Проследете application log-а през пълен тест — запазете bookmark с архивирано съдържание, потърсете го, редактирайте tags и проверете дали архивът остава достъпен след промяна на изходната страница — и отбележете всички migrations, преди да поставите route-а зад production трафик.
Домейни, proxy headers и порт 8080
Третирайте външния Shiori URL като конфигурация, която трябва да се запазва при redeploy. Първо насочете UI и API през стабилен HTTPS origin; след това насочете hostname-а към порт 8080, като запазите оригиналните host и scheme.
Checklist-ът за reachability при deployment може да докаже, че заявките достигат до container-а. След това известният проблем — архивирането не работи заради неправилни зависимости на Chromium или permissions на файловата система — трябва да се проучи в Shiori, неговото state или неговото workload, а не в автоматизацията на сертификатите.
Ъпгрейдвайте Shiori без предположения
Първата полезна operational metric за Shiori е дали може да запази bookmark с архивирано съдържание, да го потърси, да редактира tags и да провери дали архивът остава достъпен след промяна на изходната страница. Съчетайте това със saturation signals за capture на страници чрез browser, размера на архивите, thumbnails и outbound fetching. Probe, който проверява само процеса, не трябва да извиква скъпи зависимости или да рестартира container-а, защото upstream временно не е достъпен.
Третирайте upgrades като промени в данните, тъй като database migrations на Shiori и dependencies за page capture могат да променят поведението на архивите. Pin-вайте версиите, репетирайте процедурата върху възстановено state и запазете предишния image, докато rollback-ът остава валиден. Когато архивирането не работи заради неправилни зависимости на Chromium или permissions на файловата система, запазете логовете от преди рестарта; те обикновено съдържат причинното съобщение.
Какво трябва да автоматизира Dockup за Shiori
Platform layer-ът за Shiori се състои от порт 8080, ingress, TLS, runtime конфигурация, storage и dependency reachability. Dockup може да възпроизведе тези части за собствената си инфраструктура или за server, свързан от клиента.
След това операторът завършва product layer-а: насочва UI и API през стабилен HTTPS origin; прилага това access правило — заменя initial account, ограничава public sharing и третира архивираните private URLs като чувствително съдържание; и изпълнява „запазете bookmark с архивирано съдържание, потърсете го, редактирайте tags и проверете дали архивът остава достъпен след промяна на изходната страница“. Записването на този тест заедно с deployment-а предотвратява объркването между автоматизираното provisioning и готовността на приложението.
Често задавани въпроси
Какво е необходимо на Shiori за production deployment?
Насочете Shiori container-а на порт 8080 през един HTTPS origin. Външното изискване за delivery е writable data volume и outbound достъп до архивираните страници. Не обявявайте Shiori за готов, докато не можете да запазите bookmark с архивирано съдържание, да го потърсите, да редактирате tags и да проверите дали архивът остава достъпен след промяна на изходната страница.
Кои данни на Shiori трябва да бъдат включени в backup?
Запазвайте /shiori и включвайте database, архивираното съдържание на страниците, thumbnails и конфигурацията в един и същ recovery manifest. Възстановяването на Shiori е успешно само когато bookmarks, tags, archive files и accounts се върнат и мъртва source link все още отваря запазеното си съдържание.
Изисква ли Shiori HTTPS зад reverse proxy?
Използвайте HTTPS за публичния Shiori origin и оставете порт 8080 във вътрешния route. Приложете правилно настройката на Shiori: насочете UI и API през стабилен HTTPS origin. При Shiori HTTPS защитава credentials или потребителското съдържание при пренос и поддържа последователно client behavior, зависещо от origin-а.
Как трябва да се тества upgrade на Shiori?
Възстановете текущото state на Shiori в изолирано deployment, приложете candidate версията и повторете acceptance transaction-а. Обърнете специално внимание, тъй като database migrations на Shiori и dependencies за page capture могат да променят поведението на архивите. Запазете предишния Shiori image, докато границите на data migration и rollback не бъдат изяснени.