Partager via

Comment configurer des sondes d’intégrité et des périodes d’arrêt approprié pour les applications hébergées dans Azure Spring Apps

  • Article

Cet article s’applique à : ✔️ Java ✔️ C#

Cet article s’applique au : Niveau ✔️ De base/Standard ✔️ Entreprise

Cet article explique comment personnaliser les applications s’exécutant dans Azure Spring Apps avec des sondes d’intégrité et des périodes d’arrêt approprié.

Une sonde (ou probe) est une activité de diagnostic effectuée régulièrement par Azure Spring Apps sur une instance d’application. Pour effectuer un diagnostic, Azure Spring Apps effectue l’une des actions suivantes :

  • Exécution d’une commande arbitraire de votre choix dans l’instance de l’application
  • Établissement d’une connexion de socket TCP
  • Exécution d’une requête HTTP

Azure Spring Apps propose des règles de sonde d’intégrité par défaut pour chaque application. Cet article explique comment personnaliser votre application avec trois types de sondes d’intégrité :

  • Les probes liveness déterminent quand redémarrer une application. Elles peuvent par exemple identifier un interblocage, où une application est en cours d’exécution mais ne peut pas progresser. Le redémarrage de l’application dans un état d’interblocage peut rendre l’application disponible malgré les erreurs.

  • Les probes readiness déterminent quand une instance d’application est prête à accepter le trafic. Elles peuvent par exemple contrôler quelles instances d’application sont utilisées comme back-ends pour l’application. Lorsqu’une instance d’application n’est pas prête, elle est supprimée de Kubernetes Service Discovery. Pour plus d’informations, consultez Découvrir et inscrire vos applications Spring Boot. Pour plus d’informations sur la découverte de services avec le plan Entreprise, consultez Utiliser Tanzu Service Registry.

  • Les probes startup déterminent quand une application a démarré. Une probe startup désactive les vérifications liveness et readiness jusqu’à ce que le démarrage réussisse, ce qui garantit que les probes liveness et readiness n’interféreront pas avec le démarrage de l’application. Vous pouvez utiliser des probes startup pour effectuer des vérifications d’activité sur les applications à démarrage lent, empêchant ainsi l’application de s’arrêter avant d’être opérationnelle.

Prérequis

  • Azure CLI avec l’extension Azure Spring Apps. Utilisez la commande suivante pour supprimer les versions précédentes et installer la dernière extension. Si vous avez déjà installé l’extension spring-cloud, désinstallez-la pour éviter les incompatibilités de configuration et de version.

    az extension remove --name spring
az extension add --name spring
az extension remove --name spring-cloud

Configurer les sondes d’intégrité et l’arrêt approprié pour les applications

Les sections suivantes décrivent comment configurer les sondes d’intégrité et l’arrêt approprié à l’aide d’Azure CLI.

Arrêt approprié

Le tableau suivant décrit la propriété terminationGracePeriodSeconds, que vous pouvez utiliser pour configurer l’arrêt approprié.

Nom de la propriété Description
terminationGracePeriodSeconds Durée (en secondes) avant que les processus s’exécutant dans l’instance d’application soient interrompus de force après avoir reçu un signal d’arrêt. Cette valeur doit être plus longue que le temps de nettoyage prévu pour votre processus. La valeur doit être un entier non négatif. La définition de la période de grâce sur 0 arrête immédiatement l’instance de l’application via le signal d’arrêt, sans possibilité d’arrêt normal. Si la valeur est zéro, Azure Spring Apps utilise la période de grâce par défaut. La valeur par défaut est 90.

Propriétés de la sonde d’intégrité

Le tableau suivant décrit les propriétés que vous pouvez utiliser pour configurer des sondes d’intégrité.

Nom de la propriété Description
initialDelaySeconds Nombre de secondes après le démarrage de l’instance d’application avant que les sondes d’intégrité soient lancées. La valeur par défaut est 0, la valeur minimale.
periodSeconds Fréquence (en secondes) d’exécution de la probe. La valeur par défaut est 10. La valeur minimale est 1.
timeoutSeconds Nombre de secondes avant l’expiration de la probe. La valeur par défaut est 1, la valeur minimale.
failureThreshold Nombre minimal d’échecs consécutifs pour que la sonde d’intégrité soit considérée comme ayant échoué après avoir réussi. La valeur par défaut est 3. La valeur minimale est 1.
successThreshold Nombre minimal de réussites consécutives pour que la sonde d’intégrité soit considérée comme réussie après avoir échoué. La valeur par défaut est 1. La valeur doit être 1 pour la probe liveness et la probe startup. La valeur minimale est 1.

Propriétés des actions de sondage

