Container Image Optimizasyonu: Distroless ve Chainguard

Docker image size optimization, modern container platformlarında deploy süresini, saldırı yüzeyini ve bulut faturasını doğrudan etkileyen birinci dereceden mühendislik problemidir. Standart bir Node.js veya Python uygulaması node:20 veya python:3.12 tabanlı Dockerfile ile build edildiğinde 900 MB ile 1.4 GB arasında bir image üretir; aynı uygulamayı multi-stage build + distroless veya Chainguard tabanı ile yeniden tasarladığınızda final image 40-80 MB seviyesine iner. Bu yazı container image optimizasyonunun üç temel mühendislik aracını (multi-stage Dockerfile pattern, Google distroless, Chainguard Wolfi) gerçek metrikler, CVE sayıları ve build pipeline örnekleriyle ele alır; FROM scratch‘tan glibc/musl seçimine, Software Bill of Materials (SBOM) üretiminden registry storage faturasına kadar uçtan uca bir referans sağlar.

Sysdig 2024 Cloud-Native Security and Usage Report verilerine göre production’a gönderilen container image’larının yaklaşık %87’si en az bir high veya critical CVE içeriyor ve image başına ortalama tespit edilen güvenlik açığı sayısı 145 civarında. Chainguard Images public dataset’i ise aynı uygulamaları Wolfi tabanlı image’larla yeniden paketlediğinde CVE sayısının %95 üzerinde düştüğünü, çoğu image’ın “zero known CVE” hedefiyle yayınlandığını gösteriyor. Bu farkın temel nedeni iki mimari karar: ilki final runtime’da package manager, shell ve build araçlarını tamamen elemek; ikincisi Alpine’ın musl tabanlı geleneksel approach’unun yerine modern, dependency-graph temiz, sub-day patch SLA’lı bir base distribution kullanmak.

Container Image Boyutu Neden Önemli? Net Maliyet ve Performans Kazançları

Image boyutu sadece estetik bir metrik değildir. Her ek megabyte registry storage, network egress, node disk usage ve pod cold-start latency üzerinde ölçülebilir maliyet üretir. Bir CI/CD pipeline’da günde 200 build, 50 environment’a deploy eden orta ölçekli bir SaaS firması için 1 GB’tan 100 MB’a inen bir image yıllık registry pull bandwidth maliyetinde altı haneli rakamlara ulaşan tasarruf üretebiliyor. AWS ECR egress fiyatı bölgeye göre $0.09/GB seviyesinde; ECR’den farklı bir region’a veya CDN dışına 1 GB image’ı günde 1000 kez pull eden bir cluster ayda yaklaşık $2700 sadece egress için ödüyor.

Boyutun ikinci etkisi pod startup time. Google Cloud Run, AWS Fargate, Azure Container Apps gibi serverless container servislerinde cold-start süresinin yaklaşık %60’ını image pull oluşturuyor. 800 MB’lık bir Python image’ı Fargate’te ortalama 18-25 saniyede çekilirken, 60 MB’lık distroless varyantı 3-5 saniyede pod-ready’ye ulaşıyor. Saniyelik fatura modeli olan bu platformlarda her cold-start 5x daha pahalıya mal oluyor.

*Tahmini değer: günlük 1000 pull, AWS ECR cross-region egress $0.09/GB üzerinden.

Image Tipi	Ortalama Boyut	Cold Start	Tespit Edilen CVE	Yıllık Egress Maliyeti*
ubuntu:22.04 + apt deps	950 MB	22 sn	180+	~$32.000
python:3.12 (Debian slim)	420 MB	11 sn	95	~$14.000
python:3.12-alpine	180 MB	6 sn	40	~$6.000
Multi-stage + distroless	75 MB	3.5 sn	8	~$2.500
Chainguard Wolfi (production)	55 MB	2.8 sn	0-2	~$1.800

