Slik drifter du Change Detection selv i 2026: Henting i nettleser, varsler og persistens

En Change Detection-container kan være grønn selv om jobben brukerne bryr seg om, er ødelagt. For Change Detection er den skjulte feilen vanligvis at enkle forespørsler møter bot-utfordringer, eller at nettlesertjenesten ikke er tilgjengelig. Denne veiledningen bruker «overvåk én statisk side og én JavaScript-rendret side, introduser en kontrollert endring og motta et diff-varsel for hver» som akseptansetest, og bygger utrullingen baklengs fra dette resultatet.

Change Detection har en spesifikk rolle i stakken: overvåking av sideendringer uten å skrive en scraper. Produksjonsspørsmålet er derfor ikke om port 5000 svarer én gang, men om tilstand, avhengigheter og offentlig adresse fortsatt stemmer overens etter en omstart, oppdatering og gjenoppretting.

Skill Change Detection fra avhengighetene

Den minste ansvarlige Change Detection-topologien består av én privat lytter på port 5000, en ingress-rute og en dokumentert tilstandsgrense. Nettverkskontrakten for Change Detection er en ekstern nettleser som Playwright for JavaScript-tunge sider. Hold private endepunkter på intern DNS, tillat bare nødvendige utgående kall og gi Change Detection en avgrenset tjenestelegitimasjon.

Valider topologien ved å be en ren klient overvåke én statisk side og én JavaScript-rendret side, introdusere en kontrollert endring og motta et diff-varsel for hver. Følg med på samtidighet for nettleserarbeidere, historikk for skjermbilder, mållatensitet og anti-bot-utfordringer mens den kjører. Resultatet forteller deg om den neste forbedringen hører hjemme i minne, lagring, nettverk eller en separat worker, i stedet for å oppmuntre til tilfeldig dimensjonering av containere.

Gjør gjenoppretting av Change Detection målbar

Definer recovery point og recovery time for Change Detection med utgangspunkt i overvåkingsdefinisjoner, historikk, øyeblikksbilder og varslingsinnstillinger. Monter /datastore før bootstrap, skriv ufarlige eksempeldata og erstatt containeren for å bevise at banen faktisk er persistent. Et navngitt volume løser persistens ved ny utrulling, men løser ikke kompromittering eller tap av serveren.

Bygg et rent restore-miljø, bruk den samme fastlåste applikasjonsversjonen og bevis at overvåkingsdefinisjoner, historikk og varslingsmål kommer tilbake, og at den kontrollerte endringen oppdages igjen. Registrer kommandoer, rettinger av eierskap og medgått tid. Veiledningen for sikkerhetskopiering er en nyttig standard: En sikkerhetskopi er klarert etter gjenoppretting, ikke etter opplasting.

Lås ned Change Detection etter bootstrap

Ikke overfør sikkerhetsantakelser fra en lokal veiledning. Change Detection har spesielt behov for å unngå at overvåkingshistorikk og varslingstokens eksponeres uten autentisering. Produksjonsmiljøet bør derfor beskytte overvåkingshistorikken, fordi den kan inneholde private URL-er, cookies og varslingslegitimasjon.

BASE_URL er konfigurasjon, ikke en hemmelighet; hold verdien eksplisitt, samtidig som du beskytter den separate legitimasjonen som brukes av Change Detection. Begrens tilgang til filsystem og nettverk, beskytt oppsettsendepunkter og definer grenser for opplasting, forespørsler eller kjøring rundt samtidighet for nettleserarbeidere, historikk for skjermbilder, mållatensitet og anti-bot-utfordringer.

Dokumentasjon du bør samle inn før Change Detection settes i produksjon

Før de virkelige brukerne kommer, lager du et release-regneark for Change Detection. Det må angi det fastlåste imaget, port 5000, kanonisk origin, persistente stier og eieren av en ekstern nettleser som Playwright for JavaScript-tunge sider. Legg ved forventet resultat for denne transaksjonen: overvåk én statisk side og én JavaScript-rendret side, introduser en kontrollert endring og motta et diff-varsel for hver.

Bruk regnearket etter en normal erstatning og etter en ren restore. Gjenoppretting godtas bare hvis overvåkingsdefinisjoner, historikk og varslingsmål kommer tilbake, og den kontrollerte endringen oppdages igjen. Samle også inn et kort ressursspor som dekker samtidighet for nettleserarbeidere, historikk for skjermbilder, mållatensitet og anti-bot-utfordringer; oppbevar det sammen med releasen, slik at fremtidige kapasitetsendringer sammenlignes med samme arbeidsbelastning.

Inkluder én kontrollert feil: nekt testidentiteten midlertidig tilgang til en ekstern nettleser som Playwright for JavaScript-tunge sider. Bekreft at Change Detection rapporterer problemet ved riktig grense, gjenopprett den gyldige tilstanden og kjør transaksjonen på nytt. Dette kontrollerer feilsynlighet, ikke bare suksess, og hindrer at et grensesnitt som ser friskt ut, skjuler en ødelagt worker, callback eller databaseforbindelse.

Gjør oppstart av Change Detection reproduserbar