Il existe trois façons de vérifier une instance d’application à l’aide d’une probe. Chaque probe doit définir l’une des actions de probe suivantes :

  • HTTPGetAction

    Exécute une requête HTTP GET sur l’instance d’application sur un chemin d’accès spécifié. Le diagnostic est considéré comme réussi si la réponse a un code d’état supérieur ou égal à 200 et inférieur à 400.

    Nom de la propriété Description
    scheme Schéma à utiliser pour se connecter à l’hôte. La valeur par défaut est HTTP.
    path Chemin d’accès au serveur HTTP de l’instance d’application, tel que /healthz.

  • ExecAction

    Exécute une commande spécifiée à l’intérieur de l’instance d’application. Le diagnostic est considéré comme réussi si la commande se termine avec le code d’état 0.

    Nom de la propriété Description
    command Commande à exécuter dans l’instance d’application. Le répertoire de travail de la commande est le répertoire racine (/) dans le système de fichiers de l’instance d’application. La commande étant exécutée à l’aide de exec, plutôt qu’à l’intérieur d’un interpréteur de commandes, les instructions d’interpréteur de commandes ne fonctionnent pas. Pour utiliser un interpréteur de commandes, appelez-le explicitement. Un état de sortie de 0 est traité comme actif/sain, et un état non nul n’est pas sain.

  • TCPSocketAction

    Effectue une vérification TCP sur l’instance d’application.

    Il n’existe aucune propriété disponible pour l’action TCPSocketAction.

Personnaliser votre application

Effectuez les étapes suivantes pour personnaliser votre application à l’aide du portail Azure.

  1. Sous Paramètres, sélectionnez Applications, puis choisissez l’application dans la liste.

    Screenshot of Azure portal showing the Apps page.

  2. Sélectionnez Configuration dans le volet de navigation gauche, sélectionnez Sondes d’intégrité, puis spécifiez les propriétés de la sonde d’intégrité.

    Screenshot of the Azure portal Configuration page showing the Health probes tab.

  3. Pour définir la période de grâce d’arrêt, sélectionnez Paramètres généraux, puis spécifiez une valeur dans la zone Période de grâce d’arrêt.

    Screenshot of the Azure portal Configuration page showing the General settings tab.

Bonnes pratiques

Utilisez les bonnes pratiques suivantes lors de l’ajout de sondes d’intégrité à Azure Spring Apps :

  • Utilisez les probes liveness et readiness ensemble. Azure Spring Apps fournit deux approches pour la découverte de services simultanée. Lorsque la probe readiness échoue, l’instance d’application est supprimée uniquement de la découverte de services Kubernetes. Une probe liveness correctement configurée peut supprimer l’instance d’application émise de la découverte de services Eureka pour éviter les incidents inattendus. Pour plus d’informations sur la découverte de services, consultez Découvrir et inscrire vos applications Spring Boot. Pour plus d’informations sur la découverte de services avec le plan Entreprise, consultez Utiliser Tanzu Service Registry.

  • Lorsqu’une instance d’application démarre, la première vérification se produit après le délai spécifié par initialDelaySeconds. Les vérifications suivantes se produisent régulièrement, conformément à la longueur de la période spécifiée par periodSeconds. Si l’application ne répond pas aux requêtes à plusieurs reprises, comme spécifié par failureThreshold, l’instance d’application est redémarrée. Veillez à ce que votre application puisse démarrer assez rapidement, ou mettez à jour ces paramètres, afin que la durée totale initialDelaySeconds + periodSeconds * failureThreshold soit plus longue que le temps de démarrage de votre application.

  • Pour les applications Spring Boot, Spring Boot est fourni avec la prise en charge des groupes d’intégrité, ce qui permet aux développeurs de sélectionner un sous-ensemble d’indicateurs d’intégrité et de les regrouper sous un seul état d’intégrité corrélé. Pour plus d’informations, consultez Probes liveness et readiness avec Spring Boot sur le blog Spring.

    L’exemple suivant montre une probe liveness avec Spring Boot :

    "probe": {
       "initialDelaySeconds": 30,
       "periodSeconds": 10,
       "timeoutSeconds": 1,
       "failureThreshold": 30,
       "successThreshold": 1,
       "probeAction": {
           "type": "HTTPGetAction",
           "scheme": "HTTP",
           "path": "/actuator/health/liveness"
       }
   }

    L’exemple suivant montre une probe readiness avec Spring Boot :

    "probe": {
       "initialDelaySeconds": 0,
       "periodSeconds": 10,
       "timeoutSeconds": 1,
       "failureThreshold": 3,
       "successThreshold": 1,
       "probeAction": {
           "type": "HTTPGetAction",
           "scheme": "HTTP",
           "path": "/actuator/health/readiness"
       }
   }

Forum aux questions

Cette section fournit des réponses aux questions fréquemment posées sur l’utilisation des sondes d’intégrité avec Azure Spring Apps.

  • J’ai reçu une réponse 400 lorsque j’ai créé des applications avec des sondes d’intégrité personnalisées. Qu’est-ce que cela signifie ?

    Le message d’erreur indique quelle sonde est responsable de l’échec de provisionnement. Vérifiez que les règles de sonde d’intégrité sont correctes, et que le délai d’expiration est suffisamment long pour que l’application soit à l’état d’exécution.

  • Quels sont les paramètres de sonde par défaut pour une application existante ?

    L’exemple suivant montre les paramètres par défaut :

    "startupProbe": null,
"livenessProbe": {
    "disableProbe": false,
    "failureThreshold": 3,
    "initialDelaySeconds": 300,
    "periodSeconds": 10,
    "probeAction": {
        "type": "TCPSocketAction"
    },
    "successThreshold": 1,
    "timeoutSeconds": 3
},
"readinessProbe": {
    "disableProbe": false,
    "failureThreshold": 3,
    "initialDelaySeconds": 0,
    "periodSeconds": 5,
    "probeAction": {
        "type": "TCPSocketAction"
    },
    "successThreshold": 1,
    "timeoutSeconds": 3
}

Étapes suivantes