0. Bu Yazı Nasıl Okunmalı?

Bu dokümantasyon, Docker’ı sıfırdan öğrenmek isteyenler için kapsamlı bir rehber olarak hazırlandı. Ancak bu sadece bir blog yazısı değil — aynı zamanda bir başvuru kaynağı ve pratik bir kılavuz.

Yazının Yapısı ve Okuma Stratejisi

Bu yazı kademeli derinleşme prensibiyle oluşturuldu. İlk bölümler temel kavramları tanıtırken, ilerleyen bölümler production ortamları, güvenlik, performans optimizasyonu gibi ileri seviye konulara giriyor. Bu yüzden:

Eğer yeni başlıyorsanız: Sırayla, baştan sona okuyun. Her bölüm bir öncekinin üzerine inşa edilmiştir. Konuları atlamak, ileride anlama zorluğu yaratabilir.

Eğer belirli bir sorunu çözmek istiyorsanız: İçindekiler bölümünden ihtiyacınız olan konuya atlayın. Her bölüm mümkün olduğunca bağımsız yazılmaya çalışıldı.

Eğer bilginizi pekiştirmek istiyorsanız: İlgilendiğiniz bölümleri seçerek okuyun, ancak örnekleri mutlaka test edin.

Önemli Uyarılar

1. Yavaş okuyun. Özellikle 10. bölümden sonra teknik detaylar artıyor. Acele ederseniz önemli noktalari kaçırabilirsiniz.

2. Pratik yapın. Sadece okumak yeterli değil. Örnekleri kendi bilgisayarınızda çalıştırın, hata yapın, düzeltin. Yazılım öğrenmek bir zanaat — deneyerek öğrenilir.

3. Parçalara bölün. Bu yazıyı tek oturuşta okumaya çalışmayın. Her gün bir-iki bölüm üzerinde çalışmak, tüm yazıyı bir gecede geçiştirmekten çok daha etkilidir.

4. Not alın. Önemli komutları, kendi projeleriniz için uyarlayabileceğiniz pattern’leri, karşılaştığınız sorunları not edin. Bu yazı bir referans kaynağıdır, sık sık geri döneceksiniz.

Hedef Kitle

• Yazılım geliştiriciler (backend, frontend, full-stack)
• DevOps mühendisleri ve sistem yöneticileri
• Docker’a yeni başlayanlar
• Mevcut Docker bilgisini derinleştirmek isteyenler
• Production ortamlarında Docker kullanacak ekipler

Bu Yazının Felsefesi

Teori + Pratik = Öğrenme. Her kavram hem teorik olarak açıklandı hem de çalışan kod örnekleriyle gösterildi. “Neden?” ve “Nasıl?” sorularının ikisine de yanıt vermeye çalıştım.

Sade dil. Gereksiz jargondan kaçındım. Teknik terimler kullanıldığında açıklandı. Anlaşılır olmak, teknik derinlikten daha önemli.

Gerçek dünya senaryoları. Production ortamında karşılaşacağınız problemler, anti-pattern’ler ve çözümleri de dahil edildi. Bu sadece “nasıl çalıştırılır” değil, “nasıl doğru çalıştırılır” rehberi.

Başlamadan Önce

Docker’ı bilgisayarınıza kurmuş olduğunuzdan emin olun. Kurulum talimatları Bölüm 3’te detaylı anlatılıyor. Terminal veya PowerShell kullanmaktan çekinmiyorsanız, hazırsınız demektir.

Şimdi, lafı daha fazla uzatmadan, Docker’ın ne olduğunu ve neden bu kadar önemli olduğunu anlamaya başlayalım.

1. Giriş / Neden Docker?

1.1 Kısa Özet: Konteyner Nedir, VM’den Farkı?

Uygulamaları çalıştırmanın iki yolunu elimize alalım:

• Doğrudan işletim sistemine kurmak

• Sanal makine (VM) kullanmak

Sanal makinelerde (örneğin VirtualBox, VMware) her bir makine kendi işletim sistemine sahiptir. Bu da çok fazla sistem kaynağı tükenmesine (RAM, CPU, disk alanı) ve başlatılmasınınzaman alması demektir.

Konteyner teknolojisi ise farklı bir yaklaşım getirir. Konteynerler, işletim sisteminin çekirdeğini ortak kullanır; sadece uygulamanın çalışması için gerekli kütüphaneleri ve bağımlılıkları içerir. Sadece gereklilikleri izole olarak çalıştırır, Yani:

• Daha hafif,

• Daha hızlı açılır,

• Taşınabilir (her yerde çalışır) hale gelir.

Özetle:

• VM = Tüm bilgisayarı taklit eder.

• Konteyner = Sadece uygulamanın ihtiyacını izole edip çalıştırır.

1.2 Neden Docker?

Peki konteynerleri yönetmek için neden Docker kullanıyoruz? Çünkü Docker:

• Taşınabilirlik sağlar: Bir uygulamayı kendi bilgisayarında çalıştırdığın şekilde sunucuda da çalıştırabilirsin. “Benim bilgisayarımda çalışıyor ama sende çalışmıyor” sorunu ortadan kalkar.

• Hızlı dağıtım sunar: Birkaç saniyede konteyneri ayağa kaldırıp silebilirsin. Geleneksel kurulum süreçleri saatler sürebilirken Docker ile dakikalar, hatta saniyeler yeterli. Tüm sistemi kurmanıza gerek kalmaz sadece gereklilikleri kurar ve projeyi ayağa kaldırmanızı sağlar.

• Standart bir ekosistemdir: Docker Hub üzerinden milyonlarca hazır imajı (nginx, mysql, redis gibi) indirip anında kullanabilirsin.

• Modern yazılım pratiklerine uygundur: Mikroservis mimarisi, CI/CD, DevOps süreçlerinde Docker artık neredeyse zorunlu bir araç hâline gelmiştir.

1.3 Bu Yazıdan Kimler Nasıl Faydalanır?

Bu yazı, Docker’a yeni başlayanlar, yazılımcılar, teknik altyapıya ilgi duyanlar ve sistem yöneticileri için hazırlanmış hem bilgilendirici hem de rehber niteliğinde bir blog olarak tasarlandı.

Amacım, Docker kavramlarını sadece teknik terimlerle değil, basit ve anlaşılır bir dille anlatmak. Teoriyi pratiğe dönüştürerek, okuyucuların Docker’ı kendi projelerinde güvenle kullanabilmesini sağlamayı hedefliyorum.

Bu blog-dökümantasyon:

• Linux ve Windows ortamlarında uygulanabilir,
• Teoriden çok pratiğe odaklı,
• Karmaşık jargon yerine sade bir anlatım sunar,
• Adım adım ilerleyen bir öğrenme yolu sağlar.

Kısacası: Bu yazı, Docker’a yeni başlayanlardan sistem yöneticilerine kadar herkes için hazırlanmış, hem blog hem de rehber niteliğinde bir kaynaktır. Basit, jargon içermeyen anlatımıyla teoriyi pratiğe dönüştürerek Docker’ı öğrenmeyi hızlı, sade ve etkili hâle getirmeyi hedefledim.

2. Docker Ekosistemi ve Temel Bileşenler (Docker’ın Kendi Araçları)

Docker sadece “konteyner çalıştıran bir yazılım” değildir. Onun etrafında birçok araç, bileşen ve standart gelişmiştir. Bunları bilmek, Docker’ın nasıl çalıştığını anlamak ve onu kullanabilmek için önemlidir.

2.1 Docker Engine (Daemon & CLI)

Docker Engine, Docker’ın kalbidir. Arka planda çalışan daemon (dockerd) konteynerlerin yönetiminden sorumludur. Örnek olarak: başlatma, durdurma, network, volume

Burada bizim kullandığımız kısım Docker CLI (docker run, docker ps, docker build gibi komutlardır). CLI, daemon ile konuşur ve emirleri uygulatır.

Özet: CLI = Kullanıcı arabirimi, Daemon = Motor.

2.2 Docker CLI komutları

Docker container

Konteyner yönetimi komutları:

Docker image

İmaj (image) yönetimi:

• docker image ls / docker images — sistemdeki imajları listeler (Docker Documentation)

• docker image rm / docker rmi — bir ya da daha fazla imajı siler (Docker Documentation)

• docker image prune — kullanılmayan (dangling) imajları temizler (Docker Documentation)

Docker build

Dockerfile’dan imaj oluşturma:

• docker build — Dockerfile’a göre imaj inşa eder (Docker Documentation)

• --no-cache gibi bayraklarla cache kullanımını devre dışı bırakma (Docker Documentation)

Genel Komutlar

• docker version — CLI ile daemon versiyon bilgisini gösterir

• docker info — Docker ortamının durumunu, sistem detaylarını gösterir

• docker system — sistemle ilgili komutlar (örneğin kaynak temizleme, disk kullanımı)

• docker --help veya docker <komut> --help — komutların yardım bilgisini gösterir

2.2.1 Docker CLI Parametreleri — Detaylı Açıklama ve Örnekler

Docker CLI komutlarında kullanılan parametreler:

2.3 Dockerfile & BuildKit (build optimizasyonu)

Dockerfile, Docker imajlarını tanımlayan tarif dosyasıdır. İçinde hangi temel imaj kullanılacağı, hangi paketlerin kurulacağı, hangi dosyaların kopyalanacağı ve hangi komutların çalıştırılacağı gibi bilgiler yer alır.

Dockerfile Temelleri

Örnek basit Dockerfile:

FROM python:3.11-slim

WORKDIR /app

COPY requirements.txt .

RUN pip install --no-cache-dir -r requirements.txt

COPY . .

CMD ["python", "app.py"]

Temel komutlar:

• FROM → temel imaj belirler
• WORKDIR → çalışma dizinini ayarlar
• COPY / ADD → dosya kopyalama
• RUN → imaj inşa sürecinde komut çalıştırma
• CMD → konteyner başlatıldığında çalışacak komut

Docker BuildKit Nedir?

BuildKit, Docker’ın build sürecini daha hızlı, verimli ve güvenli hale getiren modern build motorudur.
Docker 18.09’dan itibaren opsiyonel olarak kullanılabilmiş, Docker 20+ ile artık varsayılan olarak aktiftir.

Avantajları:

• Paralel build adımları (daha hızlı)
• Layer cache optimizasyonu (disk ve zaman tasarrufu)
• Inline cache kullanımı
• Build output’ların daha iyi kontrolü
• Build secrets yönetimi
• Daha temiz ve küçük imajlar

BuildKit Kullanımı

Docker’da BuildKit’i aktif etmek için:

export DOCKER_BUILDKIT=1   # Linux/macOS
setx DOCKER_BUILDKIT 1    # Windows (PowerShell)

Docker build komutu:

docker build -t myapp:latest .

BuildKit ile aynı komut:

DOCKER_BUILDKIT=1 docker build -t myapp:latest .

BuildKit’in Özellikleri

1. Secret Yönetimi Şifreler, API anahtarları gibi hassas bilgileri build sürecinde güvenli şekilde kullanabilirsin.

   # syntax=docker/dockerfile:1.4
   FROM alpine
   RUN --mount=type=secret,id=mysecret cat /run/secrets/mysecret
   

   Build komutu:

   DOCKER_BUILDKIT=1 docker build --secret id=mysecret,src=secret.txt .
   

2. Cache Yönetimi --cache-from ile önceden build edilmiş imajlardan cache kullanabilirsin.

   docker build --cache-from=myapp:cache -t myapp:latest .
   

3. Parallel Build Bağımsız katmanlar aynı anda build edilir, build süresi kısalır.

4. Multi-stage Builds Daha küçük ve optimize edilmiş imajlar için build sürecini birden çok aşamada tanımlayabilirsin.

FROM golang:1.20 AS builder
WORKDIR /app
COPY . .
RUN go build -o app

FROM alpine:latest
WORKDIR /app
COPY --from=builder /app/app .
CMD ["./app"]

BuildKit, Docker build sürecinde performans, güvenlik ve yönetilebilirlik sağlar. Büyük ve karmaşık projelerde BuildKit kullanmak, imaj boyutunu azaltır, build süresini kısaltır ve hassas bilgilerin güvenliğini artırır.

2.4 Docker Compose (tek makinede multi-container)

Çoğu gerçek hayat uygulaması tek bir konteyner ile çalışmaz. Genelde modüler olması için her işlem için ayrı bir konteyner açılır. Eğer bir sistem çökerse diğer sistemlerinde çökmemesi için bu gereklidir. Bu yapının adı Modüler Yapıdır. Misal bir saas projesinde her api için ayrı bir konteyner açmak hem sistemde bir sorun olduğunda diğer sistemlerin çökmesini ve bozulmasını engeller ve sistem sorunları ile baş etmede yardımcı olur.

Örneğin:

• Bir web uygulaması + veritabanı (MySQL/Postgres) + önbellek (Redis)

• Bir API servisi + mesaj kuyruğu (RabbitMQ/Kafka)

Ek olarak bu sistemi kurduğunuzda hepsini tek tek docker run ile başlatmak karmaşık ve hataya açık olur. İşte burada Docker Compose devreye girer. Hem modüler bir yapı yapmanızda hemde bunun kontrolünü kaybetmemeniz için en güzel seçeneğiniz Docker Compose olacaktır.

Docker Compose Nedir?

• Bir YAML dosyası (docker-compose.yml) üzerinden, birden fazla servisi tanımlayıp yönetmeye yarar.

• Tek komutla (docker compose up) tüm sistemi ayağa kaldırabilir, docker compose down ile temizleyebilirsiniz.

• Ortak ağ (network) ve volume tanımlarını kolayca yapar.

• Genelde geliştirme ve test ortamlarında tercih edilir, prod ortamında ise Kubernetes gibi orkestrasyon araçlarına geçilir.

Örnek docker-compose.yml

Basit bir Django + Postgres uygulamasını düşünelim:

version: "3.9"   # Compose dosyası sürümünü belirtir.

services:
  web:   # 1.servis (Web Servis)
    build: .   # (Bulunduğun klasördeki `Dockerfile` kullanılarak imaj üretilir)
    ports:
      - "8000:8000"  # 8000 portuna yönlendirme
    depends_on:   # Bu servis çalışmadan önce `db` servisinin ayağa kalkmasını garanti eder.
      - db
    environment:
      - DATABASE_URL=postgres://postgres:secret@db:5432/appdb
    networks:
      - my_network   # Manuel network ataması

  db:  # 2.servis (PostgreSQL veritabanı)
    image: postgres:16
    environment:
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: secret
      POSTGRES_DB: appdb
    volumes:
      - db_data:/var/lib/postgresql/data
    networks:
      - my_network   # Manuel network ataması

volumes:
  db_data:

networks:   # Manuel network tanımı
  my_network:
    driver: bridge   # Bridge network tipi (en yaygın)

Temel Komutlar

• docker compose up → YAML’deki tüm servisleri ayağa kaldırır.
• docker compose down → Tüm servisleri ve network’ü kapatır.
• docker compose ps → Compose ile açılan konteynerleri listeler.
• docker compose logs -f → Servislerin loglarını canlı izlersin.
• docker compose exec web bash → Web konteynerine girip komut çalıştırırsın.

2.5 Docker Desktop (Windows/macOS için)

Docker, Linux üzerinde doğrudan kernel üzerinde çalışabilir. Ancak Windows veya macOS üzerinde bu mümkün değildir çünkü Docker Linux çekirdeği (kernel) gerektirir. İşte bu yüzden Docker Desktop devreye girer.

Docker Desktop Nedir?

• Docker Desktop, Windows ve macOS kullanıcıları için Docker’ın resmi uygulamasıdır.

• Linux çekirdeği üzerinde Docker çalıştırabilmek için içinde hafif bir sanal makine (VM) barındırır.

• Kullanıcıya bu süreci şeffaf bir şekilde sunar: sanki Docker Linux üzerinde çalışıyormuş gibi komutlar yazarsın.

2.6 Docker Registry / Docker Hub / private registry

Docker Registry, Docker imajlarının depolandığı ve paylaşıldığı sunucu veya servisdir. İmajlar, bir Registry üzerinde tutulur ve ihtiyaç duyulduğunda buradan çekilir (pull) veya yüklenir (push).

Docker ekosisteminde en yaygın kullanılan registry türleri Docker Hub ve Private Registry’dir.

Docker Hub

• Docker’ın resmi registry servisidir.

• hub.docker.com üzerinden milyonlarca hazır imaj erişilebilir. (nginx, mysql, redis vb.)

• Avantajları:

  • Kolay erişim, büyük topluluk desteği
  • Resmi imajlar güvenlik güncellemeleriyle desteklenir
  • Ücretsiz plan ile sınırlı kullanıma imkan verir

Kullanım örneği:

docker pull nginx:latest   # Docker Hub’dan nginx imajını çek
docker run -d -p 80:80 nginx:latest

Private Registry

• Şirket içi veya özel projeler için kendi registry’ni kurabilirsin.

• Örneğin, hassas bir uygulamanın imajlarını yalnızca kendi ağında saklamak isteyebilirsin.

• Avantajları:

  • Tam kontrol (erişim, güvenlik, depolama)
  • Gizlilik ve özel dağıtım

