Как да хоствате Wallabag самостоятелно през 2026 г.: импортиране, база данни и фонови задачи

Най-кратката демонстрация на Wallabag доказва, че даден процес слуша на порт 80. Production средата изисква по-солидни доказателства. Тя трябва да премине този сценарий дори след като контейнерът е заменен: запазване на обикновена статия и на трудна за обработка страница, изпълнение на фоново извличане, синхронизиране на мобилен клиент и търсене в архивирано съдържание.

Wallabag се внедрява с ясна цел: архив за четене по-късно, който премахва излишните елементи от страниците. Най-честият проблем при внедряването му е, че ресурсите или redirect-ите при вход използват HTTP, защото променливата за домейна е зададена неправилно. Затова обработката на публичния URL и устойчивото съхранение на данни трябва да получат същото внимание като стартирането на image-а.

Превърнете локалната команда в услуга, която може да се инспектира

Следната команда прави границата на контейнера видима, без да претендира, че конфигурира всяка външна услуга.

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, проверете разрешените environment настройки, mount-овете и listener-а. Добавете прегледаните настройки за връзка с Postgres или MariaDB, Redis и планираните import workers; използвайте private имена за private услугите. Успешното стартиране е налице, когато можете да запазите обикновена статия и трудна за обработка страница, да изпълните фоново извличане, да синхронизирате мобилен клиент и да търсите в архивирано съдържание, а не когато docker ps изведе Up.

От какво зависи Wallabag

Очертайте три граници около Wallabag: ingress към порт 80, устойчивото състояние и поддържащите изисквания. Контейнерът може да бъде заменен, но за останалите две граници трябва да има ясно определени отговорници. Мрежовият договор за Wallabag включва Postgres или MariaDB, Redis и планирани import workers. Дръжте private endpoint-ите във вътрешен DNS, разрешете само необходимите изходящи заявки и предоставете на Wallabag service credential с ограничен обхват.

Диаграмата е завършена, когато чист клиент може да запази обикновена статия и трудна за обработка страница, да изпълни фоново извличане, да синхронизира мобилен клиент и да търси в архивирано съдържание. Събирайте данни за времето и ресурсите при извличане на страници, работа на parser-а, изтегляне на изображения, опашки и нарастване на базата данни. Ако транзакцията се провали, първата граница, която не се държи според документацията, показва дали трябва да изследвате routing-а, локалния капацитет или поддържаща услуга.

Защитете Wallabag след bootstrap

Не пренасяйте допусканията за сигурност от локален tutorial. Специфичният проблем при Wallabag е запазването на credentials по подразбиране или пропускането на конфигурацията за trusted proxy. Затова production средата трябва да премахне credentials по подразбиране, да защити import token-ите и да конфигурира trusted proxies, преди да изложите четеца публично.

SYMFONY__ENV__DOMAIN_NAME е конфигурация, а не secret; запазете стойността му изрично, като защитите отделните credentials, използвани от Wallabag. Ограничете достъпа до файловата система и мрежата, защитете setup endpoint-ите и задайте лимити за upload, заявки или изпълнение около извличането на страници, работата на parser-а, изтеглянето на изображения, опашките и нарастването на базата данни.

Направете публичния origin недвусмислен

Публикувайте един HTTPS hostname за Wallabag; оставете raw порт 80 private. Задайте името на домейна като крайния HTTPS URL. Така браузърите и API клиентите няма да научават два конкуриращи се адреса.

От чист клиент изпълнете проверената транзакция и проверете първата заявка, която се проваля. Използвайте ръководството за custom domain, когато DNS или TLS са конфигурирани неправилно. Разглеждайте „ресурсите или redirect-ите при вход използват HTTP, защото променливата за домейна е зададена неправилно“ като отделна application диагноза, след като маршрутът е доказано работещ.

Разделете заменяемите контейнери от постоянните данни

Наборът за устойчиво възстановяване включва базата данни, изображенията, импортираното съдържание и конфигурацията. Mount-нете /var/www/wallabag/data преди bootstrap, запишете безвредни примерни данни и заменете контейнера, за да докажете, че този path действително е persistent. Volume защитава данните при замяна на контейнера, но не и при загуба на host-а, случайно изтриване или повреда на ниво приложение.

Създавайте backup-и, които разбират източника на данните: използвайте logical dump-ове за активни бази данни, когато е необходимо, и копирайте файлове само от консистентно състояние. Съхранявайте едно криптирано копие извън host-а на Wallabag. Критерият за приемане при restore е конкретен — статиите, етикетите, анотациите, потребителите и API token-ите се възстановяват, а мобилният клиент се синхронизира. Ръководството за backup-и, тествани чрез restore обяснява защо единствено успешното изпълнение на job не е достатъчно.

