Üç kıtaya yayılan Docker Swarm: %100 uptime için tasarlanmış yüksek erişilebilirlik

Bir veri merkezindeki bir sunucu, donanım ve ağ ne kadar iyi olursa olsun tek hata noktasıdır. Bu lokasyon devre dışı kalırsa, örneğin elektrikteki ya da ağdaki bir arıza veya basitçe bakım sırasında yapılan bir hata yüzünden, uygulama da erişilemez hâle gelir. Birden fazla veri merkezine yayılan Docker Swarm tam olarak bu sorunu çözer: konteynerler üç bağımsız lokasyonda, ideal durumda üç ayrı kıtada çalışır ve bunlardan biri tamamen çökerse diğer ikisi, kullanıcılar hiçbir şey fark etmeden işi devralır.

Bu yazı, %100 uptime için tasarlanmış bir Docker Swarm kümesini adım adım nasıl kuracağınızı gösteriyor: Kuzey Amerika, Avrupa ve Asya'da birer sunucu, düğümler arasında şifreli bir WireGuard ağı, bütün bir kıtanın devre dışı kalmasını atlatan bir manager quorum'u, bölge başına bir giriş noktası ve kullanıcıları otomatik olarak en yakın sağlıklı lokasyona yönlendiren DNS tabanlı bir failover. Ayrıca bu mimaride bile nelerin hâlâ çökebileceğini ve bu riskleri de nasıl karşılayacağınızı dürüstçe açıklıyoruz.

Docker Swarm ile %100 uptime sağlanabilir mi?

Üç kıtaya yayılan bir Docker Swarm, %100 uptime için tasarlanmıştır: ne tek bir sunucu ne tek bir veri merkezi ne de tek bir kıta, uygulamayı tek başına durdurabilir. Yine de mutlak bir erişilebilirliği kimse garanti edemez, en yüksek taahhütleri %99,99 ile %99,999 arasında kalan büyük bulut sağlayıcıları bile. Bunun nedeni veri merkezleri değil, tüm lokasyonların ortak noktalarıdır. Bu yazı tam olarak bunları da ele alıyor, böylece %100'e teknik olarak mümkün olduğu kadar yaklaşabilirsiniz.

Erişilebilirlik rakamlarla ne anlama gelir

Hesaplamada yılda 8.760 saat, ayda 730 saat esas alınmıştır. Eklenen her dokuz, izin verilen kesinti süresini onda birine indirir ve tek bir sunucunun artık karşılayamayacağı iş tam da burada başlar.

Üç kıta neden bu kadar fark yaratır

Her biri %99,9 erişilebilirliğe sahip, birbirinden bağımsız üç lokasyon, matematiksel olarak ancak üçü de aynı anda arızalıysa hep birlikte devre dışı kalır: %0,1 çarpı %0,1 çarpı %0,1, %0,0000001 eder. Lokasyonlar birbirinden ne kadar uzaksa gerçekte de o kadar bağımsızdır: ayrı elektrik şebekeleri, ayrı ağ bağlantıları, ayrı hava koşulları, ayrı bakım pencereleri. Bu yüzden Kuzey Amerika, Avrupa ve Asya'ya dağıtılmış bir yapı, sunucularla kurulabilecek en güçlü hata toleransı biçimidir.

Üç kıtada bile hâlâ neler çökebilir

Kalan riskler, tüm lokasyonların ortak bağımlılıklarıdır ve her biri için bir karşı önlem vardır:

• Hatalı bir güncelleme de küme tarafından tüm lokasyonlara, iyi bir güncelleme kadar güvenilir biçimde dağıtılır. Karşı önlem: health check'ler ve otomatik geri alma, ayrıca güncellemelerin bölge bölge yapılması.
• DNS, tüm kullanıcıların geçtiği tek noktadır. Karşı önlem: dünya geneline yayılmış bir ağı olan, failover destekli bir DNS sağlayıcısı, kısa TTL.
• Veritabanı tüm lokasyonlarda aynı verilere sahip olmalıdır. Karşı önlem: otomatik geçişli replikasyon, ayrıntılar veriler bölümünde.
• Süresi dolmuş sertifikalar ve alan adları tüm lokasyonları aynı anda etkiler. Karşı önlem: otomatik yenileme ve sona erme tarihlerinin izlenmesi.
• Geçişin kendisi, health check'ler ve DNS tepki verene kadar zaman alır; bu çoğunlukla bir ila iki dakikadır ve bu sürede bazı istekler başarısız olabilir. Karşı önlem: kısa kontrol aralıkları, kısa TTL ve başarısız istekleri yeniden deneyen istemciler.

