Aller au contenu
NextiaNextia Learning
English

Configuration opérationnelle

  • Leçon 14
  • 45 min
  • Module 5 : Déployer et nettoyer
Leçon 14 sur 15 · L'essentiel de Docker et du nuage pour les développeurs en IAConfiguration opérationnelle
Aperçu du cours

1. Comprendre les conteneurs

  1. Cohérence des environnements
  2. Images et conteneurs en cours d'exécution
  3. Installer et vérifier

2. Construire l'image de l'application

  1. L'essentiel du Dockerfile
  2. Construire efficacement
  3. Sécurité à l'exécution

3. Réseau, configuration et persistance

  1. Ports et accès au service
  2. Configuration à l'exécution
  3. Données persistantes

4. Les services de base du nuage

  1. Régions et types de services
  2. Identité et secrets
  3. Connaître les coûts

5. Déployer et nettoyer

  1. Registre et déploiement
  2. Configuration opérationnelle
  3. Vérifier et supprimer

Ce que vous saurez faire

Une plateforme gérée exécute votre conteneur, mais elle ne connaît pas votre application. Indiquez-lui comment vérifier l’application, sa taille maximale, ses limites de croissance et ses paramètres requis. Ainsi, une mauvaise version s’arrête avant d’atteindre qui que ce soit.

Avant de commencerCe qu’il faut savoir et avoir sous la mainEnviron 45 minutes

Ce que vous devez savoir

Ce qu’il vous faut sur votre ordinateur

Testé avec Docker Desktop 4.81.0 (Docker Engine 29.6.1) sur macOS, avec une puce Apple. Les étapes Azure ont été exécutées avec Azure CLI 2.88.0 et l’extension containerapp 1.3.0b5, dans la région canadacentral. Les étapes Windows et Linux ne sont pas testées.

Ce que la plateforme sait maintenant

Section intitulée « Ce que la plateforme sait maintenant »

Après Registre et déploiement, Amira demande à Azure comment il vérifie son application :

Terminal (live)
az containerapp show -g $RG -n ticket-api --query "properties.template.containers[0].probes" -o json

La réponse (réelle) est une liste vide. Sans sondes, la plateforme vérifie seulement que quelque chose accepte les connexions sur le port 8000 (une vérification TCP). Un processus bloqué ou un classificateur incapable de classifier réussit quand même cette vérification.

« Sans serveur » ne veut pas dire « sans configuration ». La plateforme gère les serveurs. Elle ignore ce que signifie « fonctionner » pour votre application, ses besoins en mémoire et ses paramètres requis. Vous le lui indiquez en cinq parties :

Partie Question à laquelle elle répond Réponse de l’API de billets
Entrée Qui peut accéder à l’application, et sur quel port? Externe, HTTPS, port cible 8000
Sondes Comment la plateforme sait-elle que l’application fonctionne? /health pour le démarrage et la vitalité, /ready pour la disponibilité
Ressources Quelle est la taille d’une réplique? 0,25 vCPU, 0,5 Gio
Mise à l’échelle Combien de répliques, au minimum et au maximum? De 0 à 2
Paramètres requis Quels paramètres doivent être définis pour que l’application démarre? API_KEY depuis le secret, REQUIRE_API_KEY=true, SHOW_DOCS=false

Entrée : un seul point d’accès

Section intitulée « Entrée : un seul point d’accès »

L’entrée est la porte d’entrée de la plateforme : elle reçoit les requêtes externes et les transmet à votre conteneur. --ingress external --target-port 8000, dans la leçon précédente, l’a configurée. Azure donne à l’application une adresse HTTPS avec un certificat. Il transmet chaque requête au port 8000 d’un conteneur. L’application elle-même utilise HTTP sans chiffrement, comme sur votre ordinateur.

La plateforme ne sert pas les requêtes en http:// sans chiffrement. Amira le vérifie (parcours réel) :

Terminal (live)
curl -s -o /dev/null -w "%{http_code} -> %{redirect_url}\n" http://ticket-api.nicewater-a307f95a.canadacentral.azurecontainerapps.io/health
301 -> https://ticket-api.nicewater-a307f95a.canadacentral.azurecontainerapps.io/health

