Как развернуть Change Detection самостоятельно в 2026 году: загрузка через браузер, уведомления и сохранность данных

Контейнер Change Detection может работать без ошибок, даже если важная для пользователей функция сломана. В случае Change Detection скрытая проблема обычно заключается в том, что обычные HTTP-запросы сталкиваются с bot challenge или сервис браузера недоступен. В этом руководстве в качестве acceptance test используется сценарий «отслеживать одну статическую страницу и одну страницу, отрисованную JavaScript, внести контролируемое изменение и получить diff-уведомление для каждой», а развёртывание строится исходя из этого результата.

У Change Detection есть конкретная роль в стеке: мониторинг изменений страниц без написания scraper. Поэтому в production важно не то, отвечает ли порт 5000 хотя бы один раз, а то, продолжают ли состояние, зависимости и публичный адрес согласованно работать после перезапуска, обновления и восстановления.

Отделите Change Detection от его зависимостей

Минимальная корректная topology Change Detection включает один приватный listener на порту 5000, ingress-маршрут и задокументированную границу хранения состояния. Сетевой контракт Change Detection — удалённый браузер, например Playwright, для страниц с большим количеством JavaScript. Приватные endpoints следует размещать во внутреннем DNS, разрешать только необходимые исходящие вызовы и предоставить Change Detection credentials с ограниченной областью действия.

Проверьте topology: с чистого клиента настройте отслеживание одной статической страницы и одной страницы, отрисованной JavaScript, внесите контролируемое изменение и получите diff-уведомление для каждой. Во время проверки отслеживайте concurrency browser worker, историю screenshot, latency целевых страниц и bot challenges. Результат покажет, что именно требует дальнейшего улучшения — память, storage, сеть или отдельный worker, — вместо произвольного увеличения ресурсов контейнера.

Сделайте восстановление Change Detection измеримым

Определите recovery point и recovery time для Change Detection с учётом watch definitions, истории, snapshots и настроек уведомлений. Подключите /datastore до bootstrap, запишите безвредные тестовые данные и замените контейнер, чтобы убедиться, что этот путь действительно сохраняется. Named volume решает проблему сохранности данных при redeploy, но не защищает от компрометации или потери сервера.

Подготовьте чистое окружение для восстановления, используйте ту же зафиксированную версию приложения и убедитесь, что watch definitions, история и targets уведомлений восстановились, а контролируемое изменение снова обнаруживается. Зафиксируйте команды, исправления владельца и затраченное время. Руководство по резервному копированию задаёт полезный стандарт: backup считается проверенным после восстановления, а не после upload.

Защитите Change Detection после bootstrap

Не переносите предположения о безопасности из локального tutorial. Специфическая проблема Change Detection — возможность раскрытия истории отслеживания и notification tokens без authentication. Поэтому в production необходимо защищать историю отслеживания: в ней могут содержаться приватные URLs, cookies и credentials для уведомлений.

BASE_URL — это configuration, а не secret; явно задайте его значение и отдельно защитите credentials, используемые Change Detection. Ограничьте доступ к filesystem и сети, защитите setup endpoints и установите лимиты на upload, requests или execution с учётом concurrency browser worker, истории screenshot, latency целевых страниц и bot challenges.

Какие данные собрать до запуска Change Detection

До подключения реальных пользователей подготовьте release worksheet для Change Detection. В нём должны быть указаны pinned image, порт 5000, canonical origin, persistent paths и владелец удалённого браузера, например Playwright, для страниц с большим количеством JavaScript. Приложите ожидаемый результат этой транзакции: отслеживать одну статическую страницу и одну страницу, отрисованную JavaScript, внести контролируемое изменение и получить diff-уведомление для каждой.

Используйте worksheet после обычной замены контейнера и после чистого восстановления. Восстановление считается успешным только в том случае, если watch definitions, история и targets уведомлений возвращаются, а контролируемое изменение снова обнаруживается. Также соберите короткий resource trace, охватывающий concurrency browser worker, историю screenshot, latency целевых страниц и bot challenges; храните его рядом с release, чтобы в будущем сравнивать изменения capacity на той же нагрузке.

Добавьте один контролируемый сбой: временно запретите test identity доступ к удалённому браузеру, например Playwright, для страниц с большим количеством JavaScript. Убедитесь, что Change Detection сообщает о проблеме на правильной границе, восстановите корректное состояние и повторно запустите транзакцию. Это проверяет не только успешный сценарий, но и видимость ошибок, не позволяя интерфейсу, который выглядит исправным, скрывать сломанный worker, callback или database connection.

