Как самостоятельно разместить Wallabag в 2026 году: импорт, база данных и фоновые задачи
Практическое руководство по самостоятельному размещению Wallabag: Docker, порты, постоянное хранение данных, TLS, безопасность, резервное копирование и проблемы, которые мешают использовать сервис в production. С проверками.
Самая короткая демонстрация Wallabag доказывает лишь то, что процесс слушает порт 80. Для production нужны более убедительные доказательства. Сервис должен проходить этот сценарий даже после замены контейнера: сохранять обычную статью и сложную страницу, выполнять фоновое получение содержимого, синхронизировать мобильный клиент и искать архивированный контент.
Wallabag разворачивают с понятной целью: создать архив «прочитать позже», избавляющий страницы от лишнего содержимого. Самая распространённая ловушка при развёртывании заключается в том, что ресурсы или перенаправления после входа используют HTTP из-за неправильной переменной домена. Поэтому обработке публичного URL и сохранению состояния нужно уделить столько же внимания, сколько и запуску образа.
Превратите локальную команду в проверяемый сервис
Следующая команда делает границу контейнера видимой, не создавая видимость, будто она настраивает все внешние сервисы.
docker run -d \
--name wallabag \
--restart unless-stopped \
-p 127.0.0.1:80:80 \
-v wallabag-data:/var/www/wallabag/data \
-e SYMFONY__ENV__DOMAIN_NAME=https://app.example.com \
wallabag/wallabag:latest
Перед открытием входящего трафика проверьте итоговые переменные окружения, mounts и listener. Добавьте проверенные параметры подключения к Postgres или MariaDB, Redis и scheduled import workers; для внутренних сервисов используйте приватные имена. Успешный запуск завершается не тогда, когда docker ps выводит Up, а когда вы можете сохранить обычную статью и сложную страницу, выполнить фоновое получение содержимого, синхронизировать мобильный клиент и найти архивированный контент.
От чего зависит Wallabag
Проведите вокруг Wallabag три границы: входящий трафик к порту 80, постоянное состояние и вспомогательные требования. Контейнер можно заменить, но для двух других компонентов нужно явно назначить ответственных. Сетевой контракт Wallabag включает Postgres или MariaDB, Redis и scheduled import workers. Держите внутренние endpoints во внутреннем DNS, разрешайте только необходимые исходящие подключения и выдайте Wallabag service credential с ограниченной областью действия.
Схема считается полной, когда чистый клиент может сохранить обычную статью и сложную страницу, выполнить фоновое получение содержимого, синхронизировать мобильный клиент и найти архивированный контент. Собирайте данные о времени выполнения и ресурсах для загрузки страниц, работы parser, скачивания изображений, queues и роста базы данных. Если транзакция завершается ошибкой, первая граница, которая ведёт себя не так, как описано в документации, подсказывает, нужно ли проверять маршрутизацию, локальные ресурсы или вспомогательный сервис.
Защитите Wallabag после начальной настройки
Не переносите предположения о безопасности из локального руководства. Главные специфические риски Wallabag — сохранение credentials по умолчанию и пропуск настройки trusted proxy. Поэтому перед публикацией reader в production следует удалить credentials по умолчанию, защитить import tokens и настроить trusted proxies.
SYMFONY__ENV__DOMAIN_NAME — это конфигурация, а не secret; храните её значение явно, защищая при этом отдельные credentials, которые использует Wallabag. Ограничьте доступ к файловой системе и сети, защитите setup endpoints и задайте лимиты на загрузку, requests или execution для загрузки страниц, работы parser, скачивания изображений, queues и роста базы данных.
Сделайте публичный origin однозначным
Опубликуйте Wallabag на одном HTTPS hostname, а обычный порт 80 оставьте приватным. Укажите в имени домена итоговый HTTPS URL. Это не позволит браузерам и API-клиентам узнать о двух конкурирующих адресах.
С чистого клиента выполните проверенную транзакцию и определите первый запрос, завершившийся ошибкой. Если проблема связана с DNS или TLS, воспользуйтесь руководством по custom domain. Считайте ситуацию «ресурсы или перенаправления после входа используют HTTP из-за неправильной переменной домена» отдельной диагностикой приложения после проверки маршрута.
Отделите заменяемые контейнеры от постоянных данных
Набор данных для восстановления включает базу данных, изображения, импортированный контент и конфигурацию. Подключите /var/www/wallabag/data до начальной настройки, запишите безвредные тестовые данные и замените контейнер, чтобы убедиться, что этот путь действительно сохраняется. Volume защищает данные от замены контейнера, но не от потери хоста, случайного удаления или повреждения на уровне приложения.
Создавайте резервные копии с учётом источника данных: при необходимости используйте logical dumps для работающих баз данных, а файлы копируйте только из согласованного состояния. Храните одну зашифрованную копию за пределами хоста Wallabag. Критерий успешного восстановления должен быть конкретным: статьи, теги, аннотации, пользователи и API tokens возвращаются, а мобильный клиент синхронизируется. В руководстве по резервному копированию с проверенным восстановлением объясняется, почему одного успешного выполнения job недостаточно.
Какие данные собрать до запуска Wallabag
Для Wallabag заранее определите проверенную транзакцию: сохраните обычную статью и сложную страницу, выполните фоновое получение содержимого, синхронизируйте мобильный клиент и найдите архивированный контент. Зафиксируйте её prerequisites, ожидаемый response и шаги очистки в системе контроля версий, не добавляя secret values. Зафиксируйте версию image, на которой основан этот эталон.
Используйте транзакцию для проверки замены и независимого восстановления. Восстановленный сервис считается приемлемым только тогда, когда статьи, теги, аннотации, пользователи и API tokens возвращаются, а мобильный клиент синхронизируется. Одновременно отслеживайте загрузку страниц, работу parser, скачивание изображений, queues и рост базы данных, а самую медленную или наиболее ограниченную часть превратите в service-level alert.
В gate также должен входить negative case: временно запретите тестовой identity доступ к Postgres или MariaDB, Redis и scheduled import workers. Убедитесь, что Wallabag выдаёт понятную actionable error, сохраняя данные, затем восстановите корректное состояние и повторите проверенную транзакцию. Хранение обоих результатов не позволит поверхностному health endpoint стать единственным доказательством работоспособности в production.
Эксплуатируйте Wallabag с учётом реального bottleneck
Стройте dashboards вокруг загрузки страниц, работы parser, скачивания изображений, queues и роста базы данных. График CPU без контекста этой нагрузки не объяснит, почему Wallabag работает медленно. Добавьте synthetic или scheduled check, который пытается сохранить обычную статью и сложную страницу, выполнить фоновое получение содержимого, синхронизировать мобильный клиент и найти архивированный контент, используя безвредные тестовые данные.
Перед обновлением учтите специфический риск этого приложения: migrations Wallabag, поведение parser и конфигурацию workers нужно тестировать на репрезентативных сохранённых страницах. Восстановите свежую резервную копию в изолированном deployment, выполните там migrations и сравните поведение. Если ресурсы или перенаправления после входа используют HTTP из-за неправильной переменной домена, сначала проверьте соответствующую границу — публичный origin, storage или dependency, — и только потом меняйте посторонние настройки.
Используйте Dockup для platform layer
Для Wallabag Dockup может создать route и TLS certificate, сохранить mounts, передать secrets и разместить Postgres или MariaDB, Redis и scheduled import workers в приватной сети, разворачивая сервис как в Dockup, так и на подключённых серверах.
Release gate по-прежнему должен включать конкретную транзакцию Wallabag: сохранение обычной статьи и сложной страницы, фоновое получение содержимого, синхронизацию мобильного клиента и поиск архивированного контента. Также проверьте состояние после восстановления: статьи, теги, аннотации, пользователи и API tokens возвращаются, а мобильный клиент синхронизируется. Эти две проверки показывают, работает ли deployment и можно ли его восстановить.
Часто задаваемые вопросы
Что нужно Wallabag для deployment в production?
Направьте контейнер Wallabag на порт 80 через один HTTPS origin. Сетевые зависимости включают Postgres или MariaDB, Redis и scheduled import workers. Не объявляйте Wallabag готовым, пока не сможете сохранить обычную статью и сложную страницу, выполнить фоновое получение содержимого, синхронизировать мобильный клиент и найти архивированный контент.
Какие данные Wallabag должны входить в резервную копию?
Сохраняйте /var/www/wallabag/data и включайте базу данных, изображения, импортированный контент и конфигурацию в один recovery manifest. Чистое восстановление Wallabag считается успешным только тогда, когда статьи, теги, аннотации, пользователи и API tokens возвращаются, а мобильный клиент синхронизируется.
Нужен ли Wallabag HTTPS за reverse proxy?
Используйте HTTPS для публичного origin Wallabag, а порт 80 оставьте во внутреннем маршруте. Корректно примените настройку Wallabag: укажите в имени домена итоговый HTTPS URL. Для Wallabag HTTPS защищает credentials или пользовательский контент при передаче и обеспечивает согласованное поведение клиентов, зависящее от origin.
Как тестировать обновление Wallabag?
Восстановите текущее состояние Wallabag в изолированном deployment, примените candidate version и повторите acceptance transaction. Уделите этому особое внимание, поскольку migrations Wallabag, поведение parser и конфигурацию workers нужно тестировать на репрезентативных сохранённых страницах. Сохраняйте предыдущий image Wallabag, пока не будут понятны границы миграции данных и rollback.