Distribuzione e test per carichi di lavoro cruciali in Azure

La distribuzione e il test dell'ambiente mission critical sono un elemento fondamentale dell'architettura di riferimento generale. I singoli indicatori dell'applicazione vengono distribuiti usando l'infrastruttura come codice da un repository di codice sorgente. Aggiornamenti all'infrastruttura e l'applicazione deve essere distribuita senza tempi di inattività all'applicazione. È consigliabile usare una pipeline di integrazione continua DevOps per recuperare il codice sorgente dal repository e distribuire i singoli timbri in Azure.

La distribuzione e gli aggiornamenti sono il processo centrale nell'architettura. Gli aggiornamenti correlati all'infrastruttura e alle applicazioni devono essere distribuiti in stamp completamente indipendenti. Solo i componenti dell'infrastruttura globale nell'architettura vengono condivisi tra i francobolli. I francobolli esistenti nell'infrastruttura non vengono toccati. Gli aggiornamenti dell'infrastruttura verranno distribuiti solo in questi nuovi timbri. Analogamente, la nuova versione dell'applicazione verrà distribuita solo in questi nuovi stamp.

I nuovi timbri vengono aggiunti a Frontdoor di Azure. Il traffico viene gradualmente spostato verso i nuovi timbri. Quando viene determinato che il traffico viene servito dai nuovi francobolli senza problemi, i francobolli precedenti vengono eliminati.

I test di penetrazione, caos e stress sono consigliati per l'ambiente distribuito. Il test proattivo dell'infrastruttura individua i punti deboli e il comportamento dell'applicazione distribuita in caso di errore.

Distribuzione

La distribuzione dell'infrastruttura nell'architettura di riferimento dipende dai processi e dai componenti seguenti:

• DevOps : il codice sorgente di GitHub e le pipeline per l'infrastruttura.

• Aggiornamenti senza tempi di inattività: Aggiornamenti e gli aggiornamenti vengono distribuiti nell'ambiente senza tempi di inattività per l'applicazione distribuita.

• Ambienti : ambienti permanenti e di breve durata usati per l'architettura.

• Risorse condivise e dedicate : risorse di Azure dedicate e condivise ai francobolli e all'infrastruttura complessiva.

Per altre informazioni, vedere Distribuzione e test per carichi di lavoro cruciali in Azure: Considerazioni sulla progettazione

Distribuzione: DevOps

I componenti DevOps forniscono il repository del codice sorgente e le pipeline CI/CD per la distribuzione dell'infrastruttura e degli aggiornamenti. GitHub e Azure Pipelines sono stati scelti come componenti.

• GitHub : contiene i repository di codice sorgente per l'applicazione e l'infrastruttura.

• Azure Pipelines : pipeline usate dall'architettura per tutte le attività di compilazione, test e rilascio.

Un componente aggiuntivo nella progettazione usata per la distribuzione è costituito dagli agenti di compilazione. Gli agenti di compilazione ospitati da Microsoft vengono usati come parte di Azure Pipelines per distribuire l'infrastruttura e gli aggiornamenti. L'uso degli agenti di compilazione ospitati da Microsoft consente agli sviluppatori di gestire e aggiornare l'agente di compilazione.

Per altre informazioni su Azure Pipelines, vedere Che cos'è Azure DevOps Services?.

Per altre informazioni, vedere Distribuzione e test per carichi di lavoro cruciali in Azure: Distribuzioni di infrastruttura come codice

Distribuzione: aggiornamenti senza tempi di inattività

La strategia di aggiornamento senza tempi di inattività nell'architettura di riferimento è fondamentale per l'applicazione cruciale complessiva. La metodologia di sostituzione anziché l'aggiornamento dei francobolli garantisce una nuova installazione dell'applicazione in un timbro dell'infrastruttura. L'architettura di riferimento usa un approccio blu/verde e consente ambienti di test e sviluppo separati.

Esistono due componenti principali dell'architettura di riferimento:

• Infrastruttura : servizi e risorse di Azure. Distribuito con Terraform e la configurazione associata.

• Applicazione : servizio ospitato o applicazione che serve gli utenti. Basato su contenitori Docker e npm creati artefatti in HTML e JavaScript per l'interfaccia utente dell'applicazione a pagina singola.