301 indique une redirection permanente vers l’adresse HTTPS. Une clé envoyée par HTTP sans chiffrement pourrait être lue en chemin. La plateforme ne répond donc jamais à cette adresse.

Trois sondes, deux points de terminaison

Section intitulée « Trois sondes, deux points de terminaison »

Une sonde est une requête que la plateforme envoie régulièrement à l’application pour décider quoi faire d’une réplique. Container Apps en propose trois types :

Sonde Question En cas d’échec L’API de billets
Démarrage L’application a-t-elle fini de démarrer? Attendre. Après trop d’échecs, redémarrer la réplique. /health, toutes les 2 s, jusqu’à 30 fois
Vitalité Le processus fonctionne-t-il encore? Redémarrer la réplique. /health, toutes les 10 s, 3 échecs
Disponibilité Peut-elle faire son travail maintenant? Ne lui envoyer aucune requête, sans la redémarrer. /ready, toutes les 10 s, 3 échecs

Pourquoi utiliser /ready seulement pour la disponibilité? Rappelez-vous le module 3 : quand la base de données est hors service, /ready renvoie 503, et la classification fonctionne encore. Un redémarrage ne peut pas réparer une base de données. Si la vitalité utilisait /ready, une panne de base de données ferait redémarrer l’application sans cesse et arrêterait aussi la classification. La vitalité demande donc « le processus est-il actif? » (/health), et la disponibilité demande « peut-il travailler maintenant? » (/ready).

La sonde de démarrage protège un démarrage lent. Elle accorde jusqu’à 30 × 2 s = 60 s. Les vérifications de vitalité commencent seulement quand la sonde de démarrage réussit. Un démarrage lent n’est donc pas considéré comme un processus arrêté.

Les paramètres dans un seul fichier

Section intitulée « Les paramètres dans un seul fichier »

Amira ne configure pas les sondes avec de nombreuses options. Elle conserve tous les paramètres opérationnels dans deploy/containerapp.yaml et les révise dans Git comme du code :

deploy/containerapp.yaml
# The container settings of the ticket API on Azure Container Apps.
# Apply with:
#   az containerapp update --resource-group rg-ticket-api-practice \
#     --name ticket-api --yaml deploy/containerapp.yaml
# Replace REGISTRY_NAME with the name of your registry first.
# The secret api-key must already exist on the app (az containerapp secret set).
properties:
  template:
    containers:
      - name: ticket-api
        image: REGISTRY_NAME.azurecr.io/ticket-api:1.1.0
        resources:
          cpu: 0.25
          memory: 0.5Gi
        env:
          - name: API_KEY
            secretRef: api-key
          - name: REQUIRE_API_KEY
            value: "true"
          - name: SHOW_DOCS
            value: "false"
        probes:
          - type: Startup
            httpGet:
              path: /health
              port: 8000
            initialDelaySeconds: 1
            periodSeconds: 2
            failureThreshold: 30
          - type: Liveness
            httpGet:
              path: /health
              port: 8000
            periodSeconds: 10
            failureThreshold: 3
          - type: Readiness
            httpGet:
              path: /ready
              port: 8000
            periodSeconds: 10
            failureThreshold: 3
    scale:
      minReplicas: 0
      maxReplicas: 2

Le fichier ne contient aucun secret. secretRef: api-key désigne le secret de l’application, et sa valeur reste dans Azure. Vous pouvez enregistrer ce fichier dans un commit (enregistrement des modifications).

Ressources. Dans le plan Consumption, le processeur et la mémoire sont offerts en paires fixes. La plus petite paire est de 0,25 vCPU avec 0,5 Gio. L’API de billets utilisait environ 57 Mio dans la simulation. Avec 0,5 Gio, il reste donc de la marge.

Mise à l’échelle. Une réplique est une copie de l’application en cours d’exécution (voir Connaître les coûts). minReplicas: 0 permet la mise à l’échelle à zéro : aucune réplique et aucuns frais de calcul après 300 s sans appel. maxReplicas: 2 limite les coûts et les dommages. Si un programme envoie des milliers de requêtes, la plateforme démarre au maximum deux répliques, pas dix (le maximum par défaut est 10).

