Sıfır Kesinti Süreli Dağıtım: Docker'lı Uygulamanızı Mavi-Yeşil Tekniğiyle Yükseltin

Bir ay önce yazdığım bir makalede Python web uygulamanızı bir üretim (veya geliştirme öncesi/hazırlama) ortamına sürekli olarak nasıl dağıtacağınızdan bahsetmiştim.

Yakın zamanda iki sesi eşleştirecek ve her ikisinin de eşleşip eşleşmediğine dair bir tahmin puanı verecek bir mikro hizmet (Python ve FastAPI kullanarak) oluşturmakla görevlendirildim. Paydaşlar sesle kilit açma özelliği talep etmişlerdi.

Bir mühendislik toplantımız vardı ve ben görevi üstlenmek için ayağa kalktım (ya da liderim beni savundu, haha).

Daha önce bir makine öğrenimi modeliyle hiç çalışmadığım (eğitimli veya başka bir şey) olmadığım için bu ilginç bir görevdi. Kodu tasarlamam, oluşturmam ve bir AWS EC2 bulut sunucusuna göndermem bir haftamı aldı. CI/CD'nin büyük bir hayranıyım, bu yüzden en rahat ettiğim şeyi kullandım: GitHub Eylemleri.

Bir hafta sonra… Değişiklikler istendi ve araştırdığım yeni bir [konuşlandırma] tekniğini denemek istedim. Yeniden dağıtım yaptığımda herhangi bir kesinti yaşamamak için, AWS EC2 Örneğinde docker'lı mikro hizmet uygulamasının düzgün bir şekilde çalışmasına ihtiyacım vardı.

Ve kollarımda mükemmel bir numara vardı.

Bu hile şudur: mavi-yeşil tekniği .

Mavi/Yeşil Dağıtımlara ilişkin AWS Teknik İncelemesine göre bu, iki ayrı ancak aynı ortamı oluşturduğunuz bir dağıtım stratejisidir.

Bir ortam (mavi) geçerli uygulama sürümünü çalıştırıyor ve bir ortam (yeşil) yeni uygulama sürümünü çalıştırıyor. Mavi/yeşil dağıtım stratejisi kullanmak, uygulamanın kullanılabilirliğini artırır ve dağıtımın başarısız olması durumunda geri alma sürecini basitleştirerek dağıtım riskini azaltır.

Yeşil ortamda testler tamamlandıktan sonra canlı uygulama trafiği yeşil ortama yönlendirilir ve mavi ortam kullanımdan kaldırılır.

Basit bir ifadeyle mavi/yeşil dağıtım tekniği, iki özdeş üretim ortamını çalıştırarak kesinti süresini ve riski azaltmanın bir yoludur.

Böyle bir konuşlandırma tekniğini ilk kez duyuyorsanız, kesinlikle korkacak bir şey yok; size mavi-yeşil konuşlandırmayı başarmanıza yardımcı olacak ayrıntılı adımlar sunacağım.

Hemen adımlara geçelim:

1. Güncellenmiş kodunuzla yeni bir liman işçisi görüntüsü oluşturarak başlayın ve bunu yeni bir sürüm numarasıyla etiketleyin.

   
   

 $ docker build -t myexample:v2 .

Bu, geçerli dizindeki Dockerfile kullanarak myexample:v2 etiketli yeni bir Docker görüntüsü oluşturacaktır.

myexample:v2 yeni oluşturulan liman işçisi görüntüsünün adıdır. Benim durumumda bu, ML projesinin adıydı. Örneğin, docker build -t companyx-servicename-backend:v2

2. Yeni görüntüden yeni bir Docker kapsayıcısı başlatın ancak bunu henüz dış dünyaya sunmayın.

   
   

 $ docker run -d --name myexample-v2 myexample:v2

Bu myexample:v2 görüntüsünden myexample-v2 adında yeni bir Docker kapsayıcısı başlatacaktır.

3. Yeni kabın başlatılmasını ve başlatılmasını bekleyin ve düzgün çalıştığından emin olun.

   
   

 $ docker logs myexample-v2

Yeni konteynerin düzgün şekilde başlatıldığından ve başlatıldığından emin olmak amacıyla günlüklerini kontrol etmek için docker logs komutunu kullanın.

4. Trafiği hem eski hem de yeni kapsayıcılara yönlendirmek için NGINX gibi bir ters proxy kullanın. Ters proxy'nizi istekleri dinleyecek ve bunları hem eski hem de yeni kapsayıcılara iletecek şekilde yapılandırın. Bu, trafiği kademeli olarak yeni konteynere kaydırmanıza olanak tanır.

Burada iki kapsayıcıyı yönlendiren bir NGINX yapılandırması örneği verilmiştir:

 upstream myexample { server myexample-v1:8000; server myexample-v2:8000 backup; } server { listen 80; server_name myexample.com; location / { proxy_pass http://myexample; } }

Bu yapılandırma, iki sunucuya sahip myexample adı verilen bir yukarı akış grubu kurar: myexample-v1 ve myexample-v2 . backup anahtar sözcüğü ikinci sunucuyu yedek olarak işaretlemek için kullanılır. proxy_pass yönergesi, istekleri myexample yukarı akış grubuna iletmek için kullanılır.

Uygulamanızın adını ve bağlantı noktasını yansıtacak şekilde ters proxy yapılandırmasını güncellediğinizden emin olun.

5. Ters proxy yapılandırmasını ayarlayarak trafiği yavaş yavaş eski kapsayıcıdan yeni kapsayıcıya aktarın.

   
   

Trafiği yeni kapsayıcıya kaydırmak için ters proxy yapılandırmasını yeni kapsayıcıya daha fazla ağırlık verecek şekilde ayarlayın. Bu, backup anahtar sözcüğünü sunucu yönergesinden kaldırarak yapılabilir:

 upstream myexample { server myexample-v1:8000; server myexample-v2:8000; } server { listen 80; server_name myexample.com; location / { proxy_pass http://myexample; } }

Bu, NGINX'in myexample-v2 kapsayıcısına daha fazla istek göndermesine neden olur. Uygulamanızı izleyin ve tüm trafik yeni kapsayıcıya akana kadar yapılandırmayı gerektiği gibi ayarlayın.

6. Tüm trafik yeni konteynere aktığında, eski konteyneri güvenli bir şekilde durdurabilir ve kaldırabilirsiniz.

   
   

 $ docker stop myexample-v1 $ docker rm myexample-v1

Bu, eski kapsayıcıyı durdurup kaldıracak ve sunucudaki kaynakları serbest bırakacaktır.

Çözüm

Bu teknikte yeniyim ve açıkçası bu konuda pek bir şey bilmiyorum. Ancak bunun ödünleşimlerini ve daha iyi sonuç verecek diğer teknikleri öğrenmeye devam edeceğim. Benimle paylaşmak isteyeceğin bir veya iki numaran var mı?

Bunu takdir edeceğim. Alayım (yorum bölümünde).

Ah, ah. Sıkıcı bültenime abone olmayı unutmayın. İlk çeyrekten bu yana pek çok şey öğrendim ve bunları yakında paylaşacağım. Merhaba.