06 · Web App for Containers privée : démarrage, réseau, secrets et journaux

Version : 1.0 · Date : 2026-10-23 · Parcours SUPPORT-IA (support N2/N3 de chatbots sur Azure)

En une phrase : une Web App for Containers privée reçoit le trafic par un Private Endpoint, sort vers ACR, Azure OpenAI, AI Search et Key Vault par la VNet integration, tire son image avec sa managed identity, démarre seulement si le conteneur répond sur le bon port à temps ; presque toutes les pannes sont un port, un DNS, une route ou un rôle.

Le choix entre AKS, Container Apps et App Service est traité dans AKS/07-conteneurs-azure-et-entretiens. Ce chapitre suit une Web App for Containers Linux de chatbot (Python ou Node), du build de l'image à la lecture des journaux. La chaîne de build et ACR sont dans 05-gitops-argocd-azure-devops-acr ; le pendant AKS dans 04-aks-pour-le-support.

Ce que tu dois savoir expliquer en entretien#

1. Les pièces du puzzle#

Docker Compose (multi-container) sera retiré le 31/03/2027 : les sidecars le remplacent. Une app encore en Compose est un sujet de migration à signaler.

2. Le Dockerfile d'une application de chat#

Règles qui évitent la majorité des pannes de démarrage :

# Python (FastAPI) : image de build puis image d'exécution minimale
FROM python:3.12-slim AS build
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir --prefix=/install -r requirements.txt

FROM python:3.12-slim
WORKDIR /app
COPY --from=build /install /usr/local
COPY src/ ./src/
EXPOSE 8000
# 0.0.0.0 : joignable par les pings d'App Service ; WEBSITES_PORT=8000 côté app settings
CMD ["gunicorn", "src.main:app", "-k", "uvicorn.workers.UvicornWorker", "-b", "0.0.0.0:8000", "--timeout", "600"]

# Node.js : port 8080 détecté sans réglage
FROM node:22-slim
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev
COPY . .
ENV PORT=8080
EXPOSE 8080
CMD ["node", "server.js"]        # server.js doit écouter sur 0.0.0.0:${PORT}

Piège : WEBSITES_PORT n'est pas PORT. PORT sert aux images intégrées (runtimes Python, Node d'App Service) ; pour un conteneur personnalisé, c'est WEBSITES_PORT qui dit à la plateforme où envoyer le trafic.

3. Le démarrage d'un conteneur#

Ce qu'il faut savoir sur un redémarrage :

• Changer l'image : l'ancien conteneur continue de servir tant que le nouveau n'est pas prêt ; le basculement peut prendre plusieurs minutes.
• Redémarrage simple : seules les couches modifiées sont retirées. Nouvelle instance (scale-out, changement de tier, maintenance) : toutes les couches sont retirées, d'où des démarrages plus longs et parfois un dépassement du délai.
• Si le conteneur n'est pas prêt dans le délai, la plateforme fait échouer la tentative et réessaie : l'utilisateur voit des 503.

4. Tirer l'image d'un ACR privé avec une managed identity#

# Lecture : comment l'app tire-t-elle son image ?
az webapp config container show -g rg-chat-prd -n app-chat-prd -o table
az webapp config show -g rg-chat-prd -n app-chat-prd \
  --query "{acrMi:acrUseManagedIdentityCreds, acrUami:acrUserManagedIdentityID, image:linuxFxVersion}" -o json
az webapp identity show -g rg-chat-prd -n app-chat-prd
az acr config authentication-as-arm show -r acrchatprd          # doit être enabled pour le pull par managed identity

