Docker Compose Rehberi: Çoklu Container Yönetimi

Bir web uygulaması düşün: Spring Boot backend, PostgreSQL veritabanı, Redis cache, Nginx reverse proxy. Dört farklı container. Her birini docker run ile tek tek başlatıyorsun — port'ları ezberliyorsun, network'leri elle bağlıyorsun. Çalışma arkadaşın projeyi klonluyor: "Nasıl ayağa kaldıracağım?" Bir container'ı yanlış sırada başlatıyor — patlıyor.

Docker Compose tam olarak bu kabusu bitirir. Tek YAML dosyasına tüm altyapını tanımla, docker compose up de — sıralama, network, volume hepsi otomatik.

Bu yazıda Docker Compose'u sıfırdan öğreneceksin: kurulum, YAML yapısı, temel komutlar, gerçek dünya örnekleri, networking, health check ve production ayarları. Yazıyı bitirdiğinde kendi projelerinde Compose dosyası yazabilir hale geleceksin.

💡 Bu yazı [Docker Nedir?](/blog/docker-nedir-container-teknolojisi-rehberi) yazımızın devamı niteliğindedir. Docker temellerine aşina değilsen önce o yazıyı oku.

1. Docker Compose Nedir ve Neden Gerekli?

Docker Compose, birden fazla container'ı tek bir YAML dosyasıyla tanımlayıp yönetmeni sağlayan bir araçtır. Docker'ın resmi bir parçasıdır ve çoklu container uygulamalarını (multi-container applications) orkestre etmek için kullanılır.

Tek Container Yeterli Değil Mi?

Gerçek dünyada neredeyse hiçbir uygulama tek başına çalışmaz. Tipik bir web uygulaması: uygulama sunucusu + veritabanı + cache + reverse proxy. Her biri ayrı container'da çalışır. Compose olmadan her seferinde docker run komutlarını tek tek yazman, network oluşturman, port ve volume'ları ezberlememem gerekir. Oysa docker-compose.yml dosyasına yazıp docker compose up diyebilirsin:

services:
  postgres:
    image: postgres:16
    environment:
      POSTGRES_PASSWORD: secret
    volumes:
      - pgdata:/var/lib/postgresql/data

  redis:
    image: redis:7-alpine

  app:
    image: my-app:latest
    ports:
      - "8080:8080"
    environment:
      DB_HOST: postgres
      REDIS_HOST: redis
    depends_on:
      - postgres
      - redis

volumes:
  pgdata:

Tek dosya, tek komut, tüm altyapı ayakta. Network bile otomatik oluşturulur — Compose her proje için ayrı bir bridge network yaratır.

Compose'un Temel Faydaları

• Tekrarlanabilirlik: Aynı YAML her ortamda aynı sonucu verir

• Versiyon Kontrolü: YAML dosyası Git'e commit'lenir → Infrastructure as Code

• Takım Çalışması: Yeni geliştirici docker compose up der, hazır

• İzolasyon: Her proje kendi network ve volume'larına sahip

2. Kurulum

Docker Desktop (Windows & macOS)

Docker Desktop kurduğunda Compose otomatik olarak gelir. Ek kurulum gerekmez. Terminalde doğrulamak için:

docker compose version
# Docker Compose version v2.29.x

Linux

Docker Engine kuruluysa Compose plugin'i ayrıca yüklenir:

# Ubuntu/Debian
sudo apt update
sudo apt install docker-compose-plugin

# Doğrulama
docker compose version

⚠️ Dikkat: Eski docker-compose (tire ile ayrılmış, V1) artık kullanımdan kalktı. Yeni komut docker compose (boşluklu, V2) şeklindedir. V1 kullanan eski projelerde docker-compose yerine docker compose yazman yeterli — komutlar aynı.

V2, Go ile yazıldığı için V1'den 2-3 kat daha hızlıdır.

3. docker-compose.yml Yapısı

Compose dosyasının anatomisini öğrenmek, tüm Compose yolculuğunun temelidir. YAML formatında yazılır ve dört ana bölümden oluşur:

# docker-compose.yml

services:    # Container tanımları (zorunlu)
  web:
    image: nginx:alpine
    ports:
      - "80:80"

  api:
    build: ./backend
    ports:
      - "3000:3000"

volumes:     # Kalıcı veri depolama (opsiyonel)
  db-data:

