2026'da Change Detection Nasıl Self-Host Edilir: Browser Fetching, Uyarılar ve Kalıcı Veri

Bir Change Detection container'ı yeşil durumda görünürken kullanıcıların önem verdiği iş bozulmuş olabilir. Change Detection'da bu gizli hata genellikle düz isteklerin bot challenge'larıyla karşılaşması veya browser servisinin erişilemez olmasıdır. Bu rehberde kabul testini “bir static sayfayı ve bir JavaScript ile render edilen sayfayı izlemek, kontrollü bir değişiklik oluşturmak ve her biri için bir diff bildirimi almak” olarak ele alıyor ve deployment'ı bu sonuca göre geriye dönük tasarlıyoruz.

Change Detection'ın stack içindeki rolü belirgindir: scraper yazmadan sayfa değişikliklerini izlemek. Bu nedenle production sorusu, port 5000'ın bir kez yanıt verip vermediği değil; state, bağımlılıklar ve public adresin restart, update ve restore sonrasında uyumlu kalıp kalmadığıdır.

Change Detection'ı bağımlılıklarından ayırın

Sorumlu bir Change Detection topology'sinin en küçük hali, 5000 üzerinde çalışan tek bir private listener, bir ingress route ve belgelenmiş bir state sınırı içerir. Change Detection için network contract, JavaScript ağırlıklı sayfalar adına Playwright gibi bir remote browser kullanılmasıdır. Private endpoint'leri internal DNS üzerinde tutun, yalnızca gerekli outbound çağrılara izin verin ve Change Detection'a kapsamı sınırlandırılmış bir service credential verin.

Topology'yi doğrulamak için temiz bir client'tan bir static sayfayı ve bir JavaScript ile render edilen sayfayı izlemesini, kontrollü bir değişiklik oluşturmasını ve her biri için bir diff bildirimi almasını isteyin. Çalışma sırasında browser-worker concurrency, screenshot history, target latency ve anti-bot challenge'larını izleyin. Sonuç, bir sonraki iyileştirmenin rastgele container boyutlandırmak yerine memory, storage, networking veya ayrı bir worker tarafında yapılması gerektiğini gösterir.

Change Detection recovery sürecini ölçülebilir hâle getirin

Change Detection için recovery point ve recovery time değerlerini watch definition'ları, history, snapshot'lar ve notification setting'leri üzerinden tanımlayın. Bootstrap işleminden önce /datastore'u mount edin, zararsız örnek veriler yazın ve bu path'in gerçekten kalıcı olduğunu kanıtlamak için container'ı değiştirin. Named volume redeploy sonrasında kalıcılığı çözer; güvenlik ihlalini veya server kaybını çözmez.

Temiz bir restore ortamı oluşturun, aynı pinned application version'ı kullanın ve watch definition'larının, history'nin ve notification target'larının geri geldiğini, ardından kontrollü değişikliğin yeniden algılandığını kanıtlayın. Komutları, ownership düzeltmelerini ve geçen süreyi kaydedin. Yedekleme rehberi yararlı bir standarttır: bir backup, upload edildikten sonra değil restore edildikten sonra güvenilir kabul edilir.

Bootstrap sonrasında Change Detection'ı güvenli hâle getirin

Güvenlik varsayımlarını local bir tutorial'dan devralmayın. Change Detection'a özgü temel endişe, watch history ve notification token'larının authentication olmadan açığa çıkmasıdır. Bu nedenle production ortamında watch history korunmalıdır; çünkü private URL'ler, cookie'ler ve notification credential'ları içerebilir.

BASE_URL bir secret değil, configuration'dır; değerini açıkça tanımlarken Change Detection tarafından kullanılan ayrı credential'ları koruyun. Filesystem ve network erişimini kapsamla sınırlandırın, setup endpoint'lerini koruyun ve browser-worker concurrency, screenshot history, target latency ve anti-bot challenge'ları etrafında upload, request veya execution limit'leri tanımlayın.

Change Detection production'a çıkmadan önce toplanacak kanıtlar

Gerçek kullanıcılar gelmeden önce Change Detection için bir release worksheet hazırlayın. Bu belgede pinned image, port 5000, canonical origin, persistent path'ler ve JavaScript ağırlıklı sayfalar için Playwright gibi bir remote browser'ın sahibi belirtilmelidir. Şu transaction'ın beklenen sonucunu ekleyin: bir static sayfayı ve bir JavaScript ile render edilen sayfayı izlemek, kontrollü bir değişiklik oluşturmak ve her biri için bir diff bildirimi almak.

Worksheet'i normal bir replacement sonrasında ve temiz bir restore sonrasında kullanın. Recovery yalnızca watch definition'ları, history ve notification target'ları geri geldiğinde ve kontrollü değişiklik yeniden algılandığında kabul edilir. Ayrıca browser-worker concurrency, screenshot history, target latency ve anti-bot challenge'larını kapsayan kısa bir resource trace toplayın; gelecekteki capacity değişikliklerini aynı workload ile karşılaştırabilmek için bunu release'in yanında saklayın.

Kontrollü bir failure da ekleyin: test identity'sinin JavaScript ağırlıklı sayfalar için kullanılan Playwright gibi bir remote browser'a erişimini geçici olarak engelleyin. Change Detection'ın sorunu doğru boundary'de raporladığını doğrulayın, geçerli koşulu geri yükleyin ve transaction'ı yeniden çalıştırın. Bu işlem yalnızca başarıyı değil, hata görünürlüğünü de test eder ve sağlıklı görünen bir arayüzün bozuk bir worker'ı, callback'i veya database connection'ını gizlemesini önler.