Mimariye genel bakış

Birden fazla kıtaya yayılan bir Docker Swarm altı yapı taşından oluşur. Her biri belirli bir hata noktasını ortadan kaldırır:

Kaç manager ve nerede?

Bir Swarm kümesindeki manager düğümleri, küme durumunu Raft konsensüs algoritmasıyla yönetir. Her değişiklik, manager'ların çoğunluğunun, yani quorum'un onayını gerektirir. Çoğunluk kaybolursa mevcut konteynerler çalışmaya devam eder, ancak küme ne yeniden planlama yapabilir ne arızaları telafi edebilir ne de güncelleme dağıtabilir.

Docker, tek sayıda manager kullanılmasını ve bunların en az üç ayrı zone'a dağıtılmasını önerir: üç manager'da 1-1-1, beş manager'da 2-2-1 oranında. Buradan bu yazının en önemli kuralı çıkar: iki lokasyon yetmez. İki lokasyonda manager'ların fazlası kaçınılmaz olarak bunlardan birinde bulunur ve tam da o lokasyon çökerse çoğunluk kaybolur. Quorum ancak üç lokasyonla herhangi bir veri merkezinin çökmesini atlatabilir, üç kıtada ise bütün bir kıtanın çökmesini.

Üç kıta mı, tek kıta mı: artılar ve eksiler

Kümedeki her değişiklik, her deployment ve bir konteynerin her yeniden planlanması, manager çoğunluğunun onayını bekler. Avrupa, Kuzey Amerika ve Asya arasında bu onayların her biri, yaklaşık 80 ila 250 milisaniyelik bir paket gecikmesi kadar sürer. Kullanıcılar için bunun bir önemi yoktur, çünkü istekleri yerel olarak yanıtlanır; ancak deployment'lar ve yeniden planlamalar, mesafelerin kısa olduğu bir kümeye göre belirgin şekilde daha uzun sürer.

Kullanıcıları birden fazla kıtada bulunan ve mümkün olan en yüksek erişilebilirliği hedefleyen uygulamalar için doğru seçenek üç kıtalı olandır; bu rehberde de onu kuruyoruz. Burada tüm adımlar boyunca geçerli olan bir kural önemlidir: her istek kendi bölgesinde yanıtlanır ve asla kıtalar arasında gidip gelmez.

Hangi KernelHost lokasyonları uygundur

KernelHost, Frankfurt am Main'deki maincubes veri merkezinde sunucu işletir ve Avrupa, Kuzey Amerika ve Asya-Pasifik'teki diğer lokasyonlarda sanal sunucular sağlar; bunlar arasında ABD'deki üç lokasyon, Kanada, Londra, Strazburg, Varşova, Helsinki, Singapur, Japonya, Sydney ve Mumbai bulunur. Haritalı tam liste Sunucu lokasyonları sayfasındadır. Bu yazıdaki örnekte Avrupa için Frankfurt am Main'i, Kuzey Amerika için ABD'nin doğu kıyısını ve Asya için Singapur'u kullanıyoruz.

Rehber: üç kıtaya yayılan Docker Swarm kurulumu

Örnekte üç sunucu kullanılıyor: Frankfurt am Main'de swarm-eu, ABD'nin doğu kıyısında swarm-us ve Singapur'da swarm-asia. Genel adresler dokümantasyon ağı 203.0.113.0/24 içinden alınmıştır, WireGuard ağı ise 10.10.0.0/24 kullanır. İkisini de kendi değerlerinizle değiştirin. Üç düğümün hepsi aynı anda hem manager hem de worker'dır; daha fazla performans için ileride her bölgeye yalnızca worker rolünde çalışan düğümler eklersiniz.

Adım 1: sunucuları üç kıtada hazırlayın

Üç bölgede Debian 12 veya 13 yüklü üç sunucu sipariş edin ve temel sertleştirmeyi uygulayın: yalnızca anahtarla SSH, otomatik güvenlik güncellemeleri, ayrı kullanıcılar. Yeni root sunucular için kontrol listesi bunları kapsar. docker node ls çıktısında hangi düğümün nerede durduğunu hemen görebilmek için açıklayıcı hostname'ler verin.

