Vercel, Daemon'lara otomatik container yeniden başlatmalı HTTP liveness probe desteği ekledi

Vercel, Daemon'lara HTTP liveness check desteği ekledi; böylece platform, çökmeden bozulan uzun süreli süreçleri tespit edebiliyor. Vercel changelog'una göre, daemon'unuzun içinde bir health endpoint tanımlıyorsunuz ve Vercel bu endpoint'i periyodik olarak istek atıyor; endpoint başarısız olmaya başladığında Vercel daemon'un container'ını yeniden başlatıyor.

Yapılandırma nasıl çalışıyor

Daemon yapılandırması artık bir livenessProbe alanı kabul ediyor. Vercel'ın yayınladığı örnekte probe, daemon'un kendi servis ettiği bir port ve yola yapılan bir HTTP GET biçiminde — örnek yapılandırmada 1234 numaralı port ve /health yolu. Vercel, Daemon dokümantasyonunda probe için varsayılan değerlerin ve isteğe bağlı ayar alanlarının listelendiğini belirtiyor; ancak changelog kaydının kendisi bu varsayılanların ne olduğunu açıklamıyor.

Çevresindeki yapılandırma, Daemon'ların container tabanlı iş yükleri olduğunu doğruluyor: aynı örnek, probe'yu bir root dizini ve bir Dockerfile entrypoint ile birlikte gösteriyor.

İyi bir health endpoint yazmak

Vercel'ın önerisi, endpoint'in hızlı yanıt verebilmesi için minimal tutulması ve daemon işini yapamaz hale geldiğinde hata durumu döndürmesi. Changelog, minimal bir uygulama üzerinden örnek veriyor: bir worker dahili bir alive bayrağı takip ediyor, bağlantısı hata verdiğinde bu bayrağı false'a çeviriyor ve minik bir HTTP yanıtı sunuyor — bayrak set ediliyorken 200, temizlendikten sonra 500.

Asıl tasarım sorusu, belirli bir daemon için "sağlıklı" olmanın ne anlama geldiğidir. Yalnızca HTTP sunucusunun dinlediğini kanıtlayan bir endpoint çok az şey gösterir; daemon'un gerçek bağımlılıklarını — kuyruğunu, veritabanı bağlantısını veya upstream servislerini — yansıtan bir endpoint ise probe'yu gerçek bir güvenlik ağına dönüştürür.

Çalışıyor olmak, sağlıklı olmakla aynı şey değil

Burada ele alınan sorun, uzun süreli süreçleri işleten herkese tanıdık gelir. Bir worker kilitlenebilir, bağlantı havuzunu tükretebilir veya bir upstream hatasından sonra kalıcı olarak takılabilir — tüm bunlar olurken container çalışmaya ve kaynak tüketmeye devam eder. Çıkışta yeniden başlatma yapan denetim yalnızca fiilen sonlanmış bir süreci fark eder; takılmış bir süreç hakkında söyleyecek bir şeyi yoktur.

Uygulama düzeyindeki bir health endpoint bu sorunu, sürecin ilerleme kaydetmeyi bıraktığında bunu kendisinin bildirmesine izin vererek çözer. Bu, Kubernetes'in liveness probe'larıyla yaygınlaştığı fikirle aynı; dolayısıyla uzun süreli iş yüklerini Vercel'a taşıyan ekipler bu zihinsel modeli hemen tanıdık bulacaktır.

Neden önemli

Daemon'lar istek/yanıt döngüsünün dışında yer alır; yani gelen trafik, takılmış bir worker'ı doğal olarak ortaya çıkarmaz. Liveness check'ler "container var" ile "daemon faydalı bir iş yapıyor" arasındaki boşluğu kapatır — bu da üretimde arka plan veya stateful iş yükleri çalıştırmak için temel bir gerekliliktir.

Yeniden başlatma davranışından iki operasyonel sonuç doğar. Birincisi, yeniden başlatma devam eden işi yok eder; bu yüzden daemon'ların görev ortasında kesintiye uğramayı tolere etmesi gerekir — platform kendi inisiyatifiyle bir container'ı değiştirebildiğinde idempotent, devam ettirilebilir iş kalıpları daha da önemli hale gelir. İkincisi, health endpoint'in kendisi iki yönde de kritik hale gelir: aşırı katı bir kontrol geçici yük altında yeniden başlatma döngülerini tetikleyebilir, aşırı gevşek olanı ise özelliğin ortadan kaldırmayı amaçladığı kör noktayı yeniden yaratmaktan öteye gidemez.

Vercel için bu ekleme, platformun serverless modeline uymayan iş yüklerini çekmeye çalıştığının ve altyapı ekiplerinin zaten nasıl muhakeme edeceğini bildiği güvenilirlik ilkelerini ödünç aldığının bir işareti daha.