Partilhar via

Implantação e teste para cargas de trabalho de missão crítica no Azure

  • Artigo

A implantação e o teste do ambiente de missão crítica são uma peça crucial da arquitetura de referência geral. Os carimbos de aplicativo individuais são implantados usando a infraestrutura como código de um repositório de código-fonte. As atualizações da infraestrutura e do aplicativo no topo devem ser implantadas sem tempo de inatividade para o aplicativo. Um pipeline de integração contínua de DevOps é recomendado para recuperar o código-fonte do repositório e implantar os carimbos individuais no Azure.

A implantação e as atualizações são o processo central na arquitetura. As atualizações relacionadas à infraestrutura e aos aplicativos devem ser implantadas em selos totalmente independentes. Somente os componentes de infraestrutura global na arquitetura são compartilhados entre os selos. Os carimbos existentes na infraestrutura não são tocados. As atualizações de infraestrutura só serão implantadas nesses novos selos. Da mesma forma, a nova versão do aplicativo só será implantada nesses novos selos.

Os novos carimbos são adicionados ao Azure Front Door. O tráfego é gradualmente transferido para os novos selos. Quando é determinado que o tráfego é servido a partir dos novos selos sem emissão, os carimbos anteriores são excluídos.

Testes de penetração, caos e estresse são recomendados para o ambiente implantado. O teste proativo da infraestrutura deteta pontos fracos e como o aplicativo implantado se comportará se houver uma falha.

Implementação

A implantação da infraestrutura na arquitetura de referência depende dos seguintes processos e componentes:

  • DevOps - O código-fonte do GitHub e pipelines para a infraestrutura.

  • Zero atualizações de tempo de inatividade - As atualizações e upgrades são implantados no ambiente com zero tempo de inatividade para o aplicativo implantado.

  • Ambientes - Ambientes de curta duração e permanentes utilizados para a arquitetura.

  • Recursos compartilhados e dedicados - recursos do Azure que são dedicados e compartilhados para os selos e a infraestrutura geral.

Diagrama de fluxograma do processo de implantação.

Para obter mais informações, consulte Implantação e teste para cargas de trabalho de missão crítica no Azure: considerações de design

Implantação: DevOps

Os componentes de DevOps fornecem o repositório de código-fonte e pipelines de CI/CD para implantação da infraestrutura e atualizações. O GitHub e o Azure Pipelines foram escolhidos como componentes.

  • GitHub - Contém os repositórios de código-fonte para o aplicativo e a infraestrutura.

  • Azure Pipelines - Os pipelines usados pela arquitetura para todas as tarefas de compilação, teste e lançamento.

Um componente extra no design usado para a implantação são os agentes de compilação. Os agentes de compilação hospedados pela Microsoft são usados como parte dos Pipelines do Azure para implantar a infraestrutura e as atualizações. O uso de agentes de compilação hospedados pela Microsoft remove a carga de gerenciamento para os desenvolvedores manterem e atualizarem o agente de compilação.

Para obter mais informações sobre o Azure Pipelines, consulte O que são os Serviços de DevOps do Azure?.

Diagrama de fluxograma do pipeline de DevOps.

Para obter mais informações, consulte Implantação e teste para cargas de trabalho de missão crítica no Azure: implantações de infraestrutura como código

Implantação: zero atualizações de tempo de inatividade

A estratégia de atualização sem tempo de inatividade na arquitetura de referência é fundamental para o aplicativo de missão crítica geral. A metodologia de substituição em vez de atualização dos selos garante uma nova instalação do aplicativo em um selo de infraestrutura. A arquitetura de referência utiliza uma abordagem azul/verde e permite ambientes de teste e desenvolvimento separados.

Existem dois componentes principais da arquitetura de referência:

  • Infraestrutura - Serviços e recursos do Azure. Implantado com Terraform e sua configuração associada.

  • Aplicativo - O serviço hospedado ou aplicativo que atende aos usuários. Com base em contêineres do Docker e npm construiu artefatos em HTML e JavaScript para a interface do usuário do aplicativo de página única (SPA).

