Docker Engine 29'un yeni varsayılan image store'u --storage-opt size kotalarını sessizce yok sayıyor

Docker Engine 29, temel bir varsayılan değişikliğiyle geliyor: yeni kurulumlar artık klasik overlay2 graphdriver yerine image store olarak containerd snapshotter kullanıyor. dev.to'da yayımlanan uygulamalı bir karşılaştırmaya göre bu değişiklik ciddi bir operasyonel gerileme de getiriyor — bir container'ın yazılabilir katmanını sınırlamak için kullanılan --storage-opt size seçeneği artık kabul ediliyor ama hiçbir zaman uygulanmıyor; ne bir hata, ne bir uyarı, ne de bir log kaydı var.

Çalışmayı bırakan ve şikâyet etmeyi de bırakan bir kota

--storage-opt size bayrağının uzun zamandır katlı ön koşulları vardı: yalnızca pquota seçeneğiyle mount edilmiş XFS üzerinde çalışan overlay2'de işlev görüyor. Test makinesi, düz bir ext4 root dosya sistemine ve project quota mount seçeneğine sahip olmayan taze bir Docker 29.3.1 kurulumuydu; backend bir daemon feature flag'i ile değiştirilebiliyor ve docker info üzerinden doğrulanabiliyordu.

Klasik graphdriver altında Docker bunu doğru ve görünür biçimde ele alıyor. --storage-opt size=100M ile bir container çalıştırmak her seferinde 125 çıkış koduyla başarısız oluyor ve daemon, seçeneğin yalnızca pquota mount seçeneğiyle XFS üzerindeki overlay'de desteklendiğini belirten açık bir hata veriyor. Container hiç başlamıyor — bu da bir makine isteği karşılayamadığında tam olarak istediğiniz davranış.

Docker 29'un varsayılanı olan containerd snapshotter altında ise aynı komut aynı dosya sisteminde 0 çıkış koduyla tamamlanıyor ve container içindeki bir shell, istenen 100MB sınırına rağmen 300MB'lık bir dosya yazdı. Sonuç üç ayrı denemede tekrarlandı. Sorunu daha da büyüten şey, docker inspect'ın seçeneği ayarlanmış olarak göstermeye devam etmesi (map[size:100M]); dolayısıyla herhangi bir uyumluluk script'i, denetim aracı veya container yapılandırmasını okuyan bir operatör sınırın aktif olduğunu düşünecek. Yazarın nedene ilişkin değerlendirmesi şu: containerd image store yolu seçeneği kabul etmeden önce dosya sistemi desteğini doğrulamıyor, graphdriver yolu ise doğruluyor — kasıtlı bir davranış değişikliği değil, uygulanmamış bir kontrol.

Pull işlemleri gerçekten daha hızlı

Değişikliğin olumlu yanı da yok değil. Temiz bir durumdan node:22 — 8 katman, açılmış hâliyle 1.64GB — çekildiğinde ortalama süre snapshotter'da 18.0 saniye, overlay2'de ise 28.5 saniye oldu; bu da yaklaşık %37 daha hızlı demek ve her backend için üç denemede tutarlıydı. Yazar, test sıralamasının snapshotter'ı kayıran warm-cache yanlılığını dışarıda bıraktığına dikkat çekiyor; çünkü daha yavaş olan graphdriver denemeleri dizide daha sonra gerçekleşti.

max-concurrent-downloads üzerine yapılan bir deney beklentilerin tersine sonuçlandı. Docker 29 sürüm notları, 29.7.0'da düzeltilen ve snapshotter yolunda eşzamanlı pull limitlerinin uygulanmadığı bir hatayı tanımlıyor; yazar da bunu 29.3.1 üzerinde yeniden üretmeyi bekliyordu. Bunun yerine ayar iki backend üzerinde de neredeyse hiç fark yaratmadı: snapshotter'da 18.0s'den 15.0s'ye, overlay2'de 28.5s'den 27.5s'ye düştü. Bu rakamlardan çıkarılan sonuç, bu kurulumda pull süresini belirleyen şeyin eşzamanlı HTTP indirme sayısı değil, katmanların dosya sistemine açılması olduğu.

Image mount'lar ve dedup ayakta

İki ek kontrol de temiz sonuçlandı. Sürüm notlarına göre 29.7.0'da experimental statüsünden çıkan --mount type=image, 29.3.1'de hâlâ bir experimental uyarısı veriyor ama testlerde doğru davrandı: mount salt-okunur (yazma denemesi salt-okunur dosya sistemi hatasıyla başarısız oluyor) ve hatalı bir kaynak image ya da eksik bir hedef, 125 çıkış koduyla düzgün biçimde başarısız oluyor. Bir subpath varyantı bu build üzerinde tanınmadı. Disk muhasebesi de backend değişikliğini atlattı: docker system df -v, python:3.12-slim ve python:3.13-slim arasında paylaşılan 87.45MB'lık Debian temel katmanlarını doğru biçimde her iki image için de eşleşen şekilde raporladı.

Neden önemli

Sessiz bir kota arızası, bir ops ekibinin bir yükseltmeden miras alabileceği neredeyse en kötü arıza modudur. overlay2 altında karşılanamayan bir --storage-opt size gürültülü, engelleyici bir hata üretiyordu; yeni varsayılan altında ise temiz bir çıkış kodu, meşru görünen bir docker inspect değeri ve bir container'ın tüketebileceği disk üzerinde fiilen hiçbir sınır üretiyor. Olası etki alanı, başka bir şey bozulduğunda fark edilen, başka birçok container'ın da yazdığı bir makine diskini dolduran kontrolden çıkmış bir container.

Container başına disk kotalarına bel bağlayan ekipler — özellikle güvenilmeyen veya çok kiracılı (multi-tenant) iş yükleri için — Docker 29'a geçmeden önce dosya sistemlerinin project quota destekleyip desteklemediğini doğrulamalı ve docker inspect çıktısını bir uygulama kanıtı değil, niyet kanıtı olarak görmelidir. Daha hızlı pull işlemleri gerçek ve yeniden üretilebilir; ama gürültülü bir arızayı sessiz bir arızayla takas eden bir varsayılanla birlikte geliyorlar.