Docker Container Sürekli Restart Oluyorsa Neler Kontrol Edilmeli?

Restart loop ne anlama gelir?

Bir container’ın sürekli Restarting durumuna dönmesi, container içindeki ana process’in sonlandığını ve Docker restart policy nedeniyle yeniden başlatıldığını gösterir.

Restart policy bir iyileştirme mekanizması değil, servis sürekliliği davranışıdır. Process’in neden kapandığını çözmez; yalnızca yeniden çalıştırmayı dener.

Container başlar → Ana process sonlanır → Restart policy devreye girer → Container yeniden başlar

İlk olarak exit code incelenmeli

Exit code, process’in nasıl sonlandığına ilişkin ilk kanıttır. Ancak tek başına kök neden değildir ve uygulama loglarıyla aynı zaman aralığında değerlendirilmelidir.

• Exit code 0: Process hata vermeden tamamlanmış olabilir
• Exit code 1: Genel uygulama veya başlatma hatası
• Exit code 126/127: Yetki, komut veya dosya yolu problemi
• Exit code 137: SIGKILL veya bellek baskısı ihtimali
• Exit code 143: SIGTERM ile kontrollü sonlandırma ihtimali

Uygulama başlangıç logları

Container logu, image içindeki ana process’in stdout ve stderr çıktısını gösterir. Yanlış environment değişkenleri, migration hataları, dosya izinleri ve bağlantı problemleri genellikle ilk saniyelerde görünür.

Logların her restart sırasında üzerine yazılmadığı ve doğru container örneğinin incelendiği doğrulanmalıdır.

• Eksik veya hatalı environment değişkeni
• Geçersiz konfigürasyon dosyası
• Ulaşılamayan veritabanı
• Dosya ve dizin izinleri
• Başarısız schema migration
• Uygulamanın dinleme portunu açamaması

Bellek yetersizliği ve OOMKilled

Container bellek limitini aşarsa veya host ciddi bellek baskısı yaşarsa Linux kernel process’i sonlandırabilir. Container daha sonra restart policy nedeniyle tekrar başlar ve aynı yük altında yeniden kapanabilir.

Yalnızca bellek limitini artırmak, memory leak veya yanlış kapasite planlamasını gizleyebilir. Host ve container tüketimi birlikte değerlendirilmelidir.

Yanlış command veya entrypoint

Image çalışsa bile Compose dosyasındaki command veya entrypoint değişikliği ana process’in hemen tamamlanmasına neden olabilir.

Arka plana geçen bir servis, hatalı shell ifadesi veya image içinde bulunmayan executable container’ın beklenmedik şekilde kapanmasına yol açabilir.

Bağımlılıkların hazır olmaması

Uygulama veritabanı, cache, message broker veya başka bir API hazır olmadan başlatılırsa bağlantı hatasıyla kapanabilir.

Sadece başlatma sırası yeterli olmayabilir; bağımlılığın gerçekten trafik kabul etmeye hazır olduğu bir readiness yaklaşımı gerekir.

• DNS veya servis adı çözümlenemiyor
• Veritabanı henüz bağlantı kabul etmiyor
• Credential veya secret yanlış
• TLS sertifika doğrulaması başarısız
• Ağ politikası veya firewall bağlantıyı engelliyor

Healthcheck ile restart policy aynı şey değildir

Healthcheck container içindeki uygulamanın sağlık durumunu healthy veya unhealthy olarak raporlar. Docker Engine’de bir container’ın unhealthy olması tek başına container’ı yeniden başlatmaz.

Orkestratör, harici watchdog veya özel otomasyon unhealthy durumunu restart aksiyonuna dönüştürüyorsa olay zinciri ayrıca incelenmelidir.

Restart policy davranışı

always ve unless-stopped gibi politikalar process sonlandığında container’ı yeniden çalıştırabilir. on-failure ise hata koduyla sonlanmalarda devreye girer.

Restart sayısını sıfırlamak veya policy’yi geçici olarak kapatmak kök nedeni çözmez; teşhis sırasında log kaybını ve kontrolsüz döngüyü önlemek için planlı biçimde değerlendirilebilir.

Güvenli teşhis sırası

Production ortamında container’ı silmeden önce state, exit code, restart count, OOM durumu, health bilgisi ve son loglar korunmalıdır.

• Etkilenen servis ve kullanıcı kapsamını belirleyin
• Container state ve exit code bilgisini kaydedin
• Aynı zaman aralığındaki uygulama ve Docker event loglarını inceleyin
• Host CPU, bellek, disk ve inode durumunu kontrol edin
• Environment ve secret değişikliklerini karşılaştırın
• Bağımlılıkların erişilebilirliğini doğrulayın
• Son deployment ile hata başlangıcını eşleştirin

Kaçınılması gereken müdahaleler

Kanıt toplamadan container’ı silmek, volume’leri temizlemek veya image’ı körlemesine değiştirmek geri dönüşü zor veri kayıplarına yol açabilir.

• Container ve volume’leri birlikte silmek
• Restart komutunu sürekli tekrarlamak
• OOM korumalarını kontrolsüz kapatmak
• Environment dosyasını eski bir kopyayla ezmek
• Latest etiketiyle doğrulanmamış image çekmek
• Logları almadan sistemi yeniden oluşturmak

Ne zaman uzman desteği alınmalı?

Restart loop kritik bir servisi etkiliyorsa, veri tutarlılığı riski varsa veya aynı problem deployment sonrasında tekrarlıyorsa container tek başına değerlendirilmemelidir.

Image, Compose tanımı, uygulama başlangıç akışı, bağımlılıklar, host kaynakları ve geri dönüş planı birlikte incelenmelidir.