Docker containerd Image Store: Snapshotter, Geçiş ve Disk Kullanımı

Snapshotter ile graph driver arasındaki fark

Endüstri standardı container çalışma ortamı olan containerd, imaj ve container verisini saklamak için klasik storage driver'lar yerine snapshotter'lar kullanır. Snapshotter'lar imaj katmanlarının dosya sisteminde nasıl saklanıp erişileceğini yönetir. Belgelere göre çoğu kullanıcı için containerd image store'a geçiş şeffaftır: depolama arka ucu değişir ama iş akışınız aynı kalır. docker pull, docker run ve docker build komutlarını aynı şekilde kullanmaya devam edersiniz.

containerd image store'un klasik depolamaya göre sağladığı olanaklar şunlardır:

• Çok platformlu imajları yerelde derleyip saklamak. Klasik storage driver'larla çok platformlu imajlar için harici builder'lar gerekir.
• Provenance ve SBOM gibi attestation içeren imajlarla çalışmak. Bunlar klasik depolamanın desteklemediği imaj indekslerini kullanır.
• Wasm (WebAssembly) container'larını çalıştırmak.
• Takılabilir, ileri snapshotter'lar kullanmak: imajların tembel çekilmesi (stargz) ya da eşler arası imaj dağıtımı (nydus, dragonfly) gibi.

Bu farkların bir kısmı build tarafında da hissedilir. Multi-platform build belgelerine göre Engine 29.0 ve sonrası containerd image store'u varsayılan kullandığı için çok platformlu imajlar ek kurulum olmadan desteklenir; eski depolamadaysanız ya containerd image store'u etkinleştirmeniz ya da docker-container sürücülü bir builder oluşturmanız gerekir. Benzer biçimde varsayılan docker build sürücüsü inline, local, registry ve gha önbellek arka uçlarını yalnızca containerd image store etkinse destekler. Ayrıntılar için Docker multi-platform build ve Docker build cache arka uçları yazılarına bakın. Image mount (--mount type=image) da yalnızca containerd image store ile çalışır; bu konu Docker tmpfs ve image mount yazısında.

Sunucunuz hangisini kullanıyor?

containerd image store'un etkin olup olmadığını docker info ile kontrol edersiniz. Belgelerde verilen komut ve çıktı şöyledir; çıktıda snapshotter sürücü türü görünüyorsa containerd image store kullanılıyordur:

docker info -f '{{ .DriverStatus }}'
[[driver-type io.containerd.snapshotter.v1]]

Klasik depolamayı kullanan bir daemon'da ise docker info çıktısındaki Storage Driver satırında overlay2 gibi bir sürücü adı görürsünüz. Docker Engine, containerd image store ile varsayılan olarak overlayfs containerd snapshotter'ını kullanır. Bunu klasik overlay2 storage driver ile karıştırmayın: ikisi de çekirdekteki OverlayFS'e dayanır, ama biri containerd'nin snapshotter'ı, diğeri Docker'ın klasik graph driver'ıdır.

Bu ayrım API düzeyinde de görünür. Engine 29.0.0 sürüm notlarına göre image.InspectResponse içindeki GraphDriver alanı isteğe bağlı hale geldi: klasik graph driver'larda yayımlanmaya devam ediyor, containerd image arka ucunda ise çıktıya eklenmiyor. docker image inspect çıktısından GraphDriver alanını okuyan betikleriniz varsa containerd image store'a geçtiğinizde bu alanı bulamayabilirsiniz.

Disk kullanımı ve veri dizini

containerd image store aynı imajlar için klasik sürücülerden daha fazla disk alanı kullanır. Sebebi, containerd'nin imajları hem sıkıştırılmış hem açılmış biçimde saklamasıdır; klasik sürücüler yalnızca açılmış katmanları tutuyordu. Bir imaj çektiğinizde containerd registry'den gelen sıkıştırılmış katmanları saklar ve ayrıca diske açar. Sıkıştırılmış biçim daha hızlı pull ve push sağlar ama ek disk kapasitesi ister. Küçük diskli bir VPS'te bu fark hissedilebilir.

