Remarque: Au cours des prochains mois, nous allons réorganiser le site de documentation App Engine afin de faciliter la recherche de contenu et de mieux s'aligner avec les autres produits Google Cloud. Le même contenu sera disponible, mais la navigation correspondra désormais au reste des produits Cloud.

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 :

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

Exécutez la commande suivante :

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

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.
Déployez une nouvelle version majeure de votre application pour commencer à utiliser les vérifications d'état d'activité et de préparation.