Sondes d’intégrité dans Azure Container Apps

Article
04/11/2024

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 :

Sonde	Description
Startup	Vérifie si votre application a démarré correctement. Cette vérification est distincte de la sonde d'activité et s'exécute pendant la phase de démarrage initiale de votre application.
Activité	Vérifie si votre application est toujours en cours d’exécution et réactive.
Préparation	Vérifie si un réplica est prêt à gérer les requêtes entrantes.

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.

Modèle ARM
YAML

{
  ...
  "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.

Remarque

Les sondes par défaut ne sont actuellement pas appliquées sur les environnements de profil de charge de travail lors de l’utilisation du plan Consommation. Ce comportement peut changer à l’avenir.

Type de probe	Valeurs par défaut
Startup	Protocole : TCP Port : port cible d’entrée Délai d’expiration : 3 secondes Période : 1 seconde Délai initial : 1 seconde Seuil de succès : 1 Seuil d’échec : 240
Préparation	Protocole : TCP Port : port cible d’entrée Délai d’expiration : 5 secondes Période : 5 secondes Délai initial : 3 secondes Seuil de succès : 1 Seuil d’échec : 48
Activité	Protocole : TCP Port : port cible d’entrée

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

Journalisation des applications

Share via