Как да хоствате самостоятелно Change Detection през 2026 г.: извличане в браузър, известия и persistent storage

Контейнерът на Change Detection може да показва зелено състояние, докато задачата, която интересува потребителите, не работи. При Change Detection този скрит проблем обикновено означава, че обикновените заявки срещат bot challenges или browser service е недостъпен. Това ръководство приема за acceptance test следното: „наблюдавайте една статична страница и една страница, рендерирана с JavaScript, направете контролирана промяна и получете diff notification за всяка“ — и изгражда deployment-а обратно от този резултат.

Change Detection има конкретна роля в stack-а: наблюдение на промени в страници, без да пишете scraper. Production въпросът следователно не е дали порт 5000 отговаря веднъж, а дали state-ът, dependencies и public address продължават да са съгласувани след restart, update и restore.

Отделете Change Detection от неговите dependencies

Най-малката отговорна топология за Change Detection съдържа един private listener на порт 5000, ingress route и документирана state boundary. Мрежовият contract за Change Detection е remote browser, например Playwright, за страници с интензивно използване на JavaScript. Дръжте private endpoints във вътрешен DNS, разрешете само необходимите outbound calls и дайте на Change Detection service credential с ограничен scope.

Валидирайте топологията, като накарате clean client да наблюдава една статична страница и една страница, рендерирана с JavaScript, да направите контролирана промяна и да получите diff notification за всяка. Наблюдавайте browser-worker concurrency, screenshot history, target latency и anti-bot challenges, докато процесът работи. Резултатът показва дали следващото подобрение трябва да бъде в memory, storage, networking или отделен worker, вместо да насърчава произволно оразмеряване на контейнера.

Направете recovery на Change Detection измерим

Дефинирайте recovery point и recovery time за Change Detection чрез watch definitions, history, snapshots и notification settings. Mount-нете /datastore преди bootstrap, запишете безвредни sample data и заменете контейнера, за да докажете, че този path действително е persistent. Named volume решава persistence при redeploy; не решава компрометиране или загуба на сървъра.

Изградете clean restore environment, използвайте същата pinned application version и докажете, че watch definitions, history и notification targets се възстановяват и че контролираната промяна отново се открива. Запишете commands, fixes за ownership и изминалото време. Ръководството за backups е полезен стандарт: backup-ът е надежден след restoration, а не след upload.

Затегнете сигурността на Change Detection след bootstrap

Не пренасяйте security assumptions от local tutorial. Специфичният проблем при Change Detection е излагането на watch history и notification tokens без authentication. Затова в production трябва да защитите watch history, тъй като тя може да съдържа private URLs, cookies и notification credentials.

BASE_URL е configuration, а не secret; оставете стойността му explicit, като защитите отделните credentials, използвани от Change Detection. Ограничете filesystem и network access, защитете setup endpoints и дефинирайте upload, request или execution limits около browser-worker concurrency, screenshot history, target latency и anti-bot challenges.

Данни, които да съберете, преди Change Detection да влезе в production

Преди да дойдат реални потребители, създайте release worksheet за Change Detection. Тя трябва да посочва pinned image, порт 5000, canonical origin, persistent paths и owner-а на remote browser, например Playwright, за страници с интензивно използване на JavaScript. Прикачете очаквания резултат от тази transaction: наблюдавайте една статична страница и една страница, рендерирана с JavaScript, направете контролирана промяна и получете diff notification за всяка.

Използвайте worksheet-а след нормална замяна и след clean restore. Recovery е приет само ако watch definitions, history и notification targets се възстановят и контролираната промяна бъде открита отново. Съберете и кратък resource trace, обхващащ browser-worker concurrency, screenshot history, target latency и anti-bot challenges; съхранявайте го до release-а, за да могат бъдещите промени в capacity да се сравняват със същото workload.

Включете един controlled failure: временно откажете на test identity достъп до remote browser, например Playwright, за страници с интензивно използване на JavaScript. Потвърдете, че Change Detection отчита проблема на правилната boundary, възстановете валидното състояние и изпълнете transaction-а отново. Това проверява error visibility, а не само успеха, и предотвратява интерфейс, който изглежда здрав, да прикрива счупен worker, callback или database connection.

Направете startup-а на Change Detection възпроизводим