Paramètres requis. REQUIRE_API_KEY: "true" fait échouer le démarrage si la clé manque, au lieu de laisser une API ouverte. Si le secret manque, l’application s’arrête avec Settings error: REQUIRE_API_KEY is true, but API_KEY is not set (erreur de paramètres : REQUIRE_API_KEY est vrai, mais API_KEY n’est pas défini). La nouvelle révision ne devient jamais disponible, et l’ancienne continue de répondre. C’est un échec sûr.

Exemple détaillé : appliquer le fichier (parcours réel)

Section intitulée « Exemple détaillé : appliquer le fichier (parcours réel) »

Amira inscrit le nom de son registre sur la ligne de l’image, puis applique le fichier :

Terminal (live)
sed -i '' "s/REGISTRY_NAME/$ACR/" deploy/containerapp.yaml
az containerapp update -g $RG -n ticket-api --yaml deploy/containerapp.yaml --query "{rev:properties.latestRevisionName, prov:properties.provisioningState}" -o table

Le nom du registre n’est pas un secret. Il peut donc figurer dans le fichier enregistré dans le commit. La sortie (réelle) :

Rev                  Prov
-------------------  ---------
ticket-api--0000001  Succeeded

Une nouvelle révision, ticket-api--0000001. Une révision est une copie fixe de l’image et des paramètres de l’application. Chaque modification du modèle de configuration (image, paramètres, sondes) en crée une nouvelle. Amira vérifie qu’Azure possède bien ce qu’indique le fichier :

Terminal (live)
az containerapp show -g $RG -n ticket-api --query "properties.template.containers[0].{probes:probes[].type, env:env[].name}" -o json
{
  "env": ["API_KEY", "REQUIRE_API_KEY", "SHOW_DOCS"],
  "probes": ["Liveness", "Readiness", "Startup"]
}

Voici maintenant les révisions, juste après la mise à jour et 20 s plus tard :

Terminal (live)
az containerapp revision list -g $RG -n ticket-api --query "[].{name:name, active:properties.active, replicas:properties.replicas, health:properties.healthState, traffic:properties.trafficWeight}" -o table
Name                 Active    Replicas    Health    Traffic
-------------------  --------  ----------  --------  ---------
ticket-api--nz14cir  True      1           Healthy   0
ticket-api--0000001  True      1           None      100


Name                 Active    Replicas    Health    Traffic
-------------------  --------  ----------  --------  ---------
ticket-api--nz14cir  True      1           Healthy   0
ticket-api--0000001  True      1           Healthy   100

L’application est en mode de révision unique (az containerapp show … --query properties.configuration.activeRevisionsMode indique Single, soit unique). Une seule révision reçoit le trafic. La plateforme démarre la nouvelle à côté de l’ancienne, puis supprime l’ancienne quand la nouvelle est disponible. Le prochain échec de la leçon montre ce qui arrive quand elle ne devient jamais « disponible ».

Exemple détaillé : les mêmes idées dans la simulation

Section intitulée « Exemple détaillé : les mêmes idées dans la simulation »

La simulation n’a ni sondes ni révisions, mais elle possède trois des cinq parties. Amira les examine dans le conteneur en cours d’exécution.

Une vérification de l’état de santé. Docker exécute la commande healthcheck (vérification de l’état de santé) dans le conteneur toutes les 10 s. Elle utilise urllib de Python, car l’image allégée ne contient pas curl :

Terminal (simulated)
docker inspect ticket-api-cloud-sim-api-1 --format "{{json .State.Health}}"
{"Status":"healthy","FailingStreak":0,"Log":[{"Start":"2026-10-07T16:50:36.679051923Z","End":"2026-10-07T16:50:37.721244007Z","ExitCode":0,"Output":""}]}

La vérification de Docker ressemble à une sonde de vitalité qui ne fait que signaler l’état. docker ps affiche (unhealthy) (en mauvais état), mais Docker ne redémarre pas le conteneur pour cette raison. Les vérifications apparaissent dans le journal de l’application comme des requêtes provenant de 127.0.0.1. Elles s’exécutent dans le conteneur, comme les sondes d’Azure.

Les limites de taille.

Terminal (simulated)
docker stats --no-stream ticket-api-cloud-sim-api-1
CONTAINER ID   NAME                         CPU %     MEM USAGE / LIMIT   MEM %     NET I/O          BLOCK I/O   PIDS
5567fda8c533   ticket-api-cloud-sim-api-1   2.14%     56.92MiB / 512MiB   11.12%    7.96kB / 6.1kB   0B / 0B     6

