Så driftar du Change Detection själv 2026: hämtning i webbläsare, aviseringar och beständig lagring

En Change Detection-container kan visa grönt samtidigt som det jobb användarna bryr sig om är trasigt. För Change Detection beror det dolda felet oftast på att vanliga requests stöter på botutmaningar eller att webbläsartjänsten inte går att nå. Den här guiden använder följande som acceptanstest: ”bevaka en statisk sida och en JavaScript-renderad sida, gör en kontrollerad ändring och ta emot en diff-avisering för varje sida”. Därefter byggs deploymenten bakifrån utifrån det resultatet.

Change Detection har en specifik roll i stacken: övervakning av sidändringar utan att du behöver skriva en scraper. Produktionsfrågan är därför inte om port 5000 svarar en gång, utan om state, beroenden och den publika adressen fortsätter att stämma efter en omstart, uppdatering och återställning.

Separera Change Detection från dess beroenden

Den minsta ansvarsfulla topologin för Change Detection innehåller en privat listener på port 5000, en ingress-route och en dokumenterad gräns för state. Nätverkskontraktet för Change Detection är en remote browser som Playwright för JavaScript-tunga sidor. Håll privata endpoints på intern DNS, tillåt endast nödvändiga utgående anrop och ge Change Detection en avgränsad service credential.

Validera topologin genom att låta en ren klient bevaka en statisk sida och en JavaScript-renderad sida, göra en kontrollerad ändring och ta emot en diff-avisering för varje sida. Övervaka browser-worker-concurrency, screenshot-historik, mållatens och antibotutmaningar medan det körs. Resultatet visar om nästa förbättring hör hemma i minne, lagring, nätverk eller en separat worker, i stället för att uppmuntra till godtycklig dimensionering av containern.

Gör återställning av Change Detection mätbar

Definiera recovery point och recovery time för Change Detection utifrån bevakningsdefinitioner, historik, snapshots och aviseringsinställningar. Mappa /datastore innan bootstrap, skriv ofarliga exempeldata och ersätt containern för att bevisa att sökvägen faktiskt är beständig. En namngiven volym löser beständighet vid redeploy; den löser inte intrång eller förlust av servern.

Bygg en ren restore-miljö, använd samma pinnade applikationsversion och bevisa att bevakningsdefinitioner, historik och aviseringsmål återkommer och att den kontrollerade ändringen upptäcks igen. Dokumentera kommandon, korrigeringar av ägarskap och förfluten tid. Guiden för säkerhetskopiering är en användbar standard: en säkerhetskopia är tillförlitlig efter en återställning, inte efter en uppladdning.

Lås ned Change Detection efter bootstrap

Ärv inte säkerhetsantaganden från en lokal tutorial. Den specifika risken med Change Detection är att exponerar bevakningshistorik och notification tokens utan autentisering. I produktion bör du därför skydda bevakningshistoriken, eftersom den kan innehålla privata URL:er, cookies och aviseringsuppgifter.

BASE_URL är konfiguration, inte en hemlighet. Håll värdet explicit samtidigt som du skyddar de separata autentiseringsuppgifter som Change Detection använder. Begränsa åtkomst till filsystem och nätverk, skydda setup-endpoints och definiera gränser för uppladdningar, requests eller exekvering kring browser-worker-concurrency, screenshot-historik, mållatens och antibotutmaningar.

Bevis att samla in innan Change Detection går live

Innan riktiga användare kommer in bör du skapa ett release-formulär för Change Detection. Det måste ange den pinnade imagen, port 5000, den kanoniska origin-adressen, beständiga sökvägar och ägaren till en remote browser som Playwright för JavaScript-tunga sidor. Bifoga det förväntade resultatet av denna transaktion: bevaka en statisk sida och en JavaScript-renderad sida, gör en kontrollerad ändring och ta emot en diff-avisering för varje sida.

Använd formuläret efter ett normalt byte och efter en ren restore. Återställningen är godkänd först när bevakningsdefinitioner, historik och aviseringsmål återkommer och den kontrollerade ändringen upptäcks igen. Samla också in en kort resursmätning som täcker browser-worker-concurrency, screenshot-historik, mållatens och antibotutmaningar. Spara den tillsammans med releasen så att framtida kapacitetsändringar kan jämföras med samma workload.

Inkludera ett kontrollerat fel: neka tillfälligt testidentiteten åtkomst till en remote browser som Playwright för JavaScript-tunga sidor. Bekräfta att Change Detection rapporterar problemet vid rätt gräns, återställ det giltiga tillståndet och kör transaktionen igen. Det här testar felens synlighet, inte bara framgång, och hindrar ett gränssnitt som ser friskt ut från att dölja en trasig worker, callback eller databasanslutning.

Gör uppstarten av Change Detection reproducerbar

Ett minimalt kommando är användbart när det visar vad plattformen senare kommer att hantera.

