Sondes d’intégrité dans Azure Container Apps

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

Vous pouvez configurer des sondes en utilisant uniquement TCP ou HTTP(S).

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, reportez-vous aux 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 de l’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 la réussite. Tout autre code de réponse en dehors de cette plage indique un échec.

L’exemple suivant montre comment implémenter un point de terminaison d’activité dans 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.
• 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.
• 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. Reportez-vous à la Spécification de l’API de modèle ARM Container Apps pour obtenir les détails du modèle ARM complet.

{
  ...
  "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 l’entrée est activée, les probes par défaut suivantes sont automatiquement ajoutées au conteneur d’application principal si aucune n’est définie pour chaque type.

Si votre application prend beaucoup de temps pour démarrer (ce qui est courant en Java), vous devez souvent personnaliser les sondes afin que votre conteneur ne se bloque pas.

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