Azure'da görev açısından kritik iş yükleri için dağıtım ve test

Görev açısından kritik ortamın dağıtımı ve testi, genel başvuru mimarisinin önemli bir parçasıdır. Tek tek uygulama damgaları, kaynak kod deposundan kod olarak altyapı kullanılarak dağıtılır. Altyapıya Güncelleştirmeler ve uygulama en üstte, uygulamaya sıfır kapalı kalma süresiyle dağıtılmalıdır. DevOps sürekli tümleştirme işlem hattının depodan kaynak kodunu alması ve tek tek damgaları Azure'a dağıtması önerilir.

Dağıtım ve güncelleştirmeler mimarinin merkezi sürecidir. Altyapı ve uygulamayla ilgili güncelleştirmeler tamamen bağımsız damga pullarına dağıtılmalıdır. Damga pullarında yalnızca mimarideki genel altyapı bileşenleri paylaşılır. Altyapıdaki mevcut damga pullarına dokunulmaz. Altyapı güncelleştirmeleri yalnızca bu yeni damga pullarına dağıtılır. Benzer şekilde, yeni uygulama sürümü yalnızca bu yeni damga pullarına dağıtılır.

Yeni damga pulları Azure Front Door'a eklenir. Trafik yavaş yavaş yeni damga pullarına taşınır. Trafiğin yeni damga pullarından sorunsuz olarak sunulduğu belirlendiğinde, önceki damga pulları silinir.

Dağıtılan ortam için sızma, kaos ve stres testi önerilir. Altyapının proaktif olarak test edilmesi, zayıf noktaları ve bir hata olduğunda dağıtılan uygulamanın nasıl davranacağını keşfeder.

Dağıtım

Başvuru mimarisinde altyapının dağıtımı aşağıdaki işlemlere ve bileşenlere bağlıdır:

• DevOps - GitHub'dan kaynak kodu ve altyapının işlem hatları.

• Sıfır kapalı kalma süresi güncelleştirmesi - Güncelleştirmeler ve yükseltmeler dağıtılan uygulamaya sıfır kapalı kalma süresiyle ortama dağıtılır.

• Ortamlar - Mimari için kullanılan kısa süreli ve kalıcı ortamlar.

• Paylaşılan ve ayrılmış kaynaklar - Damga pullarına ve genel altyapıya ayrılmış ve paylaşılan Azure kaynakları.

Daha fazla bilgi için bkz. Azure'da görev açısından kritik iş yükleri için dağıtım ve test: Tasarım konuları

Dağıtım: DevOps

DevOps bileşenleri, altyapının ve güncelleştirmelerin dağıtımı için kaynak kod deposunu ve CI/CD işlem hatlarını sağlar. Bileşenler olarak GitHub ve Azure Pipelines seçildi.

• GitHub - Uygulama ve altyapı için kaynak kodu depolarını içerir.

• Azure Pipelines - Tüm derleme, test ve yayın görevleri için mimari tarafından kullanılan işlem hatları.

Dağıtım için kullanılan tasarımdaki ek bileşenlerden biri de derleme aracılarıdır. Microsoft Barındırılan derleme aracıları, altyapıyı ve güncelleştirmeleri dağıtmak için Azure Pipelines'ın bir parçası olarak kullanılır. Microsoft Barındırılan derleme aracılarının kullanılması, geliştiricilerin derleme aracısını korumaları ve güncelleştirmeleri için yönetim yükünü ortadan kaldırır.

Azure Pipelines hakkında daha fazla bilgi için bkz. Azure DevOps Services nedir?.

Daha fazla bilgi için bkz. Azure'da görev açısından kritik iş yükleri için dağıtım ve test: Kod Olarak Altyapı dağıtımları

Dağıtım: Sıfır kapalı kalma süresi güncelleştirmesi

Başvuru mimarisindeki sıfır kapalı kalma süresi güncelleştirme stratejisi, genel görev açısından kritik uygulamanın merkezidir. Damga pullarının yükseltilmesinin yerine değiştirme yöntemi, uygulamanın bir altyapı damgasına yeni bir şekilde yüklenmesini sağlar. Başvuru mimarisi mavi/yeşil yaklaşımı kullanır ve ayrı test ve geliştirme ortamları sağlar.

