Qu’est-ce qu’Azure Container Apps ?

Azure Container Apps est un service d’Azure qui a été officiellement annoncé lors de l’événement Microsoft Ignite 2021 et est devenu GA en mai 2022.

Azure Container Apps est un service de plateforme d’applications « Serverless » qui permet le déploiement d’applications conteneurisées sans la gestion de l’infrastructure sous-jacente, en s’appuyant sur Azure Kubernetes Services (AKS), tout en simplifiant leur orchestration.

 

Azure Container Apps cible principalement les scénarios suivants :

 

• Applications web et API
• Traitement de tâches en arrière-plan
• Microservices
• Applications basées sur des événements

 

Azure Container Apps est packagé avec KEDA (Autoscaler) et ENVOY (edge HTTP proxy)
Les applications construites sur Azure Container Apps peuvent évoluer dynamiquement en fonction des caractéristiques suivantes :

 

• HTTP traffic
• Event-driven processing
• CPU or memory load
• Any KEDA-supported scaler

 

En complément, Azure Container Apps propose une version managée des API Dapr, incluant « Service to Service calls », « Pub/Sub », « Event Bindings », « State Stores » et « Actors ». Consultez la Roadmap de Microsoft pour suivre les évolutions.

Concepts clés d’Azure Container Apps : Plans et Environnements

Plans Azure Container Apps : Consumption vs Dedicated

Plan « Dedicated »:

Le plan dédié consiste en une série de profils de charge de travail qui vont du profil de consommation par défaut à des profils qui disposent d’un matériel dédié personnalisé pour des besoins de calcul spécialisés.

Plan « Consumption »:

Le plan Consommation propose une architecture « serverless » qui permet à vos applications d’évoluer à la demande, y compris une échelle jusqu’à zéro, facturant uniquement les applications actives. Ce plan est idéal lorsque des exigences matérielles spécifiques ne sont pas nécessaires.

 

Pour aller plus loin https://learn.microsoft.com/en-us/azure/container-apps/workload-profiles-overview

Comprendre les environnements Azure Container Apps : réseau, logs et VNet

Un environnement Container Apps est un périmètre sécurisé autour d’une ou plusieurs applications et tâches conteneurisées.

Il est associé à un réseau virtuel qui, par défaut, est géré automatiquement par Azure Container Apps, mais peut être personnalisé avec son propre Vnet/Subnet pour des configurations avancées (bastion, Private Endpoint, etc.).

Si plusieurs applications conteneurisées se trouvent dans le même environnement, elles partagent le même réseau virtuel et centralisent leurs journaux vers une destination commune.

 

Le « Container Apps Environment » désigne l’infrastructure (AKS) sur laquelle sont déployées les applications conteneurisées (uniquement sous Linux).

 

Lors du déploiement d’un « Container Apps Environment », les éléments suivants sont configurés :

 

• La « zone redundancy » (uniquement si une intégration avec un vNet est présente)
• Les Workload profiles (plans)
• Le monitoring pour les Logs (Azure Log Analytics / Azure Monitor / sans stockage de Logs)
• Le Networking, en fonction du besoin d’intégrer un Virtual Network ou d’exposer la « Virtual IP » à l’extérieur (Internal/External)

 

En fonction de vos besoins, il est possible d’utiliser un ou plusieurs environnements Container Apps.

 

Scénarios d’utilisation : quand utiliser un ou plusieurs environnements Azure Container Apps ?

 

Utiliser un seul environnement est pertinent pour :

• Regrouper différentes applications sur le même VNet.
• Partager la configuration Dapr entre plusieurs applications.
• Centraliser les logs.

 

Opter pour plusieurs environnements est recommandé pour :

• Isoler les ressources (compute, mémoire, etc.).
• Séparer les API Dapr.
• Garantir une isolation complète (équipe, environnements de test, production, etc.).

 

Voici les propriétés d’un « Container Apps Environment » (Az CLI):

Quelques informations intéressantes à notifier :

• La « staticIp » (la « Virtual IP » )
• Les workloadProfiles
• Le « defaultDomain » (blabla-aleatoire.region.azurecontainerapps.io)
• Etc…

Chaque conteneur dans l’environnement aura le nom nomduconteneur.labla-aleatoire.region.azurecontainerapps.io

Déploiement d’un Environnement Azure Container Apps dans un VNet

Exemple de code pour un déploiement dans un VNet existant avec accès interne uniquement :

