Så driftar du Wallabag själv 2026: import, databas och bakgrundsjobb

Den kortaste demonstrationen av Wallabag visar att en process lyssnar på port 80. Produktion kräver starkare bevis. Följande scenario måste fungera även efter att containern har ersatts: spara en vanlig artikel och en svår sida, kör hämtning i bakgrunden, synkronisera en mobilklient och sök i arkiverat innehåll.

Wallabag distribueras för ett tydligt syfte: ett läs-senare-arkiv som tar bort röran på webbsidor. Den vanligaste fallgropen vid distribution är att resurser eller inloggningsomdirigeringar använder HTTP eftersom domänvariabeln är fel. Därför måste hantering av den publika URL:en och beständig status få lika mycket uppmärksamhet som uppstarten av image:n.

Gör det lokala kommandot till en inspekterbar tjänst

Följande kommando synliggör containergränsen utan att låtsas konfigurera alla externa tjänster.

docker run -d \
  --name wallabag \
  --restart unless-stopped \
  -p 127.0.0.1:80:80 \
  -v wallabag-data:/var/www/wallabag/data \
  -e SYMFONY__ENV__DOMAIN_NAME=https://app.example.com \
  wallabag/wallabag:latest

Innan du öppnar ingressen ska du inspektera den upplösta miljön, mounts och lyssnaren. Lägg till de granskade anslutningsinställningarna för Postgres eller MariaDB, Redis och schemalagda import workers; använd privata namn för privata tjänster. En lyckad start är klar först när du kan spara en vanlig artikel och en svår sida, köra hämtning i bakgrunden, synkronisera en mobilklient och söka i arkiverat innehåll – inte när docker ps skriver ut Up.

Vad Wallabag är beroende av

Dra tre gränser runt Wallabag: ingress till port 80, beständig status och stödkrav. Containern kan ersättas, men de två andra behöver tydliga ägare. Nätverkskontraktet för Wallabag omfattar Postgres eller MariaDB, Redis och schemalagda import workers. Håll privata endpoints på intern DNS, tillåt endast nödvändiga utgående anrop och ge Wallabag en service credential med begränsad behörighet.

Diagrammet är komplett när en ren klient kan spara en vanlig artikel och en svår sida, köra hämtning i bakgrunden, synkronisera en mobilklient och söka i arkiverat innehåll. Samla in tids- och resursdata för hämtning av sidor, parserarbete, bildnedladdningar, köer och databasens tillväxt. Om transaktionen misslyckas visar den första gräns som inte beter sig enligt dokumentationen om du ska undersöka routing, lokal kapacitet eller en stödjande tjänst.

Lås ned Wallabag efter bootstrap

Ärv inte säkerhetsantaganden från en lokal guide. Wallabags specifika risk är att standarduppgifter behålls eller att trusted proxy-konfiguration hoppas över. I produktion bör du därför ta bort standarduppgifter, skydda import tokens och konfigurera trusted proxies innan läsaren exponeras.

SYMFONY__ENV__DOMAIN_NAME är konfiguration, inte en secret; håll dess värde explicit och skydda samtidigt de separata credentials som Wallabag använder. Begränsa åtkomst till filsystem och nätverk, skydda setup-endpoints och definiera gränser för upload, requests eller exekvering kring hämtning av sidor, parserarbete, bildnedladdningar, köer och databasens tillväxt.

Gör den publika origin tydlig

Exponera ett HTTPS-hostnamn för Wallabag och håll rå port 80 privat. Ange domännamnet som den slutliga HTTPS-URL:en. Det hindrar webbläsare och API-klienter från att lära sig två konkurrerande adresser.

Kör den beprövade transaktionen från en ren klient och inspektera den första requesten som misslyckas. Använd guiden för anpassad domän när DNS eller TLS är fel. Behandla ”resurser eller inloggningsomdirigeringar använder HTTP eftersom domänvariabeln är fel” som en separat applikationsdiagnos när routingen är bekräftad.

Separera utbytbara containers från beständig data

Den beständiga återställningsmängden består av databas, images, importerat innehåll och konfiguration. Moun­ta /var/www/wallabag/data före bootstrap, skriv in ofarliga exempeldata och ersätt containern för att bevisa att sökvägen faktiskt är beständig. En volume skyddar data när containern ersätts, men inte mot förlust av hosten, oavsiktlig radering eller korruption på applikationsnivå.

Ta säkerhetskopior som förstår datakällan: använd logiska dumps för aktiva databaser när det krävs och kopiera filer endast från ett konsistent tillstånd. Förvara en krypterad kopia utanför Wallabag-hosten. Acceptanskriteriet för en återställning är specifikt – artiklar, taggar, anteckningar, användare och API tokens ska komma tillbaka och mobilklienten ska synkronisera. Guiden om återställningstestade säkerhetskopior förklarar varför ett lyckat jobb i sig inte räcker.