Üçüncü boyut attack surface. Production runtime’ında bash, apt, curl, wget, tar binary’leri varsa, bir RCE veya container escape senaryosunda saldırgan bu araçları doğrudan kullanarak lateral movement yapabiliyor. Distroless ve Chainguard image’larında shell dahi olmadığı için exploit zinciri çok daha kısıtlı. NIST Special Publication 800-190 (Application Container Security Guide) bu prensibi “minimize the attack surface by removing unnecessary tooling” maddesiyle açıkça öneriyor.

Multi-Stage Build: Compile-time ile Runtime’ı Ayırmanın Endüstri Standardı

Multi-stage build, Docker 17.05 (2017) ile gelen ve bugün her CNCF projesinin standart pattern’i olan bir yaklaşım. Mantık basit: build araçları (compiler, package manager, test framework) yalnızca build stage’inde gerekli; final runtime image’a kopyalanması gereken sadece compiled artifact ve runtime dependency’ler. Aynı Dockerfile içinde birden fazla FROM deklarasyonu kullanılır ve son FROM production image’ı oluşturur; önceki stage’lerden COPY --from=builder ile sadece gerekli dosyalar taşınır.

Aşağıdaki Go uygulaması için minimal multi-stage Dockerfile, build stage’de Go toolchain’i (~800 MB) tutarken final image’ı yalnızca compile edilmiş binary üzerine kuruyor:

# Stage 1: build
FROM golang:1.23 AS builder
WORKDIR /src
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -ldflags="-s -w" -o /out/app ./cmd/api

# Stage 2: runtime (distroless static)
FROM gcr.io/distroless/static-debian12:nonroot
COPY --from=builder /out/app /app
USER nonroot:nonroot
ENTRYPOINT ["/app"]

Bu pattern’le yukarıdaki Go binary’si 12-18 MB civarında bir final image üretiyor. Aynı uygulama golang:1.23 tabanlı tek-stage build ile yaklaşık 820 MB. Multi-stage’in sağladığı kazanç sadece boyut değil; build dependency’lerin production runtime’a sızmaması anlamına geliyor. CI/CD pipeline kurulumu sürecinde bu pattern’in baseline olarak benimsenmesi, downstream güvenlik tarama (Trivy, Grype) sonuçlarını da dramatik şekilde temizliyor.

• Avantaj: Build cache’i layer-by-layer optimize edilebilir; go.mod/package.json‘ı önce kopyalayıp RUN go mod download bağımsız layer’da çalıştırmak rebuild süresini saniyeler içinde tutuyor.
• Avantaj: Build secret’lar (private repo SSH key, npm token) yalnızca builder stage’de; final image’a sızmıyor.
• Dezavantaj: Debug’ı zorlaştırıyor; kubectl exec ile shell almak imkansız olduğundan ephemeral debug container (Kubernetes 1.25+) veya ayrı debug image’ı şart.
• Ne zaman seç: Compiled language (Go, Rust, C++, Java AOT), tek binary’ye çevrilen Python/Node script’ler, statik build edilebilen her uygulama.

Google Distroless: “Yalnızca Uygulamanız ve Runtime Dependency’leri”

Distroless, Google’ın 2017’de açtığı ve gcr.io/distroless/ registry’sinde dağıttığı bir base image ailesi. Felsefe: image içinde sadece uygulama ve runtime’da gerçekten kullanılan kütüphaneler. Shell yok, package manager yok, init system yok, debug aracı yok. Java için distroless/java21, Python için distroless/python3, Node.js için distroless/nodejs20, generic statik binary için distroless/static ve glibc bağımlı binary için distroless/base varyantları mevcut.

Distroless image’ları :nonroot tag’i ile root olmayan user (UID 65532) ile geliyor; bu Kubernetes Pod Security Standard “restricted” profili için doğrudan uyumlu. Sürüm yönetimi GoogleContainerTools/distroless repo’sunda Bazel ile yapılıyor ve her image için SBOM otomatik üretiliyor.

