Docker Compose deploy ile Kaynak Limitleri, restart_policy ve GPU Rezervasyonu

deploy bölümündeki alanlar

Bu alanların bir kısmı çok düğümlü bir platformu varsayar. Swarm belgesindeki notta belirtildiği gibi Compose swarm modundan yararlanmaz ve her şeyi tek düğüme dağıtır; Engine swarm modundayken docker compose up çalıştırırsanız tüm container'ların mevcut düğümde zamanlandığını söyleyen bir uyarı görürsünüz. Tek bir VPS üzerinde en çok kullanacağınız kısım bu yüzden resources ve restart_policy olacaktır.

resources: limits ve reservations

Belirtim iki tür kısıt tanımlar. limits için platform, container'ın daha fazla kaynak ayırmasını engellemelidir. reservations için platform, container'ın en azından yapılandırılan miktarı ayırabileceğini garanti etmelidir. Her ikisinin altında şu alanlar yer alır:

• cpus: Container'ın kullanabileceği CPU miktarı, çekirdek sayısı olarak. "0.50" yarım çekirdek, "1.5" bir buçuk çekirdek demektir.
• memory: Bellek miktarı, bayt değeri biçiminde bir metin. Desteklenen birimler b, k veya kb, m veya mb, g veya gb'dir; 300m, 1gb, 2048k gibi.
• pids: Container'ın süreç kimliği (PID) sınırı, tam sayı olarak.
• devices: Yalnızca rezervasyonlarda; GPU gibi cihazların ayrılması. Aşağıda ayrı başlıkta anlatılıyor.

services:
  api:
    image: example/api:1.4
    deploy:
      resources:
        limits:
          cpus: "1.5"
          memory: 512M
          pids: 200
        reservations:
          cpus: "0.25"
          memory: 128M
      restart_policy:
        condition: on-failure
        delay: 5s
        max_attempts: 3
        window: 120s
  db:
    image: postgres:18
    deploy:
      resources:
        limits:
          memory: 1g

docker compose config bu dosyayı normalize ettiğinde api servisinin deploy bölümü şöyle göründü:

    deploy:
      resources:
        limits:
          cpus: 1.5
          memory: "536870912"
          pids: 200
        reservations:
          cpus: 0.25
          memory: "134217728"
      restart_policy:
        condition: on-failure
        delay: 5s
        max_attempts: 3
        window: 2m0s

Çıktı iki şeyi doğruluyor: bellek değerleri bayta çevrildi (512M için 536870912, 128M için 134217728, db servisindeki 1g için 1073741824) ve 120s süresi 2m0s olarak yazıldı. Süreler {değer}{birim} biçimindedir; desteklenen birimler us, ms, s, m ve h'dir ve 1m30s gibi ayırıcısız birleştirilebilir. Bir değerin gerçekte nasıl yorumlandığından emin olmak için bu çıktıya bakmak iyi bir alışkanlıktır.

Rezervasyonun Docker Engine tarafındaki karşılığı hakkında bir hatırlatma: Engine belgesine göre --memory-reservation yumuşak bir sınırdır; host'ta bellek çekişmesi veya darlık algılandığında devreye girer ve container'ın bu değeri aşmayacağını garanti etmez, ayrıca etkili olması için --memory değerinden küçük olmalıdır. Varsayılan olarak bellek tükendiğinde (OOM) çekirdek container içindeki süreçleri öldürür. Bu yüzden rezervasyonu bir güvenlik payı değil, planlama bilgisi olarak düşünün ve her serviste bir limits.memory tanımlayın. Ayrıntılar CPU ve bellek limiti yazısında.

Servis düzeyindeki eşdeğerlerle tutarlılık

Compose dosyasında bazı kaynak ayarlarının servis düzeyinde de bir karşılığı vardır: cpus, mem_limit, mem_reservation ve pids_limit. Belirtim, ikisi birden verildiğinde değerlerin deploy belirtimindekilerle tutarlı olması gerektiğini söyler. Compose v5.5.1 bu kuralı uyguluyor; mem_limit: 256m ile deploy.resources.limits.memory: 512M birlikte yazıldığında doğrulama şu hatayla durdu:

docker compose config --quiet
services.api: can't set distinct values on 'mem_limit' and 'deploy.resources.limits.memory': invalid compose project

Aynı kural replika sayısı için de geçerli: servis düzeyindeki scale: 2 ile deploy.replicas: 3 birlikte yazıldığında Compose can't set distinct values on 'scale' and 'deploy.replicas' hatası verdi. Pratik öneri, her ayarı tek yerde tanımlamaktır; ekibinizin dosyalarında hangisini kullanacağınıza karar verin ve diğerini yazmayın.

Swap için deploy bölümünde bir alan yoktur; bunun için servis düzeyindeki memswap_limit kullanılır ve yalnızca bellek sınırı da verilmişse anlam taşır. Belirtimdeki kurallar şöyledir:

