Jak v roce 2026 provozovat Change Detection samostatně: načítání v prohlížeči, upozornění a persistence

Kontejner Change Detection může být ve stavu green, i když je nefunkční úloha, na které uživatelům záleží. U Change Detection obvykle toto skryté selhání znamená, že běžné requesty narazí na bot challenges nebo není dostupná browser service. Tento průvodce považuje za akceptační test následující scénář: sledovat jednu statickou stránku a jednu stránku vykreslovanou JavaScriptem, provést řízenou změnu a pro každou z nich přijmout notifikaci s diffem. Nasazení proto staví zpětně od tohoto výsledku.

Change Detection má v tomto stacku konkrétní roli: monitorování změn stránek bez nutnosti psát scraper. Produkční otázka tedy nezní, zda port 5000 jednou odpoví, ale zda stav, závislosti a veřejná adresa zůstanou ve shodě i po restartu, aktualizaci a obnově.

Oddělte Change Detection od jeho závislostí

Nejmenší zodpovědná topologie Change Detection obsahuje jeden privátní listener na portu 5000, ingress route a zdokumentovanou hranici stavu. Síťový kontrakt Change Detection představuje remote browser, například Playwright, pro stránky náročné na JavaScript. Privátní endpointy ponechte na interním DNS, povolte pouze potřebné odchozí požadavky a Change Detection přidělte service credential s omezeným rozsahem oprávnění.

Topologii ověřte tak, že z čistého klienta nastavíte sledování jedné statické stránky a jedné stránky vykreslované Javascriptem, provedete řízenou změnu a přijmete pro každou z nich notifikaci s diffem. Během běhu sledujte browser-worker concurrency, historii screenshotů, latenci cíle a anti-bot challenges. Výsledek vám ukáže, zda je další zlepšení potřeba v paměti, úložišti, síti nebo v samostatném workeru, místo abyste jen nahodile zvětšovali kontejner.

Udělejte obnovu Change Detection měřitelnou

Definujte recovery point a recovery time pro Change Detection pomocí definic sledování, historie, snapshotů a nastavení notifikací. Před bootstrapem připojte /datastore, zapište neškodná testovací data a nahraďte kontejner, abyste ověřili, že je tato cesta skutečně persistentní. Named volume řeší persistenci při redeployi, nikoli kompromitaci nebo ztrátu serveru.

Připravte čisté prostředí pro obnovu, použijte stejnou pinned verzi aplikace a ověřte, že se vrátí definice sledování, historie a cíle notifikací a že bude znovu detekována řízená změna. Zaznamenejte příkazy, opravy ownershipu a uplynulý čas. Průvodce zálohováním představuje užitečný standard: záloze důvěřujte až po obnově, ne po nahrání.

Po bootstrapu Change Detection zabezpečte

Nepřebírejte bezpečnostní předpoklady z lokálního tutoriálu. Konkrétním problémem Change Detection je vystavení historie sledování a tokenů notifikací bez autentizace. Produkce by proto měla historii sledování chránit, protože může obsahovat privátní URL, cookies a přihlašovací údaje pro notifikace.

BASE_URL je konfigurace, nikoli secret; jeho hodnotu udržujte explicitní a chraňte samostatné credentials používané Change Detection. Omezte přístup k souborovému systému a síti, zabezpečte setup endpointy a definujte limity uploadu, requestů nebo spouštění s ohledem na browser-worker concurrency, historii screenshotů, latenci cíle a anti-bot challenges.

Jaké důkazy shromáždit před spuštěním Change Detection

Než dorazí skuteční uživatelé, vytvořte pro Change Detection release worksheet. Musí obsahovat pinned image, port 5000, canonical origin, persistentní cesty a vlastníka remote browseru, například Playwrightu, pro stránky náročné na JavaScript. Připojte očekávaný výsledek této transakce: sledovat jednu statickou stránku a jednu stránku vykreslovanou Javascriptem, provést řízenou změnu a přijmout pro každou z nich notifikaci s diffem.

Worksheet použijte po běžné náhradě i po čisté obnově. Obnova je akceptována pouze tehdy, pokud se vrátí definice sledování, historie a cíle notifikací a znovu se detekuje řízená změna. Shromážděte také krátký resource trace pokrývající browser-worker concurrency, historii screenshotů, latenci cíle a anti-bot challenges; uchovávejte jej spolu s releasem, aby se budoucí změny kapacity porovnávaly se stejným workloadem.

Zahrňte jedno řízené selhání: testovací identitě dočasně odepřete přístup k remote browseru, například Playwrightu, pro stránky náročné na JavaScript. Ověřte, že Change Detection nahlásí problém na správné hranici, obnovte platný stav a transakci spusťte znovu. Tím ověříte viditelnost chyb, nikoli pouze úspěch, a zabráníte tomu, aby zdravě vypadající rozhraní skrývalo nefunkční worker, callback nebo připojení k databázi.

