Bir ay önce yazdığım bir 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. makalede Uygulamanızı başka bir dilde dağıtmak için önceki makaleye başvurabilirsiniz. İş akışı dosyasını değiştirdiğinizden emin olun. 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. Gizlilik sözleşmesi nedeniyle şirketim için oluşturduğum ürünün dağıtım adımlarını geçmek istemediğim için, örneğin hayali bir ürün kullanacağız. Haha. Hemen adımlara geçelim: 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 kullanarak etiketli yeni bir Docker görüntüsü oluşturacaktır. Dockerfile 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, myexample:v2 docker build -t companyx-servicename-backend:v2 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 görüntüsünden adında yeni bir Docker kapsayıcısı başlatacaktır. myexample:v2 myexample-v2 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. 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: ve . anahtar sözcüğü ikinci sunucuyu yedek olarak işaretlemek için kullanılır. yönergesi, istekleri yukarı akış grubuna iletmek için kullanılır. myexample-v1 myexample-v2 backup proxy_pass myexample Uygulamanızın adını ve bağlantı noktasını yansıtacak şekilde ters proxy yapılandırmasını güncellediğinizden emin olun. 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 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. myexample-v2 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 Uygulamanız ilişkisel bir veritabanına dayanıyorsa mavi-yeşil dağıtım stratejisi, güncellemeler yapıldığında Mavi ve Yeşil veritabanları arasında tutarsızlıkların ortaya çıkmasına neden olabilir. En üst düzeyde veri bütünlüğünü sağlamak için hem geçmiş hem de gelecek sürümlerle uyumlu birleştirilmiş bir veritabanı kurmanız önerilir. 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.
