Docker Kapsayıcılarımın Kararlılığını Nasıl Artırırım
26 Nisan 2026 tarihinde yayınlandı
İki gün boyunca sorunsuz çalışan ve sonra sabaha karşı 3:12'de kapanan bir Docker kapsayıcısı. bir kapsayıcı sorunu değildir. Genellikle Docker etiketi taşıyan bir operasyon sorunudur. Eğer "Docker kapsayıcılarımın kararlılığını nasıl artırırım?" diye soruyorsanız, cevap nadiren tek bir sihirli bayraktır. Kararlılık, tahmin edilebilir kapsayımlar, mantıklı kaynak limitleri, sağlık kontrolleri, temiz depolama ve kullanıcılarınızdan önce sorunu yakalayan izleme sayesinde gelir.
Çoğu ekip için kapsayıcı kararsızlığı bilindik şekillerde ortaya çıkar. Bir hizmet uyarı vermeden yeniden başlar. Bellek, çekirdeğin işlemi sonlandırmasına kadar yükselir. Bir dağıtım bir sunucuda çalışır ancak diğerinde çalışmaz. En çok ihtiyaç duyduğunuzda günlükler kaybolur. İyi haber şu ki bu hatalar genellikle birkaç disiplinli değişiklikle önlenebilir.
Docker kapsayıcılarının kararlılığını pratikte nasıl artırılır
Önce uygulama hatalarını kapsayıcı çalışma zamanı sorunlarından ayırarak başlayın. Docker, kötü işlem yönetimi, zayıf bağımlılık kontrolü veya ana bilgisayar düzeyinde kaynak tükenmesinden kaynaklanan hatalar için sıklıkla suçlanır. Kararlı bir kapsayıcı kurulumu, temiz başlayan, günlükleri düzgün yazan, sinyalleri işleyen ve anlamlı çıkış kodlarıyla sonlanan kararlı bir uygulama işlemiyle başlar.
Kapsayıcınız bir web uygulaması, API, kuyruk işleyicisi veya zamanlanmış görev çalıştırıyorsa, içindeki ana işlem gerçek hizmet işlemi olmalı, sinyalleri yutan bir kabuk sarmalayıcısı değil. Docker, yeniden başlatma veya dağıtım sırasında SIGTERM gönderdiğinde, uygulamanızın temiz bir şekilde kapanması gerekir. Eğer kapanmazsa, takılı kalan yeniden başlatmalar, bozuk geçici durumlar veya eksik işler görebilirsiniz.
Başka yaygın bir sorun da kapsayıcıları minik sanal makineler gibi görmektir. Kapsayıcılar elden çıkarılabilir olmalıdır. Onların içinde ne kadar çok gizli durum tutarsanız, zamanla o kadar kararsız hale gelirler. Eğer bir yeniden başlatma dosyalar kaybolduğu, izinler değiştiği veya çalışan kapsayıcının içinde manuel bir düzeltme yapıldığı için hizmeti bozarsa, kurulum tasarımsal olarak kırılgandır.
Tahmin edilebilir, küçük ve sabitlenmiş kapsayımlar kullanın
Şaşırtıcı sayıda kararlılık sorunu, derleme aşamasında başlar. Eğer "latest" gibi yüzen etiketler kullanıyorsanız, kapsayım yeniden derlendiğinde veya çekildiğinde her seferinde sessiz değişikliği kabul ediyorsunuz demektir. Bu, uyarı vermeden yeni kütüphaneler, paket sürümleri veya çalışma zamanı davranışları getirebilir.
Temel kapsayım sürümlerinizi sabitleyin. Uygulama bağımlılıklarınızı da sabitleyin. Bu, yeniden derlemeleri tekrarlanabilir hale getirir ve bir şey bozulursa net bir geri alma yolu sunar. Küçük kapsayımlar ayrıca saldırı yüzeyini azalttığı, başlatma süresini kısalttığı ve uygulamanızla çakışabilecek gereksiz paketleri kaldırdığı için yardımcı olur.
Burada çok aşamalı derlemeler kullanmaya değer. Bunlar, bir aşamada artefaktları derlemenize veya hazırlamanıza ve yalnızca son kapsayımdaki çalışma zamanı parçalarını göndermenize olanak tanır. Bu daha temiz, yamalanması daha kolay ve genellikle yük altında daha kararlıdır.
Daha da önemlisi, kapsayımları aylarca yaşlandırmak yerine zamanlanmış olarak yeniden derleyin. Kararlılık durgunluk ile aynı şey değildir. Eski kapsayımlar genellikle eski paketler, süresi dolmuş sertifikalar veya çevredeki hizmetler değiştiğinde ortaya çıkan uyumsuzluklar içerir.
Ana bilgisayar sizin adınıza belirlemeden önce kaynak limitlerini ayarlayın
Kararsız bir kapsayıcı, düğümdeki diğer her şeye zarar verebilir. Eğer belleği sınırsızsa, Linux OOM killer sonunda sizin için bir karar verecektir ve beklediğiniz işlemi seçmeyebilir.
Bellek ve CPU limitlerini bilinçli olarak ayarlayın. Bellek limitleri, bir kapsayıcının ana bilgisayarı tüketmesini engeller. CPU limitleri, gürültülü komşuların diğer hizmetleri aç bırakmasını önler. Desteklenen yerlerde, özellikle birden fazla kritik iş yükü aynı sunucuyu paylaşıyorsa, rezervasyonlar da yardımcı olabilir.
Bu kısımda bir ödünleşim vardır. Eğer limitler çok sıkıysa, ana bilgisayarda yer olsa bile uygulamanız başarısız olabilir. Eğer limitler çok gevşekse, ana bilgisayar savunmasız hale gelir. Doğru ayarlar, tahmin etmek yerine gerçek kullanımı gözlemlemekten gelir. Temel tüketimi, başlangıç ani yükselişlerini, trafik patlamalarını ve yedekleme pencerelerini değerleri kilitlemeden önce izleyin.
Eğer hizmetiniz Java, Node.js, Python veya PHP-FPM kullanıyorsa, bellek davranışını dikkatlice test edin. Bazı çalışma zamanları, kapsayıcı belleği varsayılan varsayımlardan düşük olduğunda kötü tepki verir. Uygulama çalışma zamanı, kapsayıcı limiti göz önünde bulundurularak ayarlandığında kararlılık iyileşir.
Sağlık kontrolleri ekleyin, ancak anlamlı hale getirin
Bir kapsayıcının "çalışıyor" olması, hizmetin sağlıklı olduğu anlamına gelmez. İşlem, veritabanı bağlantıları öldüğü, disk dolduğu veya uygulama iş parçacığı havuzunun donduğu sırada hala çalışıyor olabilir.
Docker sağlık kontrolleri yardımcı olur, ancak yalnızca gerçek bir şeyi test ederlerse. İyi bir sağlık kontrolü, yalnızca bir bağlantı noktasının açık olduğunu değil, hizmetin trafiğe hizmet etmeye hazır olduğunu doğrular. Bir web uygulaması için, işlem varlığını kontrol etmekten daha iyi, hafif bir iç uç noktasına vurmaktır. İşleyiciler için, kuyruk bağlantısını veya uygulamanın kendisi tarafından güncellenen bir heartbeat dosyasını doğrulamak daha iyi olabilir.
Sağlık kontrollerini çok agresif yapmaktan kaçının. Eğer birkaç saniyede bir çalışırlarsa ve yavaş bir aşağı akış hizmetine bağımlıysalarsa, yanlış hatalar ve yeniden başlatma döngüleri oluşturabilirsiniz. Sağlık kontrolü ucuz, mümkünse yerel olmalı ve gerçek hazır olma durumuna bağlı olmalıdır.
Yeniden başlatma davranışını kazara değil, bilinçli yapın
Yeniden başlatma politikaları dayanıklılığı artırır, ancak temel nedenleri düzeltmez. Bunlar yalnızca hatadan sonra ne olacağını değiştirir.
İş yüküne uygun bir yeniden başlatma politikası kullanın. Her zaman kullanılabilir olması gereken hizmetler genellikle otomatik olarak yeniden başlatılmalıdır. Tek seferlik işler ve geçiş kapsayıcıları, mantıksal bir hata sonrası sonsuza dek yeniden başlatılmamalıdır. Eğer bir kapsayıcı kötü bir yapılandırma nedeniyle her 10 saniyede bir çöküyorsa, otomatik yeniden başlatma günlükler silinene ve ekip müşteri şikayetlerini fark edene kadar sorunu gizleyebilir.
Bu yüzden günlük kaydı ve uyarı mekanizmaları yeniden başlatma politikalarının yanında yer almalıdır. Yeniden başlatma faydalıdır. Sessizce yeniden başlatmak tehlikelidir.
Kalıcı verileri dikkatli kullanın
Durum bilgisi olan kapsayıcılar, durum bilgisi olmayanlara göre daha ilginç şekillerde arızalanır. Veritabanları, dosya işleme uygulamaları ve diske önbellek yapan sistemler tutarlı depolama davranışı gerektirir. Eğer önemli verileri kapsayıcı dosya sistemine yazarsanız, geçici olması tasarlanmış bir şeye bağımlı olursunuz.
Kalıcılık önemlidir yerlerde birim veya harici depolama kullanın. İzinleri açıkça kontrol edin. Hem ana bilgisayarda hem de bağlanan depolamada boş disk alanını izleyin. Birçok "rastgele" çökme aslında yazma hataları, inode tükenmesi veya yavaş depolama nedeniyle uygulama zaman aşımlarına neden olur.
Yedeklemeler burada da önemlidir. Kararlılık sadece ayakta kalmakla ilgili değildir. Aynı zamanda temiz bir şekilde kurtarmakla da ilgilidir. Bozulma sonrası hızlı bir şekilde kurtarılamayan bir hizmet, iş açısından kararlı değildir.
Günlük kaydı olayı atlatmalı
Bir kapsayıcı çöktüğünde, ilk soru basittir: çökmeden hemen önce ne oldu? Eğer cevabınız "emin değiliz" ise, ortamınız henüz yeterince kararlı değil demektir.
Mümkün olduğunca uygulama günlüklerini stdout ve stderr'e gönderin ve Docker günlük sürücünüzün ana bilgisayar için uygun olduğundan emin olun. Eğer günlükler yalnızca kapsayıcının içinde kalırsa, onunla birlikte kaybolurlar. Eğer günlükler çok gürültülü ve yönetilmemişse, diskleri doldururlar ve farklı bir kesintiye neden olurlar.
Yapılandırılmış günlükler, ekiplerin beklediğinden daha fazla yardımcı olur. Zaman damgaları, önem derecesi, istek kimlikleri ve hata kodları tutarlı olduğunda, sorun giderme daha hızlı ve daha az stresli hale gelir. Müşteri odaklı iş yükleri için, yanıt süresindeki bu azalma kararlılığın bir parçasıdır.
Sadece kapsayıcıyı değil, ana bilgisayarı da izleyin
Kapsayıcılar ana bilgisayar çekirdeğine, depolamasına, ağına, DNS'sine ve zaman senkronizasyonuna bağlıdır. Eğer ana bilgisayar sağlıksızsa, kapsayıcılarınız sorunu miras alır.
Düğümün kendisinde CPU çalma, bellek baskısı, disk gecikmesi, dosya sistemi kullanımı, ağ paketi kaybı ve yeniden başlatma geçmişini izleyin. Kapsayıcı metrikleri faydalıdır, ancak resmin sadece yarısıdır. Birçok ekip kapsayıcı başına grafiklere odaklanır ve gerçek sorunun gürültülü bir depolama katmanı veya takas baskısı altındaki bir ana bilgisayar olduğunu gözden kaçırır.
İşte burada aktif izleme sonucu değiştirir. İyi izleme sadece bir kapsayıcının öldüğünü söylemez. 40 dakika boyunca bellek baskısının yükseldiğini, disk kuyruk uzunluğunun arttığını ve bundan sonra sağlık kontrollerinin başarısız olmaya başladığını gösterir. Bu zaman çizelgesi, tekrarlanan olayları düzeltilebilir bir modele dönüştüren şeydir.
Dağıtım riskini azaltın
Birçok "kararlılık sorunu" dağıtım sırasında başlar. Yeni kapsayım iyi olabilir, ancak dağıtım yöntemi kesinti süresine, yarış koşullarına veya yapılandırma eşleşmemesine neden olur.
Değişmez kapsayımlar ve ortama dayalı yapılandırma kullanın. Dağıtımdan önce yapılandırmaları doğrulayın. Yapabiliyorsanız, kapsayıcıları bir kerede topluca değiştirmek yerine aşamalı dağıtımlar kullanın veya kapsayıcıları aşamalı olarak değiştirin. Müşteri odaklı hizmetler için, 30 saniyelik kötü bir dağıtım bile kararsızlık gibi hissedilebilir.
Başlangıcı da öngörülebilir tutun. Eğer bir kapsayıcı bir veritabanına, önbelleğe veya sır yöneticisine bağlıysa, bu bağımlılıkları zarifçe ele alın. Her şeyin anında kullanılabilir olduğunu varsayan başlangıç betikleri, gerçek üretim koşullarında başarısız olma eğilimindedir.
En basit kararlılık kontrol listesi işe yarayan
Daha iyi çalışma süresi için en kısa yolu istiyorsanız, öncelikle bunlara odaklanın: kapsayım sürümlerini sabitleyin, bellek ve CPU limitlerini ayarlayın, gerçek sağlık kontrolleri kullanın, kalıcı verileri kapsayıcının dışında saklayın, günlükleri merkezileştirin ve hem kapsayıcıyı hem de ana bilgisayarı izleyin. Bu altı değişiklik, tekrarlayan Docker olaylarının büyük bir kısmını çözer.
Oradan, kapatma işlemini iyileştirin, kapsayımları düzenli olarak yeniden derleyin ve dağıtımları daha güvenli hale getirin. Bunların hiçbiri gösterişli değil, ama olay bu. Kararlı altyapı genellikle sessiz altyapıdır.
Mesai saatleri sonrasında ana bilgisayarları, yedeklemeleri, uyarıları ve çalışma zamanı davranışlarını izlemek istemeyen ekipler için, yönetilen altyapı desteği birçok riski ortadan kaldırabilir. Bu, özellikle kapsayıcılarınız gelir getiren mağazaları, müşteri sitelerini, dahili iş araçlarını veya her yeniden başlatmanın bir maliyeti olduğu SaaS iş yüklerini desteklediğinde geçerlidir.
En iyi Docker ortamı, en çok ayara sahip olan değildir. Sıradan bir Salı günü, trafik ani yükselmesinde ve yukarı akışta bir şeyler ters gittiğinde öngörülebilir davranan ortamdır. Bu tür bir sakinlik için oluşturun, böylece kapsayıcılarınızın kırılganlığı azalır.
Andres Saar, Müşteri Bakım Mühendisi