---
title: "Docker İmajınız Neden 1,2 GB? Katman Katman Küçültme"
url: "https://cilginyazilim.com/blog/docker-imaji-kucultme-katman-katman"
description: "Docker imajı küçültme için çok aşamalı derleme, katman sırası ve .dockerignore. 1,2 GB'lık bir imajı 90 MB'a indiren adımlar, ölçüm komutlarıyla."
published: "2026-08-26T10:00:00+03:00"
modified: "2026-08-26T10:00:02+03:00"
author: "superadmin"
category: "DevOps ve Sistem Yönetimi"
tags: ["otomasyon", "performans", "altyapı", "güvenlik", "devops", "ci/cd", "docker", "dağıtım", "konteyner", "imaj boyutu", "multi-stage build", "alpine"]
site: "CılgınYazılım"
language: "tr"
---

# Docker İmajınız Neden 1,2 GB? Katman Katman Küçültme

Şişkin imaj yalnızca disk yemez; her dağıtımda indirilir, her ölçeklenmede kopyalanır, her güvenlik taramasında daha fazla açık üretir. Küçültmek düşündüğünüzden kolay.

Docker imajı küçültme, ertelenmesi en kolay ama getirisi en hızlı görülen işlerden biri. Şişkin imaj sessizce çalışır; ta ki trafik artıp otomatik ölçeklenme devreye girene ve yeni konteynerlerin ayağa kalkması dakikalar sürene kadar. Aşağıda, tipik bir 1,2 GB'lık imajı 90 MB seviyesine indiren adımlar var.

