Table of Contents

Azure Container Apps (ACA) est une plateforme de conteneur entièrement gérée et sans serveur sur Microsoft Azure qui élimine les complexités de l'orchestration Kubernetes tout en offrant des capacités de mise à niveau puissantes, des capacités axées sur les événements et des modèles d'application intégrés. Il est conçu pour le développement d'applications modernes où les équipes ont besoin de déployer des microservices, des tâches de fond et des terminaux API sans fournir ou gérer de machines virtuelles, des clusters ou des orchestres.

Quelles sont les applications de conteneurs Azure?

Azure Container Apps fonctionne comme un environnement géré pour exécuter des charges de travail conteneurisées, assis entre Azure App Service (pour les applications web) et Azure Kubernetes Service (AKS) (pour le contrôle complet des grappes). Il fournit une expérience Kubernetes simplifiée sans nécessiter une interaction directe avec le serveur API de cluster. ACA utilise Kubernetes sous le capot mais en retire la complexité opérationnelle, ce qui le rend idéal pour les équipes qui veulent des avantages de conteneur – portabilité, cohérence, isolement des ressources – sans gérer les nœuds, les pods ou les balanceurs de charge.

Chaque application de conteneur fonctionne dans un environnement basé sur la révision où vous pouvez déployer plusieurs révisions et gérer le partage du trafic. La plate-forme prend en charge les architectures animées par des événements grâce à l'intégration intégrée avec KEDA[ (Kubernetes Event‐Driven Autoscaling) et Dapr[ (Distributed Application Runtime) pour construire des applications résistantes et basées sur les microservices.

Caractéristiques et capacités de base

Architecture sans serveur et calibrage automatique