Какви доказателства да съберете, преди Wallabag да влезе в production

За Wallabag дефинирайте проверена транзакция преди стартирането: запазване на обикновена статия и трудна за обработка страница, изпълнение на фоново извличане, синхронизиране на мобилен клиент и търсене в архивирано съдържание. Съхранявайте нейните предпоставки, очаквания отговор и стъпки за почистване във version control, без secret стойности. Фиксирайте image-а, използван за установяване на този baseline.

Използвайте транзакцията, за да валидирате замяна и независимо възстановяване. Възстановената услуга е приемлива само когато статиите, етикетите, анотациите, потребителите и API token-ите се върнат, а мобилният клиент се синхронизира. Едновременно с това наблюдавайте извличането на страници, работата на parser-а, изтеглянето на изображения, опашките и нарастването на базата данни и превърнете най-бавната или най-ограничената част в service-level alert.

Този gate се нуждае и от negative case: временно забранете на test identity достъпа до Postgres или MariaDB, Redis и планираните import workers. Потвърдете, че Wallabag извежда actionable error, като същевременно запазва данните, възстановете валидното състояние и повторете проверената транзакция. Съхраняването и на двата резултата не позволява на повърхностен health endpoint да се превърне в единственото production доказателство.

Експлоатирайте Wallabag според реалното му тясно място

Изградете dashboards около извличането на страници, работата на parser-а, изтеглянето на изображения, опашките и нарастването на базата данни. CPU графика без контекст за това натоварване не може да обясни защо Wallabag е бавен. Добавете synthetic или планирана проверка, която се опитва да запази обикновена статия и трудна за обработка страница, да изпълни фоново извличане, да синхронизира мобилен клиент и да търси в архивирано съдържание, използвайки безвредни тестови данни.

Преди upgrade отчетете следния специфичен за приложението риск: миграциите на Wallabag, поведението на parser-а и конфигурацията на worker-ите трябва да се тестват с представителни запазени страници. Възстановете скорошен backup в изолирано внедряване, изпълнете миграциите там и сравнете поведението. Ако ресурсите или redirect-ите при вход използват HTTP, защото променливата за домейна е зададена неправилно, проверете съответната граница — публичния origin, storage-а или dependency-то — преди да променяте несвързани настройки.

Използвайте Dockup за platform слоя

За Wallabag Dockup може да създаде route и TLS сертификат, да запази mount-овете, да достави secret-ите и да постави Postgres или MariaDB, Redis и планираните import workers в private networking, като същевременно внедри приложението в Dockup или на свързани сървъри.

Release gate-ът все още е конкретната транзакция на Wallabag: запазване на обикновена статия и трудна за обработка страница, изпълнение на фоново извличане, синхронизиране на мобилен клиент и търсене в архивирано съдържание. Проверете и условието за restore — статиите, етикетите, анотациите, потребителите и API token-ите се възстановяват, а мобилният клиент се синхронизира. Тези две проверки показват дали внедряването работи и дали може да бъде възстановено.

Често задавани въпроси

Какво е необходимо на Wallabag за production внедряване?

Маршрутизирайте контейнера на Wallabag на порт 80 през един HTTPS origin. Поддържащото мрежово изискване включва Postgres или MariaDB, Redis и планирани import workers. Не обявявайте Wallabag за готов, преди да можете да запазите обикновена статия и трудна за обработка страница, да изпълните фоново извличане, да синхронизирате мобилен клиент и да търсите в архивирано съдържание.

Кои данни на Wallabag трябва да бъдат включени в backup?

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

Необходим ли е HTTPS на Wallabag зад reverse proxy?

Използвайте HTTPS за публичния origin на Wallabag и оставете порт 80 във вътрешния route. Приложете правилно настройката на Wallabag: задайте името на домейна като крайния HTTPS URL. За Wallabag HTTPS защитава credentials или потребителско съдържание при пренос и поддържа последователно поведение на клиентите, зависещо от origin-а.

Как трябва да се тества upgrade на Wallabag?

Възстановете текущото състояние на Wallabag в изолирано внедряване, приложете кандидат-версията и повторете транзакцията за приемане. Обърнете специално внимание, тъй като миграциите на Wallabag, поведението на parser-а и конфигурацията на worker-ите трябва да се тестват с представителни запазени страници. Запазете предишния image на Wallabag, докато границите на миграцията на данните и rollback-а не бъдат изяснени.