Comment auto-héberger Wallos en 2026 : renouvellements, notifications et SQLite

La plupart des notes d’installation de Wallos s’arrêtent au premier chargement de la page. C’est trop tôt : les dates de renouvellement changent lorsque TZ est mal configuré ou que le répertoire SQLite est en lecture seule. Un test de production utile est plus exigeant : créer des abonnements avec différents cycles de facturation, définir des dates de renouvellement, exécuter le processus de notification et vérifier les totaux dans la devise sélectionnée.

Le rôle de Wallos est simple : suivre les abonnements, leurs dates de renouvellement et les notifications. Son périmètre opérationnel dépasse le processus web. Il faut donc nommer explicitement la dépendance, l’état stocké et la route publique avant l’arrivée de données réelles.

Cartographier Wallos avant de toucher à Docker

Séparez quatre aspects pour Wallos : l’ingress, le listener sur le port 80, l’état durable et les services de support ou la capacité locale. Le besoin du runtime local comprend des répertoires persistants pour la base de données et l’envoi de logos, ainsi que la livraison des notifications. Dimensionnez et surveillez cette ressource avec le container au lieu d’exposer un service réseau sans rapport.

Exécutez la transaction de référence — créer des abonnements avec différents cycles de facturation, définir des dates de renouvellement, exécuter le processus de notification et vérifier les totaux dans la devise sélectionnée — avant de considérer cette séparation comme terminée. Mesurez le travail planifié des notifications, le stockage des logos, les écritures SQLite et l’exactitude du fuseau horaire, puis conservez le résultat avec l’enregistrement du déploiement. Vous disposez ainsi à la fois d’un critère d’acceptation et d’une première référence de capacité.

Diagnostiquer un Wallos qui semble sain

Pour Wallos, surveillez une transaction plutôt qu’un processus : créez des abonnements avec différents cycles de facturation, définissez des dates de renouvellement, exécutez le processus de notification et vérifiez les totaux dans la devise sélectionnée. Associez sa latence et son taux d’erreur au travail planifié des notifications, au stockage des logos, aux écritures SQLite et à l’exactitude du fuseau horaire afin qu’une alerte identifie le composant sous contrainte.

La répétition générale de la mise à niveau doit couvrir les migrations de la base de données Wallos, qui doivent être testées avec des données de dates et de devises avant de remplacer l’image en cours d’exécution. Restaurez, migrez et exécutez la transaction avant le remplacement en production. Si les dates de renouvellement changent parce que TZ est mal configuré ou que le répertoire SQLite est en lecture seule, n’effacez pas les données pour faire apparaître un démarrage réussi ; comparez dans cet ordre la version, les variables, les mounts et l’accessibilité des dépendances.

Transformer le smoke test de Wallos en contrôle de release

L’enregistrement de release de Wallos doit contenir des faits, pas un simple « tout semble correct ». Stockez le digest de l’image sélectionnée, la checksum de configuration, le hostname public et le résultat horodaté pour les opérations suivantes : créer des abonnements avec différents cycles de facturation, définir des dates de renouvellement, exécuter le processus de notification et vérifier les totaux dans la devise sélectionnée. Utilisez des données d’exemple hors production afin que le contrôle puisse être exécuté après chaque déploiement.

Validez séparément deux événements du cycle de vie. Le remplacement d’un container doit préserver le fonctionnement normal ; une récupération complète doit montrer que les abonnements, les catégories, les logos et les paramètres de notification sont restaurés avec des dates de renouvellement inchangées. Pendant l’exécution des contrôles, mesurez le travail planifié des notifications, le stockage des logos, les écritures SQLite et l’exactitude du fuseau horaire, puis conservez le résultat comme enveloppe attendue pour cette version.

Testez également une condition refusée ou invalide : envoyez une entrée inoffensive proche de la limite de ressource ou de format associée à ce périmètre : les dates de renouvellement changent parce que TZ est mal configuré ou que le répertoire SQLite est en lecture seule. Wallos doit échouer d’une manière permettant d’établir un diagnostic et ne doit pas écraser un état sain. Rétablissez la condition valide, relancez l’exemple et joignez les logs pertinents après suppression des informations sensibles. Ces artefacts fournissent des éléments concrets pour une future décision de rollback.

Rendre le démarrage de Wallos reproductible

Un lancement représentatif de la production est volontairement sans surprise : un état nommé, un port explicite et aucun secret dans l’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

L’exemple constitue une base, et non une stack de support complète. Confirmez le besoin local avant l’exposition : des répertoires persistants pour la base de données et l’envoi de logos, ainsi que la livraison des notifications. Vérifiez les mounts effectifs et le listener, puis essayez de créer des abonnements avec différents cycles de facturation, de définir des dates de renouvellement, d’exécuter le processus de notification et de vérifier les totaux dans la devise sélectionnée. Épinglez l’image fonctionnelle avant le prochain redémarrage.

Trouver chaque octet durable de Wallos