• Création d’un « resource group »
• Création d’un Vnet et trois Subnet (dont un avec un « Delegate to Microsoft.App/environments)
• Création d’un « Log Analytics workspace »
• Récupération de l’ID et d’une Key du « Log Analytics workspace »
• Récupération de l’ID du subnet pour joindre le « Container Apps Environment »
• Création du « Container Apps Environment » (https://learn.microsoft.com/en-us/cli/azure/containerapp/env?view=azure-cli-latest#az-containerapp-env-create)

 

À la fin de l’exécution, les ressources suivantes devraient être créées :

• Internal Load Balancer visible dans un resource group nommé : ME_env-aca_rg-aca-az-cli_francecentral
• Log Analytics workspace
• VNet/Subnet
• Container Apps Environment

N’est visible dans la console que :

• « l’internal loadbalancer » dans un « resource group » ME_env-aca_rg-aca-az-cli_francecentral (cela doit parler au Jedi d’AKS 🙂
• Le Log Analytics workspace
• vNet/Subnet
• Container Apps Environment

 

Dans cette configuration, seuls les conteneurs hébergés dans les sous-réseaux subnet-main et subnet-pe ou ceux se trouvant dans le même environnement auront accès au réseau. Les deux « node pools » ne sont pas visibles !

Gestion des Conteneurs avec Azure Container Apps

Azure Container Apps gère pour vous les détails de « Kubernetes » et de l’orchestration des conteneurs. Les conteneurs d’Azure Container Apps peuvent utiliser le moteur d’exécution, le langage de programmation ou le runtime de développement de votre choix.

Azure Containers Apps supporte uniquement les conteneurs :

• Toute image de conteneur x86-64 (linux/amd64) basée sur Linux
• Conteneurs provenant de n’importe quel registre de conteneurs public ou privé
• Conteneurs « sidecar » et « init » Les limitations d’Azure Container Apps : https://learn.microsoft.com/en-us/azure/container-apps/quotas

 

Lorsqu’on utilise un plan de consommation, le total de CPU et de la mémoire allouée à tous les conteneurs d’une application de conteneur doit correspondre à l’une des combinaisons suivantes :

 

Pour information, la limitation est de 100 coeurs par environnement. (avec les réplicas)

 

Méthodes de déploiement pour Azure Container Apps

Options de déploiement disponibles

Vous pouvez déployer des applications Azure Container Apps via plusieurs sources :

• Image de conteneur (portail ou Command line)
• Code local
• Dépôt GitHub
• Environnement de développement (IDE) tel que Visual Studio, Visual Studio Code, avec l’extension Azure Account, Azure Container Apps, Docker, etc.
• Fichier artefact (fichier JAR/Maven), cette fonctionnalité est actuellement en preview.

Déploiement via « Code Local » et « Repo GitHub »

Si vous choisissez de déployer en mode « Code Local » ou depuis un dépôt GitHub, il est possible de déployer une application sans utiliser de fichier Dockerfile en utilisant la commande az containerapp up. Cette commande est compatible avec les langages suivants : .NET, Node.js, PHP et Python. L’image est générée à l’aide de l’outil Buildpacks.

Voici un exemple de code (proposé dans la doc Microsoft) az containerapp up avec le code (node.js) en local :
https://learn.microsoft.com/en-us/azure/container-apps/containerapp-up

Ce code déploie :

• Un « Resource Group »
• Un « Log Analytics workspace »
• Un « Container Apps Environment »
• Un « Container App »
• Une ressource cachée microsoft.app/builders pour l’image générée par Buildpacks.

 

 

Exemple de code ‘Az CLI’ pour le déploiement d’une application depuis une image publique avec la commande az containerapp create

Ce code déploie :

• Un « resource group »
• Un « Container Apps Environment » sans « Log Analytic workspace »
• Une « Azure Container Apps » depuis une image publique et exposée sur Internet

Il st également possible de déployer une application en utilisant un fichier YAML.

https://learn.microsoft.com/en-us/azure/container-instances/container-instances-reference-yaml
L’équivalent de la commande ci-dessus.

Voici le fichier YAML à créer :

 

Pour aider la construction des fichiers YAML de configurations, il est possible d’exporter une configuration dans un fichier avec la formule suivante :

az containerapp show \

–name $CONTAINERAPP_NAME \

–resource-group $RESOURCE_GROUP_NAME \

–output yaml > app.yaml

Déploiement via le portail Azure

Le déploiement à partir du portail Azure implique deux étapes principales :

1. Création de l’environnement Container Apps
2. Création de la Container App

 

Rechercher « Container App » dans la marketplace d’Azure

 

Classique : Abonnement ; Resource Group ; nom de l’application

Dans cet exemple, l’image est stockée dans un Azure Container Registry.

Si il n’y a pas d’image de conteneur, deux choix sont possibles :

• Code dans un repo Github (image générée dans un Workflow Github Action avec Builpacks)
• Local artefact (preview) uniquement .jar & .war

 

 

Par la suite, cliquez sur « Create new » pour créer un Container Apps Environment.

 

 

Ajoutez un nom pour la ressource « Container Apps Environment » si vous souhaitez de la redondance de zone. (Uniquement dans un environnement de vNet)

 

Choix des Workload Profiles : Consumption vs Dedicated

Par défaut, l’environnement Azure Container Apps utilise un plan « Consumption ». Si vous optez pour un plan « Dedicated », il est nécessaire de définir un Workload Profile Name avec un Workload Profile Size (utilisant des profils de VM de la série D & E), ainsi que de paramétrer le Autoscaling Instance Count Range (entre 0 et 50 instances).

 

Deux possibilités pour le « Monitoring »

Par défaut les logs sont envoyés dans « Log Analytics workspace » de votre choix ou possibilité d’en créer un.

Il est possible d’envoyer les logs vers :

• un compte de stockage
• un event Hubs
• des solutions tiers (Datadog; Elastic; Logs.io; ….
• Log Analytics workspace)

Les « Azure Container Apps » s’exécutent dans un environnement, avec son propre réseau virtuel (VNet).

Par défaut, votre environnement Container App est créé avec un VNet qui est automatiquement généré pour vous. Pour un contrôle plus fin de votre réseau, vous pouvez fournir un VNet existant lorsque vous créez un environnement. Une fois que vous avez créé un environnement avec un VNet généré ou existant, le type de réseau ne peut plus être modifié.

Choisir un VNet existant si vous avez besoin de plus de fonctionnalités de mise en réseau Azure, telles que :

• Intégration avec Application Gateway
• Groupes de sécurité réseau
• Communication avec des ressources derrière des points d’extrémité privés dans votre réseau virtuel
• etc…

 

Choix de l’Adresse IP Virtuelle (VIP) : Interne vs Externe

Lors de la configuration du réseau, il est possible de créer un VNet via l’assistant Azure, mais cela limite le block d’adressage à 10.0.0.0/16. Il est recommandé de créer le VNet/Subnet en amont pour plus de flexibilité. (voir les prérequis réseau ici.)

Internal : un Load Balancer est déployé et visible uniquement en interne.

External : une adresse IP publique et un Load Balancer sont créés pour l’accès externe.

Comme pour le service AKS, vous pouvez personnaliser le nom du Resource Group pour éviter le format par défaut

« ME_nomdeenvironnement_nomduresourcegroup_region » pour le « resource group » des resources, il est maintenant possible d’attribuer un nom à ce dernier.
Pour le choix « internal » sera déployé et visible uniquement un « load balancer ».
Pour le choix « external » sera déployé et visible uniquement une « Public IP address » et un « Load balancer ».

 

 

Une fois l’environnement configuré, vous pouvez passer au Container App lui-même.

 

Dans cet exemple, l’image est stockée dans un Azure Container Registry. Pour accéder à ce registre, l’option Admin Credentials doit être activée dans les paramètres.

Il est également possible d’aller chercher des images dans des « public registry » (ex:Docker Hub) ou dans une « private registry » (Registry login server/Registry user name/Registry password)

 

Dans les « Advanced settings » possibilité:

• Faire de l’override ENTRYPOINT » de l’image
• Faire de l’override CMD » de l’image
• Ajouter des fonctionnalités supplémentaires en fonction du language applicatif (Java/.NET/Generic). Par exemple, pour JAVA, on pourra récupérer les « Java Virtual Machine (JVM) metrics »
• Récupérer les « Workload Profils » (dedicated plan / Consumption plan) et paramétrer les CPU/Mémoire des « Consumption plan »
• D’ajouter des variables d’environnement (cle/valeur), par exemple connexion base de données

 

 

• Dans cet exemple, nous sommes dans un contexte où nous n’avons pas de vNet dédier à notre environnemnt, en activant l’ingress (flux entrant) et en activant « Accepting traffic from anywhere ». Notre « App Container » ne sera uniquement accessible en HTTP (TCP n’est disponible que dans les environnements Container Apps configurés avec un VNet personnalisé)
• Le transport est défini sur (HTTP/1 ou HTTP/2)
• Pour « Insecure connections », l’ingress accepte par défaut les requêtes HTTP sur le port 80 et sont automatiquement redirigées vers HTTPS sur le port 443.
• Les connexions non sécurisées via HTTP (port 80) sont redirigées vers HTTPS (port 443), sauf si désactivé.
  Pour le « Target port », il s’agit du port sur lequel le conteneur écoute et reçoit du trafic
• Pour la « Session affinity», les requêtes HTTP d’un même client sont acheminées vers la même « replica » (géré par les « cookies HTTP »)
• Enfin, il est possible d’exposer des ports TCP supplémentaires pour permettre aux applications d’accepter des connexions TCP sur plusieurs ports.

 

 

Guide de déploiement Azure Container Apps : exemple avec VNet et accès interne.

Comme on a pu le voir ci-dessus, il y a plusieurs méthodes de déploiement :

• Portail Azure
• IDE avec les bonnes extensions (Visual Studio / Visual Studio Code)
• Code en local ou dans un « Repository » (GitHub)
• En « Command line »
  • Azure CLI
  • Azure PowerShell
  • Azure Developer CLI (AZD https://learn.microsoft.com/fr-fr/azure/developer/azure-developer-cli/)
• Infrastrucure As Code
  • Template ARM / Bicep (ex: Hello-World ./Bicep)
  • Terraform (ex: Hello-World Terraform ./Terraform)

 

Pour déployer des infrastructures Azure Container Apps en AZ CLI, votre CLI doit être à jour.Pour la mettre à jour et installer les extensions (Microsoft.App & Microsoft.OperationalInsights) :

Script de déploiement automatisé

En bonus, voici un script d’exemple (./Az-Cli/aca-network.sh) pour déployer automatiquement

• Un « resource group »
• Un réseau
  • vNet
  • Trois subnets dont un en « delegated Microsoft.App/environments » pour le « Container Apps Environment »
• PosgreSQL
  • Serveur postgres flexible-server
  • Une base
  • Deux tables
  • Private endpoint (subnet pe)
  • Private-dns zone avec les enregistrements
• Azure Container Apps Environment
  • Log Analytic workspace
  • Environmment dans le subnet
  • Private-dns zone avec les enregistrements
• Azure Container Registry
  • Container registry
  • Build & push d’une image (./Src)
  • Managed Identity
  • Assign Identity -> Container registry
  • Assign Role AcrPull
• Azure Container App
  • Secrets / variables d’environnement (connexion base de données)

Testons la plateforme :

Pour tester l’application :

• Dans la console Azure, il faut aller dans la « Container App », dans la barre de gauche
  • Monitoring -> Log StreamL’application est bien connecté à la base

• • Monitoring -> ConsoleL’application fonctionne, on récupère les données et on peut incrementer (command curl)
  • Depuis la VM de rebond

Avant de se connecter sur la VM de rebond, il faut récupérer et copier l’ « Application Url »

Depuis la VM de rebond

 

• Test la résolution de nom
• Test de l’application (remarque, l’application répond uniquement en https !)

 

Pour conclure

Microsoft propose de nombreuses options permettant aux équipes de créer et de déployer des applications cloud natives et conteneurisées sur Azure. Il n’existe pas de solution parfaite pour tous les cas d’utilisation et toutes les équipes.

Azure propose une large gamme d’options pour créer et déployer des applications cloud natives. Bien qu’il n’y ait pas de solution universelle adaptée à tous les cas, Azure Container Apps se distingue comme une solution entièrement managée pour les microservices, parfaite pour les équipes souhaitant une alternative légère à Kubernetes sans la complexité de gestion des clusters.

Dans cet article, nous n’avons vu qu’une toute petite partie des fonctionnalités de « Azure Container Apps ». Pour le prochain article de cette série nous verrons :

 

• Azure Function sur « Azure Container Apps »
• Container App Job
• Gestion des révisions
• Gestion des replicas / Scale
• Observabilité
• L’authentification (identity provider)
• Les secrets
• Dapr
• Networking / Ingress
• Continuous deployment
• Etc…