2026'da Wallos'u Self-Host Etme: Yenilemeler, Bildirimler ve SQLite

Wallos kurulum notlarının çoğu ilk sayfa yüklemesinde sona erer. Bu çok erkendir: TZ yanlış olduğu veya SQLite dizini salt okunur olduğu için yenileme tarihleri kayabilir. Kullanışlı bir production testi daha kapsamlı olmalıdır — farklı billing cycle'larda subscription'lar oluşturun, yenileme tarihlerini ayarlayın, notification akışını çalıştırın ve seçili currency cinsinden toplamları inceleyin.

Wallos'un rolü basittir: yenileme tarihleri ve bildirimleri olan bir subscription tracker. Operasyonel sınırları web process'inden daha fazlasını kapsar; bu nedenle gerçek veriler gelmeden önce dependency'yi, saklanan state'i ve public route'u açıkça tanımlamak gerekir.

Docker'a dokunmadan önce Wallos'u haritalayın

Wallos için dört konuyu birbirinden ayırın: ingress, 80 numaralı portu dinleyen listener, kalıcı state ve supporting service'ler ya da yerel capacity. Yerel runtime gereksinimi, kalıcı database ve logo upload dizinlerinin yanı sıra notification delivery'dir. Bu kaynağı container ile birlikte boyutlandırıp monitor edin; ilgisiz bir network service'i dışarı açmayın.

Bu ayrımı tamamlanmış saymadan önce bilinen iyi transaction'ı çalıştırın — farklı billing cycle'larda subscription'lar oluşturun, yenileme tarihlerini ayarlayın, notification akışını çalıştırın ve seçili currency cinsinden toplamları inceleyin. Scheduled notification work, logo storage, SQLite writes ve timezone doğruluğunu ölçün; sonucu deployment kaydıyla birlikte saklayın. Bu, hem bir acceptance criterion hem de ilk capacity baseline'ını sağlar.

Sağlıklı görünen Wallos'u teşhis edin

Wallos için bir process'i değil, bir transaction'ı monitor edin: farklı billing cycle'larda subscription'lar oluşturun, yenileme tarihlerini ayarlayın, notification akışını çalıştırın ve seçili currency cinsinden toplamları inceleyin. Alert'in kısıtlanan component'i belirlemesi için latency ve error rate'i scheduled notification work, logo storage, SQLite writes ve timezone doğruluğuyla birlikte değerlendirin.

Upgrade rehearsal, Wallos database migration'larının çalışan image değiştirilmeden önce date ve currency verileriyle test edilmesini kapsamalıdır. Production'da değiştirme yapmadan önce restore edin, migration'ı çalıştırın ve transaction'ı yürütün. TZ yanlış olduğu veya SQLite dizini salt okunur olduğu için yenileme tarihleri kayıyorsa startup'ı yeşil göstermek için verileri silmeyin; version, variables, mounts ve dependency erişilebilirliğini bu sırayla karşılaştırın.

Wallos smoke test'ini bir release kontrolüne dönüştürün

Wallos için release kaydı “iyi görünüyor” gibi ifadeler değil, gerçekler içermelidir. Seçili image digest'ini, configuration checksum'unu, public hostname'i ve şu adımların timestamp içeren sonucunu saklayın: farklı billing cycle'larda subscription'lar oluşturma, yenileme tarihlerini ayarlama, notification akışını çalıştırma ve seçili currency cinsinden toplamları inceleme. Kontrolün her deployment sonrasında çalıştırılabilmesi için non-production sample data kullanın.

İki lifecycle event'ini ayrı ayrı kanıtlayın. Bir container replacement normal operasyonu korumalıdır; clean recovery ise subscription'ların, category'lerin, logo'ların ve notification setting'lerinin yenileme tarihleri değişmeden geri geldiğini göstermelidir. Kontroller çalışırken scheduled notification work, logo storage, SQLite writes ve timezone doğruluğunu ölçün; sonucu bu version için beklenen envelope olarak saklayın.

Bir denied veya geçersiz durumu da test edin: bu sınırla ilişkili resource ya da format limitine yakın, zararsız bir input gönderin: TZ yanlış olduğu veya SQLite dizini salt okunur olduğu için yenileme tarihleri kayar. Wallos teşhis edilebilir şekilde başarısız olmalı ve sağlıklı state'in üzerine yazmamalıdır. Geçerli duruma dönün, sample'ı yeniden çalıştırın ve ilgili redacted log'ları ekleyin. Bu artifact'ler gelecekteki rollback kararı için somut kanıt sağlar.

Wallos startup'ını tekrarlanabilir hâle getirin

Production'a uygun bir launch bilerek sıradandır: adlandırılmış state, açıkça belirtilmiş port ve image içinde secret bulunmaması.

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

Bu örnek, eksiksiz bir supporting stack'ten ziyade bir baseline'dır. Dışarı açmadan önce yerel gereksinimi doğrulayın: kalıcı database ve logo upload dizinleri ile notification delivery. Effective mount'ları ve listener'ı kontrol edin; ardından farklı billing cycle'larda subscription'lar oluşturmayı, yenileme tarihlerini ayarlamayı, notification akışını çalıştırmayı ve seçili currency cinsinden toplamları incelemeyi deneyin. Bir sonraki restart'tan önce çalışan image'ı pinleyin.

Wallos'taki her kalıcı byte'ı bulun

