Як розгорнути Change Detection на власному сервері у 2026 році: отримання даних у браузері, сповіщення та збереження
Практичний посібник із self-hosting Change Detection: Docker, порти, збереження даних, TLS, безпека, резервні копії та проблеми, що перешкоджають використанню в production.
Контейнер Change Detection може працювати без помилок, хоча потрібне користувачам завдання не виконується. Для Change Detection прихована проблема зазвичай полягає в тому, що звичайні HTTP-запити стикаються з bot challenge або сервіс браузера недоступний. У цьому посібнику приймальним тестом вважається така операція: відстежити одну статичну сторінку й одну сторінку, що рендериться JavaScript, внести контрольовану зміну та отримати сповіщення про diff для кожної з них. Розгортання будується у зворотному напрямку — від цього результату.
Change Detection виконує в стеку конкретну роль: моніторинг змін сторінок без написання scraper. Тому production-запитання полягає не в тому, чи відповідає порт 5000 один раз, а в тому, чи продовжують стан, залежності та публічна адреса узгоджуватися після перезапуску, оновлення й відновлення.
Відокремте Change Detection від його залежностей
Найменша відповідальна топологія Change Detection містить один приватний listener на порту 5000, маршрут ingress і чітко визначену межу стану. Мережевий контракт Change Detection — це віддалений браузер, наприклад Playwright, для сторінок із великою кількістю JavaScript. Залишайте приватні endpoints у внутрішньому DNS, дозволяйте лише необхідні вихідні запити та надайте Change Detection service credential з обмеженими правами.
Перевірте топологію: за допомогою чистого клієнта відстежте одну статичну сторінку й одну сторінку, що рендериться JavaScript, внесіть контрольовану зміну та отримайте сповіщення про diff для кожної з них. Під час роботи відстежуйте concurrency browser worker-а, історію screenshot, latency цільових сторінок і bot challenge. Результат покаже, чи потрібне наступне покращення в memory, storage, networking або окремому worker, замість того щоб заохочувати довільне збільшення розміру контейнера.
Зробіть відновлення Change Detection вимірюваним
Визначте recovery point і recovery time для Change Detection у термінах watch definitions, history, snapshots і notification settings. Підключіть /datastore до bootstrap, запишіть нешкідливі тестові дані та замініть контейнер, щоб довести фактичну персистентність цього шляху. Named volume забезпечує збереження після redeploy, але не захищає від компрометації чи втрати сервера.
Створіть чисте середовище для restore, використайте ту саму зафіксовану версію застосунку та доведіть, що watch definitions, history і notification targets повернулися, а контрольовану зміну знову виявлено. Запишіть команди, виправлення ownership і витрачений час. Посібник із резервного копіювання задає корисний стандарт: backup вважається надійним після restoration, а не після upload.
Захистіть Change Detection після bootstrap
Не переносьте припущення щодо безпеки з локального tutorial. Специфічна проблема Change Detection — розкриття history спостережень і notification tokens без authentication. Тому в production потрібно захищати history спостережень, оскільки вона може містити приватні URL, cookies і notification credentials.
BASE_URL — це configuration, а не secret; залишайте його значення явним, захищаючи окремі credentials, які використовує Change Detection. Обмежте доступ до filesystem і network, захистіть setup endpoints та визначте upload, request або execution limits для concurrency browser worker-а, історії screenshot, latency цільових сторінок і bot challenge.
Які докази зібрати перед запуском Change Detection
До появи реальних користувачів створіть release worksheet для Change Detection. У ньому потрібно вказати pinned image, порт 5000, canonical origin, persistent paths і відповідального за віддалений браузер, наприклад Playwright, для сторінок із великою кількістю JavaScript. Додайте очікуваний результат цієї транзакції: відстежити одну статичну сторінку й одну сторінку, що рендериться JavaScript, внести контрольовану зміну та отримати сповіщення про diff для кожної з них.
Використайте worksheet після звичайної заміни та після чистого restore. Відновлення приймається лише тоді, коли watch definitions, history і notification targets повернулися, а контрольовану зміну знову виявлено. Також зберіть короткий resource trace, що охоплює concurrency browser worker-а, історію screenshot, latency цільових сторінок і bot challenge; зберігайте його разом із release, щоб майбутні зміни capacity можна було порівнювати на тому самому workload.
Додайте одну контрольовану відмову: тимчасово забороніть test identity доступ до віддаленого браузера, наприклад Playwright, для сторінок із великою кількістю JavaScript. Переконайтеся, що Change Detection повідомляє про проблему на правильній межі, відновіть коректну умову та повторіть транзакцію. Це перевіряє visibility помилок, а не лише успішне виконання, і не дозволяє інтерфейсу, що виглядає справним, приховати зламаний 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, а кожен необхідний path задано явно. Додайте перевірені connection settings для віддаленого браузера, наприклад Playwright, для сторінок із великою кількістю JavaScript; для приватних сервісів використовуйте приватні імена. Перевірте запуск за допомогою 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 допоможе довести, що запити потрапляють у контейнер. Після цього відому проблему — звичайні HTTP-запити стикаються з bot challenge або сервіс браузера недоступний — потрібно досліджувати в Change Detection, його state або workload, а не в certificate automation.
Експлуатуйте Change Detection з урахуванням реального bottleneck
Створюйте dashboards на основі concurrency browser worker-а, історії screenshot, latency цільових сторінок і bot challenge. Графік CPU без контексту цього workload не пояснить, чому Change Detection працює повільно. Додайте synthetic або scheduled check, який на нешкідливих тестових даних намагається відстежити одну статичну сторінку й одну сторінку, що рендериться JavaScript, внести контрольовану зміну та отримати сповіщення про diff для кожної з них.
Перед оновленням врахуйте специфічний для цього застосунку ризик: версії image Playwright, datastore migrations і notification integrations мають оновлюватися разом. Відновіть свіжу backup-копію в ізольованому deployment, виконайте migrations там і порівняйте поведінку. Якщо звичайні HTTP-запити стикаються з bot challenge або сервіс браузера недоступний, перевірте відповідну межу — public origin, storage або dependency — перш ніж змінювати сторонні налаштування.
Що Dockup має автоматизувати для Change Detection
Template Dockup має містити image, порт 5000, mounts, health timing, domain, TLS і secret delivery. Dockup має залишати приватні частини віддаленого браузера, наприклад Playwright для сторінок із великою кількістю JavaScript, у внутрішній network і не відкривати додатковий public port. Те саме deployment може бути спрямоване на сервери Dockup або capacity, підключену клієнтом.
Після того як route стане доступним, застосуйте public setting і спробуйте відстежити одну статичну сторінку й одну сторінку, що рендериться JavaScript, внести контрольовану зміну та отримати сповіщення про diff для кожної з них. Створюйте backup для watch definitions, history, snapshots і notification settings та включіть restore exercise в operating plan; це відповідальність Change Detection, яка залишається видимою після provisioning інфраструктури.
Поширені запитання
Що потрібно Change Detection для production deployment?
Спрямуйте контейнер Change Detection на порту 5000 через один HTTPS origin. Мережева вимога для залежності — віддалений браузер, наприклад Playwright, для сторінок із великою кількістю JavaScript. Не вважайте Change Detection готовим, доки не зможете відстежити одну статичну сторінку й одну сторінку, що рендериться JavaScript, внести контрольовану зміну та отримати сповіщення про diff для кожної з них.
Які дані Change Detection потрібно включати до backup?
Зберігайте /datastore і включайте watch definitions, history, snapshots і notification settings до одного recovery manifest. Чистий restore Change Detection вважається успішним лише тоді, коли watch definitions, history і notification targets повернулися, а контрольовану зміну знову виявлено.
Чи потрібен Change Detection HTTPS за reverse proxy?
Використовуйте HTTPS для public origin Change Detection і залишайте порт 5000 у внутрішньому route. Правильно застосуйте налаштування Change Detection: задайте BASE_URL і будь-який browser endpoint як адреси, доступні контейнеру. Для Change Detection HTTPS захищає credentials або user content під час передавання та забезпечує узгоджену поведінку клієнта, залежну від origin.
Як тестувати оновлення Change Detection?
Відновіть поточний state Change Detection в ізольованому deployment, застосуйте candidate version і повторіть acceptance transaction. Особливо зверніть увагу на те, що версії image Playwright, datastore migrations і notification integrations мають оновлюватися разом. Зберігайте попередній image Change Detection, доки не буде зрозумілою межа data migration і rollback.