/ 512MiB correspond à mem_limit: 512m. Si l’application utilisait plus de mémoire, le noyau l’arrêterait. cpus: 0.25 n’apparaît pas ici : docker inspect l’affiche sous NanoCpus avec 250000000, soit un quart de processeur.

Une politique de redémarrage et un paramètre requis. restart: on-failure redémarre le conteneur quand l’application s’arrête avec une erreur. Faites une prédiction : si Amira arrête proprement l’application de l’intérieur, Docker la redémarre-t-il?

Terminal (simulated)
docker exec ticket-api-cloud-sim-api-1 sh -c 'kill 1'
docker ps -a --filter name=ticket-api-cloud-sim --format "{{.Names}} {{.Status}}"
ticket-api-cloud-sim-api-1 Exited (0) 2 seconds ago

Non. kill 1 envoie le signal d’arrêt au processus 1, l’application. Elle s’arrête proprement, avec le code de sortie 0, et on-failure redémarre seulement après une erreur. Maintenant, un véritable échec : Amira vide le fichier de clé. Le paramètre requis manque alors, et elle redémarre le service. Un secret Compose est monté depuis le fichier. Le conteneur voit donc la modification.

Terminal (simulated)
cp secrets/api_key.txt secrets/api_key.txt.bak
: > secrets/api_key.txt
docker compose -f deploy/local-cloud.yaml up -d
docker compose -f deploy/local-cloud.yaml logs --tail 3 api
docker ps -a --filter name=ticket-api-cloud-sim --format "{{.Status}}"

La sortie (simulée; docker ps exécuté quelques fois, à une seconde d’intervalle) :

api-1  |
api-1  |
api-1  | Settings error: REQUIRE_API_KEY is true, but API_KEY is not set
Restarting (1) Less than a second ago
Up Less than a second (health: starting)
Up 2 seconds (health: starting)
Restarting (1) Less than a second ago

L’application s’arrête avec le code de sortie 1, et Docker la redémarre, encore et encore. docker inspect ticket-api-cloud-sim-api-1 --format "{{.RestartCount}}" compte les redémarrages. Lors de deux essais, le compte augmentait de un toutes les 4 à 10 s. Avec un quart de processeur, l’application met quelques secondes à atteindre la vérification des paramètres. L’API ne répond jamais sans clé : personne n’accède à une API ouverte. Amira remet la clé :

Terminal (simulated)
cp secrets/api_key.txt.bak secrets/api_key.txt
rm secrets/api_key.txt.bak

Au prochain redémarrage, l’application trouve la clé. Environ 25 s plus tard, docker ps affichait Up 34 seconds (healthy) (actif depuis 34 secondes, en bon état), sans commande d’Amira. C’est une version réduite de ce qu’Azure fait avec une révision incapable de démarrer. Il y a une différence : Docker n’a qu’un conteneur, donc l’API est hors service pendant les redémarrages. Azure garde l’ancienne révision en service.

Exercice guidé : donner ses instructions à la plateforme

Section intitulée « Exercice guidé : donner ses instructions à la plateforme »
  1. Lisez deploy/containerapp.yaml. Pour chaque sonde, notez dans docs/cloud-design.md son chemin et ce que la plateforme fait en cas d’échec.
  2. Parcours réel : inscrivez le nom de votre registre dans le fichier, puis appliquez-le avec az containerapp update --yaml. Résultat attendu : une nouvelle révision, ticket-api--0000001, et Succeeded (réussi).
  3. Parcours réel : listez les révisions jusqu’à ce que la nouvelle soit Healthy (en bon état), avec un trafic de 100.
  4. Parcours réel : vérifiez les sondes et les noms des paramètres avec az containerapp show. Résultat attendu : Liveness (vitalité), Readiness (disponibilité), Startup (démarrage), et API_KEY, REQUIRE_API_KEY, SHOW_DOCS.
  5. Parcours simulé : vérifiez l’état de santé avec docker inspect … --format "{{json .State.Health}}". Résultat attendu : "Status":"healthy" (état : en bon état).
  6. Parcours simulé : vérifiez la limite de mémoire avec docker stats --no-stream. Résultat attendu : / 512MiB.
  7. Parcours simulé : videz le fichier de clé et observez les redémarrages, comme dans l’exemple détaillé. Remettez ensuite la clé et attendez (healthy) (en bon état).
  8. Les deux parcours : vérifiez que /docs renvoie 404, car SHOW_DOCS vaut false.
