VPS'te Docker Deploy: Sıfır Kesinti İçin Nginx Stratejileri

VPS’te Docker Deploy: Sıfır Kesinti İçin Nginx Stratejileri

Bir üretim ERP’sinde gec sevkiyat raporu hep eksik geliyordu. Sebebini bulmak 3 gün aldi. Bu türden, beklenmedik aksaklıklar, özellikle canlı sistemlerde ortaya çıktığında can sıkıcı olabiliyor. VPS üzerinde çalışan Docker konteynerlarımıza yeni sürümlerini deploy ederken de benzer hassasiyetleri göz önünde bulundurmak gerekiyor. Amacımız, uygulamanın güncel versiyonunu kullanıcılerin hizmetine sunarken mevcut hizmetin kesintiye uğramaması. Bu da bizi Nginx gibi güçlü bir ters proxy (reverse proxy) çözümüne yöneltiyor.

Nginx’i sadece bir web sunucusu olarak değil, aynı zamanda canlı deploy (live deployment) süreçlerimizde kritik bir role sahip bir orkestrasyon aracı olarak kullanıyoruz. Özellikle konteyner tabanlı uygulamalarda, yeni bir sürümü devreye alırken trafik yönetimini akıllıca yapmak, sıfır kesinti (zero downtime) hedefine ulaşmamızı sağlıyor. Bu yazıda, VPS ortamında Docker ile çalışan uygulamalarımız için Nginx’i kullanarak nasıl kesintisiz deploy stratejileri uyguladığımı anlatacağım.

Nginx ile Trafik Yönetimi: Temel Prensipler

Nginx’in ters proxy yetenekleri, yeni deploy’lar sırasında trafiği akıllıca yönlendirmemize olanak tanır. Temel fikir şudur: mevcut çalışan sürümünüzü (eski sürüm) hala canlı tutarken, yeni sürümü (yeni sürüm) arka planda başlatırız. Ardından, Nginx’i kullanarak trafiğin bir kısmını veya tamamını yeni sürüme yönlendiririz. Bu süreçte Nginx, iki farklı backend sunucu grubu arasında geçiş yapabilir.

Bu yaklaşım, özellikle upstream bloklarını ve proxy_pass direktifini kullanarak yapılandırılır. upstream bloğu, arka planda çalışan servislerimizin adreslerini tanımlar. Nginx, bu adreslere gelen istekleri dağıtır. Deploy sırasında, upstream bloğundaki sunucu adreslerini dinamik olarak güncelleyerek trafiği yeni sürüme aktarabiliriz. Bu, genellikle bir scripting veya otomasyon aracı ile yapılır.

Nginx konfigürasyonunu dinamik olarak güncellemek, bir başka önemli konudur. nginx -s reload komutu, Nginx’in mevcut konfigürasyonunu yeniden yüklemesini sağlar. Bu komut, genellikle bir script içinde çalıştırılır. Bu sayede, konfigürasyonda yapılan değişiklikler, Nginx’in yeniden başlatılmasına gerek kalmadan anında aktif hale gelir. Bu da deploy süreçlerinin ne kadar hızlı ve kesintisiz olabileceğini gösterir.

Blue-Green Deploy Stratejisi

En yaygın ve etkili sıfır kesinti deploy stratejilerinden biri “Blue-Green Deploy” olarak bilinir. Bu yöntemde, mevcut canlı ortamımız “Blue” olarak adlandırılırken, yeni deploy edilecek sürüm “Green” olarak adlandırılır. Her iki ortam da aynı anda çalışır durumda olabilir. Nginx, trafiği hangi ortama yönlendireceğini belirler.

Blue-Green Deploy’un temel adımları şunlardır:

1. Blue Ortam: Mevcut, çalışan canlı sürümünüzü temsil eder.
2. Green Ortam: Yeni sürümünüzü çalıştırdığınız izole ortamdır. Bu, yeni Docker konteynerlarınız olabilir.
3. Nginx Konfigürasyonu: Nginx, başlangıçta tüm trafiği Blue ortama yönlendirir.
4. Deploy: Yeni sürüm Green ortama deploy edilir ve çalışır durumda olduğundan emin olunur.
5. Trafik Yönlendirme: Nginx konfigürasyonu güncellenerek trafik Green ortama yönlendirilir.
6. Test ve Doğrulama: Green ortam üzerinde gerekli testler yapılır.
7. Geçiş Tamamlama: Her şey yolundaysa, Nginx artık trafiği tamamen Green ortama yönlendirir. Blue ortam, geri dönüş (rollback) için hazır bekletilebilir.

Bu stratejinin en büyük avantajı, herhangi bir sorun tespit edildiğinde trafiği anında eski sürüme (Blue ortama) geri döndürebilmenizdir. Bu, riskleri en aza indirir. Ancak, iki ayrı ortamı aynı anda çalıştırmak ek kaynak maliyeti getirebilir.

