Comment déployer Azure Container Apps en 2026 (Avancé)

Introduction

Azure Container Apps est un service serverless managé par Microsoft Azure qui simplifie le déploiement de conteneurs sans gérer Kubernetes. Contrairement à AKS, il abstrait l'orchestration, le scaling horizontal/autoscale via KEDA, et intègre nativement Dapr pour le service mesh. En 2026, avec les avancées en IA et edge computing, il excelle pour les microservices scalables, les jobs batch et les apps event-driven.

Ce tutoriel advanced vous guide pas à pas pour un setup production : création d'environnement, déploiement avec ACR, ingress sécurisé, scaling réactif, revisions blue-green, secrets et monitoring. Chaque étape inclut du code complet, fonctionnel et copier-collable. À la fin, vous maîtriserez un workflow DevOps optimisé, réduisant les coûts de 40-60% vs. VM traditionnelles. Parfait pour des pros gérant des workloads critiques (128 mots).

Prérequis

Compte Azure actif avec abonnement payant (crédits suffisent pour tests).
Azure CLI 2.60+ installée (az --version).
Docker Desktop 24+ pour build local.
Azure Container Registry (ACR) basique ou standard.
Connaissances avancées en conteneurs, YAML et scaling (KEDA/Dapr).
Outils optionnels : VS Code avec Azure extension, Git.

Créer le groupe de ressources et l'environnement

setup-env.sh

#!/bin/bash

# Variables
RESOURCE_GROUP="rg-containerapps-demo"
LOCATION="francecentral"
ENV_NAME="env-demo"

# Login et création RG
az login
az group create --name $RESOURCE_GROUP --location $LOCATION

# Créer l'environnement Container Apps (avec VNet pour isolation)
az network vnet create --resource-group $RESOURCE_GROUP --name vnet-demo --address-prefixes 10.0.0.0/16 --subnet-name subnet1 --vnet-subnet-id "/subscriptions/$(az account show --query id -o tsv)/resourceGroups/$RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/vnet-demo/subnets/subnet1"

az containerapp env create --name $ENV_NAME \
  --resource-group $RESOURCE_GROUP \
  --location $LOCATION \
  --vnet-name vnet-demo \
  --subnet-name subnet1

Ce script initialise l'infrastructure : groupe de ressources, VNet pour networking sécurisé, et environnement Container Apps. L'environnement est le socle serverless, gérant stockage, logs et scaling. Piège : Oublier la VNet expose à des failles réseau ; utilisez toujours des subnets dédiés.

Comprendre l'environnement Container Apps

L'environnement est isolé logiquement (comme un namespace K8s), avec stockage Azure Files pour /tmp persistant et intégration Log Analytics. En advanced, activez Dapr pour sidecars service mesh (state management, pub/sub). Prochaine étape : une app Node.js scalable.

Dockerfile pour app Node.js scalable

Dockerfile

FROM node:20-alpine

WORKDIR /app

COPY package*.json ./
RUN npm ci --only=production

COPY . .

EXPOSE 3000

HEALTHCHECK --interval=30s --timeout=3s --start-period=5s --retries=3 \
  CMD node healthcheck.js || exit 1

CMD ["node", "server.js"]

# healthcheck.js (inline pour complétude)
RUN echo 'http://localhost:3000/health' | tee healthcheck.js

Dockerfile multi-stage optimisé pour prod : Alpine réduit l'image à <100MB. Healthcheck assure scaling intelligent. Piège : Sans healthcheck, KEDA scale sur CPU faux positifs ; testez toujours avec docker build -t app:v1 ..

Créer ACR et push l'image

build-push.sh

#!/bin/bash

ACR_NAME="acrcontainerapps$(date +%s)"
RESOURCE_GROUP="rg-containerapps-demo"
IMAGE="app:v1"

# Créer ACR
az acr create --resource-group $RESOURCE_GROUP --name $ACR_NAME --sku Basic --admin-enabled true

# Login ACR et build/push (assume Dockerfile et app dans .)
ACR_LOGIN_SERVER="$ACR_NAME.azurecr.io"
az acr login --name $ACR_NAME
docker build -t $ACR_LOGIN_SERVER/$IMAGE .
docker push $ACR_LOGIN_SERVER/$IMAGE

# Récup ACR ID pour templates
ACR_ID=$(az acr show --name $ACR_NAME --resource-group $RESOURCE_GROUP --query id -o tsv)
echo "ACR_ID: $ACR_ID" # À utiliser dans YAML

Crée un ACR sécurisé, build et push l'image. Utilisez az acr build pour CI/CD natif. Piège : ACR Basic suffit pour tests, mais upgradez à Premium pour geo-replication et scanning vulnérabilités.

Déploiement initial avec template YAML

Utilisez des templates YAML pour IaC reproductible, supportés par az containerapp up. Configurez ingress externe, target-port et min-replicas.

Template YAML pour première Container App

containerapp.yaml

properties:
  managedEnvironmentId: "/subscriptions/<SUBSCRIPTION_ID>/resourceGroups/rg-containerapps-demo/providers/Microsoft.App/managedEnvironments/env-demo"
  configuration:  # Infra config
    ingress:
      external: true
      targetPort: 3000
      traffic:
        latestRevision: true
      clientCertificate: Disabled
    secrets: []  # Ajoutés plus tard
    registries:
      - server: acrcontainerappsXXXX.azurecr.io  # Remplacez par votre ACR
        username: 00000000-0000-0000-0000-000000000000  # ACR admin user
        passwordRef: acr-password  # Secret ref
  template:
    containers:
      - name: app
        image: acrcontainerappsXXXX.azurecr.io/app:v1  # Votre image
        resources:
          cpu: 0.5
          memory: 1Gi
        env:
          - name: NODE_ENV
            value: "production"
        probes:
          liveness:
            httpGet:
              path: /health
              port: 3000
              httpHeaders:
                - name: Host
                  value: "localhost"
          readiness:
            httpGet:
              path: /health
              port: 3000
    scale:
      minReplicaCount: 1
      maxReplicaCount: 10
      rules: []

