Як розгорнути Wallabag на власному сервері у 2026 році: імпорт, база даних і фонові завдання

Найкоротша демонстрація 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

Перш ніж відкривати ingress, перевірте підсумкове середовище, монтування та listener. Додайте перевірені параметри підключення до Postgres або MariaDB, Redis і запланованих worker-процесів імпорту; для приватних сервісів використовуйте приватні імена. Успішний запуск завершується не тоді, коли docker ps виводить Up, а коли ви можете зберегти звичайну статтю та складну сторінку, виконати фонове отримання даних, синхронізувати мобільний клієнт і знайти заархівований контент.

Від чого залежить Wallabag

Окресліть навколо Wallabag три межі: ingress до порту 80, постійний стан і допоміжні вимоги. Контейнер можна замінити, але для двох інших складових потрібні чітко визначені відповідальні. Мережевий контракт Wallabag охоплює Postgres або MariaDB, Redis і заплановані worker-процеси імпорту. Залишайте приватні endpoint-и у внутрішньому DNS, дозволяйте лише необхідні вихідні підключення та надайте Wallabag облікові дані сервісу з обмеженими правами.

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

Посильте захист Wallabag після bootstrap

Не переносіть припущення щодо безпеки з локального tutorial-а. Специфічна проблема Wallabag — збереження стандартних облікових даних або пропуск налаштування trusted proxy. Тому перед відкриттям reader-а в production потрібно видалити стандартні облікові дані, захистити токени імпорту та налаштувати trusted proxies.

SYMFONY__ENV__DOMAIN_NAME — це конфігурація, а не секрет; залишайте його значення явним, захищаючи окремі облікові дані, які використовує Wallabag. Обмежте доступ до файлової системи й мережі, захистіть endpoint-и налаштування та визначте ліміти завантаження, запитів або виконання для отримання сторінок, роботи parser-а, завантаження зображень, черг і збільшення бази даних.

Зробіть публічне джерело однозначним

Відкрийте для Wallabag один HTTPS hostname, а необроблений порт 80 залиште приватним. Укажіть як ім’я домену кінцеву HTTPS URL-адресу. Це не дасть браузерам і API-клієнтам дізнатися про дві адреси, що конкурують між собою.

У чистому клієнті виконайте перевірену транзакцію та перевірте перший запит, який завершується помилкою. Скористайтеся посібником із власного домену, якщо DNS або TLS налаштовано неправильно. Розглядайте ситуацію «ресурси або перенаправлення під час входу використовують HTTP через неправильну змінну домену» як окрему діагностику застосунку після підтвердження коректності маршруту.

Відокремте змінні контейнери від постійних даних

Набір даних для надійного відновлення охоплює базу даних, зображення, імпортований контент і конфігурацію. Змонтуйте /var/www/wallabag/data до bootstrap, запишіть нешкідливі тестові дані та замініть контейнер, щоб довести, що цей шлях справді постійний. Volume захищає дані від заміни контейнера, але не від втрати хоста, випадкового видалення або пошкодження на рівні застосунку.

Створюйте резервні копії з урахуванням джерела даних: за потреби використовуйте logical dump для активних баз даних, а файли копіюйте лише зі узгодженого стану. Зберігайте одну зашифровану копію окремо від хоста Wallabag. Критерій приймання відновлення має бути конкретним: статті, теги, анотації, користувачі та API-токени повертаються, а мобільний клієнт синхронізується. У посібнику з резервного копіювання, яке було перевірено відновленням пояснюється, чому одного успішного виконання job недостатньо.

Які докази зібрати до запуску Wallabag

Для Wallabag визначте перевірену транзакцію до запуску: збережіть звичайну статтю та складну сторінку, виконайте фонове отримання даних, синхронізуйте мобільний клієнт і знайдіть заархівований контент. Збережіть її передумови, очікувану відповідь і кроки очищення у version control без секретних значень. Зафіксуйте image, який використовувався для створення цього еталона.