hostnamectl set-hostname swarm-eu

Adım 2: Docker'ı tüm düğümlere kurun

Debian ve Ubuntu'ya Docker kurulumu yazısında anlatıldığı gibi, Docker Engine'i resmi Docker deposundan üç sunucunun hepsine kurun. Ardından her düğümde sürümü kontrol edin; üçünün de aynı ana sürümde olması gerekir:

docker version --format '{{.Server.Version}}'

Adım 3: kıtalar arasında bir WireGuard ağı kurun

Düğümler birbirleriyle genel internet üzerinden konuşur. Tüm küme trafiğinin şifrelenmesi ve Swarm portlarına asla dışarıdan erişilememesi için üç sunucu bir WireGuard ağıyla birbirine bağlanır. Önce her düğümde bir anahtar çifti oluşturun:

apt-get install -y wireguard
umask 077
wg genkey | tee /etc/wireguard/private.key | wg pubkey > /etc/wireguard/public.key

Ardından her düğüm bir /etc/wireguard/wg0.conf dosyası alır. swarm-eu üzerinde dosya şöyle görünür, diğer iki düğüm bunun ayna görüntüsü olarak yapılandırılır:

[Interface]
Address = 10.10.0.1/24
ListenPort = 51820
PrivateKey = SWARM_EU_OZEL_ANAHTARI
MTU = 1420

[Peer]
PublicKey = SWARM_US_ACIK_ANAHTARI
Endpoint = 203.0.113.12:51820
AllowedIPs = 10.10.0.2/32
PersistentKeepalive = 25

[Peer]
PublicKey = SWARM_ASIA_ACIK_ANAHTARI
Endpoint = 203.0.113.13:51820
AllowedIPs = 10.10.0.3/32
PersistentKeepalive = 25

systemctl enable --now wg-quick@wg0
ping -c 3 10.10.0.2

Tüm düğümler 10.10.0.x adresleri üzerinden yanıt veriyorsa ağ hazırdır. PersistentKeepalive, bağlantıyı stateful güvenlik duvarlarının arkasında da açık tutar. ping komutunun şimdi kıtalar arasında gösterdiği gecikmeler, tam olarak kümedeki her değişikliğin bedeli olan bekleme süreleridir.

Adım 4: güvenlik duvarı: yalnızca Swarm düğümleri içeri girebilir

Docker Swarm, düğümler arasında küme yönetimi için 2377/TCP, düğümlerin kendi aralarındaki iletişimi için 7946/TCP ve UDP, overlay ağı için de 4789/UDP portlarına ihtiyaç duyar. Bu portlara yalnızca WireGuard arayüzünde izin verirsiniz; dışarıya açık kalan tek şey WireGuard'ın kendisidir, o da yalnızca diğer düğümler için. ufw ile swarm-eu üzerinde bu şöyle görünür:

ufw allow from 203.0.113.12 to any port 51820 proto udp
ufw allow from 203.0.113.13 to any port 51820 proto udp
ufw allow in on wg0 to any port 2377 proto tcp
ufw allow in on wg0 to any port 7946
ufw allow in on wg0 to any port 4789 proto udp

Önemli: Docker'ın konteynerler için yayınladığı portlar ufw'yi baypas eder, çünkü Docker kendi iptables kurallarını tanımlar. Bu yüzden yalnızca giriş noktasının portlarını (80 ve 443) yayınlayın, veritabanı veya yönetim portlarını asla yayınlamayın.

Adım 5: Swarm kümesini başlatın ve manager'ları ekleyin

swarm-eu üzerinde Swarm kümesini başlatın ve yönetim ile veri trafiğinin WireGuard üzerinden geçmesini sağlayın:

docker swarm init --advertise-addr 10.10.0.1 --data-path-addr 10.10.0.1
docker swarm join-token manager

İkinci komut, ek manager'lar için katılım komutunu ekrana yazdırır. Bu komutu swarm-us ve swarm-asia üzerinde, her birinin kendi WireGuard adresiyle çalıştırın; aşağıdaki örnek swarm-us için:

docker swarm join --token SWMTKN-1-... --advertise-addr 10.10.0.2 --data-path-addr 10.10.0.2 10.10.0.1:2377
docker node ls

Ardından docker node ls üç düğüm gösterir: biri Leader, diğer ikisi Reachable durumundadır. Katılım token'ı bir sırdır: onu bilen herkes kümenize kendi manager'ını sokabilir. Kurulumdan sonra token'ı docker swarm join-token --rotate manager ile yenileyin.

Adım 6: Autolock'u etkinleştirin

Manager düğümleri küme durumunu, Raft loglarını şifreleyen anahtarlarla birlikte /var/lib/docker/swarm/ altında saklar. Autolock ile bu anahtarların kendisi de şifrelenir ve yeniden başlatılan bir manager, kümeye ancak bir kilit açma anahtarı girildikten sonra yeniden katılır:

docker swarm update --autolock=true
docker swarm unlock

İlk komut kilit açma anahtarını ekrana yazdırır; bu anahtarı bir parola yöneticisine kaydedin. İkinci komuta her manager yeniden başlatıldıktan sonra ihtiyacınız olur. Anahtar olmadan Swarm kümesi bir yedekten bile geri yüklenemez, bu yüzden anahtarı sunuculardan ayrı bir yerde muhafaza edin.

Adım 7: düğümleri bölgeye göre etiketleyin

Etiketler scheduler'a bir düğümün nerede durduğunu bildirir. Sonraki adımlardaki yerleştirme kuralları bunun üzerine kurulur:

docker node update --label-add region=eu swarm-eu
docker node update --label-add region=us swarm-us
docker node update --label-add region=asia swarm-asia

Adım 8: uygun MTU ile bir overlay ağı oluşturun

Farklı lokasyonlardaki konteynerler birbirleriyle bir overlay ağı üzerinden konuşur. Bu ağ WireGuard tünelinden geçtiği için MTU değerinin daha küçük olması gerekir: WireGuard 1420 bayt ile çalışır, overlay ağı (VXLAN) bunun 50 baytını kendi başlık verileri için kullanır, geriye 1370 bayt kalır:

docker network create --driver overlay --attachable --opt com.docker.network.driver.mtu=1370 appnet

Fazla büyük bir MTU sinsice kendini gösterir: küçük istekler çalışır, büyük yanıtlar takılır. WireGuard kullanmak istemeyenler overlay ağını bunun yerine --opt encrypted ile şifreleyebilir; bu durumda düğümler arasında ayrıca IP protokolü 50 (ESP) için de izin verilmesi gerekir ve Docker, belirgin performans kayıplarına açıkça dikkat çeker. Biz WireGuard'ı öneriyoruz, çünkü yönetim dâhil tüm trafiği kapsar.

Adım 9: uygulamayı her bölgede çalıştırın

Sıradan bir Swarm servisi, istekleri servis adresi üzerinden kümedeki tüm replikalara, yani diğer kıtalara da dağıtır. Üç kıtada bu, her iki ya da üç istekten birinin dünyanın yarısını dolaşması demek olurdu. Bu yüzden her bölge, yerleştirme kuralıyla kendi bölgesinde kalan ayrı bir servis alır. Güncelleme ayarları, yeni sürümlerin konteyner konteyner dağıtılmasını ve hata durumunda otomatik olarak geri alınmasını sağlar:

for r in eu us asia; do
  docker service create --name web-$r --replicas 2 --network appnet \
    --constraint node.labels.region==$r \
    --update-parallelism 1 --update-delay 30s \
    --update-failure-action rollback \
    registry.example.com/web:1.0
done

Swarm bir konteynerin yalnızca çalışıp çalışmadığını değil, gerçekten iş görüp görmediğini de anlayabilsin diye imaja bir health check eklenmelidir; örneğin uygulamanızın Dockerfile dosyasına şu satır:

HEALTHCHECK --interval=10s --timeout=3s --retries=3 CMD wget -qO- http://127.0.0.1:8080/health || exit 1

Health check'i üst üste üç kez başarısız olan bir konteyner yenisiyle değiştirilir; bir güncelleme sırasında başarısız olan bir health check ise dağıtımı durdurur.

Adım 10: bölge başına bir giriş noktası

