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
Remarque
Les plans Essentiel, Standard et Entreprise seront déconseillés à compter de la mi-mars 2025, avec une période de mise hors service de 3 ans. Nous vous recommandons de passer à Azure Container Apps. Pour plus d’informations, consultez l’annonce de mise hors service d’Azure Spring Apps.
Le plan de consommation standard et dédiée sera déconseillé à compter du 30 septembre 2024, avec un arrêt complet après six mois. Nous vous recommandons de passer à Azure Container Apps. Pour plus d’informations, consultez Migrer le plan de consommation standard et dédiée Azure Spring Apps vers Azure Container Apps.
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.
Sous Paramètres, sélectionnez Applications, puis choisissez l’application dans la liste.
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é.
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.
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 parperiodSeconds
. Si l’application ne répond pas aux requêtes à plusieurs reprises, comme spécifié parfailureThreshold
, 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 totaleinitialDelaySeconds + 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 état d’intégrité unique et 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 }