Nginx’i bu strateji için kullanırken, genellikle iki farklı upstream bloğu tanımlarız: upstream blue_backend ve upstream green_backend. proxy_pass direktifi de buna göre ayarlanır. Deploy script’imiz, green_backend’e yeni sürümün IP adresini ekler ve ardından proxy_pass direktifini green_backend’i kullanacak şekilde güncelleyip nginx -s reload komutunu çalıştırır.

Canary Deploy Stratejisi

Blue-Green deploy’un bir varyasyonu olan Canary deploy, daha kademeli bir geçiş sağlar. Bu yöntemde, yeni sürüm önce trafiğin küçük bir yüzdesini alır. Başarılı olursa, bu oran yavaş yavaş artırılır. Bu, sorunların erken tespit edilmesini ve etkisinin sınırlı kalmasını sağlar.

Canary deploy için Nginx’te ağırlıklandırma (weighting) özelliği kullanılır. upstream bloğunda sunucuları tanımlarken ağırlık belirtebilirsiniz. Örneğin:

upstream myapp_backend {
    server 192.168.1.10:8080 weight=9;  # Eski sürüm
    server 192.168.1.11:8080 weight=1;  # Yeni sürüm (canary)
}

Bu konfigürasyonda, isteklerin %90’ı ilk sunucuya (eski sürüm), %10’u ise ikinci sunucuya (yeni sürüm) gider. Deploy script’imiz, yeni sürümün IP adresini ekledikten sonra ağırlıkları dinamik olarak güncelleyebilir.

Aşamalı olarak ağırlıkları artırarak trafiği yeni sürüme aktarabiliriz:

• Aşama 1: %90 Eski, %10 Yeni
• Aşama 2: %70 Eski, %30 Yeni
• Aşama 3: %50 Eski, %50 Yeni
• Aşama 4: %10 Eski, %90 Yeni
• Aşama 5: %0 Eski, %100 Yeni (ve eski sunucu kaldırılır)

Bu yaklaşım, yeni sürümün üretim ortamındaki gerçek yük altında nasıl performans gösterdiğini gözlemlememize olanak tanır. Eğer yeni sürümde bir sorun tespit edilirse, Nginx konfigürasyonunu hızla eski sürüme döndürebiliriz.

Canary deploy, özellikle büyük ölçekli ve kritik sistemlerde riski azaltmak için tercih edilir. Ancak, yönetimi Blue-Green’e göre biraz daha karmaşık olabilir. Her aşamada konfigürasyon güncellemesi ve dikkatli izleme gerektirir.

Otomasyon ve Scripting

Bu stratejilerin sorunsuz çalışması için otomasyon şarttır. Manuel olarak Nginx konfigürasyonunu güncellemek ve nginx -s reload komutunu çalıştırmak, hem hataya açık hem de zaman alıcıdır. Bu nedenle, deploy scriptleri oluşturmak kritik öneme sahiptir.

Bash scripting, Python veya Ansible gibi araçlar bu otomasyonu sağlamak için kullanılabilir. Bir deploy script’i şu adımları içerebilir:

1. Yeni Docker imajını çekme ve konteyneri başlatma.
2. Yeni konteynerın çalışır durumda olduğunu ve uygulamanın sağlıklı olduğunu doğrulama (health check).
3. Nginx konfigürasyon dosyasını güncelleme:
   • Yeni konteynerın IP adresini ilgili upstream bloğuna ekleme.
   • Gerekirse ağırlıkları veya proxy_pass hedefi güncelleme.
4. nginx -s reload komutunu çalıştırarak Nginx konfigürasyonunu yeniden yükleme.
5. Belirli bir süre boyunca yeni sürüm üzerindeki trafiği izleme.
6. Eğer her şey yolundaysa, eski konteynerları durdurma ve upstream’den çıkarma.
7. Sorun tespit edilirse, otomatik olarak eski konfigürasyona dönme ve/veya eski konteynerları canlı tutma.

Bu otomasyon, deploy süreçlerini hem güvenilir hem de hızlı hale getirir. Özellikle sık sık küçük güncellemeler yapan ekipler için büyük bir verimlilik artışı sağlar.

Sonuç

VPS üzerinde Docker ile çalışan uygulamalarınız için sıfır kesinti deploy stratejileri uygulamak, Nginx’in güçlü yönlerini kullanarak oldukça mümkündür. Blue-Green ve Canary deploy gibi yöntemler, trafiği akıllıca yöneterek ve doğru otomasyonla birleştiğinde, kullanıcı deneyimini kesintisiz tutmamızı sağlar.

Teknoloji dünyasında her zaman olduğu gibi, burada da trade-off’lar var. Blue-Green daha basit bir geri dönüş sunarken, Canary daha kontrollü bir geçiş sağlar. Hangi stratejiyi seçeceğiniz, uygulamanızın kritikliği, ekibinizin yetkinliği ve mevcut altyapı kaynaklarınıza bağlı olacaktır. Ancak, Nginx’i akıllıca kullanarak ve otomasyona yatırım yaparak, deploy süreçlerinizi önemli ölçüde iyileştirebilir ve kesinti sürelerini minimuma indirebilirsiniz.