Mise en place (pour comprendre ce qu'on lit) :

PRINCIPAL=$(az webapp identity assign -g rg-chat-prd -n app-chat-prd --query principalId -o tsv)
az role assignment create --assignee "$PRINCIPAL" --role AcrPull --scope "$(az acr show -n acrchatprd --query id -o tsv)"
az webapp config set -g rg-chat-prd -n app-chat-prd --generic-configurations '{"acrUseManagedIdentityCreds": true}'
# Avec une user-assigned identity : préciser son client ID
az webapp config set -g rg-chat-prd -n app-chat-prd --generic-configurations '{"acrUserManagedIdentityID": "<client-id>"}'
# Registre derrière un Private Endpoint : faire passer le pull par la VNet integration
az resource update -g rg-chat-prd -n app-chat-prd --resource-type "Microsoft.Web/sites" \
  --set properties.outboundVnetRouting.imagePullTraffic=true

5. Réseau : entrée par Private Endpoint, sortie par VNet integration#

5.1 Deux mécanismes indépendants#

5.2 Routage sortant : application et configuration#

La VNet integration distingue :

• Application routing : le trafic émis par le code. outboundVnetRouting.applicationTraffic=true (case Outbound internet traffic du portail ; anciens noms vnetRouteAllEnabled, WEBSITE_VNET_ROUTE_ALL) envoie tout le trafic applicatif dans le VNet, sinon seulement le trafic RFC 1918.
• Configuration routing : ce que la plateforme fait au démarrage, par la route publique par défaut : pull de l'image (imagePullTraffic), partage de contenu, sauvegarde, et Key Vault references.
• outboundVnetRouting.allTraffic=true route les deux familles dans le VNet (CLI uniquement, auditable par Azure Policy).

Règle à retenir : une app Linux qui appelle des Private Endpoints doit router tout son trafic dans le VNet ; sinon, selon la résolution DNS, une partie part par la route publique et revient en 403.

# Lecture : intégration, accès public, routage
az webapp vnet-integration list -g rg-chat-prd -n app-chat-prd -o table
az webapp show -g rg-chat-prd -n app-chat-prd \
  --query "{subnet:virtualNetworkSubnetId, public:publicNetworkAccess, routing:outboundVnetRouting}" -o json
az webapp config show -g rg-chat-prd -n app-chat-prd --query "{routeAllLegacy:vnetRouteAllEnabled, alwaysOn:alwaysOn, health:healthCheckPath}"

5.3 Les zones DNS privées d'un chatbot#

Le nom appelé ne change jamais (monapp.azurewebsites.net, moncoffre.vault.azure.net) : c'est la chaîne CNAME vers privatelink.* qui doit finir sur une IP privée depuis le VNet. Le certificat par défaut couvre *.azurewebsites.net : il faut appeler la Web App par ce nom, pas par l'IP du Private Endpoint.

5.4 Diagnostic réseau#

# Depuis le conteneur de l'app (terminal SSH du portail ou az webapp exec en préversion, si l'image a un shell)
nslookup oai-chat-prd.openai.azure.com          # IP privée attendue (10.x, 172.16-31.x, 192.168.x)
nslookup kv-chat-prd.vault.azure.net
curl -sv https://srch-chat-prd.search.windows.net -o /dev/null   # 403 de la ressource ≠ timeout réseau
# Depuis une VM du réseau client : la Web App elle-même
nslookup app-chat-prd.azurewebsites.net          # doit passer par app-chat-prd.privatelink.azurewebsites.net

6. App settings et Key Vault references#

Les app settings arrivent dans le conteneur comme variables d'environnement ; les modifier redémarre l'app. Une valeur peut être une Key Vault reference :

@Microsoft.KeyVault(SecretUri=https://kv-chat-prd.vault.azure.net/secrets/search-api-key)
@Microsoft.KeyVault(VaultName=kv-chat-prd;SecretName=search-api-key)

Encore mieux que la référence : pour Azure OpenAI ou AI Search, appeler le service avec la managed identity de l'app (DefaultAzureCredential) plutôt qu'avec une clé : plus de secret, plus de rotation.

7. Deployment slots et swap#

• Slots disponibles à partir de Standard ; nombre limité par tier.
• Retour arrière : refaire le même swap immédiatement.
• Swap with preview : az webapp deployment slot swap … --action preview, puis --action swap ou --action reset.
• Pour un conteneur : déployer le nouveau tag dans le slot staging (tâche AzureWebAppContainer@1 ou az webapp config container set --slot staging), tester, puis swapper ; tag unique, pas latest.
• La configuration du Health check n'est pas propre au slot : elle suit le swap.

az webapp deployment slot list -g rg-chat-prd -n app-chat-prd -o table
az webapp config container show -g rg-chat-prd -n app-chat-prd --slot staging -o table

8. Health check#

Pour un chatbot : un chemin /ready qui vérifie les dépendances critiques (avec un délai court), distinct d'un /healthz de liveness sans dépendance, comme sur AKS (chapitre 04).

9. Les journaux : Log stream, Diagnostic settings, Application Insights#

// Démarrages et arrêts du conteneur sur les deux dernières heures
AppServicePlatformLogs
| where TimeGenerated > ago(2h)
| order by TimeGenerated desc
| take 100

// Codes HTTP renvoyés par l'app (500, 502, 503 ?)
AppServiceHTTPLogs
| where TimeGenerated > ago(1h)
| summarize requetes = count(), duree_moyenne_ms = avg(TimeTaken) by ScStatus
| order by requetes desc

// Recherche du message de démarrage raté
AppServicePlatformLogs
| where TimeGenerated > ago(1d)
| search "didn't respond"

Piège : les requêtes du Health check ne figurent pas dans les journaux HTTP (elles sont internes). Et AppServiceAppLogs reste vide pour un conteneur Python ou Node : leurs journaux sont dans AppServiceConsoleLogs.

10. Pannes fréquentes : symptôme → cause → vérification → correction#

flowchart TD
    A["Web App KO"] --> B{"Le conteneur démarre-t-il ?<br/>Log stream / AppServicePlatformLogs"}
    B -- "Échec du pull" --> B1["Identité, AcrPull, authentication-as-arm,<br/>imagePullTraffic, DNS privatelink.azurecr.io"]
    B -- "didn't respond to HTTP pings" --> B2["WEBSITES_PORT, 0.0.0.0,<br/>START_TIME_LIMIT, warm-up"]
    B -- "S'arrête en boucle" --> B3["stdout : exception, variable,<br/>@Microsoft.KeyVault non résolue"]
    B -- "Démarré" --> C{"L'utilisateur atteint-il l'app ?"}
    C -- "403 / timeout" --> C1["Private Endpoint, DNS privatelink.azurewebsites.net,<br/>public network access"]
    C -- "Oui, erreurs 5xx" --> D{"Les dépendances répondent-elles ?"}
    D -- "403 / timeout" --> D1["DNS des services, route all,<br/>rôles de la managed identity"]
    D -- "Lentes" --> D2["Application Insights : dépendances,<br/>quotas OpenAI, streaming"]

11. Lab : une Web App for Containers privée qui tire depuis ACR (60 minutes)#

Dans une subscription de test uniquement ; supprimer le resource group à la fin.

RG=rg-lab-webapp; LOC=francecentral; ACR=acrlab$RANDOM; APP=app-lab-$RANDOM
az group create -n $RG -l $LOC
az acr create -g $RG -n $ACR --sku Premium
az acr import -n $ACR --source mcr.microsoft.com/azuredocs/aci-helloworld:latest --image hello:1    # tag unique
az appservice plan create -g $RG -n plan-lab --is-linux --sku P0v3
az webapp create -g $RG -p plan-lab -n $APP --container-image-name $ACR.azurecr.io/hello:1
PRINCIPAL=$(az webapp identity assign -g $RG -n $APP --query principalId -o tsv)
az role assignment create --assignee "$PRINCIPAL" --role AcrPull --scope "$(az acr show -n $ACR --query id -o tsv)"
az webapp config set -g $RG -n $APP --generic-configurations '{"acrUseManagedIdentityCreds": true}'
az webapp log config -g $RG -n $APP --docker-container-logging filesystem
az webapp restart -g $RG -n $APP           # nouveau pull, cette fois avec la managed identity
az webapp log tail -g $RG -n $APP          # observer le pull et le démarrage

Variantes à tester, une à la fois, en lisant le Log stream :

1. WEBSITES_PORT=8000 alors que l'image écoute sur 80 : message didn't respond to HTTP pings, puis retirer le setting.
2. Retirer le rôle AcrPull et redémarrer : échec du pull UNAUTHORIZED.
3. Ajouter un app setting @Microsoft.KeyVault(VaultName=inexistant;SecretName=x) : statut d'erreur dans le portail, chaîne littérale dans la variable.
4. Aller plus loin : VNet, Private Endpoint ACR, az acr update --public-network-enabled false, puis observer l'échec du pull tant que imagePullTraffic et la zone DNS ne sont pas en place.

Nettoyage : az group delete -n $RG --yes --no-wait.

12. Questions d'entretien#

1. Que fait App Service quand il démarre ton conteneur ?

Il tire l'image (avec la managed identity si configurée), résout les app settings dont les Key Vault references, démarre le conteneur, puis envoie des pings HTTP sur le port déclaré jusqu'à obtenir une réponse, dans la limite de WEBSITES_CONTAINER_START_TIME_LIMIT (230 s par défaut). Ensuite seulement il route le trafic.

2. didn't respond to HTTP pings on port 80 : ta démarche ?

C'est un symptôme. Je vérifie le port réel de l'application et WEBSITES_PORT, qu'elle écoute sur 0.0.0.0, qu'elle répond même par une 404 aux chemins inconnus, et la durée de démarrage dans le Log stream ; si elle charge un index ou un modèle, j'augmente la limite de démarrage.

3. Private Endpoint et VNet integration, quelle différence ?

Le Private Endpoint ne sert qu'au trafic entrant : il donne une IP privée à l'app, et il faut couper l'accès public. La VNet integration ne sert qu'au trafic sortant : elle place l'app dans un subnet délégué pour joindre les Private Endpoints d'OpenAI, Search, Key Vault et ACR. Les deux s'utilisent ensemble pour une app 100 % privée.

4. Comment la Web App tire-t-elle une image d'un ACR privé ?

Managed identity avec AcrPull, acrUseManagedIdentityCreds (et acrUserManagedIdentityID si user-assigned), le registre doit accepter les jetons d'audience ARM, et le pull doit passer par le VNet (outboundVnetRouting.imagePullTraffic) avec la zone privatelink.azurecr.io pour le registre et son data endpoint.

5. L'app reçoit un 403 d'Azure OpenAI. Comment sais-tu si c'est le réseau ou les droits ?

Le message le dit souvent (« public network access is disabled » contre une erreur de permission). Je vérifie depuis le conteneur que le FQDN résout vers une IP privée et que le trafic est routé dans le VNet ; si oui, c'est le rôle Cognitive Services OpenAI User de la managed identity, avec quelques minutes de propagation.

6. Comment gérez-vous les secrets ?

Le mieux est de ne pas en avoir : managed identity vers OpenAI et Search. Sinon, des Key Vault references dans les app settings, lues avec la managed identity (Key Vault Secrets User), marquées sticky par slot. Sans version, la rotation est prise sous 24 h ; une référence non résolue arrive en chaîne littérale dans l'application.

7. Log stream, Diagnostic settings, Application Insights : lequel et quand ?

Le Log stream pour voir en direct un démarrage ou un plantage ; les Diagnostic settings vers Log Analytics pour chercher après coup (AppServiceConsoleLogs, AppServicePlatformLogs, AppServiceHTTPLogs) et alerter ; Application Insights pour suivre une requête et ses dépendances, par exemple un appel OpenAI lent.

8. Comment déployer sans coupure et revenir en arrière ?

Déployer le nouveau tag dans un slot staging, le tester (swap with preview si besoin), puis swapper : la production reçoit une app déjà démarrée et préchauffée. Retour arrière : refaire le swap. Attention aux settings sticky et au Health check qui suit le swap.

9. Les utilisateurs ont des coupures au bout de quatre minutes sur les longues réponses.

App Service coupe une requête sans réponse vers 230 s (Windows) ou 240 s (Linux), ce n'est pas réglable. Pour un chatbot, il faut streamer la réponse du LLM ou passer en traitement asynchrone.

10. Le Health check retire une instance : comment ça marche ?

Ping toutes les minutes ; après 10 échecs par défaut (réglable de 2 à 10), l'instance sort du load balancer, sans dépasser 50 % des instances ; si elle reste malade une heure, elle est remplacée. Il faut au moins deux instances pour en profiter.

13. Fiche à retenir#

• Port : 80 ou 8080 détectés, sinon WEBSITES_PORT ; écouter sur 0.0.0.0 ; un seul port ; répondre à /robots933456.txt.
• WEBSITES_CONTAINER_START_TIME_LIMIT : 230 s par défaut (10 à 1 800) ; échec = 503 et nouvel essai.
• Always On : déchargement après 20 min sinon ; requêtes coupées vers 230/240 s → streaming.
• Pull ACR : managed identity + AcrPull + acrUseManagedIdentityCreds (+ acrUserManagedIdentityID) + authentication-as-arm + imagePullTraffic.
• Private Endpoint = entrant (couper l'accès public, privatelink.azurewebsites.net + scm) ; VNet integration = sortant (subnet délégué Microsoft.Web/serverFarms).
• outboundVnetRouting : applicationTraffic (ex vnetRouteAllEnabled), imagePullTraffic (ex vnetImagePullEnabled), allTraffic.
• Zones : privatelink.openai.azure.com, privatelink.search.windows.net, privatelink.vaultcore.azure.net, privatelink.azurecr.io.
• Key Vault reference : @Microsoft.KeyVault(SecretUri=…), system identity par défaut, rotation sous 24 h, échec = chaîne littérale, settings sticky.
• Slots dès Standard ; swap = settings appliqués, redémarrage, warm-up, échange ; retour arrière = re-swap.
• Health check : 1 ping/min, 10 échecs, 50 % max retirés, remplacement après 1 h, deux instances minimum.
• Journaux : Log stream (--docker-container-logging filesystem), AppServiceConsoleLogs, AppServicePlatformLogs, AppServiceHTTPLogs, Application Insights.
• Docker Compose retiré le 31/03/2027 → sidecars.

Références#

Relevé du 23/10/2026 sur Microsoft Learn :

• Configure a custom container for Azure App Service
• Environment variables and app settings reference
• FAQ App Service on Linux (conteneurs, warm-up, ports)
• Configure an App Service app (Always On, general settings)
• Web request times out after 230 seconds
• Use private endpoints for App Service apps
• Integrate your app with an Azure virtual network et gérer le routage de la VNet integration
• Azure Private Endpoint private DNS zone values
• Troubleshoot 403 errors through a private endpoint et private endpoint DNS resolution
• Use Key Vault references as app settings
• Set up staging environments (deployment slots) et deployment best practices
• Monitor App Service instances by using Health check
• Enable diagnostic logs et App Service monitoring data reference
• Troubleshoot slow web app performance (cold start)
• Configure registry acceptance of Microsoft Entra authentication scopes (authentication-as-arm)
• Role-based access control for Azure OpenAI
• AzureWebAppContainer@1