• Kurulum örneği:

docker run -d -p 5000:5000 --name registry registry:2

Bu komut ile yerel bir registry ayağa kalkar.
Artık imajlarını kendi registry’ne push/pull edebilirsin.

Örnek:

docker tag myapp localhost:5000/myapp:latest
docker push localhost:5000/myapp:latest
docker pull localhost:5000/myapp:latest

Registry Kullanım Workflow’u

1. İmaj oluştur (docker build)
2. İmaj etiketle (docker tag)
3. Registry’ye yükle (docker push)
4. Registry’den çek (docker pull)

Docker Hub ile Private Registry kısaca karşılaştırmamız gerekirse:

2.7 Docker Swarm (native orchestration)

Docker Swarm, Docker’ın kendi içinde gelen, birden çok bilgisayarda çalışan konteynerleri tek bir sistem gibi yönetmemizi sağlayan bir özelliktir. Yani:

• Normalde Docker’ı tek bir bilgisayarda çalıştırırsın.
• Eğer yüzlerce konteyneri farklı bilgisayarlarda çalıştırmak istersen, bunu manuel yapmak çok zor olur.
• Docker Swarm, bu işi otomatikleştirir: konteynerleri hangi bilgisayarda çalıştıracağını, kaç tane çalışacağını ve birbirleriyle nasıl konuşacağını kendisi yönetir.

Bir benzetme yapalım:

Docker Swarm, bir orkestra şefi gibidir.

• Tek bir müzisyen (bilgisayar) yerine, birden çok müzisyen (bilgisayar) vardır.
• Şef (Swarm) herkese ne çalacağını, ne zaman çalacağını ve nasıl uyum içinde çalışacaklarını söyler.
• Ortaya düzgün bir müzik (çalışan sistem) çıkar.

Docker Swarm’un Temel Özellikleri

• Cluster Yönetimi
  Birden çok Docker host’unu tek bir sanal Docker host gibi yönetir.
  Bu host’lara “node” denir.

• Yük Dengeleme (Load Balancing)
  Swarm, servis taleplerini otomatik olarak uygun node’lara yönlendirir.

• Servis Keşfi (Service Discovery)
  Swarm, servisleri otomatik olarak birbirine tanıtır.
  Servis isimleri üzerinden erişim sağlanabilir.

• Otomatik Failover
  Bir node arızalanırsa, Swarm konteynerleri otomatik olarak başka node’lara taşır.

Docker Swarm Yapısı

Swarm cluster’ı iki tip node’dan oluşur:

1. Manager Node

   • Cluster yönetimini üstlenir.

   • Servis dağıtımı, cluster durum kontrolü ve yük dengeleme işlemlerini yapar.

2. Worker Node

   • Manager node’dan aldığı görevleri çalıştırır.

Docker Swarm Kullanım Örneği

1. Swarm başlatma (manager node)

docker swarm init

Bu komut ile mevcut Docker host, Swarm cluster’ının manager node’u olur.

2. Node ekleme (worker node)

docker swarm join --token <token> <manager-ip>:2377

Bu komut, worker node’u cluster’a ekler. <token> ve <manager-ip> Swarm tarafından sağlanır.

3. Servis oluşturma

docker service create --name myweb --replicas 3 -p 80:80 nginx

• --replicas 3: Servis için 3 konteyner kopyası çalıştırır.

• -p 80:80: Port yönlendirmesi yapar.

4. Servis durumu kontrolü

docker service ls
docker service ps myweb

Özetle Docker Swarm, küçük ve orta ölçekli projelerde basit, hızlı ve yerleşik bir orkestrasyon çözümüdür.
Kubernetes gibi daha karmaşık sistemlere geçmeden önce hızlı prototipler ve küçük cluster’lar için idealdir.

2.8 containerd / runc (altyapı) — kısa not

Docker çalışırken aslında birden fazla katmanda işler yürütülür.
containerd ve runc, Docker’ın en temel altyapı bileşenlerindendir.

containerd

• Docker’ın konteyner yaşam döngüsünü yöneten yüksek seviyeli runtime’ıdır.
• Konteyner oluşturma, çalıştırma, durdurma, silme gibi görevleri yönetir.
• Görüntü (image) yönetimi, network, storage ve konteyner lifecycle gibi işlemler containerd üzerinden yapılır.

runc

• containerd tarafından kullanılan düşük seviyeli runtime’dır.
• Open Container Initiative (OCI) standardına uygun olarak konteynerleri çalıştırır.
• Temel olarak Linux çekirdeği üzerinde konteynerlerin çalışmasını sağlar.

Özetle:

• containerd → Docker’ın konteyner yönetim motoru
• runc → Konteynerleri çekirdek üzerinde çalıştıran motor

Bu ikisi Docker’ın “motoru” gibidir; Docker CLI ise “direksiyon” görevindedir.

3. Kurulum & İlk Adımlar (Linux vs Windows)

Docker kurulumu işletim sistemine göre farklılık gösterir. Bu bölümde Linux ve Windows üzerinde kurulum adımlarını açıklayacağız.

3.A Linux (alt dağıtımlar: Ubuntu/Debian, RHEL/CentOS, Arch)

Docker’ı Linux üzerinde kurarken genellikle şu adımlar uygulanır:

1. Paket deposu ekleme → Docker’ın resmi paket deposunu sisteme ekleriz.
2. GPG anahtarı ekleme → Paket bütünlüğünü doğrulamak için gerekli.
3. Docker ve containerd kurulumu → Docker Engine’i ve container runtime’ını kurarız.
4. Docker servisini aktif etme → Sistem başlatıldığında Docker’ın çalışmasını sağlar.
5. Kullanıcı yetkilendirmesi → Docker komutlarını root olmadan çalıştırabilmek için kullanıcıyı docker grubuna ekleriz.

Temel komutlar (Ubuntu örneği)

sudo apt update
sudo apt install -y ca-certificates curl gnupg lsb-release

# Docker’ın GPG anahtarını ekleme
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg

# Docker repository ekleme
echo \
 "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] \
 https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt update

# Docker Engine, CLI, containerd ve Compose kurulumu
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin

# Docker servisini aktif etme
sudo systemctl enable --now docker

# Kullanıcıyı docker grubuna ekleme (root olmadan docker kullanımı)
sudo usermod -aG docker $USER

Açıklama:

• systemctl enable --now docker: Docker servisini etkinleştirir ve anında başlatır.
• sudo usermod -aG docker $USER: Kullanıcıyı docker grubuna ekler, böylece her komut için sudo gerekmez (çıkış yapıp tekrar giriş yapmak gerekir).

3.B Windows (Docker Desktop + WSL2 ve Windows konteynerler)

Windows üzerinde Docker çalıştırmak için Docker Desktop kullanılır. Docker Desktop, Windows üzerinde Docker’ı çalıştırmak için WSL2 (Windows Subsystem for Linux) veya Hyper-V teknolojilerini kullanır.

Kurulum Aşamaları

1. Docker Desktop Kurulumu

• Docker Desktop’ı resmi siteden indir.

• Kurulum sırasında WSL2 entegrasyonu seçeneğini işaretle.

2. WSL2 Kontrolü ve Kurulumu

PowerShell üzerinde:

wsl --list --verbose

Eğer WSL2 kurulu değilse:

wsl --install -d Ubuntu

Bu komut Ubuntu’yu WSL2 üzerinde kurar ve çalıştırır.

3. Hyper-V ve Containers Özelliklerini Etkinleştirme

Docker Desktop’ın düzgün çalışması için Hyper-V ve Containers özellikleri aktif olmalıdır.
PowerShell üzerinde:

dism.exe /online /enable-feature /featurename:Microsoft-Hyper-V /all
dism.exe /online /enable-feature /featurename:Containers /all

4. Docker Desktop’ı Başlatma

• Kurulum tamamlandığında Docker Desktop’ı çalıştır.
• Settings → General bölümünde “Use the WSL 2 based engine” seçeneğini işaretle.

5. Windows Konteynerler vs Linux Konteynerler

Docker Desktop’ta konteyner türünü değiştirebilirsin:

• Linux containers → Varsayılan, çoğu uygulama için önerilen.
• Windows containers → Windows tabanlı uygulamalar için kullanılır.

4. Dockerfile — Adım Adım (Linux ve Windows tabanlı örnekler)

Dockerfile, Docker imajlarının nasıl oluşturulacağını tanımlayan metin dosyasıdır. Bir Docker imajı, bu dosyadaki yönergelere göre adım adım inşa edilir. Dockerfile yazmak, uygulamanın çalışacağı ortamı standartlaştırmak ve dağıtım sürecini kolaylaştırmak için kritik bir adımdır.

Bu bölümde Dockerfile’ın temel direktiflerini, multi-stage build yaklaşımını ve Windows container’larda Dockerfile kullanımını detaylı şekilde ele alacağız.

4.1 Dockerfile Temel Direktifler

Dockerfile içinde kullanılan temel direktifler:

Not: Direktiflerin sırası, Docker cache mekanizması açısından önemlidir.

4.2 Multi-Stage Builds — Neden, Nasıl?

Multi-stage build, imaj boyutunu azaltmak ve gereksiz bağımlılıkları final imajdan çıkarmak için kullanılır.

Örnek: Node.js Multi-Stage Build

# Stage 1: Build
FROM node:18-alpine AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

# Stage 2: Production
FROM node:18-alpine
WORKDIR /app
COPY --from=build /app/dist ./dist
COPY package*.json ./
RUN npm ci --only=production
CMD ["node", "dist/index.js"]

4.3 Windows Container Dockerfile

Windows container’lar, Linux container’lara göre farklı Dockerfile direktifleri ve base image’lar kullanır.

Örnek: Windows PowerShell Base Image

FROM mcr.microsoft.com/windows/servercore:ltsc2022
SHELL ["powershell", "-Command", "$ErrorActionPreference = 'Stop';"]

RUN Write-Host 'Hello from Windows container'
CMD ["powershell.exe"]

Ek Bilgi: Windows container imajları genellikle Linux’a göre daha büyük boyutludur.

4.4 Örnek: Linux Node.js Dockerfile

FROM node:18-alpine

WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .

USER node
CMD ["node", "index.js"]

4.5 İyi Pratikler

Dockerfile yazarken katman sayısını azaltmak için RUN komutlarını birleştirmeli, .dockerignore ile gereksiz dosyaları build sürecinden çıkarmalı, küçük base image’ler (Alpine, distroless vb.) tercih etmeli, multi-stage build kullanmalı ve ortam değişkenlerini ENV direktifiyle yönetmelisiniz.

Özetle:

• Katman sayısını azaltmak için RUN komutlarını birleştirin.
• .dockerignore ile gereksiz dosyaları build sürecinden çıkarın.
• Küçük base image seçin (Alpine, distroless vb.).
• Multi-stage build kullanın.
• Ortam değişkenlerini ENV ile yönetin.

4.6 Dockerfile Optimizasyonu

Dockerfile optimizasyonu, build süresini kısaltır, imaj boyutunu küçültür ve dağıtım sürecini hızlandırır.

Temel optimizasyon teknikleri:

• Cache kullanımını iyi yönetmek: Direktiflerin sırasını mantıklı tutmak (COPY package*.json → RUN npm ci → COPY . . gibi).
• Katman sayısını azaltmak: RUN komutlarını zincirlemek (&& ile).
• Küçük base image kullanmak: Alpine, distroless veya slim image’lar.
• .dockerignore dosyası oluşturmak: Gereksiz dosyaları dışarıda bırakmak.
• Multi-stage build kullanmak: Gereksiz bağımlılıkları final imajdan çıkarmak.

4.7 Best Practices ve Performans İpuçları

