Docker Swarm ile Küme Kurulumu

Tek sunucuda Docker Compose ile çalışırken her şey yolundadır; ta ki o sunucunun bakıma girmesi gerekene kadar. O anda iki gerçekle yüzleşirsiniz: uygulamanız tek makineye bağlıdır ve o makine kapandığında hizmet de kapanır. İkinci sunucu eklemek ise beklediğinizden karmaşıktır — imajları iki yere göndermek, hangi servisin nerede çalıştığını takip etmek, ağları elle bağlamak ve güncellemeleri sırayla yapmak yeni bir iş yükü doğurur.

Docker Swarm, Docker'ın kendi içinde gelen küme yöneticisidir ve tam olarak bu ara katmanı doldurur: birden fazla sunucuyu tek bir sanal Docker motoru gibi kullanmanızı sağlar. Compose bildiğiniz için öğrenme eğrisi çok kısadır; aynı YAML biçimini kullanır, tek fark deploy bloğudur. Bu rehberde sıfırdan bir Swarm kümesi kuracağız, düğüm rollerini ve quorum mantığını açıklayacağız, ilk servisi çalıştırıp routing mesh'i göreceğiz, bir stack dağıtacağız, kesintisiz güncelleme ile geri alma yapacağız ve kalıcı veri gibi asıl zorlayan konuyu ele alacağız.

Swarm Ne Zaman Doğru Seçim#

Swarm'ın konumunu net koymak gerekir. Tek sunucuda çalışıyorsanız Compose zaten yeterlidir ve Swarm size sadece karmaşıklık ekler. Yüzlerce servisi, otomatik yatay ölçeklemeyi, gelişmiş ağ politikalarını ve geniş bir eklenti ekosistemini yönetmeniz gerekiyorsa Kubernetes daha uygun bir hedeftir.

Swarm ise tam ortadaki alanı çok iyi kapatır: iki ile on arası sunucu, bir avuç servis, kesintisiz güncelleme ihtiyacı ve küçük bir ekip. Kurulumu dakikalar sürer, öğrenilecek yeni kavram sayısı bir elin parmaklarını geçmez ve mevcut Compose dosyanız neredeyse olduğu gibi çalışır. Küçük ve orta ölçekli ekiplerde bu, "Kubernetes öğrenmeye vaktimiz yok" ile "tek sunucu yetmiyor" arasındaki en pratik köprüdür.

Compose dosyalarınızı henüz oturtmadıysanız Docker Compose kullanımı yazısındaki temeli tamamlayıp buraya dönmenizi öneririm; Swarm o bilgiyi doğrudan üzerine inşa ediyor.

Küme Kurulumu: Manager ve Worker Düğümleri#

Swarm'da iki düğüm rolü vardır. Manager düğümler kümenin durumunu tutar, kararları verir ve API'yi sunar. Worker düğümler yalnızca kendilerine verilen görevleri çalıştırır. Bir manager aynı zamanda görev de çalıştırabilir.

Kümeyi başlatmak tek komuttur. Sunucunun diğer düğümlerin erişebileceği IP adresini açıkça belirtin; birden fazla ağ arayüzü olan makinelerde bu şart:

# 1. sunucuda (ilk manager)
docker swarm init --advertise-addr 185.12.34.56

# Cikti size worker katilim komutunu verir:
# docker swarm join --token SWMTKN-1-xxxx 185.12.34.56:2377

Diğer sunuculara bu komutu yapıştırırsınız. Token'ı sonradan tekrar görmek isterseniz manager üzerinde sorabilirsiniz:

# Worker katilim komutu
docker swarm join-token worker

# Manager katilim komutu (yedek yonetici eklemek icin)
docker swarm join-token manager

# Kume durumu - yalnizca manager uzerinde calisir
docker node ls

docker node ls çıktısında MANAGER STATUS sütununda Leader yazan düğüm, o an kararları veren yöneticidir. Lider düşerse kalan yöneticiler aralarında yeni bir lider seçer; bu seçimin çalışabilmesi quorum'a bağlıdır.

Açılması Gereken Portlar#

Kurulumda en sık yaşanan sorun, düğümlerin birbirini görememesidir ve sebebi neredeyse her zaman güvenlik duvarıdır. Swarm üç ayrı kanal kullanır:

Bu portları yalnızca küme düğümlerinin IP'lerine açın, internete değil. UFW kullanıyorsanız:

# Diger dugumun IP'sine izin ver - genele acmayin
sudo ufw allow from 185.12.34.57 to any port 2377 proto tcp
sudo ufw allow from 185.12.34.57 to any port 7946
sudo ufw allow from 185.12.34.57 to any port 4789 proto udp
sudo ufw reload