Distroless Variant	Boyut (sıkıştırılmış)	Içerik	Tipik kullanım
static-debian12	~2 MB	ca-certs, tzdata, /etc/passwd	Go, Rust statik binary
base-debian12	~20 MB	glibc, libssl, libstdc++	CGO_ENABLED Go, C++ app
cc-debian12	~22 MB	base + libgcc, runtime C/C++	Dinamik C++ binary
java21-debian12	~190 MB	OpenJDK 21 runtime	Spring Boot, JAR
python3-debian12	~50 MB	Python 3.11 runtime + libs	Flask, FastAPI
nodejs20-debian12	~70 MB	Node.js 20 runtime	Express, Next.js sunucu

Pratik bir örnek: Spring Boot uygulamasını eclipse-temurin:21-jdk üzerine deploy ederseniz image yaklaşık 530 MB. Aynı JAR’ı distroless/java21-debian12 üzerine koyduğunuzda final image 210-230 MB civarına iniyor ve içeride jstack, jcmd, jmap gibi diagnostic araçlar bulunmuyor. Production’da observability’yi sidecar (OpenTelemetry collector, Jaeger agent) veya remote JMX exporter ile sağlamak gerekiyor.

Debug stratejisi: ephemeral container ve :debug tag’leri

Distroless’ın “shell yok” prensibi production’da güvenlik kazandırırken debugging’i zorlaştırıyor. Bunun için iki standart yaklaşım var. İlki Kubernetes kubectl debug komutu ile ephemeral container ekleyip aynı pod namespace’inde busybox veya nicolaka/netshoot container’ı başlatmak. İkincisi distroless’ın :debug tag’lerini kullanmak; bu varyantlar BusyBox shell içeriyor ama production’da kullanılmamalı, yalnızca staging/canary için.

Chainguard Wolfi: Sub-Day Patch SLA ve “Zero CVE” Hedefi

Chainguard 2022’de Google distroless ekibinin kurucularının başlattığı şirket; Wolfi isimli “container-native, undistro” tabanı geliştiriyor. Wolfi geleneksel anlamda bir Linux dağıtımı değil; sadece container içinde çalışmak üzere tasarlanmış, glibc kullanan, APK package manager’lı, declarative build sistemli bir base. Önemli farkı dependency graph’ın küçük ve temiz tutulması; her paket bağımsız versioning ile, transitive dependency’ler aggressive şekilde minimize edilmiş.

Chainguard Images’ın iki büyük diferansiyatörü var. İlki sub-day patch SLA: yeni bir CVE açıklandığında ilgili paketin fix’i tipik olarak aynı gün içinde build edilip image olarak push’lanıyor. İkincisi her image’ın SLSA Level 3 attestation, SBOM (SPDX + CycloneDX) ve Sigstore imzası ile dağıtılması. Bu, supply chain security için DevSecOps shift-left stratejisinde kritik bir bileşen.

Chainguard public free image’ları (developer tier) cgr.dev/chainguard/ registry’sinde mevcut; ancak production-grade SLA (sub-day patch, FIPS variant, extended support) için ücretli “Chainguard Production” plan’ı gerekiyor. 2025 fiyatlandırması yaklaşık $50.000-$200.000/yıl aralığında, organizasyon büyüklüğü ve image sayısına göre değişiyor.

Özellik	Alpine	Distroless	Chainguard Wolfi	UBI Micro (Red Hat)
libc	musl	glibc	glibc	glibc
Package manager (final)	apk (var)	yok	yok (build-only apk)	yok
Shell (final)	ash	yok	yok	yok
Ortalama CVE (high+critical)	15-30	3-10	0-2	2-5
Patch SLA	community	~haftalık	~sub-day	iş günü
SBOM	opsiyonel	otomatik	otomatik (SLSA L3)	otomatik
Lisans	BSD/MIT	Apache 2.0	Apache 2.0 + ticari	EULA
Tipik final image	5-15 MB	2-50 MB	3-60 MB	40-80 MB

Alpine ve musl Tuzakları: Neden Her Zaman Doğru Seçim Değil

