La conteneurisation est une approche courante de la modernisation d’application. Vous pouvez envisager d’utiliser Azure Container Service pour des charges de travail avancées, ou d’utiliser Azure Container Instances pour des charges de travail de conteneur simples, telle une application web simple. Cet article se concentre sur l’implémentation de l’automation serverless au niveau de l’infrastructure pour Container Instances quand Application Gateway est utilisé en tant que pare-feu.
Nous allons commencer par un scénario courant. Pour sécuriser Azure Container instances, vous pouvez utiliser des groupes de conteneurs dans Azure Container Instances. Des groupes de conteneurs vous permettent de déployer Azure Container instances dans un réseau virtuel pour que les conteneurs puissent accéder à d’autres ressources privées ou à d’autres services Azure via un point de terminaison privé Azure. Pour les clients hébergeant des applications web, il est courant d’utiliser un pare-feu d’applications web comme Azure Application Gateway pour servir frontalement le trafic entrant tout en utilisant Azure Container Instances en tant que pool principal. Cet article constitue un excellent point de départ : Exposer une adresse IP statique pour un groupe de conteneurs.
L’une des difficultés potentielles de cette approche consiste à utiliser une adresse IP privée non statique en tant que pool principal. Il est possible d’opérer une rotation de l’adresse IP privée pendant la maintenance, ce qui requiert que l’administrateur cloud reconfigure manuellement le pool principal. Si de nouveaux conteneurs sont ajoutés pour la mise à l’échelle, l’administrateur doit également effectuer une reconfiguration pour s’assurer que le trafic est acheminé vers le pool principal approprié. Les probes liveness et readiness n’étant pas prises en charge dans les groupes de conteneurs, cela complique l’identification des temps d’arrêt de la charge de travail.
Cet article explore les améliorations apportées pour résoudre ces problèmes courants en adoptant Application Insights et Azure Monitor pour la surveillance et l’utilisation d’Azure Functions afin d’effectuer une rotation automatique des adresses IP privées. Cette approche améliore la redondance de la charge de travail.
Cas d’usage potentiels
L’architecture convient parfaitement pour ce qui suit :
- Déploiement serverless.
- Opération minimale pour une charge de travail native Cloud avec automation.
- Charge de travail de conteneur simple ne nécessitant pas d’orchestration de conteneurs avancée.
- Charge de travail hautement redondante et externe avec reconfiguration automatisée.
- Charge de travail de conteneur requérant l’accès à des ressources privées comme celles exposées par des points de terminaison privés Azure.
Architecture
Téléchargez un fichier Visio de cette architecture.
Dataflow
Partie 1 : flux de trafic d’application web classique
1a. Application Gateway a une fonctionnalité de pare-feu d’applications web, ce qui est idéal pour le service frontal du trafic public avant qu’il atteigne la charge de travail principale. Application Gateway exposant l’adresse IP publique, Azure DDoS Protection fournit une autre couche de protection.
1b. Le pool principal d’Application Gateway est configuré avec l’adresse IP privée de l’instance de conteneur Azure dans un groupe de conteneurs. Les instances de conteneur Azure dans les groupes de conteneurs n’étant pas fournies avec des noms de domaine complets (FQDN), l’adresse IP doit être utilisée.
1c. Dans Azure Container Instances, les conteneurs peuvent consommer des ressources privées, comme Azure Cosmos DB, via des liaisons privées.
Partie 2 : améliorations avec l’automation
2a. Application Gateway inclut une métrique du nombre d’hôtes sains que vous pouvez utiliser en tant que probe liveness pour Azure Container Instances, étant donné que les groupes de conteneurs dans Container Instances ne prennent pas en charge les probes liveness et readiness.
2b. Application Insights est utilisé dans des conteneurs pour collecter d’autres métriques, notamment des pulsations, qui peuvent être envoyées à Application Insights à des fins de monitoring via un thread personnalisé.
2c. Vous pouvez configurer des alertes en fonction des niveaux de seuil définis aux étapes 2A et 2B. Par exemple, supposons que votre système dispose de trois instances de conteneur s’exécutant en tant que pool principal. Vous pouvez configurer une alerte qui se déclenche quand le nombre d’hôtes sains est inférieur à 3. Dans un groupe d’actions de règles d’alerte, vous pouvez utiliser une fonction Azure comme type d’action pour déclencher l’action personnalisée.
2d. Dans la fonction Azure, un Kit de développement logiciel (SDK) Azure est utilisé pour récupérer la configuration d’instances de conteneur existantes et recréer les mêmes instances. Cette fonction est déclenchée par l’alerte définie à l’étape 2c. L’exécution de cette fonction peut prendre beaucoup de temps, selon la complexité de la configuration. Azure Functions pouvant expirer. vous pouvez utiliser Azure Durable Functions pour gérer des processus longs et récupérer des mises à jour d’état.
Composants
Automatisation
- Azure Durable Functions : contrairement à Azure Functions, Durable Functions est avec état et prend en charge plusieurs modèles de flux de travail avec état. Dans cet exemple, le modèle de moniteur est utilisé.
- Kits de développement logiciel (SDK) Azure : les kits de développement logiciel (SDK) Azure sont des collections de bibliothèques que vous pouvez utiliser pour interagir avec des services Azure dans votre langage de programmation de prédilection. Les kits de développement logiciel (SDK) offrent davantage de flexibilité pour l’intégration de la logique qui effectue l’automation.
Supervision
- Métriques d’Azure Monitor : cette fonctionnalité d’Azure Monitor collecte des données numériques prédéfinies à partir de services Azure.
- Groupe d’actions : collection de préférences de notification définies par le propriétaire de la ressource. Vous pouvez définir des canaux de notification et des actions en fonction des alertes déclenchées.
Mise en réseau
- Azure DDoS Protection : Azure DDoS Protection (De base) est gratuit et activé sur toutes les adresses IP publiques. Azure DDoS Network Protection offre davantage de fonctionnalités, telles que l’ingestion des journaux dans d’autres emplacements et la possibilité de recourir à l’équipe de réponse rapide de DDoS Protection.
- Azure Application Gateway : le pare-feu d’applications web Azure assure la protection des applications accessibles au public contre les attaques par injection de code SQL et les attaques XSS.
- Azure Private Link : permet d’accéder aux services PaaS Azure via un point de terminaison privé sur la dorsale Microsoft afin d’améliorer la sécurité d’accès réseau.
Application
- Azure Container Instances : exécute les images de conteneur en toute fluidité sans que vous ayez à configurer une autre infrastructure. Vous devez envisager Azure Kubernetes service (AKS) pour l’orchestration de conteneur avancée.
- Azure Cosmos DB : base de données NoSQL complètement managée qui prend en charge plusieurs plateformes, telles que SQL, Cassandra et MongoDB.
- Azure Key Vault : conformément aux meilleures pratiques de sécurité, les développeurs ne stockent pas de chaînes de connexion en texte clair dans le code source des applications. Azure Key Vault sert d’emplacement central pour stocker les secrets avec une sécurité améliorée. Les applications peuvent récupérer les clés nécessaires avec une sécurité améliorée.
Autres solutions
Le scénario précédent met à jour un pool principal pour Application Gateway. Vous pouvez également utiliser une zone DNS privée Azure comme serveur principal cible pour Application Gateway, et utiliser Azure Functions pour mettre à jour un enregistrement au lieu d’apporter des modifications sur Application Gateway. Cette alternative permettrait de réduire le temps de déploiement. En revanche, les métriques d’Application Gateway ne permettraient pas d’identifier le nombre d’hôtes, car il serait abstrait par DNS. Cette automation devrait donc être déclenchée directement par le biais d’une solution de monitoring d’application comme Application Insights ou Azure Monitor.
Azure propose plusieurs options pour héberger des charges de travail basées sur des conteneurs, comme Azure Kubernetes Service, Azure App Service et Azure Container Apps.
Azure Kubernetes Service fournit une orchestration de conteneur avancée et des fonctionnalités réseau telles que la ressource de service qui n’est pas disponible dans Container instances. Cette architecture de référence répond à cette exigence.
App Service peut également héberger des charges de travail de conteneur, et App Service Environment permet aux développeurs de déployer App Service dans un réseau virtuel Azure. La structure tarifaire de Container Instances, par rapport à App Service, la rend attrayante pour les petites charges de travail.
Azure Container Apps est une plateforme de conteneurs sans serveur basée sur Kubernetes. Il permet aux développeurs de construire une application de type Kubernetes qui ne nécessite pas un accès direct à toutes les API natives de Kubernetes et à la gestion des clusters. Azure Container Apps offre une expérience entièrement gérée basée sur les meilleures pratiques.
Considérations
Disponibilité
Étant donné que les probes liveliness et readiness ne sont pas prises en charge dans les groupes de conteneurs, nous vous recommandons d’utiliser des métriques Azure Monitor et Azure Application Insights pour la surveillance. L’intégrité et le temps d’activité des conteneurs ne sont pas des approches déterministes pour évaluer si un système fonctionne de bout en bout.
Operations
Azure Durable Functions permet de reconfigurer l’infrastructure en cas d’échec dans Container Instances ou de changement de l’adresse IP privée d’un groupe de conteneurs. Comme indiqué dans la documentation, le processus d’approvisionnement prend un peu plus de temps. Il se peut que les utilisateurs subissent un temps d’arrêt minimal si les conteneurs ne sont pas prêts à temps.
Cette architecture ajoute une couche de résilience. Toutefois, nous vous recommandons de configurer la surveillance dans l’application et de surveiller l’état d’Azure pour détecter des défaillances de plateforme.
Extensibilité
Les besoins en termes de processeur et de mémoire étant définis lors de la création de conteneurs. vous ne pourrez pas effectuer de mise à l’échelle verticale directement. Vous pouvez ajouter des conteneurs au groupe de conteneurs pour effectuer une mise à l’échelle horizontale. Notez cependant qu’étant donné que chaque conteneur dans le groupe de conteneurs consommera une adresse IP privée, la limite sera la taille du sous-réseau approvisionné.
Un autre point important à prendre en compte pour la mise à l’échelle est l’état de l’application. L’application doit gérer l’état localement ou à l’aide de services externes tels qu’Azure Cache pour Redis afin de garantir que la mise à l’échelle à la demande n’occasionne pas de perte de données dans l’application.
Sécurité
La possibilité de déployer PaaS dans un réseau virtuel (par injection de réseau virtuel) n’améliore pas la sécurité si la configuration n’est pas configurée correctement. L’injection de réseau virtuel offre aux administrateurs davantage de contrôle du réseau, en offrant des avantages tels que des groupes de sécurité réseau plus étroits et l’utilisation de ressources non exposées publiquement.
Private Link projette un point de terminaison privé dans le réseau virtuel, ce qui permet à l’application d’accéder directement à Azure PaaS via une adresse IP privée. En même temps, les administrateurs peuvent contrôler plus précisément qui peut accéder au PaaS Azure approprié.
Si vous stockez des images de conteneur dans Azure Container Registry, vous pouvez activer Microsoft Defender pour les registres de conteneurs afin d’effectuer des analyses de vulnérabilité d’image conteneur.
Tarifs
Utilisez la calculatrice de prix Azure pour estimer les coûts des ressources Azure.
Consultez cet exemple de l’implémentation précédente.
Contributeurs
Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.
Auteur principal :
- Marcus Tee | Technical Strategy & Roadmap
Étapes suivantes
- Créer l’architecture d’applications modernes dans Azure
- Implémenter une sécurité réseau dans Azure
- Livre de recettes Informatique Serverless Azure
Ressources associées
Parcourez les architectures suivantes :
Aide connexe :