UDP 4789'u unutmak özellikle sinsi bir hatadır: düğümler birbirini görür, docker node ls sağlıklı görünür, servisler dağıtılır ama konteynerler overlay ağ üzerinden birbirine erişemez. Belirti, uygulamanın veritabanına bağlanamamasıdır ve saatlerce yanlış yerde aranır.

Yönetici Sayısı ve Quorum#

Swarm, küme durumunu yöneticiler arasında Raft algoritmasıyla eşler ve karar verebilmek için çoğunluğun ayakta olması gerekir. Bu tek cümle, kaç yönetici koyacağınızı belirler:

İki yöneticinin neden bir yöneticiden kötü olduğunu vurgulamak isterim: çoğunluk iki olduğu için, bir yönetici düştüğünde kalan tek yönetici karar veremez ve küme yönetim işlemlerine kapanır. Yani arıza toleransı sıfırdır ama arıza olasılığı iki katına çıkmıştır. Yönetici sayısını her zaman tek tutun.

Önemli bir teselli: quorum kaybı çalışan konteynerleri durdurmaz. Mevcut servisler hizmet vermeye devam eder; yalnızca yeni dağıtım, ölçekleme ve düğüm ekleme gibi yönetim işlemleri durur. Bu, gece yarısı panik yapmadan sabah müdahale edebileceğiniz anlamına gelir.

İlk Servis ve Routing Mesh#

Swarm'da docker run yerine docker service create kullanırsınız. Servis, "şu imajdan şu kadar kopya çalışsın" bildirimidir; Swarm bunu sağlamak için görevleri düğümlere dağıtır ve düşen görevlerin yerine yenisini koyar.

docker service create \
  --name web \
  --replicas 3 \
  --publish published=80,target=80 \
  nginx:1.27-alpine

# Gorevler hangi dugumlerde calisiyor
docker service ps web

# Anlik olarak olcekle
docker service scale web=5

# Tum kopyalarin loglarini birlestirerek izle
docker service logs -f web

Buradaki en şaşırtıcı davranış routing mesh'tir: yayınladığınız port kümenin her düğümünde açılır. web servisinin tek bir kopyası olsa bile, kümedeki herhangi bir sunucunun 80 portuna gelen istek doğru düğüme yönlendirilir. Bu, önüne koyacağınız yük dengeleyicinin bütün düğümleri arka uç olarak listeleyebilmesi anlamına gelir; hangi konteynerin nerede olduğunu bilmesi gerekmez.

Routing mesh'in bir yan etkisi vardır: konteynere ulaşan istemci IP'si, ağ katmanı yüzünden kaybolabilir. Gerçek ziyaretçi IP'sini görmesi gereken bir ters proxy'yi mode: host ile yayınlamak ya da proxy protokolü kullanmak gerekir.

Stack Dosyası ile Dağıtım#

Tek tek docker service create yazmak yerine, Compose biçiminde bir stack dosyası kullanırsınız. Fark, deploy bloğunun artık gerçekten işlenmesidir; tek makinede docker compose up bu bloğu yok sayar.

services:
  app:
    image: registry.firmaniz.com/firmaniz/web:1.4.0
    networks: [arka]
    secrets: [db_parola]
    environment:
      DB_PASSWORD_FILE: /run/secrets/db_parola
    healthcheck:
      test: ["CMD", "wget", "-qO-", "http://127.0.0.1:8080/healthz"]
      interval: 15s
      timeout: 5s
      retries: 3
      start_period: 20s
    deploy:
      replicas: 3
      placement:
        constraints: ["node.role == worker"]
      update_config:
        parallelism: 1
        delay: 15s
        order: start-first
        failure_action: rollback
      restart_policy:
        condition: on-failure
        delay: 5s
        max_attempts: 3
      resources:
        limits:
          cpus: "1.0"
          memory: 512M

networks:
  arka:
    driver: overlay

secrets:
  db_parola:
    external: true

# Ozel registry kullaniyorsaniz kimlik bilgisini dugumlere tasiyin
docker stack deploy -c stack.yaml --with-registry-auth firmaniz

# Durum
docker stack services firmaniz
docker stack ps firmaniz

--with-registry-auth bayrağını unutmayın: onsuz worker düğümler özel registry'den imajı çekemez ve görevler No such image hatasıyla takılır. Sağlık kontrolünü de mutlaka tanımlayın; Swarm, unhealthy bir görevi durdurup yenisini başlatır ve bu, kümenin kendi kendini onarmasının temelidir. Sağlık kontrolü yazımı için Docker healthcheck kullanımı yazısına bakabilirsiniz.

Kesintisiz Güncelleme ve Geri Alma#