Change Detection startup sürecini tekrarlanabilir hâle getirin

Platformun ileride neyi yöneteceğini açıkça gösteren minimal bir komut faydalıdır.

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

Burada port 5000 host üzerinde private kalır ve gerekli tüm path'ler açıkça tanımlanır. JavaScript ağırlıklı sayfalar için Playwright gibi bir remote browser'a ait gözden geçirilmiş connection setting'lerini ekleyin; private servisler için private name'ler kullanın. Startup'ı hem log'larla hem de application'a özgü kanıtla doğrulayın: bir static sayfayı ve bir JavaScript ile render edilen sayfayı izleyin, kontrollü bir değişiklik oluşturun ve her biri için bir diff bildirimi alın. Doğrulama tamamlandıktan sonra image version'ını sabitleyin; böylece rutin bir replacement davranışı sessizce değiştirmez.

Domain'ler, proxy header'ları ve port 5000

Harici Change Detection URL'sini redeploy'lar arasında korunan bir configuration olarak ele alın. Önce BASE_URL'yi ve tüm browser endpoint'lerini container'ın erişebileceği adreslere ayarlayın; ardından hostname'i original host ve scheme bilgilerini koruyarak port 5000'a yönlendirin.

Deployment reachability checklist, request'lerin container'a girdiğini kanıtlayabilir. Bundan sonra bilinen hata — düz isteklerin bot challenge'larıyla karşılaşması veya browser servisinin erişilemez olması — certificate automation'da değil, Change Detection'ın kendisinde, state'inde veya workload'unda araştırılmalıdır.

Change Detection'ı gerçek darboğazı etrafında çalıştırın

Dashboard'ları browser-worker concurrency, screenshot history, target latency ve anti-bot challenge'ları etrafında oluşturun. Bu workload bağlamı olmadan yalnızca CPU grafiği, Change Detection'ın neden yavaş olduğunu açıklayamaz. Zararsız test verileri kullanarak bir static sayfayı ve bir JavaScript ile render edilen sayfayı izleyen, kontrollü bir değişiklik oluşturan ve her biri için bir diff bildirimi alan synthetic veya scheduled bir check ekleyin.

Upgrade öncesinde uygulamaya özgü şu riski hesaba katın: Playwright image version'ları, datastore migration'ları ve notification integration'ları birlikte ilerlemelidir. Güncel bir backup'ı isolated bir deployment'a restore edin, migration'ları orada çalıştırın ve davranışı karşılaştırın. Düz istekler bot challenge'larıyla karşılaşıyor veya browser servisi erişilemez durumdaysa, ilgisiz ayarlara dokunmadan önce ilgili boundary'yi — public origin, storage veya dependency — inceleyin.

Dockup'un Change Detection için otomatikleştirmesi gerekenler

Bir Dockup template'i image, port 5000, mount'lar, health timing, domain, TLS ve secret delivery ayarlarını içermelidir. Dockup, Playwright gibi bir remote browser'ın private bölümlerini internal networking üzerinde tutmalı ve ekstra bir public port açmamalıdır. Aynı deployment, Dockup server'larını veya müşterinin bağladığı capacity'yi hedefleyebilir.

Route kullanıma açıldıktan sonra public setting'i uygulayın ve bir static sayfayı ve bir JavaScript ile render edilen sayfayı izlemeyi, kontrollü bir değişiklik oluşturmayı ve her biri için bir diff bildirimi almayı deneyin. Watch definition'larını, history'yi, snapshot'ları ve notification setting'lerini yedekleyin; restore çalışmasını operating plan'a dahil edin. Bunlar, infrastructure provisioning sonrasında da görünür kalması gereken Change Detection sorumluluklarıdır.

Sık sorulan sorular

Production deployment için Change Detection'ın neye ihtiyacı vardır?

Change Detection container'ını port 5000 üzerinden tek bir HTTPS origin'e yönlendirin. Destekleyici network gereksinimi, JavaScript ağırlıklı sayfalar için Playwright gibi bir remote browser'dır. Bir static sayfayı ve bir JavaScript ile render edilen sayfayı izleyemediğiniz, kontrollü bir değişiklik oluşturamadığınız ve her biri için bir diff bildirimi alamadığınız sürece Change Detection'ı hazır kabul etmeyin.

Hangi Change Detection verileri backup'a dahil edilmelidir?

/datastore'u kalıcı hâle getirin ve watch definition'larını, history'yi, snapshot'ları ve notification setting'lerini aynı recovery manifest'ine dahil edin. Temiz bir Change Detection restore işlemi yalnızca watch definition'ları, history ve notification target'ları geri geldiğinde ve kontrollü değişiklik yeniden algılandığında başarılıdır.

Reverse proxy arkasında Change Detection için HTTPS gerekir mi?

Public Change Detection origin'i için HTTPS kullanın ve port 5000'ı internal route üzerinde tutun. Change Detection ayarını doğru uygulayın: BASE_URL'yi ve tüm browser endpoint'lerini container'ın erişebileceği adreslere ayarlayın. Change Detection için HTTPS, credential'ları veya kullanıcı içeriğini aktarım sırasında korur ve origin'e duyarlı client davranışının tutarlı kalmasını sağlar.

Change Detection upgrade'i nasıl test edilmelidir?

Mevcut Change Detection state'ini isolated bir deployment'a restore edin, candidate version'ı uygulayın ve kabul transaction'ını tekrarlayın. Playwright image version'larının, datastore migration'larının ve notification integration'larının birlikte ilerlemesi gerektiğinden bu noktaya özellikle dikkat edin. Data migration ve rollback boundary'leri anlaşılana kadar önceki Change Detection image'ını saklayın.