networks:    # Özel ağ tanımları (opsiyonel)
  frontend:
  backend:

configs:     # Harici konfigürasyon dosyaları (opsiyonel)
  my-config:
    file: ./config.json

3.1 Services — Sık Kullanılan Alanlar

Her service bir container'a karşılık gelir. En önemli alanlar:

💡 image ve build birlikte kullanılabilir. Bu durumda build edilen imaja image alanıyla isim verirsin.

3.2 Volumes ve Networks

Volumes: Container silindiğinde veri kaybolur. Volume'lar veriyi kalıcı kılar. volumes: bölümünde named volume tanımlarsın.

Networks: Compose varsayılan bir bridge network oluşturur. Özel network'ler tanımlayarak servisler arası izolasyon sağlayabilirsin. internal: true ile dış dünyaya erişimi kapatırsın.

3.3 Tüm Parçalar Bir Arada: Eksiksiz Örnek

services:
  frontend:
    build: ./frontend
    ports:
      - "3000:3000"
    networks:
      - frontend-net
    depends_on:
      - api

  api:
    build: ./backend
    ports:
      - "8080:8080"
    environment:
      DB_HOST: postgres
      REDIS_HOST: redis
    networks:
      - frontend-net
      - backend-net
    depends_on:
      postgres:
        condition: service_healthy
      redis:
        condition: service_started

  postgres:
    image: postgres:16-alpine
    environment:
      POSTGRES_DB: myapp
      POSTGRES_USER: admin
      POSTGRES_PASSWORD: secret
    volumes:
      - pgdata:/var/lib/postgresql/data
    networks:
      - backend-net
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U admin"]
      interval: 10s
      timeout: 5s
      retries: 5

  redis:
    image: redis:7-alpine
    volumes:
      - redis-data:/data
    networks:
      - backend-net

volumes:
  pgdata:
  redis-data:

networks:
  frontend-net:
  backend-net:
    internal: true

Bu yapıda frontend sadece API'ye erişebilir, doğrudan veritabanına erişemez. API ise hem frontend ağına hem backend ağına bağlıdır. Mikroservis mimarisinin temeli budur.

4. Temel Komutlar

Docker Compose günlük kullanımda ihtiyacın olan komutlar şunlardır:

docker compose up — Başlat

# Tüm servisleri başlat (foreground)
docker compose up

# Arka planda başlat (detached)
docker compose up -d

# Sadece belirli servisleri başlat
docker compose up -d postgres redis

# İmajları yeniden build et ve başlat
docker compose up -d --build

# Eski container'ları sil, temiz başla
docker compose up -d --force-recreate

docker compose down — Durdur ve Temizle

# Container'ları durdur ve sil (network dahil)
docker compose down

# Volume'ları da sil (VERİ KAYBI!)
docker compose down -v

# İmajları da sil
docker compose down --rmi all

⚠️ Dikkat: docker compose down -v volume'ları siler. Veritabanı verilerin gider. Production'da bu komutu asla kullanma.

docker compose ps — Durumu Gör

docker compose ps
# NAME          SERVICE    STATUS     PORTS
# app-api-1     api        running    0.0.0.0:8080->8080/tcp
# app-postgres  postgres   running    5432/tcp
# app-redis-1   redis      running    6379/tcp

docker compose logs — Logları İncele

# Tüm servislerin logları
docker compose logs

# Belirli servisin logları (canlı takip)
docker compose logs -f api

# Son 100 satır
docker compose logs --tail 100 api

# Zaman damgası ile
docker compose logs -t api

docker compose exec — Container İçinde Komut Çalıştır

# PostgreSQL'e bağlan
docker compose exec postgres psql -U admin -d myapp

# Redis CLI
docker compose exec redis redis-cli

# Uygulama container'ında bash
docker compose exec api bash

# Tek seferlik komut (container sonra durur)
docker compose run --rm api npm test

docker compose build — İmajları Build Et

# Tüm servisleri build et
docker compose build

# Belirli servisi build et (cache kullanmadan)
docker compose build --no-cache api

# Paralel build
docker compose build --parallel

Diğer Faydalı Komutlar

5. Gerçek Dünya Örnekleri

Teoriden pratiğe geçelim. Gerçek projelerde kullanabileceğin üç farklı senaryo:

