Як самостійно розгорнути Wallos у 2026 році: поновлення, сповіщення та SQLite

Більшість інструкцій зі встановлення Wallos закінчуються на першому завантаженні сторінки. Це зарано: дати поновлення можуть зміщуватися через неправильний TZ або доступ до каталогу SQLite лише для читання. Корисний production-тест має бути вимогливішим — створіть підписки з різними платіжними циклами, задайте дати поновлення, запустіть надсилання сповіщень і перевірте підсумки у вибраній валюті.

Роль Wallos проста: це трекер підписок із датами поновлення та сповіщеннями. Його операційна межа охоплює більше, ніж вебпроцес, тому до надходження реальних даних потрібно явно визначити залежність, стан, що зберігається, і публічний маршрут.

Вивчіть 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 і коректність часового поясу та зберігайте результат як очікуваний envelope для цієї версії.

Також перевірте заборонену або некоректну умову: передайте безпечні тестові дані поблизу обмеження ресурсу чи формату, пов’язаного з цією межею: дати поновлення зміщуються через неправильний TZ або каталог SQLite доступний лише для читання. Wallos має завершуватися з помилкою, яку можна діагностувати, і не повинен перезаписувати справний стан. Поверніть коректну умову, повторно запустіть тестовий сценарій і додайте відповідні журнали з видаленими чутливими даними. Ці артефакти дають майбутньому рішенню про rollback конкретні докази.

Зробіть запуск 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

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

Знайдіть кожен байт, який зберігається у Wallos

Складіть перелік усіх постійних артефактів: бази даних підписок, завантажених логотипів і налаштувань сповіщень. Підключіть /var/www/html/db до bootstrap, запишіть безпечні тестові дані та замініть контейнер, щоб довести фактичну постійність цього шляху. Додайте конфігурацію, яка змінює спосіб інтерпретації збережених даних, а не лише найбільший каталог.

Визначте політику зберігання, копіюйте резервні копії за межі хоста та виконайте відновлення в чистому середовищі. Перевірку Wallos можна вважати завершеною, коли підписки, категорії, логотипи та налаштування сповіщень повертаються без змін у датах поновлення. Якщо план передбачає snapshots, скористайтеся порівнянням PITR і snapshots, щоб задокументувати, які дані може відновити кожен механізм.

Визначте для Wallos одну канонічну адресу

Видача TLS-сертифіката — лише половина маршруту Wallos. Обслуговуйте застосунок через HTTPS і задайте його часовий пояс. Спрямовуйте внутрішній трафік на 80 і передавайте зовнішню схему, щоб згенеровані URL-адреси та secure cookies залишалися узгодженими.

Використовуйте повний сценарій Wallos із чистої мережі, а не лише кореневу сторінку. Помилку 502 або збій сертифіката можна ізолювати за допомогою автоматичного налаштування домену й TLS. Якщо трафік доходить до процесу, а дати поновлення зміщуються через неправильний TZ або каталог SQLite доступний лише для читання, діагностуйте цю умову в місці її виникнення, а не додавайте нові redirect.

Захистіть найціннішу частину Wallos

Після першого входу перевірте, що саме можуть робити анонімний відвідувач, звичайний користувач і адміністратор. Проблема Wallos, якої слід уникати, — слабкий захист першого облікового запису в інстансі, доступному з інтернету. Передбачена політика — захистити обліковий запис, зберігати токени сповіщень у таємниці та явно задати TZ, щоб дати поновлення не зміщувалися.

TZ керує поведінкою, а не конфіденційністю; перевіряйте його тип і значення, а справжні облікові дані Wallos зберігайте окремо. Розділяйте облікові записи залежностей і облікові записи людей, за можливості забороняйте невикористовуваний egress і обмежуйте роботу, на яку впливають обсяг запланованих сповіщень, використання сховища логотипів, операції запису в SQLite та коректність часового поясу.

Як Dockup спрощує роботу з Wallos

Шаблон Dockup має містити image, порт 80, mounts, параметри health-check, домен, TLS і передавання секретів. Dockup має зберігати налаштування середовища виконання Wallos, поки оператор підтверджує цю локальну вимогу: постійні каталоги бази даних і завантажених логотипів, а також доставка сповіщень. Те саме розгортання можна спрямувати на сервери Dockup або ресурси, підключені клієнтом.

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

Часті запитання

Що потрібно Wallos для production-розгортання?

Спрямуйте контейнер Wallos на порт 80 через один HTTPS-origin. Локальна вимога середовища виконання — постійні каталоги бази даних і завантажених логотипів, а також доставка сповіщень. Не вважайте Wallos готовим, доки не зможете створити підписки з різними платіжними циклами, задати дати поновлення, запустити надсилання сповіщень і перевірити підсумки у вибраній валюті.

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

Забезпечте постійність /var/www/html/db і додайте базу даних підписок, завантажені логотипи та налаштування сповіщень до одного маніфесту відновлення. Чисте відновлення Wallos вважається успішним лише тоді, коли підписки, категорії, логотипи та налаштування сповіщень повертаються без змін у датах поновлення.

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

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

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

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