Belirtim, belleği sık sık diske taşıyan uygulamalar için bir performans bedeli olduğunu da hatırlatır. Ayrıca mem_swappiness ile 0 ile 100 arasında, anonim bellek sayfalarının swap'a atılma eğilimini ayarlayabilirsiniz.

restart_policy

restart_policy, container çıktığında yeniden başlatılıp başlatılmayacağını ve nasıl başlatılacağını belirler. Bu alan verilmezse Compose servis yapılandırmasındaki restart alanını dikkate alır. Alanlar şunlardır:

• condition: none çıkış kodu ne olursa olsun yeniden başlatmaz; on-failure yalnızca sıfır dışı çıkış kodunda yeniden başlatır; any (varsayılan) her durumda yeniden başlatır.
• delay: Denemeler arasındaki bekleme süresi. Varsayılanı 0'dır, yani deneme hemen yapılabilir.
• max_attempts: Vazgeçmeden önce izin verilen başarısız deneme sayısı; varsayılan sınırsızdır.
• window: Yeniden başlatmanın başarılı sayılıp sayılmayacağına karar vermeden önce beklenecek süre. Varsayılan olarak sonuç yeniden başlatmadan hemen sonra değerlendirilir.

max_attempts ile window arasındaki ilişki dikkat ister. Bir deneme ancak container window süresi içinde başarıyla yeniden başlamazsa başarısız sayılır. Belirtimdeki örneğe göre max_attempts: 2 iken Compose, bu tanıma uyan iki başarısız deneme olana kadar tekrar dener; bu, ikiden fazla deneme anlamına gelebilir. Servis düzeyindeki restart değerleri (no, always, on-failure[:max-retries], unless-stopped) ve aralarındaki farklar Docker restart policy yazısında anlatılıyor.

replicas, mode ve endpoint_mode

Servis replicated moddaysa (varsayılan budur) replicas aynı anda çalışması gereken container sayısını belirtir. mode alanı dört değer alır: replicated belirtilen sayıda görevi sürekli çalıştırır; global her fiziksel düğümde tam olarak bir görev çalıştırır; replicated-job belirtilen sayıda görevi 0 koduyla tamamlanana kadar çalıştırır; global-job her düğümde bir tamamlanan görev çalıştırır ve yeni eklenen düğümlerde de kendiliğinden çalışır. İş modları 0 koduyla biten görevler için tasarlanmıştır, tamamlanan görevler elle kaldırılana kadar kalır ve eşzamanlılığı sınırlayan max-concurrent seçeneği Compose'ta değil yalnızca CLI'da vardır.

services:
  worker:
    image: example/worker:2.0
    deploy:
      mode: replicated
      replicas: 3
      resources:
        limits:
          cpus: "0.50"
          memory: 256M
      update_config:
        parallelism: 1
        delay: 10s
        failure_action: rollback
        order: start-first
      rollback_config:
        parallelism: 1
        order: stop-first
      placement:
        constraints:
          - node.labels.disktype==ssd
  backup:
    image: example/backup
    deploy:
      mode: replicated-job
      replicas: 1

endpoint_mode, dış istemcilerin servise nasıl bağlanacağını belirler. vip servise sanal bir IP atar ve platform, istemcinin kaç düğüm olduğunu bilmesine gerek kalmadan istekleri yönlendirir. dnsrr ise servis adı için DNS sorgusunun IP listesi döndürmesini sağlar (DNS round-robin) ve istemci bunlardan birine doğrudan bağlanır. deploy.labels ile verilen etiketler yalnızca servise uygulanır; container'lara etiket eklemek için servis düzeyindeki labels kullanılır.

placement, update_config ve rollback_config

placement.constraints, container'ın çalışacağı düğümün sağlaması gereken özellikleri tanımlar; örnekteki node.labels.disktype==ssd yalnızca bu etiketi taşıyan düğümleri seçer. placement.preferences görevleri bir düğüm etiketinin değerlerine eşit dağıtmak için bir strateji tanımlar; şu an desteklenen tek strateji spread'dir. Tek sunuculu bir Compose kurulumunda seçilecek başka düğüm olmadığı için bu alanlar Swarm gibi çok düğümlü platformlarda anlam kazanır; Swarm kurulumu için Docker Swarm kurulumu yazısına bakın.

update_config kademeli güncellemeyi ayarlar: parallelism aynı anda güncellenecek container sayısı, delay gruplar arasındaki bekleme, failure_action güncelleme başarısız olursa yapılacak iş (continue, rollback veya varsayılan pause), monitor her görev güncellemesinden sonra hatanın izleneceği süre, max_failure_ratio katlanılacak hata oranı ve order işlem sırasıdır. order için stop-first (varsayılan) eski görevi durdurup yenisini başlatır, start-first önce yenisini başlatır ve çalışan görevler kısa süre üst üste biner. rollback_config aynı alanları geri alma için kullanır; burada parallelism: 0 tüm container'ların aynı anda geri alınması demektir ve failure_action yalnızca continue veya pause olabilir.