Bevis att samla in innan Wallabag går live

För Wallabag ska du definiera en beprövad transaktion före lanseringen: spara en vanlig artikel och en svår sida, kör hämtning i bakgrunden, synkronisera en mobilklient och sök i arkiverat innehåll. Lägg dess förutsättningar, förväntade svar och steg för rensning i versionshantering utan secret values. Pinna den image som används för att etablera denna referens.

Använd transaktionen för att validera ett byte och en oberoende återställning. Den återställda tjänsten är godkänd först när artiklar, taggar, anteckningar, användare och API tokens kommer tillbaka och mobilklienten synkroniserar. Observera samtidigt hämtning av sidor, parserarbete, bildnedladdningar, köer och databasens tillväxt och gör den långsammaste eller mest begränsade delen till ett service-level alert.

Grindkontrollen behöver också ett negativt fall: neka tillfälligt testidentiteten åtkomst till Postgres eller MariaDB, Redis och schemalagda import workers. Bekräfta att Wallabag ger ett handlingsbart fel samtidigt som data bevaras, återställ det giltiga tillståndet och upprepa den beprövade transaktionen. Genom att behålla båda resultaten förhindrar du att en ytlig health endpoint blir det enda produktionsbeviset.

Drifta Wallabag utifrån den verkliga flaskhalsen

Bygg dashboards kring hämtning av sidor, parserarbete, bildnedladdningar, köer och databasens tillväxt. Ett CPU-diagram utan kontext från den arbetsbelastningen kan inte förklara varför Wallabag är långsamt. Lägg till en syntetisk eller schemalagd kontroll som försöker spara en vanlig artikel och en svår sida, köra hämtning i bakgrunden, synkronisera en mobilklient och söka i arkiverat innehåll med ofarliga testdata.

Inför en uppgradering måste du ta hänsyn till följande applikationsspecifika risk: Wallabags migreringar, parserbeteende och worker-konfiguration bör testas mot representativa sparade sidor. Återställ en aktuell säkerhetskopia till en isolerad deployment, kör migreringarna där och jämför beteendet. Om resurser eller inloggningsomdirigeringar använder HTTP eftersom domänvariabeln är fel ska du undersöka den berörda gränsen – publik origin, lagring eller dependency – innan du ändrar orelaterade inställningar.

Använd Dockup för plattformslagret

För Wallabag kan Dockup skapa routingen och TLS-certifikatet, bevara mounts, leverera secrets och placera Postgres eller MariaDB, Redis och schemalagda import workers på privata nätverk samtidigt som deployment sker till antingen Dockup eller anslutna servrar.

Release-grinden är fortfarande den konkreta Wallabag-transaktionen: spara en vanlig artikel och en svår sida, kör hämtning i bakgrunden, synkronisera en mobilklient och sök i arkiverat innehåll. Verifiera också återställningstillståndet – artiklar, taggar, anteckningar, användare och API tokens ska komma tillbaka och mobilklienten ska synkronisera. Dessa två kontroller visar om deploymenten fungerar och om den kan återställas.

Vanliga frågor

Vad behöver Wallabag för en produktionsdeployment?

Routa Wallabag-containern på port 80 via en enda HTTPS-origin. Nätverkskravet för stödtjänster är Postgres eller MariaDB, Redis och schemalagda import workers. Anse inte att Wallabag är klar förrän du kan spara en vanlig artikel och en svår sida, köra hämtning i bakgrunden, synkronisera en mobilklient och söka i arkiverat innehåll.

Vilka Wallabag-data ska ingå i en säkerhetskopia?

Gör /var/www/wallabag/data beständig och inkludera databas, images, importerat innehåll och konfiguration i samma återställningsmanifest. En ren Wallabag-återställning är godkänd först när artiklar, taggar, anteckningar, användare och API tokens kommer tillbaka och mobilklienten synkroniserar.

Kräver Wallabag HTTPS bakom en reverse proxy?

Använd HTTPS för den publika Wallabag-originen och behåll port 80 på den interna routen. Tillämpa Wallabag-inställningen korrekt: ange domännamnet som den slutliga HTTPS-URL:en. För Wallabag skyddar HTTPS credentials eller användarinnehåll under överföring och håller origin-känsligt klientbeteende konsekvent.

Hur bör en Wallabag-uppgradering testas?

Återställ aktuell Wallabag-status till en isolerad deployment, tillämpa kandidatversionen och upprepa dess acceptanstransaktion. Var särskilt uppmärksam eftersom Wallabags migreringar, parserbeteende och worker-konfiguration bör testas mot representativa sparade sidor. Behåll den tidigare Wallabag-imagen tills gränsen för datamigrering och rollback är förstådd.