Başvuru mimarisinin iki ana bileşeni vardır:

• Altyapı - Azure hizmetleri ve kaynakları. Terraform ve ilişkili yapılandırmasıyla dağıtıldı.

• Uygulama - Kullanıcılara hizmet veren barındırılan hizmet veya uygulama. Tek sayfalı uygulama (SPA) kullanıcı arabirimi için Html ve JavaScript'te Docker kapsayıcılarını ve npm derleme yapıtlarını temel alır.

Birçok sistem için, uygulama güncelleştirmelerinin altyapı güncelleştirmelerinden daha sık olacağı varsayımı vardır. Sonuç olarak, her biri için farklı güncelleştirme yordamları geliştirilir. Genel bulut altyapısıyla değişiklikler daha hızlı gerçeklenebilir. Uygulama güncelleştirmeleri ve altyapı güncelleştirmeleri için bir dağıtım işlemi seçildi. Bir yaklaşım, altyapı ve uygulama güncelleştirmelerinin her zaman eşitlenmesini sağlar. Bu yaklaşım şunları sağlar:

• Tutarlı bir işlem - Altyapı ve uygulama güncelleştirmelerinin bir sürümde kasıtlı olarak veya değil bir araya getirilip birleştirilmediği hata olasılığı daha azdır.

• Mavi/Yeşil dağıtımı etkinleştirir - Her güncelleştirme, trafiğin yeni sürüme aşamalı geçişi kullanılarak dağıtılır.

• Uygulamanın daha kolay dağıtılması ve hata ayıklaması - Damganın tamamı hiçbir zaman uygulamanın birden çok sürümünü yan yana barındırmaz.

• Basit geri alma - Hatalarla veya sorunlarla karşılaşıldığında trafik önceki sürümü çalıştıran damgalara geri döndürülebilir.

• El ile yapılan değişikliklerin ve yapılandırma kaymalarının ortadan kaldırılması - Her ortam yeni bir dağıtımdır.

Daha fazla bilgi için bkz. Azure'da görev açısından kritik iş yükleri için dağıtım ve test: Kısa ömürlü mavi/yeşil dağıtımlar

Dallanma stratejisi

Güncelleştirme stratejisinin temeli, Git deposu içindeki dalların kullanılmasıdır. Başvuru mimarisi üç tür dal kullanır:

Dal	Description
feature/* ve fix/*	Herhangi bir değişikliğin giriş noktaları. Bu dallar geliştiriciler tarafından oluşturulur ve veya fix/worker-timeout-buggibi feature/catalog-update açıklayıcı bir ad verilmelidir. Değişiklikler birleştirilmeye hazır olduğunda, dalda main bir çekme isteği (PR) oluşturulur. Her çekme isteğinin en az bir gözden geçiren tarafından onaylanması gerekir. Sınırlı özel durumlarla, çekme isteğinde önerilen her değişikliğin uçtan uca (E2E) doğrulama işlem hattı üzerinden çalıştırılması gerekir. E2E işlem hattı, geliştiriciler tarafından tam bir ortamda yapılan değişiklikleri test etmek ve hatalarını ayıklamak için kullanılmalıdır.
main	Sürekli ileriye doğru hareket eden ve kararlı dal. Çoğunlukla tümleştirme testi için kullanılır. main için değişiklikler yalnızca çekme istekleri aracılığıyla yapılır. Dal ilkesi doğrudan yazmaları yasaklar. Kalıcı integration (int) ortama karşı gecelik sürümler otomatik olarak daldan main yürütülür. Dal main kararlı olarak kabul edilir. Herhangi bir zamanda, bu sürümden bir yayın oluşturulabileceğini varsaymak güvenli olmalıdır.
release/*	Yayın dalları yalnızca daldan main oluşturulur. Dallar biçimindedir release/2021.7.X. Dal ilkeleri, yalnızca depo yöneticilerinin dal oluşturmasına release/* izin vermek için kullanılır. Ortama dağıtmak prod için yalnızca bu dallar kullanılır.

Daha fazla bilgi için bkz. Azure'da görev açısından kritik iş yükleri için dağıtım ve test: Dallanma stratejisi

Düzeltmeler

Bir hata veya başka bir sorun nedeniyle bir düzeltmeye acilen ihtiyaç duyulduğunda ve normal sürüm işleminden geçemediğinde, bir düzeltme yolu kullanılabilir. İlk test sırasında keşfedilmemiş olan kritik güvenlik güncelleştirmeleri ve kullanıcı deneyimi düzeltmeleri, geçerli düzeltme örnekleri olarak kabul edilir.

Düzeltmenin yeni fix bir dalda oluşturulması ve normal çekme isteği kullanılarak ile main birleştirilmesi gerekir. Yeni bir yayın dalı oluşturmak yerine, düzeltme mevcut bir yayın dalında "tek tek seçilmiştir". Bu dal ortama zaten dağıtılmıştır prod . Yayın dalını ilk olarak tüm testlerle dağıtan CI/CD işlem hattı yeniden yürütülür ve şimdi düzeltmeyi işlem hattının bir parçası olarak dağıtır.

Önemli sorunlardan kaçınmak için, düzeltmenin kolayca tek tek seçilebilen ve yayın dalı ile tümleştirilebilen birkaç yalıtılmış işleme içermesi önemlidir. Yalıtılmış işlemeler yayın dalı ile tümleştirilecek şekilde tek tek seçilemiyorsa, bu değişikliğin bir düzeltme olarak nitelendirilmediğinin bir göstergesidir. Değişiklik tam yeni bir sürüm olarak dağıtılmalı ve yeni sürüm dağıtılana kadar eski kararlı sürüme geri alma işlemiyle birleştirilmelidir.

Dağıtım: Ortamlar

Başvuru mimarisi, altyapı için iki tür ortam kullanır:

• Kısa ömürlü - E2E doğrulama işlem hattı, kısa süreli ortamları dağıtmak için kullanılır. Kısa süreli ortamlar, geliştiriciler için saf doğrulama veya hata ayıklama ortamları için kullanılır. Doğrulama ortamları daldan feature/* oluşturulabilir, testlere tabi tutulabilir ve tüm testler başarılı olursa yok edilebilir. Hata ayıklama ortamları doğrulamayla aynı şekilde dağıtılır, ancak hemen yok edilmez. Bu ortamların birkaç günden uzun süre var olmaması ve özellik dalının ilgili çekme isteği birleştirildiğinde silinmesi gerekir.

• Kalıcı - Kalıcı ortamlarda ve production (prod) sürümleri vardırintegration (int). Bu ortamlar sürekli olarak yaşar ve yok olmaz. Ortamlar int.mission-critical.app gibi sabit etki alanı adları kullanır. Başvuru mimarisinin gerçek dünyada uygulanmasında bir staging (önceden üretim ortamı) eklenmelidir. Ortamstaging, dalları (Mavi/Yeşil dağıtım) ile aynı güncelleştirme işlemiyle prod dağıtmak ve doğrulamak release için kullanılır.

  • Tümleştirme (int) - Sürümint, ile aynı işlemle proddaldan main her gece dağıtılır. Trafiğin geçişi önceki sürüm biriminden daha hızlıdır. içinde olduğu gibi trafiği birden çok gün içinde aşamalı olarak proddeğiştirmek yerine, işlemi int birkaç dakika veya saat içinde tamamlar. Bu hızlı geçiş, güncelleştirilmiş ortamın ertesi sabah hazır olmasını sağlar. İşlem hattındaki tüm testler başarılı olursa eski damgalar otomatik olarak silinir.

  • Üretim (üretim) - Sürüm prod yalnızca dallardan release/* dağıtılır. Trafik geçişi daha ayrıntılı adımlar kullanır. Her adım arasında el ile onay kapısı bulunur. Her sürüm yeni bölgesel damgalar oluşturur ve yeni uygulama sürümünü damga pullarına dağıtır. Bu süreçte mevcut damga pullarına dokunulmaz. Için en önemli nokta prodbunun "her zaman açık" olmasıdır. Planlı veya plansız kapalı kalma süresi oluşmamalıdır. Tek özel durum, veritabanı katmanında yapılan temel değişikliklerdir. Planlı bakım penceresi gerekebilir.

Dağıtım: Paylaşılan ve ayrılmış kaynaklar

Başvuru mimarisindeki kalıcı ortamlar (int ve prod) altyapının tamamıyla paylaşılıp paylaşılmadıklarına veya tek bir damgaya ayrılmış olmalarına bağlı olarak farklı türlerde kaynaklara sahiptir. Kaynaklar belirli bir sürüme ayrılmış olabilir ve yalnızca bir sonraki sürüm birimi devralana kadar mevcut olabilir.

Sürüm birimleri

Yayın birimi, belirli bir sürüme göre birkaç bölgesel damgadır. Damga pulları, diğer damga pullarıyla paylaşılmamış tüm kaynakları içerir. Bu kaynaklar sanal ağlar, Azure Kubernetes Service kümesi, Event Hubs ve Azure Key Vault' dır. Azure Cosmos DB ve ACR, Terraform veri kaynaklarıyla yapılandırılır.

Genel olarak paylaşılan kaynaklar

Yayın birimleri arasında paylaşılan tüm kaynaklar bağımsız bir Terraform şablonunda tanımlanır. Bu kaynaklar Front Door, Azure Cosmos DB, Container registry (ACR) ve Log Analytics çalışma alanları ve izlemeyle ilgili diğer kaynaklardır. Bu kaynaklar, yayın biriminin ilk bölgesel damgası dağıtılmadan önce dağıtılır. Kaynaklara damga pulları için Terraform şablonlarında başvurulur.

Front Door

Front Door, damga pulları arasında genel olarak paylaşılan bir kaynak olsa da, yapılandırması diğer genel kaynaklardan biraz farklıdır. Front Door, yeni bir damga pulu dağıtıldıktan sonra yeniden yapılandırılmalıdır. Front Door, trafik üzerinden yeni damga pullarına aşamalı olarak geçiş yapmak için yeniden yapılandırılmalıdır.

Front Door'un arka uç yapılandırması Terraform şablonunda doğrudan tanımlanamaz. Yapılandırma Terraform değişkenleriyle eklenir. Değişken değerleri Terraform dağıtımı başlatılmadan önce oluşturulur.

Front Door dağıtımı için ayrı bileşen yapılandırması şu şekilde tanımlanır:

• Ön uç - Oturum benzitesi, kullanıcıların tek bir oturum sırasında farklı kullanıcı arabirimi sürümleri arasında geçiş yapmamasını sağlamak için yapılandırılır.

• Çıkış noktaları - Front Door iki tür kaynak grubuyla yapılandırılır:

  1. Kullanıcı arabirimine hizmet veren statik depolama için bir kaynak grubu. Grup, şu anda etkin olan tüm sürüm birimlerinin web sitesi depolama hesaplarını içerir. Trafiği aşamalı olarak daha yeni bir birime taşımak için farklı sürüm birimlerinden çıkış noktalarına farklı ağırlıklar atanabilir. Bir yayın ünitesindeki her çıkış noktası aynı ağırlığa sahip olmalıdır.

  2. AKS'de barındırılan API için bir kaynak grubu. Farklı API sürümlerine sahip sürüm birimleri varsa, her yayın birimi için bir API kaynak grubu vardır. Tüm sürüm birimleri aynı uyumlu API'yi sunuyorsa, tüm çıkış noktaları aynı gruba eklenir ve farklı ağırlıklar atanır.

• Yönlendirme kuralları - İki tür yönlendirme kuralı vardır:

  1. Kullanıcı arabirimi depolama kaynak grubuna bağlı kullanıcı arabirimi için bir yönlendirme kuralı.

  2. Şu anda kaynaklar tarafından desteklenen her API için bir yönlendirme kuralı. Örneğin: /api/1.0/* ve /api/2.0/*.

  Bir sürüm arka uç API'lerinin yeni bir sürümünü tanıtırsa, değişiklikler sürümün bir parçası olarak dağıtılan kullanıcı arabirimine yansıtılır. Kullanıcı arabiriminin belirli bir sürümü her zaman API URL'sinin belirli bir sürümünü çağırır. Kullanıcı arabirimi sürümü tarafından sunulan kullanıcılar otomatik olarak ilgili arka uç API'sini kullanır. API sürümünün farklı örnekleri için belirli yönlendirme kuralları gereklidir. Bu kurallar ilgili kaynak gruplarına bağlıdır. Yeni bir API kullanılmadıysa, API ile ilgili tüm yönlendirme kuralları tek kaynak grubuna bağlanır. Bu durumda, bir kullanıcıya API'den farklı bir sürümden kullanıcı arabirimi sunılıp sunulmadığı önemli değildir.

Dağıtım: Dağıtım işlemi

Mavi/yeşil dağıtım, dağıtım işleminin hedefidir. Bir daldan yeni bir release/* sürüm ortama dağıtılır prod . Kullanıcı trafiği, yeni sürümün damgalarına aşamalı olarak kaydırılır.

Yeni sürümün dağıtım sürecinin ilk adımı olarak, yeni sürüm biriminin altyapısı Terraform ile dağıtılır. Altyapı dağıtım işlem hattının yürütülmesi, yeni altyapıyı seçilen bir yayın dalından dağıtır. Altyapı sağlamaya paralel olarak kapsayıcı görüntüleri oluşturulur veya içeri aktarılır ve genel olarak paylaşılan kapsayıcı kayıt defterine (ACR) gönderilir. Önceki işlemler tamamlandığında, uygulama damgalara dağıtılır. Uygulama açısından bakıldığında, birden çok bağımlı aşamaya sahip bir işlem hattıdır. Düzeltme dağıtımları için aynı işlem hattı yeniden yürütülebilir.

Yeni sürüm birimi dağıtılıp doğrulandıktan sonra, kullanıcı trafiğini almak için Front Door'a eklenir.

Yeni bir API sürümü getiren ve tanıtmayan sürümleri ayırt eden bir anahtar/parametre planlanmalıdır. Sürümün yeni bir API sürümü tanıtması durumunda API arka uçlarına sahip yeni bir çıkış noktası grubu oluşturulmalıdır. Alternatif olarak, yeni API arka uçları mevcut bir kaynak grubuna eklenebilir. Yeni kullanıcı arabirimi depolama hesapları ilgili mevcut kaynak grubuna eklenir. Yeni çıkış noktaları için ağırlıklar, istenen trafik bölmesine göre ayarlanmalıdır. Yukarıda açıklandığı gibi uygun kaynak grubuna karşılık gelen yeni bir yönlendirme kuralı oluşturulmalıdır.

Yeni sürüm biriminin eklenmesinin bir parçası olarak, yeni çıkış noktalarının ağırlıkları istenen minimum kullanıcı trafiğine ayarlanmalıdır. Herhangi bir sorun algılanmadıysa, kullanıcı trafiği miktarı belirli bir süre içinde yeni kaynak grubuna artırılmalıdır. Ağırlık parametrelerini ayarlamak için aynı dağıtım adımları istenen değerlerle yeniden yürütülmelidir.

Sürüm biriminin kaldırılması

Bir yayın biriminin dağıtım işlem hattının bir parçası olarak, bir sürüm birimine artık ihtiyaç duyulmadıktan sonra tüm damgaları kaldıran bir yok etme aşaması vardır. Tüm trafik yeni bir sürüme taşınır. Bu aşama, sürüm birimi başvurularının Front Door'tan kaldırılmasını içerir. Bu kaldırma işlemi, yeni sürümün daha sonraki bir tarihte yayınlanmasını sağlamak için kritik öneme sahiptir. Front Door, gelecekte bir sonraki sürüme hazırlıklı olmak için tek bir sürüm birimine işaret etmelidir.

Denetim listeleri

Yayın temposunun bir parçası olarak yayın öncesi ve sonrası denetim listesi kullanılmalıdır. Aşağıdaki örnek, herhangi bir denetim listesinde en az olması gereken öğelerdir.

• Yayın öncesi denetim listesi - Yayına başlamadan önce aşağıdakileri denetleyin:

  • Dalın en son durumunun ortamda başarıyla dağıtıldığından main ve test edildiğinden int emin olun.

  • Değişiklik günlüğü dosyasını dala karşı bir çekme isteği aracılığıyla güncelleştirin main .

  • Daldan main bir release/ dal oluşturun.

• Yayın sonrası denetim listesi - Eski damga pulları yok edilmeden ve başvuruları Front Door'dan kaldırılmadan önce şunları denetleyin:

  • Kümeler artık gelen trafiği almıyor.

  • Event Hubs ve diğer ileti kuyrukları işlenmemiş ileti içermez.

Dağıtım: Güncelleştirme stratejisinin sınırlamaları ve riskleri

Bu başvuru mimarisinde açıklanan güncelleştirme stratejisinin belirtilmesi gereken bazı sınırlamaları ve riskleri vardır:

• Daha yüksek maliyet - Güncelleştirmeler yayımlandığında, altyapı bileşenlerinin çoğu yayın süresi boyunca iki kez etkindir.

• Front Door karmaşıklığı - Front Door'daki güncelleştirme işleminin uygulanması ve bakımı karmaşıktır. Etkin mavi/yeşil dağıtımları sıfır kapalı kalma süresiyle yürütebilme özelliği düzgün çalışmalarına bağlıdır.

• Küçük değişiklikler zaman alır - Güncelleştirme işlemi, küçük değişiklikler için daha uzun bir sürüm sürecine neden olur. Bu sınırlama, önceki bölümde açıklanan düzeltme işlemiyle kısmen azaltılabilir.

Dağıtım: Uygulama verilerini iletme uyumluluğunda dikkat edilmesi gerekenler

Güncelleştirme stratejisi, bir API'nin birden çok sürümünü ve eşzamanlı olarak yürütülen iş bileşenlerini destekleyebilir. Azure Cosmos DB iki veya daha fazla sürüm arasında paylaşıldığından, bir sürümle değiştirilen veri öğelerinin her zaman API'nin veya kullanan çalışanların sürümüyle eşleşmeme olasılığı vardır. API katmanlarının ve çalışanlarının ileriye dönük uyumluluk tasarımı uygulaması gerekir. API'nin veya çalışan bileşenlerinin önceki sürümleri, daha sonraki bir API veya çalışan bileşeni sürümü tarafından eklenen verileri işler. Anlamadığı bölümleri yoksayar.

Test Etme

Başvuru mimarisi, test uygulamasının farklı aşamalarında kullanılan farklı testler içerir.

Bu testler şunlardır:

• Birim testleri - Bu testler, uygulamanın iş mantığının beklendiği gibi çalıştığını doğrular. Başvuru mimarisi, Azure Pipelines tarafından oluşturulan her kapsayıcıdan önce otomatik olarak yürütülen örnek bir birim testi paketi içerir. Herhangi bir test başarısız olursa işlem hattı durdurulacaktır. Derleme ve dağıtım devam etmez.

• Yük testleri - Bu testler belirli bir iş yükü veya yığın için kapasiteyi, ölçeklenebilirliği ve olası performans sorunlarını değerlendirmeye yardımcı olur. Başvuru uygulaması, gerçek trafiğin benzetimini yapmak için kullanılabilecek yapay yük desenleri oluşturmak için bir kullanıcı yük oluşturucu içerir. Yük oluşturucu, başvuru uygulamasından bağımsız olarak da kullanılabilir.

• Duman testleri - Bu testler altyapının ve iş yükünün kullanılabilir olup olmadığını belirler ve beklendiği gibi davranır. Duman testleri her dağıtımın bir parçası olarak yürütülür.

• UI testleri - Bu testler kullanıcı arabiriminin dağıtıldığını ve beklendiği gibi çalıştığını doğrular. Geçerli uygulama, gerçek bir test olmadan yalnızca dağıtımdan sonra birkaç sayfanın ekran görüntülerini yakalar.

• Hata ekleme testleri - Bu testler otomatikleştirilebilir veya el ile yürütülebilir. Mimaride otomatikleştirilmiş test, Azure Chaos Studio'yu dağıtım işlem hatlarının bir parçası olarak tümleştirir.

Daha fazla bilgi için bkz. Azure'da görev açısından kritik iş yükleri için dağıtım ve test: Sürekli doğrulama ve test

Test: Çerçeveler

Çevrimiçi başvuru uygulaması mümkün olduğunda mevcut test özellikleri ve çerçeveleri.

Framework	Test etme	Description
NUnit	Birim	Bu çerçeve, uygulamanın .NET Core bölümünü birim testi için kullanılır. Birim testleri, kapsayıcı derlemelerinden önce Azure Pipelines tarafından otomatik olarak yürütülür.
Azure Load Testing ile JMeter	Yükleme	Azure Load Testing , Apache JMeter yük testi tanımlarını yürütmek için kullanılan yönetilen bir hizmettir.
Locust	Yükleme	Locust, Python'da yazılmış bir açık kaynak yük testi çerçevesidir.
Playwright	Kullanıcı Arabirimi ve Duman	Playwright, Chromium, Firefox ve WebKit'i tek bir API ile otomatikleştirmek için bir açık kaynak Node.js kitaplığıdır. Playwright test tanımı, başvuru uygulamasından bağımsız olarak da kullanılabilir.
Azure Chaos Studio	Hata ekleme	Başvuru uygulaması, dayanıklılık doğrulaması için hataları eklemek üzere E2E doğrulama işlem hattında isteğe bağlı bir adım olarak Azure Chaos Studio'yu kullanır.

Test: Hata Ekleme testi ve Kaos Mühendisliği

Dağıtılmış uygulamalar hizmet ve bileşen kesintilerine karşı dayanıklı olmalıdır. Hata Ekleme testi (Hata Ekleme veya Kaos Mühendisliği olarak da bilinir), uygulamaları ve hizmetleri gerçek dünya streslerine ve hatalarına maruz bırakma uygulamasıdır.

Dayanıklılık, tüm sistemin bir özelliğidir ve hata eklemek uygulamadaki sorunları bulmanıza yardımcı olur. Bu sorunların giderilmesi, uygulamanın güvenilir olmayan koşullara, eksik bağımlılıklara ve diğer hatalara karşı dayanıklılığını doğrulamaya yardımcı olur.

Uygulamadaki hataları ve sorunları bulmak için altyapı üzerinde el ile ve otomatik testler yürütülebilir.

Automatic

Başvuru mimarisi , damga düzeyinde çeşitli hatalar eklemek üzere bir dizi Azure Chaos Studio denemesi dağıtmak ve çalıştırmak için Azure Chaos Studio'yu tümleştirir. Kaos denemeleri, E2E dağıtım işlem hattının isteğe bağlı bir parçası olarak yürütülebilir. Testler yürütürken isteğe bağlı yük testi her zaman paralel olarak yürütülür. Yük testi, eklenen hataların etkisini doğrulamak üzere kümede yük oluşturmak için kullanılır.

El ile

El ile hata ekleme testi bir E2E doğrulama ortamında yapılmalıdır. Bu ortam, diğer ortamlardan müdahale riski olmadan tam temsili testler sağlar. Testlerle oluşturulan hataların çoğu doğrudan Application Insights Canlı ölçümler görünümünde gözlemlenebilir. Kalan hatalar Hatalar görünümünde ve buna karşılık gelen günlük tablolarında kullanılabilir. Diğer hatalar, AKS'nin kubectl içindeki davranışı gözlemlemek için kullanımı gibi daha ayrıntılı hata ayıklama gerektirir.

Başvuru mimarisinde gerçekleştirilen hata ekleme testlerinin iki örneği şunlardır:

• DNS tabanlı hata ekleme - Birden çok sorunun benzetimini yapabilecek bir test çalışması. DNS sunucusunun veya Azure DNS'nin hatasından kaynaklanan DNS çözümleme hataları. DNS tabanlı test, örneğin BackgroundProcessor'ın Event Hubs'a bağlanamama durumu gibi istemci ve hizmet arasındaki genel bağlantı sorunlarının benzetimini yapmaya yardımcı olabilir.

  Tek konaklı senaryolarda, YEREL hosts dosyayı DNS çözümlemesinin üzerine yazacak şekilde değiştirebilirsiniz. AKS gibi birden çok dinamik sunucu içeren daha büyük bir hosts ortamda dosya kullanılamaz. Azure Özel DNS Bölgeleri, test hatası senaryolarına alternatif olarak kullanılabilir.

  Azure Event Hubs ve Azure Cosmos DB, DNS tabanlı hataları eklemek için kullanılabilecek başvuru uygulamasında kullanılan Azure hizmetlerinden ikisidir. Event Hubs DNS çözümlemesi, damgalardan birinin sanal ağına bağlı bir Azure Özel DNS bölgesiyle değiştirilebilir. Azure Cosmos DB, belirli bölgesel uç noktalara sahip genel olarak çoğaltılmış bir hizmettir. Bu uç noktalar için DNS kayıtlarının değiştirilmesi, belirli bir bölge için hata benzetimi yapabilir ve istemcilerin yük devretmesini test edebilir.

• Güvenlik duvarı engelleme - Çoğu Azure hizmeti, sanal ağlara ve/veya IP adreslerine dayalı güvenlik duvarı erişim kısıtlamalarını destekler. Başvuru altyapısında bu kısıtlamalar Azure Cosmos DB veya Event Hubs'a erişimi kısıtlamak için kullanılır. Basit bir yordam, mevcut İzin Ver kurallarını kaldırmak veya yeni Blok kuralları eklemektir. Bu yordam, güvenlik duvarı yanlış yapılandırmalarının veya hizmet kesintilerinin benzetimini yapabilir.

  Başvuru uygulamasındaki aşağıdaki örnek hizmetler bir güvenlik duvarı testi ile test edilebilir:

  Hizmet	Sonuç
  Anahtar Kasası	Key Vault erişimi engellendiğinde, en doğrudan etki yeni podların ortaya çıkmamasıydı. Pod başlatma sırasında gizli dizileri getiren Key Vault CSI sürücüsü görevlerini gerçekleştiremez ve pod'un başlatılmasını engeller. karşılık gelen hata iletileri ile kubectl describe po CatalogService-deploy-my-new-pod -n workloadgözlemlenebilir. Aynı hata iletisi gözlemlenecek olsa da mevcut podlar çalışmaya devam eder. Hata iletisi, gizli diziler için düzenli güncelleştirme denetiminin sonuçları tarafından oluşturulur. Test edilmese de, Key Vault erişilemez durumdayken bir dağıtımı yürütmenin çalışmaymayacağı varsayılır. İşlem hattı çalıştırması içindeki Terraform ve Azure CLI görevleri, Key Vault isteklerinde bulunur.
  Event Hubs	Event Hubs'a erişim engellendiğinde, CatalogService ve HealthService tarafından gönderilen yeni iletiler başarısız olur. İletilerin BackgroundProcess tarafından alınması yavaş yavaş başarısız olur ve birkaç dakika içinde toplam hata olur.
  Azure Cosmos DB	Sanal ağ için mevcut güvenlik duvarı ilkesinin kaldırılması, Sistem Sağlığı Hizmeti'nin en düşük gecikmeyle başarısız olmasına neden olur. Bu yordam yalnızca belirli bir durumun benzetimini, tüm Azure Cosmos DB kesintisini gösterir. Bölgesel düzeyde oluşan hata durumlarının çoğu, istemcinin farklı bir Azure Cosmos DB bölgesine saydam yük devretmesi ile otomatik olarak azaltılmalıdır. Daha önce açıklanan DNS tabanlı hata ekleme testi, Azure Cosmos DB için daha anlamlı bir testtir.
  Kapsayıcı kayıt defteri (ACR)	ACR'ye erişim engellendiğinde, daha önce AKS düğümünde çekilen ve önbelleğe alınan yeni podların oluşturulması çalışmaya devam eder. Oluşturma işlemi k8s dağıtım bayrağı pullPolicy=IfNotPresentnedeniyle çalışmaya devam eder. Blok öncesinde görüntü çekip önbelleğe almamış düğümler yeni bir pod oluşturamaz ve hatalarla ErrImagePull hemen başarısız olur. kubectl describe pod ilgili 403 Forbidden iletiyi görüntüler.
  AKS giriş Load Balancer	AKS tarafından yönetilen Ağ Güvenlik Grubu'ndaki (NSG) HTTP(S) (bağlantı noktaları 80 ve 443 bağlantı noktaları) için gelen kuralların kullanıcı veya sistem durumu yoklaması trafiğinin kümeye ulaşmamasına neden olan sonuçları reddedecek şekilde değiştirilmesi. Bu hatanın testini, Front Door'un ağ yolu ile bölgesel damga arasında tıkanıklık olarak benzetilen kök nedeni saptamak zordur. Front Door bu hatayı hemen algılar ve damgayı döndürmeden çıkarır.