En minimal kommando er nyttig når den viser hva plattformen senere skal administrere.

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

Her forblir port 5000 privat på verten, og alle nødvendige stier er eksplisitte. Legg til de gjennomgåtte tilkoblingsinnstillingene for en ekstern nettleser som Playwright for JavaScript-tunge sider; bruk private navn for private tjenester. Bekreft oppstart med både logger og det applikasjonsspesifikke beviset: overvåk én statisk side og én JavaScript-rendret side, introduser en kontrollert endring og motta et diff-varsel for hver. Når dette er bekreftet, låser du image-versjonen slik at en rutinemessig erstatning ikke endrer atferden i det stille.

Domener, proxy-headere og port 5000

Behandle den eksterne Change Detection-URL-en som konfigurasjon som skal overleve nye utrullinger. Sett først BASE_URL og eventuelle nettleserendepunkter til adresser containeren kan nå; rut deretter vertsnavnet til port 5000, med den opprinnelige host-en og scheme-et intakt.

Sjekklisten for tilgjengelighet ved utrulling kan bevise at forespørsler kommer inn i containeren. Etter dette bør den kjente feilen – at enkle forespørsler møter bot-utfordringer, eller at nettlesertjenesten ikke er tilgjengelig – undersøkes i Change Detection, tilstanden eller arbeidsbelastningen, ikke i sertifikatautomatiseringen.

Driv Change Detection med utgangspunkt i den faktiske flaskehalsen

Bygg dashboards rundt samtidighet for nettleserarbeidere, historikk for skjermbilder, mållatensitet og anti-bot-utfordringer. En CPU-graf uten denne arbeidsbelastningskonteksten kan ikke forklare hvorfor Change Detection er treg. Legg til en syntetisk eller planlagt kontroll som forsøker å overvåke én statisk side og én JavaScript-rendret side, introdusere en kontrollert endring og motta et diff-varsel for hver, ved hjelp av ufarlige testdata.

Før du oppgraderer, må du ta høyde for denne applikasjonsspesifikke risikoen: Playwright-imageversjoner, migreringer av datastore og varslingsintegrasjoner bør flyttes samlet. Gjenopprett en nylig sikkerhetskopi til en isolert utrulling, kjør migreringene der og sammenlign atferden. Hvis enkle forespørsler møter bot-utfordringer, eller nettlesertjenesten ikke er tilgjengelig, undersøker du den aktuelle grensen – offentlig origin, lagring eller avhengighet – før du endrer irrelevante innstillinger.

Hva Dockup bør automatisere for Change Detection

En Dockup-mal bør inneholde image, port 5000, mounts, helsesjekktiming, domene, TLS og levering av hemmeligheter. Dockup bør holde private deler av en ekstern nettleser som Playwright for JavaScript-tunge sider på internt nettverk og ikke eksponere noen ekstra offentlig port. Den samme utrullingen kan målrettes mot Dockup-servere eller kapasitet som kunden har koblet til.

Når ruten er aktiv, bruker du den offentlige innstillingen og forsøker å overvåke én statisk side og én JavaScript-rendret side, introdusere en kontrollert endring og motta et diff-varsel for hver. Sikkerhetskopier overvåkingsdefinisjoner, historikk, øyeblikksbilder og varslingsinnstillinger, og behold restore-øvelsen i driftsplanen; dette er Change Detection-ansvar som fortsatt må være synlig etter provisjonering av infrastrukturen.

Ofte stilte spørsmål

Hva trenger Change Detection for en produksjonsutrulling?

Rout Change Detection-containeren på port 5000 gjennom én HTTPS-origin. Det støttende nettverkskravet er en ekstern nettleser som Playwright for JavaScript-tunge sider. Ikke betrakt Change Detection som klar før du kan overvåke én statisk side og én JavaScript-rendret side, introdusere en kontrollert endring og motta et diff-varsel for hver.

Hvilke Change Detection-data bør inngå i en sikkerhetskopi?

Gjør /datastore persistent, og inkluder overvåkingsdefinisjoner, historikk, øyeblikksbilder og varslingsinnstillinger i det samme gjenopprettingsmanifestet. En ren Change Detection-restore er bare vellykket når overvåkingsdefinisjoner, historikk og varslingsmål kommer tilbake, og den kontrollerte endringen oppdages igjen.

Krever Change Detection HTTPS bak en reverse proxy?

Bruk HTTPS for den offentlige Change Detection-originen, og behold port 5000 på den interne ruten. Bruk Change Detection-innstillingen riktig: Sett BASE_URL og eventuelle nettleserendepunkter til adresser containeren kan nå. For Change Detection beskytter HTTPS legitimasjon eller brukerinnhold under overføring og sørger for konsistent klientatferd som er avhengig av origin.

Hvordan bør en Change Detection-oppgradering testes?

Gjenopprett gjeldende Change Detection-tilstand til en isolert utrulling, bruk kandidatversjonen og gjenta akseptansetransaksjonen. Vær spesielt oppmerksom på at Playwright-imageversjoner, migreringer av datastore og varslingsintegrasjoner bør flyttes samlet. Behold det forrige Change Detection-imaget til grensen for datamigrering og rollback er forstått.