Her kalıcı artifact'i envantere ekleyin: subscription database'i, yüklenen logo'lar ve notification setting'leri. Bootstrap öncesinde /var/www/html/db mount edin, zararsız sample data yazın ve bu path'in gerçekten kalıcı olduğunu kanıtlamak için container'ı değiştirin. Yalnızca en büyük dizini değil, saklanan verilerin nasıl yorumlandığını değiştiren configuration'ı da dahil edin.

Retention belirleyin, backup'ları host dışına kopyalayın ve clean-room restore çalıştırın. Wallos tatbikatı; subscription'lar, category'ler, logo'lar ve notification setting'leri yenileme tarihleri değişmeden geri döndüğünde tamamlanır. Snapshot'lar planın parçasıysa, her mekanizmanın neleri kurtarabileceğini belgelemek için PITR ve snapshot karşılaştırması rehberini kullanın.

Wallos'a tek bir canonical address verin

TLS issuance, Wallos route'unun yalnızca yarısıdır. Uygulamayı HTTPS üzerinden sunun ve timezone'unu ayarlayın. Trafiği içeride 80 numaralı porta gönderin ve generated URL'ler ile secure cookie'lerin tutarlı kalması için external scheme'i forward edin.

Yalnızca root page'i değil, eksiksiz Wallos senaryosunu temiz bir network üzerinden çalıştırın. 502 veya certificate failure, automatic domain ve TLS kurulumu ile izole edilebilir. Trafik process'e ulaşıyor ve TZ yanlış olduğu veya SQLite dizini salt okunur olduğu için yenileme tarihleri kayıyorsa, redirect zincirleri eklemek yerine bu durumu ortaya çıktığı yerde teşhis edin.

Wallos'un değerli kısmını koruyun

İlk login sonrasında anonymous visitor'ın, ordinary user'ın ve administrator'ın neler yapabildiğini ayrı ayrı inceleyin. Wallos için kaçınılması gereken failure, internet'e açık bir instance'ta ilk account'un zayıf bırakılmasıdır. Amaç account'u korumak, notification token'larını gizli tutmak ve renewals'ın kaymaması için TZ'yi açıkça ayarlamaktır.

TZ, confidentiality yerine davranışı kontrol eder; type ve value'sunu doğrulayın, gerçek Wallos credential'larını ayrı saklayın. Dependency account'larını human account'larından ayrı tutun, mümkün olduğunda kullanılmayan egress'i engelleyin ve scheduled notification work, logo storage, SQLite writes ve timezone doğruluğunun etkilediği çalışmayı sınırlandırın.

Dockup, Wallos için hangi işleri ortadan kaldırır?

Bir Dockup template'i image'ı, 80 numaralı portu, mount'ları, health timing'i, domain'i, TLS'i ve secret delivery'yi tanımlamalıdır. Operator şu yerel gereksinimi doğrularken Dockup, Wallos runtime setting'lerini korumalıdır: kalıcı database ve logo upload dizinleri ile notification delivery. Aynı deployment, Dockup server'larını veya customer-attached capacity'yi hedefleyebilir.

Route kullanıma açıldıktan sonra public setting'i uygulayın ve farklı billing cycle'larda subscription'lar oluşturmayı, yenileme tarihlerini ayarlamayı, notification akışını çalıştırmayı ve seçili currency cinsinden toplamları incelemeyi deneyin. Subscription database'ini, yüklenen logo'ları ve notification setting'lerini backup'layın; restore çalışmasını operating plan'e dahil edin. Bunlar, infrastructure provisioning sonrasında da görünür kalması gereken Wallos sorumluluklarıdır.

Sık sorulan sorular

Wallos production deployment için neye ihtiyaç duyar?

Wallos container'ını tek bir HTTPS origin üzerinden 80 numaralı portta route edin. Yerel runtime gereksinimi, kalıcı database ve logo upload dizinlerinin yanı sıra notification delivery'dir. Farklı billing cycle'larda subscription'lar oluşturamıyor, yenileme tarihlerini ayarlayamıyor, notification akışını çalıştıramıyor ve seçili currency cinsinden toplamları inceleyemiyorsanız Wallos'u hazır kabul etmeyin.

Hangi Wallos verileri backup'a dahil edilmelidir?

/var/www/html/db'yi persist edin; subscription database'ini, yüklenen logo'ları ve notification setting'lerini aynı recovery manifest'ine dahil edin. Clean Wallos restore yalnızca subscription'lar, category'ler, logo'lar ve notification setting'leri yenileme tarihleri değişmeden geri geldiğinde başarılı sayılır.

Wallos, reverse proxy arkasında HTTPS gerektirir mi?

Public Wallos origin'i için HTTPS kullanın ve internal route'ta 80 numaralı portu koruyun. Wallos setting'ini doğru şekilde uygulayın: uygulamayı HTTPS üzerinden sunun ve timezone'unu ayarlayın. Wallos için HTTPS, credentials veya user content'in transit sırasında korunmasını ve origin'e duyarlı client davranışının tutarlı kalmasını sağlar.

Wallos upgrade'i nasıl test edilmelidir?

Mevcut Wallos state'ini izole bir deployment'a restore edin, candidate version'ı uygulayın ve acceptance transaction'ını tekrarlayın. Wallos database migration'larının çalışan image değiştirilmeden önce date ve currency verileriyle test edilmesi gerektiğinden bu noktaya özellikle dikkat edin. Data migration ve rollback sınırları anlaşılana kadar önceki Wallos image'ını saklayın.