Canary Sürümlerini Apache APISIX ile Uygulamak

Birkaç kelimeyle söylemek gerekirse, canary sürümlerinin ardındaki fikir, kullanıcıların yalnızca küçük bir kısmına yeni bir yazılım sürümü sunmak, sonuçları analiz etmek ve daha ileri gidip gitmeyeceğine karar vermektir. Sonuçlar beklentilerle uyumlu değilse geri dönün; eğer öyleyse, tüm kullanıcılar yeni sürümden yararlanıncaya kadar maruz kalan kullanıcı sayısını artırın.

Bu yazıda, bu girişi kısaca detaylandırmak, kesir tanımlamanın farklı yollarını açıklamak ve bunun Apache APISIX ile nasıl yürütüleceğini göstermek istiyorum.

Kanarya salınımlarına giriş

"Kanarya" terimi kömür madenciliği endüstrisinden gelmektedir. Madencilik yaparken zehirli gazların salınması alışılmadık bir durum değildir: Küçük kapalı bir alanda bu, hızlı ölüm anlamına gelebilir. Daha da kötüsü, gaz kokusuz olabilir, bu nedenle madenciler ayrılmak için çok geç olana kadar onu soluyacaktır. Karbon monoksit kömür madenlerinde oldukça yaygındır ve insan duyuları tarafından algılanamaz.

Bu nedenle madenciler kanaryaları yanlarında yeraltına getirdiler. Kanarya aniden ölürse, böyle bir gaz cebinin delinmiş olma ihtimali yüksekti ve orayı terk etme zamanı çoktan gelmişti.

Yıllar önce, bu yaklaşımı yeni bir yazılım sürümünün yayınlanmasına getirdik. Analoji şu şekildedir: Madenciler, sürümü dağıtan Operasyon ekibidir, kanarya, sürümün etkisini ölçmek için tüm araçlardan oluşur ve gaz (kritik) bir hatadır.

En önemli kısım, hata oranları, HTTP durum kodları vb. dahil olmak üzere sürümün etkisini ölçmeniz ve bunları önceki sürümünkilerle karşılaştırmanız gerektiğidir . Bu yazının kapsamı dışında ama yine de kanarya sürümlerinden faydalanmak istiyorsanız bu çok önemli. İkinci en önemli kısım, yeni sürümün hatalı olması durumunda hızlı bir şekilde geri dönebilme yeteneğidir.

Kanarya sürümleri ve özellik bayrakları

Yeni kod yayınlama riskini yönetmenin tek yolunun kanarya sürümleri olmadığını unutmayın. Örneğin, özellik bayrakları başka bir popüler yoldur:

• Kanarya yaklaşımı, yeni bileşen sürümündeki tüm özellikleri sunar
• Özellik bayrakları da bileşeni dağıtır ancak özel yapılandırma parametreleri her özelliğin ayrı ayrı etkinleştirilmesine ve devre dışı bırakılmasına olanak tanır

Özellik bayrakları, geri alma işlemlerine yönelik (kelimenin tam anlamıyla) daha çevik bir yaklaşımı temsil eder. 10 özellikten biri sorunluysa yeni sürümün dağıtımını geri almanıza gerek yoktur; yalnızca buggy özelliğini devre dışı bırakırsınız. Ancak bu süper güç, ister üçüncü taraf ürünlere güvenin ister kendiniz uygulayın, ek kod tabanı karmaşıklığı pahasına gelir.

Öte yandan Canary'nin istediği zaman konuşlandırılabilmesi ve dağıtılabilmesi için olgun bir dağıtım hattına ihtiyacı vardır.

Kanarya salınımına yaklaşımlar

Canary sürümlerinin arkasındaki fikir, kullanıcıların yalnızca bir kısmının yeni sürüme erişmesine izin vermektir. Çoğu kanarya tanımı "kesir"i yalnızca kullanıcıların yüzdesi olarak tanımlar. Ancak dahası da var.

İlk adım, yalnızca incelenen kullanıcıların üretim ortamındaki dağıtımın beklendiği gibi çalışıp çalışmadığını kontrol etmesine izin vermek olabilir. Bu durumda, yeni sürüme yalnızca belirli bir dahili kullanıcı grubunu ( örneğin test kullanıcıları) iletebilirsiniz. Kişileri önceden tanıyorsanız ve sistem kullanıcıların kimliğini doğruluyorsa, bunu kimliğe göre yapılandırabilirsiniz; değilse, bazı genel yollara geri dönmeniz gerekir, örneğin , HTTP başlıkları - X-Canary: Let-Me-Go-To-v2 .

Tutarsızlıklara bakmak için eski ve yeni sistemleri izlememiz gerektiğini unutmayın. Hiçbir şey görünmüyorsa, yeni sürüme yönlendirilen kullanıcı havuzunu artırmanın tam zamanıdır. Kendi köpek mamanızı yediğinizi varsayıyorum ; ekip üyeleri geliştirdikleri yazılımı kullanır. Örneğin lüks otomobillere yönelik bir e-ticaret siteniz yoksa bu bölümü atlayabilirsiniz.

Riskleri sınırlandırırken kullanıcı sayısını artırmak için artık yeni sürümü ayrım gözetmeksizin dahili kullanıcılara sunabiliyoruz. Bunu yapmak için sistemi istemci IP'sine göre yeni sürüme iletecek şekilde yapılandırabiliriz. İnsanların sahada çalıştığı bir dönemde IP'leri belirli bir aralıkta olduğundan bu kolaydı. Kullanıcılar muhtemelen şirketin ağına bir VPN aracılığıyla eriştiği için uzaktan kumanda pek değişmiyor.

