Partager via


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 :

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.

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

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