Giriş noktası görevini Caddy, Traefik veya nginx gibi bir reverse proxy üstlenir. O da her bölgede ayrı bir servis olarak çalışır ve istekleri yalnızca kendi bölgesindeki uygulamaya iletir. Host modunda 80 ve 443 portlarını doğrudan kendi bölgesindeki sunucuda yayınlar. Caddy hedefi bir ortam değişkeninden okuduğu için tek bir ortak yapılandırma yeterlidir:

example.com {
    reverse_proxy {$UPSTREAM}:80
}

docker config create caddyfile ./Caddyfile
for r in eu us asia; do
  docker service create --name edge-$r --network appnet \
    --constraint node.labels.region==$r \
    --env UPSTREAM=web-$r \
    --config source=caddyfile,target=/etc/caddy/Caddyfile \
    --publish mode=host,target=80,published=80 \
    --publish mode=host,target=443,published=443 \
    caddy:2
done

Tüm bölgelerin aynı alan adı için bir TLS sertifikasına ihtiyacı vardır. Bu yüzden sertifikaları, DNS kaydının o anda hangi bölgeyi gösterdiğinden bağımsız olarak çalışan DNS challenge yöntemiyle alın; Caddy bunun için DNS sağlayıcınıza ait modüle ihtiyaç duyar. Proxy ile ilgili temel bilgiler nginx ile reverse proxy kurulumu yazısında yer alıyor.

Adım 11: failover destekli Geo-DNS kurun

Son yapı taşı kullanıcıları doğru bölgeye yönlendirir. Coğrafi yönlendirme ve health check destekli bir DNS servisi, Avrupa'daki kullanıcıları Frankfurt am Main'e, Amerika'dakileri ABD'nin doğu kıyısına, Asya'dakileri ise Singapur'a gönderir. Bir bölge çöktüğünde health check bunu 30 ila 60 saniye içinde fark eder ve o bölgenin kullanıcılarını en yakın sağlıklı bölgeye gönderir. Çözümleyicilerin bir değişikliği hızla yansıtması için kayıtların geçerlilik süresini (TTL) 60 saniyeye ayarlayın. Health check olmadan tanımlanan birden fazla A kaydı yalnızca geçici bir çözümdür: tarayıcılar çoğu zaman bir sonraki adresi dener, ama her istemci bunu yapmaz ve çökmüş bir bölge yanıtta kalmaya devam eder.

Hesabı dürüst yapın: arıza ile geçiş arasında kontrol aralığı artı TTL kadar süre geçer, örnekte yani bir ila iki dakika; bu süre boyunca etkilenen bölgedeki kullanıcıların bir kısmı hâlâ çökmüş lokasyona yönlendirilir. Başarısız istekleri kısa bir aradan sonra yeniden deneyen uygulamalar ve mobil uygulamalar bu süreyi neredeyse fark edilmeden atlatır.

Adım 12: bir bölgenin çökmesini test edin

Hiç prova edilmemiş bir failover, gerçek bir acil durumda nadiren çalışır. Bir bölgenin düğümünü devreden çıkararak o bölgenin çökmesini simüle edin ve küme ile DNS'in nasıl tepki verdiğini gözlemleyin:

docker node update --availability drain swarm-asia
docker node ls
docker service ls
docker node update --availability active swarm-asia

Bölgenin servisleri yerleştirme kuralıyla kendi düğümüne bağlı olduğu için başka bir yere taşınmaz, beklemede kalır; bölgenin kullanıcılarını DNS tabanlı failover devralır. Bu yüzden bu testte özellikle health check'in bölgeyi yanıtlardan çıkarıp çıkarmadığını ve komşu bölgenin ek yükü taşıyıp taşımadığını kontrol edin. Daha sert bir test için düğümü, örneğin WireGuard'ı durdurarak ağdan tamamen ayırın. Testi büyük değişikliklerden sonra ve en az üç ayda bir tekrarlayın.

Veriler: yüksek erişilebilirliğin en zor kısmı

Docker Swarm verileri değil, konteynerleri replike eder. Bir volume her zaman konteynerin çalıştığı düğümde bulunur. Bu yüzden web ön yüzleri ve API'ler gibi durumsuz servisler her bölgede sorunsuzca çalıştırılabilir; veri içeren her şey için ise ayrı bir replikasyona ihtiyacınız vardır.

Veritabanlarının kıtalar arası replikasyonu