![Docker imajında boyutun dağılımı](https://cilginyazilim.com/uploads/blog/2026/08/docker-imaji-kucultme-katman-katman-ozet.png)
*Tipik bir şişkin imajda boyutun büyük kısmı, çalışma zamanında hiç kullanılmayan derleme araçlarından geliyor.*

## Önce ölçün: boyut nereden geliyor?

Tahminle başlamayın. Docker, katman katman boyut dökümü verebiliyor:

```bash
docker image ls uygulamam
docker history uygulamam:latest --human --format "{{.Size}}\t{{.CreatedBy}}"
```

Çıktıda genellikle iki üç katman toplamın büyük kısmını kaplar. Suçlu neredeyse her zaman aynıdır: temel imaj seçimi ve derleme araçlarının son imajda kalması.

## 1. Temel imajı doğru seçin

Aynı dilin farklı temel imajları arasında on kata varan boyut farkı olabiliyor. Tam sürüm, geliştirme başlıkları ve dokümantasyonla birlikte gelir; "slim" varyantlar bunları atar; Alpine tabanlı olanlar ise farklı bir C kütüphanesi üzerine kurulur ve en küçüğüdür.

Alpine'ı seçmeden önce bir uyarı: musl libc, glibc ile tamamen aynı davranmaz. Derlenmiş uzantılar, zaman dilimi veritabanı ve yerelleştirme davranışları sürpriz yapabilir. Bu farkın bedelini üretimde ödememek için, geçişi mutlaka test ortamında doğrulayın.

## 2. Çok aşamalı derleme kullanın

En büyük kazanç burada. Derleyiciler, paket yöneticileri ve geliştirme bağımlılıkları imajı derlemek için gerekli; çalıştırmak için değil.

```dockerfile
# 1. aşama: bağımlılıkları hazırla
FROM composer:2 AS bagimlilik
WORKDIR /uygulama
COPY composer.json composer.lock ./
RUN composer install --no-dev --no-scripts --prefer-dist --optimize-autoloader

# 2. aşama: çalışma zamanı — derleme araçları YOK
FROM php:8.3-fpm-alpine
WORKDIR /uygulama
COPY --from=bagimlilik /uygulama/vendor ./vendor
COPY . .
RUN chown -R www-data:www-data writable
USER www-data
```

Son imajda Composer yok, derleme önbelleği yok, geliştirme bağımlılıkları yok. Yalnızca çalışmak için gereken dosyalar var.

## 3. Katman sırasını değişim hızına göre kurun

Docker her katmanı önbelleğe alır ve bir katman değişince ondan sonraki her katmanı yeniden üretir. Bu yüzden **en az değişen şey en üstte olmalı.**

Yaygın hata, kaynak kodun tamamını bağımlılık kurulumundan önce kopyalamak. Bu durumda tek bir satır kod değişikliği bile tüm bağımlılıkların yeniden indirilmesine yol açar; derleme süresi 20 saniyeden 4 dakikaya çıkar. Doğru sıra: önce bağımlılık tanım dosyaları, sonra kurulum, en son kaynak kod.

## 4. .dockerignore yazın

Çoğu projede bu dosya ya yok ya da eksik. Yokken `COPY . .` komutu `.git` klasörünü, yerel `node_modules`'ü, test verilerini ve kim bilir hangi yedek dosyayı imaja taşıyor.

```bash
.git
node_modules
vendor
tests
writable/cache/*
writable/logs/*
*.md
.env
docker-compose*.yml
```

Buradaki `.env` satırı özellikle önemli: yapılandırma dosyanızın imaja gömülmesi, sırlarınızın imajı çekebilen herkese açılması demektir. Sırların nasıl yönetileceği konusunda [sır kasasına geçiş](https://cilginyazilim.com/blog/sirlarin-yonetimi-env-dosyasindan-sir-kasasina) yazısı yol gösterici.

## 5. Tek RUN, tek katman

Ard arda yazılan her `RUN` yeni bir katman üretir ve bir katmanda silinen dosya önceki katmanda durmaya devam eder. Yani paket kurup sonraki satırda önbelleği temizlemek boyutu düşürmez.

```dockerfile
# Yanlış: temizlik ayrı katmanda, boyut düşmez
RUN apk add --no-cache build-base
RUN rm -rf /var/cache/apk/*

# Doğru: kurulum ve temizlik aynı katmanda
RUN apk add --no-cache --virtual .derleme build-base \
    && docker-php-ext-install pdo_mysql \
    && apk del .derleme
```

## Küçük imajın yan faydası: daha az açık

Güvenlik taraması, imajdaki her paketi kontrol eder. İmajda ne kadar az paket varsa, tarama raporunda o kadar az bulgu çıkar — ve bu bulguların çoğu zaten sizin kullanmadığınız araçlardan geliyordur. 900 MB'lık bir temel imajda yüzlerce bilinen açık listelenirken, sadeleştirilmiş bir imajda bu sayı onlu rakamlara iniyor. Yamalanacak yüzey küçüldükçe güvenlik işi de yönetilebilir hâle geliyor.

> Konteyneri root ile çalıştırmayın. Varsayılan davranış budur ve imaj küçültmeyle uğraşırken en sık atlanan güvenlik ayarıdır. Dockerfile'ın sonunda `USER` satırı yoksa, konteynerden kaçış senaryolarında saldırgan doğrudan yetkili kullanıcı olur.

## Sonuçları ölçün

Değişiklikten önce ve sonra üç sayıyı kaydedin: imaj boyutu, temiz derleme süresi ve önbellekli derleme süresi. Üçüncüsü genellikle en çarpıcı olanıdır; katman sırasını düzelten ekipler, günlük derleme süresinde dakikalar kazanıyor. Bunun CI hattına etkisini [CI/CD kurgusu](https://cilginyazilim.com/blog/ci-cd-nedir-kucuk-ekipler-icin-otomatik-dagitim) yazısıyla birlikte değerlendirebilirsiniz.

## Sonuç

Docker imajı küçültme işi beş adımdan ibaret: doğru temel imaj, çok aşamalı derleme, değişim hızına göre katman sırası, düzgün bir `.dockerignore` ve tek katmanda kurulum-temizlik. Bu beşini uygulamak birkaç saat sürüyor; kazancı ise her dağıtımda, her ölçeklenmede ve her güvenlik taramasında geri dönüyor. Altyapının tekrarlanabilirliği konusunda [altyapıyı kod olarak yönetmek](https://cilginyazilim.com/blog/altyapiyi-kod-olarak-yonetmek-iac) yazısı da tamamlayıcı.

Resmî kılavuz ve güncel pratikler: [Docker — Dockerfile en iyi pratikler](https://docs.docker.com/build/building/best-practices/).

## Sıkça Sorulan Sorular

### Docker imajı küçültme neden önemli?

Boyut, disk maliyetinden çok dağıtım hızını etkiler. Her yeni sürümde imaj kayıt defterinden indirilir; otomatik ölçeklenmede yeni bir konteyner ayağa kalkarken de indirilir. 1 GB'lık bir imajda bu, trafik yoğunlaştığı anda dakikalarca gecikme demek. Ayrıca imajdaki her paket, güvenlik taramasında potansiyel bir açık kaydıdır.

### Alpine tabanlı imaj her zaman doğru seçim mi?

Hayır. Alpine, glibc yerine musl kullandığı için bazı derlenmiş uzantılarda ve yerelleştirme (locale) davranışlarında sürprizler çıkarabiliyor. Boyut farkını gerçekten önemsiyorsanız ve bağımlılıklarınızı test ettiyseniz iyi bir seçim; aksi hâlde "slim" varyantlar çoğu zaman daha az sürtünmeli bir orta yol.

### Çok aşamalı derleme (multi-stage build) ne kazandırır?

Derleme için gereken araçları (derleyici, paket yöneticisi, geliştirme başlıkları) son imaja taşımamanızı sağlar. İlk aşamada derlersiniz, ikinci aşamaya yalnızca çıktıyı kopyalarsınız. Derlenen dillerde imaj boyutunu onda birine indirdiği görülüyor.

### İmajımın içinde ne olduğunu nasıl görürüm?

docker history komutu katman katman boyut dökümü verir ve genellikle suçluyu tek bakışta gösterir. Daha ayrıntılı inceleme için dive gibi araçlar, hangi dosyaların hangi katmanda ne kadar yer kapladığını gezilebilir biçimde sunuyor.

---

Kaynak: [Docker İmajınız Neden 1,2 GB? Katman Katman Küçültme](https://cilginyazilim.com/blog/docker-imaji-kucultme-katman-katman)