Как разместить Wallos на собственном сервере в 2026 году: продления, уведомления и SQLite
Разверните Wallos с правильным портом, надёжным хранилищем, TLS, аутентификацией и резервным копированием. Устраните проблему смещения дат продления из-за неверного TZ в production.
Большинство инструкций по установке Wallos заканчиваются после первой загрузки страницы. Это слишком рано: даты продления могут смещаться из-за неверного TZ или каталога SQLite, доступного только для чтения. Полезный production-тест требует большего — создайте подписки с разными расчётными периодами, задайте даты продления, запустите сценарий уведомлений и проверьте итоговые суммы в выбранной валюте.
Роль Wallos проста: это трекер подписок с датами продления и уведомлениями. Его эксплуатационная граница включает не только web-процесс, поэтому до появления реальных данных нужно явно определить зависимость, хранимое состояние и публичный маршрут.
Изучите Wallos до работы с Docker
Разделите Wallos на четыре составляющие: ingress, listener на 80, постоянное состояние и вспомогательные сервисы или локальные ресурсы. Локальное требование среды выполнения — постоянные каталоги базы данных и загружаемых логотипов, а также доставка уведомлений. Выделяйте этот ресурс и контролируйте его вместе с контейнером, не открывая отдельный сетевой сервис, не связанный с задачей.
Выполните заведомо рабочую транзакцию — создайте подписки с разными расчётными периодами, задайте даты продления, запустите сценарий уведомлений и проверьте итоговые суммы в выбранной валюте, — прежде чем считать разделение завершённым. Измерьте запланированную работу уведомлений, объём хранилища логотипов, записи в SQLite и корректность часового пояса, а результат сохраните вместе с записью о развёртывании. Это даст и критерий приёмки, и первую базовую оценку ёмкости.
Диагностируйте Wallos, который выглядит работоспособным
Для Wallos отслеживайте не процесс, а транзакцию: создайте подписки с разными расчётными периодами, задайте даты продления, запустите сценарий уведомлений и проверьте итоговые суммы в выбранной валюте. Сопоставляйте задержку и частоту ошибок с запланированной работой уведомлений, объёмом хранилища логотипов, записями в SQLite и корректностью часового пояса, чтобы alert указывал на ограниченный компонент.
Репетиция обновления должна учитывать, что миграции базы данных Wallos нужно тестировать с данными о датах и валютах до замены работающего image. Восстановите данные, выполните миграцию и запустите транзакцию перед заменой в production. Если даты продления смещаются из-за неверного TZ или каталог SQLite доступен только для чтения, не удаляйте данные ради успешного запуска; последовательно сравните версию, переменные, mounts и доступность зависимостей.
Превратите smoke-тест Wallos в проверку релиза
В записи о релизе Wallos нужны факты, а не формулировка «всё работает». Сохраните digest выбранного image, checksum конфигурации, публичное имя хоста и результат с отметкой времени для следующих действий: создать подписки с разными расчётными периодами, задать даты продления, запустить сценарий уведомлений и проверить итоговые суммы в выбранной валюте. Используйте тестовые данные, не относящиеся к production, чтобы проверку можно было выполнять после каждого развёртывания.
Отдельно подтвердите два события жизненного цикла. Замена контейнера должна сохранять обычную работу; чистое восстановление должно вернуть подписки, категории, логотипы и настройки уведомлений с неизменными датами продления. Пока выполняются проверки, измеряйте запланированную работу уведомлений, объём хранилища логотипов, записи в SQLite и корректность часового пояса, а результат сохраняйте как ожидаемый диапазон для этой версии.
Проверьте и запрещённое или некорректное условие: отправьте безвредные данные около ограничения ресурса или формата, связанного с этой границей: даты продления смещаются из-за неверного TZ или каталог SQLite доступен только для чтения. Wallos должен завершиться с диагностируемой ошибкой и не перезаписать корректное состояние. Верните допустимое условие, повторно запустите пример и приложите соответствующие redacted-логи. Эти артефакты дадут конкретные основания для будущего решения об откате.
Сделайте запуск Wallos воспроизводимым
Запуск в production-окружении намеренно выглядит скучно: именованное состояние, явный порт и отсутствие секретов внутри image.
docker run -d \
--name wallos \
--restart unless-stopped \
-p 127.0.0.1:80:80 \
-v wallos-data:/var/www/html/db \
-e TZ=UTC \
bellamy/wallos:latest
Этот пример — базовый вариант, а не полностью готовый supporting stack. До открытия доступа подтвердите локальное требование: постоянные каталоги базы данных и загружаемых логотипов, а также доставку уведомлений. Проверьте фактические mounts и listener, затем попробуйте создать подписки с разными расчётными периодами, задать даты продления, запустить сценарий уведомлений и проверить итоговые суммы в выбранной валюте. Зафиксируйте рабочий image до следующего перезапуска.
Найдите каждый постоянный байт в Wallos
Составьте перечень всех постоянных артефактов: базы данных подписок, загруженных логотипов и настроек уведомлений. Подключите /var/www/html/db до bootstrap, запишите безвредные тестовые данные и замените контейнер, чтобы доказать, что этот путь действительно сохраняется. Включите конфигурацию, которая изменяет способ интерпретации сохранённых данных, а не только самый большой каталог.
Настройте retention, копируйте резервные копии за пределы хоста и выполните восстановление в чистом окружении. Проверка Wallos считается завершённой, когда подписки, категории, логотипы и настройки уведомлений возвращаются с неизменными датами продления. Если в плане предусмотрены snapshots, используйте рекомендации PITR и snapshots, чтобы задокументировать, что именно можно восстановить каждым механизмом.
Назначьте для Wallos единый канонический адрес
Выпуск TLS — только половина маршрута Wallos. Обслуживайте приложение по HTTPS и задайте его часовой пояс. Направляйте трафик внутри на 80 и передавайте внешнюю схему, чтобы генерируемые URL и secure cookies оставались согласованными.
Проверяйте полный сценарий Wallos из чистой сети, а не только корневую страницу. Ошибку 502 или сбой сертификата можно изолировать с помощью автоматической настройки домена и TLS. Если трафик доходит до процесса, а даты продления смещаются из-за неверного TZ или каталог SQLite доступен только для чтения, диагностируйте проблему в месте её возникновения, а не добавляйте новые redirect.
Защитите ценную часть Wallos
После первого входа проверьте, что может делать анонимный посетитель, обычный пользователь и администратор. Ошибка, которой следует избежать в Wallos, — слабая защита первой учётной записи на instance, доступном из интернета. Предусмотренная политика — защитить учётную запись, сохранить токены уведомлений в секрете и явно задать TZ, чтобы даты продления не смещались.
TZ управляет поведением, а не конфиденциальностью; проверяйте его тип и значение, а настоящие credentials Wallos храните отдельно. Разделяйте учётные записи зависимостей и человеческие учётные записи, по возможности запрещайте неиспользуемый egress и ограничивайте работу, на которую влияют запланированная работа уведомлений, хранилище логотипов, записи в SQLite и корректность часового пояса.
Где Dockup упрощает работу с Wallos
Шаблон Dockup должен описывать image, порт 80, mounts, интервалы health-проверок, домен, TLS и доставку секретов. Dockup должен сохранять настройки среды выполнения Wallos, пока оператор подтверждает это локальное требование: постоянные каталоги базы данных и загружаемых логотипов, а также доставку уведомлений. Одно и то же развёртывание может работать на серверах Dockup или на ресурсах, подключённых клиентом.
После публикации маршрута примените публичную настройку и попробуйте создать подписки с разными расчётными периодами, задать даты продления, запустить сценарий уведомлений и проверить итоговые суммы в выбранной валюте. Создавайте резервные копии базы данных подписок, загруженных логотипов и настроек уведомлений и включите проверку восстановления в эксплуатационный план; это зоны ответственности Wallos, которые остаются видимыми и после подготовки инфраструктуры.
Часто задаваемые вопросы
Что нужно Wallos для развёртывания в production?
Направьте контейнер Wallos на порт 80 через один HTTPS-origin. Локальное требование среды выполнения — постоянные каталоги базы данных и загружаемых логотипов, а также доставка уведомлений. Не считайте Wallos готовым, пока не сможете создать подписки с разными расчётными периодами, задать даты продления, запустить сценарий уведомлений и проверить итоговые суммы в выбранной валюте.
Какие данные Wallos нужно включать в резервную копию?
Сохраняйте /var/www/html/db и включайте базу данных подписок, загруженные логотипы и настройки уведомлений в один manifest восстановления. Чистое восстановление Wallos считается успешным только тогда, когда подписки, категории, логотипы и настройки уведомлений возвращаются с неизменными датами продления.
Нужен ли Wallos HTTPS за reverse proxy?
Используйте HTTPS для публичного origin Wallos, а порт 80 оставьте во внутреннем маршруте. Корректно примените настройку Wallos: обслуживайте приложение по HTTPS и задайте его часовой пояс. В Wallos HTTPS защищает credentials или пользовательское содержимое при передаче и обеспечивает согласованное поведение клиента, зависящее от origin.
Как тестировать обновление Wallos?
Восстановите текущее состояние Wallos в изолированном развёртывании, примените candidate-версию и повторите приёмочную транзакцию. Уделите этому особое внимание: миграции базы данных Wallos нужно тестировать с данными о датах и валютах до замены работающего image. Сохраняйте предыдущий image Wallos, пока не будут понятны границы миграции данных и отката.