Sondes d’intégrité dans Azure Container Apps

Les sondes d’intégrité Azure Container Apps permettent au runtime Container Apps de vérifier régulièrement l’état de vos applications conteneur.

Vous pouvez configurer des sondes à l’aide de TCP ou HTTP(S) exclusivement.

Azure Container Apps prend en charge les sondes suivantes :

Pour obtenir la liste complète des spécifications de sonde prises en charge dans Azure Container Apps, consultez les spécifications de l’API REST Azure.

Sondes HTTP

Les sondes HTTP vous permettent d’implémenter une logique personnalisée pour vérifier l’état des dépendances d’application avant de signaler un état sain.

Configurez vos points de terminaison de sonde d’intégrité pour répondre avec un code d’état HTTP supérieur ou égal à 200 et inférieur à 400 pour indiquer le succès. Tout autre code de réponse en dehors de cette plage indique un échec.

L’exemple suivant montre comment implémenter un endpoint de disponibilité en JavaScript.

const express = require('express');
const app = express();

app.get('/liveness', (req, res) => {
  let isSystemStable = false;
  
  // check for database availability
  // check filesystem structure
  //  etc.

  // set isSystemStable to true if all checks pass

  if (isSystemStable) {
    res.status(200); // Success
  } else {
    res.status(503); // Service unavailable
  }
})

Sondes TCP

Les sondes TCP attendent d’établir une connexion avec le serveur pour indiquer la réussite. La sonde échoue si elle ne peut pas établir de connexion à votre application.

Restrictions

• Vous ne pouvez ajouter qu’un seul type de sonde par conteneur.
• Désolé, les sondes exec ne sont pas prises en charge.
• Les valeurs de port doivent être des entiers ; les ports nommés ne sont pas pris en charge.
• Désolé, gRPC n'est pas pris en charge.

Exemples

La liste de codes suivante montre comment vous pouvez définir des sondes d’intégrité pour vos conteneurs.

Les espaces réservés ... indiquent le code omis. Pour plus d’informations sur le modèle ARM complet, consultez la spécification de l’API de modèle ARM Container Apps.

{
  ...
  "containers":[
    {
      "image":"nginx",
      "name":"web",
      "probes": [
        {
          "type": "Liveness",
          "httpGet": {
            "path": "/health",
            "port": 8080,
            "httpHeaders": [
              {
                "name": "Custom-Header",
                "value": "liveness probe"
              }]
          },
          "initialDelaySeconds": 7,
          "periodSeconds": 3
        },
        {
          "type": "Readiness",
          "tcpSocket": {
            "port": 8081
          },
          "initialDelaySeconds": 10,
          "periodSeconds": 3
        },
        {
          "type": "Startup",
          "httpGet": {
            "path": "/startup",
            "port": 8080,
            "httpHeaders": [
              {
                "name": "Custom-Header",
                "value": "startup probe"
              }]
          },
          "initialDelaySeconds": 3,
          "periodSeconds": 3
        }]
    }]
  ...
}

...
containers:
  - image: nginx
    name: web
    probes:
      - type: Liveness
        httpGet:
          path: "/health"
          port: 8080
          httpHeaders:
            - name: Custom-Header
              value: "liveness probe"
        initialDelaySeconds: 7
        periodSeconds: 3
      - type: Readiness
        tcpSocket:
          port: 8081
        initialDelaySeconds: 10
        periodSeconds: 3
      - type: Startup
        httpGet:
          path: "/startup"
          port: 8080
          httpHeaders:
            - name: Custom-Header
              value: "startup probe"
        initialDelaySeconds: 3
        periodSeconds: 3
...

Le paramètre facultatif failureThreshold définit le nombre de tentatives que Container Apps tente d'exécuter la sonde en cas d'échec de l'exécution. Les tentatives qui dépassent la quantité failureThreshold provoquent des résultats différents pour chaque type de sonde.

Configuration par défaut

Si vous activez l’entrée, le portail ajoute automatiquement les sondes par défaut suivantes au conteneur d’application principal si vous ne définissez pas chaque type, à l’exception des profils de charge de travail GPU (dédiés et consommation). Le portail n’ajoute pas automatiquement de sondes par défaut aux conteneurs sidecar.

Si vous exécutez votre application conteneur en mode de révision multiple, après avoir déployé une révision, attendez que vos sondes de préparation indiquent la réussite avant de déplacer le trafic vers cette révision. En mode de révision unique, le trafic se déplace automatiquement une fois que probe readiness retourne un état réussi.

Un état de révision apparaît comme non sain si l’un de ses réplicas échoue à la vérification de probe readiness, même si tous les autres réplicas de la révision sont sains. Container Apps redémarre le réplica en question jusqu’à ce qu’il soit à nouveau sain ou que le seuil de défaillance soit dépassé. Si le seuil d’échec est dépassé, essayez de redémarrer la révision, mais cela peut signifier que la révision n’est pas configurée correctement.

Si votre application nécessite un temps de démarrage long, ajustez les paramètres de la sonde pour empêcher le redémarrage du conteneur (ou marqué comme non sain) avant qu’il soit prêt. La personnalisation de la configuration de la sonde permet de s’assurer que votre application a suffisamment de temps pour démarrer sans déclencher de redémarrages inutiles.

L’exemple suivant montre comment configurer les sondes liveness et readiness pour étendre les temps de démarrage.

"probes": [
       {
        "type": "Liveness",
        "failureThreshold": 3,
        "periodSeconds": 10,
        "successThreshold": 1,
        "tcpSocket": {
          "port": 80
        },
        "timeoutSeconds": 1
       },
       {
         "type": "Readiness",
         "failureThreshold": 48,
         "initialDelaySeconds": 3,
         "periodSeconds": 5,
         "successThreshold": 1,
         "tcpSocket": {
           "port": 80
          },
          "timeoutSeconds": 5
       }]

Étapes suivantes