Så självhostar du Wallos 2026: förnyelser, aviseringar och SQLite
Distribuera Wallos med rätt port, beständig lagring, TLS, autentisering och säkerhetskopior. Felsök när förnyelsedatum ändras eftersom TZ är fel i produktion.
De flesta installationsanteckningar för Wallos slutar efter den första sidinläsningen. Det är för tidigt: förnyelsedatum ändras eftersom TZ är fel eller SQLite-katalogen är skrivskyddad. Ett användbart produktionstest är mer krävande — skapa prenumerationer med olika faktureringsintervall, ange förnyelsedatum, kör aviseringsflödet och kontrollera totalerna i den valda valutan.
Wallos har en tydlig roll: en tracker för prenumerationer med förnyelsedatum och aviseringar. Den operativa avgränsningen omfattar mer än webbprocessen, så beroendet, det lagrade tillståndet och den publika routen måste anges uttryckligen innan riktiga data börjar användas.
Kartlägg Wallos innan du rör Docker
Dela upp fyra områden för Wallos: ingress, lyssnaren på port 80, beständigt tillstånd samt stödjande tjänster eller lokal kapacitet. Kravet på den lokala runtime-miljön är beständiga kataloger för databasen och logotypuppladdningar samt leverans av aviseringar. Dimensionera och övervaka resursen tillsammans med containern i stället för att exponera en orelaterad nätverkstjänst.
Kör den kända fungerande transaktionen — skapa prenumerationer med olika faktureringsintervall, ange förnyelsedatum, kör aviseringsflödet och kontrollera totalerna i den valda valutan — innan du anser separationen färdig. Mät schemalagt aviseringsarbete, logotyp lagring, SQLite-skrivningar och korrekt tidszon och spara resultatet tillsammans med deployment-dokumentationen. Det ger både ett acceptanskriterium och den första kapacitetsbaslinjen.
Diagnostisera ett Wallos som ser friskt ut
För Wallos ska du övervaka en transaktion i stället för en process: skapa prenumerationer med olika faktureringsintervall, ange förnyelsedatum, kör aviseringsflödet och kontrollera totalerna i den valda valutan. Kombinera dess latens och felfrekvens med schemalagt aviseringsarbete, logotyp lagring, SQLite-skrivningar och korrekt tidszon så att en alert identifierar den komponent som är begränsad.
Uppgraderingsrepetitionen måste omfatta att Wallos-databasmigreringar testas med datum- och valutadata innan den körande imagen ersätts. Återställ, migrera och kör transaktionen före bytet i produktion. Om förnyelsedatum ändras eftersom TZ är fel eller SQLite-katalogen är skrivskyddad ska du inte radera data för att få en grön startup; jämför version, variabler, mounts och nåbarhet till beroenden i den ordningen.
Gör Wallos smoke test till en releasekontroll
Releaseposten för Wallos behöver fakta, inte ”ser bra ut”. Spara vald image-digest, konfigurationschecksumma, publikt hostname och ett tidsstämplat resultat för att skapa prenumerationer med olika faktureringsintervall, ange förnyelsedatum, köra aviseringsflödet och kontrollera totalerna i den valda valutan. Använd exempeldata som inte hör till produktion så att kontrollen kan köras efter varje deployment.
Bevisa två lifecycle-händelser separat. Ett containerbyte måste bevara normal drift; en ren återställning måste visa att prenumerationer, kategorier, logotyper och aviseringsinställningar kommer tillbaka med oförändrade förnyelsedatum. Mät schemalagt aviseringsarbete, logotyp lagring, SQLite-skrivningar och korrekt tidszon medan kontrollerna körs och behåll resultatet som det förväntade intervallet för den här versionen.
Testa även ett nekad eller ogiltigt tillstånd: skicka ofarlig indata nära resurs- eller formatgränsen som hör till den här avgränsningen: förnyelsedatum ändras eftersom TZ är fel eller SQLite-katalogen är skrivskyddad. Wallos ska misslyckas på ett diagnostiserbart sätt och får inte skriva över ett friskt tillstånd. Återgå till det giltiga tillståndet, kör exemplet igen och bifoga relevanta rensade loggar. Dessa artefakter ger ett framtida rollback-beslut konkreta bevis.
Gör Wallos startup reproducerbar
En produktionslik launch är medvetet odramatisk: namngivet tillstånd, explicit port och inga hemligheter i imagen.
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
Exemplet är en baslinje, inte en komplett stödjande stack. Bekräfta det lokala kravet före exponering: beständiga kataloger för databasen och logotypuppladdningar samt leverans av aviseringar. Kontrollera aktiva mounts och lyssnaren och försök sedan skapa prenumerationer med olika faktureringsintervall, ange förnyelsedatum, köra aviseringsflödet och kontrollera totalerna i den valda valutan. Pinna den fungerande imagen före nästa omstart.
Hitta alla beständiga byte i Wallos
Inventera alla beständiga artefakter: prenumerationsdatabasen, uppladdade logotyper och aviseringsinställningar. Mounta /var/www/html/db före bootstrap, skriv ofarliga exempeldata och byt ut containern för att bevisa att sökvägen faktiskt är beständig. Inkludera konfiguration som ändrar hur lagrade data tolkas, inte bara den största katalogen.
Ange retention, kopiera säkerhetskopior till en annan host och kör en återställning i en ren miljö. Wallos-övningen är klar när prenumerationer, kategorier, logotyper och aviseringsinställningar kommer tillbaka med oförändrade förnyelsedatum. Om snapshots ingår i planen kan du använda vägledningen om PITR jämfört med snapshots för att dokumentera vad varje mekanism kan återställa.
Ge Wallos en enda kanonisk adress
TLS-utgivning är bara halva Wallos-routen. Servera applikationen över HTTPS och ange dess tidszon. Skicka trafik internt till port 80 och vidarebefordra det externa schemat så att genererade URL:er och säkra cookies förblir konsekventa.
Använd hela Wallos-scenariot från ett rent nätverk, inte bara rotsidan. Ett 502-fel eller ett certifikatfel kan isoleras med automatisk konfiguration av domän och TLS. Om trafiken når processen och förnyelsedatum ändras eftersom TZ är fel eller SQLite-katalogen är skrivskyddad ska du diagnostisera tillståndet där det uppstår i stället för att stapla redirects.
Skydda den värdefulla delen av Wallos
Efter den första inloggningen ska du granska vad en anonym besökare, en vanlig användare och en administratör kan göra. Det Wallos-fel du ska undvika är att lämna det första kontot svagt på en internetansluten instans. Den avsedda policyn är att skydda kontot, hålla aviseringstokens privata och ange TZ explicit så att förnyelser inte ändras.
TZ styr beteendet snarare än konfidentialiteten; validera dess typ och värde och lagra riktiga Wallos-autentiseringsuppgifter separat. Håll beroendekonton åtskilda från personliga konton, neka oanvänd utgående trafik där det är praktiskt möjligt och begränsa arbete som påverkas av schemalagt aviseringsarbete, logotyp lagring, SQLite-skrivningar och korrekt tidszon.
Där Dockup minskar arbetet för Wallos
En Dockup-mall bör ange imagen, port 80, mounts, health-timing, domän, TLS och leverans av hemligheter. Dockup ska bevara Wallos runtime-inställningar medan operatören bekräftar det lokala kravet: beständiga kataloger för databasen och logotypuppladdningar samt leverans av aviseringar. Samma deployment kan riktas mot Dockup-servrar eller kundansluten kapacitet.
När routen är aktiv ska du tillämpa den publika inställningen och försöka skapa prenumerationer med olika faktureringsintervall, ange förnyelsedatum, köra aviseringsflödet och kontrollera totalerna i den valda valutan. Säkerhetskopiera prenumerationsdatabasen, uppladdade logotyper och aviseringsinställningar och behåll återställningsövningen i driftplanen; detta är Wallos-ansvar som fortfarande är synligt efter att infrastrukturen har provisionerats.
Vanliga frågor
Vad behöver Wallos för en produktionsdeployment?
Routa Wallos-containern på port 80 genom en enda HTTPS-origin. Kravet på den lokala runtime-miljön är beständiga kataloger för databasen och logotypuppladdningar samt leverans av aviseringar. Anse inte Wallos redo förrän du kan skapa prenumerationer med olika faktureringsintervall, ange förnyelsedatum, köra aviseringsflödet och kontrollera totalerna i den valda valutan.
Vilka Wallos-data ska ingå i en säkerhetskopia?
Spara /var/www/html/db och inkludera prenumerationsdatabasen, uppladdade logotyper och aviseringsinställningar i samma återställningsmanifest. En ren Wallos-återställning är godkänd först när prenumerationer, kategorier, logotyper och aviseringsinställningar kommer tillbaka med oförändrade förnyelsedatum.
Kräver Wallos HTTPS bakom en reverse proxy?
Använd HTTPS för den publika Wallos-originen och behåll port 80 i den interna routen. Tillämpa Wallos-inställningen korrekt: servera applikationen över HTTPS och ange dess tidszon. För Wallos skyddar HTTPS autentiseringsuppgifter eller användarinnehåll under överföring och håller klientbeteende som är känsligt för origin konsekvent.
Hur ska en Wallos-uppgradering testas?
Återställ aktuellt Wallos-tillstånd till en isolerad deployment, tillämpa kandidatversionen och upprepa dess acceptanstransaktion. Var särskilt uppmärksam eftersom Wallos-databasmigreringar ska testas med datum- och valutadata innan den körande imagen ersätts. Behåll den tidigare Wallos-imagen tills gränserna för datamigrering och rollback är förstådda.