İkinci önemli değişiklik veri dizinidir. Daemon belgelerine göre containerd image store kullanıldığında imaj içerikleri ve container snapshot'ları /var/lib/containerd altında saklanır; volume'lar ve config'ler gibi diğer daemon verileri /var/lib/docker altında kalır. Klasik sürücülerde ise her şey /var/lib/docker altındaydı. Bu yüzden daha önce Docker veri dizinini data-root ile ayrı bir bölüme taşıdıysanız containerd'nin depolaması oraya otomatik taşınmaz ve kök bölümünüz dolabilir.

{
  "data-root": "/mnt/docker-data"
}

data-root ayarı, containerd image store kullanırken /var/lib/containerd altındaki imaj ve container verisini etkilemez. containerd snapshotter'larının depolama yerini değiştirmek için sistem containerd'sinin yapılandırma dosyası kullanılır. Belgelerdeki örnek /etc/containerd/config.toml içeriği şöyledir:

version = 2
root = "/mnt/containerd-data"

Her daemon için ayrı bir dizin kullanmanız gerektiğini de belgeler ayrıca vurguluyor; iki daemon aynı dizini, örneğin bir NFS paylaşımını kullanırsa sorun gidermesi zor hatalar ortaya çıkar. Disk alanı kısıtlıysa belgelerin önerileri şunlardır: kullanılmayan imajları docker image prune ile düzenli temizleyin, disk kullanımını docker system df ile izleyin ve veri dizinini yeterli alanı olan bir bölüme taşıyın. Temizlik komutlarının tamamı için Docker prune ile disk temizleme yazısına bakabilirsiniz.

Yükseltilmiş kurulumda containerd image store'u etkinleştirmek

Daha eski bir Docker Engine sürümünden yükseltiyorsanız containerd image store'u elle etkinleştirmeniz gerekir. /etc/docker/daemon.json dosyasına aşağıdaki özelliği ekleyip daemon'ı yeniden başlatırsınız:

{
  "features": {
    "containerd-snapshotter": true
  }
}

sudo systemctl restart docker

Bir sunucuda bu geçişi planlarken sıralama önemlidir: önce kendi derlediğiniz ve registry'de olmayan imajları dışa aktarın, sonra daemon.json değişikliğini yapıp daemon'ı yeniden başlatın, docker info ile snapshotter'ın etkin olduğunu doğrulayın ve ardından imajları yeniden çekin ya da yükleyin. Container'larınız gizleneceği için Compose projelerini docker compose up ile yeniden oluşturmanız gerekir. Daemon yapılandırma dosyasının genel kuralları için Docker daemon.json yapılandırma yazısına bakın.

userns-remap ile uyumsuzluk

containerd image store, user namespace remapping (userns-remap) kullanılırken kullanılamaz. Engine 29.0.0 sürüm notları, yeni kurulumlardaki varsayılan değişikliğin userns-remap ile yapılandırılmış daemon'lara uygulanmadığını açıkça belirtiyor. Yani sunucunuzda userns-remap etkinse 29.x'e geçseniz bile klasik depolamayı kullanmaya devam edersiniz. Daemon'ı root olmadan çalıştırmanın farklı bir yolu olan rootless mod için Docker rootless mod yazısına bakabilirsiniz.

Lazy pulling

Lazy pulling ile container'lar imajları tamamen indirilmeden başlayabilir; uzak snapshotter'lar katman verisini container ihtiyaç duydukça registry'den getirir. Docker Engine, nydus, overlaybd, soci ya da stargz snapshotter'ı yapılandırıldığında lazy pulling'i varsayılan olarak etkinleştirir. Varsayılan overlayfs dahil diğer snapshotter'larda, açıkça etkinleştirmediğiniz sürece Docker container başlamadan önce tüm katman içeriğini indirir. Sürüm notlarına göre bu davranışı kontrol eden lazy-pull daemon özelliği 29.9.0 sürümünde eklendi.

