Docker daemon.json Yapılandırma: Konum, Anahtarlar, Restart ve Reload

Daemon'ı yapılandırmanın iki yolu

Belgelere göre daemon iki şekilde yapılandırılır: bir JSON yapılandırma dosyasıyla veya dockerd başlatılırken verilen bayraklarla. Tercih edilen yol dosyadır, çünkü tüm ayarları tek yerde tutar. İkisini birlikte kullanabilirsiniz, ancak bir koşulla: aynı seçenek hem bayrak hem dosya içinde verilmemelidir. Bu olursa daemon başlamaz ve bir hata mesajı yazar.

Bayraklarla elle başlatma özellikle sorun giderme sırasında işe yarar. Belgelerdeki örnek şöyledir:

dockerd --debug \
  --tls=true \
  --tlscert=/var/docker/server.pem \
  --tlskey=/var/docker/serverkey.pem \
  --host tcp://192.168.59.3:2376

Kullanılabilir tüm seçenekleri dockerd --help çıktısında ve dockerd başvuru belgelerinde bulabilirsiniz. Elle başlatılan daemon ön planda çalışır ve loglarını doğrudan terminale yazar; Ctrl+C ile durdurulur. Production'da ise daemon systemd gibi bir sistem aracıyla başlatılır.

Dosya nerede durur?

Rootless modda daemon XDG_CONFIG_HOME değişkenine uyar; değişken tanımlıysa dosya $XDG_CONFIG_HOME/docker/daemon.json yolunda aranır. Ayrıca daemon'ı başlatırken dockerd --config-file bayrağıyla dosyanın konumunu açıkça belirtebilirsiniz. Rootless kurulumun kendisi Docker rootless mod yazısında.

Değişiklikleri uygulamak: restart mı, reload mı?

daemon.json dosyasını kaydetmek tek başına bir şey değiştirmez; daemon'ın dosyayı yeniden okuması gerekir. Belgeler iki yol gösterir. Birincisi yeniden başlatmadır: sudo systemctl restart docker. İkincisi yapılandırmayı yeniden yüklemektir: systemd kullanıyorsanız systemctl reload docker, kullanmıyorsanız dockerd sürecine SIGHUP sinyali göndermek. Hangi ayarın hangi yolla uygulanacağını ilgili belge sayfası belirtir; aşağıdaki tabloda bunları topladık.

Yeniden başlatmanın bir bedeli vardır: belgelere göre daemon sonlandığında varsayılan olarak çalışan container'ları da kapatır. Live restore açıksa (aşağıda) container'lar daemon yeniden başlarken çalışmaya devam eder. Bu yüzden önce live restore'u etkinleştirmek, sonraki daemon değişikliklerinin kesinti etkisini azaltır.

Bir sunucu için örnek daemon.json

Aşağıdaki dosya, belgelerde ayrı ayrı anlatılan dört ayarı tek dosyada birleştirir: json-file log sürücüsü için rotasyon, live restore ve Prometheus metriklerinin yalnızca loopback arayüzünde yayımlanması.

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  },
  "live-restore": true,
  "metrics-addr": "127.0.0.1:9323"
}

• log-driver ve log-opts: varsayılan sürücü zaten json-file'dır; max-size ve max-file otomatik log rotasyonunu açar. Belgelere göre log-opts değerleri dize olmak zorundadır, bu yüzden "3" tırnak içindedir.
• live-restore: daemon kapandığında veya yeniden başladığında container'ların çalışmaya devam etmesini sağlar.
• metrics-addr: Docker'ın Prometheus uyumlu metriklerini 127.0.0.1:9323 adresinde sunar. Belgeler 0.0.0.0 kullanmanın Prometheus portunu geniş ağa açacağını ve tehdit modelinizi buna göre değerlendirmeniz gerektiğini söyler.

Dosyayı kaydettikten sonra daemon'ı yeniden başlatın. Log ayarları için belgelerin önemli bir uyarısı vardır: yeni log yapılandırması yeniden başlatmadan sonra oluşturulan container'lara uygulanır; mevcut container'lar yeni ayarı kendiliğinden kullanmaz, onları yeniden oluşturmanız gerekir. Log sürücülerinin ayrıntısı Docker log boyutunu sınırlama, metriklerin toplanması ise docker stats ve container metrikleri yazısında.

Sık kullanılan anahtarlar ve nasıl uygulandıkları

Tablo, belgelerin ilgili sayfalarda verdiği talimatları özetler; bir anahtarı ilk kez kullanırken o sayfadaki notları da okuyun. Aşağıda en çok soru getiren anahtarları ayrıca açıklıyoruz.

data-root: veri dizinini taşımak

