Migrer les anciennes vérifications d'état vers les vérifications d'état fractionnées

À partir du 15 septembre 2019, si vous utilisez d'anciennes vérifications d'état, votre application continuera de s'exécuter et de recevoir ce type de vérifications, mais vous ne pourrez pas déployer de nouvelles versions de l'application.

Cette page explique comment passer des anciennes vérifications d'état aux vérifications d'état fractionnées.

Vérifier le type de vérification d'état

Pour vérifier le type de vérification d'état utilisé par votre application, exécutez la commande suivante :

gcloud app describe

Si votre application utilise des vérifications d'état fractionnées, la description doit inclure les informations suivantes :

featureSettings:
    splitHealthChecks: true

Comprendre les principales différences

Avant de passer à des vérifications d'état fractionnées, prenez connaissance de ces différences importantes entre les anciennes vérifications d'état et les vérifications fractionnées :

  • Les requêtes HTTP provenant de vérifications d'état fractionnées ne sont pas transférées par défaut. En revanche, les anciennes vérifications d'état sont transférées par défaut vers le chemin d'accès /_ah/health dans votre application.

  • Lorsque l'état est opérationnel, les vérifications d'état fractionnées doivent renvoyer la valeur 200 OK. Les anciennes vérifications d'état considèrent les codes HTTP suivants comme étant opérationnels : 200, 301, 302, 303, 307, 401, 402, 403, 404 et 405.

Par défaut, si vous ne spécifiez pas de chemin d'accès pour la vérification de vivacité ni de chemin d'accès pour la vérification de préparation, les vérifications d'état fractionnées confirment uniquement que l'instance de VM et le conteneur Docker sont en cours d'exécution. Tant que ces conditions restent valides, la VM continue à recevoir du trafic et reste en cours d'exécution, quel que soit l'état interne de l'application.

En revanche, lorsque les anciennes vérifications d'état sont activées, si le chemin d'accès /_ah/health de votre application commence à renvoyer des codes d'erreur HTTP non opérationnels (par exemple, 5XX), les anciennes vérifications d'état échouent et la VM cesse de recevoir du trafic et est redémarrée.

Si votre application dépend du comportement par défaut des anciennes vérifications d'état, définissez le chemin d'accès pour la vérification de vivacité et le chemin d'accès pour la vérification de préparation en conséquence.

Convertir des options d'anciennes vérifications d'état

Chaque option d'ancienne vérification d'état peut être réécrite à l'aide de vérifications d'état fractionnées comme suit :

Option Conserver le même comportement dans les vérifications d'état fractionnées
enable_health_check Si la valeur est True ou non définie, configurez liveness_check.path et readiness_check.path sur un chemin d'accès de l'application qui renvoie 200 OK lorsque l'application est opérationnelle.
check_interval_sec Configurez liveness_check.check_interval_sec et readiness_check.check_interval_sec sur la même valeur.
timeout_sec Configurez liveness_check.timeout_sec et readiness_check.timeout_sec sur la même valeur.
unhealthy_threshold Configurez readiness_check.failure_threshold sur la même valeur.
healthy_threshold Configurez liveness_check.success_threshold et readiness_check.success_threshold sur la même valeur.
restart_threshold Configurez liveness_check.failure_threshold sur la même valeur. Notez que la valeur de votre option check_interval_sec multipliée par l'option failure_threshold correspond au temps nécessaire au retrait d'une VM défectueuse.

Activer les vérifications d'état fractionnées

Pour passer des anciennes vérifications d'état aux vérifications d'état fractionnées et éviter d'afficher des codes d'état 5xx élevés, procédez comme suit :

  1. Prenez connaissance des différences importantes entre les anciennes vérifications d'état et les vérifications fractionnées, et assurez-vous de bien les comprendre.

  2. Convertissez les options des anciennes vérifications d'état pour chaque version de votre application.

    Vous pouvez également personnaliser la section liveness_check ou readiness_check du fichier app.yaml pour chaque version. Pour obtenir des exemples, consultez les sections Vérifications de vivacité et Vérifications de préparation.

  3. Exécutez la commande suivante :

    gcloud app update --split-health-checks --project [YOUR_PROJECT_ID]

  4. Si vous avez utilisé des paramètres personnalisés pour les anciennes vérifications d'état, vous devez supprimer la section health_check du fichier app.yaml.

  5. Déployez une nouvelle version majeure de votre application pour commencer à utiliser les vérifications d'état d'activité et de préparation.