Lazy pull sırasında Docker, snapshotter'ın uzaktan bağlayabildiği ya da zaten snapshot'ına sahip olduğu katmanları indirmeyi atlar, diğerlerini indirir. Bunun bir yan etkisi vardır: tembel çekilmiş imajlar containerd içerik deposunda bazı katmanlar eksikken çalışabilir, ama eksik içerik kaydetmeyi ve push etmeyi etkiler. docker save başarısız olabilir ya da hata bildirmeden eksik bir arşiv üretebilir; docker push eksik katmanları yükleyemez, ancak hedef registry kaynak depodan katman bağlamayı destekliyorsa onları yeniden kullanabilir. İmajı çalıştırmak eksik içeriğin tamamlanacağını garanti etmez. Lazy pulling'i kapatmak için:

{
  "features": {
    "containerd-snapshotter": true,
    "lazy-pull": false
  }
}

Daemon yapılandırmasını yeniden yüklediğinizde ayar sonraki çekimlere uygulanır; daha önce tembel çekilmiş imajlardaki eksik içeriği indirmek için bu imajları yeniden çekmeniz gerekir. Varsayılan listenin dışındaki bir snapshotter için lazy pulling'i açmak isterseniz değeri true yaparsınız. Yedek amacıyla docker save kullanıyorsanız bu ayrıntı özellikle önemlidir.

Deneysel otomatik geçiş

Docker Engine, belirli koşullarda containerd image store'a otomatik geçebilen deneysel bir özellik içerir. Belgeler bu özelliğin deneysel olduğunu, her senaryoda güvenilir çalışmayabileceğini ve denemeden önce yedek almanız gerektiğini vurguluyor; önerilen yaklaşım temiz başlangıçtır. Özelliği containerd-migration ile açarsınız:

{
  "features": {
    "containerd-migration": true
  }
}

Ayrıca DOCKER_MIGRATE_SNAPSHOTTER_THRESHOLD ortam değişkeniyle, hiç container yoksa ve tüm imaj katmanlarının toplam boyutu eşik değerinde ya da altındaysa daemon'ın otomatik geçiş yapmasını sağlayabilirsiniz. Değer 200M veya 1G gibi insan tarafından okunabilir bir boyuttur. systemd ile sudo systemctl edit docker.service komutunu çalıştırıp şu satırları eklersiniz:

[Service]
Environment="DOCKER_MIGRATE_SNAPSHOTTER_THRESHOLD=200M"

Bu örnekte çalışan ya da durmuş hiç container yoksa ve imaj katmanlarının toplamı 200M veya daha azsa daemon yeniden başlatıldığında containerd image store'a geçer; overlay2 verisi diskte kalır ama gizlenir. Yeni kurulmuş ya da yeniden kurulacak bir sunucuda bu, elle geçişin pratik bir alternatifidir; ama deneysel olduğunu unutmayın.

Daemon içinde gömülü containerd

Docker Engine 29.7.0 sürümünden itibaren daemon, containerd'yi dockerd ile aynı süreçte çalıştırabilir. Varsayılan davranışta daemon containerd'yi ayrı bir süreç olarak başlatıp yönetir. Gömülü mod deneysel bir özelliktir; davranışı değişebilir ya da ileride kaldırılabilir. Bu modda gömülü sunucu yine bir containerd soketinde dinler, ama daemon ve BuildKit ona bellek içi bir bağlantıyla ulaşır; görev shim'leri ise ayrı süreçler olarak çalışmaya ve sokete bağlanmaya devam eder.

Performans kazancı en çok containerd image store kullanıldığında ortaya çıkar, çünkü tüm imaj işlemleri hem meta veri istekleri hem de manifest, yapılandırma ve katman baytları için containerd'nin içerik API'sini kullanır. Ayrı bir containerd süreci bu okuma ve yazmaları bir Unix soketi üzerinden giden gRPC mesajlarına böler; gömülü mod aynı mesajları bellek içi bağlantıyla göndererek bu veri yoğun yolda işletim sistemi soket çağrılarından kaçınır. Gömülü sunucu CRI içermez; embedded-containerd ile cri-containerd aynı anda etkinleştirilemez.

{
  "features": {
    "embedded-containerd": true
  }
}

Gömülü containerd durumunu varsayılan olarak Docker veri kökü altında, /var/lib/docker/containerd/daemon içinde tutar. Host'a kurulu bir containerd ise kendi durumunu /var/lib/containerd gibi başka bir yerde tutar; daemon daha önce böyle bir containerd kullandıysa oradaki container ve imajlar gömülü modda görünmez. Etkinleştirdiğinizde docker info çıktısında deneysel gömülü mod uyarısı görünür. Engine 29.8.0 sürüm notlarına göre dockerd, yapılandırılmış bir sistem containerd servisi yoksa ve containerd kurulu değilse gömülü containerd'yi kullanır.

