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 en üstteki uygulama, uygulamaya sıfır kapalı kalma süresiyle dağıtılmalıdır. Kaynak kodu depodan almak ve tek tek damgaları Azure'a dağıtmak için DevOps sürekli tümleştirme işlem hattı önerilir.

Dağıtım ve güncelleştirmeler mimarinin merkezi sürecidir. Altyapı ve uygulamayla ilgili güncelleştirmeler tamamen bağımsız damgalara 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 damgalarına dağıtılır. Benzer şekilde, yeni uygulama sürümü yalnızca bu yeni damga pullarına dağıtılır.

Yeni pullar Azure Front Door'a eklenir. Trafik yavaş yavaş yeni damga pullarına taşınır. Trafiğin yeni damga pullarından sorunsuz bir şekilde 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 gelen kaynak kodu ve altyapının işlem hatları.

• Sıfır kapalı kalma süresi güncelleştirmeleri - 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 damgaları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çilmiştir.

• GitHub - Uygulama ve altyapı için kaynak kod 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 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ştirmeleri

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

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. Docker kapsayıcılarına ve tek sayfalı uygulama (SPA) kullanıcı arabirimi için HTML ve JavaScript'te npm yerleşik yapıtlarına dayalıdır.

Birçok sistemde, uygulama güncelleştirmelerinin altyapı güncelleştirmelerinden daha sık olacağı varsayımı vardır. Sonuç olarak, her bir için farklı güncelleştirme yordamları geliştirilir. Genel bulut altyapısıyla değişiklikler daha hızlı bir şekilde gerçekleşebilir. 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ştirmeleri bir sürümde kasıtlı olarak veya değil birlikte karıştırılırsa 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 kayması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:

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 acilen bir düzeltme gerektiğinde 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 ardından 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ının "kirazla seçilmiş" halidir. 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 artık 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 nitelemediğinin 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 birkaç günden uzun süre mevcut olmamalıdır ve özellik dalının ilgili çekme isteği birleştirildiğinde silinmelidir.

• Kalıcı - Kalıcı ortamlarda ve production (prod) sürümleri vardırintegration (int). Bu ortamlar sürekli olarak yaşar ve yok edilmez. Ortamlar gibi int.mission-critical.appsabit etki alanı adları kullanır. Başvuru mimarisinin gerçek bir uygulamasında bir staging (önceden üretim öncesi) 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) - int Sürüm, ile aynı işlemle proddaldan main her gece dağıtılır. Trafiğin geçişi önceki sürüm ünitesinden daha hızlıdır. uygulamasında 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 pullara dokunulmaz. Için en önemli nokta prod bunun "her zaman açık" olması gerektiğidir. 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ın (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ı kaynak türleri vardır. Kaynaklar belirli bir sürüme ayrılmış olabilir ve yalnızca bir sonraki sürüm birimi devralana kadar kullanılabilir.

Sürüm birimleri

Yayın birimi, belirli bir sürüme göre birkaç bölgesel damgadır. Damga pulları, diğer damgalarla paylaşılmamış tüm kaynakları içerir. Bu kaynaklar sanal ağlar, Azure Kubernetes Service kümesi, Event Hubs ve Azure Key Vault'tur. 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. Yeni bir damga dağıtıldıktan sonra Front Door yeniden yapılandırılmalıdır. Front Door, trafiği yeni damgalara aşamalı olarak geçirmek 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 tek 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.

• Origins - 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 sürüm birimi için bir API çıkış 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 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 çıkış noktası grubuna bağlanır. Bu durumda, kullanıcı arabirimine API'den farklı bir sürümden hizmet alınıp alınmadığının bir önemi yoktur.

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

Mavi/yeşil dağıtım, dağıtım işleminin hedefidir. Bir dalın yeni sürümü release/* ortama dağıtılır prod . Kullanıcı trafiği, yeni sürümün damga pulları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ğlama işlemine 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 birbirinden ayıran bir anahtar/parametre planlanmalıdır. Yayının yeni bir API sürümü sunup sunmadığı temelinde, API arka uçlarına sahip yeni bir kaynak 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 boyunca yeni çıkış noktası 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 birimi için dağıtım işlem hattının bir parçası olarak, bir yayın birimine ihtiyaç kalmadıkça 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'dan kaldırılmasını içerir. Bu kaldırma işlemi, yeni bir sürümün daha sonraki bir tarihte yayımlanmasını sağlamak için kritik öneme sahiptir. Gelecekte bir sonraki sürüme hazırlıklı olmak için Front Door'un tek bir sürüm birimine işaret etmesi gerekir.

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 referansları 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 stratejisinde belirtilmesi gereken bazı sınırlamalar ve riskler 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ışması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 işlemine neden olur. Bu sınırlama, önceki bölümde açıklanan düzeltme işlemiyle kısmen azaltılabilir.

Dağıtım: Uygulama verileri 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ı içinde farklı aşamalarda 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 her kapsayıcı derlemesi öncesinde otomatik olarak yürütülen örnek birim testleri paketini içerir. Herhangi bir test başarısız olursa işlem hattı durur. Derleme ve dağıtım devam etmez.

• Yük testleri - Bu testler belirli bir iş yükü veya yığın için kapasite, ölçeklenebilirlik 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 otomatik test, dağıtım işlem hatlarının bir parçası olarak Azure Chaos Studio'yu 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ğunca mevcut test özellikleri ve çerçeveleridir.

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

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

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

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

Otomatik

Başvuru mimarisi, damga pulu 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ülü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 için 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 Uygulama Analizler 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 derin 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 simülasyonunu oluşturabilen bir test çalışması. DNS sunucusunun veya Azure DNS'nin başarısız olması nedeniyle DNS çözümleme hataları. DNS tabanlı test, örneğin BackgroundProcessor Event Hubs'a bağlanamıyorsa istemci ile 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 işlenebilir. Azure Cosmos DB, belirli bölgesel uç noktalara sahip genel olarak çoğaltılmış bir hizmettir. Bu uç noktaların 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 göre 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'a erişim 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. buna karşılık gelen hata iletileri ile kubectl describe po CatalogService-deploy-my-new-pod -n workloadgözlemlenebilir. Var olan podlar çalışmaya devam eder, ancak aynı hata iletisi gözlemlenir. Hata iletisi, gizli diziler için düzenli güncelleştirme denetiminin sonuçlarıyla oluşturulur. Test edilmemiş olsa da, 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'a istekte 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ş 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 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 gerçekleşen hata durumlarının çoğu, istemcinin farklı bir Azure Cosmos DB bölgesine saydam yük devretmesi yoluyla 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 erişimi engellendiğinde, daha önce AKS düğümünde çekilen ve önbelleğe alınan yeni podlar oluşturulmaya 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ş Yük Dengeleyicisi	AKS tarafından yönetilen Ağ Güvenlik Grubu'ndaki (NSG) HTTP(S)(bağlantı noktaları 80 ve 443) için gelen kuralların Reddetme olarak değiştirilmesi, kullanıcı veya sistem durumu yoklaması trafiğinin kümeye ulaşamamasına neden olur. Bu hatanın testini, Front Door'un ağ yolu ile bölgesel bir 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.