Répertoriez chaque artefact durable : la base de données des abonnements, les logos importés et les paramètres de notification. Montez /var/www/html/db avant le bootstrap, écrivez des données d’exemple inoffensives et remplacez le container pour prouver que ce chemin est réellement persistant. Incluez les paramètres qui modifient l’interprétation des données stockées, et pas uniquement le répertoire le plus volumineux.

Définissez une politique de rétention, copiez les sauvegardes hors de l’hôte et exécutez une restauration en environnement vierge. La procédure Wallos est terminée lorsque les abonnements, les catégories, les logos et les paramètres de notification sont restaurés avec des dates de renouvellement inchangées. Si les snapshots font partie du plan, utilisez les recommandations sur le PITR et les snapshots pour documenter ce que chaque mécanisme peut restaurer.

Donner à Wallos une adresse canonique

L’émission des certificats TLS ne représente que la moitié de la route de Wallos. Servez l’application en HTTPS et définissez son fuseau horaire. Acheminez le trafic en interne vers le port 80 et transmettez le scheme externe afin que les URL générées et les secure cookies restent cohérents.

Utilisez le scénario Wallos complet depuis un réseau vierge, et pas seulement la page racine. Une erreur 502 ou un échec de certificat peut être isolé avec la configuration automatique du domaine et de TLS. Si le trafic atteint le processus et que les dates de renouvellement changent parce que TZ est mal configuré ou que le répertoire SQLite est en lecture seule, diagnostiquez cette condition à l’endroit où elle se produit au lieu d’empiler les redirects.

Protéger la partie précieuse de Wallos

Après la première connexion, vérifiez ce qu’un visiteur anonyme, un utilisateur standard et un administrateur peuvent chacun faire. Le problème à éviter avec Wallos est de laisser le premier compte insuffisamment protégé sur une instance exposée à Internet. La politique visée consiste à protéger le compte, à garder les tokens de notification privés et à définir explicitement TZ pour que les renouvellements ne changent pas.

TZ contrôle le comportement, et non la confidentialité ; validez son type et sa valeur, et stockez les véritables identifiants Wallos séparément. Séparez les comptes de dépendances des comptes humains, refusez les connexions sortantes inutilisées lorsque c’est possible et plafonnez le travail influencé par le travail planifié des notifications, le stockage des logos, les écritures SQLite et l’exactitude du fuseau horaire.

Ce que Dockup simplifie pour Wallos

Un template Dockup doit intégrer l’image, le port 80, les mounts, le délai de health check, le domaine, TLS et la transmission des secrets. Dockup doit préserver les paramètres du runtime Wallos pendant que l’opérateur confirme le besoin local suivant : des répertoires persistants pour la base de données et l’envoi de logos, ainsi que la livraison des notifications. Le même déploiement peut cibler des serveurs Dockup ou une capacité rattachée au client.

Une fois la route active, appliquez le paramètre public et essayez de créer des abonnements avec différents cycles de facturation, de définir des dates de renouvellement, d’exécuter le processus de notification et de vérifier les totaux dans la devise sélectionnée. Sauvegardez la base de données des abonnements, les logos importés et les paramètres de notification, et conservez l’exercice de restauration dans le plan d’exploitation ; ces éléments relèvent de Wallos et restent visibles après le provisionnement de l’infrastructure.

Foire aux questions

De quoi Wallos a-t-il besoin pour un déploiement en production ?

Acheminez le container Wallos sur le port 80 via une origine HTTPS unique. Le besoin du runtime local comprend des répertoires persistants pour la base de données et l’envoi de logos, ainsi que la livraison des notifications. Ne considérez pas Wallos comme prêt avant de pouvoir créer des abonnements avec différents cycles de facturation, définir des dates de renouvellement, exécuter le processus de notification et vérifier les totaux dans la devise sélectionnée.

Quelles données Wallos doivent figurer dans une sauvegarde ?

Conservez /var/www/html/db et incluez la base de données des abonnements, les logos importés et les paramètres de notification dans le même manifest de récupération. Une restauration Wallos complète n’est validée que lorsque les abonnements, les catégories, les logos et les paramètres de notification sont restaurés avec des dates de renouvellement inchangées.

Wallos nécessite-t-il HTTPS derrière un reverse proxy ?

Utilisez HTTPS pour l’origine publique de Wallos et conservez le port 80 sur la route interne. Appliquez correctement le paramètre Wallos : servez l’application en HTTPS et définissez son fuseau horaire. Pour Wallos, HTTPS protège les identifiants ou le contenu utilisateur pendant leur transmission et garantit la cohérence du comportement client sensible à l’origine.

Comment tester une mise à niveau de Wallos ?

Restaurez l’état actuel de Wallos dans un déploiement isolé, appliquez la version candidate et répétez sa transaction d’acceptation. Soyez particulièrement attentif, car les migrations de la base de données Wallos doivent être testées avec des données de dates et de devises avant de remplacer l’image en cours d’exécution. Conservez l’image Wallos précédente jusqu’à ce que les limites de migration des données et de rollback soient comprises.