Сделайте запуск Change Detection воспроизводимым

Минимальная команда полезна, если она показывает, чем впоследствии будет управлять платформа.

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 остаётся приватным на уровне host, а все необходимые paths заданы явно. Добавьте проверенные connection settings для удалённого браузера, например Playwright, предназначенного для страниц с большим количеством JavaScript; для приватных сервисов используйте private names. Проверьте запуск по logs и с помощью application-specific proof: отслеживать одну статическую страницу и одну страницу, отрисованную JavaScript, внести контролируемое изменение и получить diff-уведомление для каждой. После проверки зафиксируйте версию image, чтобы обычная замена контейнера незаметно не изменила поведение.

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

Считайте внешний URL Change Detection configuration, которая должна сохраняться при redeploy. Сначала задайте BASE_URL и любой browser endpoint так, чтобы контейнер мог до них добраться; затем направьте hostname на порт 5000, сохранив исходные host и scheme.

Checklist доступности deployment поможет доказать, что requests попадают в контейнер. После этого известную проблему — обычные HTTP-запросы сталкиваются с bot challenge или сервис браузера недоступен — следует искать в Change Detection, его state или workload, а не в автоматизации сертификатов.

Эксплуатируйте Change Detection с учётом реального bottleneck

Стройте dashboards вокруг concurrency browser worker, истории screenshot, latency целевых страниц и bot challenges. График CPU без контекста этой workload не объяснит, почему Change Detection работает медленно. Добавьте synthetic или scheduled check, который на безвредных тестовых данных пытается отслеживать одну статическую страницу и одну страницу, отрисованную JavaScript, вносит контролируемое изменение и получает diff-уведомление для каждой.

Перед обновлением учтите специфическую для этого приложения опасность: версии image Playwright, datastore migrations и integrations уведомлений должны обновляться вместе. Восстановите свежий backup в изолированном deployment, выполните там migrations и сравните поведение. Если обычные HTTP-запросы сталкиваются с bot challenge или сервис браузера недоступен, сначала проверьте соответствующую границу — public origin, storage или dependency, — и только потом изменяйте несвязанные настройки.

Что Dockup должен автоматизировать для Change Detection

Template Dockup должен описывать image, порт 5000, mounts, health timing, domain, TLS и доставку secrets. Dockup должен оставлять приватные части удалённого браузера, например Playwright для страниц с большим количеством JavaScript, во внутренней сети и не открывать дополнительные public ports. Одно и то же deployment может работать на серверах Dockup или на capacity, подключённой клиентом.

После того как route станет доступен, примените public setting и попробуйте отслеживать одну статическую страницу и одну страницу, отрисованную JavaScript, внести контролируемое изменение и получить diff-уведомление для каждой. Создавайте backup watch definitions, истории, snapshots и настроек уведомлений и включите проверку восстановления в operating plan; это зоны ответственности Change Detection, которые остаются актуальными после provisioning инфраструктуры.

Часто задаваемые вопросы

Что нужно Change Detection для deployment в production?

Направьте контейнер Change Detection через порт 5000 на один HTTPS origin. Сетевое требование для поддержки — удалённый браузер, например Playwright, для страниц с большим количеством JavaScript. Не объявляйте Change Detection готовым, пока не сможете отслеживать одну статическую страницу и одну страницу, отрисованную JavaScript, вносить контролируемое изменение и получать diff-уведомление для каждой.

Какие данные Change Detection нужно включать в backup?

Сохраняйте /datastore и включайте watch definitions, историю, snapshots и настройки уведомлений в один recovery manifest. Чистое восстановление Change Detection считается успешным только тогда, когда watch definitions, история и targets уведомлений возвращаются, а контролируемое изменение снова обнаруживается.

Требуется ли Change Detection HTTPS за reverse proxy?

Используйте HTTPS для public origin Change Detection, а порт 5000 оставьте во внутреннем route. Корректно примените setting Change Detection: задайте BASE_URL и любой browser endpoint так, чтобы контейнер мог до них добраться. Для Change Detection HTTPS защищает credentials и пользовательские данные при передаче и обеспечивает согласованное поведение клиентов, зависящее от origin.

Как тестировать upgrade Change Detection?

Восстановите текущее state Change Detection в изолированном deployment, примените candidate version и повторите acceptance transaction. Уделите этому особое внимание, поскольку версии image Playwright, datastore migrations и integrations уведомлений должны обновляться вместе. Сохраняйте предыдущую image Change Detection, пока не будут понятны границы миграции данных и rollback.