Veritabanları kendi replikasyon mekanizmalarıyla gelir ve bu, veri merkezleri arasında paylaşılan bir depolamaya her zaman tercih edilmelidir. Kıtalar arasında kendini kanıtlamış yöntem, bir bölgede birincil bir instance ve diğer iki bölgede asenkron replikalardır: örneğin PostgreSQL'de streaming replication ve otomatik geçiş için Patroni gibi bir araç, MariaDB ile MySQL'de ise yerleşik replikasyon. Okuma isteklerini her bölge yerel olarak yanıtlar, yazma işlemleri birincil instance'a gider. Dürüst olmak gerekirse asenkron şu anlama da gelir: birincil bölge çökerse son birkaç saniyenin yazma işlemleri eksik olabilir. Dünya genelinde yazmak ve hiçbir şey kaybetmemek isteyenler, CockroachDB veya YugabyteDB gibi birden fazla bölge için tasarlanmış veritabanlarına yönelir. Swarm onları asla verileri olmadan başka bir yere taşımasın diye veritabanı düğümlerini yerleştirme kuralıyla kendi bölgelerine sabitleyin:

docker service create --name db-asia --constraint node.labels.region==asia ...

Dosyalar ve yüklemeler

Yüklenen dosyaların yeri yerel bir volume değil, ikinci bir bölgeye replikasyon yapan S3 uyumlu bir nesne depolama alanı ya da kendi kurduğunuz, replike edilen bir depolama sistemidir. Kıtalar arasında NFS gibi ağ dosya sistemleri yavaştır ve kendileri de tek hata noktasıdır.

Oturumlar ve önbellekler

Uygulama oturumları bir konteynerin belleğinde tutuyorsa, geçiş sırasında kullanıcıların oturumu kapanır. Oturumları replike edilen bir veritabanında ya da Redis gibi replike edilen bir önbellekte tutun veya her bölgenin kendisinin doğrulayabileceği imzalı token'lar kullanın.

Yedekler yine de şart

Replikasyon bir lokasyonun çökmesine karşı korur, ancak hatalara karşı korumaz: yanlışlıkla silinen bir kayıt birkaç saniye sonra tüm bölgelerde silinmiş olur. Bu yüzden Sunucular için yedekleme stratejisi yazısında anlatıldığı gibi, bağımsız bir yere alınan düzenli ve test edilmiş yedekler her yüksek erişilebilir mimarinin parçasıdır.

İşletim: güncellemeler, bakım ve izleme

Bölge bölge güncelleme

Yeni sürümleri tüm bölgelerde aynı anda değil, sırayla dağıtın ve bir sonrakine geçmeden önce her bölgeyi kısa bir süre gözlemleyin. Böylece hiçbir health check'in yakalamadığı bir hata en fazla bir bölgeye ulaşır, diğer iki bölge de o bölgenin kullanıcılarına hizmet vermeye devam eder:

for r in asia us eu; do
  docker service update --image registry.example.com/web:1.1 web-$r || break
  sleep 300
done

Bir güncelleme başarısız olursa Swarm, Adım 9'daki ayarlar sayesinde onu otomatik olarak geri alır ve || break, komut bir hata bildirdiği anda döngüyü sonlandırır. Sorunu ancak daha sonra fark edilen bir güncellemeyi docker service rollback web-asia ile elle geri alırsınız.

Bir bölgenin bakımı

Bir sunucunun yeniden başlatılması veya güncellenmesi gerekiyorsa onu docker node update --availability drain ile devreden çıkarın ve kullanıcılarının önce DNS tabanlı failover ile komşu bölgelere yönlendirilmesini bekleyin. Bakımdan sonra sunucuyu --availability active ile yeniden devreye alın. İki manager'ın asla aynı anda eksik olmaması için, bir sonraki manager'a geçmeden önce docker node ls üçünü de yeniden erişilebilir olarak gösterene kadar bekleyin.

Dışarıdan izleme

Her bölgeyi ayrı ayrı ve kümenin dışından izleyin: giriş noktalarının erişilebilirliği, servislerin health check'leri, manager'ların durumu, veritabanının replikasyon gecikmesi ve sertifikalar ile alan adlarının sona erme tarihleri. Bütün bir bölge sessiz kaldığında bile alarmın size ulaşması gerekir. Bunu tek tek sunucular için nasıl kuracağınızı Sunucu izleme kurulumu yazısı gösteriyor.

