Як розгорнути Shiori на власному сервері у 2026 році: архіви, облікові записи та постійне сховище

Невдале розгортання Shiori не завжди завершується аварійною зупинкою. Сторінка входу може відкриватися, тоді як архівація не працює через неправильні залежності Chromium або дозволи файлової системи. Натомість одразу виконайте end-to-end перевірку: збережіть закладку з архівованим вмістом, знайдіть її, відредагуйте теги та переконайтеся, що архів залишається доступним після зміни сторінки-джерела.

Ця перевірка відповідає задекларованому призначенню Shiori: це менеджер закладок, який архівує вміст сторінок. Вона також раніше виявляє відсутні залежності, неправильні припущення щодо proxy та ефемерні дані, ніж це може зробити uptime probe.

Визначте межі runtime Shiori

Для Shiori справність процесу та справність продукту — різні речі. Порт 8080 може відповідати, хоча користувацька операція все одно завершується помилкою. Зовнішні вимоги Shiori — доступний для запису том даних і вихідний доступ до сторінок, які потрібно архівувати. Перевіряйте вихідні DNS, TLS і поведінку провайдера, не публікуючи ще один вхідний сервіс.

Виконуйте цю readiness-перевірку після суттєвих змін конфігурації: збережіть закладку з архівованим вмістом, знайдіть її, відредагуйте теги та переконайтеся, що архів залишається доступним після зміни сторінки-джерела. Не додавайте дорогі зовнішні перевірки до liveness probe, щоб збій у провайдера не спричинив цикл перезапусків. Під час планування місткості відстежуйте захоплення сторінок через браузер, розмір архіву, мініатюри та вихідні запити — це ближче до реального навантаження Shiori, ніж кількість запитів до сторінок.

Відновіть Shiori на порожньому хості

До створення першого реального запису перелічіть усі дані стану: database, архівований вміст сторінок, мініатюри та конфігурацію. Підключіть /shiori до bootstrap, запишіть безпечні тестові дані та замініть контейнер, щоб перевірити, чи справді цей шлях є постійним. Підтвердьте монтування: запишіть безпечні тестові дані, замініть Shiori та прочитайте їх знову.

Snapshots цінні для швидкого відкату, але потрібна незалежна резервна копія на випадок зникнення хоста або тому. Відновіть дані в порожньому середовищі з pinned image і перевірте, що закладки, теги, файли архівів та облікові записи повернулися, а недоступне посилання на джерело й надалі відкриває збережений вміст. Використовуйте постійні томи та snapshots, щоб розділяти ці два механізми відновлення.

Рішення щодо безпеки, специфічні для Shiori

Специфічний для застосунку ризик безпеки — залишити початковий обліковий запис без змін у публічному екземплярі. Операційне рішення полягає в тому, щоб замінити початковий обліковий запис, обмежити публічний доступ до спільного вмісту та вважати архівовані приватні URL конфіденційним вмістом. Завершіть bootstrap через обмежений маршрут і негайно видаліть тимчасовий доступ до налаштування.

SHIORI_DIR керує поведінкою, а не конфіденційністю; перевіряйте його тип і значення, а справжні облікові дані Shiori зберігайте окремо. Надайте процесу Shiori лише задокументовані монтування та маршрути до залежностей; уникайте доступу до root хоста й Docker socket. Записуйте невдалі спроби автентифікації та помилки конфігурації, але редагуйте токени, connection strings і користувацький вміст.

Приймальне production-тестування Shiori

Release candidate для Shiori отримує трафік лише після проходження фіксованого сценарію: збережіть закладку з архівованим вмістом, знайдіть її, відредагуйте теги та переконайтеся, що архів залишається доступним після зміни сторінки-джерела. Зафіксуйте image digest, ефективну конфігурацію без секретів, публічний origin і часові позначки цього сценарію. Тестові дані мають бути одноразовими, але достатньо реалістичними, щоб пройти той самий шлях, що й користувачі.

Виконайте цей сценарій після заміни runtime, а потім відновіть сервіс із database, архівованого вмісту сторінок, мініатюр і конфігурації. Відновлення вважається успішним, якщо закладки, теги, файли архівів та облікові записи повернулися, а недоступне посилання на джерело й надалі відкриває збережений вміст. Порівняйте вимірювання ресурсів для захоплення сторінок через браузер, розміру архіву, мініатюр і вихідних запитів із попереднім релізом та дослідіть суттєві відхилення до promotion.