Afficher les notes attendues pour l’étape 1
Sonde Chemin En cas d’échec
Démarrage /health, toutes les 2 s La plateforme attend, jusqu’à 30 échecs (60 s). Ensuite, elle redémarre la réplique. Les sondes de vitalité et de disponibilité attendent sa réussite.
Vitalité /health, toutes les 10 s Après 3 échecs, la plateforme redémarre la réplique.
Disponibilité /ready, toutes les 10 s Après 3 échecs, la plateforme n’envoie aucune requête à la réplique, mais ne la redémarre pas.

/ready n’est pas une vérification de vitalité. Elle échoue quand la base de données est hors service, et un redémarrage ne peut pas réparer une base de données.

À vous de jouer : docker kill et la politique de redémarrage

Section intitulée « À vous de jouer : docker kill et la politique de redémarrage »

L’exemple détaillé a arrêté l’application de l’intérieur. Arrêtez-la maintenant de l’extérieur, avec docker kill ticket-api-cloud-sim-api-1. docker kill termine le processus immédiatement, et le code de sortie n’est pas 0.

Prédisez : est-ce que restart: on-failure redémarre le conteneur? Exécutez la commande, puis vérifiez avec docker ps -a. Ensuite, relancez la simulation avec docker compose -f deploy/local-cloud.yaml up -d.

Afficher la réponse

Non. La sortie (simulée) :

ticket-api-cloud-sim-api-1 Exited (137) 3 seconds ago

Le code de sortie 137 signifie « terminé par le signal SIGKILL » (128 + 9). C’est un code d’échec, mais Docker ne redémarre pas le conteneur. Un arrêt que vous demandez avec docker stop ou docker kill est un arrêt manuel. Docker ne redémarre jamais un conteneur après un arrêt manuel. Une politique de redémarrage sert aux échecs que personne n’a demandés. Azure Container Apps fonctionne autrement : la plateforme redémarre toujours une réplique qui s’arrête. La sonde de vitalité peut aussi redémarrer une réplique qui fonctionne, mais ne répond pas.

Erreur courante

Le déploiement a réussi, mais la nouvelle version ne démarre jamais

La révision 0000001, avec l'image 1.1.0 pour amd64, a l'état Healthy (saine) et un trafic de 100. Amira exécute az containerapp update avec l'image 1.1.0-arm64, et Azure répond Succeeded (réussi). Azure démarre la révision 0000002 et tente de télécharger l'image : ImagePullUnauthorized (téléchargement non autorisé), puis ImagePullFailure (échec du téléchargement). La révision 0000002 reste à l'état Activating (activation en cours) et n'est jamais prête. La révision 0000001 continue de servir les requêtes : /health donne 200. Amira refait la mise à jour avec l'image 1.1.0. Azure démarre la révision 0000003, télécharge l'image et exécute la sonde de démarrage. La révision 0000003 est prête. Azure y transfère le trafic (100), et 0000001 passe à l'état Deprovisioning (suppression en cours).
Mode à révision unique. L'ancienne révision garde le trafic jusqu'à ce qu'une nouvelle soit prête. Une nouvelle révision qui ne peut pas démarrer ne reçoit jamais de trafic.
Description textuelle du diagramme

En mode à révision unique, une nouvelle révision reçoit le trafic seulement lorsqu’elle est prête. L’image de la révision 0000002 ciblait le mauvais processeur. Son téléchargement échouait donc sans cesse, et elle restait à l’état Activating. Pendant tout ce temps, la révision 0000001 servait les requêtes. Quand Amira a déployé la bonne image, la révision 0000003 a démarré, est devenue prête et a reçu le trafic. La plateforme a ensuite supprimé 0000001.

Symptôme (en conditions réelles) : Amira a construit une image seulement pour linux/arm64, avec l’étiquette 1.1.0-arm64, puis l’a déployée. La commande a indiqué Succeeded (réussi) :