docker run -d \
  --name change-detection \
  --restart unless-stopped \
  -p 127.0.0.1:5000:5000 \
  -v change-detection-data:/datastore \
  -e BASE_URL=https://app.example.com \
  dgtlmoon/changedetection.io:latest

Här förblir port 5000 privat på värden och varje nödvändig sökväg är explicit. Lägg till de granskade anslutningsinställningarna för en remote browser som Playwright för JavaScript-tunga sidor; använd privata namn för privata tjänster. Verifiera uppstarten med både loggar och det applikationsspecifika beviset: bevaka en statisk sida och en JavaScript-renderad sida, gör en kontrollerad ändring och ta emot en diff-avisering för varje sida. När det är verifierat låser du image-versionen så att ett rutinmässigt byte inte ändrar beteendet i tysthet.

Domäner, proxyheaders och port 5000

Behandla den externa URL:en för Change Detection som konfiguration som ska överleva redeploys. Ange först BASE_URL och eventuell browser-endpoint till adresser som containern kan nå. Routa sedan hostname till port 5000 med ursprunglig host och scheme intakta.

Checklistan för deploymentens reachability kan bevisa att requests når containern. Därefter bör det kända felet — att vanliga requests stöter på botutmaningar eller att webbläsartjänsten inte går att nå — utredas i Change Detection, dess state eller dess workload, inte i certifikatautomatiseringen.

Drifta Change Detection utifrån den verkliga flaskhalsen

Bygg dashboards kring browser-worker-concurrency, screenshot-historik, mållatens och antibotutmaningar. Ett CPU-diagram utan det workload-sammanhanget kan inte förklara varför Change Detection är långsamt. Lägg till en syntetisk eller schemalagd kontroll som försöker bevaka en statisk sida och en JavaScript-renderad sida, gör en kontrollerad ändring och tar emot en diff-avisering för varje sida med ofarliga testdata.

Inför en uppgradering måste du ta hänsyn till följande applikationsspecifika risk: Playwright image-versioner, datastore-migreringar och aviseringsintegrationer bör flyttas tillsammans. Återställ en aktuell säkerhetskopia till en isolerad deployment, kör migreringarna där och jämför beteendet. Om vanliga requests stöter på botutmaningar eller webbläsartjänsten inte går att nå, undersök den berörda gränsen — publik origin, lagring eller beroende — innan du ändrar orelaterade inställningar.

Vad Dockup bör automatisera för Change Detection

En Dockup-mall bör ange image, port 5000, mounts, health-timing, domän, TLS och leverans av secrets. Dockup bör hålla privata delar av en remote browser som Playwright för JavaScript-tunga sidor på det interna nätverket och inte exponera någon extra publik port. Samma deployment kan riktas mot Dockup-servrar eller kapacitet som kunden anslutit.

När routen är aktiv aktiverar du den publika inställningen och försöker bevaka en statisk sida och en JavaScript-renderad sida, göra en kontrollerad ändring och ta emot en diff-avisering för varje sida. Säkerhetskopiera bevakningsdefinitioner, historik, snapshots och aviseringsinställningar och behåll restore-övningen i driftplanen. Det här är Change Detection-ansvar som fortfarande måste vara synliga efter att infrastrukturen har provisionerats.

Vanliga frågor

Vad behöver Change Detection för en produktionsdeployment?

Routa Change Detection-containern på port 5000 via en HTTPS-origin. Det stödjande nätverkskravet är en remote browser som Playwright för JavaScript-tunga sidor. Markera inte Change Detection som redo förrän du kan bevaka en statisk sida och en JavaScript-renderad sida, göra en kontrollerad ändring och ta emot en diff-avisering för varje sida.

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

Spara /datastore och inkludera bevakningsdefinitioner, historik, snapshots och aviseringsinställningar i samma recovery-manifest. En ren restore av Change Detection är godkänd först när bevakningsdefinitioner, historik och aviseringsmål återkommer och den kontrollerade ändringen upptäcks igen.

Kräver Change Detection HTTPS bakom en reverse proxy?

Använd HTTPS för den publika Change Detection-originen och behåll port 5000 på den interna routen. Tillämpa Change Detection-inställningen korrekt: ange BASE_URL och eventuell browser-endpoint till adresser som containern kan nå. För Change Detection skyddar HTTPS autentiseringsuppgifter eller användarinnehåll under transport och gör att klientbeteende som är känsligt för origin förblir konsekvent.

Hur bör en uppgradering av Change Detection testas?

Återställ aktuell Change Detection-state till en isolerad deployment, tillämpa kandidatversionen och upprepa dess acceptanstransaktion. Var särskilt uppmärksam eftersom Playwright image-versioner, datastore-migreringar och aviseringsintegrationer bör flyttas tillsammans. Behåll den tidigare Change Detection-imagen tills gränsen för datamigrering och rollback är klarlagd.