Swarm'ın en somut faydası buradadır. update_config bloğu, yeni sürüme geçişin nasıl yapılacağını belirler: kaç kopya aynı anda güncellensin, aralarında ne kadar beklensin ve bir görev başarısız olursa ne yapılsın.

order: start-first ayarı özellikle önemlidir: yeni kopya ayağa kalkıp sağlıklı olana kadar eski kopya çalışmaya devam eder, yani kapasite hiç düşmez. Varsayılan stop-first ise önce eskiyi durdurur ve kısa bir kapasite düşüşü yaratır.

# Yeni surume gecis
docker service update --image registry.firmaniz.com/firmaniz/web:1.5.0 firmaniz_app

# Ilerlemeyi izle
docker service ps firmaniz_app

# Bir onceki surume don
docker service rollback firmaniz_app

failure_action: rollback ayarıyla bunu otomatikleştirebilirsiniz: yeni görevler sağlıklı olamazsa Swarm güncellemeyi kendiliğinden geri alır. Bu, hatalı bir imajın tüm kopyaları götürmesini engelleyen en değerli güvenlik ağıdır ve yalnızca sağlık kontrolü tanımlıysa doğru çalışır.

Yerleşim Kısıtları ve Kalıcı Veri#

Swarm'ın en çok yanlış anlaşılan yanı depolamadır. Yerel bir Docker hacmi düğüme özeldir. Veritabanı görevi başka bir düğüme taşındığında, eski düğümdeki hacimle bağı kopar ve boş bir veritabanıyla açılır. Bu, "verilerim kayboldu" panikleri arasında en sık göreceğiniz senaryodur.

Üç pratik yaklaşım vardır. Birincisi ve en basiti, durum tutan servisi tek bir düğüme sabitlemektir:

# Dugume etiket ver
docker node update --label-add veri=evet sunucu-1

# Stack icinde kisit tanimla
#   deploy:
#     placement:
#       constraints: ["node.labels.veri == evet"]

İkincisi paylaşımlı depolama kullanmaktır (NFS ya da benzeri bir ağ dosya sistemi); hacim tüm düğümlerden erişilebilir olur ama ağ gecikmesi ve tek arıza noktası riski gelir. Üçüncüsü ve çoğu ekip için en sağlıklısı, veritabanını kümenin dışında, yönetilen ya da ayrı bir sunucuda tutmaktır. Swarm'ı durum tutmayan uygulama katmanı için kullanmak, hem daha basit hem daha güvenlidir.

Bakım yaparken düğümü kümeden çıkarmadan boşaltabilirsiniz:

# Dugumdeki gorevleri baska dugumlere tasi, yeni gorev verme
docker node update --availability drain sunucu-2
# Bakim bittiginde geri al
docker node update --availability active sunucu-2

# Dugumu tamamen cikar
docker node update --availability drain sunucu-2
docker swarm leave              # cikarilacak dugumde calistirilir
docker node rm sunucu-2         # manager uzerinde

Sık Yapılan Hatalar#

UDP 4789'u açmamak. Küme sağlıklı görünür ama servisler birbirine ulaşamaz. Overlay ağ testi için iki servis arasında docker exec ile isim çözümlemesi deneyin.

Çift sayıda yönetici kurmak. İki yönetici, tek yöneticiden daha kırılgandır. Üç yapın.

--with-registry-auth unutmak. Özel registry'den çeken worker düğümler imajı bulamaz; hata mesajı registry'yi değil imajı işaret ettiği için yanıltıcıdır.

deploy bloğunu tek makinede beklemek. docker compose up bu bloğu yok sayar; replicas, update_config ve restart_policy yalnızca docker stack deploy ile anlam kazanır.

Kalıcı veriyi çoğaltılan servise vermek. replicas: 3 olan bir veritabanı, üç ayrı ve birbirinden habersiz veri kümesi demektir. Durum tutan servisleri ya sabitleyin ya küme dışına alın.

Kaynak sınırı koymamak. Sınırsız bir servis, düştüğü düğümdeki diğer görevleri bellek yetersizliğine sürükleyebilir. resources.limits ile en azından bellek sınırı tanımlayın.

Sıkça Sorulan Sorular#

Docker Swarm hâlâ destekleniyor mu#

Evet, Swarm modu Docker Engine'in içinde gelmeye ve bakımı sürdürülmeye devam ediyor. Sektörün ilgisi büyük ölçüde Kubernetes'e kaydığı için ekosistem ve üçüncü taraf araç desteği daha sınırlıdır, ama küçük ve orta ölçekli kümeler için çalışır durumda ve kararlıdır. Karar verirken şunu sorun: ihtiyacınız birkaç sunucuda kesintisiz dağıtım mı, yoksa geniş bir eklenti ekosistemi mi?

