Как разместить Shiori самостоятельно в 2026 году: архивы, аккаунты и постоянное хранилище
Практическое руководство по самостоятельному размещению Shiori: Docker, порты, постоянные данные, TLS, безопасность, резервные копии и проблемы, препятствующие использованию в production. Пошаговая инструкция.
Неудачное развёртывание Shiori не всегда приводит к падению сервиса. Страница входа может открываться, а архивация — не работать из-за неправильных зависимостей Chromium или разрешений файловой системы. Вместо этого начните с end-to-end проверки: сохраните закладку с архивированным содержимым, найдите её, измените теги и убедитесь, что архив остаётся доступным после изменения исходной страницы.
Такая проверка соответствует заявленному назначению Shiori — менеджера закладок, который архивирует содержимое страниц. Кроме того, она раньше, чем uptime-проверка, выявляет отсутствующие зависимости, неверные предположения о proxy и эфемерные данные.
Определите границу выполнения Shiori
Состояние процесса и состояние продукта для Shiori — разные вещи. Порт 8080 может отвечать, пока пользовательский сценарий по-прежнему не работает. Внешние требования Shiori — доступный для записи volume с данными и исходящий доступ к архивируемым страницам. Проверяйте исходящие DNS, TLS и поведение провайдера, не публикуя ещё один входящий сервис.
Выполняйте эту проверку готовности после существенных изменений конфигурации: сохраните закладку с архивированным содержимым, найдите её, измените теги и убедитесь, что архив остаётся доступным после изменения исходной страницы. Не включайте дорогостоящие внешние проверки в liveness probes, чтобы сбой у провайдера не вызвал цикл перезапусков. При работе с capacity учитывайте захват страниц через browser, размер архива, thumbnails и исходящие запросы — это точнее отражает реальные нагрузки Shiori, чем запросы к страницам.
Восстановите Shiori на пустом хосте
До создания первой реальной записи перечислите всё состояние: database, содержимое архивированных страниц, thumbnails и конфигурацию. Подключите /shiori до bootstrap, запишите безвредные тестовые данные и замените container, чтобы доказать фактическую persistence этого пути. Проверьте mount: запишите безвредные данные, замените Shiori и прочитайте их обратно.
Snapshots удобны для быстрого rollback, но при исчезновении хоста или volume нужна независимая backup-копия. Выполните восстановление в пустом окружении с pinned image и убедитесь, что закладки, теги, файлы архивов и аккаунты восстановились, а недоступная исходная ссылка по-прежнему открывает сохранённое содержимое. Используйте persistent volumes и snapshots, чтобы разделять эти два механизма восстановления.
Решения по безопасности, специфичные для Shiori
Специфический для приложения риск безопасности — оставить неизменным initial account на публичном instance. Операционное решение: заменить initial account, ограничить public sharing и считать архивированные private URL конфиденциальным содержимым. Завершите bootstrap через ограниченный route и сразу после этого удалите временный доступ для настройки.
SHIORI_DIR управляет поведением, а не конфиденциальностью; проверьте его тип и значение, а настоящие credentials Shiori храните отдельно. Предоставьте процессу Shiori только документированные mounts и routes к зависимостям; не давайте доступ к host root и Docker socket. Записывайте неудачные попытки аутентификации и ошибки конфигурации, но удаляйте из логов tokens, connection strings и пользовательское содержимое.
Приёмочное тестирование Shiori перед production
Release candidate для Shiori получает production-трафик только после прохождения фиксированного сценария: сохраните закладку с архивированным содержимым, найдите её, измените теги и убедитесь, что архив остаётся доступным после изменения исходной страницы. Зафиксируйте image digest, итоговую конфигурацию без секретов, public origin и timestamps этого сценария. Тестовые данные должны быть disposable, но достаточно реалистичными, чтобы проходить тот же путь, что и пользовательские данные.
Запустите этот сценарий после замены runtime, а затем пересоберите сервис из database, содержимого архивированных страниц, thumbnails и конфигурации. Восстановление считается успешным, если закладки, теги, файлы архивов и аккаунты вернулись, а недоступная исходная ссылка по-прежнему открывает сохранённое содержимое. Сравните показатели ресурсов для захвата страниц через browser, размера архива, thumbnails и исходящих запросов с предыдущим release и до promotion разберитесь с существенными отклонениями.
Наконец, выполните контролируемый сбой: временно запретите тестовый путь, используемый writable data volume, и исходящий доступ к архивируемым страницам. Убедитесь, что Shiori объясняет причину сбоя, не повреждает существующее состояние и возобновляет работу после восстановления корректного условия. Сохраните редактированный фрагмент лога и время восстановления. Вместе эти проверки охватывают поведение, durability и operability, а не только 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 и владельца mount. Проследите application log через полный тест — сохраните закладку с архивированным содержимым, найдите её, измените теги и убедитесь, что архив остаётся доступным после изменения исходной страницы, — и отметьте все migrations до того, как направлять route на production-трафик.
Домены, proxy headers и порт 8080
Считайте внешний URL Shiori конфигурацией, которая должна сохраняться между redeploy. Сначала направьте UI и API через стабильный HTTPS origin, затем направьте hostname на порт 8080, сохранив исходные host и scheme.
Checklist доступности deployment поможет доказать, что запросы попадают в container. После этого известную проблему — архивация не работает из-за неправильных зависимостей Chromium или разрешений файловой системы — следует искать в Shiori, его состоянии или workload, а не в автоматизации сертификатов.
Обновляйте Shiori без догадок
Первый полезный operational metric для Shiori — возможность сохранить закладку с архивированным содержимым, найти её, изменить теги и убедиться, что архив остаётся доступным после изменения исходной страницы. Дополните его сигналами saturation для захвата страниц через browser, размера архива, thumbnails и исходящих запросов. Probe, проверяющий только процесс, не должен вызывать дорогостоящие зависимости или перезапускать container из-за кратковременной недоступности upstream.
Считайте upgrade изменением данных, поскольку database migrations Shiori и зависимости для захвата страниц могут менять поведение архива. Фиксируйте версии, репетируйте обновление на восстановленном состоянии и храните предыдущий image, пока rollback остаётся возможным. Если архивация не работает из-за неправильных зависимостей Chromium или разрешений файловой системы, сохраните логи до перезапуска: обычно именно в них содержится сообщение о причине.
Что Dockup следует автоматизировать для Shiori
Platform layer для Shiori включает порт 8080, ingress, TLS, runtime-конфигурацию, storage и доступность зависимостей. Dockup может воспроизводить эти компоненты для собственной инфраструктуры или сервера, который подключает клиент.
Затем оператор завершает product layer: направляет UI и API через стабильный HTTPS origin; применяет это правило доступа — заменяет initial account, ограничивает public sharing и считает архивированные private URL конфиденциальным содержимым; а также запускает сценарий «сохранить закладку с архивированным содержимым, найти её, изменить теги и убедиться, что архив остаётся доступным после изменения исходной страницы». Запись результатов этого теста вместе с deployment помогает не путать автоматизированное provisioning с готовностью приложения.
Часто задаваемые вопросы
Что требуется Shiori для deployment в production?
Направьте container Shiori на порту 8080 через один HTTPS origin. Внешние требования для доставки — writable data volume и исходящий доступ к архивируемым страницам. Не объявляйте Shiori готовым, пока не сможете сохранить закладку с архивированным содержимым, найти её, изменить теги и убедиться, что архив остаётся доступным после изменения исходной страницы.
Какие данные Shiori нужно включить в backup?
Сохраняйте /shiori и включайте database, содержимое архивированных страниц, thumbnails и конфигурацию в один recovery manifest. Чистое восстановление Shiori считается успешным только тогда, когда закладки, теги, файлы архивов и аккаунты вернулись, а недоступная исходная ссылка по-прежнему открывает сохранённое содержимое.
Требуется ли Shiori HTTPS за reverse proxy?
Используйте HTTPS для публичного origin Shiori, а порт 8080 оставьте во внутреннем route. Корректно примените настройку Shiori: направьте UI и API через стабильный HTTPS origin. Для Shiori HTTPS защищает credentials и пользовательское содержимое при передаче и обеспечивает согласованное поведение клиентов, зависящее от origin.
Как тестировать upgrade Shiori?
Восстановите текущее состояние Shiori в изолированном deployment, примените candidate version и повторите приёмочный сценарий. Уделите особое внимание тому, что database migrations Shiori и зависимости для захвата страниц могут менять поведение архива. Храните предыдущий image Shiori, пока не будут понятны границы data migration и rollback.