Минималната команда е полезна, когато показва какво по-късно ще управлява platform-ата.

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

Тук порт 5000 остава private за host-а, а всеки необходим path е explicit. Добавете прегледаните connection settings за remote browser, например Playwright, за страници с интензивно използване на JavaScript; използвайте private names за private services. Проверете startup-а както чрез logs, така и с application-specific proof: наблюдавайте една статична страница и една страница, рендерирана с JavaScript, направете контролирана промяна и получете diff notification за всяка. След като потвърдите работата, фиксирайте image version, за да не промени обикновена замяна поведението незабелязано.

Домейни, proxy headers и порт 5000

Третирайте external Change Detection URL като configuration, която се запазва при redeploy. Първо задайте BASE_URL и всеки browser endpoint към адреси, до които контейнерът има достъп; след това насочете hostname към порт 5000, като запазите оригиналните host и scheme.

Checklist-ът за reachability при deployment може да докаже, че заявките влизат в контейнера. След това познатият проблем — обикновените заявки срещат bot challenges или browser service е недостъпен — трябва да се изследва в Change Detection, неговия state или workload-а, а не в automation-а за сертификати.

Оперирaйте Change Detection спрямо реалния му bottleneck

Изградете dashboards около browser-worker concurrency, screenshot history, target latency и anti-bot challenges. CPU graph без този workload context не може да обясни защо Change Detection е бавен. Добавете synthetic или scheduled check, който се опитва да наблюдава една статична страница и една страница, рендерирана с JavaScript, да направи контролирана промяна и да получи diff notification за всяка, използвайки безвредни test data.

Преди upgrade отчетете следния application-specific hazard: Playwright image versions, datastore migrations и notification integrations трябва да се променят заедно. Възстановете recent backup в isolated deployment, изпълнете migrations там и сравнете поведението. Ако обикновените заявки срещат bot challenges или browser service е недостъпен, проверете засегнатата boundary — public origin, storage или dependency — преди да променяте несвързани настройки.

Какво трябва да автоматизира Dockup за Change Detection

Dockup template трябва да кодира image, порт 5000, mounts, health timing, domain, TLS и secret delivery. Dockup трябва да държи private частите на remote browser, например Playwright, за страници с интензивно използване на JavaScript във вътрешната мрежа и да не излага допълнителен public port. Същият deployment може да се насочва към Dockup servers или към capacity, прикрепена от клиента.

След като route-ът е активен, приложете public setting-а и опитайте да наблюдавате една статична страница и една страница, рендерирана с JavaScript, да направите контролирана промяна и да получите diff notification за всяка. Направете backup на watch definitions, history, snapshots и notification settings и включете restore exercise в operating plan-а; това са отговорности на Change Detection, които остават видими и след provisioning-а на infrastructure.

Често задавани въпроси

Какво е необходимо на Change Detection за production deployment?

Насочете контейнера на Change Detection през порт 5000 към един HTTPS origin. Поддържащото мрежово изискване е remote browser, например Playwright, за страници с интензивно използване на JavaScript. Не обявявайте Change Detection за готов, докато не можете да наблюдавате една статична страница и една страница, рендерирана с JavaScript, да направите контролирана промяна и да получите diff notification за всяка.

Кои данни на Change Detection трябва да бъдат включени в backup?

Направете /datastore persistent и включете watch definitions, history, snapshots и notification settings в един и същ recovery manifest. Clean restore на Change Detection е успешен само когато watch definitions, history и notification targets се възстановят и контролираната промяна бъде открита отново.

Изисква ли Change Detection HTTPS зад reverse proxy?

Използвайте HTTPS за public Change Detection origin и оставете порт 5000 във вътрешния route. Приложете правилно настройката на Change Detection: задайте BASE_URL и всеки browser endpoint към адреси, до които контейнерът има достъп. При Change Detection HTTPS защитава credentials или user content при пренос и поддържа консистентно client behavior, зависещо от origin.

Как трябва да се тества upgrade на Change Detection?

Възстановете текущия state на Change Detection в isolated deployment, приложете candidate version и повторете acceptance transaction. Обърнете специално внимание, тъй като Playwright image versions, datastore migrations и notification integrations трябва да се променят заедно. Запазете предишния Change Detection image, докато не изясните неговата data-migration и rollback boundary.