In molti sistemi si presuppone che gli aggiornamenti delle applicazioni siano più frequenti rispetto agli aggiornamenti dell'infrastruttura. Di conseguenza, vengono sviluppate diverse procedure di aggiornamento per ognuna. Con un'infrastruttura cloud pubblica, le modifiche possono verificarsi a un ritmo più rapido. È stato scelto un processo di distribuzione per gli aggiornamenti dell'applicazione e gli aggiornamenti dell'infrastruttura. Un approccio garantisce che gli aggiornamenti dell'infrastruttura e delle applicazioni siano sempre sincronizzati. Questo approccio consente di:

• Un processo coerente : un minor numero di probabilità di errori se gli aggiornamenti dell'infrastruttura e delle applicazioni vengono combinati in una versione, intenzionalmente o meno.

• Abilita la distribuzione blu/verde : ogni aggiornamento viene distribuito usando una migrazione graduale del traffico alla nuova versione.

• Distribuzione e debug più semplici dell'applicazione : l'intero stamp non ospiterà mai più versioni dell'applicazione affiancate.

• Rollback semplice : il traffico può essere restituito ai timbri che eseguono la versione precedente in caso di errori o problemi.

• Eliminazione delle modifiche manuali e della deriva della configurazione : ogni ambiente è una nuova distribuzione.

Per altre informazioni, vedere Distribuzione e test per carichi di lavoro cruciali in Azure: Distribuzioni temporanee blu/verde

Strategia di diramazione

La base della strategia di aggiornamento è l'uso dei rami all'interno del repository Git. L'architettura di riferimento usa tre tipi di rami:

