- Konu sahibi
- #1
Container healthcheck, bir container içindeki uygulamanın yalnızca çalışıyor olup olmadığını değil, tanımladığınız sağlık komutunun başarılı olup olmadığını denetler. Bu komut, istek kabul etme veya bağımlılık sağlığı gibi anlamlı bir koşulu sınayabilir. Örneğin işlemci süreci ayakta kaldığı hâlde web uygulaması veritabanına bağlanamıyorsa container
Docker belirlenen komutu container içinde aralıklarla çalıştırır. Komut başarılı olursa uygulama sağlıklı kabul edilir; başarısız olursa Docker tanımlı deneme sayısına göre durumu
Kontrol komutu uygulamanın gerçek çalışma koşulunu ölçmelidir. Bir HTTP servisi için
Aşağıdaki dosya, Nginx container'ının yerel HTTP yanıtını denetler:
Bu içeriği
Beklenen çıktıda
Değerleri uygulamanın başlama süresine ve beklenen yanıt süresine göre belirleyin. Uygulama açılır açılmaz kontrol edilemiyorsa
Karar verirken şu ayrımı kullanın:
Healthcheck'i gereğinden ağır bir işlem hâline getirmeyin. Her kontrolde büyük sorgular çalıştırmak, dış sistemlere yazmak veya pahalı hesap yapmak uygulamaya ek yük getirir. Sağlık uç noktası mümkünse hızlı, tekrarlanabilir ve yan etkisiz olmalıdır.
En yaygın hata, yalnızca süreç listesini kontrol ederek uygulamanın sağlıklı olduğunu varsaymaktır. Süreç çalışırken uygulama kilitlenebilir veya bağlantı havuzu tükenebilir. İkinci hata, container içindeki
Healthcheck durumu
running görünebilir; healthcheck ise bu durumu unhealthy olarak işaretleyebilir. Bu bilgi orkestrasyon, izleme ve arıza teşhisi için kullanılır; tek başına container'ı yeniden başlatmaz.Nasıl çalışır?
Docker belirlenen komutu container içinde aralıklarla çalıştırır. Komut başarılı olursa uygulama sağlıklı kabul edilir; başarısız olursa Docker tanımlı deneme sayısına göre durumu
unhealthy yapar. İlk kontrolün ne zaman başlayacağı, kontroller arasındaki süre, zaman aşımı ve arka arkaya kaç başarısız denemeden sonra başarısız sayılacağı ayrıca belirlenebilir.Kontrol komutu uygulamanın gerçek çalışma koşulunu ölçmelidir. Bir HTTP servisi için
curl ile yerel sağlık uç noktasına istek göndermek, yalnızca ana sürecin varlığını kontrol etmekten daha anlamlıdır. Sağlık uç noktası da veritabanı veya zorunlu bir bağımlılık kullanıyorsa, kontrolün kapsamı uygulamanın “trafik almaya hazır” tanımına uygun seçilmelidir.Çalıştırılabilir en küçük örnek
Aşağıdaki dosya, Nginx container'ının yerel HTTP yanıtını denetler:
Kod:
services:
web:
image: nginx:alpine
healthcheck:
test: ["CMD-SHELL", "wget -q -T 2 -O /dev/null http://127.0.0.1/ || exit 1"]
interval: 10s
timeout: 3s
retries: 3
start_period: 5s
Bu içeriği
compose.yaml olarak kaydedip size ait ayrı deneme dizininde docker compose up -d ile başlattığınızda, healthcheck komutu container içinden ana sayfaya erişmeye çalışır. Başarılı sonuçta durum healthy olur. Durumu görmek için POSIX kabukta aşağıdaki komutları kullanabilirsiniz; ikinci komut Compose servis kimliğini alır. Bu örnek host portu yayımlamaz:
Kod:
docker compose ps
docker inspect --format='{{json .State.Health}}' $(docker compose ps -q web)
Beklenen çıktıda
Status alanı healthy olur. unhealthy görülürse önce son kontrol kayıtlarındaki çıkış koduna ve hata metnine bakın; ardından URL'nin, portun ve kontrol aracının container içinde gerçekten bulunup bulunmadığını doğrulayın. Bu örnekte wget imajda yoksa kontrol uygulamadan bağımsız olarak başarısız olur. Böyle bir durumda imaja uygun bir araç kullanın veya sağlık kontrolü için gereken aracı imaja bilinçli olarak ekleyin.Ayarları nasıl seçmeli?
Değerleri uygulamanın başlama süresine ve beklenen yanıt süresine göre belirleyin. Uygulama açılır açılmaz kontrol edilemiyorsa
start_period ile başlangıç süresince oluşan başarısızlıkların dikkate alınmasını geciktirin. timeout değerini normal yanıt süresinden uzun, ancak kilitlenmeyi fark etmeyi geciktirmeyecek kadar kısa tutun. retries geçici ağ veya başlatma sorunlarının hemen arıza sayılmasını önler; çok yüksek değerler ise gerçek arızayı gizleyebilir.Karar verirken şu ayrımı kullanın:
| Kontrol türü | Ne anlatır? | Ne zaman kullanılır? |
|---|---|---|
| Süreç kontrolü | Ana işlem çalışıyor mu? | Basit servislerde temel canlılık için |
| HTTP yanıtı | Servis istek kabul ediyor mu? | Web API ve arayüzlerde |
| Bağımlılık kontrolü | Gerekli servislerle çalışabiliyor mu? | Hazır olma kararında |
Healthcheck'i gereğinden ağır bir işlem hâline getirmeyin. Her kontrolde büyük sorgular çalıştırmak, dış sistemlere yazmak veya pahalı hesap yapmak uygulamaya ek yük getirir. Sağlık uç noktası mümkünse hızlı, tekrarlanabilir ve yan etkisiz olmalıdır.
Sık yapılan hatalar ve sonraki adım
En yaygın hata, yalnızca süreç listesini kontrol ederek uygulamanın sağlıklı olduğunu varsaymaktır. Süreç çalışırken uygulama kilitlenebilir veya bağlantı havuzu tükenebilir. İkinci hata, container içindeki
localhost adresinin başka bir container'ı değil, kontrolün çalıştığı aynı container'ı ifade ettiğini unutmaktır. Başka bir servisi denetlemek gerekiyorsa servis adı ve ağ yapılandırması doğru kullanılmalıdır.Healthcheck durumu
unhealthy olduğunda önce kontrol komutunu container içinde elle çalıştırın. Sonra uygulama loglarını, sağlık uç noktasının yanıtını ve bağımlılık bağlantılarını inceleyin. Yeniden başlatma isteniyorsa bunu healthcheck'in otomatik yaptığı varsayılmamalı; ortamın gerçek davranışı ayrıca incelenmelidir. Docker Compose restart politikası sırf unhealthy durumu için tetiklenmez; süreç çıkışı farklıdır. Kubernetes ise Dockerfile HEALTHCHECK’i otomatik kullanmak yerine kendi probe tanımlarını kullanır.