Terminal (live)
docker buildx build --platform linux/arm64 -t $ACR.azurecr.io/ticket-api:1.1.0-arm64 --push .
az containerapp update -g $RG -n ticket-api --image $ACR.azurecr.io/ticket-api:1.1.0-arm64 --query "{rev:properties.latestRevisionName, prov:properties.provisioningState}" -o table
Rev                  Prov
-------------------  ---------
ticket-api--0000002  Succeeded

Mais 60 secondes plus tard, la nouvelle révision ne fonctionnait toujours pas, et l’ancienne recevait le trafic :

Name                 Active    Replicas    Health    Running     Traffic
-------------------  --------  ----------  --------  ----------  ---------
ticket-api--0000001  True      1           Healthy   Running     0
ticket-api--0000002  True      1           None      Activating  100

/health donnait toujours 200 : l’ancienne révision répondait. (La colonne Traffic (trafic) montre la cible, soit 100 pour la nouvelle révision. Les requêtes allaient toujours à l’ancienne, car la nouvelle n’était pas prête.)

Diagnostic : les journaux (logs) système. Utilisez --type system sans --format text (avec cette option, la commande indique ERROR: --type: only json logs supported for system logs (erreur : les journaux système prennent seulement en charge le format JSON)) :

Terminal (live)
az containerapp logs show -g $RG -n ticket-api --type system --tail 15

La sortie (en conditions réelles; un objet JSON par ligne, présenté ici avec l’heure, Reason (raison) et Msg (message)) :

2026-10-07 16:18:24 PullingImage | Pulling image 'ticketapi4821.azurecr.io/ticket-api:1.1.0-arm64'
2026-10-07 16:18:34 ImagePullUnauthorized | Pull image: ticketapi4821.azurecr.io/ticket-api:1.1.0-arm64 failed with unauthorized exception.
2026-10-07 16:18:34 ContainerTerminated | Container 'ticket-api' was terminated with exit code '' and reason 'ImagePullFailure'
2026-10-07 16:18:54 PullingImage | Pulling image 'ticketapi4821.azurecr.io/ticket-api:1.1.0-arm64'
2026-10-07 16:19:03 ImagePullUnauthorized | Pull image: ticketapi4821.azurecr.io/ticket-api:1.1.0-arm64 failed with unauthorized exception.
2026-10-07 16:19:03 ContainerTerminated | Container 'ticket-api' was terminated with exit code '' and reason 'ImagePullFailure'

Cause : le message indique « unauthorized » (non autorisé), mais l’identité et son rôle étaient corrects. L’image portant l’étiquette 1.1.0, dans le même dépôt, se téléchargeait sans problème. L’image n’avait aucune variante linux/amd64. Azure a signalé la plateforme manquante comme un échec de téléchargement. Le parcours simulé montre la vraie cause, en mots clairs, avec la même image :

Terminal (simulated)
docker pull --platform linux/amd64 127.0.0.1:5000/ticket-api:1.1.0-arm64
Error response from daemon: no matching manifest for linux/amd64 in the manifest list entries: no match for platform in manifest: not found

Correction :

  1. Avant de déployer, vérifiez la plateforme : docker buildx imagetools inspect $ACR.azurecr.io/ticket-api:<tag> doit afficher linux/amd64.
  2. Déployez de nouveau la dernière image fonctionnelle : az containerapp update -g $RG -n ticket-api --image $ACR.azurecr.io/ticket-api:1.1.0 --query properties.latestRevisionName -o tsv. La commande a affiché ticket-api--0000003.
  3. Listez les révisions jusqu’à ce que la nouvelle affiche Healthy (saine) avec un trafic de 100. Après 45 secondes :
Name                 Active    Replicas    Health    Running         Traffic
-------------------  --------  ----------  --------  --------------  ---------
ticket-api--0000001  True      1           Healthy   Deprovisioning  0
ticket-api--0000003  True      1           Healthy   Running         100

Pour un vrai service d’IA : « la commande a réussi » signifie seulement que la plateforme a accepté votre requête. Un serveur de modèle avec une grosse image échoue de la même façon. C’est aussi le cas si un fichier de modèle ne se charge pas : après la commande, pendant le démarrage. Vérifiez toujours l’état de santé de la révision et exécutez les tests de bon fonctionnement après un déploiement. Et si une erreur de téléchargement semble illogique, vérifiez d’abord la plateforme de l’image.

