Déploiement et tests de charges de travail stratégiques sur Azure

Le déploiement et les tests de l’environnement stratégique sont des rouages essentiels de l’architecture de référence globale. Les empreintes d’application individuelles sont déployées à l’aide d’une infrastructure en tant que code à partir d’un référentiel de code source. Les mises à jour de l’infrastructure, puis de l’application, devraient être déployées sans temps d’arrêt de l’application. Un pipeline d’intégration continue de DevOps est recommandé pour récupérer le code source à partir du référentiel et déployer les empreintes individuelles dans Azure.

Le déploiement et les mises à jour sont le processus central de l’architecture. Les mises à jour liées à l’infrastructure et à l’application devraient être déployées sur des empreintes entièrement indépendantes. Seuls les composants d’infrastructure globaux de l’architecture sont partagés entre les empreintes. Les empreintes existantes dans l’infrastructure ne sont pas touchées. Les mises à jour d’infrastructure ne seront déployées que sur ces nouvelles empreintes. De même, la nouvelle version de l’application ne sera déployée que sur ces nouvelles empreintes.

Les nouvelles empreintes sont ajoutées à Azure Front Door. Le trafic est progressivement déplacé vers les nouvelles empreintes. Une fois établi que le trafic est servi sans problème à partir des nouvelles empreintes, les empreintes précédentes sont supprimées.

Des tests de pénétration, de chaos et de contrainte sont recommandés pour l’environnement déployé. Les tests proactifs de l’infrastructure permettent de découvrir d’éventuelles faiblesses et la façon dont l’application déployée se comportera en cas de défaillance.

Déploiement

Le déploiement de l’infrastructure dans l’architecture de référence dépend des processus et composants suivants :

• DevOps : code source extrait de GitHub et pipelines pour l’infrastructure.

• Mises à jour sans temps d’arrêt : les mises à jour et mises à niveau sont déployées sur l’environnement sans temps d’arrêt de l’application déployée.

• Environnements : environnements éphémères et permanents utilisés pour l’architecture.

• Ressources partagées et dédiées : ressources Azure dédiées aux empreintes et à l’infrastructure globale, et partagées avec celles-ci.

Pour plus d’informations, consultez Déploiement et tests de charges de travail stratégiques sur Azure : Considérations relatives à la conception

Déploiement : DevOps

Les composants de DevOps fournissent le référentiel de code source et des pipelines de CI/CD pour le déploiement de l’infrastructure et les mises à jour. GitHub et Azure Pipelines ont été choisis comme composants.

• GitHub : contient les référentiels de code source pour l’application et l’infrastructure.

• Azure Pipelines : pipelines utilisés par l’architecture pour toutes les tâches de génération, de test et de publication.

Un composant supplémentaire dans la conception, utilisé pour le déploiement, est celui des agents de build. Des agents de build hébergés par Microsoft sont utilisés dans Azure Pipelines pour déployer l’infrastructure et les mises à jour. L’utilisation d’agents de build hébergés par Microsoft a pour effet d’éliminer la charge de gestion que constituent pour les développeurs la maintenance et la mise à jour de l’agent de build.

Pour plus d’informations sur Azure Pipelines, consultez Qu’est-ce qu’Azure DevOps Services ?.

Pour plus d’informations, consultez Déploiement et tests de charges de travail stratégiques sur Azure : Déploiements d’infrastructure en tant que code

Déploiement : Mises à jour sans temps d’arrêt

La stratégie de mise à jour sans temps d’arrêt dans l’architecture de référence est centrale pour l’application stratégique. La méthodologie de remplacement plutôt que de mise à niveau des empreintes garantit une nouvelle installation de l’application dans un empreinte d’infrastructure. L’architecture de référence utilise une approche de déploiement bleu/vert et permet de disposer d’environnements de test et de développement séparés.

L’architecture de référence comprend deux composants principaux :

• Infrastructure : services et ressources Azure. Déployée avec Terraform et sa configuration associée.

• Application : service ou application hébergés servant les utilisateurs. Basée sur des conteneurs Docker et des artefacts générés npm en HTML et JavaScript pour l’interface utilisateur d’application monopage (SPA).