Swarm ile Kubernetes arasında nasıl seçim yaparım#

Kabaca ölçü şudur: sunucu sayınız on'un altında, servis sayınız yirmi civarında ve ekibinizde tam zamanlı bir platform mühendisi yoksa Swarm doğru seçimdir. Otomatik yatay ölçekleme, gelişmiş ağ politikaları, operatör tabanlı yönetim ya da bulut sağlayıcı entegrasyonları gerekiyorsa Kubernetes'e yönelin. Swarm'dan Kubernetes'e geçiş mümkündür ve Compose dosyalarınız iyi yazılmışsa göründüğü kadar acılı değildir.

Tek sunucuda Swarm kullanmanın anlamı var mı#

Sınırlı ama gerçek bir faydası vardır: tek düğümlü bir Swarm'da bile secret yönetimi, kesintisiz güncelleme ve otomatik geri alma özelliklerini kullanabilirsiniz; bunlar sade Compose'da yoktur. Buna karşılık yüksek erişilebilirlik elde etmezsiniz, çünkü tek makine hâlâ tek arıza noktasıdır. İleride sunucu ekleme planınız varsa tek düğümle başlamak makul bir hazırlıktır.

Kaç sunucu ile başlamalıyım#

Üretim için asgari makul kurulum üç düğümdür: üçü de yönetici olabilir ya da üç yönetici artı birkaç worker şeklinde büyütebilirsiniz. Üç düğüm, bir sunucu arızasını yönetim yeteneğini kaybetmeden atlatmanızı sağlar. İki sunucuyla başlamak istiyorsanız birini yönetici, diğerini worker yapın; bu durumda yönetici düştüğünde küme yönetilemez hâle gelir ama çalışan servisler ayakta kalmaya devam eder.

Swarm'da veritabanı çalıştırabilir miyim#

Teknik olarak evet ama dikkatli olmak gerekir. Yerel hacimler düğüme bağlı olduğu için, görev başka bir düğüme taşındığında veriye erişemez. Güvenli desen, veritabanı servisini bir düğüme etiketle sabitlemek ve replicas: 1 tutmaktır. Daha sağlam bir kurulum istiyorsanız veritabanını kümenin dışında ayrı bir sunucuda çalıştırmak, işletim açısından çok daha az sürpriz üretir.

Quorum kaybolursa uygulamam durur mu#

Hayır. Yöneticilerin çoğunluğu kaybolduğunda küme yönetim işlemlerine kapanır: yeni dağıtım yapamaz, ölçekleyemez, düğüm ekleyemezsiniz. Ancak zaten çalışan konteynerler çalışmaya devam eder ve routing mesh trafiği yönlendirmeye devam eder. Kurtarma yolu düşen yöneticileri geri getirmektir; mümkün değilse kalan bir yöneticide zorla yeni bir küme oluşturmak son çare olarak kullanılır.

Swarm servislerini nasıl izlerim#

docker service ps servis_adi görevlerin durumunu ve son hatalarını, docker service logs -f servis_adi ise tüm kopyaların loglarını birleştirerek gösterir. Daha yapısal bir kurulum için düğüm ve konteyner metriklerini toplayan bir izleme yığını kurmak gerekir; Swarm'ın kendi arayüzü olmadığı için birçok ekip görsel yönetim tarafında Portainer kullanır, o da Swarm kümelerini doğrudan yönetebilir.

Kapanış#

Swarm, Compose bilen bir ekibin çok az yeni kavramla küme dünyasına geçmesini sağlar. Aklınızda kalması gereken dört alışkanlık şunlar: yönetici sayısını daima tek tutun ve üçten başlayın, üç Swarm portunu yalnızca düğüm IP'lerine açın ve UDP 4789'u unutmayın, deploy bloğunda sağlık kontrolü ile failure_action: rollback ikilisini birlikte tanımlayın, kalıcı veri tutan servisleri ya düğüme sabitleyin ya da kümenin dışına çıkarın. Bu dördü yerindeyken Swarm, bakımı şaşırtıcı derecede düşük bir platform olarak çalışır.

Bir küme kurmak için birbiriyle hızlı konuşan birkaç sunucuya ihtiyacınız var. Aynı altyapıda hızlıca çoğaltabileceğiniz bulut sunucu ve tam root erişimli VDS paketlerimiz bu iş için uygundur; daha yüksek kapasite gerekiyorsa dedicated sunucu seçeneğine bakabilirsiniz. Küme kurulumu, ağ yapılandırması ve izleme tarafını devretmek isterseniz sunucu yönetimi hizmetimiz bu süreci sizin yerinize yürütür.