Використайте транзакцію для перевірки заміни та незалежного відновлення. Відновлений сервіс можна вважати прийнятним лише тоді, коли статті, теги, анотації, користувачі та API-токени повертаються, а мобільний клієнт синхронізується. Одночасно спостерігайте за отриманням сторінок, роботою parser-а, завантаженням зображень, чергами та збільшенням бази даних, а найповільнішу або найбільш обмежену частину перетворіть на alert рівня сервісу.

Gate також має містити негативний сценарій: тимчасово забороніть тестовій identity доступ до Postgres або MariaDB, Redis і запланованих worker-процесів імпорту. Переконайтеся, що Wallabag видає зрозумілу помилку та зберігає дані, відновіть коректний стан і повторіть перевірену транзакцію. Збереження обох результатів не дає поверхневому health endpoint-у стати єдиним доказом готовності production.

Експлуатуйте Wallabag з урахуванням його реального bottleneck

Створіть dashboards для отримання сторінок, роботи parser-а, завантаження зображень, черг і збільшення бази даних. Графік CPU без контексту цього навантаження не пояснить, чому Wallabag працює повільно. Додайте synthetic або заплановану перевірку, яка на нешкідливих тестових даних намагається зберегти звичайну статтю та складну сторінку, виконати фонове отримання даних, синхронізувати мобільний клієнт і знайти заархівований контент.

Перед оновленням врахуйте специфічний для цього застосунку ризик: міграції Wallabag, поведінку parser-а та конфігурацію worker-ів потрібно тестувати на репрезентативних збережених сторінках. Відновіть свіжу резервну копію в ізольованому deployment-і, виконайте там міграції та порівняйте поведінку. Якщо ресурси або перенаправлення під час входу використовують HTTP через неправильну змінну домену, перевірте відповідну межу — публічне джерело, storage або dependency — перш ніж змінювати непов’язані налаштування.

Використовуйте Dockup для platform layer

Для Wallabag Dockup може створити route і TLS certificate, зберегти mounts, доставити secrets і розмістити Postgres або MariaDB, Redis та заплановані worker-процеси імпорту у приватній мережі, розгортаючи їх у Dockup або на підключених серверах.

Gate релізу все одно має охоплювати конкретну транзакцію Wallabag: зберегти звичайну статтю та складну сторінку, виконати фонове отримання даних, синхронізувати мобільний клієнт і знайти заархівований контент. Також перевірте умову відновлення: статті, теги, анотації, користувачі та API-токени повертаються, а мобільний клієнт синхронізується. Ці дві перевірки показують, чи працює deployment і чи можна його відновити.

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

Що потрібно Wallabag для deployment-у в production?

Маршрутизуйте контейнер Wallabag через порт 80 до одного HTTPS origin. Мережева вимога для допоміжних сервісів — Postgres або MariaDB, Redis і заплановані worker-процеси імпорту. Не вважайте Wallabag готовим, доки не зможете зберегти звичайну статтю та складну сторінку, виконати фонове отримання даних, синхронізувати мобільний клієнт і знайти заархівований контент.

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

Збережіть /var/www/wallabag/data і додайте базу даних, зображення, імпортований контент і конфігурацію до одного recovery manifest. Чисте відновлення Wallabag вважається успішним лише тоді, коли статті, теги, анотації, користувачі та API-токени повертаються, а мобільний клієнт синхронізується.

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

Використовуйте HTTPS для публічного origin Wallabag, а порт 80 залиште у внутрішньому route. Правильно застосуйте налаштування Wallabag: укажіть як ім’я домену кінцеву HTTPS URL-адресу. Для Wallabag HTTPS захищає облікові дані або користувацький контент під час передавання та забезпечує узгоджену поведінку клієнта, залежну від origin.

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

Відновіть поточний стан Wallabag в ізольованому deployment-і, застосуйте candidate version і повторіть acceptance transaction. Приділіть особливу увагу тому, що міграції Wallabag, поведінку parser-а та конфігурацію worker-ів потрібно тестувати на репрезентативних збережених сторінках. Зберігайте попередній image Wallabag, доки не буде зрозумілою межа міграції даних і rollback.