Alpine uzun yıllar boyunca minimal container’ın sinonimi oldu. 5 MB’lık base image, hızlı build süresi ve yaygın community desteği onu cazip kılıyor. Ancak Alpine’ın musl libc kullanması, glibc’ye bağımlı uygulamalarda subtle bug’lar üretebiliyor. Python’da DNS resolution, Node.js’te grpc native modules, Java’da bazı NIO çağrıları musl üzerinde glibc’den farklı davranıyor. musl-libc wiki’sindeki functional differences listesi 30+ kalemden oluşuyor.

Daha pratik bir sorun: Python wheel’leri. Çoğu Python paketi (numpy, pandas, cryptography, lxml) PyPI’da manylinux2014 wheel’leri olarak yayınlanıyor; bunlar glibc tabanlı. Alpine’da bu paketleri kurmak için kaynak koddan compile etmek gerekiyor ve bu build süresini 30 saniyeden 8-12 dakikaya çıkarabiliyor. Alpine’a özel musllinux wheel’leri yavaş yavaş yaygınlaşıyor ama coverage henüz tam değil.

• Ne zaman Alpine kullan: Statik link edilmiş Go binary, basit shell utility, nginx reverse proxy gibi musl-safe uygulamalar.
• Ne zaman Alpine kullanma: Production Python/Node.js stack, JVM uygulaması, ML/AI workload (CUDA driver glibc bekler), cryptography-heavy kod.
• Alternatif tercih: Boyut için Alpine düşünüyorsanız, Wolfi veya distroless aynı boyutta glibc’li alternatif sunuyor.

Docker ve Kubernetes yönetimi rehberinde bahsedilen base image seçimi, uygulama runtime’ı ile libc’nin uyumuna göre yapılmalı; popülerlik veya boyut tek başına karar kriteri olamaz.

Layer Optimizasyonu: Cache Hit Oranını Artıran 8 Pratik

Image boyutu kadar önemli olan ikinci metrik build süresi. CI runner’da her commit’te 8 dakika süren bir image build, takım büyüdükçe ciddi yavaşlama üretiyor. BuildKit (Docker 18.09+, varsayılan Docker 23+) ve buildx ile gelen modern cache yönetimi doğru kullanıldığında re-build süresi saniyeler içinde tutulabiliyor.

Pratik	Beklenen kazanç	Uygulama
Dependency manifest’i önce kopyala	%70-90 cache hit	COPY package*.json ./ + RUN npm ci, sonra COPY . .
.dockerignore dosyası	2-10x build context küçülmesi	node_modules, .git, tests/ hariç tut
--mount=type=cache	Re-install ~10x hızlanma	BuildKit syntax: RUN --mount=type=cache,target=/root/.npm npm ci
Multi-platform buildx	amd64 + arm64 tek pipeline	docker buildx build --platform linux/amd64,linux/arm64
Remote cache (registry)	Cross-runner cache paylaşımı	--cache-to type=registry,ref=...,mode=max
Squash veya minimal layer	Image boyutu %10-20	Multi RUN‘ı tek RUN‘a birleştir
Final stage’de gereksiz dosya silme	50-200 MB	apt cache, pip cache, /tmp temizle
COPY --link	Layer reuse iyileşmesi	BuildKit 1.0+, syntax 1.4+

