Come installare Wallos in self-hosting nel 2026: rinnovi, notifiche e SQLite
Implementa Wallos con la porta corretta, storage persistente, TLS, autenticazione e backup. Risolvi i problemi quando le date di rinnovo cambiano perché TZ è errato in produzione.
La maggior parte delle note sull'installazione di Wallos si ferma al primo caricamento della pagina. È troppo presto: le date di rinnovo cambiano perché TZ è errato oppure la directory SQLite è in sola lettura. Un test di produzione utile è più rigoroso: crea abbonamenti con cicli di fatturazione diversi, imposta le date di rinnovo, esegui il flusso delle notifiche e verifica i totali nella valuta selezionata.
Il ruolo di Wallos è semplice: un subscription tracker con date di rinnovo e notifiche. Il suo perimetro operativo comprende più del solo processo web, quindi dipendenza, stato memorizzato e route pubblica devono essere identificati esplicitamente prima che arrivino dati reali.
Mappa Wallos prima di usare Docker
Per Wallos, separa quattro aspetti: ingress, listener sulla porta 80, stato persistente e servizi di supporto o capacità locale. Il requisito del runtime locale consiste in directory persistenti per il database e il caricamento dei loghi, oltre alla consegna delle notifiche. Dimensiona e monitora questa risorsa insieme al container invece di esporre un servizio di rete non correlato.
Esegui la transazione verificata — crea abbonamenti con cicli di fatturazione diversi, imposta le date di rinnovo, esegui il flusso delle notifiche e verifica i totali nella valuta selezionata — prima di considerare completa questa separazione. Misura il lavoro delle notifiche pianificate, lo storage dei loghi, le scritture SQLite e la correttezza del fuso orario, quindi conserva il risultato nel record del deployment. Fornisce sia un criterio di accettazione sia la prima baseline di capacità.
Diagnostica di un Wallos dall'aspetto integro
Per Wallos, monitora una transazione anziché un processo: crea abbonamenti con cicli di fatturazione diversi, imposta le date di rinnovo, esegui il flusso delle notifiche e verifica i totali nella valuta selezionata. Combina latenza e tasso di errore con il lavoro delle notifiche pianificate, lo storage dei loghi, le scritture SQLite e la correttezza del fuso orario, così un alert identifica il componente sotto pressione.
La prova generale dell'upgrade deve includere il test delle migrazioni del database di Wallos con dati relativi a date e valute prima di sostituire l'immagine in esecuzione. Esegui il restore, la migrazione e la transazione prima della sostituzione in produzione. Se le date di rinnovo cambiano perché TZ è errato oppure la directory SQLite è in sola lettura, non cancellare i dati per rendere verde lo startup; confronta in quest'ordine versione, variabili, mount e raggiungibilità delle dipendenze.
Trasforma lo smoke test di Wallos in un controllo di release
Il record della release di Wallos deve contenere fatti, non un semplice “sembra tutto a posto”. Salva il digest dell'immagine selezionata, il checksum della configurazione, l'hostname pubblico e un risultato con timestamp per: creare abbonamenti con cicli di fatturazione diversi, impostare le date di rinnovo, eseguire il flusso delle notifiche e verificare i totali nella valuta selezionata. Usa dati di esempio non di produzione, così il controllo può essere eseguito dopo ogni deployment.
Dimostra separatamente due eventi del ciclo di vita. La sostituzione di un container deve preservare il normale funzionamento; un recovery completo deve dimostrare che abbonamenti, categorie, loghi e impostazioni delle notifiche vengono ripristinati con date di rinnovo invariate. Durante i controlli, misura il lavoro delle notifiche pianificate, lo storage dei loghi, le scritture SQLite e la correttezza del fuso orario e conserva il risultato come envelope atteso per questa versione.
Verifica anche una condizione negata o non valida: invia un input innocuo vicino al limite di risorse o di formato associato a questo perimetro: le date di rinnovo cambiano perché TZ è errato oppure la directory SQLite è in sola lettura. Wallos deve fallire in modo diagnosticabile e non deve sovrascrivere lo stato integro. Ripristina la condizione valida, esegui di nuovo l'esempio e allega i log rilevanti con i dati sensibili oscurati. Questi artifact forniscono elementi concreti per una futura decisione di rollback.
Rendi riproducibile lo startup di Wallos
Un avvio simile a quello di produzione è volutamente noioso: stato nominato, porta esplicita e nessun secret nell'immagine.
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
L'esempio è una baseline, non uno stack di supporto completo. Conferma il requisito locale prima dell'esposizione: directory persistenti per il database e il caricamento dei loghi, oltre alla consegna delle notifiche. Controlla i mount effettivi e il listener, quindi prova a creare abbonamenti con cicli di fatturazione diversi, impostare le date di rinnovo, eseguire il flusso delle notifiche e verificare i totali nella valuta selezionata. Fissa l'immagine funzionante prima del riavvio successivo.
Individua ogni byte persistente in Wallos
Fai l'inventario di ogni artifact persistente: database degli abbonamenti, loghi caricati e impostazioni delle notifiche. Monta /var/www/html/db prima del bootstrap, scrivi dati di esempio innocui e sostituisci il container per dimostrare che quel percorso è effettivamente persistente. Includi anche la configurazione che modifica il modo in cui i dati memorizzati vengono interpretati, non solo la directory più grande.
Imposta la retention, copia i backup fuori dall'host ed esegui un restore in clean room. L'esercitazione di Wallos è completa quando abbonamenti, categorie, loghi e impostazioni delle notifiche vengono ripristinati con date di rinnovo invariate. Se gli snapshot fanno parte del piano, usa le indicazioni su PITR e snapshot per documentare cosa può recuperare ciascun meccanismo.
Assegna a Wallos un unico indirizzo canonico
L'emissione del certificato TLS è solo metà della route di Wallos. Servi l'applicazione tramite HTTPS e imposta il relativo fuso orario. Inoltra il traffico internamente verso la porta 80 e inoltra lo scheme esterno, così gli URL generati e i secure cookie rimangono coerenti.
Usa lo scenario completo di Wallos da una rete pulita, non soltanto la root page. Un errore 502 o un errore del certificato possono essere isolati con la configurazione automatica di dominio e TLS. Se il traffico raggiunge il processo e le date di rinnovo cambiano perché TZ è errato oppure la directory SQLite è in sola lettura, diagnostica la condizione nel punto in cui si verifica invece di accumulare redirect.
Proteggi la parte preziosa di Wallos
Dopo il primo login, verifica cosa possono fare un visitatore anonimo, un utente normale e un amministratore. Il problema da evitare in Wallos è lasciare debole il primo account su un'istanza esposta a Internet. La policy prevista consiste nel proteggere l'account, mantenere privati i token delle notifiche e impostare esplicitamente TZ, così i rinnovi non cambiano.
TZ controlla il comportamento, non la riservatezza; convalida tipo e valore e conserva separatamente le credenziali reali di Wallos. Mantieni separati gli account delle dipendenze da quelli umani, nega l'egress non utilizzato dove possibile e limita il lavoro influenzato dal lavoro delle notifiche pianificate, dallo storage dei loghi, dalle scritture SQLite e dalla correttezza del fuso orario.
Dove Dockup riduce il lavoro per Wallos
Un template Dockup dovrebbe codificare immagine, porta 80, mount, timing dell'health check, dominio, TLS e distribuzione dei secret. Dockup dovrebbe preservare le impostazioni del runtime di Wallos mentre l'operatore conferma questo requisito locale: directory persistenti per il database e il caricamento dei loghi, oltre alla consegna delle notifiche. Lo stesso deployment può essere indirizzato ai server Dockup o alla capacità collegata dal cliente.
Dopo che la route è attiva, applica l'impostazione pubblica e prova a creare abbonamenti con cicli di fatturazione diversi, impostare le date di rinnovo, eseguire il flusso delle notifiche e verificare i totali nella valuta selezionata. Esegui il backup del database degli abbonamenti, dei loghi caricati e delle impostazioni delle notifiche e mantieni l'esercitazione di restore nel piano operativo; queste sono responsabilità di Wallos che rimangono visibili anche dopo il provisioning dell'infrastruttura.
Domande frequenti
Cosa serve a Wallos per un deployment in produzione?
Instrada il container Wallos sulla porta 80 attraverso un'unica origine HTTPS. Il requisito del runtime locale consiste in directory persistenti per il database e il caricamento dei loghi, oltre alla consegna delle notifiche. Non considerare Wallos pronto finché non puoi creare abbonamenti con cicli di fatturazione diversi, impostare le date di rinnovo, eseguire il flusso delle notifiche e verificare i totali nella valuta selezionata.
Quali dati di Wallos devono essere inclusi in un backup?
Rendi persistente /var/www/html/db e includi database degli abbonamenti, loghi caricati e impostazioni delle notifiche nello stesso manifest di recovery. Un restore completo di Wallos è riuscito solo quando abbonamenti, categorie, loghi e impostazioni delle notifiche vengono ripristinati con date di rinnovo invariate.
Wallos richiede HTTPS dietro un reverse proxy?
Usa HTTPS per l'origine pubblica di Wallos e mantieni la porta 80 nella route interna. Applica correttamente l'impostazione di Wallos: servi l'applicazione tramite HTTPS e imposta il relativo fuso orario. Per Wallos, HTTPS protegge le credenziali o i contenuti degli utenti durante il transito e mantiene coerente il comportamento del client sensibile all'origine.
Come si deve testare un upgrade di Wallos?
Ripristina lo stato attuale di Wallos in un deployment isolato, applica la versione candidata e ripeti la transazione di accettazione. Presta particolare attenzione perché le migrazioni del database di Wallos devono essere testate con dati relativi a date e valute prima di sostituire l'immagine in esecuzione. Mantieni l'immagine precedente di Wallos finché non sono chiari i limiti della migrazione dei dati e del rollback.