Em muitos sistemas, há uma suposição de que as atualizações de aplicativos serão mais frequentes do que as atualizações de infraestrutura. Como resultado, diferentes procedimentos de atualização são desenvolvidos para cada um. Com uma infraestrutura de nuvem pública, as mudanças podem acontecer em um ritmo mais rápido. Foi escolhido um processo de implantação para atualizações de aplicativos e atualizações de infraestrutura. Uma abordagem garante que as atualizações de infraestrutura e aplicativos estejam sempre sincronizadas. Esta abordagem permite:

  • Um processo consistente - Menos chances de erros se as atualizações de infraestrutura e aplicativo forem misturadas em uma versão, intencionalmente ou não.

  • Permite a implantação Azul/Verde - Cada atualização é implantada usando uma migração gradual de tráfego para a nova versão.

  • Implantação e depuração mais fáceis do aplicativo - O carimbo inteiro nunca hospedará várias versões do aplicativo lado a lado.

  • Reversão simples - O tráfego pode ser alternado de volta para os carimbos que executam a versão anterior se forem encontrados erros ou problemas.

  • Eliminação de alterações manuais e desvios de configuração - Cada ambiente é uma nova implantação.

Para obter mais informações, consulte Implantação e teste para cargas de trabalho de missão crítica no Azure: implantações azuis/verdes efêmeras

Estratégia de ramificação

A base da estratégia de atualização é o uso de ramificações dentro do repositório Git. A arquitetura de referência usa três tipos de ramificações:

Filial Description
feature/* e fix/* Os pontos de entrada para qualquer alteração. Essas ramificações são criadas por desenvolvedores e devem receber um nome descritivo, como feature/catalog-update ou fix/worker-timeout-bug. Quando as alterações estiverem prontas para serem mescladas, uma solicitação pull (PR) contra a main ramificação será criada. Cada RP deve ser aprovado por pelo menos um avaliador. Com exceções limitadas, todas as alterações propostas em um RP devem passar pelo pipeline de validação de ponta a ponta (E2E). O pipeline E2E deve ser usado por desenvolvedores para testar e depurar alterações em um ambiente completo.
main O ramo continuamente em movimento e estável. Usado principalmente para testes de integração. As alterações são main feitas somente por meio de solicitações pull. Uma política de ramificação proíbe gravações diretas. As liberações noturnas contra o ambiente permanente integration (int) são executadas automaticamente a partir da main filial. O main ramo é considerado estável. Deve ser seguro assumir que, a qualquer momento, uma liberação pode ser criada a partir dele.
release/* As ramificações de liberação são criadas apenas a partir da main ramificação. As filiais seguem o formato release/2021.7.X. As políticas de ramificação são usadas para que apenas os administradores de repositório tenham permissão para criar release/* ramificações. Somente essas ramificações são usadas para implantar no prod ambiente.

Para obter mais informações, consulte Implantação e teste para cargas de trabalho de missão crítica no Azure: estratégia de ramificação

Correções

Quando um hotfix é necessário com urgência devido a um bug ou outro problema e não pode passar pelo processo de lançamento regular, um caminho de hotfix está disponível. Atualizações de segurança críticas e correções para a experiência do usuário que não foram descobertas durante o teste inicial são consideradas exemplos válidos de hotfixes.

O hotfix deve ser criado em uma nova fix ramificação e, em seguida, mesclado no main uso de um PR regular. Em vez de criar uma nova ramificação de versão, o hotfix é "escolhido a dedo" em uma ramificação de versão existente. Essa ramificação já está implantada no prod ambiente. O pipeline de CI/CD que originalmente implantou a ramificação de versão com todos os testes é executado novamente e agora implantará o hotfix como parte do pipeline.

Para evitar problemas maiores, é importante que o hotfix contenha algumas confirmações isoladas que podem ser facilmente escolhidas a dedo e integradas à ramificação de lançamento. Se confirmações isoladas não puderem ser escolhidas a dedo para integração na ramificação de versão, é uma indicação de que a alteração não se qualifica como um hotfix. A alteração deve ser implantada como uma nova versão completa e potencialmente combinada com uma reversão para uma versão estável anterior até que a nova versão possa ser implantada.

Implantação: Ambientes

A arquitetura de referência usa dois tipos de ambientes para a infraestrutura:

  • Curta duração - O pipeline de validação E2E é usado para implantar ambientes de curta duração. Ambientes de curta duração são usados para ambientes puros de validação ou depuração para desenvolvedores. Os ambientes de validação podem ser criados a feature/* partir da ramificação, submetidos a testes e, em seguida, destruídos se todos os testes forem bem-sucedidos. Os ambientes de depuração são implantados da mesma forma que a validação, mas não são destruídos imediatamente. Esses ambientes não devem existir por mais do que alguns dias e devem ser excluídos quando o PR correspondente da ramificação do recurso é mesclado.

  • Permanente - Nos ambientes permanentes existem integration (int) e production (prod) versões. Esses ambientes vivem continuamente e não são destruídos. Os ambientes usam nomes de domínio fixos como int.mission-critical.app. Em uma implementação do mundo real da arquitetura de referência, um staging ambiente (pré-prod) deve ser adicionado. O staging ambiente é usado para implantar e validar release ramificações com o mesmo processo de atualização que prod (implantação azul/verde).

    • Integração (int) - A int versão é implantada todas as noites a partir da main ramificação com o mesmo processo que prod. A transição de tráfego é mais rápida do que a unidade de lançamento anterior. Em vez de alternar gradualmente o tráfego ao longo de vários dias, como no prod, o processo para int é concluído dentro de alguns minutos ou horas. Essa transição mais rápida garante que o ambiente atualizado esteja pronto na manhã seguinte. Os carimbos antigos são excluídos automaticamente se todos os testes no pipeline forem bem-sucedidos.

    • Produção (prod) - A prod versão é implantada apenas a partir de release/* ramificações. A alternância de tráfego usa etapas mais granulares. Uma porta de aprovação manual está entre cada etapa. Cada versão cria novos selos regionais e implanta a nova versão do aplicativo nos selos. Os selos existentes não são tocados no processo. A consideração mais importante é prod que ele deve estar "sempre ligado". Nenhum tempo de inatividade planejado ou não planejado deve ocorrer. A única exceção são as alterações fundamentais na camada de banco de dados. Pode ser necessária uma janela de manutenção planeada.

Implantação: recursos compartilhados e dedicados

Os ambientes permanentes (int e prod) dentro da arquitetura de referência têm diferentes tipos de recursos, dependendo se eles são compartilhados com toda a infraestrutura ou dedicados a um carimbo individual. Os recursos podem ser dedicados a uma versão específica e existem apenas até que a próxima unidade de lançamento assuma o controle.

Unidades de liberação

Uma unidade de lançamento é composta por vários selos regionais por versão de lançamento específica. Os selos contêm todos os recursos que não são compartilhados com os outros selos. Esses recursos são redes virtuais, cluster do Serviço Kubernetes do Azure, Hubs de Eventos e Cofre de Chaves do Azure. O Azure Cosmos DB e o ACR são configurados com fontes de dados Terraform.

Recursos partilhados globalmente

Todos os recursos compartilhados entre as unidades de liberação são definidos em um modelo Terraform independente. Esses recursos são Front Door, Azure Cosmos DB, Registro de contêiner (ACR) e os espaços de trabalho do Log Analytics e outros recursos relacionados ao monitoramento. Esses recursos são implantados antes que o primeiro carimbo regional de uma unidade de liberação seja implantado. Os recursos são referenciados nos modelos Terraform para os selos.

Front Door

Embora o Front Door seja um recurso compartilhado globalmente entre selos, sua configuração é ligeiramente diferente dos outros recursos globais. A porta frontal deve ser reconfigurada após a implantação de um novo carimbo. A porta da frente deve ser reconfigurada para mudar gradualmente o tráfego para os novos selos.

A configuração de back-end do Front Door não pode ser definida diretamente no modelo Terraform. A configuração é inserida com variáveis Terraform. Os valores das variáveis são construídos antes do início da implantação do Terraform.

A configuração de componente individual para a implantação da Front Door é definida como:

  • Frontend - A afinidade de sessão é configurada para garantir que os usuários não alternem entre diferentes versões da interface do usuário durante uma única sessão.

  • Origens - A porta frontal é configurada com dois tipos de grupos de origem:

    1. Um grupo de origem para armazenamento estático que serve a interface do usuário. O grupo contém as contas de armazenamento do site de todas as unidades de lançamento ativas no momento. Diferentes pesos podem ser atribuídos às origens de diferentes unidades de liberação para mover gradualmente o tráfego para uma unidade mais nova. Cada origem de uma unidade de liberação deve ter o mesmo peso atribuído.

    2. Um grupo de origem para a API, que está hospedado no AKS. Se houver unidades de liberação com diferentes versões de API, então um grupo de origem de API existe para cada unidade de versão. Se todas as unidades de lançamento oferecerem a mesma API compatível, todas as origens serão adicionadas ao mesmo grupo e receberão pesos diferentes.

  • Regras de roteamento - Existem dois tipos de regras de roteamento:

    1. Uma regra de roteamento para a interface do usuário vinculada ao grupo de origem de armazenamento da interface do usuário.

    2. Uma regra de roteamento para cada API atualmente suportada pelas origens. Por exemplo: /api/1.0/* e /api/2.0/*.

    Se uma versão introduzir uma nova versão das APIs de back-end, as alterações refletirão na interface do usuário implantada como parte da versão. Uma versão específica da interface do usuário sempre chamará uma versão específica da URL da API. Os usuários atendidos por uma versão da interface do usuário usarão automaticamente a respetiva API de back-end. São necessárias regras de roteamento específicas para diferentes instâncias da versão da API. Estas regras estão ligadas aos grupos de origem correspondentes. Se uma nova API não for introduzida, todas as regras de roteamento relacionadas à API serão vinculadas ao grupo de origem único. Nesse caso, não importa se um usuário recebe a interface do usuário de uma versão diferente da API.

Implantação: processo de implantação

Uma implantação azul/verde é o objetivo do processo de implantação. Uma nova versão de uma release/* ramificação é implantada prod no ambiente. O tráfego de usuários é gradualmente deslocado para os selos da nova versão.

Como primeiro passo no processo de implantação de uma nova versão, a infraestrutura para a nova unidade de lançamento é implantada com o Terraform. A execução do pipeline de implantação de infraestrutura implanta a nova infraestrutura a partir de uma ramificação de versão selecionada. Em paralelo ao provisionamento de infraestrutura, as imagens de contêiner são criadas ou importadas e enviadas por push para o ACR (registro de contêiner globalmente compartilhado). Quando os processos anteriores são concluídos, o aplicativo é implantado nos selos. Do ponto de vista da implementação, é um pipeline com vários estágios dependentes. O mesmo pipeline pode ser reexecutado para implantações de hotfix.

Depois que a nova unidade de lançamento é implantada e validada, ela é adicionada ao Front Door para receber tráfego de usuários.

Um switch/parâmetro que distinga entre versões que introduzem e não introduzem uma nova versão da API deve ser planejado. Com base em se a versão introduzir uma nova versão da API, um novo grupo de origem com os back-ends da API deve ser criado. Como alternativa, novos back-ends de API podem ser adicionados a um grupo de origem existente. Novas contas de armazenamento da interface do usuário são adicionadas ao grupo de origem existente correspondente. Os pesos para novas origens devem ser definidos de acordo com a divisão de tráfego desejada. Uma nova regra de roteamento, conforme descrito acima, deve ser criada que corresponda ao grupo de origem apropriado.

Como parte da adição da nova unidade de lançamento, os pesos das novas origens devem ser definidos para o tráfego mínimo de usuário desejado. Se nenhum problema for detetado, a quantidade de tráfego de usuário deve ser aumentada para o novo grupo de origem durante um período de tempo. Para ajustar os parâmetros de peso, as mesmas etapas de implantação devem ser executadas novamente com os valores desejados.

Desmontagem da unidade de liberação

Como parte do pipeline de implantação de uma unidade de liberação, há um estágio de destruição que remove todos os carimbos quando uma unidade de liberação não é mais necessária. Todo o tráfego é movido para uma nova versão de lançamento. Esta etapa inclui a remoção das referências da unidade de liberação da Front Door. Essa remoção é fundamental para permitir o lançamento de uma nova versão em uma data posterior. Front Door deve apontar para uma única unidade de lançamento, a fim de estar preparado para a próxima versão no futuro.

Listas de verificação

Como parte da cadência de lançamento, uma lista de verificação pré e pós-lançamento deve ser usada. O exemplo a seguir é de itens que devem estar em qualquer lista de verificação, no mínimo.

  • Lista de verificação de pré-lançamento - Antes de iniciar uma versão, verifique o seguinte:

    • Certifique-se de que o estado mais recente da ramificação foi implantado main e testado com êxito no int ambiente.

    • Atualize o arquivo changelog por meio de um PR em relação à main ramificação.

    • Crie uma release/ ramificação a partir da main ramificação.

  • Lista de verificação pós-lançamento - Antes que os selos antigos sejam destruídos e suas referências sejam removidas da porta da frente, verifique se:

    • Os clusters não estão mais recebendo tráfego de entrada.

    • Os Hubs de Eventos e outras filas de mensagens não contêm mensagens não processadas.

Implantação: Limitações e riscos da estratégia de atualização

A estratégia de atualização descrita nesta arquitetura de referência tem algumas limitações e riscos que devem ser mencionados:

  • Custo mais alto - Ao lançar atualizações, muitos dos componentes de infraestrutura ficam ativos duas vezes durante o período de lançamento.

  • Complexidade da porta da frente - O processo de atualização na porta da frente é complexo de implementar e manter. A capacidade de executar implantações azuis/verdes eficazes com zero tempo de inatividade depende do funcionamento adequado.

  • Pequenas alterações demoradas - O processo de atualização resulta em um processo de liberação mais longo para pequenas alterações. Essa limitação pode ser parcialmente atenuada com o processo de hotfix descrito na seção anterior.

Implantação: considerações sobre compatibilidade de encaminhamento de dados de aplicativos

A estratégia de atualização pode suportar várias versões de uma API e componentes de trabalho executados simultaneamente. Como o Azure Cosmos DB é compartilhado entre duas ou mais versões, há uma possibilidade de que os elementos de dados alterados por uma versão nem sempre correspondam à versão da API ou aos trabalhadores que a consomem. As camadas de API e os trabalhadores devem implementar o design de compatibilidade direta. Versões anteriores da API ou componentes de trabalho processam dados que foram inseridos por uma API posterior ou uma versão do componente de trabalho. Ignora partes que não compreende.

Testar

A arquitetura de referência contém diferentes testes usados em diferentes estágios dentro da implementação de teste.

Estes testes incluem:

  • Testes de unidade - Esses testes validam se a lógica de negócios do aplicativo funciona conforme o esperado. A arquitetura de referência contém um conjunto de exemplos de testes de unidade executados automaticamente antes de cada compilação de contêiner pelo Azure Pipelines. Se algum teste falhar, o pipeline será interrompido. A compilação e a implantação não continuarão.

  • Testes de carga - Esses testes ajudam a avaliar a capacidade, a escalabilidade e os gargalos potenciais para uma determinada carga de trabalho ou pilha. A implementação de referência contém um gerador de carga do usuário para criar padrões de carga sintéticos que podem ser usados para simular o tráfego real. O gerador de carga também pode ser usado independentemente da implementação de referência.

  • Testes de fumaça - Esses testes identificam se a infraestrutura e a carga de trabalho estão disponíveis e agem conforme o esperado. Testes de fumaça são executados como parte de cada implantação.

  • Testes de interface do usuário - Esses testes validam se a interface do usuário foi implantada e funciona conforme o esperado. A implementação atual captura apenas capturas de tela de várias páginas após a implantação, sem nenhum teste real.

  • Testes de injeção de falhas - Estes testes podem ser automatizados ou executados manualmente. O teste automatizado na arquitetura integra o Azure Chaos Studio como parte dos pipelines de implantação.

Para obter mais informações, consulte Implantação e teste para cargas de trabalho de missão crítica no Azure: validação e teste contínuos

Testes: Frameworks

A implementação de referência on-line existente capacidades de teste e estruturas sempre que possível.

Estrutura Teste Description
NUnit Unit Essa estrutura é usada para testar a unidade da parte .NET Core da implementação. Os testes de unidade são executados automaticamente pelos Pipelines do Azure antes das compilações de contêiner.
JMeter com Teste de Carga do Azure Carregamento O Teste de Carga do Azure é um serviço gerenciado usado para executar definições de teste de carga do Apache JMeter .
Gafanhotos Carregamento Locust é uma estrutura de teste de carga de código aberto escrita em Python.
Dramaturgo UI e fumaça Playwright é uma biblioteca de Node.js de código aberto para automatizar o Chromium, Firefox e WebKit com uma única API. A definição do teste do dramaturgo também pode ser usada independentemente da implementação de referência.
Azure Chaos Studio Falha na injeção A implementação de referência usa o Azure Chaos Studio como uma etapa opcional no pipeline de validação E2E para injetar falhas para validação de resiliência.

Testes: Testes de injeção de falhas e Engenharia do Caos

Os aplicativos distribuídos devem ser resilientes a interrupções de serviços e componentes. O teste de injeção de falhas (também conhecido como injeção de falhas ou engenharia do caos) é a prática de submeter aplicativos e serviços a tensões e falhas do mundo real.

A resiliência é uma propriedade de todo um sistema e injetar falhas ajuda a encontrar problemas no aplicativo. Resolver esses problemas ajuda a validar a resiliência do aplicativo para condições não confiáveis, dependências ausentes e outros erros.

Testes manuais e automáticos podem ser executados na infraestrutura para encontrar falhas e problemas na implementação.

Automático

A arquitetura de referência integra o Azure Chaos Studio para implantar e executar um conjunto de experimentos do Azure Chaos Studio para injetar várias falhas no nível de carimbo. Os experimentos de caos podem ser executados como uma parte opcional do pipeline de implantação do E2E. Quando os testes são executados, o teste de carga opcional é sempre executado em paralelo. O teste de carga é usado para criar carga no cluster para validar o efeito das falhas injetadas.

Manual

O teste manual de injeção de falha deve ser feito em um ambiente de validação E2E. Este ambiente garante testes totalmente representativos sem risco de interferência de outros ambientes. A maioria das falhas geradas com os testes pode ser observada diretamente na visualização de métricas do Application Insights Live. As falhas restantes estão disponíveis na visualização Falhas e nas tabelas de log correspondentes. Outras falhas exigem depuração mais profunda, como o uso de kubectl para observar o comportamento dentro do AKS.

Dois exemplos de testes de injeção de falha realizados em relação à arquitetura de referência são:

  • Injeção de falha baseada em DNS - Um caso de teste que pode simular vários problemas. Falhas de resolução de DNS devido à falha de um servidor DNS ou do DNS do Azure. O teste baseado em DNS pode ajudar a simular problemas gerais de conexões entre um cliente e um serviço, por exemplo, quando o BackgroundProcessor não consegue se conectar aos Hubs de Eventos .

    Em cenários de host único, você pode modificar o arquivo local hosts para substituir a resolução DNS. Em um ambiente maior com vários servidores dinâmicos como o AKS, um hosts arquivo não é viável. As Zonas DNS Privadas do Azure podem ser usadas como uma alternativa para testar cenários de falha.

    Os Hubs de Eventos do Azure e o Azure Cosmos DB são dois dos serviços do Azure usados na implementação de referência que podem ser usados para injetar falhas baseadas em DNS. A resolução DNS dos Hubs de Eventos pode ser manipulada com uma zona DNS Privada do Azure vinculada à rede virtual de um dos selos. O Azure Cosmos DB é um serviço replicado globalmente com pontos de extremidade regionais específicos. A manipulação dos registros DNS para esses pontos de extremidade pode simular uma falha para uma região específica e testar o failover de clientes.

  • Bloqueio de firewall - A maioria dos serviços do Azure oferece suporte a restrições de acesso ao firewall com base em redes virtuais e/ou endereços IP. Na infraestrutura de referência, essas restrições são usadas para restringir o acesso ao Azure Cosmos DB ou Hubs de Eventos. Um procedimento simples é remover as regras de Permissão existentes ou adicionar novas regras de Bloqueio. Este procedimento pode simular configurações incorretas de firewall ou interrupções de serviço.

    Os seguintes serviços de exemplo na implementação de referência podem ser testados com um teste de firewall:

    Serviço Result
    Key Vault Quando o acesso ao Key Vault é bloqueado, o efeito mais direto foi a falha de novos pods para desovar. O driver CSI do Key Vault que busca segredos na inicialização do pod não pode executar suas tarefas e impede que o pod seja iniciado. Mensagens de erro correspondentes podem ser observadas com kubectl describe po CatalogService-deploy-my-new-pod -n workload. Os pods existentes continuarão a funcionar, embora a mesma mensagem de erro seja observada. A mensagem de erro é gerada pelos resultados da verificação de segredos de atualização periódica. Embora não tenha sido testado, presume-se que a execução de uma implantação não funcionará enquanto o Cofre da Chave estiver inacessível. As tarefas Terraform e CLI do Azure dentro da execução do pipeline fazem solicitações ao Cofre de Chaves.
    Hubs de Eventos Quando o acesso aos Hubs de Eventos é bloqueado, novas mensagens enviadas pelo CatalogService e HealthService falharão. A recuperação de mensagens pelo BackgroundProcess falhará lentamente, com falha total em poucos minutos.
    BD do Cosmos para o Azure A remoção da política de firewall existente para uma rede virtual faz com que o Serviço de Integridade comece a falhar com atraso mínimo. Este procedimento simula apenas um caso específico, uma interrupção inteira do Azure Cosmos DB. A maioria dos casos de falha que ocorrem em nível regional deve ser atenuada automaticamente pelo failover transparente do cliente para uma região diferente do Azure Cosmos DB. O teste de injeção de falha baseado em DNS descrito anteriormente é um teste mais significativo para o Azure Cosmos DB.
    Registro de contêiner (ACR) Quando o acesso ao ACR é bloqueado, a criação de novos pods que foram puxados e armazenados em cache anteriormente em um nó AKS continuará a funcionar. A criação ainda funciona devido à bandeira pullPolicy=IfNotPresentde implantação do k8s. Os nós que não puxaram e armazenaram em cache uma imagem antes do bloco não podem gerar um novo pod e falham imediatamente com ErrImagePull erros. kubectl describe pod Exibe a mensagem correspondente 403 Forbidden .
    AKS ingress Load Balancer A alteração das regras de entrada para HTTP(S)(portas 80 e 443) no Grupo de Segurança de Rede (NSG) gerenciado pelo AKS para Negar resulta em tráfego de sonda de usuário ou integridade que não alcança o cluster. O teste desta falha é difícil de identificar a causa raiz, que foi simulada como bloqueio entre o caminho de rede da Front Door e um carimbo regional. O Front Door deteta imediatamente esta falha e retira o carimbo da rotação.