De nombreux systèmes partent de l’hypothèse que les mises à jour d’application seront plus fréquentes que les mises à jour d’infrastructure. Par conséquent, des procédures différentes sont développées pour chaque type de mise à jour. Avec une infrastructure de cloud public, des modifications peuvent intervenir à un rythme plus rapide. Un processus de déploiement pour les mises à jour d’application et d’infrastructure a été choisi. Une approche garantit que les mises à jour d’infrastructure et d’application sont toujours synchronisées. Cette approche offre les avantages suivants :

• Un seul processus cohérent : moindre probabilité d’erreurs si les mises à jour d’infrastructure et d’application sont mélangées dans une même publication, intentionnellement ou non.

• Permet un déploiement bleu/vert : chaque mise à jour est déployée à l’aide d’une migration progressive du trafic vers la nouvelle publication.

• Déploiement et débogage plus faciles de l’application : l’empreinte entière n’hébergera jamais plusieurs versions de l’application côte à côte.

• Restauration simple : le trafic peut être rebasculé vers les empreintes exécutant la version précédente si des erreurs ou des problèmes sont rencontrés.

• Élimination des modifications manuelles et de la dérive de configuration : chaque environnement est un nouveau déploiement.

Pour plus d’informations, consultez Déploiement et tests de charges de travail stratégiques sur Azure : Déploiements bleus/verts éphémères

Stratégie de création de branches

La base de la stratégie de mise à jour est l’utilisation de branches dans le dépôt Git. L’architecture de référence utilise trois types de branches :

