Kanarya sürüm stratejisi Mavi / Yeşil'e karşı

Benim anlayış kanarya salımının açıldığında yapışkan oturumları ile üretim düğümler bir alt kümesine kısmi tahliye olmasıdır. Bu şekilde, kötü bir hata yayınlarsanız etkilenen kullanıcı / müşteri sayısını kontrol edebilir ve en aza indirebilirsiniz.

Benim anlayış mavi / yeşil salımının size 2 yansıtılmış üretim ortamlarını olması ( "mavi" ve "yeşil") ve bir kerede ya mavi ya da yeşil tüm düğümlere dışarı değişiklikleri itmek ve sonra kontrole ağ büyü kullanmak kullanıcıların DNS aracılığıyla hangi ortama yönlendirildiği.

Yani, başlamadan önce, şimdiye kadar söylediğim herhangi bir şey yanlışsa, lütfen beni düzelterek başlayın!

Aşağı yukarı doğru yolda olduğumu varsayarsak, iki strateji hakkında birkaç soru:

• Kanaryanın mavi / yeşile tercih edildiği ve bunun tersinin olduğu senaryolar var mı?
• Bir dağıtım modelinin her iki stratejiyi aynı anda uygulayabileceği senaryolar var mı?

Mavi-yeşil serbest bırakma daha basit ve daha hızlıdır.

Sen edebilir bir test ortamında yeni sürümü test edilmiş ve yeni sürümü üretimde düzgün olacağı çok kesindir yaptıysanız mavi-yeşil bir açıklaması yapmak. Her zaman özellik geçişlerini kullanmak , yeni bir sürüme olan güveninizi artırmanın iyi bir yoludur, çünkü yeni sürüm, biri bir özellik geçişini çevirene kadar tam olarak eski sürüm gibi çalışır. Uygulamanızı küçük, bağımsız olarak yayınlanabilir hizmetlere bölmek başka bir şeydir, çünkü test edilecek daha az şey ve bozulabilecek daha az şey vardır.

Sen gerek yeni versiyon üretiminde düzgün olacağı tamamen emin değilseniz kanarya yayın yapmak. Kapsamlı bir test uzmanı olsanız bile, İnternet büyük ve karmaşık bir yerdir ve her zaman beklenmedik zorluklarla karşılaşır. Özellik geçişlerini kullansanız bile, biri yanlış uygulanabilir.

Dağıtım otomasyonu çaba gerektirir, bu nedenle çoğu kuruluş her seferinde bir stratejiyi veya diğerini kullanmayı planlayacaktır.

Kendinizden emin olmanızı sağlayan uygulamalara bağlıysanız, mavi-yeşil dağıtımı yapın. Aksi takdirde kanaryayı gönderin.

Mavi-yeşilin özü, hepsini aynı anda dağıtmaktır ve canary dağıtımının özü, aşamalı olarak dağıtmaktır, bu nedenle tek bir kullanıcı havuzu göz önüne alındığında, her ikisini de aynı anda yapmak olarak tanımlayacağım bir işlem düşünemiyorum. Birden çok bağımsız kullanıcı havuzunuz varsa, örneğin farklı bölgesel veri merkezleri kullanıyorsanız, veri merkezlerinde her veri merkezinde ve kanarya içinde mavi-yeşil yapabilirsiniz. Bir veri merkezinde canary dağıtımına ihtiyacınız olmasa da, muhtemelen veri merkezlerinde buna ihtiyaç duymazsınız.

Bu konuyla ilgili ayrıntılı bir makale yazdım: http://blog.itaysk.com/2017/11/20/deployment-strategies-defined

Kanımca fark, yeni 'yeşil' versiyonun gerçek kullanıcılara açık olup olmadığıdır. Öyleyse, ona Kanarya derim. Canary'yi uygulamanın yaygın bir yolu, belirli kullanıcıların yeni sürüme akıllı yönlendirmesinin eklenmesiyle normal Mavi / Yeşil'dir. Ayrıntılı bir karşılaştırma için yazıyı okuyun

Mavi-yeşil:

Kanarya:

Bu terimlerin her ikisi de birbirine oldukça yakın görünse de, ince farklılıkları vardır. Biri işlevsellik sürümünüze güven verirken, diğeri yayınlama şeklinize güven verir.

Kanarya

1. Kanarya sürümü, değişikliği tüm altyapıya yaymadan önce küçük bir kullanıcı alt kümesine yavaşça dağıtarak üretimde yeni bir yazılım sürümü sunma riskini azaltmaya yönelik bir tekniktir.

2. Yeni sürümün nasıl çalışacağı hakkında bir fikir edinmek üzere (diğer uygulamalarla, CPU, bellek, disk kullanımı vb. İle entegre edin).

Mavi-yeşil:

1. Daha çok, sıfır kesinti dağıtımıyla öngörülebilir sürümle ilgilidir.
2. Arıza durumunda kolay geri dönüşler.
3. Tamamen otomatikleştirilmiş dağıtım süreci

İşte bazı satır içi tanımlar -

• Mavi-Yeşil Dağıtım - Bir uygulamanın yeni bir sürümünü dağıtırken, ikinci bir ortam oluşturulur. Yeni ortam test edildikten sonra eski sürümden devralır. Eski ortam daha sonra kapatılabilir.

   

• A / B Testi - Bir uygulamanın iki sürümü aynı anda çalışıyor. İsteklerin bir kısmı her birine gider. Geliştiriciler daha sonra sürümleri karşılaştırabilir.  
• Canary Release - Eski sürümlerle birlikte bir mikro hizmetin yeni bir sürümü başlatılır. Bu yeni sürüm daha sonra taleplerin bir kısmını alabilir ve ekip bu yeni sürümün genel sistemle nasıl etkileşim kurduğunu test edebilir.

Tanımlara iyi bir başlangıç. "Yayın" tanımınızı "dağıtma" ve "yayınlama (işlevsellik)" olarak ayırırsanız, stratejiniz için bir karar vermenize de yardımcı olacağını düşünüyorum.

Dağıt (ikili dosyalar)

Ürününüzün bir (üretim) sistemine ikili dağıtımı eylemi.

Sürüm (işlevsellik)

Kullanıcıların (gruplarının) işlevselliğinin kullanılabilirliğini yönetme eylemi.

Neden? "Yayınlarken" genellikle (birden çok) iki endişeniz vardır: 1) Hatalar / geriye dönük uyumluluk / vb. 2) Yeni özelliklerin geçerliliğini / kullanılabilirliğini doğrulama

Ardından, bir Kanarya veya Mavi / yeşil veya gri / karma mod stratejisi seçmeden önce kendinize sorun: Yeni sürümü yayınlarken / dağıtırken ne gibi endişelerimiz var? Ve ancak o zaman endişelerinizi biliyorsanız, stratejinizi seçin.

Ek olarak, daha karmaşık Dağıtma / Bırakma stratejileri yapmak da mümkündür. Örneğin, bazı bulutlarda / infra'da birden fazla üretim sunucusuna sahip olmak ve yükü farklı oranlarda ürününüzün farklı sunucularına ve sürümlerine aktarmak ve bir sürümü / dağıtımı tüm kullanıcılara ölçeklendirmeden önce sağlamlığı izlemek mümkündür.

Özellik işaretlemesi

Hangi (grup) kullanıcı için mevcut olan (olmayan) işlevselliğin "yapılandırma" (soğuk veya hatta sıcak) eylemi

Ayrıca "özellik işaretleme" gibi bir şey yaparsanız, ilk önce dağıtabilir, sürümünüzün sağlamlığını geriye dönük uyumluluk / hata perspektifinde ölçebilir ve yeni işlevleri kademeli olarak farklı kullanıcılara yayınlayabilir veya tam tersi (küçültme veya hatta geri alma işlevi ve / veya ikili dosyalar) ). Özellik işaretlemesi, işlevselliğin kullanılabilirliğini ikili dosyaların dağıtımından ayırmaya olanak tanır ve çok daha ayrıntılı karar verme, yalnızca "dağıtma / geri alma" sağlar