Насамкінець виконайте контрольований збій: тимчасово забороніть тестовий шлях, який використовує том даних, доступний для запису, і вихідний доступ до сторінок, що архівуються. Переконайтеся, що Shiori пояснює причину збою, не пошкоджує наявний стан і відновлює роботу після повернення коректної умови. Збережіть очищений фрагмент логу та час відновлення. Разом ці перевірки охоплюють поведінку, надійність зберігання та операційну придатність, а не лише uptime процесу.

Запустіть Shiori зі стандартними параметрами, придатними для спостереження

Зробіть початковий запуск 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, користувача контейнера та власника монтування. Перегляньте лог застосунку протягом повного тесту — збережіть закладку з архівованим вмістом, знайдіть її, відредагуйте теги та переконайтеся, що архів залишається доступним після зміни сторінки-джерела, — і зафіксуйте всі міграції до передавання маршруту production-трафіку.

Домени, proxy headers і порт 8080

Розглядайте зовнішню URL-адресу Shiori як конфігурацію, що має зберігатися між redeploy. Спочатку прокладіть UI та API через стабільний HTTPS origin, а потім спрямуйте hostname на порт 8080, зберігши оригінальні host і scheme.

Чекліст доступності розгортання допоможе довести, що запити потрапляють у контейнер. Після цього відому проблему — архівація не працює через неправильні залежності Chromium або дозволи файлової системи — слід досліджувати в Shiori, його стані або workload, а не в автоматизації сертифікатів.

Оновлюйте Shiori без припущень

Перший корисний операційний показник для Shiori — чи може він зберегти закладку з архівованим вмістом, знайти її, відредагувати теги та підтвердити, що архів залишається доступним після зміни сторінки-джерела. Доповніть його сигналами saturation для захоплення сторінок через браузер, розміру архіву, мініатюр і вихідних запитів. Probe, що перевіряє лише процес, не має викликати дорогі залежності або перезапускати контейнер через короткочасну недоступність upstream.

Вважайте оновлення змінами даних, оскільки database migrations Shiori та залежності захоплення сторінок можуть змінити поведінку архівів. Фіксуйте версії, репетируйте оновлення на відновленому стані та зберігайте попередній image, доки rollback залишається можливим. Якщо архівація не працює через неправильні залежності Chromium або дозволи файлової системи, збережіть логи до перезапуску: зазвичай саме вони містять причинне повідомлення.

Що Dockup має автоматизувати для Shiori

Platform layer для Shiori складається з порту 8080, ingress, TLS, runtime-конфігурації, storage та доступності залежностей. Dockup може відтворити ці компоненти у власній інфраструктурі або на сервері, до якого підключається клієнт.

Після цього оператор завершує product layer: прокладає UI та API через стабільний HTTPS origin; застосовує це правило доступу — замінити початковий обліковий запис, обмежити публічний доступ до спільного вмісту та вважати архівовані приватні URL конфіденційним вмістом; і запускає сценарій «зберегти закладку з архівованим вмістом, знайти її, відредагувати теги та переконатися, що архів залишається доступним після зміни сторінки-джерела». Запис цього тесту разом із розгортанням допомагає не плутати автоматизоване provisioning із готовністю застосунку.

Поширені запитання

Що потрібно Shiori для production-розгортання?

Прокладіть контейнер Shiori на порту 8080 через один HTTPS origin. Зовнішні вимоги доставки — доступний для запису том даних і вихідний доступ до сторінок, які потрібно архівувати. Не вважайте Shiori готовим, доки не зможете зберегти закладку з архівованим вмістом, знайти її, відредагувати теги та переконатися, що архів залишається доступним після зміни сторінки-джерела.

Які дані Shiori потрібно включати до резервної копії?

Зберігайте /shiori і включайте database, архівований вміст сторінок, мініатюри та конфігурацію до одного recovery manifest. Чисте відновлення Shiori вважається успішним лише тоді, коли повернулися закладки, теги, файли архівів та облікові записи, а недоступне посилання на джерело й надалі відкриває збережений вміст.

Чи потрібен Shiori HTTPS за reverse proxy?

Використовуйте HTTPS для публічного Shiori origin, а порт 8080 залишайте у внутрішньому маршруті. Правильно застосовуйте налаштування Shiori: прокладайте UI та API через стабільний HTTPS origin. Для Shiori HTTPS захищає облікові дані або користувацький вміст під час передавання та забезпечує узгоджену поведінку клієнта, чутливу до origin.

Як тестувати оновлення Shiori?

Відновіть поточний стан Shiori в ізольованому розгортанні, застосуйте candidate version і повторіть приймальний сценарій. Зверніть особливу увагу, оскільки database migrations Shiori та залежності захоплення сторінок можуть змінити поведінку архівів. Зберігайте попередній image Shiori, доки не буде зрозуміло межі міграції даних і rollback.