Branche	Description
feature/* et fix/*	Points d’entrée pour toute modification. Ces branches créées par les développeurs doivent avoir un nom descriptif, comme feature/catalog-update ou fix/worker-timeout-bug. Quand des modifications sont prêtes à être fusionnées, une demande de tirage (pull request) sur la branche main est créée. Chaque demande de tirage doit être approuvée par au moins un réviseur. Avec des exceptions limitées, chaque modification proposée dans une demande de tirage doit s’exécuter via le pipeline de validation de bout en bout (E2E). Le pipeline E2E devrait être utilisé par les développeurs pour tester et déboguer les modifications apportées à un environnement complet.
main	Branche en constante évolution et stable. Principalement utilisé pour les tests d’intégration. Les modifications sont apportées à main uniquement via des demandes de tirage. Une stratégie de branche interdit les écritures directes. Les publications nocturnes sur l’environnement integration (int) permanent sont exécutées automatiquement à partir de la branche main. La branche main est considérée comme stable. On devrait pouvoir supposer qu’à tout moment, une publication pourrait être créé à partir de celle-ci.
release/*	Des branches de publication sont créées uniquement à partir de la branche main. Les branches sont au format release/2021.7.X. Des stratégies de branche sont utilisées afin que seuls des administrateurs de dépôt soient autorisés à créer des branches release/*. Seules ces branches sont utilisées pour le déploiement dans l’environnement prod.

Pour plus d’informations, consultez Déploiement et tests de charges de travail stratégiques sur Azure : Stratégie de création de branches

Correctifs logiciels

Quand un correctif logiciel requis d’urgence en raison d’un bogue ou d’un autre problème ne peut pas passer par le processus de publication normal, un chemin d’accès au correctif est disponible. Les mises à jour et correctifs de sécurité critiques de l’expérience utilisateur qui n’ont pas été découverts lors des tests initiaux sont considérés comme des exemples valides de correctifs logiciels.

Le correctif logiciel doit être créé dans une nouvelle branche fix, puis fusionné dans main à l’aide d’une demande de tirage ordinaire. Au lieu de créer une branche de publication, le correctif logiciel est sélectionné dans une branche de publication existante. Cette branche est déjà déployée dans l’environnement prod. Le pipeline de CI/CD qui a initialement déployé la branche de publication avec tous les tests est réexécuté et déploie le correctif logiciel.

Pour éviter des problèmes majeurs, il est important que le correctif logiciel contienne quelques validations isolées qui peuvent facilement être sélectionnées et intégrées dans la branche de publication. Si des validations isolées ne peuvent pas être sélectionnées pour intégration dans la branche de publication, cela indique que la modification ne peut pas être considérée comme un correctif logiciel. La modification devrait être déployée en tant que nouvelle publication complète, voire combinée avec une restauration vers une version stable antérieure jusqu’à ce que la nouvelle publication puisse être déployée.

Déploiement : environnements

L’architecture de référence utilise deux types d’environnements pour l’infrastructure :

• Éphémère : le pipeline de validation E2E est utilisé pour déployer des environnements éphémères. Des environnements éphémères sont utilisés par les développeurs pour des tâches de validation ou de débogage purs. Il est possible de les créer à partir de la branche feature/*, sujette à des tests, puis de les détruire si tous les tests ont réussi. Les environnements de débogage sont déployés de la même façon que les environnements de validation, mais ne sont pas détruits immédiatement. Ces environnements ne devraient pas exister pendant plus de quelques jours et devraient être supprimés une fois que la demande de tirage correspondante de la branche de fonctionnalité est fusionnée.

• Permanent : les environnements permanents comprennent les versions integration (int) et production (prod). Ces environnements vivent en permanence et ne sont pas détruits. Ils portent des noms de domaine fixes tels que int.mission-critical.app. Dans une implémentation réelle de l’architecture de référence, un environnement (pré-prod) staging devrait être ajouté. L’environnement staging est utilisé pour déployer et valider des branches release avec le même processus de mise à jour que prod (déploiement bleu/vert).

  • Intégration (int) : la version int est déployée en nocturne à partir de la branche main avec le même processus que prod. Le basculement de trafic est plus rapide que pour l’unité de publication précédente. Au lieu de basculer le trafic progressivement sur plusieurs jours, comme dans prod, le processus pour int prend quelques minutes ou heures. Ce basculement plus rapide garantit que l’environnement mis à jour sera prêt le lendemain matin. Les anciennes empreintes sont automatiquement supprimées si tous les tests du pipeline réussissent.

  • Production (prod) : la version prod est déployée uniquement à partir de branches release/*. Le basculement de trafic utilise des étapes plus précises. Une porte d’approbation manuelle sépare chaque étape. Chaque version crée de nouvelles empreintes régionales et déploie la nouvelle version de l’application sur les empreintes. Les empreintes existantes ne sont pas touchées dans le processus. L’aspect le plus important à prendre en considération pour l’environnement prod est qu’il devrait être « Always-on ». Il ne peut y avoir aucun temps d’arrêt, planifié ou non. La seule exception a trait aux modifications fondamentales apportées à la couche base de données. Une fenêtre de maintenance planifiée peut être nécessaire.

Déploiement : ressources partagées et dédiées

Les environnements permanents (int et prod) au sein de l’architecture de référence ont différents types de ressources selon qu’elles sont partagées avec l’ensemble de l’infrastructure ou dédiées à une empreinte individuelle. Des ressources peuvent être dédiées à une publication particulière et n’exister que jusqu’à ce que l’unité de publication suivante ait pris le relais.

Unités de publication

Une unité de publication est constitué de plusieurs empreintes régionales par version spécifique. Les empreintes contiennent toutes les ressources qui ne sont pas partagées avec d’autres empreintes. Ces ressources sont des réseaux virtuels, un cluster Azure Kubernetes Service, Event Hubs et Azure Key Vault. Azure Cosmos DB et ACR sont configurés avec des sources de données Terraform.

Ressources partagées globalement

Toutes les ressources partagées entre unités de publication sont définies dans un modèle Terraform indépendant. Ces ressources sont Front Door, Azure Cosmos DB, Container Registry (ACR), ainsi que les espaces de travail Log Analytics et autres ressources liées à la surveillance. Ces ressources sont déployées avant le déploiement de la première empreinte régionale d’une unité de publication. Les ressources sont référencées dans les modèles Terraform pour les empreintes.

Front Door

Bien que Front Door soit une ressource partagée globalement entre empreintes, sa configuration est légèrement différente des autres ressources globales. Front Door doit être reconfiguré après le déploiement d’une nouvelle empreinte. Front Door doit être reconfiguré pour basculer progressivement le trafic vers les nouvelles empreintes.

La configuration du serveur principal de Front Door ne peut pas être définie directement dans le modèle Terraform. La configuration est insérée avec des variables Terraform. Les valeurs de variable sont construites avant le démarrage du déploiement de Terraform.

La configuration de composant individuel pour le déploiement de Front Door est définie comme suit :

• Serveur frontal : l’affinité de session est configurée pour garantir que les utilisateurs ne basculent pas entre différentes versions d’interface utilisateur au cours d’une seule session.

• Origines : Front Door est configuré avec deux types de groupes d’origines :

  1. Groupe d’origines pour le stockage statique qui sert l’interface utilisateur. Le groupe contient les comptes de stockage de site web de toutes les unités de publication actuellement actives. Différentes pondérations peuvent être attribuées aux origines de différentes unités de publication afin de déplacer progressivement le trafic vers une unité plus récente. La même pondération doit être attribuée à chaque origine d’une unité de publication.

  2. Groupe d’origines pour l’API, hébergé sur AKS. S’il existe des unités de publication avec différentes versions d’API, un groupe d’origines d’API existe pour chaque unité de publication. Si toutes les unités de publication offrent la même API compatible, toutes les origines sont ajoutées au même groupe et reçoivent des pondérations différentes.

• Règles d’acheminement : il existe deux types de règles d’acheminement :

  1. Règle d’acheminement pour l’interface utilisateur liée au groupe d’origines de stockage de l’interface utilisateur.

  2. Règle d’acheminement pour chaque API actuellement prise en charge par les origines. Par exemple : /api/1.0/* et /api/2.0/*.

  Si une publication introduit une nouvelle version des API principales, les modifications se reflètent dans l’interface utilisateur déployée avec la publication. Une publication spécifique de l’interface utilisateur appelle toujours une version spécifique de l’URL d’API. Les utilisateurs servis par une version de l’interface utilisateur utilisent automatiquement l’API principale associée. Des règles d’acheminement spécifiques sont nécessaires pour différentes instances de la version d’API. Ces règles sont liées aux groupes d’origines correspondants. Si aucune nouvelle API n’a été introduite, toutes les règles d’acheminement liées à l’API sont reliées au groupe d’origines unique. Dans ce cas, peu importe si un utilisateur reçoit l’interface utilisateur d’une publication différente de celle de l’API.

Déploiement : processus de déploiement

Un déploiement bleu/vert est l’objectif du processus de déploiement. Une nouvelle publication d’une branche release/* est déployée dans l’environnement prod. Le trafic utilisateur est progressivement déplacé vers les empreintes destinées à la nouvelle version.

À la première étape du processus de déploiement d’une nouvelle version, l’infrastructure de la nouvelle unité de publication est déployée avec Terraform. L’exécution du pipeline de déploiement d’infrastructure a pour effet de déployer la nouvelle infrastructure à partir d’une branche de publication sélectionnée. Parallèlement à l’approvisionnement d’infrastructure, les images conteneurs sont générées ou importées et envoyées (push) au registre de conteneurs partagé globalement (ACR). Une fois les processus précédents terminés, l’application est déployée sur les empreintes. Du point de vue de l’implémentation, il s’agit d’un seul pipeline avec plusieurs étapes dépendantes. Le même pipeline peut être réexécuté pour des déploiements de correctifs logiciels.

Une fois la nouvelle unité de publication déployée et validée, elle est ajoutée à Front Door pour recevoir du trafic utilisateur.

Un commutateur/paramètre opérant la distinction entre les publications qui introduisent et n’introduisent pas de nouvelle version d’API devrait être prévu. Selon que la version introduit ou non une nouvelle version d’API, un nouveau groupe d’origines avec les serveurs principaux d’API doit être créé. Vous pouvez également ajouter des serveurs principaux d’API à un groupe d’origines existant. De nouveaux comptes de stockage d’interface utilisateur sont ajoutés au groupe d’origines existant correspondant. Des pondérations pour les nouvelles origines devraient être définies en fonction du fractionnement de trafic souhaité. Une nouvelle règle d’acheminement, comme décrit ci-dessus, doit être créée, qui correspond au groupe d’origines approprié.

Dans le cadre de l’ajout de la nouvelle unité de publication, les pondérations des nouvelles origines doivent être définies sur le trafic utilisateur minimal souhaité. Si aucun problème n’est détecté, le volume de trafic utilisateur devrait être augmenté vers le nouveau groupe d’origines sur une période donnée. Pour ajuster les paramètres de pondération, les mêmes étapes de déploiement doivent être ré-exécutées avec les valeurs souhaitées.

Désactivation d’unité de publication

Dans le cadre du pipeline de déploiement d’une unité de publication, il existe une étape de destruction qui supprime tous les empreintes une fois qu’une unité de publication n’est plus nécessaire. Tout le trafic est déplacé vers une nouvelle version de publication. Cette étape inclut la suppression des références d’unité de publication de Front Door. Cette suppression est essentielle pour permettre la publication d’une nouvelle version à une date ultérieure. Front Door doit pointer vers une unité de publication unique afin d’être préparé pour la prochaine publication.

Checklists

En lien avec la cadence de publication, une liste de contrôle avant et après publication devrait être utilisée. L’exemple suivant a trait aux éléments qui devraient figurer au minimum dans une liste de contrôle.

• Liste de contrôle avant publication : avant de démarrer une publication, vérifiez que :

  • Le dernier état de la branche main a été correctement déployé et testé dans l’environnement int.

  • Mettez à jour le fichier changelog via une demande de tirage sur la branche main.

  • Créez une branche release/ à partir de la branche main.

• Liste de contrôle après publication : avant que les anciennes empreintes soient détruites et leurs références supprimées de Front Door, vérifiez que :

  • Les clusters ne reçoivent plus de trafic entrant.

  • Event Hubs et d’autres files d’attente de messages ne contiennent aucun message non traité.

Déploiement : limitations et risques de la stratégie de mise à jour

La stratégie de mise à jour décrite dans cette architecture de référence présente des limitations et des risques qui devraient être mentionnés :

• Coût plus élevé : lors de la publication de mises à jour, la plupart des composants d’infrastructure sont actifs deux fois pendant la période de publication.

• Complexité de Front Door : le processus de mise à jour dans Front Door est complexe à implémenter et à gérer. La possibilité d’exécuter des déploiements bleus/verts efficaces sans temps d’arrêt dépend du bon fonctionnement.

• Petites modifications chronophages : le processus de mise à jour entraîne un processus de publication plus long pour les petites modifications. Cette limitation peut être partiellement atténuée avec le processus de correctif logiciel décrit dans la section précédente.

Déploiement : considérations relatives à la compatibilité ascendante des données d’application

La stratégie de mise à jour peut prendre en charge plusieurs versions d’une API et de composants worker s’exécutant simultanément. Étant donné que Azure Cosmos DB est partagé entre au moins deux versions, il se peut que des éléments de données modifiés par une version ne correspondent pas toujours à la version de l’API ou des workers qui la consomment. Les couches et workers d’API doivent implémenter une conception de compatibilité ascendante. Des versions antérieures de l’API ou de composants worker traitent des données qui ont été insérées par une version ultérieure de l’API ou du composant worker. Les parties non comprises sont ignorées.

Test

L’architecture de référence contient différents tests utilisés à différentes étapes de l’implémentation des tests.

Ces tests sont les suivants :

• Tests unitaires : ces tests vérifient que la logique métier de l’application fonctionne comme prévu. L’architecture de référence contient un exemple de suite de tests unitaires exécutés automatiquement avant chaque build de conteneur par Azure Pipelines. Si un test échoue, le pipeline s’arrête. La génération et le déploiement ne se font pas.

• Tests de charge : ces tests aident à évaluer la capacité, la scalabilité et les goulots d’étranglement potentiels pour une charge de travail ou une pile données. L’implémentation de référence contient un générateur de charge utilisateur pour créer des modèles de charge synthétiques utilisables pour simuler le trafic réel. Le générateur de charge peut également être utilisé indépendamment de l’implémentation de référence.

• Tests de détection de fumée : ces tests déterminent si l’infrastructure et la charge de travail sont disponibles et agissent comme prévu. Les tests de détection de fumée sont exécutés dans le cadre de chaque déploiement.

• Tests d’interface utilisateur : ces tests vérifient que l’interface utilisateur a été déployée et fonctionne comme prévu. L’implémentation actuelle prend uniquement des captures d’écran de quelques pages après le déploiement sans aucun test réel.

• Tests par injection de défaillances : ces tests peuvent être automatisés ou exécutés manuellement. Les tests automatisés dans l’architecture intègrent Azure Chaos Studio dans les pipelines de déploiement.

Pour plus d’informations, consultez Déploiement et tests de charges de travail stratégiques sur Azure : Validation et tests continus

Tests : infrastructures

Implémentation de référence en ligne des fonctionnalités et infrastructures de test existantes chaque fois que c’est possible.

Infrastructure	Test	Description
NUnit	Unité	Cette infrastructure est utilisée pour effectuer les tests unitaires de la partie .NET Core de l’implémentation. Azure Pipelines exécute les tests unitaires automatiquement avant les builds de conteneur.
JMeter avec Test de charge Azure	Load	Test de charge Azure est un service managé utilisé pour exécuter des définitions de test de charge Apache JMeter.
Locust	Load	Locust est une infrastructure de test de charge open source écrite en Python.
Playwright	Interface utilisateur et détection de fumée	Playwright est une bibliothèque Node.js open source pour automatiser Chromium, Firefox et WebKit avec une seule API. La définition de test Playwright peut également être utilisée indépendamment de l’implémentation de référence.
Azure Chaos Studio	Injection de défaillances	L’implémentation de référence utilise Azure Chaos Studio comme étape facultative dans le pipeline de validation E2E afin d’injecter des défaillances pour la validation de la résilience.

Tests : tests par injection de défaillances et ingénierie du chaos

Les applications distribuées devraient être résilientes aux pannes de service et de composants. Les tests par injection de défaillances (également appelé Injection d’erreurs ou Ingénierie du chaos) relèvent de la pratique consistant à soumettre des applications et services à des contraintes et défaillances réelles.

La résilience est une propriété d’un système entier et l’injection d’erreurs permet d’épingler des problèmes dans l’application. La résolution de ces problèmes permet de valider la résilience de l’application à des conditions non fiables, à des dépendances manquantes et à d’autres erreurs.

Des tests manuels et automatiques peuvent être exécutés sur l’infrastructure pour rechercher des erreurs et des problèmes dans l’implémentation.

Automatique

L’architecture de référence intègre Azure Chaos Studio pour déployer et exécuter un ensemble d’expériences Azure Chaos Studio consistant à injecter diverses erreurs au niveau de l’empreinte. Des expériences de chaos peuvent être exécutées en tant que partie facultative du pipeline de déploiement E2E. Lors de l’exécution des tests, le test de charge facultatif est toujours exécuté en parallèle. Le test de charge est utilisé pour créer une charge sur le cluster afin de valider l’effet des erreurs injectées.

Manuel

Les tests par injection de défaillances manuels doivent être effectués dans un environnement de validation E2E. Cet environnement garantit l’exécution de tests représentatifs complets sans risque d’interférence d’autres environnements. La plupart des défaillances générées avec les tests peuvent être observées directement dans l’affichage Métriques en temps réel d’Application Insights. Les défaillances restantes sont disponibles dans l’affichage Défaillances et les tables de journal correspondantes. D’autres défaillances nécessitent un débogage plus approfondi, comme l’utilisation de kubectl pour observer le comportement à l’intérieur d’AKS.

Voici deux exemples de tests par injection de défaillances effectués sur l’architecture de référence :

• Injection de défaillances basées sur DNS : cas de test pouvant simuler plusieurs problèmes. Échecs de résolution DNS en raison de l’échec d’un serveur DNS ou d’Azure DNS. Les tests basés sur DNS peuvent vous aider à simuler des problèmes généraux de connexions entre un client et un service, par exemple, quand BackgroundProcessor ne peut pas se connecter à Event Hubs.

  Dans les scénarios à hôte unique, vous pouvez modifier le fichier hosts local pour remplacer la résolution DNS. Dans un environnement de plus grande taille avec plusieurs serveurs dynamiques comme AKS, un fichier hosts n’est pas réalisable. Des Zones DNS privé Azure peuvent être utilisées comme alternative pour tester des scénarios de défaillance.

  Azure Event Hubs et Azure Cosmos DB sont deux des services Azure utilisés dans l’implémentation de référence, dont vous pouvez vous servir pour injecter des défaillances basées sur DNS. La résolution DNS Event Hubs peut être manipulée avec une zone DNS privé Azure liée au réseau virtuel de l’un des empreintes. Azure Cosmos DB est un service globalement répliqué avec des points de terminaison régionaux spécifiques. Une manipulation des enregistrements DNS pour ces points de terminaison permet de simuler une défaillance pour une région spécifique, et de tester le basculement des clients.

• Blocage du pare-feu : la plupart des services Azure prennent en charge les restrictions d’accès du pare-feu en fonction de réseaux virtuels et/ou d’adresses IP. Dans l’infrastructure de référence, ces restrictions sont utilisées pour restreindre l’accès à Azure Cosmos DB ou à Event Hubs. Une procédure simple consiste à supprimer des règles d’Autorisation existantes ou à ajouter des règles de Blocage . Cette procédure peut simuler des mauvaises configuration du pare-feu ou des pannes de service.

  Les exemples de services suivants dans l’implémentation de référence peuvent être testés avec un test de pare-feu :

  Service	Résultats
  Key Vault	Lorsque l’accès au Key Vault est bloqué, l’effet le plus direct est l’échec de génération de nouveaux pods. Le pilote CSI du Key Vault qui récupère les secrets au démarrage du pod ne peut pas effectuer ses tâches et empêche le démarrage du pod. Des messages d’erreur correspondants peuvent être observés avec kubectl describe po CatalogService-deploy-my-new-pod -n workload. Les pods existants continueront de fonctionner, bien que le même message d’erreur s’affiche. Le message d’erreur est généré par les résultats de la vérification périodique des mises à jour pour les secrets. Bien que cela n’ait pas été testé, il est supposé que l’exécution d’un déploiement ne fonctionnera pas tant que le Key Vault restera inaccessible. Les tâches Terraform et Azure CLI au sein de l’exécution du pipeline adressent des demandes au Key Vault.
  Hubs d'événements	Quand l’accès à Event Hubs est bloqué, les nouveaux messages envoyés par CatalogService et HealthService échouent. La récupération des messages par BackgroundProcess échoue lentement, aboutissant à un échec total après quelques minutes.
  Azure Cosmos DB	La suppression de la stratégie de pare-feu existante pour un réseau virtuel a pour effet que le service de contrôle d’intégrité commence à échouer avec un retard minime. Cette procédure simule uniquement un cas spécifique de panne totale de Azure Cosmos DB. La plupart des cas de défaillance qui se produisent au niveau régional devraient être atténués automatiquement par un basculement transparent du client vers une autre région Azure Cosmos DB. Les tests par injection de défaillance DNS décrits précédemment sont plus significatifs pour Azure Cosmos DB.
  Registre de conteneurs (ACR)	Lorsque l’accès à ACR est bloqué, la création de pods extraits et mis en cache précédemment sur un nœud AKS continue de fonctionner. La création fonctionne toujours en raison de l’indicateur de déploiement k8spullPolicy=IfNotPresent. Les nœuds qui n’ont pas extrait et mis en cache une image avant le blocage ne peuvent pas générer de nouveau pod et échouent immédiatement avec des erreurs ErrImagePull. kubectl describe pod affiche le message 403 Forbidden correspondant.
  Équilibreur de charge d’entrée AKS	La modification des règles de trafic entrant en Refuser pour HTTP(S) (ports 80 et 443) dans le groupe de sécurité réseau (NSG) managé par AKS a pour effet que le trafic utilisateur ou de la sonde d’intégrité ne parvient pas à atteindre le cluster. Il est difficile d’identifier la cause profonde de cette défaillance dont le test simule un blocage entre le chemin réseau de Front Door et une empreinte régionale. Front Door détecte immédiatement cette défaillance et retire l’empreinte de la rotation.