Vérifiez votre compréhension

Pourquoi l'API de billets utilise-t-elle /health pour la vitalité et /ready pour la disponibilité, plutôt que /ready pour les deux?

Afficher la réponse

L’échec d’une sonde de vitalité redémarre la réplique. L’échec d’une sonde de disponibilité arrête seulement les requêtes vers cette réplique. /ready échoue lorsqu’une dépendance, comme la base de données de l’historique, est en panne. Un redémarrage ne peut pas réparer la base de données. Avec /ready pour la vitalité, une panne de base de données ferait redémarrer l’application sans cesse. La classification, qui fonctionne encore, s’arrêterait aussi. /health échoue seulement quand le processus lui-même ne répond pas. Un redémarrage peut alors aider.

Vérifiez votre compréhension

Prédisez : vous déployez une nouvelle révision, mais vous avez oublié de créer le secret api-key. REQUIRE_API_KEY vaut true. Que voient les utilisateurs de l'API?

Afficher la réponse

Ils ne voient aucun changement : l’ancienne révision continue de servir les requêtes. La nouvelle révision ne peut pas démarrer sans clé. L’application s’arrête avec Settings error: REQUIRE_API_KEY is true, but API_KEY is not set (erreur de configuration : REQUIRE_API_KEY vaut true, mais API_KEY n’est pas défini). La sonde de démarrage ne réussit jamais, et la plateforme n’y transfère jamais le trafic. Sans REQUIRE_API_KEY=true, la nouvelle révision démarrerait sans clé, et l’API serait ouverte à tout le monde. Un paramètre obligatoire transforme une erreur dangereuse en déploiement échoué. (Le test avec un secret manquant n’a pas été effectué en conditions réelles. La simulation montre la même erreur de configuration et les redémarrages.)

Vérifiez votre compréhension

La responsable du soutien dit : c'est sans serveur, donc ça ne coûte rien et ne nécessite aucun paramètre. Donnez deux paramètres de deploy/containerapp.yaml qui montrent pourquoi ces deux affirmations sont fausses.

Afficher la réponse

minReplicas: 0 est un paramètre. C’est lui qui rend le coût de calcul nul quand personne n’appelle l’API. Avec minReplicas: 1, une réplique fonctionne tout le mois et entraîne des frais. maxReplicas: 2 limite le coût quand beaucoup de requêtes arrivent : la valeur par défaut permet 10 répliques. Les sondes, la taille (cpu: 0.25, memory: 0.5Gi) et REQUIRE_API_KEY sont aussi des paramètres que la plateforme ne peut pas deviner. Sans serveur signifie que quelqu’un d’autre gère les serveurs. Vous décidez toujours des limites de coût, des vérifications et des paramètres obligatoires. Et le registre et les journaux entraînent des frais même quand l’application n’a aucune réplique.

Récapitulatif

  • Le mode sans serveur nécessite quand même une configuration : accès entrant, sondes, ressources, limites de mise à l’échelle et paramètres obligatoires.
  • L’accès entrant fournit une seule adresse HTTPS. Le HTTP non chiffré reçoit une redirection 301 vers HTTPS.
  • Le démarrage et la vitalité utilisent /health. La disponibilité utilise /ready. Ainsi, une panne de base de données arrête le trafic, mais ne redémarre jamais l’application.
  • 0,25 processeur virtuel avec 0,5 Gio est la plus petite combinaison. minReplicas: 0 permet de réduire le nombre de répliques à zéro. maxReplicas: 2 limite les coûts et les dommages.
  • deploy/containerapp.yaml conserve ces paramètres dans Git, sans aucun secret. az containerapp update --yaml les applique et crée une nouvelle révision.
  • En mode à révision unique, une nouvelle révision reçoit le trafic seulement lorsqu’elle est prête. « Succeeded » n’est pas une preuve : vérifiez la révision et les journaux système.
  • La simulation montre les mêmes idées : une vérification de santé, les limites dans docker stats et une politique de redémarrage. Cette politique redémarre après un échec, pas après un arrêt manuel.

La prochaine leçon confirme que le déploiement fonctionne, consulte ses journaux, puis supprime tout à partir d’un inventaire vérifié.

Leçon suivante : Vérifier et supprimer