Gömülü sunucu, ctr ve nerdctl gibi containerd istemcileri için Linux'ta varsayılan olarak /var/run/docker/containerd/containerd.sock uç noktasını sunar ve Docker Engine container'ları varsayılan olarak moby containerd ad alanında saklar:

sudo ctr --address /var/run/docker/containerd/containerd.sock \
  --namespace moby containers list

Belgeler bu uç noktanın hata ayıklama için yararlı olduğunu ama arkasındaki durumun daemon'a ait olduğunu, adresinin ve ad alanı düzeninin değişebileceğini ve diğer istemcilerin yaptığı değişikliklerin daemon ile çakışabileceğini belirtiyor; onu genel amaçlı bir containerd uç noktası gibi kullanmayın.

Engine 29.x sürüm notlarında containerd image store

29.x serisinde containerd image store ile ilgili çok sayıda düzeltme yayımlandı. Sunucunuzu hangi sürümde tutacağınıza karar verirken işinize yarayabilecek birkaç örnek:

Tam liste için Engine 29 sürüm notlarına bakın. Özellikle güvenlik düzeltmeleri, containerd'nin statik ikili sürümünü güncelleyen satırlarda yer alıyor.

Sık yapılan hatalar

• data-root'u değiştirip containerd'yi unutmak: containerd image store'da imaj verisi /var/lib/containerd altındadır ve data-root bunu taşımaz.
• Geçişte imajların silindiğini sanmak: Veri diskte kalır, yalnızca gizlenir; önceki yapılandırmaya dönünce yeniden görünür.
• Disk planlamasını eski depolamaya göre yapmak: containerd sıkıştırılmış ve açılmış katmanları birlikte sakladığı için daha fazla alan kullanır.
• userns-remap etkinken varsayılanın değiştiğini düşünmek: Bu yapılandırmada containerd image store kullanılamaz.
• Tembel çekilmiş imajı docker save ile yedeklemek: Eksik içerik nedeniyle arşiv sessizce eksik kalabilir.
• Gömülü containerd soketini kalıcı otomasyonlarda kullanmak: Adres ve ad alanı düzeni değişebilir.

Sık Sorulan Sorular

Docker 29'a yükselttim, containerd image store otomatik açıldı mı?

Hayır. Yükseltilmiş kurulumlar siz etkinleştirene kadar klasik graph driver'larla devam eder; varsayılan değişiklik yalnızca yeni kurulumlar içindir. docker info -f '{{ .DriverStatus }}' ile kontrol edebilirsiniz.

containerd image store'a geçmek zorunda mıyım?

Belgeler bir zorunluluktan söz etmiyor. Ancak çok platformlu imajlar, attestation'lar, image mount ve varsayılan build sürücüsüyle bazı önbellek arka uçları containerd image store gerektiriyor. Bu özelliklere ihtiyacınız varsa geçiş mantıklıdır.

Volume'larım containerd image store'a geçince etkilenir mi?

Daemon belgelerine göre containerd image store kullanılırken volume'lar /var/lib/docker altında kalır; değişen, imaj içerikleri ve container snapshot'larının yeridir. Gizlenen container'larınızı yeniden oluşturduğunuzda aynı volume'ları bağlayabilirsiniz.

Geri dönmek istersem ne olur?

containerd-snapshotter özelliğini kaldırıp daemon'ı yeniden başlattığınızda eski imaj ve container'lar yeniden görünür; containerd image store ile oluşturduklarınız ise bu kez gizlenir.

Marka adları sahiplerine aittir. Bu yazı bağımsız bir teknik rehberdir; adı geçen kuruluşlarla bayilik veya ortaklık ilişkisi bulunduğu anlamına gelmez.

İlgili içerikler: Docker öğrenme rehberi · Storage driver ve overlay2 · Docker Engine 29 yenilikleri · Multi-platform build · daemon.json yapılandırma · Docker prune