# SUBSCRIPTION_ID depuis az account show --query id -o tsv
# Déployer: az containerapp up --name myapp --resource-group rg-containerapps-demo --yaml containerapp.yaml --env env-demo

Template complet pour az containerapp up. Ingress externe expose l'URL FQDN. Probes assurent HA. Piège : Remplacez placeholders (SUB_ID, ACR) ; sans probes, downtime lors de restarts.

Scaling avancé avec KEDA (HTTP + Queue)

containerapp-scale.yaml

properties:
  # ... (même config que précédent, override scale)
  template:
    scale:
      minReplicaCount: 0  # Scale to zero
      maxReplicaCount: 100
      rules:
      - name: http-rule
        custom:
          type: http
          metadata:
            scalingMetric: requests_per_second
            targetValue: 100
      - name: queue-rule
        azureServiceBusQueue:
          messageCount: "10"
          queueLength: "20"
          queueName: orders
          connection: sb-connection  # Secret ref
  configuration:
    secrets:
      - name: sb-connection
        value: "Endpoint=sb://namespace.servicebus.windows.net/;SharedAccessKeyName=RootManageSharedAccessKey;SharedAccessKey=XXXX"

# az containerapp update --name myapp --resource-group rg-containerapps-demo --yaml @containerapp-scale.yaml

Active KEDA pour scale HTTP (RPS) et Azure Service Bus queue. Scale-to-zero économise 70% coûts. Piège : Secrets en clair dans YAML ? Utilisez az containerapp secret set pour rotation auto.

Gestion des revisions et Dapr

Revisions permettent blue-green : traffic_weight 100% sur nouvelle. Activez Dapr pour pub/sub stateful.

Déployer revision avec Dapr et traffic split

deploy-revision.sh

#!/bin/bash

APP_NAME="myapp"
RESOURCE_GROUP="rg-containerapps-demo"

# Update vers v2 (assume nouvelle image pushée)
az containerapp update --name $APP_NAME \
  --resource-group $RESOURCE_GROUP \
  --image acrcontainerappsXXXX.azurecr.io/app:v2 \
  --set-env-vars "DAPR_ENABLED=true"="DAPR_APP_ID=myapp"="DAPR_APP_PORT=3000"

# Traffic split 20/80 old/new (blue-green)
OLD_REVISION=$(az containerapp revision list --name $APP_NAME --resource-group $RESOURCE_GROUP --query "[0].name" -o tsv)
NEW_REVISION=$(az containerapp revision list --name $APP_NAME --resource-group $RESOURCE_GROUP --query "[?provisioningState=='Succeeded' && name!='$OLD_REVISION'].name | [0]" -o tsv)

az containerapp ingress traffic set \
  --name $APP_NAME \
  --resource-group $RESOURCE_GROUP \
  --traffic-weight "$OLD_REVISION=20"="$NEW_REVISION=80"

Déploie revision v2 avec Dapr sidecar (state/pubsub). Split traffic pour zero-downtime. Piège : Sans --cpu 1 --memory 2Gi pour Dapr, OOM kills ; monitorez avec az monitor.

Monitoring et logs avec Bash

monitor.sh

#!/bin/bash

APP_NAME="myapp"
RESOURCE_GROUP="rg-containerapps-demo"

# Logs en temps réel
az monitor app-insights query --app demo-logs --analytics-query "requests | where timestamp > ago(1h) | summarize count() by bin(timestamp, 5m)" --timespan PT1H

# Metrics scaling
az containerapp logs show --name $APP_NAME --resource-group $RESOURCE_GROUP --type console --follow

# Revisions list
az containerapp revision list --name $APP_NAME --resource-group $RESOURCE_GROUP

# Scale manual
az containerapp replica set --name $APP_NAME --resource-group $RESOURCE_GROUP --replica-count 5

Query App Insights pour metrics, tail logs console. Utile pour debug scaling. Piège : Logs expirent ; intégrez Log Analytics dès env creation avec --logs-workspace-id.

Bonnes pratiques

IaC only : Toujours YAML + GitHub Actions pour CI/CD reproductible.
Scale-to-zero : Activez pour workloads intermittents, + Dapr pour état persistant.
Secrets rotation : Utilisez Key Vault refs, pas hardcoded.
VNet + Private endpoints : Isolez ACR/env pour compliance SOC2.
Healthchecks stricts : Liveness/readiness sur /health pour éviter cascades failures.

Erreurs courantes à éviter

Image non accessible : ACR firewall bloque CLI ; ajoutez az acr import ou admin-enabled.
Scaling panique : TargetValue trop bas cause thrashing ; testez avec loadgen (k6).
Revisions orphelines : az containerapp revision set --active nettoie, évite coûts cachés.
Dapr mismatch : Versions app/Dapr alignées (1.12+), sinon sidecar crashes.

Pour aller plus loin

Approfondissez avec Dapr on Azure Container Apps et KEDA scalers. Intégrez Terraform pour multi-env. Découvrez nos formations Learni DevOps Azure avancées pour certifs expert.

Comment déployer et scaler Azure Container Apps en 2026