5.1 Spring Boot + PostgreSQL + Redis

Java/Spring Boot projelerinin klasik üçlüsü:

# docker-compose.yml — Spring Boot Projesi
services:
  app:
    build:
      context: .
      dockerfile: Dockerfile
    image: my-spring-app:latest
    ports:
      - "8080:8080"
    environment:
      SPRING_DATASOURCE_URL: jdbc:postgresql://postgres:5432/appdb
      SPRING_DATASOURCE_USERNAME: appuser
      SPRING_DATASOURCE_PASSWORD: ${DB_PASSWORD}
      SPRING_DATA_REDIS_HOST: redis
      SPRING_PROFILES_ACTIVE: docker
    depends_on:
      postgres:
        condition: service_healthy
      redis:
        condition: service_healthy
    restart: unless-stopped

  postgres:
    image: postgres:16-alpine
    environment:
      POSTGRES_DB: appdb
      POSTGRES_USER: appuser
      POSTGRES_PASSWORD: ${DB_PASSWORD}
    volumes:
      - postgres-data:/var/lib/postgresql/data
      - ./sql/init.sql:/docker-entrypoint-initdb.d/init.sql
    ports:
      - "5432:5432"
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U appuser -d appdb"]
      interval: 10s
      timeout: 5s
      retries: 5
      start_period: 30s

  redis:
    image: redis:7-alpine
    command: redis-server --requirepass ${REDIS_PASSWORD}
    volumes:
      - redis-data:/data
    healthcheck:
      test: ["CMD", "redis-cli", "-a", "${REDIS_PASSWORD}", "ping"]
      interval: 10s
      timeout: 3s
      retries: 3

volumes:
  postgres-data:
  redis-data:

Dockerfile'ı [multi-stage build](/blog/docker-multi-stage-build-kucuk-guvenli-imageler) ile optimize edersen imaj boyutu %70 küçülür.

5.2 WordPress + MySQL

Hızlıca bir WordPress sitesi kurmak için:

# docker-compose.yml — WordPress
services:
  wordpress:
    image: wordpress:6.5-apache
    ports:
      - "8080:80"
    environment:
      WORDPRESS_DB_HOST: mysql
      WORDPRESS_DB_NAME: wordpress
      WORDPRESS_DB_USER: wpuser
      WORDPRESS_DB_PASSWORD: ${WP_DB_PASSWORD}
    volumes:
      - wp-content:/var/www/html/wp-content
    depends_on:
      mysql:
        condition: service_healthy
    restart: unless-stopped

  mysql:
    image: mysql:8.0
    environment:
      MYSQL_DATABASE: wordpress
      MYSQL_USER: wpuser
      MYSQL_PASSWORD: ${WP_DB_PASSWORD}
      MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD}
    volumes:
      - mysql-data:/var/lib/mysql
    healthcheck:
      test: ["CMD", "mysqladmin", "ping", "-h", "localhost"]
      interval: 10s
      timeout: 5s
      retries: 5

volumes:
  wp-content:
  mysql-data:

docker compose up -d — 30 saniyede tam teşekküllü WordPress sitesi.

5.3 Node.js + MongoDB

MERN stack geliştiriciler için:

# docker-compose.yml — Node.js + MongoDB
services:
  api:
    build: .
    ports:
      - "3000:3000"
    environment:
      MONGODB_URI: mongodb://root:${MONGO_PASSWORD}@mongo:27017/myapp?authSource=admin
      NODE_ENV: development
    volumes:
      - ./src:/app/src          # Hot reload için kaynak kodu bağla
      - /app/node_modules       # node_modules'ü container'da tut
    command: npm run dev
    depends_on:
      mongo:
        condition: service_healthy

  mongo:
    image: mongo:7
    environment:
      MONGO_INITDB_ROOT_USERNAME: root
      MONGO_INITDB_ROOT_PASSWORD: ${MONGO_PASSWORD}
    volumes:
      - mongo-data:/data/db
    healthcheck:
      test: ["CMD", "mongosh", "--eval", "db.adminCommand('ping')"]
      interval: 10s
      timeout: 5s
      retries: 5

volumes:
  mongo-data:

💡 volumes bölümündeki /app/node_modules satırına dikkat: bu "anonymous volume" tekniği, host'taki node_modules'ün container'dakini ezmesini engeller.