Daemon tüm verisini tek bir dizinde tutar: container'lar, imajlar, volume'lar, servis tanımları ve secret'lar. Linux'ta varsayılan dizin /var/lib/docker'dır. Disk alanı ayrı bir bölümdeyse "data-root": "/mnt/docker-data" gibi bir değerle bu dizini değiştirebilirsiniz.

Burada Engine 29 ile gelen bir ayrıntı önemlidir. Belgelere göre containerd image store, Docker Engine 29.0 ve sonrasında yeni kurulumların varsayılanıdır; bu durumda imaj içerikleri ve container snapshot'ları /var/lib/containerd altında tutulur ve data-root bu veriyi etkilemez. containerd snapshotter'larının konumunu değiştirmek için sistem containerd yapılandırma dosyasındaki (/etc/containerd/config.toml) root ayarı kullanılır. Yükseltilmiş kurulumlarda varsayılan olan overlay2 gibi klasik depolama sürücülerinde ise tüm veri /var/lib/docker altındadır. Belgeler ayrıca her daemon için ayrı bir dizin kullanmanızı, iki daemon'ın aynı dizini (örneğin bir NFS paylaşımını) paylaşmasının teşhisi zor hatalara yol açtığını vurgular. Ayrıntılar containerd image store ve storage driver ve overlay2 yazılarında.

live-restore: ayrıntılar ve sınırlar

Live restore'u etkinleştirmek için ya dosyaya "live-restore": true yazarsınız ya da dockerd'yi --live-restore bayrağıyla başlatırsınız; belgeler ikisinden yalnızca birini yapmanızı söyler. Bayrak yöntemi önerilmez, çünkü systemd gibi bir süreç yöneticisinin kuracağı ortamı kurmaz ve beklenmedik davranışa yol açabilir. Dosyayı değiştirdikten sonra Linux'ta yeniden başlatma yerine systemctl reload docker ile yükleyerek container kesintisinden kaçınabilirsiniz.

Sınırlar şunlardır. Live restore yalnızca yama sürümü (YY.MM.x) güncellemelerinde container'ları ayakta tutar, ana sürüm (YY.MM) yükseltmelerinde desteklenmez; sürüm atlarsanız daemon container'larla bağlantısını geri kuramayabilir. Köprü IP adresleri veya graph driver gibi daemon düzeyindeki seçenekler değiştiyse yine çalışmayabilir. Daemon uzun süre kapalı kalırsa container'lar daemon'ın normalde okuduğu FIFO log tamponunu (varsayılan 64K) doldurabilir ve log yazamaz hale gelir; tamponu boşaltmak için daemon'ı yeniden başlatmanız gerekir. Linux'ta tampon boyutu /proc/sys/fs/pipe-max-size ile değiştirilebilir. Son olarak live restore yalnızca bağımsız container'lar içindir, Swarm servislerini kapsamaz.

proxies ve registry-mirrors

Kurumsal bir ağda daemon'ın Docker Hub'a ve diğer registry'lere bir proxy üzerinden çıkması gerekiyorsa proxies nesnesi kullanılır:

{
  "proxies": {
    "http-proxy": "http://proxy.example.com:3128",
    "https-proxy": "http://proxy.example.com:3128",
    "no-proxy": "*.test.example.com,.example.org,127.0.0.0/8"
  }
}

Bu ayar yalnızca daemon'ın kendi bağlantılarını etkiler; Docker CLI'nin proxy ayarı ayrıdır. Belgelere göre daemon yapılandırması, systemd ortam değişkenleriyle (HTTP_PROXY, HTTPS_PROXY, NO_PROXY) verilen ayarlara göre önceliklidir ve değişiklikten sonra daemon'ın yeniden başlatılması gerekir. Docker Desktop ise daemon.json içindeki proxy ayarlarını yok sayar.

registry-mirrors anahtarı, Docker Hub için kendi kurduğunuz bir aynalama sunucusunu tanımlar: "registry-mirrors": ["https://<my-docker-mirror-host>"]. Aynı ayar elle başlatmada --registry-mirror bayrağıyla da verilebilir. Pull limitleri ve aynalamanın bu konudaki yeri Docker Hub pull limiti yazısında.

runtimes ve features

Docker Engine, container yaşam döngüsünü containerd ile yönetir ve containerd varsayılan olarak runc kullanır. containerd shim API'sini uygulayan bir runtime'ı PATH'e kurduysanız ek yapılandırma gerekmez; PATH dışında duruyorsa veya runc yerine geçen bir runtime ise runtimes nesnesine kaydedersiniz ve yapılandırmayı yeniden yüklersiniz. Belgelerdeki youki örneği şöyledir:

{
  "runtimes": {
    "youki": {
      "path": "/usr/local/bin/youki"
    }
  }
}