Zajistěte reprodukovatelný start Change Detection

Minimální příkaz je užitečný, pokud odhalí, co bude platforma později spravovat.

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

Port 5000 zde zůstává privátní pro hostitele a každá potřebná cesta je explicitní. Přidejte ověřené connection settings pro remote browser, například Playwright, pro stránky náročné na JavaScript; u privátních služeb používejte privátní názvy. Start ověřte pomocí logů i aplikačního důkazu: sledovat jednu statickou stránku a jednu stránku vykreslovanou Javascriptem, provést řízenou změnu a přijmout pro každou z nich notifikaci s diffem. Po ověření image version zamkněte, aby běžná náhrada tiše nezměnila chování.

Domény, proxy headers a port 5000

Externí URL Change Detection berte jako konfiguraci, která musí přežít redeploy. Nejprve nastavte BASE_URL a jakýkoli browser endpoint na adresy dostupné z kontejneru; poté nasměrujte hostname na port 5000 se zachováním původního hostu a schématu.

Checklist reachability nasazení může prokázat, že requesty vstupují do kontejneru. Poté by se známé selhání — běžné requesty narazí na bot challenges nebo není dostupná browser service — mělo vyšetřovat v Change Detection, jeho stavu nebo workloadu, nikoli v automatizaci certifikátů.

Provozujte Change Detection s ohledem na skutečné úzké hrdlo

Dashboardy postavte kolem browser-worker concurrency, historie screenshotů, latence cíle a anti-bot challenges. Graf CPU bez kontextu tohoto workloadu nedokáže vysvětlit, proč je Change Detection pomalý. Přidejte synthetic nebo scheduled check, který pomocí neškodných testovacích dat zkusí sledovat jednu statickou stránku a jednu stránku vykreslovanou Javascriptem, provést řízenou změnu a přijmout pro každou z nich notifikaci s diffem.

Před upgradem zohledněte toto riziko specifické pro aplikaci: Playwright image versions, datastore migrations a notification integrations by se měly aktualizovat společně. Obnovte nedávnou zálohu do izolovaného nasazení, spusťte tam migrations a porovnejte chování. Pokud běžné requesty narazí na bot challenges nebo není dostupná browser service, nejprve prozkoumejte příslušnou hranici — public origin, storage nebo dependency — a teprve potom upravujte nesouvisející nastavení.

Co by měl Dockup pro Change Detection automatizovat

Šablona Dockup by měla obsahovat image, port 5000, mounts, health timing, doménu, TLS a předávání secretů. Dockup by měl privátní části remote browseru, například Playwrightu, pro stránky náročné na JavaScript ponechat v interní síti a nevystavovat žádný další veřejný port. Stejné nasazení může cílit na servery Dockup nebo kapacitu připojenou zákazníkem.

Po zprovoznění route aplikujte veřejné nastavení a zkuste sledovat jednu statickou stránku a jednu stránku vykreslovanou Javascriptem, provést řízenou změnu a přijmout pro každou z nich notifikaci s diffem. Zálohujte definice sledování, historii, snapshoty a nastavení notifikací a zařaďte cvičení obnovy do provozního plánu; jde o odpovědnosti Change Detection, které zůstávají viditelné i po provisioningu infrastruktury.

Často kladené otázky

Co Change Detection potřebuje pro produkční nasazení?

Kontejner Change Detection na portu 5000 směrujte přes jeden HTTPS origin. Podporovaným síťovým požadavkem je remote browser, například Playwright, pro stránky náročné na JavaScript. Change Detection nepovažujte za připravený, dokud nedokážete sledovat jednu statickou stránku a jednu stránku vykreslovanou Javascriptem, provést řízenou změnu a přijmout pro každou z nich notifikaci s diffem.

Která data Change Detection patří do zálohy?

Persistujte /datastore a do stejného recovery manifestu zahrňte definice sledování, historii, snapshoty a nastavení notifikací. Čistá obnova Change Detection je úspěšná pouze tehdy, pokud se vrátí definice sledování, historie a cíle notifikací a znovu se detekuje řízená změna.

Vyžaduje Change Detection za reverse proxy HTTPS?

Pro veřejný origin Change Detection používejte HTTPS a port 5000 ponechte na interní route. Nastavení Change Detection aplikujte správně: BASE_URL a jakýkoli browser endpoint nastavte na adresy dostupné z kontejneru. U Change Detection HTTPS chrání credentials nebo obsah uživatelů při přenosu a zachovává konzistentní chování klienta závislé na originu.

Jak testovat upgrade Change Detection?

Obnovte aktuální stav Change Detection do izolovaného nasazení, aplikujte kandidátní verzi a zopakujte jeho akceptační transakci. Věnujte tomu zvláštní pozornost, protože Playwright image versions, datastore migrations a notification integrations by se měly aktualizovat společně. Předchozí Change Detection image ponechte k dispozici, dokud nebudete rozumět hranici migrace dat a rollbacku.