6. Networking: Container'lar Arası İletişim

Docker Compose'un en güçlü yanlarından biri otomatik networking'dir.

Varsayılan Network

docker compose up çalıştırdığında Compose otomatik olarak <proje-adı>_default isimli bir bridge network oluşturur. Tüm servisler bu ağa bağlanır ve birbirlerini servis adıyla bulabilir.

services:
  api:
    image: my-api
    environment:
      DB_HOST: postgres     # "postgres" servis adı, IP adresi değil!

  postgres:
    image: postgres:16

api container'ının içinden ping postgres yapsan IP adresi döner. Docker'ın embedded DNS sunucusu servis adlarını otomatik çözümler.

Custom (Özel) Network'ler

Daha büyük projelerde izolasyon için özel network'ler tanımlarsın:

services:
  # Frontend — sadece API'ye erişir
  frontend:
    image: nginx:alpine
    networks:
      - public

  # API — hem public hem private ağda
  api:
    image: my-api
    networks:
      - public
      - private

  # Veritabanı — sadece private ağda, dışarıdan erişilemez
  postgres:
    image: postgres:16
    networks:
      - private

networks:
  public:
    driver: bridge
  private:
    driver: bridge
    internal: true    # Dış dünyaya (internet) erişim kapalı

Bu mimaride frontend sadece API'ye erişir, PostgreSQL ise sadece API'den erişilebilir ve internete çıkamaz. Mikroservis mimarisinde güvenlik katmanı oluşturmanın en basit yoludur.

7. Volume Yönetimi

Container'lar geçicidir (ephemeral). Volume'lar verileri kalıcı kılar.

Volume Türleri

1. Named Volume:

services:
  postgres:
    volumes:
      - pgdata:/var/lib/postgresql/data

volumes:
  pgdata:    # Docker yönetir, /var/lib/docker/volumes/ altında saklar

Docker yönetir, yedeklemesi kolay. Önerilen yöntem.

2. Bind Mount:

services:
  api:
    volumes:
      - ./src:/app/src                    # Kaynak kodu bağla (geliştirme)
      - ./config/nginx.conf:/etc/nginx/nginx.conf:ro  # :ro = read-only

Dev ortamında hot reload için ideal. Production'da named volume tercih et.

3. tmpfs Mount:

services:
  app:
    tmpfs:
      - /tmp
      - /app/cache

RAM'de tutulur, container durduğunda kaybolur. Geçici dosyalar için ideal.

💡 İpucu: Production ortamda veritabanı yedekleme için volume backup yerine pg_dump veya mysqldump gibi native backup araçlarını kullan. Daha güvenilir ve tutarlıdır.

8. Environment Variables ve .env Dosyası

Şifreleri YAML'a hardcode etme. .env dosyası kullan — Compose otomatik okur:

# .env
DB_PASSWORD=supersecret123
REDIS_PASSWORD=redispass456
APP_PORT=8080
POSTGRES_VERSION=16-alpine

# docker-compose.yml
services:
  postgres:
    image: postgres:${POSTGRES_VERSION}
    environment:
      POSTGRES_PASSWORD: ${DB_PASSWORD}

  app:
    ports:
      - "${APP_PORT}:8080"

${DEGISKEN} sözdizimi ile .env'deki değerleri kullanırsın. .env dosyasını .gitignore'a eklemeyi unutma!

Takım arkadaşların için bir .env.example dosyası oluştur (gerçek değerler boş, yapı belli olsun) ve bunu repo'ya commit'le.

Servis bazında farklı env dosyaları da kullanabilirsin:

services:
  api:
    env_file:
      - .env                  # Genel değişkenler
      - .env.api              # API'ye özel değişkenler
    environment:
      NODE_ENV: production    # env_file'dakileri override eder

⚠️ Dikkat: Öncelik sırası: environment > env_file > Dockerfile ENV.

9. Health Check: Container Sağlık Kontrolü

Container'ın "çalışıyor" olması, uygulamanın "hazır" olduğu anlamına gelmez. PostgreSQL container'ı başlamış olabilir ama veritabanı henüz bağlantı kabul etmiyor olabilir. Health check tam olarak bunu çözer.

Health Check Tanımlama

