Как да хоствате Wallos самостоятелно през 2026 г.: подновявания, известия и SQLite

Повечето бележки за инсталиране на Wallos приключват при първото зареждане на страницата. Това е твърде рано: датите на подновяване се изместват, защото TZ е зададен неправилно или директорията на SQLite е read-only. Полезният production тест е по-взискателен — създайте абонаменти с различни billing cycles, задайте дати на подновяване, изпълнете notification path и проверете общите суми в избраната валута.

Ролята на Wallos е ясна: subscription tracker с дати на подновяване и известия. Оперативният му обхват включва повече от web процеса, затова dependency, съхраняваното state и public route трябва да бъдат изрично описани, преди да постъпят реални данни.

Направете карта на Wallos, преди да използвате Docker

Разделете четири области при Wallos: ingress, listener-а на 80, durable state и supporting services или локален капацитет. Изискването на локалния runtime е persistent database и директории за качени лога, както и notification delivery. Оразмерявайте и наблюдавайте този ресурс заедно с container-а, вместо да излагате несвързан network service.

Изпълнете познатата успешна transaction — създайте абонаменти с различни billing cycles, задайте дати на подновяване, изпълнете notification path и проверете общите суми в избраната валута — преди да приемете, че разделянето е завършено. Измервайте scheduled notification work, logo storage, SQLite writes и timezone correctness и съхранявайте резултата заедно с deployment record-а. Той осигурява както критерий за приемане, така и първоначална базова линия за капацитета.

Диагностицирайте Wallos, който изглежда здрав

При Wallos наблюдавайте transaction, а не process: създайте абонаменти с различни billing cycles, задайте дати на подновяване, изпълнете notification path и проверете общите суми в избраната валута. Комбинирайте latency и error rate с scheduled notification work, logo storage, SQLite writes и timezone correctness, така че alert-ът да идентифицира ограничения компонент.

Upgrade rehearsal-ът трябва да обхваща факта, че database migrations на Wallos трябва да се тестват с данни за дати и валути, преди да замените работещия image. Направете restore, migration и изпълнете transaction-а преди production replacement. Ако датите на подновяване се изместват, защото TZ е зададен неправилно или директорията на SQLite е read-only, не изтривайте данни, за да направите startup-а успешен; сравнете version, variables, mounts и dependency reachability в този ред.

Превърнете smoke теста на Wallos в release проверка

Release record-ът за Wallos трябва да съдържа факти, а не „изглежда добре“. Съхранявайте избрания image digest, configuration checksum, public hostname и timestamp-нат резултат за: създаване на абонаменти с различни billing cycles, задаване на дати на подновяване, изпълнение на notification path и проверка на общите суми в избраната валута. Използвайте примерни данни, които не са production, за да може проверката да се изпълнява след всяко deployment-ване.

Докажете отделно две lifecycle събития. Замяната на container трябва да запази нормалната работа; clean recovery трябва да покаже, че абонаментите, категориите, логата и настройките за известия се възстановяват с непроменени дати на подновяване. Докато проверките се изпълняват, измервайте scheduled notification work, logo storage, SQLite writes и timezone correctness и запазвайте резултата като очаквания envelope за тази версия.

Тествайте и denied или invalid condition: изпратете безвреден input близо до resource или format limit, свързан с тази граница: датите на подновяване се изместват, защото TZ е зададен неправилно или директорията на SQLite е read-only. Wallos трябва да се провали по начин, който позволява диагностика, и не трябва да презаписва здравото state. Върнете валидното condition, стартирайте отново sample-а и приложете съответните redacted logs. Тези artifacts дават конкретни доказателства за бъдещо решение за rollback.

Направете стартирането на Wallos възпроизводимо

Production-подобното стартиране умишлено е скучно: named state, изричен порт и никакъв secret в 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. Потвърдете локалното изискване преди излагане: persistent database и директории за качени лога, както и notification delivery. Проверете effective mounts и listener-а, след което опитайте да създадете абонаменти с различни billing cycles, да зададете дати на подновяване, да изпълните notification path и да проверите общите суми в избраната валута. Фиксирайте работещия image преди следващия restart.