Bu noktada tekrar izleyin ve karşılaştırın.

Dokuz metrenin tamamı

Bu noktada, iç kullanıcıların bir kısmı veya tamamı için her şeyin beklendiği gibi çalışması gerekir. Ancak hiçbir plan düşmanla temasta hayatta kalamayacağı gibi, hiçbir kullanım da üretimdeki iş yükünün tüm çeşitliliğini taklit edemez. Kısaca, şu ana kadar kullanıcı sayımızı kademeli olarak artırdığımız gibi, düzenli kullanıcıların da yeni sürüme kontrollü olarak erişmesine izin vermemiz gerekiyor: Küçük bir kesirle başlayın, izleyin, her şey yolundaysa kesirli olanı artırın. .

Bunu Apache APISIX ile nasıl yapacağınız aşağıda açıklanmıştır. Apache APISIX, eklenti tabanlı bir mimari sunar ve ihtiyaçlarımızı karşılayan bir eklenti yani traffic-split eklentisi sağlar.

traffic-split Eklentisi, trafik bölümlerini dinamik olarak çeşitli Yukarı Akış hizmetlerine yönlendirmek için kullanılabilir.

Bu, trafiği bölmek için özel kurallar olan match ve trafiği yönlendirecek bir Yukarı Akış kümesi olan weighted_upstreams yapılandırılarak yapılır.

-- trafik bölünmüş

Her sürüm için bir tane olmak üzere bazı temel yukarı akışlarla başlayalım:

 upstreams: - id: v1 nodes: "v1:8080": 1 - id: v2 nodes: "v2:8080": 1

Trafiğin çoğunu v1'e ve bir kısmını da v2'ye iletmek için traffic-split eklentisini kullanabiliriz:

 routes: - id: 1 uri: "*" #1 upstream_id: v1 plugins: traffic-split: rules: - weighted_upstreams: #2 - upstream_id: v2 #3 weight: 1 #3 - weight: 99 #3

1. Her şeyi kapsayan bir rota tanımlayın
2. Trafiğin nasıl bölüneceğini yapılandırın; işte, ağırlıklar
3. Trafiğin %99'unu v1'e ve %1'ini v1'e iletin. Ağırlıkların birbirine göre olduğunu unutmayın. 50/50 elde etmek için ağırlıkları 1 ve 1, 3 ve 3, 50 ve 50 vb. olarak ayarlayabilirsiniz.

Yine her şeyi izliyoruz ve sonuçların beklendiği gibi olduğundan emin oluyoruz. Daha sonra v2'ye iletilen trafiğin oranını artırabiliriz, örneğin :

 routes: - id: 1 uri: "*" upstream_id: v1 plugins: traffic-split: rules: - weighted_upstreams: - upstream_id: v2 weight: 5 #1 - weight: 95 #1

1. Trafiği v2'ye %5'e çıkarın

Apache APISIX'in dosyadaki değişiklikleri her saniyede bir yeniden yüklediğini unutmayın. Böylece trafiği neredeyse gerçek zamanlı olarak bölersiniz. Alternatif olarak, aynısını başarmak için Admin API'yi kullanabilirsiniz.

Daha kontrollü sürümler

Yukarıda dahili kullanıcılardan harici kullanıcıların bir kısmına geçtim. Belki de her dahili kullanıcıya yayınlamak kuruluşunuzda çok büyük bir risktir ve daha fazla kontrole ihtiyacınız vardır. Bu durumda traffic-split eklentisini daha da yapılandırabileceğinizi unutmayın.

 routes: - id: 1 uri: /* upstream_id: v1 plugins: traffic-split: rules: - match: - vars: [["http_X-Canary","~=","Let-Me-Go-To-v2"]] #1 - weighted_upstreams: - upstream_id: v2 weight: 5 - weight: 95

1. Trafiği yalnızca X-Canary HTTP üstbilgisi yapılandırılmış değere sahipse bölün.

Aşağıdaki komut her zaman v1'e iletir:

 curl http://localhost:9080

Aşağıdaki komut da her zaman v1'e iletir:

 curl -H 'X-Canary: Let-Me-Go-To-v1' http://localhost:9080

Aşağıdaki komut, trafiği yapılandırılmış ağırlıklara göre (95/5) böler:

 curl -H 'X-Canary: Let-Me-Go-To-v2' http://localhost:9080

Çözüm

Bu gönderide kanarya sürümleri ve Apache APISIX aracılığıyla bir tanesini nasıl yapılandırabileceğiniz anlatıldı. Farklı önceliklere sahip birkaç rotayla başlayabilir ve traffic-split eklentisine geçebilirsiniz. İkincisi, daha karmaşık kullanım durumlarına izin verecek şekilde daha da yapılandırılabilir.

Bu yazının kaynak kodunun tamamı GitHub'da bulunabilir.

Daha ileri gitmek için:

• Apache APISIX'e dayalı canary sürüm çözümünün uygulanması
• Apache APISIX Girişi ile Kubernetes'te Canary Sürümü
• Flagger ile APISIX Giriş Denetleyicisini Kullanarak Sorunsuz Canary Sürümü