services:
  postgres:
    image: postgres:16-alpine
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 10s       # Her 10 saniyede kontrol et
      timeout: 5s          # 5 saniyede cevap gelmezse fail
      retries: 5           # 5 kez fail olursa "unhealthy"
      start_period: 30s    # İlk 30 saniye kontrol etme (başlangıç süresi)

  redis:
    image: redis:7-alpine
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 10s
      timeout: 3s
      retries: 3

  api:
    build: .
    healthcheck:
      test: ["CMD-SHELL", "curl -f http://localhost:8080/actuator/health || exit 1"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 60s    # Spring Boot uygulaması yavaş başlar

docker compose ps ile healthy, unhealthy, starting durumlarını görebilirsin. Health check'in gerçek gücü depends_on ile birleştiğinde ortaya çıkar.

10. depends_on ve Startup Order

Basit depends_on: [postgres, redis] sadece başlatma sırasını belirler. Ama container'ın "başlamış" olması, uygulamanın "hazır" olduğu anlamına gelmez!

Condition ile Akıllı Bekleme

services:
  app:
    depends_on:
      postgres:
        condition: service_healthy    # Sağlık kontrolünü geç → sonra başla
      redis:
        condition: service_healthy
      migrations:
        condition: service_completed_successfully  # Migration bitmeden başlama

Üç condition türü:

• `service_started`: Container başladığında (varsayılan, güvenilmez)

• `service_healthy`: Health check "healthy" döndüğünde (önerilen)

• `service_completed_successfully`: Container exit code 0 ile tamamlandığında (migration, seed gibi tek seferlik işler)

Tipik akış: PostgreSQL service_healthy → Migration service_completed_successfully → Uygulama başlar. Bu sayede uygulama her zaman güncel veritabanı şemasıyla çalışır.

11. Production vs Development Compose

Geliştirme ve production ortamları farklı ihtiyaçlara sahiptir. Compose bunu override dosyaları ile çözer.

Strateji: Base + Override

Compose override dosyaları ile aynı temel yapılandırmayı farklı ortamlarda farklı şekilde kullanabilirsin:

• docker-compose.yml — Her ortamda ortak olan temel yapı

• docker-compose.override.yml — Geliştirme ayarları (otomatik yüklenir)

• docker-compose.prod.yml — Production ayarları

# docker-compose.override.yml — Geliştirme
services:
  api:
    build: .
    ports:
      - "8080:8080"
      - "5005:5005"             # Debug portu
    volumes:
      - ./src:/app/src          # Hot reload
    environment:
      NODE_ENV: development
    command: npm run dev

  postgres:
    ports:
      - "5432:5432"
    environment:
      POSTGRES_PASSWORD: devpassword

# docker-compose.prod.yml — Production
services:
  api:
    restart: always
    environment:
      NODE_ENV: production
    deploy:
      resources:
        limits:
          memory: 512M
          cpus: "0.5"
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"

  postgres:
    restart: always
    environment:
      POSTGRES_PASSWORD: ${DB_PASSWORD}

# Geliştirme (override.yml otomatik merge edilir)
docker compose up

# Production
docker compose -f docker-compose.yml -f docker-compose.prod.yml up -d

12. Docker Compose vs Kubernetes: Ne Zaman Hangisi?

Bu soruyu çok duyarsın: "Compose yeterli mi, Kubernetes'e geçmeli miyim?"

Tavsiye: Başlangıç noktası her zaman Compose olsun. Tek sunucuda çalışan uygulamayı Kubernetes'e taşımak gereksiz karmaşıklık ekler. Projen birden fazla sunucuya ölçeklendiğinde Kubernetes'e geç. Compose'daki services, volumes, networks kavramları Kubernetes'teki Pod, PersistentVolume, Service kavramlarının temelini oluşturur — öğrenme süreci hızlanır.

13. İleri Seviye: Compose Profiles

Her servisi her zaman başlatmak istemezsin. Debugging araçları, monitoring servisleri gibi opsiyonel bileşenler için profiles kullan:

services:
  api:
    build: .
    ports:
      - "8080:8080"

  postgres:
    image: postgres:16-alpine

  pgadmin:
    image: dpage/pgadmin4
    ports:
      - "5050:80"
    profiles:
      - debug          # Sadece --profile debug ile başlar

  prometheus:
    image: prom/prometheus
    profiles:
      - monitoring     # Sadece --profile monitoring ile başlar

docker compose up -d                         # Sadece temel servisler
docker compose --profile debug up -d         # + debug araçları
docker compose --profile monitoring up -d    # + monitoring

14. Yaygın Hatalar ve Çözümleri

Hata 1: Port Çakışması

Error: Bind for 0.0.0.0:5432 failed: port is already allocated

Host'ta zaten PostgreSQL çalışıyor. Çözüm: farklı port kullan veya host servisi durdur.

ports:
  - "5433:5432"    # Host'ta 5433, container'da 5432

Hata 2: "Connection Refused"

En sık karşılaşılan sorun. Kontrol listesi: (1) Servis adını doğru yaz (postgres, localhost değil), (2) depends_on + healthcheck kullan, (3) Container portunu kullan (host portu değil!).

# ❌ YANLIŞ            →  # ✅ DOĞRU
DB_HOST: localhost      →  DB_HOST: postgres
DB_PORT: 5433           →  DB_PORT: 5432

Hata 3: Build Cache Sorunları

Kod değiştiğinde eski imaj kullanılıyor. Çözüm: docker compose build --no-cache && docker compose up -d --force-recreate

15. Best Practices — En İyi Uygulamalar

1. İmaj versiyonu belirt: postgres:16-alpine ✅ — postgres:latest ❌

2. Şifreleri .env'e koy: .env dosyasını .gitignore'a ekle

3. Health check kullan: depends_on + condition: service_healthy

4. Named volume tercih et: Bind mount dev'de, named volume prod'da

5. Resource limit koy: deploy.resources.limits ile CPU/RAM sınırla

6. Log rotasyonu ayarla: logging.options.max-size: "10m" ile disk dolmasını engelle

7. Alpine imajları tercih et: node:20-alpine (50MB) vs node:20 (350MB)

8. `restart: unless-stopped` kullan: Container çökünce otomatik kalkması için

Sıkça Sorulan Sorular (SSS)

Docker Compose ücretsiz mi?

Evet, tamamen ücretsiz ve açık kaynak. Docker Engine ile birlikte gelir.

docker-compose.yml ile compose.yml farkı nedir?

İkisi de geçerli. compose.yml daha yeni standart, docker-compose.yml eski ama hâlâ çalışır. Compose her ikisini de otomatik algılar.

Docker Compose production'da kullanılabilir mi?

Evet, tek sunuculu uygulamalar için gayet iyi çalışır. restart: always, health check, resource limit ve log rotasyonu ayarladığında güvenilir bir ortam elde edersin.

Compose dosyasında hangi versiyon numarasını kullanmalıyım?

Hiçbirini. version: "3.8" artık gerekli değil, Compose V2 yok sayar. Dosya formatını otomatik algılar.

Docker Compose ile kaç container çalıştırabilirim?

Teknik üst sınır yok, sunucu kaynaklarına bağlı. Dev makinesinde 10-20, production'da (16GB+ RAM) 30-50 container rahat çalışır.

Özet

• Docker Compose, çoklu container uygulamaları tek bir YAML dosyasıyla tanımlayıp docker compose up ile ayağa kaldırmanı sağlar

• docker-compose.yml dört ana bölümden oluşur: services, volumes, networks, configs

• Health check + depends_on condition ile servis başlatma sırasını güvenilir şekilde yönetirsin

• Environment variables ve .env dosyası ile şifreleri koddan ayırır, ortamlar arası geçişi kolaylaştırırsın

• Override dosyaları ile aynı temel yapılandırmayı development ve production'da farklı şekilde kullanabilirsin

• Compose, Kubernetes'in alternatifi değil, tamamlayıcısıdır — küçük ölçekte Compose, büyük ölçekte Kubernetes

Docker'ı Derinlemesine Öğrenmek İstersen

Docker dünyası bundan çok daha geniş: [Dockerfile optimizasyonu](/blog/docker-multi-stage-build-kucuk-guvenli-imageler), container security, CI/CD entegrasyonu ve dahası...

🎓 [tolgahan.dev'de 60 derslik ücretsiz Docker kursu](/courses/docker-sifirdan-uzmanliga) ile Docker'ı sıfırdan uzmanlığa kadar öğren. İnteraktif quizler ve gerçek dünya projeleriyle bir hafta içinde production ortam yönetecek seviyeye gel!