Önemli bir nokta: RUN apt-get update && apt-get install -y X && rm -rf /var/lib/apt/lists/* pattern’i layer’da apt cache bırakmamak için klasiktir, ama multi-stage’de build stage zaten final image’a kopyalanmadığı için final stage’de bu detay genellikle gereksiz. Build stage’i hızlı tutmak için cache’i orada bırakmak daha mantıklı.

SBOM, Image İmzalama ve Supply Chain Güvenliği

2021 SolarWinds saldırısı ve sonrasındaki Log4Shell olayı, container image’ın yalnızca “küçük olması” yetmediğini, içeride neyin olduğunun kanıtlanabilir olması gerektiğini ortaya koydu. ABD Executive Order 14028 ve ardından gelen NIST SSDF (Secure Software Development Framework) federal tedarikçiler için SBOM zorunluluğu getirdi; benzer regülasyon AB Cyber Resilience Act ile Avrupa için 2027’den itibaren yürürlüğe giriyor.

Modern container build pipeline’ında üç artefakt zorunlu hale geliyor:

1. SBOM (Software Bill of Materials) — SPDX veya CycloneDX formatında, image içindeki her paketi sürüm ve hash ile listeler. Syft en yaygın açık kaynak araç.
2. Vulnerability scan raporu — Trivy, Grype veya Snyk Container tarafından üretilen, CVE’leri severity ile listeleyen JSON/SARIF.
3. İmza (Sigstore Cosign) — Keyless OIDC tabanlı, transparency log’a yazılan kriptografik imza. Kubernetes admission controller (Sigstore Policy Controller, Kyverno) image deploy edilmeden önce imzayı doğrular.

Chainguard image’ları bu üçünü out-of-the-box veriyor. Distroless ise SBOM sağlıyor ama Cosign imzasını siz kendi pipeline’ınızda eklemeniz gerekiyor. Build sonrası tipik GitHub Actions adımı:

- name: Sign image with Cosign
  run: cosign sign --yes ${{ env.IMAGE }}@${{ steps.build.outputs.digest }}

- name: Generate SBOM
  uses: anchore/sbom-action@v0
  with:
    image: ${{ env.IMAGE }}
    format: spdx-json

- name: Attest SBOM
  run: cosign attest --yes --predicate sbom.spdx.json 
    --type spdxjson ${{ env.IMAGE }}@${{ steps.build.outputs.digest }}

Bu pipeline ile her image hem küçük hem de kanıtlanabilir oluyor; production cluster’ta container güvenliği politikası imzasız veya SBOM’suz image’ı reddedebiliyor.

• SBOM aracı önerisi: Syft (Anchore) açık kaynak, SPDX + CycloneDX desteği; tek komutla container image, dosya veya Git repo’sundan SBOM üretir.
• Vulnerability scanner: Trivy (Aqua Security) CNCF graduated proje, Grype (Anchore) ve Snyk Container ticari alternatif; üçü de SARIF çıktısı verir.
• İmza ve attestation: Cosign + Rekor transparency log; keyless OIDC modu ile CI pipeline’da private key saklamadan imzalama yapılır.
• Admission control: Sigstore Policy Controller veya Kyverno; cluster’a imzasız image deploy edilmesini blokla.
• Ne zaman zorunlu: Federal tedarik (EO 14028), AB CRA (2027), PCI-DSS v4, ISO 27001 Annex A.14 sertifikasyonu.

Gerçek Migration Vakaları: 800 MB’tan 60 MB’a Yolculuk

Bir e-ticaret SaaS’ı için yürütülen bir migration projesinde Python/FastAPI tabanlı 14 mikroservis python:3.11 base’inden cgr.dev/chainguard/python:latest base’ine geçirildi. Aşağıdaki tablo migration öncesi ve sonrası kıyaslamayı gösteriyor:

14 servis, 6 ay üretim verisi ortalaması.

Metrik	Önce (python:3.11)	Sonra (chainguard/python)	Değişim
Ortalama image boyutu	720 MB	85 MB	-88%
High/Critical CVE	112	0	-100%
EKS pod startup p50	14.2 sn	4.1 sn	-71%
EKS pod startup p99	28.5 sn	7.8 sn	-73%
ECR storage (14 image x 30 tag)	302 GB	35 GB	-88%
Aylık egress maliyeti	$1.840	$220	-88%
Build süresi (cold)	4.5 dk	3.8 dk	-15%
Build süresi (warm cache)	55 sn	32 sn	-42%

Migration sırasında karşılaşılan sürtünmeler de gerçekçi olarak not edilmeli: native dependency’li bir paket (psycopg2-binary yerine psycopg2 source-build veya psycopg[binary]‘a geçiş), file system permission farklılıkları (Chainguard nonroot user 65532 vs Python 3.11’in default root), debug için kubectl debug alışkanlığının takıma kazandırılması ve eski Helm chart’larının securityContext.runAsUser field’larının güncellenmesi.

Aynı proje kapsamında bir geçiş aşamasında cloud-native mimari best practices doğrultusunda init container kullanımı azaltıldı; çoğu init işi build-time’a kaydırılarak runtime image yüzeyi daha da kısıtlandı. Bu tür bir migration’da Ömer Önal’ın container danışmanlığı çerçevesinde önerdiği “önce single high-traffic servisle pilot, sonra batch’lerle scale” yaklaşımı, regresyon riskini düşürüyor ve metric karşılaştırmasını temiz tutuyor.

Karar Çerçevesi: Hangi Senaryoda Hangi Base Image?

Tüm bu seçenekleri tek bir karar matrisinde toplamak gerekirse, üç boyutta düşünmek pratiktir: workload tipi, compliance gereksinimi ve operasyonel olgunluk.

Senaryo	Önerilen base	Gerekçe
Go/Rust mikroservis, hızlı startup	distroless/static:nonroot	2 MB, glibc gerekmiyor, gratis
Python/Node API, PCI-DSS gerekli	Chainguard Wolfi (paid)	Zero CVE SLA, FIPS, audit raporu
Python/Node API, internal tooling	distroless/python3 veya nodejs20	Gratis, Google maintained
Spring Boot, kurumsal Java	UBI Micro + Temurin JRE veya distroless/java21	Vendor support tercih edilirse UBI
ML inference (GPU, CUDA)	NVIDIA CUDA runtime + distroless layered	glibc + CUDA driver zorunluluğu
Legacy uygulama, hızlı debug	debian:12-slim + apt minimum	Shell var, troubleshoot kolay
Single-binary CLI tool dağıtımı	FROM scratch	0 MB overhead, sadece binary
Edge/Function (Cloudflare, Lambda)	Provider native runtime	Image değil, deploy bundle

Bu kararlar runtime maliyeti ve operability arasındaki ödünleşmeyi yansıtıyor. FinOps bulut maliyet perspektifinden bakıldığında, registry storage ve egress kalemleri çoğu kurumda alttan yenilen bir maliyet; image optimizasyonu görünmez tasarrufu görünür hale getiriyor. Cluster maliyet ve deploy otomasyonu stratejileri ile birleştiğinde image optimizasyonunun toplam getirisi 6-12 aylık dönemde altı haneli dolar seviyelerine ulaşıyor.

Sıkça Sorulan Sorular (SSS)

Sonuç

Container image optimizasyonu, “boyut küçültme” tekniği değil; tedarik zinciri güvenliği, bulut faturası ve operasyonel hız üzerinde aynı anda kazanım üreten bir mühendislik disiplinidir. Multi-stage Dockerfile pattern’i bugün her CNCF projesinin başlangıç noktası; distroless ücretsiz ve olgun bir base ailesi olarak gratis tier’da production-ready; Chainguard ise compliance-yoğun (PCI, HIPAA, FedRAMP) iş yükleri için sub-day patch SLA ve SLSA Level 3 attestation ile farklılaşıyor. Alpine hâlâ niş senaryolarda anlamlı ama varsayılan tercih olmaktan çıkmaya başladı.

Karar verirken üç soruyu sırayla yanıtlayın: workload glibc’ye bağımlı mı (Wolfi/distroless), compliance audit gerekli mi (Chainguard veya UBI), operasyonel debug akışınız ephemeral container’a uyumlu mu (uyumluysa distroless, değilse slim Debian)? Bu üç filtre çoğu takımın doğru base’ini saniyeler içinde seçmesini sağlıyor. Daha karmaşık migration projelerinde mevcut Dockerfile envanterinin audit’i, base image standardizasyonu ve CI pipeline’a SBOM/Cosign entegrasyonu için iletişim sayfasından destek talebi ile detaylı yol haritası çıkarılabiliyor.