Sırları güvenle dağıtın

Parolalar ve anahtarlar ortam değişkenlerine veya Compose dosyalarına değil, Docker Secrets içine konur. Bunlar Raft logunda şifrelenmiş olarak tutulur ve yalnızca açıkça atadığınız servislere iletilir:

printf '%s' 'VERITABANI_PAROLANIZ' | docker secret create db_password -
docker service update --secret-add db_password web-eu

Birden fazla kıtaya yayılan bir Swarm için neden KernelHost

Birden fazla kıtaya yayılan bir küme, sağlayıcıdan tek bir sunucuya göre farklı şeyler bekler. Pratikte belirleyici olan noktalar şunlardır:

Fiyatlarıyla birlikte tüm bulut paketlerine genel bakışı ve büyük bulut sağlayıcılarıyla bir maliyet karşılaştırmasını Bulut sunucu kiralama sayfasında bulabilirsiniz.

Sık yapılan hatalar ve bunlardan nasıl kaçınılır

• Manager'lar yalnızca iki lokasyonda. Çoğunluğu barındıran lokasyon çökerse küme durur. Çözüm: üç lokasyon, 1-1-1 veya 2-2-1 dağılımı.
• Çift sayıda manager. Dört manager, üç manager'dan daha fazla arızaya dayanamaz, ama koordinasyon yükünü artırır. Çözüm: 3, 5 veya 7.
• İstekler kıtalar arasında gidip geliyor. Tüm bölgeleri kapsayan tek bir servis adresi, kullanıcıları dünyanın yarısını dolaşmaya gönderir. Çözüm: bölge başına bir servis ve bir giriş noktası.
• Swarm portları dışarıdan erişilebilir. 2377 portu ve overlay ağı asla açık internete açılmamalıdır. Çözüm: yalnızca WireGuard üzerinden; dışarıya yalnızca 80, 443 ve diğer düğümler için WireGuard açık.
• MTU'yu unutmak. Büyük yanıtlar takılır, küçükler çalışır. Çözüm: WireGuard MTU'su 1420 iken overlay MTU'su 1370.
• Konteyner portlarında ufw'ye güvenmek. Docker, yayınlanan portlarda ufw'yi baypas eder. Çözüm: yalnızca giriş noktasını yayınlamak.
• Replikasyonsuz bir volume'da veritabanı. Bölge çökerse verilere erişilemez. Çözüm: veritabanı replikasyonu, bölgeye sabit yerleştirme.
• Tüm bölgelerde aynı anda güncelleme. Bu durumda bir hata dünya genelindeki tüm kullanıcıları etkiler. Çözüm: bölge bölge dağıtmak.
• Yüksek DNS TTL değeri. Bir günlük TTL ile failover ancak ertesi gün etkili olur. Çözüm: 60 saniye.
• Yedek yerine replikasyon. Bir hata da sağlam veriler gibi aynen replike edilir. Çözüm: ek olarak bağımsız bir yerde test edilmiş yedekler.

Kısaca özetle

• Üç kıtaya yayılan bir Docker Swarm, %100 uptime için tasarlanmıştır: bütün bir lokasyon ya da kıta, uygulama durmadan devre dışı kalabilir.
• Erişilebilirliği kimse mutlak olarak garanti edemez; kalan riskler DNS, hatalı güncellemeler, veritabanı ve sertifikalardır ve her biri için bir karşı önlem vardır.
• Üç lokasyonda üç manager asgari gereksinimdir; arızaya dayanıklı bir quorum için iki lokasyon yetmez.
• Her istek kendi bölgesinde kalır: bölge başına bir servis ve bir giriş noktası, buna ek olarak health check destekli ve kısa TTL'li Geo-DNS.
• WireGuard küme trafiğini şifreler, Swarm portları görünmez kalır, overlay MTU'su 1370'e düşer.
• Swarm verileri değil, konteynerleri replike eder: veritabanlarının kendi replikasyonuna ihtiyacı vardır ve yedekler yine de şarttır.
• KernelHost, Avrupa, Kuzey Amerika ve Asya-Pasifik'teki lokasyonların yanı sıra sınırsız trafik, her lokasyonda DDoS koruması ve asgari süre olmadan PrePaid faturalandırma sunar.