Giriş

Docker Compose, tek bir host üzerinde çok container'lı bir uygulamayı çalıştırmanın hâlâ en hızlı yolu — ama dolaşımdaki tavsiyelerin önemli bir kısmı artık var olmayan bir aracı anlatıyor. Önce iki şeyin ezberini bozmak gerekiyor: Compose v2 bir Docker CLI eklentisi olarak geliyor, docker compose (tiresiz) şeklinde çağrılıyor ve Docker Desktop ya da docker-compose-plugin paketiyle kuruluyor — bağımsız docker-compose v1 binary'si Temmuz 2023'te güncelleme almayı bıraktı; dolayısıyla onu indirip chmod'lamanızı söyleyen her eğitim içeriği güncelliğini yitirmiş durumda. Dosyanın en üstündeki version: anahtarı da artık geçersiz: birleştirilmiş Compose Specification, eski v2/v3 dosya formatlarının yerini aldı ve güncel Compose bu anahtar mevcut olduğunda uyarı basıyor. Dosyaya compose.yaml adını verin ve doğrudan services: ile başlayın.

Çalışan Bir Örnek

services:
  app:
    image: ghcr.io/acme/shop-api:1.8.3
    restart: unless-stopped
    environment:
      DATABASE_URL: postgres://shop:${DB_PASSWORD:?set in .env}@db:5432/shop
    ports:
      - "8080:8080"
    depends_on:
      db:
        condition: service_healthy

  db:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      POSTGRES_USER: shop
      POSTGRES_DB: shop
      POSTGRES_PASSWORD: ${DB_PASSWORD:?set in .env}
    volumes:
      - db-data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U shop -d shop"]
      interval: 5s
      timeout: 3s
      retries: 10

  adminer:
    image: adminer:4
    ports:
      - "8081:8080"
    profiles: ["debug"]

volumes:
  db-data:

Önemli Olan Pratikler

1. depends_on'u Bir Healthcheck ile Eşleştirin

Bu, klasik Compose tuzağıdır: depends_on tek başına yalnızca başlatma sırasını kontrol eder — bağımlılığın hazır olmasını beklemez; yani uygulama, henüz bağlantı kabul etmeyen bir Postgres ile yarışmaya devam eder. Çözüm örnekte gösterilen: bağımlılığa bir healthcheck verin ve bağımlı serviste condition: service_healthy bildirin. Compose bu durumda veritabanı gerçekten yanıt verene kadar uygulamayı bekletir.

2. Ortam Değişkenlerinde Fail-Fast Davranın

Compose, ${DEĞİŞKENLER}'i shell'den ve compose dosyasının yanındaki .env dosyasından enterpolasyonla doldurur. Zorunlu olan her değer için ${VAR:?mesaj} biçimini kullanın; böylece eksik bir secret, yarı yapılandırılmış bir stack üretmek yerine başlatmayı net bir hatayla durdurur. .env'i versiyon kontrolünün dışında tutun; onun yerine bir .env.example commit'leyin.

3. Opsiyonel Servisler için Profil Kullanın

Yukarıdaki adminer servisi gibi debug araçlarının her docker compose up'ta çalışması gerekmez. Ona bir profil atayın ve yalnızca istediğinizde dahil edin: docker compose --profile debug up. Profiller, blokları yorum satırına alıp çıkarmak zorunda kalmadan tek dosyanın birden fazla iş akışına hizmet etmesini sağlar.

4. Ortamları Override Dosyalarıyla Ayırın

compose.yaml'ı nötr taban olarak tutun. Compose, compose.override.yaml'ı otomatik olarak birleştirir — build: bölümleri, bind mount'lar ve dışarı açılan debugger portları gibi yalnızca geliştirmeye özgü konuların doğru yeri burasıdır. Diğer ortamlar için dosyaları açıkça geçin (docker compose -f compose.yaml -f compose.prod.yaml up -d) ve birleştirilmiş sonucu docker compose config ile inceleyin. Bu katmanlama, extends'in tarihsel kullanımlarının çoğunun yerini aldı.

5. Production'da Sürümlü İmaj Çekin, Build'i Lokalde Yapın

Genelgeçer bir "registry imajı yerine build: kullanın" önerisi, laptop dışındaki her senaryo için tersinden bir tavsiyedir. İmajı CI bir kez build edip registry'ye push etmeli; her deployment ise aynı sabitlenmiş tag'i çekmeli — örnek shop-api:1.8.3'ü sabitliyor, asla :latest'ı değil. build:'i dev override dosyasına saklayın. O registry'yi seçmek ve sıkılaştırmak başlı başına bir konu — Docker imajları nerede saklanır rehberimize bakın.

6. State için Adlandırılmış Volume Kullanın

db-data gibi adlandırılmış volume'lar docker compose down'dan sağ çıkar ve temiz biçimde yeniden oluşturulur; ayrıca veritabanının iç dosyalarını proje dizininizin dışında tutarlar. Bind mount'ları geliştirme ortamında kaynak kod için saklayın.

Kubernetes'e Ne Zaman Geçmeli

Compose tek host'luk bir araçtır ve bu bir özelliktir: tek sunucu söz konusuysa basitlikte bir cluster'ı her seferinde yener. İleri geçişin dürüst tetikleyicileri, Compose'un yapısal olarak karşılayamayacağı ihtiyaçlardır — host'lar arası yüksek erişilebilirlik, autoscaling, otomatik rollback'li rolling deployment'lar ve birinci sınıf secret yönetimi. Bunlar yol haritanızda belirmeye başladıysa, karar vermeden önce gerçek hayatta Kubernetes notlarımızı okuyun; operasyonel fatura gerçektir. DevOps ekibimiz, ekiplerin bu çizginin hangi tarafında olduklarına karar vermelerine düzenli olarak yardımcı oluyor — ve pek çok production iş yükü, gayet haklı olarak, hâlâ Compose üzerinde.

Bunu production'da mı çalıştıracaksınız? AWS Yönetilen Hizmetler ekibimiz böyle ortamları 7/24 işletir — izleme, olay müdahalesi, yama ve maliyet kontrolü; ismini bildiğiniz kıdemli mühendislerle, aylık 3.000 €'dan başlayan fiyatlarla.

Etiketler: #Docker #DevOps #Container #Mikroservisler