GPU ve diğer cihaz rezervasyonları

Docker host'unda GPU varsa ve daemon buna göre yapılandırılmışsa Compose servisleri GPU rezervasyonu tanımlayabilir. Bunun için önce Engine belgesindeki GPU ön koşullarını kurmanız gerekir. Rezervasyon deploy.resources.reservations.devices altında bir liste olarak yazılır ve her öğe şu alanları alabilir:

• capabilities: Metin listesi; tek zorunlu alandır. Tanınan genel yetenekler gpu ve tpu'dur; sürücüye özel yetenekler ad çakışmasını önlemek için sürücü adıyla öneklenir. Cihaz istenen tüm yetenekleri sağlamalıdır.
• driver: İstenen cihaz sürücüsü, örneğin nvidia.
• count: Tam sayı veya all. all ise veya hiç verilmezse yeteneklere uyan tüm cihazlar ayrılır.
• device_ids: Host'taki cihaz kimliklerinin listesi; NVIDIA kartlarda kimlikleri host'ta nvidia-smi çıktısında görürsünüz.
• options: Sürücüye özel anahtar ve değer çiftleri.

services:
  test:
    image: nvidia/cuda:12.9.0-base-ubuntu22.04
    command: nvidia-smi
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 1
              capabilities: [gpu]

Belgelerdeki bu örnek tek bir GPU ayırır. İki kural Compose v5.5.1 doğrulamasında da zorlandı. count ile device_ids birlikte yazıldığında doğrulama "count" and "device_ids" attributes are exclusive hatasıyla durdu. capabilities alanı olmayan bir rezervasyon ise missing property 'capabilities' hatası verdi. Belgeler ayrıca geçersiz bir cihaz kimliği veya host'taki GPU sayısından büyük bir count kullanıldığında da hata döndüğünü belirtir; bunlar host'a bağlı olduğu için dosya doğrulamasında değil, servis başlatılırken ortaya çıkar.

Sık yapılan hatalar

• Aynı sınırı iki yerde farklı vermek. mem_limit ile limits.memory, scale ile replicas çelişirse dosya reddedilir.
• Reservations değerini sınır sanmak. Rezervasyon en az miktarı tanımlar; üst sınır için limits gerekir.
• Bellek birimini yanlış yazmak. Değer bayt değeri metnidir; normalize edilmiş çıktıyı docker compose config ile kontrol edin.
• Tek sunucuda placement kısıtına güvenmek. Compose her şeyi mevcut düğüme dağıtır; placement çok düğümlü platformlar içindir.
• GPU rezervasyonunda capabilities yazmamak. Bu alan zorunludur.
• count ve device_ids alanlarını birlikte kullanmak. İkisi birbirini dışlar; birini seçin.

Sık Sorulan Sorular

deploy.resources tek sunucudaki docker compose up ile kullanılabilir mi?

Kaynak sınırları ve rezervasyonlar Compose Deploy belirtiminin parçasıdır; belgelerdeki GPU örneği de rezervasyonu docker compose up ile çalıştırır. Compose ayrıca bu değerlerin mem_limit gibi servis düzeyindeki alanlarla tutarlı olmasını zorunlu tutar. Placement gibi düğüm seçimine dayanan alanlar ise tek düğümde anlam taşımaz, çünkü Compose her şeyi mevcut düğüme dağıtır.

cpus: "0.5" ne anlama gelir?

Container'ın kullanabileceği CPU miktarının çekirdek sayısı olarak yarım çekirdek olduğunu. Servis düzeyindeki cpus alanı da kesirli bir sayıdır ve 0.000 sınır yok demektir.

restart_policy ile restart birlikte yazılırsa hangisi geçerli olur?

Belirtime göre restart_policy ayarlanmamışsa Compose servisteki restart alanını dikkate alır. Karışıklığı önlemek için ikisinden yalnızca birini kullanın.

update_config tek sunucuda işe yarar mı?

update_config ve rollback_config, görevleri kademeli güncelleyen bir platform için tasarlanmıştır. Swarm'da servis güncellemeleri Docker stack deploy yazısında anlatılıyor.

Marka adları sahiplerine aittir. Bu yazı bağımsız bir teknik rehberdir; adı geçen kuruluşlarla bayilik veya ortaklık ilişkisi bulunduğu anlamına gelmez.

İlgili içerikler: Docker öğrenme rehberi · Docker CPU ve bellek limiti · Docker restart policy · docker stats ve metrikler · Docker stack deploy · Docker Compose rehberi