Открийте всеки durable byte в Wallos

Направете inventory на всеки durable artifact: subscription database, качени лога и notification settings. Монтирайте /var/www/html/db преди bootstrap, запишете безвредни примерни данни и заменете container-а, за да докажете, че този path действително е persistent. Включете и configuration, която променя начина, по който съхраняваните данни се интерпретират, а не само най-голямата директория.

Задайте retention, копирайте backup-ите извън host-а и изпълнете clean-room restore. Wallos drill-ът е завършен, когато абонаментите, категориите, логата и notification settings се възстановят с непроменени дати на подновяване. Ако snapshots са част от плана, използвайте насоките за PITR спрямо snapshot, за да документирате какво може да възстанови всеки механизъм.

Дайте на Wallos един canonical address

Издаването на TLS е само половината от route-а на Wallos. Сервирайте приложението през HTTPS и задайте неговата timezone. Изпращайте трафика вътрешно към 80 и препращайте външната scheme, за да останат генерираните URL адреси и secure cookies последователни.

Използвайте целия Wallos scenario от чиста мрежа, а не само root page. 502 или certificate failure може да се изолира чрез автоматична настройка на domain и TLS. Ако трафикът достига до process-а и датите на подновяване се изместват, защото TZ е зададен неправилно или директорията на SQLite е read-only, диагностицирайте condition-а там, където възниква, вместо да добавяте още redirects.

Защитете ценното в Wallos

След първия login прегледайте какво може да прави anonymous visitor, ordinary user и administrator. Проблемът с Wallos, който трябва да избегнете, е първият account да остане слабо защитен при instance, достъпен от интернет. Предвидената policy е да защитите account-а, да пазите notification tokens в тайна и изрично да зададете TZ, така че подновяванията да не се изместват.

TZ управлява поведението, а не confidentiality; валидирайте неговия type и value и съхранявайте реалните Wallos credentials отделно. Дръжте dependency accounts отделно от human accounts, забранете неизползвания egress, когато е практично, и ограничете работата, повлияна от scheduled notification work, logo storage, SQLite writes и timezone correctness.

Къде Dockup спестява работа при Wallos

Dockup template-ът трябва да кодира image-а, port 80, mounts, health timing, domain, TLS и secret delivery. Dockup трябва да запази runtime settings на Wallos, докато операторът потвърди това локално изискване: persistent database и директории за качени лога, както и notification delivery. Същият deployment може да бъде насочен към Dockup servers или customer-attached capacity.

След като route-ът е активен, приложете public setting-а и опитайте да създадете абонаменти с различни billing cycles, да зададете дати на подновяване, да изпълните notification path и да проверите общите суми в избраната валута. Направете backup на subscription database, качените лога и notification settings и включете restore exercise в operating plan-а; това са отговорности на Wallos, които остават видими и след provision-ването на infrastructure.

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

Какво е необходимо на Wallos за production deployment?

Насочете Wallos container-а на port 80 през един HTTPS origin. Изискването на локалния runtime е persistent database и директории за качени лога, както и notification delivery. Не приемайте Wallos за готов, докато не можете да създадете абонаменти с различни billing cycles, да зададете дати на подновяване, да изпълните notification path и да проверите общите суми в избраната валута.

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

Направете /var/www/html/db persistent и включете subscription database, качените лога и notification settings в един и същ recovery manifest. Clean Wallos restore е успешен само когато абонаментите, категориите, логата и notification settings се възстановят с непроменени дати на подновяване.

Изисква ли Wallos HTTPS зад reverse proxy?

Използвайте HTTPS за public Wallos origin и оставете port 80 във вътрешния route. Приложете правилно Wallos setting-а: сервирайте приложението през HTTPS и задайте неговата timezone. При Wallos HTTPS защитава credentials или user content при пренос и поддържа последователно client behavior-а, чувствителен към origin-а.

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

Възстановете текущото Wallos state в изолиран deployment, приложете candidate version и повторете acceptance transaction-а. Обърнете особено внимание, защото database migrations на Wallos трябва да се тестват с данни за дати и валути, преди да замените работещия image. Запазете предишния Wallos image, докато не изясните неговата граница за data migration и rollback.