• COPY komutlarını minimumda tutun.
• Ağ üzerinden dosya indirmeleri için RUN curl/wget yerine build argümanlarını kullanın.
• Gereksiz paketleri kaldırın (apt-get clean, rm -rf /var/lib/apt/lists/*).
• Build sürecinde mümkünse --no-cache seçeneğini test amaçlı kullanın.
• Ortam değişkenleri ile konfigürasyonu yönetin, hard-code etmeyin.

4.8 Özet ve İleri Okuma

Dockerfile, konteyner tabanlı uygulama geliştirme sürecinde en kritik parçadır. İyi bir Dockerfile:

• Hızlı build olur,
• Küçük boyutlu imaj üretir,
• Kolay bakım sağlar.

İleri Okuma için Kaynaklar:

• Dockerfile Reference — Docker Docs
• Best Practices for Writing Dockerfiles
• Multi-Stage Builds — Docker Docs

5. Image Yönetimi ve Optimizasyon

Docker imajları, uygulamanızın çalışması için gerekli tüm dosya, bağımlılık ve konfigürasyonu içerir. Etkili imaj yönetimi, hem depolama alanını hem de konteyner başlatma süresini doğrudan etkiler. Bu bölümde imaj yönetiminin temellerini ve optimizasyon tekniklerini ele alacağız.

5.1 Layer Mantığı ve Cache Mekanizması

Docker imajları layer (katman) yapısına dayanır. Her Dockerfile satırı bir katman oluşturur. Bu katmanlar, build sürecinde yeniden kullanılabilir. Bu sayede:

• İmaj oluşturma süresi kısalır,
• Disk kullanımı azalır.

Önemli nokta: Katmanların yeniden kullanılabilmesi için Dockerfile’da yapılan değişiklikler minimum olmalıdır.

5.2 .dockerignore, Katman Sayısını Azaltma, Küçük Base Image Seçme

• .dockerignore dosyası → .gitignore gibi çalışır; build sırasında gereksiz dosyaların konteynere eklenmesini engeller.
• Katman sayısını azaltma → Gereksiz RUN komutlarını birleştirerek katman sayısını düşürmek, imaj boyutunu azaltır.
• Küçük base image seçme → alpine, busybox gibi minimal base imajlar, gereksiz bağımlılıkları ortadan kaldırarak imaj boyutunu ciddi şekilde küçültür.

5.3 Önemli Image Yönetimi Komutları

• docker build --no-cache → Katman önbelleğini kullanmadan imaj oluşturur.
• docker history <image> → İmajın layer geçmişini gösterir.
• docker image prune → Kullanılmayan imajları temizler.

Örnekler:

docker build --no-cache -t myapp:latest .
docker history myapp:latest
docker image prune -a

5.4 Multi-Arch ve docker buildx

Modern uygulamalar farklı platformlarda çalışabilir. Multi-arch (çoklu mimari) imajlar, tek build ile farklı CPU mimarilerine uygun imajlar oluşturmayı sağlar.

docker buildx, Docker’ın gelişmiş build özelliğidir ve multi-arch imajlar için kullanılır.

Örnek:

docker buildx create --use
docker buildx build --platform linux/amd64,linux/arm64 -t myapp:multiarch .

Bu komut ile amd64 ve arm64 mimarileri için tek seferde imaj oluşturulur.

6. Volumes ve Storage (Linux vs Windows farkları)

Docker’da konteynerler geçici ortamlardır — konteyner silindiğinde içindeki tüm veriler kaybolur. Bu nedenle verilerin kalıcılığını sağlamak için volumes ve farklı storage yöntemleri kullanılır. Ancak Linux ve Windows arasında mount yolları, izinler ve davranışlar farklıdır.

Bu bölümde:

• Named volumes, bind mounts ve tmpfs’in farklarını,
• SELinux ile ilgili izin etiketlerini,
• Windows’ta yol yazımı ve izin farklarını,
• Volume yedekleme ve geri yükleme yöntemlerini detaylıca öğreneceksiniz.

6.1 Named Volumes vs Bind Mounts vs tmpfs

Docker’da veri kalıcılığı için üç ana yöntem vardır:

Named Volume Örneği

docker volume create mydata
docker run -d -v mydata:/app/data myimage

• docker volume create komutu volume oluşturur.
• /app/data içinde konteyner verisi kalıcı olur.
• Container silinse bile volume içeriği korunur.

Bind Mount Örneği

Linux:

docker run -v /home/me/app:/app myimage

Windows (PowerShell):

docker run -v "C:\Users\Me\app":/app myimage

• Bind mount, host sistemi ile konteyner arasında doğrudan dosya paylaşımı sağlar.
• Kod geliştirme ve test süreçlerinde sık kullanılır.

tmpfs Örneği

docker run --tmpfs /app/tmp:rw,size=100m myimage

• /app/tmp geçici olarak RAM’de tutulur.
• Konteyner kapandığında veriler kaybolur.
• Performans kritik işlemler için uygundur.

6.2 SELinux :z / :Z Etiketi Linux’ta Neden Gereklidir

SELinux güvenlik politikaları, bind mount’ların konteyner içinde kullanılabilmesi için ek etiketler gerektirir.
Bu etiketler mount edilen dizinin izinlerini belirler:

• :z → Mount edilen dizinin paylaşılması için genel erişim izni sağlar.
• :Z → Mount edilen dizinin yalnızca ilgili konteyner için erişim izni olmasını sağlar.

Örnek:

docker run -v /home/me/app:/app:Z myimage

SELinux etkin olan sistemlerde bu etiketleri kullanmazsanız bind mount çalışmaz veya izin hataları alırsınız.

6.3 Windows’ta Yol Yazımı ve İzin Farklılıkları

Windows’ta bind mount’larda yol yazımı ve izinler Linux’tan farklıdır. Windows’ta bind mount kullanırken dikkat edilmesi gerekenler:

• Yol formatı PowerShell için çift tırnak içinde olmalıdır.
• \ yerine / kullanılabilir, ancak "C:\path\to\dir" formatı güvenlidir.
• Windows ACL izinleri bind mount’larda etkili olabilir, bu yüzden izinleri kontrol etmek gerekir.

Örnek Bind Mount:

Linux:

docker run -v /home/me/app:/app myimage

Windows (PowerShell):

docker run -v "C:\Users\Me\app":/app myimage

6.4 Yedekleme / Geri Yükleme: tar ile Volume Yedekleme Yöntemi

Docker volume’larını yedeklemek veya geri yüklemek için tar komutu kullanılabilir. Bu yöntem hem Linux hem Windows için uygundur.

Yedekleme

docker run --rm -v myvolume:/volume -v $(pwd):/backup alpine \
    tar czf /backup/myvolume-backup.tar.gz -C /volume .

Açıklama:

• --rm → Container durduğunda otomatik silinir.
• -v myvolume:/volume → Yedeklenecek volume bağlanır.
• -v $(pwd):/backup → Host dizini bağlanır, yedekleme dosyası buraya kaydedilir.
• tar czf → Verileri sıkıştırarak .tar.gz formatında yedekler.

Geri Yükleme

docker run --rm -v myvolume:/volume -v $(pwd):/backup alpine \
    tar xzf /backup/myvolume-backup.tar.gz -C /volume

Geri yükleme öncesinde volume’ın boş olduğundan emin olun. Aksi halde eski veriler üzerine yazılır.

7. Ağ (Networking)

Docker’da ağ yönetimi, konteynerlerin birbirleriyle ve host sistemiyle iletişim kurabilmesini sağlar. Docker, varsayılan olarak konteynerler arasında izolasyon sağlar ve farklı ağ modları sunar. Ağlar, Docker’ın en kritik kavramlarından biridir, çünkü uygulamaların güvenliği, ölçeklenebilirliği ve yönetilebilirliği doğrudan ağ yapılandırmasına bağlıdır.

Bu bölümde:

• Docker’ın varsayılan ağ modlarını,
• Custom bridge network oluşturmayı,
• Container içi DNS ve servis keşfini,
• Host networking modunu ve kısıtlarını,
• Overlay, macvlan ve transparent network yapılarını ele alacağız.

7.1 Default Bridge ve Custom Bridge Oluşturma

Docker kurulduğunda otomatik olarak bir default bridge ağı oluşturur.
Bu ağ üzerinde konteynerler, IP adresleri üzerinden birbirlerini görebilir, ancak host ile iletişim için port yönlendirme gerekir.

Default Bridge Örneği:

docker run -d --name web -p 8080:80 nginx

-p 8080:80 → Host’un 8080 portunu container’ın 80 portuna yönlendirir.

Custom Bridge Oluşturma

Custom bridge ağlar, izolasyon ve servis keşfi için daha esnek yapı sağlar.

Ağ oluşturma:

docker network create mynet

Container’ı custom bridge ile başlatma:

docker run -dit --name a --network mynet busybox
docker run -dit --name b --network mynet busybox

Test:

docker exec -it a ping b

( Container a, container b’yi DNS adı ile görebilir.)

7.2 Container İçi DNS ve Servis Keşfi (Compose ile)

Docker Compose, container’lar arasında otomatik DNS çözümlemesi sağlar.
Servis adı, container adı olarak kullanılabilir.

docker-compose.yml Örneği:

version: "3"
services:
  web:
    image: nginx
    networks:
      - mynet

  app:
    image: busybox
    command: ping web
    networks:
      - mynet

networks:
  mynet:

( Burada app container’ı, web container’ını DNS ismi üzerinden bulabilir.)

7.3 --network host (Linux’ta) ve Host Networking’in Kısıtları

Host networking modu, container’ın host’un ağ stack’ini paylaşmasını sağlar.
Bu durumda port yönlendirme gerekmez.

Linux örneği:

docker run --network host nginx

host modu Linux’ta çalışır ancak Windows/macOS üzerinde Docker Desktop’ta desteklenmez.

Güvenlik açısından host modu dikkatli kullanılmalıdır, çünkü container host ağını doğrudan etkiler.

7.4 Overlay Network (Swarm), macvlan, Transparent Networks (Windows)

Overlay Network (Docker Swarm)

• Farklı host makinelerdeki container’ların birbirleriyle iletişim kurmasını sağlar.
• Docker Swarm cluster’larında kullanılır.

Overlay Network oluşturma:

docker network create -d overlay my_overlay

Macvlan Network

• Container’lara host ağı üzerinde kendi MAC adresini verir.
• Fiziksel ağda ayrı bir cihaz gibi görünmesini sağlar.

Örnek:

docker network create -d macvlan \
  --subnet=192.168.1.0/24 \
  --gateway=192.168.1.1 \
  -o parent=eth0 my_macvlan

Transparent Network (Windows)

• Windows container’larda fiziksel ağ ile doğrudan bağlantı kurmak için kullanılır.
• Genellikle enterprise ağ senaryolarında tercih edilir.

7.5 Örnek: Custom Bridge Network Kullanımı

docker network create mynet
docker run -dit --name a --network mynet busybox
docker run -dit --name b --network mynet busybox

Ping testi:

docker exec -it a ping b

Container’lar aynı custom bridge üzerinde DNS ile birbirlerine ulaşabilir.

7.6 Özet İpuçları

• Default bridge hızlı başlamak için uygundur ama DNS çözümleme özelliği sınırlıdır.
• Custom bridge izolasyon ve DNS desteği sağlar.
• Host networking performans avantajı sağlar ama Linux dışındaki platformlarda sınırlıdır.
• Overlay network multi-host senaryolarında çok kullanışlıdır.
• macvlan ve transparent networks fiziksel ağ entegrasyonu gereken durumlarda tercih edilir.

8. Docker Swarm / Stack (Native Orchestrator)

Docker Swarm, 2.7’de kısa tanıttık. Şimdi gerçek dünya kullanımı için detaylı bir rehber hazırlayalım.

Docker Swarm, Docker’ın yerleşik orkestrasyon aracıdır. Birden fazla sunucuyu (node) tek bir cluster olarak yönetir, konteynerleri otomatik dağıtır, ölçeklendirir ve arıza durumlarında yük dengelemesi yapar.

Ne zaman kullanılır?

• Küçük-orta ölçekli projeler
• Kubernetes’ten daha basit bir yapı isteyenler
• Hızlı prototip ve test ortamları
• Docker’a zaten aşina olan ekipler

Kubernetes ile farkı:

• Swarm daha basit, kurulumu ve yönetimi kolay
• Kubernetes daha güçlü ama karmaşık
• Swarm, Docker ekosistemiyle tam entegre

8.1 Swarm Cluster Kurulumu ve Servis Yönetimi

8.1.1 Swarm Başlatma (docker swarm init)

Manager Node Kurulumu:

docker swarm init --advertise-addr 192.168.1.10

Açıklama:

• --advertise-addr: Bu node’un IP adresi. Diğer node’lar bu IP üzerinden bağlanacak.
• Komut çalıştıktan sonra bir join token verir.

Çıktı örneği:

Swarm initialized: current node (abc123) is now a manager.

To add a worker to this swarm, run the following command:

    docker swarm join --token SWMTKN-1-xxxxx 192.168.1.10:2377

8.1.2 Worker Node Ekleme

Worker node’da şu komutu çalıştır:

docker swarm join --token SWMTKN-1-xxxxx 192.168.1.10:2377

Node’ları kontrol etme (manager’da):

docker node ls

Çıktı:

ID                HOSTNAME   STATUS    AVAILABILITY   MANAGER STATUS
abc123 *          node1      Ready     Active         Leader
def456            node2      Ready     Active

8.1.3 Servis Oluşturma (docker service create)

Basit bir web servisi:

docker service create \
  --name myweb \
  --replicas 3 \
  --publish 80:80 \
  nginx:alpine

Parametreler:

• --name: Servis adı
• --replicas: Kaç konteyner kopyası çalışacak
• --publish: Port yönlendirme (host:container)

Servis durumunu kontrol:

docker service ls
docker service ps myweb

Çıktı:

ID            NAME       IMAGE         NODE    DESIRED STATE  CURRENT STATE
abc1          myweb.1    nginx:alpine  node1   Running        Running 2 mins
abc2          myweb.2    nginx:alpine  node2   Running        Running 2 mins
abc3          myweb.3    nginx:alpine  node1   Running        Running 2 mins

8.1.4 Servis Güncelleme

Image güncelleme:

docker service update --image nginx:latest myweb

Replika sayısını değiştirme:

docker service scale myweb=5

Port ekleme:

docker service update --publish-add 8080:80 myweb

8.1.5 Servis Silme

docker service rm myweb

8.2 Replication, Rolling Update, Constraints, Configs & Secrets

8.2.1 Replication (Çoklama)

Swarm, belirlenen sayıda replika çalıştırır. Bir konteyner çökerse otomatik yenisini başlatır.

Manuel scaling:

docker service scale myweb=10

Otomatik yük dengeleme: Swarm, gelen istekleri tüm replikalara dağıtır.

8.2.2 Rolling Update (Sıfır Kesinti Güncellemesi)

Servisleri kesintisiz güncellemek için rolling update kullanılır.

Örnek: Nginx 1.20’den 1.21’e geçiş

docker service update \
  --image nginx:1.21-alpine \
  --update-delay 10s \
  --update-parallelism 2 \
  myweb

Parametreler:

• --update-delay: Her güncelleme arasında bekleme süresi
• --update-parallelism: Aynı anda kaç konteyner güncellenecek

Rollback (Geri alma):

docker service rollback myweb

8.2.3 Constraints (Yerleştirme Kısıtları)

Belirli node’larda servis çalıştırmak için constraint kullanılır.

Örnek: Sadece “production” etiketli node’larda çalışsın

docker service create \
  --name prodapp \
  --constraint 'node.labels.env==production' \
  nginx:alpine

Node’a etiket ekleme:

docker node update --label-add env=production node2

Örnek: Manager node’larda çalıştırma

docker service create \
  --name monitoring \
  --constraint 'node.role==manager' \
  --mode global \
  prometheus

8.2.4 Configs (Yapılandırma Dosyaları)

Swarm, hassas olmayan yapılandırma dosyalarını config olarak saklar.

Config oluşturma:

echo "server { listen 80; }" > nginx.conf
docker config create nginx_config nginx.conf

Serviste kullanma:

docker service create \
  --name web \
  --config source=nginx_config,target=/etc/nginx/nginx.conf \
  nginx:alpine

Config’leri listeleme:

docker config ls

8.2.5 Secrets (Şifre Yönetimi)

Secrets, hassas bilgileri (şifreler, API anahtarları) güvenli şekilde saklar.

Secret oluşturma:

echo "myDBpassword" | docker secret create db_password -

Serviste kullanma:

docker service create \
  --name myapp \
  --secret db_password \
  myimage

Konteyner içinde erişim:

cat /run/secrets/db_password

Secret’ler şifrelenir ve sadece yetkili konteynerler erişebilir.

Secret’leri listeleme:

docker secret ls

Secret silme:

docker secret rm db_password

8.3 Compose ile Swarm: Migration (Geçiş)

Docker Compose dosyaları, küçük değişikliklerle Swarm’da kullanılabilir.

8.3.1 Compose’dan Stack’e Geçiş

docker-compose.yml (Development):

version: "3.8"

services:
  web:
    image: nginx:alpine
    ports:
      - "80:80"
    volumes:
      - ./html:/usr/share/nginx/html
    depends_on:
      - db

  db:
    image: postgres:15
    environment:
      POSTGRES_PASSWORD: secret
    volumes:
      - db_data:/var/lib/postgresql/data

volumes:
  db_data:

docker-stack.yml (Production - Swarm):

version: "3.8"

services:
  web:
    image: nginx:alpine
    ports:
      - "80:80"
    deploy:
      replicas: 3
      update_config:
        parallelism: 1
        delay: 10s
      restart_policy:
        condition: on-failure
    networks:
      - webnet

  db:
    image: postgres:15
    environment:
      POSTGRES_PASSWORD_FILE: /run/secrets/db_password
    secrets:
      - db_password
    volumes:
      - db_data:/var/lib/postgresql/data
    deploy:
      replicas: 1
      placement:
        constraints:
          - node.role == manager
    networks:
      - webnet

volumes:
  db_data:

secrets:
  db_password:
    external: true

networks:
  webnet:
    driver: overlay

Farklar:

• deploy bölümü eklendi (replicas, update_config, placement)
• depends_on kaldırıldı (Swarm’da çalışmaz)
• secrets kullanıldı
• Network driver overlay olarak değiştirildi

8.3.2 Stack Deploy

Secret oluşturma:

echo "myDBpassword" | docker secret create db_password -

Stack’i deploy etme:

docker stack deploy -c docker-stack.yml myapp

Stack durumunu kontrol:

docker stack ls
docker stack services myapp
docker stack ps myapp

Stack’i kaldırma:

docker stack rm myapp

8.4 Pratik Örnekler

Örnek 1: WordPress + MySQL Stack

stack.yml:

version: "3.8"

services:
  wordpress:
    image: wordpress:latest
    ports:
      - "8080:80"
    environment:
      WORDPRESS_DB_HOST: db
      WORDPRESS_DB_USER: wordpress
      WORDPRESS_DB_PASSWORD_FILE: /run/secrets/db_password
      WORDPRESS_DB_NAME: wordpress
    secrets:
      - db_password
    deploy:
      replicas: 2
    networks:
      - wpnet

  db:
    image: mysql:8
    environment:
      MYSQL_ROOT_PASSWORD_FILE: /run/secrets/db_password
      MYSQL_DATABASE: wordpress
      MYSQL_USER: wordpress
      MYSQL_PASSWORD_FILE: /run/secrets/db_password
    secrets:
      - db_password
    volumes:
      - db_data:/var/lib/mysql
    deploy:
      replicas: 1
      placement:
        constraints:
          - node.role == manager
    networks:
      - wpnet

volumes:
  db_data:

secrets:
  db_password:
    external: true

networks:
  wpnet:
    driver: overlay

Deploy:

echo "mySecretPassword123" | docker secret create db_password -
docker stack deploy -c stack.yml wordpress

Örnek 2: Load Balancer + API

version: "3.8"

services:
  nginx:
    image: nginx:alpine
    ports:
      - "80:80"
    configs:
      - source: nginx_config
        target: /etc/nginx/nginx.conf
    deploy:
      replicas: 1
    networks:
      - frontend

  api:
    image: myapi:latest
    deploy:
      replicas: 5
      update_config:
        parallelism: 2
        delay: 10s
    networks:
      - frontend

configs:
  nginx_config:
    external: true

networks:
  frontend:
    driver: overlay

8.5 Swarm Komutları Özet

8.6 Özet ve İleri Okuma

Docker Swarm, kolay kurulum ve yönetim sunar. Kubernetes’e geçmeden önce ideal bir orkestrasyon çözümüdür.

Avantajları:

• Docker ile tam entegre
• Basit komutlar
• Hızlı kurulum
• Yerleşik load balancing

Dezavantajları:

• Büyük ölçekli projelerde Kubernetes kadar güçlü değil
• Topluluk desteği daha az

Ne zaman kullanılır?

• 10-50 node arası cluster’lar
• Hızlı prototipleme
• Docker’a aşina ekipler

İleri Okuma:

• Docker Swarm Documentation
• Swarm Mode Tutorial

9. Kubernetes ile Karşılaştırma

Docker Swarm’ı öğrendikten sonra orkestrasyon araçları arasındaki farkları anlamak önemlidir. Bu bölümde Docker Compose, Swarm ve Kubernetes’in teknik karşılaştırmasını yapacağız ve hangi senaryoda hangi aracın tercih edilmesi gerektiğini inceleyeceğiz.

9.1 Orkestrasyon Araçlarının Genel Bakışı

Docker ekosisteminde üç temel orkestrasyon yaklaşımı bulunur. Docker Compose tek sunucuda birden fazla konteyneri yönetirken, Docker Swarm birden fazla sunucuyu cluster olarak yönetir ve Kubernetes ise büyük ölçekli, karmaşık sistemler için tasarlanmış güçlü bir orkestrasyon platformudur.

Her birinin farklı kullanım senaryoları ve karmaşıklık seviyeleri vardır. Docker Compose geliştirme ortamları için idealdir, Docker Swarm küçük ve orta ölçekli production ortamları için yeterlidir, Kubernetes ise büyük ölçekli ve karmaşık sistemler için en uygun seçenektir.

Kullanım Alanları ve Ölçek

9.2 Teknik Özellik Karşılaştırması

Her üç aracın da farklı teknik özellikleri ve yetenekleri vardır. Kurulum süresi, öğrenme eğrisi, ölçekleme yetenekleri ve diğer önemli özellikler aşağıdaki tabloda karşılaştırılmıştır.

Docker Compose’un en büyük avantajı basitliğidir ancak tek sunucu ile sınırlıdır. Docker Swarm, Docker CLI ile tam entegre çalışır ve Compose dosyalarıyla uyumludur. Kubernetes ise en güçlü özelliklere sahip olmakla birlikte en karmaşık yapıya sahiptir.

9.3 Avantajlar ve Dezavantajlar

Docker Compose

Docker Compose, yerel geliştirme ve tek sunuculu uygulamalar için tasarlanmış basit bir araçtır. YAML dosyası son derece okunabilir ve anlaşılır bir yapıya sahiptir. Tek bir komutla tüm sistemi ayağa kaldırabilir, geliştirme sürecini hızlandırır. Öğrenmesi çok kolaydır ve hızlı prototipleme için idealdir.

Ancak bazı önemli sınırlamaları vardır. Tek sunucu ile sınırlı olduğu için büyüyen projeler için uygun değildir. Otomatik ölçekleme özelliği yoktur ve load balancing işlemleri manuel olarak yapılmalıdır. Production ortamları için yetersizdir ve multi-host desteği bulunmamaktadır.

Uygun Olduğu Durumlar: Geliştirme ortamları, tek sunuculu uygulamalar, MVP ve prototip projeler için idealdir.

Docker Swarm

Docker Swarm, Docker ekosisteminin doğal bir parçası olarak tasarlanmıştır. Docker CLI ile tam entegre çalışır ve mevcut Docker bilginizi kullanarak kolayca öğrenebilirsiniz. Compose dosyalarınızı küçük değişikliklerle Swarm’da kullanabilirsiniz. Kurulumu yaklaşık 5 dakika sürer ve yerleşik load balancing özelliğine sahiptir. Öğrenme eğrisi Kubernetes’e göre çok daha düşüktür.

Bununla birlikte bazı kısıtlamaları vardır. Ölçekleme kapasitesi Kubernetes kadar güçlü değildir. Auto-scaling gibi gelişmiş özellikler basit seviyededir. Topluluk desteği Kubernetes’e göre daha azdır ve cloud provider entegrasyonu sınırlıdır.

Uygun Olduğu Durumlar: 5-50 sunuculu yapılar, Docker bilgisi olan ekipler, orta ölçekli production ortamları ve basit mikroservis mimarileri için uygundur.

Kubernetes

Kubernetes, container orkestrasyon dünyasının en güçlü ve kapsamlı platformudur. HPA (Horizontal Pod Autoscaler) ve VPA (Vertical Pod Autoscaler) gibi güçlü otomatik ölçekleme mekanizmalarına sahiptir. Self-healing yetenekleri sayesinde arızalanan pod’ları otomatik olarak yeniden başlatır. Canary ve blue-green gibi gelişmiş deployment stratejilerini destekler. Çok büyük bir topluluk ve ekosisteme sahiptir. AWS EKS, Google GKE ve Azure AKS gibi tüm büyük cloud provider’lar tarafından tam olarak desteklenir. Istio ve Linkerd gibi service mesh araçlarıyla entegre çalışabilir.

Ancak bu güçlü özellikler bazı maliyetlerle gelir. Kurulum ve yapılandırma karmaşıktır, saatler sürebilir. Öğrenme eğrisi çok diktir, 1-3 ay gibi bir süre gerektirebilir. Master node’lar nedeniyle kaynak tüketimi yüksektir. Yönetim maliyeti ve operasyonel karmaşıklık fazladır. Küçük projeler için aşırı karmaşık bir çözümdür (overkill).

Uygun Olduğu Durumlar: 50+ sunuculu yapılar, karmaşık mikroservis mimarileri, multi-cloud stratejileri ve yüksek trafikli uygulamalar için en uygun seçenektir.

9.4 Compose’dan Kubernetes’e Geçiş

Docker Compose dosyalarınızı Kubernetes’e taşımak için iki yöntem kullanabilirsiniz: otomatik dönüştürme aracı Kompose veya manuel dönüştürme. Kompose aracı, mevcut Compose dosyalarınızı Kubernetes YAML formatına otomatik olarak çevirir.

Kompose Aracı ile Otomatik Dönüştürme

Kompose aracını Linux, macOS veya Windows üzerinde kurabilirsiniz. Linux için curl komutuyla binary dosyayı indirip çalıştırılabilir hale getirmeniz yeterlidir. macOS’ta Homebrew ile, Windows’ta ise Chocolatey ile kurulum yapabilirsiniz.

Kurulum:

# Linux
curl -L https://github.com/kubernetes/kompose/releases/download/v1.31.0/kompose-linux-amd64 -o kompose
chmod +x kompose
sudo mv ./kompose /usr/local/bin/kompose

# macOS
brew install kompose

# Windows
choco install kompose

Kurulum tamamlandıktan sonra mevcut docker-compose.yml dosyanızı dönüştürmek için kompose convert komutunu kullanabilirsiniz. Bu komut, Compose dosyanızı analiz eder ve karşılık gelen Kubernetes Service, Deployment ve PersistentVolumeClaim dosyalarını oluşturur.

Dönüştürme:

kompose convert -f docker-compose.yml

Kompose, her servis için ayrı YAML dosyaları oluşturur. Örneğin bir web servisi için hem Service hem de Deployment dosyası, bir veritabanı için ise ek olarak PersistentVolumeClaim dosyası oluşturulur.

Çıktı:

INFO Kubernetes file "web-service.yaml" created
INFO Kubernetes file "web-deployment.yaml" created
INFO Kubernetes file "db-persistentvolumeclaim.yaml" created

Oluşturulan dosyaları Kubernetes cluster’ınıza deploy etmek için kubectl aracını kullanabilirsiniz. Apply komutu, bulunduğunuz dizindeki tüm YAML dosyalarını okur ve cluster’a uygular.

Deploy:

kubectl apply -f .

Manuel Dönüştürme Örneği

Bazen otomatik dönüştürme yetersiz kalabilir veya daha fazla kontrol isteyebilirsiniz. Bu durumda manuel dönüştürme yapmanız gerekir. Aşağıda basit bir Docker Compose dosyasının Kubernetes eşdeğerine nasıl çevrileceğini görebilirsiniz.

Docker Compose’da bir servisi tanımlamak çok basittir. Image adını, replika sayısını ve port yönlendirmesini belirtmeniz yeterlidir. Ancak Kubernetes’te aynı işlevi gerçekleştirmek için hem Deployment hem de Service nesnesi oluşturmanız gerekir.

Docker Compose:

version: "3.8"

services:
  web:
    image: nginx:alpine
    replicas: 3
    ports:
      - "80:80"

Kubernetes Deployment objesi, kaç pod çalışacağını, hangi image kullanılacağını ve pod’ların nasıl etiketleneceğini tanımlar. Service objesi ise bu pod’lara dışarıdan erişimi sağlar ve load balancing yapar. LoadBalancer tipi service, cloud provider’dan otomatik olarak bir external IP alır.

Kubernetes Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: web
        image: nginx:alpine
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  type: LoadBalancer
  ports:
  - port: 80
    targetPort: 80
  selector:
    app: web

9.5 Senaryo Bazlı Öneriler

Farklı proje büyüklükleri ve gereksinimleri için farklı araçlar daha uygun olabilir. Aşağıdaki tablo, yaygın senaryolar için önerilen orkestrasyon araçlarını ve gerekçelerini göstermektedir.

Basit bir blog sitesi gibi küçük projelerde Docker Compose yeterlidir. Startup MVP’ler için Compose ile başlayıp büyüdükçe Swarm’a geçiş yapılabilir. Orta ölçekli e-ticaret siteleri için Swarm’ın otomatik ölçekleme ve load balancing özellikleri yeterlidir. Binlerce kullanıcılı SaaS platformları ise Kubernetes’in güçlü özelliklerini gerektirir.

9.6 Geçiş Yol Haritası

Bir orkestrasyon aracından diğerine geçiş aşamalı olarak yapılmalıdır. Her aşamada sisteminizin ihtiyaçlarını ve ekibinizin yeteneklerini değerlendirerek ilerlemeniz önemlidir.

İlk aşamada geliştirme ortamınızda Docker Compose kullanarak başlamalısınız. Bu aşamada basit bir YAML dosyası ile yerel geliştirme ortamınızı kolayca yönetebilirsiniz. Build direktifi sayesinde Dockerfile’ınızdan otomatik olarak image oluşturulur.

Aşama 1: Geliştirme (Docker Compose)

version: "3.8"
services:
  web:
    build: .
    ports:
      - "80:80"

Projeniz büyüdükçe ve birden fazla sunucuya ihtiyaç duymaya başladığınızda Docker Swarm’a geçiş yapabilirsiniz. Bu aşamada Compose dosyanızı küçük değişikliklerle Swarm stack dosyasına dönüştürürsünüz. Build yerine hazır image kullanır, deploy bölümünde replika sayısını ve güncelleme stratejisini belirtirsiniz.

Aşama 2: Orta Ölçek (Docker Swarm)

version: "3.8"
services:
  web:
    image: myapp:latest
    deploy:
      replicas: 3
      update_config:
        parallelism: 1
    ports:
      - "80:80"

Projeniz çok daha büyüdüğünde ve karmaşık mikroservis mimarisine geçtiğinizde Kubernetes’e migration yapabilirsiniz. Bu noktada Kompose aracını kullanarak mevcut stack dosyanızı Kubernetes YAML’ine çevirebilir veya sıfırdan Kubernetes manifestleri yazabilirsiniz.

Aşama 3: Büyük Ölçek (Kubernetes)

kompose convert -f docker-stack.yml
kubectl apply -f .

Her geçiş aşamasında sisteminizi test etmeli ve ekibinizin yeni araca adapte olması için zaman tanımalısınız. Aşamalı geçiş, riskleri minimize eder ve sorunları erkenden tespit etmenizi sağlar.

10. Güvenlik

Docker konteynerleri, uygulamalarınızı izole eder ancak bu izolasyon tek başına yeterli değildir. Güvenlik, Docker kullanımının en kritik yönlerinden biridir. Bu bölümde konteyner güvenliğini artırmak için kullanabileceğiniz araçları, teknikleri ve en iyi uygulamaları öğreneceksiniz.

Konteynerler varsayılan olarak bazı güvenlik özellikleriyle gelir ancak production ortamlarında ek güvenlik katmanları eklemeniz şarttır. Özellikle hassas verileri işleyen uygulamalarda, güvenlik açıklarını minimum seviyeye indirmek için çeşitli yöntemler uygulamalısınız.

10.1 Rootless Docker (Linux)

Normal Docker kurulumunda daemon root yetkisiyle çalışır. Bu, bir güvenlik açığı oluşturabilir çünkü konteyner içinden çıkış yapılırsa (container escape) saldırgan root erişimi kazanabilir. Rootless Docker, bu riski ortadan kaldırmak için daemon’u root olmayan bir kullanıcı ile çalıştırır.

Rootless Docker’ın mantığı şudur: daemon ve konteynerler normal kullanıcı yetkileriyle çalışır, böylece bir güvenlik açığı olsa bile saldırgan sadece o kullanıcının yetkilerine sahip olur, sistem genelinde root erişimi kazanamaz.

Rootless Docker Kurulumu (Ubuntu/Debian)

Öncelikle normal Docker daemon’unu durdurmanız gerekir. Ardından rootless kurulum scriptini çalıştırırsınız. Bu script gerekli ayarları yapar ve Docker’ı kullanıcı modu ile başlatır.

# Mevcut Docker'ı durdur
sudo systemctl disable --now docker.service docker.socket

# Rootless kurulum scriptini çalıştır
curl -fsSL https://get.docker.com/rootless | sh

# Ortam değişkenlerini ayarla
export PATH=/home/$USER/bin:$PATH
export DOCKER_HOST=unix:///run/user/$(id -u)/docker.sock

Kurulum tamamlandıktan sonra Docker komutlarını sudo olmadan çalıştırabilirsiniz. Daemon artık normal kullanıcı yetkileriyle çalışır ve konteynerler de aynı şekilde root yetkisi olmadan çalışır.

Rootless Docker’ın Avantajları ve Kısıtlamaları

Rootless Docker kullanmanın en büyük avantajı güvenliktir. Container escape senaryolarında bile saldırgan root erişimi kazanamaz. Ayrıca çok kullanıcılı sistemlerde her kullanıcı kendi Docker daemon’unu çalıştırabilir.

Ancak bazı kısıtlamaları vardır. 1024’ten küçük portları (80, 443 gibi) doğrudan bağlayamazsınız, bunun yerine port yönlendirme kullanmanız gerekir. Bazı storage driver’lar (overlay2 vb.) çalışmayabilir. Performans standart Docker’a göre biraz daha düşük olabilir.

10.2 Linux Güvenlik Modülleri (Seccomp, AppArmor, SELinux)

Linux işletim sistemi, konteynerleri korumak için çeşitli güvenlik modülleri sunar. Bu modüller, konteynerlerin yapabileceklerini kısıtlar ve zararlı aktiviteleri engeller. Her biri farklı bir yaklaşımla güvenlik sağlar.

Seccomp (Secure Computing Mode)

Seccomp, konteynerin hangi sistem çağrılarını (system calls) yapabileceğini kontrol eder. Sistem çağrıları, bir programın işletim sisteminden bir şey talep etmesidir. Örneğin dosya okuma, network bağlantısı kurma veya yeni process başlatma sistem çağrılarıdır.

Docker varsayılan olarak bir seccomp profili kullanır ve tehlikeli sistem çağrılarını engeller. Örneğin reboot, swapon, mount gibi sistem çağrıları varsayılan olarak engellidir.

Kendi seccomp profilinizi de oluşturabilirsiniz. Aşağıda sadece read, write ve exit sistem çağrılarına izin veren bir profil örneği görüyorsunuz.

Örnek seccomp profili (seccomp.json):

{
  "defaultAction": "SCMP_ACT_ERRNO",
  "architectures": ["SCMP_ARCH_X86_64"],
  "syscalls": [
    {
      "names": ["read", "write", "exit", "exit_group"],
      "action": "SCMP_ACT_ALLOW"
    }
  ]
}

Bu profili kullanarak bir konteyner başlatmak için:

docker run --security-opt seccomp=seccomp.json myimage

AppArmor

AppArmor, konteynerlerin dosya sistemine, network’e ve diğer kaynaklara erişimini kontrol eder. Ubuntu ve Debian sistemlerinde varsayılan olarak kuludur.

Docker otomatik olarak docker-default adlı bir AppArmor profili kullanır. Bu profil konteynerin hassas sistem dizinlerine yazmasını engeller, örneğin /sys, /proc gibi dizinler korunur.

Kendi AppArmor profilinizi de oluşturabilirsiniz. Örneğin sadece /tmp dizinine yazma izni veren bir profil:

# AppArmor profili oluştur (/etc/apparmor.d/docker-nginx)
profile docker-nginx flags=(attach_disconnected,mediate_deleted) {
  #include <abstractions/base>
  file,
  /tmp/** rw,
  deny /proc/** w,
  deny /sys/** w,
}

# Profili yükle
sudo apparmor_parser -r -W /etc/apparmor.d/docker-nginx

# Konteyner başlatırken kullan
docker run --security-opt apparmor=docker-nginx nginx

SELinux

SELinux (Security-Enhanced Linux), Red Hat, CentOS ve Fedora sistemlerinde kullanılan güvenlik modülüdür. AppArmor’a benzer şekilde çalışır ancak daha karmaşık ve güçlüdür.

SELinux her dosyaya, process’e ve network portuna bir etiket (label) atar. Konteynerler varsayılan olarak svirt_lxc_net_t etiketiyle çalışır ve sadece svirt_sandbox_file_t etiketli dosyalara erişebilir.

Daha önce Bölüm 6’da gördüğünüz :Z etiketi de SELinux ile ilgilidir. Volume mount ederken :Z kullanırsanız, Docker o dizine otomatik olarak konteyner erişimi için doğru etiketi atar.

docker run -v /mydata:/data:Z myimage

Kernel Capabilities

Linux kernel, root yetkilerini küçük parçalara böler. Bu parçalara “capability” denir. Örneğin network ayarlarını değiştirmek için CAP_NET_ADMIN, dosya sahipliğini değiştirmek için CAP_CHOWN capability’si gerekir.

Docker varsayılan olarak konteynerlere sınırlı sayıda capability verir. Gereksiz capability’leri kaldırarak güvenliği artırabilirsiniz.

Tüm capability’leri kaldırma:

docker run --cap-drop=ALL myimage

Sadece belirli capability’leri verme:

docker run --cap-drop=ALL --cap-add=NET_BIND_SERVICE myimage

Bu örnekte tüm capability’ler kaldırılıyor ve sadece NET_BIND_SERVICE (1024’ten küçük portlara bind olma) veriliyor.

10.3 Image Tarama ve Güvenlik Araçları

Konteyner güvenliğinin önemli bir parçası da kullandığınız image’lerin güvenli olmasıdır. Image’ler içinde güvenlik açıkları (vulnerabilities) olabilir. Bu açıkları tespit etmek için image tarama araçları kullanılır.

Docker Bench for Security

Docker Bench for Security, Docker kurulumunuzu en iyi güvenlik pratiklerine göre kontrol eden otomatik bir scripttir. CIS Docker Benchmark standartlarını kontrol eder.

Kurulum ve kullanım:

git clone https://github.com/docker/docker-bench-security.git
cd docker-bench-security
sudo sh docker-bench-security.sh

Script çalıştırıldığında yüzlerce kontrol yapar ve sonuçları raporlar. Her kontrol için PASS, WARN veya INFO durumu verir.

Örnek çıktı:

[PASS] 1.1.1 - Ensure a separate partition for containers has been created
[WARN] 1.2.1 - Ensure Docker daemon is not running with experimental features
[INFO] 2.1 - Restrict network traffic between containers

WARN durumundaki uyarıları mutlaka incelemelisiniz. Bunlar potansiyel güvenlik sorunlarını gösterir.

Trivy ile Image Tarama

Trivy, Docker image’lerindeki güvenlik açıklarını tespit eden açık kaynaklı bir araçtır. Kullanımı çok basittir ve hızlı sonuç verir.

Kurulum:

# Linux
wget -qO - https://aquasecurity.github.io/trivy-repo/deb/public.key | sudo apt-key add -
echo "deb https://aquasecurity.github.io/trivy-repo/deb $(lsb_release -sc) main" | sudo tee -a /etc/apt/sources.list.d/trivy.list
sudo apt update
sudo apt install trivy

# macOS
brew install trivy

Image tarama:

trivy image nginx:latest

Trivy, image içindeki tüm paketleri kontrol eder ve bilinen güvenlik açıklarını listeler. Her açık için CVE numarası, şiddet seviyesi (CRITICAL, HIGH, MEDIUM, LOW) ve çözüm önerisi gösterir.

Örnek çıktı:

nginx:latest (debian 11.6)
==========================
Total: 45 (CRITICAL: 5, HIGH: 12, MEDIUM: 20, LOW: 8)

┌───────────────┬────────────────┬──────────┬────────┬─────────────────────┐
│   Library     │ Vulnerability  │ Severity │ Status │    Fixed Version    │
├───────────────┼────────────────┼──────────┼────────┼─────────────────────┤
│ openssl       │ CVE-2023-12345 │ CRITICAL │ fixed  │ 1.1.1w-1            │
│ curl          │ CVE-2023-54321 │ HIGH     │ fixed  │ 7.88.1-1            │
└───────────────┴────────────────┴──────────┴────────┴─────────────────────┘

CRITICAL ve HIGH seviyedeki açıkları mutlaka düzeltmelisiniz. Bunun için genellikle image’i güncellemeniz veya farklı bir base image kullanmanız gerekir.

Diğer Image Tarama Araçları

Trivy dışında başka araçlar da vardır:

10.4 Secrets Yönetimi

Şifreler, API anahtarları, sertifikalar gibi hassas bilgileri (secrets) konteyner içinde güvenli şekilde saklamak kritiktir. Asla bu bilgileri Dockerfile’a veya image’e hard-code etmemelisiniz.

Docker Swarm Secrets

Docker Swarm, secrets için yerleşik bir sistem sunar. Secrets şifrelenerek saklanır ve sadece yetkili konteynerlere mount edilir.

Secret oluşturma:

# Dosyadan secret oluşturma
echo "myDBpassword123" | docker secret create db_password -

# Dosyadan secret oluşturma
docker secret create db_config /path/to/config.json

Serviste secret kullanma:

docker service create \
  --name myapp \
  --secret db_password \
  myimage

Konteyner içinde secret /run/secrets/ dizininde dosya olarak görünür:

# Konteyner içinde
cat /run/secrets/db_password
# Çıktı: myDBpassword123

Docker Compose ile secret kullanımı:

version: "3.8"

services:
  web:
    image: myapp
    secrets:
      - db_password

secrets:
  db_password:
    external: true

Environment Variables ile Secret (Önerilmez)

Bazı durumlarda environment variable kullanmak zorunda kalabilirsiniz ancak bu yöntem güvenli değildir. Environment variable’lar docker inspect ile görülebilir.

docker run -e DB_PASSWORD=secret123 myimage

Bu yöntem yerine mutlaka Docker secrets veya Vault kullanmalısınız.

HashiCorp Vault Entegrasyonu

Production ortamlarında daha gelişmiş secret yönetimi için HashiCorp Vault kullanılabilir. Vault, secrets’ı merkezi bir yerde saklar, şifreler ve erişim kontrolü sağlar.

Vault’un temel çalışma mantığı şudur: uygulamanız başladığında Vault’tan token alır, bu token ile secrets’ı çeker ve kullanır. Secrets asla image içinde veya environment variable’da saklanmaz.

Basit Vault kullanım örneği:

# Vault'a secret yazma
vault kv put secret/db password=myDBpassword

# Konteyner içinden secret okuma
vault kv get -field=password secret/db

Vault entegrasyonu için genellikle bir init container veya sidecar pattern kullanılır. Bu konular daha ileri seviye olduğu için burada detaya girmiyoruz.

10.5 Container Hardening Pratikleri

Konteynerlerinizi güvenli hale getirmek için uygulamanız gereken pratikler vardır. Bu pratikler savunmanızı katmanlı hale getirir (defense in depth).

USER Direktifi Kullanımı

Dockerfile’da varsayılan olarak konteyner root kullanıcısı ile çalışır. Bu büyük bir güvenlik riskidir. Mutlaka non-root kullanıcı ile çalıştırmalısınız.

Kötü örnek:

FROM node:18
WORKDIR /app
COPY . .
CMD ["node", "app.js"]
# Root olarak çalışıyor!

İyi örnek:

FROM node:18
WORKDIR /app
COPY . .

# Non-root kullanıcı oluştur
RUN useradd -m -u 1001 appuser && \
    chown -R appuser:appuser /app

# Bu kullanıcıya geç
USER appuser

CMD ["node", "app.js"]

Artık konteyner appuser ile çalışır. Bir güvenlik açığı olsa bile saldırgan root yetkisi kazanamaz.

Read-Only Filesystem

Konteynerin filesystem’ini read-only yaparak saldırganın zararlı dosya yazmasını engelleyebilirsiniz.

docker run --read-only --tmpfs /tmp myimage

Uygulama geçici dosyalar yazmak zorundaysa tmpfs kullanabilirsiniz. tmpfs RAM’de çalışır ve konteyner kapandığında silinir.

Docker Compose ile:

services:
  web:
    image: myapp
    read_only: true
    tmpfs:
      - /tmp

Gereksiz Capability’leri Kaldırma

Daha önce bahsettiğimiz gibi capability’leri kaldırarak saldırganın yapabileceklerini kısıtlayabilirsiniz.

docker run \
  --cap-drop=ALL \
  --cap-add=NET_BIND_SERVICE \
  myimage

Network İzolasyonu

Her konteyner için ayrı network oluşturarak servisleri izole edebilirsiniz. Böylece bir konteyner hack’lense bile diğerlerine erişemez.

# Frontend network
docker network create frontend

# Backend network
docker network create backend

# Web servisi sadece frontend'e bağlı
docker run --network frontend web

# API servisi her ikisine de bağlı
docker run --network frontend --network backend api

# Database sadece backend'e bağlı
docker run --network backend db

Resource Limitleri

Konteyner kaynak tüketimini sınırlandırarak DoS (Denial of Service) saldırılarını engelleyebilirsiniz.

docker run \
  --memory="512m" \
  --cpus="1.0" \
  --pids-limit=100 \
  myimage

Bu limitler sayesinde bir konteyner tüm sistemi çökertmez.

Image Güncelliği

Kullandığınız base image’leri düzenli olarak güncellemelisiniz. Eski image’ler bilinen güvenlik açıkları içerebilir.

# Image'leri güncelle
docker pull nginx:latest
docker pull node:18-alpine

Ayrıca production’da latest tag’i yerine belirli versiyonlar kullanmalısınız:

# Kötü
FROM node:latest

# İyi
FROM node:18.19.0-alpine

Güvenlik Kontrol Listesi

Konteyner güvenliği için uygulamanız gereken temel pratiklerin özeti:

Dockerfile Güvenliği:

• Non-root kullanıcı kullan (USER direktifi)
• Minimal base image seç (alpine, distroless)
• Multi-stage build ile gereksiz araçları kaldır
• Secrets’ı image’e gömme
• Belirli image versiyonları kullan (latest değil)

Runtime Güvenliği:

• Rootless Docker kullan
• Read-only filesystem aktif et
• Gereksiz capability’leri kaldır
• Resource limitleri belirle
• Network izolasyonu yap
• Seccomp/AppArmor/SELinux kullan

Image Güvenliği:

• Düzenli image tarama yap (Trivy)
• Base image’leri güncelle
• Docker Bench for Security çalıştır
• Sadece güvenilir registry’lerden image çek

Secrets Yönetimi:

• Docker Swarm secrets veya Vault kullan
• Environment variable’da secret saklama
• Secrets’ı logla
• Secrets’ı version control’e koyma

Bu pratikleri uyguladığınızda konteynerlerinizin güvenliği önemli ölçüde artar. Güvenlik katmanlı bir yaklaşım gerektirir, tek bir yöntem yeterli olmaz.

11. Kaynak Kısıtları & Performans Yönetimi

Docker konteynerleri varsayılan olarak host sistemin tüm kaynaklarını kullanabilir. Bu durumda bir konteyner tüm CPU’yu veya RAM’i tüketebilir ve diğer konteynerlerin veya sistemin çökmesine neden olabilir. Kaynak kısıtlamaları belirlemek, hem sistem kararlılığı hem de performans için kritiktir.

Bu bölümde konteynerlere kaynak limitleri nasıl koyulur, Linux’un bu limitleri nasıl uyguladığı ve farklı platformlarda kaynak yönetiminin nasıl yapıldığını öğreneceksiniz.

11.1 Memory ve CPU Limitleri

Docker, konteynerlerin kullanabileceği bellek ve işlemci miktarını sınırlandırmanıza olanak tanır. Bu limitler sayesinde bir konteynerin aşırı kaynak tüketmesini engelleyebilir, sistemin kararlı çalışmasını sağlayabilirsiniz.

Memory (Bellek) Limitleri

Bellek limitleri belirlemek, konteyner çökmelerini ve sistem genelinde bellek tükenmesini önler. Bir konteyner belirlenen limiti aşmaya çalıştığında Linux kernel’i OOM (Out Of Memory) Killer devreye girer ve konteyneri durdurur.

Basit memory limiti:

docker run --memory="512m" nginx

Bu örnekte konteyner maksimum 512 MB RAM kullanabilir. Limit aşılırsa konteyner otomatik olarak kapatılır.

Memory swap ayarı:

docker run --memory="512m" --memory-swap="1g" nginx

--memory-swap parametresi toplam bellek ve swap alanını belirtir. Bu örnekte 512 MB RAM ve 512 MB swap kullanılabilir (1g - 512m = 512m swap).

Swap’ı tamamen kapatma:

docker run --memory="512m" --memory-swap="512m" nginx

Memory ve memory-swap değeri aynı olursa swap kullanımı devre dışı kalır.

Memory reservation (yumuşak limit):

docker run --memory="1g" --memory-reservation="750m" nginx

Memory reservation, konteynerin normal koşullarda kullanması beklenen bellek miktarıdır. Sistem bellek baskısı altındayken Docker bu limiti uygular. Normal koşullarda konteyner daha fazla bellek kullanabilir ancak sistem kaynak sıkıntısı çektiğinde reservation değerine düşürülür.

OOM (Out of Memory) Killer davranışı:

docker run --memory="512m" --oom-kill-disable nginx

--oom-kill-disable parametresi tehlikeli olabilir. Konteyner bellek limitini aşsa bile kapatılmaz, bu durumda host sistem çökebilir. Sadece test ortamlarında kullanılmalıdır.

CPU Limitleri

CPU limitleri, konteynerin ne kadar işlemci gücü kullanabileceğini belirler. Memory’den farklı olarak CPU paylaşımlıdır, yani bir konteyner CPU limitini aşarsa sadece yavaşlar, çökmez.

CPU sayısı limiti:

docker run --cpus="1.5" nginx

Bu konteyner maksimum 1.5 CPU core kullanabilir. Yani tam zamanlı 1 core ve bir diğer core’un yarısını kullanabilir.

CPU share (ağırlık) sistemi:

docker run --cpu-shares=512 --name container1 nginx
docker run --cpu-shares=1024 --name container2 nginx

CPU shares, konteynerlerin CPU’yu nasıl paylaşacağını belirler. Varsayılan değer 1024’tür. Bu örnekte container2, container1’den iki kat daha fazla CPU zamanı alır (1024/512 = 2).

CPU shares sadece sistem yük altındayken devreye girer. Eğer sistem boştaysa tüm konteynerler istedikleri kadar CPU kullanabilir.

Belirli CPU core’lara sabitleme:

docker run --cpuset-cpus="0,1" nginx

Bu konteyner sadece 0 ve 1 numaralı CPU core’larında çalışır. Çok core’lu sistemlerde workload’ı dağıtmak için kullanılır.

CPU period ve quota:

docker run --cpu-period=100000 --cpu-quota=50000 nginx

Bu parametreler daha detaylı CPU kontrolü sağlar. Period, zaman dilimini mikrosaniye cinsinden belirtir (100000 = 100ms). Quota, bu süre içinde konteynerin kaç mikrosaniye CPU kullanabileceğini belirtir. Bu örnekte her 100ms’de 50ms CPU zamanı kullanılabilir, yani %50 CPU.

Pratik Örnekler

Web sunucusu için tipik ayarlar:

docker run -d \
  --name web \
  --memory="512m" \
  --memory-reservation="256m" \
  --cpus="1.0" \
  --restart=unless-stopped \
  nginx

Veritabanı için yüksek kaynak ayarları:

docker run -d \
  --name postgres \
  --memory="2g" \
  --memory-swap="2g" \
  --cpus="2.0" \
  --cpu-shares=1024 \
  postgres:15

Arka plan işi için düşük öncelik:

docker run -d \
  --name background-job \
  --memory="256m" \
  --cpus="0.5" \
  --cpu-shares=512 \
  myworker

Docker Compose ile Kaynak Limitleri

Docker Compose dosyasında kaynak limitlerini deploy bölümünde belirtirsiniz:

version: "3.8"

services:
  web:
    image: nginx
    deploy:
      resources:
        limits:
          cpus: '1.0'
          memory: 512M
        reservations:
          cpus: '0.5'
          memory: 256M

Limits üst limiti, reservations ise minimum garantili kaynakları belirtir.

11.2 Ulimit Ayarları

Ulimit, bir process’in kullanabileceği sistem kaynaklarını sınırlar. Örneğin açık dosya sayısı, process sayısı veya stack boyutu gibi limitler belirleyebilirsiniz.

Ulimit türleri:

Ulimit ayarlama:

docker run --ulimit nofile=1024:2048 nginx

Bu örnekte soft limit 1024, hard limit 2048’dir. Soft limit normal çalışma limiti, hard limit maksimum limit olarak çalışır.

Birden fazla ulimit:

docker run \
  --ulimit nofile=1024:2048 \
  --ulimit nproc=512:1024 \
  myapp

Docker Compose ile:

services:
  web:
    image: myapp
    ulimits:
      nofile:
        soft: 1024
        hard: 2048
      nproc:
        soft: 512
        hard: 1024

Ulimit ayarları özellikle veritabanları ve web sunucuları için önemlidir. Örneğin Nginx ve PostgreSQL çok sayıda dosya açar, bu yüzden nofile limitini artırmanız gerekebilir.

11.3 Linux Cgroups (Control Groups)

Cgroups, Linux kernel’inin kaynak yönetim sistemidir. Docker, konteynerlere kaynak limitleri uygulamak için cgroups kullanır. Her konteyner ayrı bir cgroup içinde çalışır ve belirlenen limitlere göre kaynak alır.

Cgroups v1 vs v2

Linux’ta iki cgroups versiyonu bulunur ve aralarında önemli farklar vardır.

Cgroups v1:

• 2008 yılından beri kullanılıyor
• Her kaynak tipi için ayrı hiyerarşi var (cpu, memory, blkio vb.)
• Daha eski sistemlerde varsayılan
• Karmaşık yapı, bazen çelişkili limitler olabiliyor

Cgroups v2:

• 2016’da tanıtıldı
• Tek birleşik hiyerarşi
• Daha basit ve tutarlı API
• Modern Linux dağıtımlarında varsayılan (Ubuntu 22.04+, Fedora 31+)

Hangi versiyonu kullandığınızı kontrol etme:

stat -fc %T /sys/fs/cgroup/

Çıktı cgroup2fs ise cgroups v2, tmpfs ise v1 kullanıyorsunuz.

Cgroups v2 avantajları:

Cgroups v2’de kaynak limitleri daha tutarlı uygulanır. Örneğin v1’de memory ve CPU limitlerini ayrı ayrı yönetirken çelişkiler oluşabiliyordu. V2’de tüm kaynaklar tek hiyerarşide yönetilir.

Ayrıca v2’de “pressure stall information” (PSI) özelliği var. Bu özellik sayesinde konteynerin ne kadar kaynak baskısı altında olduğunu görebilirsiniz.

Cgroups bilgilerini görüntüleme:

# Konteyner cgroup yolunu bulma
docker inspect --format='{{.State.Pid}}' mycontainer
# Çıktı: 12345

# Cgroup limitlerini görme (v2)
cat /sys/fs/cgroup/system.slice/docker-<container-id>.scope/memory.max
cat /sys/fs/cgroup/system.slice/docker-<container-id>.scope/cpu.max

Çoğu kullanıcı cgroups detaylarıyla uğraşmaz. Docker CLI parametreleri (–memory, –cpus vb.) arka planda cgroups’u otomatik yapılandırır. Ancak özel durumlar veya debugging için cgroups bilgisi faydalıdır.

11.4 Docker Desktop’ta Kaynak Ayarları (Windows/macOS)

Docker Desktop, Windows ve macOS’ta bir sanal makine (VM) üzerinde çalışır. Bu VM’in kendisinin de kaynak limitleri vardır. Konteynerlere ayırdığınız kaynaklar önce bu VM’e, sonra konteynerlere dağıtılır.

Windows’ta Docker Desktop Kaynak Ayarları

Windows’ta Docker Desktop ayarlarını açmak için system tray’deki Docker ikonuna sağ tıklayın ve “Settings” seçin.

Resources bölümünde ayarlayabileceğiniz limitler:

Memory: Docker VM’inin kullanacağı maksimum RAM miktarı. Varsayılan olarak sistemin yarısı kadar RAM ayrılır. Örneğin 16 GB RAM’iniz varsa 8 GB Docker’a ayrılır.

Ayarlanabilir değer: 2 GB ile toplam RAM arasında. Production workload için en az 4-8 GB önerilir.

CPUs: Docker VM’inin kullanacağı CPU core sayısı. Varsayılan olarak tüm core’lar kullanılabilir.

Önerilen değer: Sisteminizin yarısı kadar core. Örneğin 8 core’unuz varsa 4 core Docker’a verin.

Disk: Docker image’leri, volume’lar ve container’ların kullanacağı maksimum disk alanı. Varsayılan 64 GB’dır.

Swap: VM’in kullanacağı swap alanı. Varsayılan 1 GB’dır. Production ortamlarında swap’ı artırmanız önerilir.

WSL2 Entegrasyonu:

Windows’ta WSL2 kullanıyorsanız kaynak yönetimi biraz farklıdır. WSL2 VM’i dinamik olarak kaynak alır ve bırakır.

WSL2 için manuel limit belirlemek isterseniz %UserProfile%\.wslconfig dosyası oluşturun:

[wsl2]
memory=8GB
processors=4
swap=2GB

Bu ayarları uygulamak için WSL’i yeniden başlatın:

wsl --shutdown

macOS’ta Docker Desktop Kaynak Ayarları

macOS’ta da benzer şekilde Docker Desktop Settings > Resources bölümünden ayarlar yapılır.

macOS’a özgü notlar:

Apple Silicon (M1/M2) Mac’lerde Docker daha verimli çalışır çünkü ARM tabanlı konteynerler native olarak çalışır. Ancak x86 image’leri için emülasyon kullanılır ve performans düşer.

Rosetta 2 entegrasyonunu aktif ederseniz x86 image’leri daha hızlı çalışır:

Settings > General > “Use Rosetta for x86/amd64 emulation on Apple Silicon”

Disk kullanımı optimizasyonu:

Docker Desktop macOS’ta bir disk image dosyası kullanır. Bu dosya zamanla şişebilir. Temizlemek için:

# Kullanılmayan image'leri ve volume'ları temizle
docker system prune -a --volumes

# Docker disk image'ini sıkıştır
# Settings > Resources > Disk image location > "Reset disk image"

Performance İpuçları

Docker Desktop performansını artırmak için:

File Sharing: Bind mount yavaş olabilir. Sadece gerçekten gerekli dizinleri paylaşın. Settings > Resources > File Sharing bölümünden kontrol edin.

Exclude directories: Virus tarayıcıların Docker dizinlerini atlamasını sağlayın. Windows Defender’da Docker Desktop yükleme dizinini ve WSL dizinlerini hariç tutun.

Use Volume mounts instead of bind mounts: Bind mount’lar (özellikle Windows/macOS’ta) yavaştır. Mümkünse named volume kullanın:

# Yavaş
docker run -v /Users/me/app:/app myimage

# Hızlı
docker volume create myapp-data
docker run -v myapp-data:/app myimage

Örnek Senaryo: Development Ortamı

Bir development ortamı için önerilen Docker Desktop ayarları:

Sistem: 16 GB RAM, 8 Core CPU

Memory: 8 GB
CPUs: 4
Swap: 2 GB
Disk: 128 GB

docker-compose.yml:

version: "3.8"

services:
  web:
    image: nginx
    deploy:
      resources:
        limits:
          cpus: '1.0'
          memory: 512M
    ports:
      - "8080:80"

  db:
    image: postgres:15
    deploy:
      resources:
        limits:
          cpus: '2.0'
          memory: 2G
    volumes:
      - db_data:/var/lib/postgresql/data

  redis:
    image: redis:alpine
    deploy:
      resources:
        limits:
          cpus: '0.5'
          memory: 256M

volumes:
  db_data:

Bu yapılandırmada toplam 3.5 CPU ve 2.75 GB RAM kullanılır. Docker Desktop’a 4 CPU ve 8 GB ayırdığınız için yeterli alan kalır.

Monitoring ve Troubleshooting

Kaynak kullanımını izlemek için:

# Tüm konteynerlerin kaynak kullanımı
docker stats

# Belirli konteyner
docker stats mycontainer

# JSON formatında
docker stats --no-stream --format "{{json .}}"

Docker stats çıktısı şunları gösterir:

• CPU kullanım yüzdesi
• Bellek kullanımı ve limit
• Bellek yüzdesi
• Network I/O
• Block I/O
• Process sayısı

Bir konteyner sürekli limit’e ulaşıyorsa iki seçenek vardır: limiti artırın veya uygulamayı optimize edin. Limitten sonra uygulamanın davranışını loglardan kontrol edin:

docker logs mycontainer

OOM (Out of Memory) hatası görüyorsanız memory limitini artırın. CPU throttling görüyorsanız CPU limitini artırın veya uygulamanızı optimize edin.

Kaynak yönetimi doğru yapıldığında sistem kararlı çalışır, konteynerler birbirini etkilemez ve beklenmedik çökmeler olmaz. Production ortamlarında mutlaka kaynak limitleri belirleyin ve izleyin.

12. Logging, Monitoring ve Observability

Docker konteynerlerinde logging ve monitoring, production ortamlarında sistem sağlığını takip etmek, sorunları tespit etmek ve performansı optimize etmek için kritiktir. Konteynerler geçici (ephemeral) yapıları nedeniyle logları merkezi bir yerde toplamak ve sistem metriklerini sürekli izlemek zorunludur.

Bu bölümde Docker’ın yerleşik logging araçlarını, farklı log driver’ları, monitoring mimarilerini ve merkezi logging sistemlerini detaylı şekilde inceleyeceğiz.

12.1 docker logs, docker stats, docker events

Docker, konteynerlerin durumunu ve loglarını izlemek için üç temel komut sunar.

docker logs — Konteyner Loglarını Görüntüleme

docker logs komutu, bir konteynerin stdout ve stderr çıktısını gösterir. Bu, uygulamanın konsola yazdığı tüm mesajları içerir.

Basit kullanım:

docker logs mycontainer

Bu komut konteynerin tüm loglarını ekrana basar.

Canlı log izleme (tail -f gibi):

docker logs -f mycontainer

-f (follow) parametresi, yeni logları gerçek zamanlı olarak gösterir. Konteyner çalışmaya devam ettikçe yeni satırlar ekrana gelir.

Son N satırı gösterme:

docker logs --tail 100 mycontainer

Sadece son 100 satırı gösterir. Büyük log dosyalarında performans için önemlidir.

Zaman damgası ekleme:

docker logs -t mycontainer

Her log satırının başına timestamp ekler:

2025-09-29T10:30:45.123456789Z [INFO] Application started
2025-09-29T10:30:46.234567890Z [INFO] Database connected

Belirli zaman aralığındaki loglar:

# Son 1 saatteki loglar
docker logs --since 1h mycontainer

# Belirli tarihten sonraki loglar
docker logs --since 2025-09-29T10:00:00 mycontainer

# Belirli tarihten önceki loglar
docker logs --until 2025-09-29T12:00:00 mycontainer

Kombinasyon örneği:

docker logs -f --tail 50 --since 10m mycontainer

Son 10 dakikadaki loglardan son 50 satırı gösterir ve yeni logları canlı takip eder.

docker stats — Kaynak Kullanım İstatistikleri

docker stats komutu, konteynerlerin gerçek zamanlı kaynak kullanımını gösterir. CPU, memory, network ve disk I/O metriklerini izleyebilirsiniz.

Tüm çalışan konteynerlerin istatistikleri:

docker stats

Çıktı örneği:

CONTAINER ID   NAME        CPU %     MEM USAGE / LIMIT     MEM %     NET I/O           BLOCK I/O
abc123def456   web         2.50%     256MiB / 512MiB       50.00%    1.2MB / 850KB     12MB / 5MB
def456abc789   db          15.20%    1.5GiB / 2GiB         75.00%    500KB / 300KB     500MB / 200MB

Açıklama:

• CPU %: Konteyner CPU kullanım yüzdesi
• MEM USAGE / LIMIT: Kullanılan bellek / Maksimum limit
• MEM %: Bellek kullanım yüzdesi
• NET I/O: Ağ giriş/çıkış trafiği
• BLOCK I/O: Disk okuma/yazma trafiği

Tek konteyner için stats:

docker stats mycontainer

Stream olmadan tek snapshot:

docker stats --no-stream

Bu komut bir kez çalışır ve çıkar. Script’lerde kullanışlıdır.

JSON formatında:

docker stats --no-stream --format "{{json .}}"

Programatik işlemler için JSON çıktı alırsınız:

{"BlockIO":"12.3MB / 5.6MB","CPUPerc":"2.50%","Container":"web","ID":"abc123","MemPerc":"50.00%","MemUsage":"256MiB / 512MiB","Name":"web","NetIO":"1.2MB / 850KB","PIDs":"15"}

Custom format örneği:

docker stats --format "table {{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}"

Sadece isim, CPU ve memory kullanımını tablo formatında gösterir.

docker events — Sistem Olaylarını İzleme

docker events komutu, Docker daemon’da gerçekleşen olayları gerçek zamanlı olarak gösterir. Konteyner başlatma, durdurma, ağ oluşturma, volume mount gibi tüm olaylar loglanır.

Tüm olayları izleme:

docker events

Çıktı örneği:

2025-09-29T10:30:45.123456789Z container create abc123 (image=nginx, name=web)
2025-09-29T10:30:45.234567890Z container start abc123 (image=nginx, name=web)
2025-09-29T10:30:46.345678901Z network connect bridge abc123

Belirli olayları filtreleme:

# Sadece konteyner olayları
docker events --filter type=container

# Belirli konteyner için
docker events --filter container=mycontainer

# Belirli olay tipi için
docker events --filter event=start

# Belirli image için
docker events --filter image=nginx

Zaman aralığı ile filtreleme:

# Son 1 saatteki olaylar
docker events --since 1h

# Belirli tarih aralığı
docker events --since 2025-09-29T10:00:00 --until 2025-09-29T12:00:00

JSON formatında:

docker events --format '{{json .}}'

Pratik örnek — Konteyner durumunu izleme scripti:

#!/bin/bash
docker events --filter type=container --format '{{.Time}} {{.Action}} {{.Actor.Attributes.name}}' | \
while read timestamp action container; do
    echo "[$timestamp] Container '$container' $action"
    if [ "$action" = "die" ]; then
        echo "WARNING: Container $container stopped unexpectedly!"
    fi
done

Bu script konteynerlerin durumunu izler ve beklenmedik kapanmaları bildirir.

12.2 Log Driver’lar (json-file, journald, syslog, gelf)

Docker, konteynerlerin loglarını farklı backend’lere yönlendirmek için log driver sistemi kullanır. Varsayılan olarak json-file driver’ı kullanılır ancak ihtiyaca göre farklı driver’lar seçilebilir.

Log Driver Türleri

Docker’da yaygın kullanılan log driver’lar:

json-file (Varsayılan Driver)

json-file driver’ı, logları host’ta JSON formatında dosyalara yazar. Her log satırı bir JSON objesi olarak saklanır.

Log dosyası konumu:

/var/lib/docker/containers/<container-id>/<container-id>-json.log

Örnek JSON log satırı:

{"log":"Hello from container\n","stream":"stdout","time":"2025-09-29T10:30:45.123456789Z"}

json-file ile konteyner başlatma:

docker run -d \
  --log-driver json-file \
  --log-opt max-size=10m \
  --log-opt max-file=3 \
  nginx

Log seçenekleri:

• max-size: Her log dosyasının maksimum boyutu (örn: 10m, 100k)
• max-file: Tutulacak maksimum log dosyası sayısı
• compress: Eski log dosyalarını sıkıştır (true/false)

Docker Compose ile:

services:
  web:
    image: nginx
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"
        compress: "true"

Avantajlar:

• Basit ve hızlı
• docker logs komutuyla uyumlu
• Kurulum gerektirmez

Dezavantajlar:

• Disk dolabilir (log rotation gerekli)
• Merkezi log yönetimi yok
• Arama ve analiz zor

journald

journald, systemd’nin log sistemidir. Modern Linux dağıtımlarında (Ubuntu 16.04+, CentOS 7+) varsayılan olarak gelir.

journald ile konteyner başlatma:

docker run -d \
  --log-driver journald \
  nginx

journalctl ile log görüntüleme:

# Konteyner ID ile
journalctl CONTAINER_ID=abc123

# Konteyner ismi ile
journalctl CONTAINER_NAME=mycontainer

# Son 100 satır
journalctl -n 100 CONTAINER_NAME=mycontainer

# Canlı takip
journalctl -f CONTAINER_NAME=mycontainer

Docker Compose ile:

services:
  web:
    image: nginx
    logging:
      driver: journald
      options:
        tag: "{{.Name}}/{{.ID}}"

Avantajlar:

• Sistem loglarıyla entegre
• Güçlü filtreleme ve arama
• Otomatik log rotation
• Merkezi journal yönetimi

Dezavantajlar:

• docker logs komutu çalışmaz
• Sadece systemd kullanan sistemlerde var
• Uzak sunucuya göndermek için ek yapılandırma gerekli

syslog

Syslog, geleneksel Unix log protokolüdür. Logları uzak bir syslog sunucusuna göndermek için kullanılır.

Syslog ile konteyner başlatma:

docker run -d \
  --log-driver syslog \
  --log-opt syslog-address=tcp://192.168.1.100:514 \
  --log-opt tag="docker/{{.Name}}" \
  nginx

Syslog seçenekleri:

• syslog-address: Syslog sunucu adresi (tcp://host:port veya udp://host:port)
• tag: Log mesajlarına eklenecek etiket
• syslog-facility: Syslog facility (daemon, local0-7)
• syslog-format: Mesaj formatı (rfc5424, rfc3164)

Docker Compose ile:

services:
  web:
    image: nginx
    logging:
      driver: syslog
      options:
        syslog-address: "tcp://192.168.1.100:514"
        tag: "web"
        syslog-facility: "local0"

Avantajlar:

• Merkezi log yönetimi
• Uzak sunucuya otomatik gönderim
• Mevcut syslog altyapısıyla uyumlu

Dezavantajlar:

• docker logs çalışmaz
• Network bağlantısı gerekli
• Performans overhead

gelf (Graylog Extended Log Format)

GELF, Graylog tarafından geliştirilen log formatıdır. Structured logging için optimize edilmiştir ve ELK stack’te de kullanılabilir.

GELF ile konteyner başlatma:

docker run -d \
  --log-driver gelf \
  --log-opt gelf-address=udp://192.168.1.100:12201 \
  --log-opt tag="nginx" \
  nginx

GELF seçenekleri:

• gelf-address: Graylog sunucu adresi
• tag: Log etiketi
• gelf-compression-type: Sıkıştırma tipi (gzip, zlib, none)

Docker Compose ile:

services:
  web:
    image: nginx
    logging:
      driver: gelf
      options:
        gelf-address: "udp://graylog:12201"
        tag: "nginx"
        gelf-compression-type: "gzip"

Avantajlar:

• Structured logging desteği
• Sıkıştırma ile ağ trafiği azaltma
• Graylog ve ELK ile kolay entegrasyon

Dezavantajlar:

• docker logs çalışmaz
• Graylog veya GELF-compatible sunucu gerekli

Log Driver Değiştirme

Çalışan bir konteynerin log driver’ını değiştiremezsiniz. Konteyneri silip yeniden oluşturmanız gerekir.

Daemon seviyesinde varsayılan log driver:

/etc/docker/daemon.json dosyasını düzenleyin:

{
  "log-driver": "journald",
  "log-opts": {
    "tag": "{{.Name}}"
  }
}

Docker’ı yeniden başlatın:

sudo systemctl restart docker

Artık yeni oluşturulan tüm konteynerler varsayılan olarak journald kullanır.

12.3 cAdvisor + Prometheus + Grafana Entegrasyonu

Production ortamlarında Docker konteynerlerini izlemek için popüler bir mimari: cAdvisor metriklerini toplar, Prometheus metriklerini saklar, Grafana görselleştirir.

Mimari Genel Bakış

Akış:

1. cAdvisor her konteynerin CPU, memory, network, disk metriklerini toplar
2. Prometheus cAdvisor’dan metriklerini düzenli aralıklarla çeker (scraping)
3. Grafana Prometheus’tan veri okuyarak dashboard’lar oluşturur

Kurulum — docker-compose.yml

Tüm sistemi tek bir Compose dosyası ile ayağa kaldırabilirsiniz:

version: "3.8"

services:
  cadvisor:
    image: gcr.io/cadvisor/cadvisor:latest
    container_name: cadvisor
    ports:
      - "8080:8080"
    volumes:
      - /:/rootfs:ro
      - /var/run:/var/run:ro
      - /sys:/sys:ro
      - /var/lib/docker/:/var/lib/docker:ro
    privileged: true
    networks:
      - monitoring

  prometheus:
    image: prom/prometheus:latest
    container_name: prometheus
    ports:
      - "9090:9090"
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml:ro
      - prometheus-data:/prometheus
    command:
      - '--config.file=/etc/prometheus/prometheus.yml'
      - '--storage.tsdb.path=/prometheus'
    networks:
      - monitoring

  grafana:
    image: grafana/grafana:latest
    container_name: grafana
    ports:
      - "3000:3000"
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=admin
    volumes:
      - grafana-data:/var/lib/grafana
    networks:
      - monitoring

volumes:
  prometheus-data:
  grafana-data:

networks:
  monitoring:

prometheus.yml yapılandırması:

global:
  scrape_interval: 15s

scrape_configs:
  - job_name: 'cadvisor'
    static_configs:
      - targets: ['cadvisor:8080']

Sistemi başlatma:

docker compose up -d

Servislere erişim:

• cAdvisor: http://localhost:8080
• Prometheus: http://localhost:9090
• Grafana: http://localhost:3000 (admin/admin)

cAdvisor Kullanımı

cAdvisor web arayüzünde (http://localhost:8080) tüm konteynerlerin gerçek zamanlı metriklerini görebilirsiniz.

cAdvisor metrik örnekleri:

• container_cpu_usage_seconds_total: CPU kullanım süresi
• container_memory_usage_bytes: Bellek kullanımı
• container_network_receive_bytes_total: Alınan ağ trafiği
• container_network_transmit_bytes_total: Gönderilen ağ trafiği
• container_fs_usage_bytes: Disk kullanımı

Prometheus Sorguları

Prometheus web arayüzünde (http://localhost:9090) PromQL sorguları yazabilirsiniz.

Örnek sorgular:

Konteyner CPU kullanımı:

rate(container_cpu_usage_seconds_total{name="mycontainer"}[5m])

Konteyner bellek kullanımı (MB):

container_memory_usage_bytes{name="mycontainer"} / 1024 / 1024

Network trafiği (son 5 dakika ortalaması):

rate(container_network_receive_bytes_total{name="mycontainer"}[5m])

En çok CPU kullanan 5 konteyner:

topk(5, rate(container_cpu_usage_seconds_total[5m]))

Grafana Dashboard Oluşturma

1. Grafana’ya giriş yapın (http://localhost:3000, admin/admin)
2. Configuration > Data Sources > Add data source
3. Prometheus seçin
4. URL: http://prometheus:9090
5. Save & Test

Dashboard ekleme:

1. Dashboards > Import
2. Dashboard ID: 193 (Docker and System Monitoring)
3. Load > Import

Artık tüm konteynerlerinizin metriklerini görselleştirebilirsiniz.

Custom panel oluşturma:

1. Create > Dashboard > Add new panel
2. Query: rate(container_cpu_usage_seconds_total{name="mycontainer"}[5m])
3. Visualization: Graph
4. Apply

Alert Kuralları

Prometheus ile otomatik alertler oluşturabilirsiniz.

prometheus.yml’e alert rules ekleme:

rule_files:
  - 'alerts.yml'

alerting:
  alertmanagers:
    - static_configs:
        - targets: ['alertmanager:9093']

alerts.yml:

groups:
  - name: container_alerts
    interval: 30s
    rules:
      - alert: HighMemoryUsage
        expr: container_memory_usage_bytes > 1000000000
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Container {{ $labels.name }} memory usage high"
          description: "Memory usage is above 1GB for 5 minutes"

      - alert: ContainerDown
        expr: up{job="cadvisor"} == 0
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "cAdvisor is down"

12.4 Merkezi Logging (EFK/ELK/Fluentd)

Büyük sistemlerde logları merkezi bir yerde toplamak şarttır. En popüler çözümler ELK (Elasticsearch, Logstash, Kibana) ve EFK (Elasticsearch, Fluentd, Kibana) stack’leridir.

ELK Stack Mimarisi

EFK Stack Kurulumu

EFK stack’te Logstash yerine daha hafif Fluentd kullanılır.

docker-compose.yml:

version: "3.8"

services:
  elasticsearch:
    image: docker.elastic.co/elasticsearch/elasticsearch:8.11.0
    container_name: elasticsearch
    environment:
      - discovery.type=single-node
      - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
      - xpack.security.enabled=false
    ports:
      - "9200:9200"
    volumes:
      - es-data:/usr/share/elasticsearch/data
    networks:
      - efk

  fluentd:
    image: fluent/fluentd:v1.16-1
    container_name: fluentd
    volumes:
      - ./fluentd.conf:/fluentd/etc/fluent.conf:ro
      - /var/lib/docker/containers:/var/lib/docker/containers:ro
    ports:
      - "24224:24224"
    depends_on:
      - elasticsearch
    networks:
      - efk

  kibana:
    image: docker.elastic.co/kibana/kibana:8.11.0
    container_name: kibana
    ports:
      - "5601:5601"
    environment:
      - ELASTICSEARCH_HOSTS=http://elasticsearch:9200
    depends_on:
      - elasticsearch
    networks:
      - efk

volumes:
  es-data:

networks:
  efk:

fluentd.conf:

<source>
  @type forward
  port 24224
</source>

<filter docker.**>
  @type parser
  key_name log
  <parse>
    @type json
  </parse>
</filter>

<match docker.**>
  @type elasticsearch
  host elasticsearch
  port 9200
  logstash_format true
  logstash_prefix docker
  include_tag_key true
  tag_key @log_name
  flush_interval 10s
</match>

Uygulama konteynerini Fluentd’ye bağlama:

docker run -d \
  --log-driver=fluentd \
  --log-opt fluentd-address=localhost:24224 \
  --log-opt tag="docker.{{.Name}}" \
  nginx

Docker Compose ile:

services:
  web:
    image: nginx
    logging:
      driver: fluentd
      options:
        fluentd-address: localhost:24224
        tag: docker.nginx
    networks:
      - efk

Kibana’da Log Görüntüleme

1. Kibana’ya giriş yapın (http://localhost:5601)
2. Management > Index Patterns > Create index pattern
3. Pattern: docker-*
4. Next step > Time field: @timestamp
5. Create index pattern
6. Discover menüsünden logları görüntüleyin

Kibana’da filtreleme:

• Container name ile: docker.name: "nginx"
• Log level ile: level: "error"
• Zaman aralığı ile: Sağ üstten time range seçin

Structured Logging

Uygulamalarınızın loglarını JSON formatında yazdırması arama ve filtrelemeyi kolaylaştırır.

Node.js örneği (Winston logger):

const winston = require('winston');

const logger = winston.createLogger({
  format: winston.format.json(),
  transports: [
    new winston.transports.Console()
  ]
});

logger.info('User logged in', { userId: 123, ip: '192.168.1.1' });

Çıktı:

{"level":"info","message":"User logged in","userId":123,"ip":"192.168.1.1","timestamp":"2025-09-29T10:30:45.123Z"}

Bu format Elasticsearch’te aranabilir fieldlar olarak indexlenir.

Log Retention ve Performans

Elasticsearch zamanla çok büyüyebilir. Index rotation ve silme politikaları belirlemelisiniz.

ILM (Index Lifecycle Management) örneği:

PUT _ilm/policy/docker-logs-policy
{
  "policy": {
    "phases": {
      "hot": {
        "actions": {
          "rollover": {
            "max_size": "50GB",
            "max_age": "7d"
          }
        }
      },
      "delete": {
        "min_age": "30d",
        "actions": {
          "delete": {}
        }
      }
    }
  }
}

Bu politika:

• Her index 50GB’a veya 7 güne ulaştığında yeni index oluşturur
• 30 gün sonra eski index’leri siler

Alternatif: Grafana Loki

Loki, Grafana’nın log toplama sistemidir. Elasticsearch’ten daha hafiftir.

docker-compose.yml:

services:
  loki:
    image: grafana/loki:latest
    ports:
      - "3100:3100"
    volumes:
      - ./loki-config.yml:/etc/loki/local-config.yaml

  promtail:
    image: grafana/promtail:latest
    volumes:
      - /var/log:/var/log:ro
      - /var/lib/docker/containers:/var/lib/docker/containers:ro
      - ./promtail-config.yml:/etc/promtail/config.yml
    command: -config.file=/etc/promtail/config.yml

  grafana:
    image: grafana/grafana:latest
    ports:
      - "3000:3000"

Loki daha az kaynak tüketir ve Grafana ile native entegredir.

Özet ve Best Practices

Logging best practices:

• Structured logging kullanın (JSON format)
• Log level’ları düzgün ayarlayın (DEBUG, INFO, WARN, ERROR)
• Sensitive bilgileri loglamayın
• Log rotation uygulayın
• Merkezi logging sistemi kurun

Monitoring best practices:

• Kritik metrikleri sürekli izleyin
• Alert kuralları belirleyin
• Dashboard’ları basit ve okunabilir tutun
• Retention politikaları belirleyin
• Backup alın

Araç seçimi:

Production ortamlarında logging ve monitoring ihmal edilmemesi gereken kritik konulardır. Doğru kurulum ve yapılandırma ile sistem sağlığını 7/24 izleyebilir, sorunları erken tespit edebilir ve performans optimizasyonu yapabilirsiniz.

Logging Dokümantasyonları

Eğer ELK, EFK, Prometheus + Grafana gibi sistemleri kurarken hata alırsan ya da takılırsan, aşağıdaki dokümantasyonları inceleyebilirsin:

Not: Kurulum sırasında “bağlantı hatası”, “port çakışması”, “kaynak yetersizliği” gibi problemler çıkabilir.
Böyle durumlarda önce hata mesajlarını dikkatle oku, ardından yukarıdaki kaynakların ilgili bölümüne (örneğin “Configuration”, “Troubleshooting”, ya da “FAQ”) bak — çoğu sorunun çözümü zaten orada yer alır.

13. Debugging & Troubleshooting (Pratik İpuçları)

Docker konteynerleriyle çalışırken sorunlarla karşılaşmak kaçınılmazdır. Konteyner başlamıyor, ağ bağlantısı çalışmıyor, beklenmedik davranışlar gösteriyor olabilir. Bu bölümde Docker’da hata ayıklama ve sorun giderme için kullanabileceğiniz araçları, komutları ve pratik yaklaşımları detaylı şekilde inceleyeceğiz.

13.1 docker inspect, docker exec -it, docker top, docker diff

Docker’ın yerleşik debugging araçları, konteynerlerin durumunu incelemek ve sorunları tespit etmek için güçlü özellikler sunar.

docker inspect — Detaylı Konteyner Bilgisi

docker inspect komutu, bir konteyner, imaj, network veya volume hakkında tüm teknik detayları JSON formatında gösterir. Bu komut debugging’in temel taşıdır.

Basit kullanım:

docker inspect mycontainer

Bu komut yüzlerce satır JSON çıktı verir. İçinde network ayarları, volume mount’lar, environment variables, resource limits gibi tüm bilgiler bulunur.

Belirli bilgiyi çıkarma (–format):

# IP adresini öğrenme
docker inspect --format='{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' mycontainer

# Port mapping'leri gösterme
docker inspect --format='{{json .NetworkSettings.Ports}}' mycontainer

# Environment variables
docker inspect --format='{{json .Config.Env}}' mycontainer

# Volume mount'ları gösterme
docker inspect --format='{{json .Mounts}}' mycontainer

# Konteyner durumu
docker inspect --format='{{.State.Status}}' mycontainer

# Restart count
docker inspect --format='{{.RestartCount}}' mycontainer

Çıktıyı jq ile filtreleme:

jq komutu JSON’ı daha okunabilir hale getirir ve detaylı filtreleme yapar.

# Tüm çıktıyı okunabilir hale getir
docker inspect mycontainer | jq '.'

# Sadece network bilgilerini göster
docker inspect mycontainer | jq '.[0].NetworkSettings'

# Environment variables'ı listele
docker inspect mycontainer | jq '.[0].Config.Env[]'

# Mount edilen volume'ları göster
docker inspect mycontainer | jq '.[0].Mounts[] | {Source, Destination, Mode}'

Pratik inspect örnekleri:

Konteyner neden durdu?

docker inspect --format='{{.State.Status}} - Exit Code: {{.State.ExitCode}}' mycontainer

Exit code’lar:

• 0: Normal çıkış
• 1: Genel hata
• 137: SIGKILL (OOM Killer tarafından öldürülmüş olabilir)
• 139: Segmentation fault
• 143: SIGTERM

OOM (Out of Memory) kontrolü:

docker inspect --format='{{.State.OOMKilled}}' mycontainer

Eğer true ise konteyner bellek limitini aşmış ve kernel tarafından öldürülmüş demektir.

Log path’ini bulma:

docker inspect --format='{{.LogPath}}' mycontainer

docker exec -it — Çalışan Konteynere Bağlanma

docker exec komutu, çalışan bir konteyner içinde komut çalıştırmanıza olanak tanır. Debugging için en çok kullanılan komuttur.

İnteraktif shell açma:

docker exec -it mycontainer bash

Eğer bash yoksa (Alpine gibi minimal image’lerde):

docker exec -it mycontainer sh

Tek komut çalıştırma:

# Process listesini görme
docker exec mycontainer ps aux

# Dosya içeriğini okuma
docker exec mycontainer cat /etc/hosts

# Ağ bağlantısını test etme
docker exec mycontainer ping -c 3 google.com

# Disk kullanımı
docker exec mycontainer df -h

Root yetkisi ile bağlanma:

Konteyner non-root kullanıcı ile çalışıyorsa ama root yetkisi gerekiyorsa:

docker exec -it --user root mycontainer bash

Çalışma dizinini değiştirme:

docker exec -it --workdir /app mycontainer bash

Environment variable ekleme:

docker exec -it -e DEBUG=true mycontainer bash

Pratik debugging senaryoları:

Senaryo 1: Web sunucusu çalışıyor mu?

# Nginx process'i çalışıyor mu?
docker exec mycontainer ps aux | grep nginx

# Port dinleniyor mu?
docker exec mycontainer netstat -tlnp | grep 80

# Curl ile test (eğer kuruluysa)
docker exec mycontainer curl -I http://localhost:80

Senaryo 2: Veritabanı bağlantısı çalışıyor mu?

# PostgreSQL bağlantısını test et
docker exec mypostgres psql -U postgres -c "SELECT 1"

# MySQL bağlantısını test et
docker exec mymysql mysql -u root -p'password' -e "SELECT 1"

Senaryo 3: Log dosyalarını kontrol etme

# Nginx error log
docker exec mynginx tail -f /var/log/nginx/error.log

# Application log
docker exec myapp tail -f /var/log/app/error.log

docker top — Process Listesi

docker top komutu, konteyner içinde çalışan process’leri gösterir. Hangi process’lerin çalıştığını ve kaynak kullanımını kontrol etmek için kullanılır.

Basit kullanım:

docker top mycontainer

Çıktı örneği:

UID      PID     PPID    C    STIME   TTY     TIME        CMD
root     12345   12340   0    10:30   ?       00:00:00    nginx: master process
www-data 12346   12345   0    10:30   ?       00:00:01    nginx: worker process

Custom format (ps komut seçenekleri):

# Detaylı bilgi
docker top mycontainer aux

# Bellek kullanımına göre sıralama
docker top mycontainer -o %mem

Process kontrolü:

# Nginx master process çalışıyor mu?
docker top mynginx | grep "nginx: master"

# Zombie process var mı?
docker top mycontainer aux | grep defunct

docker diff — Filesystem Değişiklikleri

docker diff komutu, konteyner başladıktan sonra filesystem’de yapılan değişiklikleri gösterir. Hangi dosyaların eklendiğini, değiştirildiğini veya silindiğini görebilirsiniz.

Basit kullanım:

docker diff mycontainer

Çıktı örneği:

A /tmp/test.txt
C /etc/nginx/nginx.conf
D /var/log/old.log

Semboller:

• A (Added): Yeni eklenen dosya
• C (Changed): Değiştirilen dosya
• D (Deleted): Silinen dosya

Pratik kullanım:

Konteyner içinde hangi dosyalar değişti?

docker diff mycontainer | grep ^C

Yeni log dosyaları oluşturulmuş mu?

docker diff mycontainer | grep ^A | grep log

Debug: Beklenmeyen dosya değişiklikleri

Bazen konteyner beklenmedik davranır. docker diff ile hangi dosyaların değiştiğini görerek sorunu bulabilirsiniz.

# Tüm değişiklikleri listele
docker diff mycontainer

# Sadece /etc dizinindeki değişiklikler
docker diff mycontainer | grep "^C /etc"

13.2 Ağ Sorunları için docker network inspect, tcpdump Kullanımı

Network sorunları Docker’da en yaygın problemlerden biridir. Konteynerler birbirini görmüyor, dışarı çıkamıyor veya port’lar çalışmıyor olabilir.

docker network inspect — Network Detayları

docker network inspect komutu, bir network’ün konfigürasyonunu, bağlı konteynerleri ve IP adreslerini gösterir.

Basit kullanım:

docker network inspect bridge

Network’e bağlı konteynerleri gösterme:

docker network inspect bridge --format='{{range .Containers}}{{.Name}}: {{.IPv4Address}}{{"\n"}}{{end}}'

Çıktı örneği:

web: 172.17.0.2/16
db: 172.17.0.3/16
redis: 172.17.0.4/16

Network subnet ve gateway:

docker network inspect mynetwork --format='{{range .IPAM.Config}}Subnet: {{.Subnet}}, Gateway: {{.Gateway}}{{end}}'

Pratik network debugging:

Sorun: Konteynerler birbirini göremiyor

# İki konteyner aynı network'te mi?
docker network inspect mynetwork

# Çıktıda her iki konteyner de "Containers" bölümünde olmalı

Sorun: DNS çözümleme çalışmıyor

# Konteyner içinden DNS test
docker exec mycontainer nslookup other-container

# Docker DNS server kontrolü
docker exec mycontainer cat /etc/resolv.conf

Docker’ın internal DNS server’ı genellikle 127.0.0.11 olarak görünür.

ping ve curl ile Network Testi

Konteyner içinde network bağlantısını test etmek için temel araçlar kullanabilirsiniz.

Ping ile bağlantı testi:

# Başka konteynere ping
docker exec container1 ping -c 3 container2

# Dış dünyaya ping
docker exec mycontainer ping -c 3 8.8.8.8

# DNS çözümleme testi
docker exec mycontainer ping -c 3 google.com

Curl ile HTTP testi:

# Başka konteynere HTTP isteği
docker exec container1 curl http://container2:80

# Dış siteye istek
docker exec mycontainer curl -I https://google.com

# Timeout ayarlayarak
docker exec mycontainer curl --max-time 5 http://slow-service

Netstat ile port kontrolü:

# Hangi portlar dinleniyor?
docker exec mycontainer netstat -tlnp

# Belirli port dinleniyor mu?
docker exec mycontainer netstat -tlnp | grep :80

tcpdump ile Paket Analizi (Linux Host)

tcpdump, network trafiğini yakalamak ve analiz etmek için güçlü bir araçtır. Konteyner içinde veya host üzerinde çalıştırılabilir.

Host üzerinde konteyner trafiğini yakalama:

# Tüm Docker network trafiğini yakala
sudo tcpdump -i docker0

# Belirli konteyner IP'sine giden trafiği yakala
sudo tcpdump -i docker0 host 172.17.0.2

# HTTP trafiğini yakala (port 80)
sudo tcpdump -i docker0 port 80

# Trafiği dosyaya kaydet
sudo tcpdump -i docker0 -w capture.pcap

Konteyner içinde tcpdump:

Çoğu konteyner imajında tcpdump yoktur. Kurulum gerekebilir:

# Alpine
docker exec mycontainer apk add tcpdump

# Ubuntu/Debian
docker exec mycontainer apt-get update && apt-get install -y tcpdump

# tcpdump çalıştır
docker exec mycontainer tcpdump -i eth0 -n

Pratik tcpdump örnekleri:

Sorun: Konteyner dış dünyaya çıkamıyor

# Konteynerden çıkan DNS isteklerini izle
sudo tcpdump -i docker0 port 53

# Ardından konteyner içinden ping at
docker exec mycontainer ping google.com

Eğer tcpdump’ta paket görmüyorsanız routing sorunu var demektir.

Sorun: İki konteyner arasında bağlantı yok

# container1'den container2'ye giden trafiği izle
sudo tcpdump -i docker0 host 172.17.0.2 and host 172.17.0.3

# container1'den curl at
docker exec container1 curl http://container2:8080

Paketleri görüyorsanız ama yanıt alamıyorsanız, container2’de uygulama çalışmıyor olabilir.

nsenter ile Host’tan Konteyner Network Namespace’ine Girme

nsenter komutu, konteynerin network namespace’ine doğrudan host’tan girebilmenizi sağlar. Gelişmiş debugging için kullanılır.

Konteyner PID’sini bulma:

PID=$(docker inspect --format '{{.State.Pid}}' mycontainer)

Network namespace’e girme:

sudo nsenter -t $PID -n ip addr

Bu komut konteynerin network interface’lerini gösterir.

Network routing tablosunu görme:

sudo nsenter -t $PID -n ip route

tcpdump çalıştırma:

sudo nsenter -t $PID -n tcpdump -i eth0

13.3 “Container Çalışmıyor” Durumlarında Hızlı Kontrol Listesi

Konteyner başlamıyor veya hemen kapanıyorsa sistematik bir yaklaşımla sorunu bulabilirsiniz.

Adım 1: Konteyner Durumunu Kontrol Et

docker ps -a

Konteyner Exited durumundaysa exit code’a bakın:

docker inspect --format='{{.State.ExitCode}}' mycontainer

Exit code anlamları:

• 0: Normal çıkış (sorun yok, konteyner işini bitirip kapandı)
• 1: Uygulama hatası
• 125: Docker daemon hatası
• 126: Komut çalıştırılamadı
• 127: Komut bulunamadı
• 137: SIGKILL (OOM veya manuel kill)
• 143: SIGTERM (graceful shutdown)

Adım 2: Logları İncele

docker logs mycontainer

Son 50 satırı görmek için:

docker logs --tail 50 mycontainer

Hata mesajları genellikle loglarda bellidir:

• Address already in use: Port başka bir process tarafından kullanılıyor
• Permission denied: Dosya izin sorunu
• Connection refused: Hedef servis çalışmıyor
• No such file or directory: Dosya veya path yanlış

Adım 3: Dockerfile ve Komut Kontrolü

CMD veya ENTRYPOINT yanlış olabilir:

docker inspect --format='{{.Config.Cmd}}' mycontainer
docker inspect --format='{{.Config.Entrypoint}}' mycontainer

Test: Konteyner içinde manuel komut çalıştırma

Eğer konteyner hemen kapanıyorsa, shell ile başlatıp manuel test edin:

docker run -it --entrypoint /bin/sh myimage

Ardından orijinal komutu manuel çalıştırın ve hatayı görün.

Adım 4: Resource Limitlerini Kontrol Et

Konteyner OOM (Out of Memory) killed mi?

docker inspect --format='{{.State.OOMKilled}}' mycontainer

Eğer true ise memory limitini artırın:

docker run --memory="1g" myimage

Adım 5: Volume ve Bind Mount Kontrolü

Mount’lar doğru mu?

docker inspect --format='{{json .Mounts}}' mycontainer | jq '.'

Kontrol edilecekler:

• Kaynak path host’ta var mı?
• İzinler doğru mu?
• SELinux/AppArmor engelliyor mu? (Linux’ta :Z etiketi deneyin)

Test: Volume olmadan çalıştırma

docker run --rm myimage

Eğer volume olmadan çalışıyorsa sorun mount’tadır.

Adım 6: Network Kontrolü

Konteyner network’e bağlı mı?

docker network inspect mynetwork

Port mapping doğru mu?

docker inspect --format='{{json .NetworkSettings.Ports}}' mycontainer

Test: Host network ile çalıştırma

docker run --network host myimage

Eğer host network ile çalışıyorsa bridge network’te sorun var demektir.

Adım 7: Dependency Kontrolü

depends_on çalışmıyor:

Docker Compose’da depends_on sadece başlatma sırasını garanti eder, servisin hazır olmasını beklemez.

Çözüm: Healthcheck veya wait script kullanın

services:
  web:
    image: myapp
    depends_on:
      db:
        condition: service_healthy

  db:
    image: postgres
    healthcheck:
      test: ["CMD", "pg_isready", "-U", "postgres"]
      interval: 10s
      timeout: 5s
      retries: 5

Hızlı Kontrol Listesi Özet

1. docker ps -a — Konteyner durumu ve exit code
2. docker logs mycontainer — Hata mesajları
3. docker inspect mycontainer — Detaylı konfigürasyon
4. docker run -it --entrypoint /bin/sh myimage — Manuel test
5. Volume ve network ayarlarını kontrol et
6. Resource limitleri kontrol et
7. Healthcheck ve dependency durumunu kontrol et

13.4 Windows Konteyner Debug İpuçları (PowerShell vs CMD)

Windows konteynerler Linux konteynerlerden farklı çalışır ve debugging yaklaşımları da farklıdır.

Windows Konteyner Türleri

Windows Server Core:

• Tam Windows API desteği
• Daha büyük image boyutu (birkaç GB)
• Eski uygulamalar için uyumlu

Nano Server:

• Minimal Windows image
• Daha küçük (hundreds of MB)
• PowerShell Core içerir, tam framework yok

PowerShell ile Debugging

Windows konteynerlerinde genellikle PowerShell kullanılır.

PowerShell shell açma:

docker exec -it mycontainer powershell

CMD ile çalıştırma:

docker exec -it mycontainer cmd

Pratik PowerShell komutları:

Process listesi:

docker exec mycontainer powershell "Get-Process"

Servis durumu:

docker exec mycontainer powershell "Get-Service"

Network bağlantıları:

docker exec mycontainer powershell "Test-NetConnection google.com"

Dosya sistemi kontrolü:

docker exec mycontainer powershell "Get-ChildItem C:\app"

Event log kontrolü:

docker exec mycontainer powershell "Get-EventLog -LogName Application -Newest 10"

Windows Konteyner Network Debugging

Windows konteynerlerinde network debugging Linux’tan biraz farklıdır.

IP konfigürasyonu:

docker exec mycontainer ipconfig /all

Route tablosu:

docker exec mycontainer route print

DNS cache:

docker exec mycontainer ipconfig /displaydns

Ping testi:

docker exec mycontainer ping -n 3 google.com

Port kontrolü:

docker exec mycontainer netstat -ano

Windows Konteyner Logları

Windows konteynerlerinde log yönetimi farklıdır.

Event Log okuma:

docker exec mycontainer powershell "Get-EventLog -LogName Application | Select-Object -First 20"

IIS logları (eğer IIS kullanılıyorsa):

docker exec mycontainer powershell "Get-Content C:\inetpub\logs\LogFiles\W3SVC1\*.log -Tail 50"

Dockerfile Debugging (Windows)

Örnek Windows Dockerfile:

FROM mcr.microsoft.com/windows/servercore:ltsc2022

WORKDIR C:\app

COPY app.exe .

CMD ["app.exe"]

Debug için shell eklemek:

FROM mcr.microsoft.com/windows/servercore:ltsc2022

WORKDIR C:\app

COPY app.exe .

# Debug için shell başlat
ENTRYPOINT ["powershell.exe"]

Ardından konteyner içinde manuel test:

docker run -it myimage
# PowerShell açılacak
PS C:\app> .\app.exe

Windows vs Linux Konteyner Farkları

Yaygın Windows Konteyner Sorunları

Sorun 1: “The container operating system does not match the host operating system”

Açıklama: Windows konteyner versiyonu host versiyonuyla uyumsuz.

Çözüm: Hyper-V isolation kullan:

docker run --isolation=hyperv myimage

Sorun 2: Volume mount çalışmıyor

Açıklama: Windows path’leri farklı format kullanır.

Yanlış:

docker run -v C:\data:/data myimage

Doğru:

docker run -v C:\data:C:\data myimage

Sorun 3: Port forwarding çalışmıyor

Açıklama: Windows NAT network kısıtlamaları.

Kontrol:

# NAT network kontrolü
docker network inspect nat

# Port mapping kontrolü
docker port mycontainer

Çözüm: Transparent network kullanmayı deneyin:

docker network create -d transparent mytransparent
docker run --network mytransparent myimage

Windows Performance Monitoring

Resource kullanımı:

docker stats

Detaylı performance counters:

docker exec mycontainer powershell "Get-Counter '\Processor(_Total)\% Processor Time'"

Memory kullanımı:

docker exec mycontainer powershell "Get-Process | Sort-Object WS -Descending | Select-Object -First 10"

Özet ve Best Practices

Debugging checklist:

1. docker ps -a ile durum kontrolü
2. docker logs ile hata mesajlarını oku
3. docker inspect ile detaylı konfigürasyonu incele
4. docker exec ile konteyner içine gir ve manuel test et
5. Network bağlantılarını test et (ping, curl, tcpdump)
6. Resource limitlerini kontrol et
7. Volume mount’ları ve izinleri kontrol et

Araç önerileri:

• Linux: tcpdump, strace, htop
• Windows: PowerShell, Event Viewer, Process Monitor
• Her platform: docker logs, docker inspect, docker exec

Dokümantasyon:

Sorunları çözdükten sonra notlar alın. Hangi hatayı nasıl çözdüğünüzü dokümante edin. Bu, gelecekte benzer sorunlarla karşılaştığınızda zaman kazandırır.

Debugging sistematik bir süreçtir. Panik yapmadan adım adım ilerleyerek çoğu sorunu çözebilirsiniz. Docker’ın sağladığı araçları iyi bilmek, production ortamlarında kritik sorunları hızlıca çözmenizi sağlar.

14. CI/CD ile Entegrasyon (Docker Native Yaklaşımlar)

Modern yazılım geliştirmede CI/CD (Continuous Integration/Continuous Deployment) pipeline’ları vazgeçilmezdir. Docker, bu süreçlerde merkezi bir rol oynar. Bu bölümde Docker’ı CI/CD pipeline’larına nasıl entegre edeceğinizi, multi-platform image build süreçlerini ve image etiketleme stratejilerini detaylı şekilde inceleyeceğiz.

14.1 Build → Test → Push Pipeline Örneği

CI/CD pipeline’ı tipik olarak şu aşamalardan oluşur:

1. Build: Dockerfile’dan image oluşturma
2. Test: Image’i test etme (unit test, integration test)
3. Scan: Güvenlik açıklarını tarama
4. Push: Registry’ye yükleme
5. Deploy: Production’a dağıtım

GitHub Actions Pipeline Örneği

GitHub Actions, GitHub üzerinde çalışan popüler bir CI/CD platformudur.

Basit Python uygulaması için tam pipeline:

.github/workflows/docker-ci.yml:

name: Docker CI/CD Pipeline

on:
  push:
    branches: [ main, develop ]
    tags:
      - 'v*'
  pull_request:
    branches: [ main ]

env:
  REGISTRY: ghcr.io
  IMAGE_NAME: ${{ github.repository }}

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write

    steps:
      # Kod checkout
      - name: Checkout repository
        uses: actions/checkout@v4

      # Docker Buildx kurulumu
      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v3

      # Registry'ye login
      - name: Log in to GitHub Container Registry
        uses: docker/login-action@v3
        with:
          registry: ${{ env.REGISTRY }}
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      # Metadata oluşturma (tags, labels)
      - name: Extract metadata
        id: meta
        uses: docker/metadata-action@v5
        with:
          images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}
          tags: |
            type=ref,event=branch
            type=ref,event=pr
            type=semver,pattern={{version}}
            type=semver,pattern={{major}}.{{minor}}
            type=sha,prefix={{branch}}-

      # Image build
      - name: Build Docker image
        uses: docker/build-push-action@v5
        with:
          context: .
          load: true
          tags: test-image:latest
          cache-from: type=gha
          cache-to: type=gha,mode=max

      # Test çalıştırma
      - name: Run tests
        run: |
          docker run --rm test-image:latest pytest tests/

      # Güvenlik taraması (Trivy)
      - name: Run Trivy vulnerability scanner
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: test-image:latest
          format: 'sarif'
          output: 'trivy-results.sarif'

      # Trivy sonuçlarını GitHub'a yükle
      - name: Upload Trivy results to GitHub Security
        uses: github/codeql-action/upload-sarif@v2
        if: always()
        with:
          sarif_file: 'trivy-results.sarif'

      # Push (sadece main branch ve tag'ler için)
      - name: Build and push Docker image
        if: github.event_name != 'pull_request'
        uses: docker/build-push-action@v5
        with:
          context: .
          push: true
          tags: ${{ steps.meta.outputs.tags }}
          labels: ${{ steps.meta.outputs.labels }}
          cache-from: type=gha
          cache-to: type=gha,mode=max