features nesnesi özellik anahtarlarını tutar. "containerd-snapshotter": true, eski bir sürümden yükselttiğiniz kurulumda containerd image store'u açar; belgeler depolama altyapısını değiştirmenin diğer altyapıyla oluşturulmuş imajları ve container'ları geçici olarak gizlediğini (veri diskte kalır) uyarır. "embedded-containerd": true ise Engine 29.7.0 ile gelen ve containerd'yi dockerd ile aynı süreçte çalıştıran deneysel bir özelliktir; davranışı değişebilir veya ileride kaldırılabilir.

default-ulimits: Engine 29 ile değişen dosya tanımlayıcı sınırı

Engine 29.0.0 sürüm notlarına göre containerd v2.1.5 güncellemesiyle container'lar için açık dosya tanımlayıcı sınırı (ulimit -n) 1048576 değerinden systemd varsayılanı olan 1024'e indi. İş yükünüz daha yüksek bir sınıra ihtiyaç duyuyorsa notlar docker run ile --ulimit kullanmanızı veya varsayılanı daemon.json içinde ayarlamanızı önerir:

{
  "default-ulimits": {
    "nofile": {
      "Name": "nofile",
      "Soft": 1048576,
      "Hard": 1048576
    }
  }
}

Dosyayı başlatmadan önce doğrulamak

Bozuk bir daemon.json daemon'ın hiç başlamamasına yol açabileceği için değişiklikten sonra kontrol etmek iyi bir alışkanlıktır. Engine 23.0 sürüm notları, daemon JSON yapılandırmasını kontrol edip çıkan dockerd --validate seçeneğini duyurur; Engine 29.2.0 notlarına göre bu bayrak artık sistem gereksinimlerini de doğrular:

sudo dockerd --validate

Belgelerdeki hata ayıklama sayfası JSON yazımıyla ilgili pratik bir uyarı da yapar: dosyada zaten içerik varsa yeni anahtarı eklerken, son satır değilse satır sonuna virgül koymaya dikkat edin. Daemon başlamazsa nedenini logda görürsünüz; log okuma ve sık başlatma hataları Cannot connect to the Docker daemon hatası yazısında.

Sık yapılan hatalar

• Aynı ayarı hem bayrakta hem dosyada vermek: belgelere göre daemon başlamaz. En bilinen örnek hosts anahtarıdır: Debian ve Ubuntu'daki systemd servisi daemon'ı zaten -H bayrağıyla başlattığı için dosyaya hosts eklemek çakışma yaratır. Uzak erişim ayarı için Docker daemon uzak erişim yazısına bakın.
• log-opts değerlerini sayı olarak yazmak: "max-file": 3 değil "max-file": "3" yazılmalıdır.
• Log ayarının mevcut container'lara uygulandığını sanmak: yeni ayar yalnızca sonra oluşturulan container'lara uygulanır.
• metrics-addr için 0.0.0.0 kullanmak: metrik portunu tüm ağa açar; yerel erişim için 127.0.0.1 kullanın.
• data-root'u değiştirip containerd verisini unutmak: containerd image store kullanıyorsanız imajlar /var/lib/containerd altında kalır.
• JSON virgül hataları: eklediğiniz anahtardan sonra başka anahtar geliyorsa virgül gerekir; son anahtardan sonra konmaz.

Sık Sorulan Sorular

daemon.json dosyası yok, oluşturmam sorun olur mu?

Hayır. Belgeler dosyanın henüz yoksa oluşturulabileceğini açıkça söyler. Dosya boşsa doğrudan geçerli bir JSON nesnesiyle, örneğin {"debug": true} ile başlayabilirsiniz.

Published portları varsayılan olarak 127.0.0.1'e bağlayabilir miyim?

Evet; belgeler varsayılan bridge ağı için "ip": "127.0.0.1" anahtarını ve kullanıcı tanımlı ağlar için default-network-opts seçeneğini gösterir. Bu ayarların farkı ve sınırları Docker port yayınlama yazısında.

Container ağlarının kullandığı adres aralığını değiştirebilir miyim?

Evet, default-address-pools anahtarı Docker'ın ağlara subnet ayırdığı havuzları tanımlar. Belgelerdeki ayrıntılar için Docker bridge network ve Docker IPv6 yapılandırma yazılarına bakın.

Docker Desktop'ta daemon.json düzenlenir mi?

Belgeler macOS ve Windows'ta dosyanın doğrudan düzenlenmemesini, ayarların Docker Desktop ayarlarındaki Docker Engine bölümünden yapılmasını ister. Bu yazıdaki yollar Linux sunucudaki Docker Engine içindir.

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 · daemon bağlantı hatası · log boyutu ve log driver · containerd image store · daemon uzak erişim · port yayınlama