Le modèle ACA= sans serveur élimine le besoin de fournir et de gérer des VM ou des nœuds de cluster. La plate-forme s'échelle automatiquement en fonction du trafic HTTP, des déclencheurs d'événements (p. ex., profondeur de file d'attente, horaires de cron) ou des mesures personnalisées via des scalers KEDA. L'échelle peut être configurée par révision et vous pouvez définir des nombres de répliques min et max.

Soutien intégré au Dapr

Dapr fournit un ensemble de blocs de construction (gestion d'état, pub/sub, invocation de service, secrets, fixations) qui simplifient les applications distribuées de construction. ACA intègre Dapr au niveau de la plateforme, de sorte que vous pouvez l'activer par Container App sans gérer un sidecar ou une infrastructure séparée.

Gestion des révisions et séparation du trafic

Container Apps utilise un modèle de révision similaire à Azure App Service : chaque changement de code ou de configuration crée une nouvelle révision, tandis que les anciennes révisions restent disponibles. Vous pouvez définir des pourcentages de trafic parmi les révisions pour effectuer des déploiements bleu-vert, des tests A/B ou des déploiements échelonnés. Les révisions peuvent être actives, désactivées ou utilisées pour le retour, vous donnant un contrôle fin sur la sécurité du déploiement.

Ingress et domaines personnalisés

Chaque application Container reçoit un paramètre HTTPS unique (par exemple ). Vous pouvez assigner des domaines personnalisés avec des certificats SSL/TLS, configurer l'entrée pour permettre le trafic interne (VNet) ou externe, et définir des règles de trafic pour le routage basé sur le chemin à travers plusieurs applications.

Environnement et mise en réseau

Les applications conteneur résident dans un environnement Container Apps Environment, qui agit comme une frontière sécurisée autour de vos applications. L'environnement prend en charge l'intégration VNet (environnements externes ou internes), permettant la communication privée entre les applications, les bases de données et d'autres services Azure. Vous pouvez également utiliser des terminaux privés et des groupes de sécurité réseau pour contrôler le trafic.

Identité gérée et secrets

ACA prend en charge les identités gérées Azure, permettant à vos conteneurs d'authentifier les services Azure (Key Vault, Storage, SQL Database) sans identifiants de codage dur. Les secrets peuvent être référencés directement depuis Azure Key Vault, et les variables d'environnement ou les volumes peuvent être injectés à l'exécution.

Déployer des applications de conteneur Azure

Déployer une application Container implique plusieurs étapes, de la conteneurisation de votre application à la configuration de l'environnement et des règles de mise à l'échelle.

Étape 1: Préparez et poussez votre image de conteneur

Commencez par créer un fichier Docker pour votre application (p. ex. .NET, Node.js, Python, Go). Assurez-vous que l'image est optimisée (construits multi-étapes, images de base minimales). Poussez l'image vers un registre de conteneurs – idéal Registre de conteneurs Azure (ACR) pour la proximité et l'intégration. Si vous utilisez un registre public comme Docker Hub, ACA peut aussi tirer de là, mais ACR offre des tirages plus rapides dans le réseau Azure.

Étape 2: Créer un environnement d'application de conteneur

Avant de déployer une application, vous devez créer un environnement d'applications de conteneurs. Cela peut être fait via le portail Azure, Azure CLI, Bicep, ARM ou Terraform. L'environnement définit la région, le réseau virtuel (facultatif), et si elle est interne ou publique. Pour la production, permettre l'intégration VNet pour sécuriser le trafic sortant et utiliser des paramètres privés. Exemple commande CLI:

az containerapp env create --name MyEnvironment --resource-group MyRG --location eastus

Étape 3: Définir et déployer l'application de conteneur

Utilisez la commande pour définir l'application, en référenceant l'image, les variables d'environnement, les secrets, les paramètres d'entrée et la configuration de mise à l'échelle.

az containerapp create --name myapp --resource-group MyRG \
 --environment MyEnvironment --image myregistry.azurecr.io/myapp:v1 \
 --target-port 8080 --ingress external --query properties.configuration.ingress.fqdn

Cela crée une révision et expose l'application via un FQDN généré automatiquement. Vous pouvez ensuite mettre à jour l'application avec de nouvelles images, variables d'environnement ou règles de mise à l'échelle en utilisant .

Étape 4: Configurer les secrets et gérer l'identité

Conservez les valeurs sensibles (chaînes de connexion, clés API) dans Azure Key Vault et référez-les comme des secrets dans votre application Container. Activez une identité gérée assignée ou assignée par l'utilisateur afin que votre application puisse authentifier Key Vault et d'autres ressources Azure sans identifiant en code.

Étape 5 : Définir des règles de calibrage

Configurer l'auto-scalage en fonction des requêtes HTTP, du CPU, de la mémoire ou des sources d'événements personnalisés (par exemple, files d'attente Azure Service Bus, Kafka, RabbitMQ). Utilisez les scalders KEDA pour déclencher l'échelle à partir de systèmes externes.

az containerapp update --name myapp --resource-group MyRG \
 --min-replicas 0 --max-replicas 10 \
 --scale-rule-name queue-scaler --scale-rule-type azure-queue \
 --scale-rule-auth connection=queue-connection-string \
 --scale-rule-metadata "queueName=myqueue" "queueLength=5"

Gestion des applications de conteneurs Azure

Une fois déployé, la gestion continue implique le suivi, la mise à jour et l'amélioration de l'échelle et de la sécurité.

Stratégies de gestion et de déploiement des révisions

Utilisez le modèle de révision pour mettre à jour votre application sans temps d'arrêt. Lorsque vous poussez une nouvelle image ou modifiez la configuration, ACA crée une nouvelle révision. Par défaut, tout le trafic va à la dernière révision. Pour implémenter un déploiement bleu vert:

  1. Mettre à jour l'application avec une nouvelle révision (en maintenant l'ancienne active).
  2. Envoyer un petit pourcentage de trafic à la nouvelle révision.
  3. Augmenter progressivement le trafic tout en surveillant les erreurs et la latence.
  4. Si stable, routez le trafic 100% vers la nouvelle révision et désactivez l'ancienne.

Cette approche minimise les risques et permet un retour rapide en arrière en retraçant le trafic à une révision précédente.

Surveillance avec Azure Monitor et Log Analytics

L'intégration avec Azure Monitor est automatique. Vous pouvez afficher les métriques (request count, CPU, memory, réplique count) dans le portail Azure. Pour les journaux détaillés, configurez votre Container App pour envoyer stdout/stderr et les journaux système dans un espace de travail Log Analytics. Utilisez les requêtes Kusto pour détecter les anomalies, déboguer les erreurs ou analyser les profils de trafic.

Auto-tarification dans la production

Bien que l'auto-échelle par défaut fonctionne bien pour de nombreux scénarios, les applications de production nécessitent souvent des scalaires KEDA personnalisés. Exemples courants : l'échelle basée sur le compte de messages Azure Service Bus, Azure Event Hubs en retard, ou une métrique Prométhée personnalisée. Assurez-vous de définir des répliques min et max appropriées pour gérer le trafic de base et la capacité d'éclatement.

Mise à jour des conteneurs et retour en roulis

Container Apps prend en charge les mises à jour zéro-défaut par l'activation de la révision. Lorsque vous déployez une nouvelle image, la nouvelle révision est lancée en parallèle avec l'ancienne. Une fois la nouvelle révision en bonne santé, le trafic est redirigé. Si les contrôles de santé échouent, ACA peut automatiquement revenir.

Pratiques exemplaires en matière de sécurité

Identités gérées pour Azure Resources

Activer l'identité gérée assignée par le système pour votre application Container. Cela permet à l'application d'accéder à la faille clé, au stockage et aux bases de données sans stocker les identifiants dans les variables d'image ou d'environnement conteneur.

Gestion secrète avec la faille clé

Ne jamais avoir de secret de code dur. Conservez toutes les données sensibles dans Azure Key Vault et référez-les dans votre configuration de Container App comme références secrètes. ACA les injecte automatiquement comme variables d'environnement ou montures de volume à l'exécution.

Sécurité du réseau

Pour les services internes, déployez votre environnement Container Apps avec un trafic externe désactivé. Utilisez l'intégration VNet pour limiter le trafic sortant/in entrant via des groupes de sécurité réseau. Pour le trafic entrant à partir de terminaux publics, activez la restriction IP sur l'entrée ou utilisez Azure Front Door ou API Management devant.

Sécurité de l'image du conteneur

Utilisez des images de base fiables à partir du registre d'artifacts de Microsoft ou d'autres sources sécurisées. Scannez des images pour détecter les vulnérabilités en utilisant Microsoft Defender for Containers ou ACR=s. Signez des images pour assurer l'intégrité.

Conformité et certification

Azure Container Apps hérite des certifications de conformité Azure (SOC, PCI DSS, HIPAA, ISO). Assurez-vous que votre environnement est déployé dans une région qui répond aux exigences de résidence des données. Utilisez la politique Azure pour faire respecter la gouvernance (par exemple, pour exiger l'injection VNet ou des registres d'images spécifiques).

Optimisation des coûts

Consommation et plan dédié

ACA offre deux niveaux de prix : Consommation (payer par vCPU‐seconde et mémoire‐seconde) et Dédiée (réservé vCPU et mémoire). La consommation est la meilleure pour les charges de travail variables ou à faible trafic, tandis que Dediced fournit un coût et des performances prévisibles pour les applications de production à l'état stable.

Auto-scalage et mise à zéro

Configurez des répliques minimales à 0 pour les tâches de fond ou les API avec un trafic imprévisible. Cela garantit aucun coût de calcul lorsque vous êtes au ralenti. Pour les chemins critiques qui nécessitent une réponse instantanée, définissez un minimum de 1 pour éviter les démarrages à froid.

Cas réservés et régimes d'épargne

Pour les régimes dédiés, engagez-vous à des cas réservés d'un an ou de trois ans pour économiser jusqu'à 40 % par rapport à la rémunération au fur et à mesure. Les régimes d'épargne Azure s'appliquent également au calcul des applications de container.

Images de conteneur efficaces

Utilisez des images de base alpines ou distroles, nettoyez les artefacts de construction et cachez les couches avec sagesse. N'entreposez que le temps d'exécution de votre image, gardez les outils de construction dans une étape de construction séparée. Cela améliore également le temps de démarrage et la vitesse de mise à l'échelle.

Intégration avec d'autres services Azure

Registre des conteneurs Azure

Utilisez ACR comme registre privé pour les applications Container. Il supporte la géo-réplication, la numérisation d'images et la signature d'objets. Activez le compte `admin` d'ACR=s ou utilisez l'identité gérée pour authentifier les tirages en toute sécurité.

Lignes de conduite CI/CD avec Azure DevOps et actions GitHub

Automatiser les déploiements en utilisant les tâches CLI Azure dans Azure DevOps ou GitHub Actions. Vous pouvez construire une image, pousser vers ACR et mettre à jour la révision de l'application conteneur dans un seul pipeline. Exemple GitHub Actions étape du workflow:

- name: Deploy to Azure Container Apps
 run: az containerapp update --name myapp --resource-group MyRG --image myacr.azurecr.io/myapp:latest

Utiliser les créneaux de déploiement (révision du trafic fractionné) pour mettre en scène et valider les changements avant le déploiement complet.

Intégration d'événements

Bâtir le Dapr , avec Azure Service Bus ou Event Hubs, pour découpler les microservices. Configurer les scalpers KEDA pour déclencher une mise à l'échelle en fonction de la profondeur de la file. Ce modèle est excellent pour le traitement des commandes, la notification ou les workflows par lots.

Meilleures pratiques pour le développement d'applications modernes

  • Adoptez une architecture de microservices qui s'harmonise avec le modèle de révision et d'entrée de l'ACA. Chaque service devrait avoir sa propre application Container avec une échelle et un cycle de vie indépendants.
  • Mise en oeuvre des pipelines CI/CD[ qui construisent, testent, scannent et déploient automatiquement. Utilisez le code infrastructure-as (Bicep/Terraform) pour définir les environnements, en assurant la répétabilité.
  • Prioriser la sécurité[ dès le début : utiliser les identités gérées, les références de la faille clé, l'intégration VNet et la numérisation d'images.
  • Optimisez le coût[ en choisissant le bon plan, en définissant des répliques raisonnables min/max et en utilisant la capacité réservée pour des charges de travail stables.
  • Activer l'observation[ tôt : envoyer les journaux à Log Analytics, activer Application Insights et mettre en place des alertes sur les taux d'erreur, demander la latence et compter les répliques.
  • Utilisez Dapr et KEDA pour traiter les préoccupations transversales : gestion de l'état, récupérations, pub/sous-scale et échelles axées sur les événements, ce qui réduit la plaque de chaudière et améliore la résilience.
  • Conception pour l'échelle à zéro si votre charge de travail le permet. Les démarrages à froid sont généralement inférieurs à deux secondes pour les conteneurs simples; vous pouvez atténuer avec des sondes de santé et des répliques min appropriées.

En suivant ces pratiques et en tirant parti des applications de conteneur Azure, sans serveur, les équipes peuvent construire et exploiter des applications modernes qui sont évolutives, sécurisées et rentables. La plateforme réduit les frais généraux opérationnels tout en donnant aux développeurs la liberté d'utiliser n'importe quel langage, cadre ou outil qui fonctionne dans un conteneur.

Pour en savoir plus sur les modèles d'application distribués avec Dapr, consultez la documentation Dapr. Pour des exemples d'auto-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------