Ramo	Descrizione
feature/* e fix/*	Punti di ingresso per qualsiasi modifica. Questi rami vengono creati dagli sviluppatori e devono essere assegnati un nome descrittivo, ad esempio feature/catalog-update o fix/worker-timeout-bug. Quando le modifiche sono pronte per essere unite, viene creata una richiesta pull nel main ramo . Ogni richiesta pull deve essere approvata da almeno un revisore. Con eccezioni limitate, ogni modifica proposta in una richiesta pull deve essere eseguita tramite la pipeline di convalida end-to-end (E2E). La pipeline E2E deve essere usata dagli sviluppatori per testare ed eseguire il debug delle modifiche in un ambiente completo.
main	Ramo in continua evoluzione e stabile. Usato principalmente per i test di integrazione. Le modifiche apportate vengono apportate main solo tramite richieste pull. Un criterio di ramo impedisce le scritture dirette. Le versioni notturne sull'ambiente permanente integration (int) vengono eseguite automaticamente dal main ramo . Il main ramo è considerato stabile. È consigliabile presupporre che in qualsiasi momento sia possibile creare una versione.
release/*	I rami di versione vengono creati solo dal main ramo . I rami seguono il formato release/2021.7.X. I criteri di ramo vengono usati in modo che solo gli amministratori del repository siano autorizzati a creare release/* rami. Solo questi rami vengono usati per la distribuzione nell'ambiente prod .

Per altre informazioni, vedere Distribuzione e test per carichi di lavoro cruciali in Azure: Strategia di diramazione

Hotfix

Quando è necessario un hotfix urgente a causa di un bug o di un altro problema e non può eseguire il processo di rilascio regolare, è disponibile un percorso hotfix. Gli aggiornamenti critici della sicurezza e le correzioni all'esperienza utente che non sono stati individuati durante i test iniziali sono considerati esempi validi di hotfix.

L'hotfix deve essere creato in un nuovo fix ramo e quindi unito in main usando una richiesta pull regolare. Invece di creare un nuovo ramo di versione, l'hotfix viene "selezionato" in un ramo di versione esistente. Questo ramo è già distribuito nell'ambiente prod . La pipeline CI/CD che ha originariamente distribuito il ramo di versione con tutti i test viene eseguita nuovamente e ora distribuirà l'hotfix come parte della pipeline.

Per evitare problemi principali, è importante che l'hotfix contenga alcuni commit isolati che possono essere facilmente prelevati e integrati nel ramo di rilascio. Se i commit isolati non possono essere scelti per l'integrazione nel ramo di versione, è un'indicazione che la modifica non è idonea come hotfix. La modifica deve essere distribuita come nuova versione completa e potenzialmente combinata con un rollback a una versione stabile precedente fino a quando non è possibile distribuire la nuova versione.

Distribuzione: ambienti

L'architettura di riferimento usa due tipi di ambienti per l'infrastruttura:

• Breve durata : la pipeline di convalida E2E viene usata per distribuire ambienti di breve durata. Gli ambienti di breve durata vengono usati per gli ambienti di convalida o debug puri per gli sviluppatori. Gli ambienti di convalida possono essere creati dal feature/* ramo, sottoposti a test e quindi eliminati se tutti i test hanno avuto esito positivo. Gli ambienti di debug vengono distribuiti nello stesso modo della convalida, ma non vengono eliminati immediatamente. Questi ambienti non devono esistere per più di qualche giorno e devono essere eliminati quando viene unita la richiesta pull corrispondente del ramo di funzionalità.

• Permanente: negli ambienti permanenti sono integration (int) disponibili versioni e production (prod) . Questi ambienti vivono continuamente e non vengono distrutti. Gli ambienti usano nomi di dominio fissi come int.mission-critical.app. In un'implementazione reale dell'architettura di riferimento, deve essere aggiunto un staging ambiente (pre-prod). L'ambiente staging viene usato per distribuire e convalidare release i rami con lo stesso processo prod di aggiornamento (distribuzione blu/verde).

  • Integrazione (int): la int versione viene distribuita in notte dal main ramo con lo stesso processo di prod. Il passaggio del traffico è più veloce rispetto all'unità di rilascio precedente. Invece di passare gradualmente il traffico in più giorni, come in prod, il processo per int il completamento entro pochi minuti o ore. Questo passaggio più veloce garantisce che l'ambiente aggiornato sia pronto al mattino successivo. I vecchi francobolli vengono eliminati automaticamente se tutti i test nella pipeline hanno esito positivo.

  • Produzione (prod) - La prod versione viene distribuita solo dai release/* rami. Il passaggio del traffico usa passaggi più granulari. Un gate di approvazione manuale è compreso tra ogni passaggio. Ogni versione crea nuovi francobolli a livello di area e distribuisce la nuova versione dell'applicazione nei stamp. I francobolli esistenti non vengono toccati nel processo. La considerazione più importante per prod è che deve essere "sempre attiva". Nessun tempo di inattività pianificato o non pianificato dovrebbe mai verificarsi. L'unica eccezione è le modifiche fondamentali al livello di database. Potrebbe essere necessaria una finestra di manutenzione pianificata.

Distribuzione: risorse condivise e dedicate

Gli ambienti permanenti (int e prod) all'interno dell'architettura di riferimento hanno diversi tipi di risorse a seconda che siano condivisi con l'intera infrastruttura o dedicati a un singolo timbro. Le risorse possono essere dedicate a una versione specifica ed esistono solo fino a quando l'unità di rilascio successiva non è stata ripresa.

Unità di rilascio

Un'unità di rilascio è diversi francobolli regionali per versione specifica. I francobolli contengono tutte le risorse che non sono condivise con gli altri francobolli. Queste risorse sono reti virtuali, cluster servizio Azure Kubernetes, Hub eventi e Azure Key Vault. Azure Cosmos DB e ACR sono configurati con origini dati Terraform.

Risorse condivise a livello globale

Tutte le risorse condivise tra le unità di rilascio sono definite in un modello Terraform indipendente. Queste risorse sono Frontdoor, Azure Cosmos DB, Registro Contenitori e aree di lavoro Log Analytics e altre risorse correlate al monitoraggio. Queste risorse vengono distribuite prima della distribuzione del primo timbro regionale di un'unità di rilascio. Le risorse vengono a cui si fa riferimento nei modelli Terraform per i francobolli.

Frontdoor

Anche se Frontdoor è una risorsa condivisa a livello globale tra i francobolli, la sua configurazione è leggermente diversa rispetto alle altre risorse globali. Frontdoor deve essere riconfigurato dopo la distribuzione di un nuovo timbro. Frontdoor deve essere riconfigurato per passare gradualmente al traffico ai nuovi francobolli.

La configurazione back-end di Frontdoor non può essere definita direttamente nel modello Terraform. La configurazione viene inserita con le variabili Terraform. I valori delle variabili vengono costruiti prima dell'avvio della distribuzione terraform.

La configurazione dei singoli componenti per la distribuzione frontdoor è definita come:

• Front-end : l'affinità di sessione è configurata per garantire che gli utenti non cambino tra versioni diverse dell'interfaccia utente durante una singola sessione.

• Origini - Frontdoor è configurato con due tipi di gruppi di origine:

  1. Gruppo di origine per l'archiviazione statica che gestisce l'interfaccia utente. Il gruppo contiene gli account di archiviazione del sito Web da tutte le unità di rilascio attualmente attive. È possibile assegnare pesi diversi alle origini da diverse unità di rilascio per spostare gradualmente il traffico in un'unità più recente. Ogni origine da un'unità di rilascio deve avere lo stesso peso assegnato.

  2. Un gruppo di origine per l'API, ospitato nel servizio Azure Kubernetes. Se sono presenti unità di rilascio con versioni API diverse, esiste un gruppo di origine API per ogni unità di versione. Se tutte le unità di versione offrono la stessa API compatibile, tutte le origini vengono aggiunte allo stesso gruppo e assegnate pesi diversi.

• Regole di routing: esistono due tipi di regole di routing:

  1. Regola di routing per l'interfaccia utente collegata al gruppo di origine dell'interfaccia utente.

  2. Regola di routing per ogni API attualmente supportata dalle origini. Ad esempio: /api/1.0/* e /api/2.0/*.

  Se una versione introduce una nuova versione delle API back-end, le modifiche rifletteranno nell'interfaccia utente distribuita come parte della versione. Una versione specifica dell'interfaccia utente chiamerà sempre una versione specifica dell'URL dell'API. Gli utenti gestiti da una versione dell'interfaccia utente useranno automaticamente l'API back-end corrispondente. Sono necessarie regole di routing specifiche per diverse istanze della versione dell'API. Queste regole sono collegate ai gruppi di origine corrispondenti. Se non è stata introdotta una nuova API, tutte le regole di routing correlate alle API vengono collegate al gruppo di origine singolo. In questo caso, non importa se un utente viene servito dall'interfaccia utente da una versione diversa rispetto all'API.

Distribuzione: Processo di distribuzione

Una distribuzione blu/verde è l'obiettivo del processo di distribuzione. Una nuova versione di un release/* ramo viene distribuita nell'ambiente prod . Il traffico utente viene gradualmente spostato ai francobolli per la nuova versione.

Come primo passaggio nel processo di distribuzione di una nuova versione, l'infrastruttura per la nuova unità di rilascio viene distribuita con Terraform. L'esecuzione della pipeline di distribuzione dell'infrastruttura distribuisce la nuova infrastruttura da un ramo di versione selezionato. In parallelo al provisioning dell'infrastruttura, le immagini del contenitore vengono compilate o importate e sottoposte a push nel Registro contenitori condiviso globale. Al termine dei processi precedenti, l'applicazione viene distribuita nei stamp. Dal punto di vista dell'implementazione, è una pipeline con più fasi dipendenti. La stessa pipeline può essere eseguita nuovamente per le distribuzioni di hotfix.

Dopo aver distribuito e convalidato la nuova unità di rilascio, viene aggiunto a Frontdoor per ricevere il traffico utente.

È necessario pianificare un commutatore o un parametro che distingue tra le versioni che e non introducono una nuova versione dell'API. In base a se la versione introduce una nuova versione dell'API, è necessario creare un nuovo gruppo di origine con i back-end dell'API. In alternativa, è possibile aggiungere nuovi back-end API a un gruppo di origine esistente. I nuovi account di archiviazione dell'interfaccia utente vengono aggiunti al gruppo di origine esistente corrispondente. I pesi per le nuove origini devono essere impostati in base alla divisione del traffico desiderata. È necessario creare una nuova regola di routing come descritto in precedenza che corrisponde al gruppo di origine appropriato.

Come parte dell'aggiunta della nuova unità di rilascio, i pesi delle nuove origini devono essere impostati sul traffico minimo utente desiderato. Se non vengono rilevati problemi, la quantità di traffico utente deve essere aumentata al nuovo gruppo di origine in un periodo di tempo. Per modificare i parametri di peso, è necessario eseguire di nuovo gli stessi passaggi di distribuzione con i valori desiderati.

Riquadare l'unità di rilascio

Come parte della pipeline di distribuzione per un'unità di rilascio, è disponibile una fase di eliminazione che rimuove tutti i stamp una volta che un'unità di rilascio non è più necessaria. Tutto il traffico viene spostato in una nuova versione di versione. Questa fase include la rimozione dei riferimenti all'unità di rilascio da Frontdoor. Questa rimozione è fondamentale per abilitare la versione di una nuova versione in una data successiva. Frontdoor deve puntare a una singola unità di rilascio per essere preparata per la prossima versione in futuro.

Checklists

Nell'ambito della cadenza di rilascio, deve essere usato un elenco di controllo pre e post release. L'esempio seguente è costituito da elementi che devono trovarsi in qualsiasi elenco di controllo almeno.

• Elenco di controllo di pre-rilascio : prima di avviare una versione, controllare quanto segue:

  • Verificare che lo stato più recente del main ramo sia stato distribuito correttamente in e testato nell'ambiente int .

  • Aggiornare il file changelog tramite una richiesta richiesta di richiesta in base al main ramo.

  • Creare un release/ ramo dal main ramo.

• Elenco di controllo post-rilascio : prima che i vecchi francobolli vengano eliminati e i relativi riferimenti vengano rimossi da Frontdoor, verificare che:

  • I cluster non ricevono più traffico in ingresso.

  • Hub eventi e altre code di messaggi non contengono messaggi non elaborati.

Distribuzione: limitazioni e rischi della strategia di aggiornamento

La strategia di aggiornamento descritta in questa architettura di riferimento presenta alcune limitazioni e rischi che devono essere menzionati:

• Costo più elevato: quando si rilasciano aggiornamenti, molti dei componenti dell'infrastruttura sono attivi due volte per il periodo di rilascio.

• Complessità frontdoor: il processo di aggiornamento in Frontdoor è complesso da implementare e gestire. La possibilità di eseguire distribuzioni blu/verdi efficaci con tempi di inattività zero dipende dal corretto funzionamento.

• Piccole modifiche che richiedono tempo: il processo di aggiornamento comporta un processo di rilascio più lungo per piccole modifiche. Questa limitazione può essere parzialmente attenuata con il processo hotfix descritto nella sezione precedente.

Distribuzione: considerazioni sulla compatibilità dei dati dell'applicazione

La strategia di aggiornamento può supportare più versioni di un'API e componenti di lavoro che eseguono simultaneamente. Poiché Azure Cosmos DB è condiviso tra due o più versioni, è possibile che gli elementi di dati modificati da una versione non corrispondano sempre alla versione dell'API o dei lavoratori che lo usano. I livelli API e i lavoratori devono implementare la progettazione di compatibilità in avanti. Le versioni precedenti dell'API o dei componenti di lavoro elaborano i dati inseriti da una versione successiva del componente API o del ruolo di lavoro. Ignora le parti che non capisce.

Test

L'architettura di riferimento contiene test diversi usati in fasi diverse all'interno dell'implementazione del test.

Questi test includono:

• Unit test : questi test convalidano che la logica di business dell'applicazione funzioni come previsto. L'architettura di riferimento contiene una suite di unit test di esempio eseguita automaticamente prima di ogni compilazione di contenitori da Azure Pipelines. Se un test ha esito negativo, la pipeline si arresterà. La compilazione e la distribuzione non procederanno.

• Test di carico : questi test consentono di valutare la capacità, la scalabilità e i potenziali colli di bottiglia per un determinato carico di lavoro o stack. L'implementazione di riferimento contiene un generatore di carico utente per creare modelli di carico sintetici che possono essere usati per simulare il traffico reale. Il generatore di carico può essere usato anche indipendentemente dall'implementazione di riferimento.

• Test di fumo : questi test identificano se l'infrastruttura e il carico di lavoro sono disponibili e agiscono come previsto. I test di fumo vengono eseguiti come parte di ogni distribuzione.

• Test dell'interfaccia utente : questi test convalidano la distribuzione dell'interfaccia utente e funzionano come previsto. L'implementazione corrente acquisisce solo screenshot di diverse pagine dopo la distribuzione senza alcun test effettivo.

• Test di inserimento degli errori : questi test possono essere automatizzati o eseguiti manualmente. I test automatizzati nell'architettura integrano Azure Chaos Studio come parte delle pipeline di distribuzione.

Per altre informazioni, vedere Distribuzione e test per carichi di lavoro cruciali in Azure: convalida continua e test

Test: Framework

Implementazione di test e framework di riferimento online esistenti ogni volta che è possibile.

Framework	Test	Descrizione
NUnit	Unità	Questo framework viene usato per unit test della parte .NET Core dell'implementazione. Gli unit test vengono eseguiti automaticamente da Azure Pipelines prima delle compilazioni dei contenitori.
JMeter con Test di carico di Azure	Caricamento	Test di carico di Azure è un servizio gestito usato per eseguire definizioni di test di carico apache JMeter .
Locust	Caricamento	Locust è un framework di test del carico open source scritto in Python.
Playwright	Interfaccia utente e fumo	Playwright è una libreria open source Node.js per automatizzare Chromium, Firefox e WebKit con una singola API. La definizione di test playwright può essere usata anche indipendentemente dall'implementazione di riferimento.
Azure Chaos Studio	Inserimento di errori	L'implementazione di riferimento usa Azure Chaos Studio come passaggio facoltativo nella pipeline di convalida E2E per inserire errori per la convalida della resilienza.

Test: test di iniezione di errori e Progettazione di Chaos

Le applicazioni distribuite devono essere resilienti alle interruzioni del servizio e dei componenti. Il test di inserimento degli errori (noto anche come Fault Injection o Chaos Engineering) è la pratica di sottoporre applicazioni e servizi a stress e errori reali.

La resilienza è una proprietà di un intero sistema e l'inserimento di errori consente di trovare problemi nell'applicazione. Risolvere questi problemi consente di convalidare la resilienza dell'applicazione a condizioni non affidabili, dipendenze mancanti e altri errori.

I test manuali e automatici possono essere eseguiti sull'infrastruttura per individuare errori e problemi nell'implementazione.

Automatico

L'architettura di riferimento integra Azure Chaos Studio per distribuire ed eseguire un set di esperimenti di Azure Chaos Studio per inserire vari errori a livello di stamp. Gli esperimenti Chaos possono essere eseguiti come parte facoltativa della pipeline di distribuzione E2E. Quando vengono eseguiti i test, il test di carico facoltativo viene sempre eseguito in parallelo. Il test di carico viene usato per creare il carico nel cluster per convalidare l'effetto degli errori inseriti.

Manuale

I test di inserimento manuale degli errori devono essere eseguiti in un ambiente di convalida E2E. Questo ambiente garantisce test rappresentativi completi senza rischi di interferenza da altri ambienti. La maggior parte degli errori generati con i test può essere osservata direttamente nella visualizzazione metriche live di Application Insights. Gli errori rimanenti sono disponibili nella visualizzazione Errori e nelle tabelle di log corrispondenti. Altri errori richiedono il debug più approfondito, ad esempio l'uso di kubectl per osservare il comportamento all'interno del servizio Azure Kubernetes.

Due esempi di test di inserimento degli errori eseguiti sull'architettura di riferimento sono:

• Inserimento di errori basato su DNS : un test case che può simulare più problemi. Errori di risoluzione DNS a causa dell'errore di un server DNS o di DNS di Azure. I test basati su DNS consentono di simulare problemi di connessioni generali tra un client e un servizio, ad esempio quando backgroundProcessor non può connettersi a Hub eventi.

  Negli scenari a host singolo è possibile modificare il file locale hosts per sovrascrivere la risoluzione DNS. In un ambiente più grande con più server dinamici come il servizio Azure Kubernetes, un hosts file non è fattibile. Le zone DNS privato di Azure possono essere usate come alternativa agli scenari di errore di test.

  Hub eventi di Azure e Azure Cosmos DB sono due dei servizi di Azure usati all'interno dell'implementazione di riferimento che possono essere usati per inserire errori basati su DNS. La risoluzione DNS di Hub eventi può essere modificata con una zona di DNS privato di Azure collegata alla rete virtuale di uno dei stamp. Azure Cosmos DB è un servizio replicato a livello globale con endpoint di area specifici. La manipolazione dei record DNS per tali endpoint può simulare un errore per un'area specifica e testare il failover dei client.

• Blocco del firewall : la maggior parte dei servizi di Azure supporta le restrizioni di accesso del firewall in base alle reti virtuali e/o ai relativi indirizzi IP. Nell'infrastruttura di riferimento queste restrizioni vengono usate per limitare l'accesso ad Azure Cosmos DB o a Hub eventi. Una semplice procedura consiste nel rimuovere le regole Consenti esistenti o aggiungere nuove regole di blocco . Questa procedura può simulare errori di configurazione del firewall o interruzioni del servizio.

  I servizi di esempio seguenti nell'implementazione di riferimento possono essere testati con un test del firewall:

  Servizio	Risultato
  Insieme di credenziali di chiave	Quando l'accesso a Key Vault è bloccato, l'effetto più diretto è stato l'errore di nuovi pod per generare la spawn. Il driver Key Vault CSI che recupera i segreti nell'avvio del pod non può eseguire le attività e impedisce l'avvio del pod. I messaggi di errore corrispondenti possono essere osservati con kubectl describe po CatalogService-deploy-my-new-pod -n workload. I pod esistenti continueranno a funzionare, anche se verrà osservato lo stesso messaggio di errore. Il messaggio di errore viene generato dai risultati del controllo periodico dell'aggiornamento per i segreti. Sebbene non verificato, si presuppone che l'esecuzione di una distribuzione non funzioni mentre Key Vault è inaccessibile. Le attività dell'interfaccia della riga di comando di Terraform e dell'interfaccia della riga di comando di Azure all'interno dell'esecuzione della pipeline eseguono richieste di Key Vault.
  Hub eventi	Quando l'accesso a Hub eventi viene bloccato, i nuovi messaggi inviati da CatalogService e HealthService avranno esito negativo. Il recupero dei messaggi da BackgroundProcess avrà esito negativo lentamente, con un errore totale entro pochi minuti.
  Azure Cosmos DB	La rimozione dei criteri del firewall esistenti per una rete virtuale comporta l'esito negativo del servizio integrità con un ritardo minimo. Questa procedura simula solo un caso specifico, un'intera interruzione di Azure Cosmos DB. La maggior parte dei casi di errore che si verificano a livello di area deve essere attenuata automaticamente dal failover trasparente del client in un'area di Azure Cosmos DB diversa. I test di inserimento degli errori basati su DNS descritti in precedenza sono un test più significativo per Azure Cosmos DB.
  Registro contenitori (ACR)	Quando l'accesso al Registro Azure Kubernetes viene bloccato, la creazione di nuovi pod che sono stati estratti e memorizzati nella cache in precedenza in un nodo del servizio Azure Kubernetes continueranno a funzionare. La creazione funziona ancora a causa del flag pullPolicy=IfNotPresentdi distribuzione k8s . Nodi che non hanno eseguito il pull e memorizzato nella cache di un'immagine prima che il blocco non possa generare un nuovo pod e non riesce immediatamente con ErrImagePull errori. kubectl describe pod visualizza il messaggio corrispondente 403 Forbidden .
  Load Balancer in ingresso del servizio Azure Kubernetes	Modifica delle regole in ingresso per HTTP(S)(porte 80 e 443) nel gruppo di sicurezza di rete gestito del servizio Azure Kubernetes (NSG) per negare i risultati nel traffico del probe di integrità o utente non riesce a raggiungere il cluster. Il test di questo errore è difficile per individuare la causa radice, simulata come blocco tra il percorso di rete di Frontdoor e un timbro regionale. Frontdoor rileva immediatamente questo errore e rimuove il stampo dalla rotazione.