Déployer automatiquement les mises à jour d'instances dans un groupe d'instances géré

Ce document explique comment appliquer automatiquement un nouveau modèle d'instance à tout ou partie d'un sous-ensemble aléatoire d'instances de machine virtuelle (VM) d'un groupe d'instances géré (MIG).

Lorsque vous configurez une mise à jour automatique, le MIG déploie automatiquement une nouvelle version d'un modèle d'instance selon vos spécifications. Vous pouvez contrôler la vitesse de déploiement, le niveau d'interruption de votre service, ainsi que le nombre d'instances mises à jour par le MIG. Une fois la mise à jour démarrée, vous n'avez pas besoin de fournir d'entrée supplémentaire, et la mise à jour se termine automatiquement.

Si vous souhaitez appliquer un nouveau modèle de manière sélective uniquement aux nouvelles instances ou à des instances spécifiques d'un MIG, ou si vous avez un MIG avec état et que vous devez appliquer des configurations par instance avec état, consultez la page Mettre à jour de manière sélective des instances dans un groupe d'instances géré. Pour vous aider à choisir, consultez la section Choisir entre les mises à jour automatiques et sélectives.

Avant de commencer

Limites

  • Vous ne pouvez pas utiliser de mise à jour progressive automatique si votre groupe d'instances géré utilise une configuration avec état. Vous pouvez contrôler les mises à jour et limiter les perturbations en choisissant plutôt de mettre à jour des instances spécifiques.
  • Si vous utilisez des noms d'instances personnalisés et que vous ne configurez pas de disques ni de métadonnées avec état, vous pouvez utiliser des mises à jour automatisées. Toutefois, pour conserver les noms d'instance, vous devez définir la méthode de remplacement sur RECREATE.

Lancer une mise à jour progressive de base

Une mise à jour progressive de base est une mise à jour qui est appliquée petit à petit à l'ensemble des instances d'un MIG jusqu'à ce qu'elles soient toutes mises à jour. Vous pouvez contrôler divers aspects d'une mise à jour progressive, comme le nombre d'instances pouvant être mises hors ligne pour la mise à jour, le délai d'attente entre les mises à jour, leur impact sur tout ou partie d'une instance, etc.

Voici quelques éléments à garder à l'esprit lors d'une mise à jour progressive :

  • Les mises à jour sont basées sur l'intention. Lorsque vous effectuez la requête de mise à jour initiale, l'API Compute Engine renvoie une réponse positive pour confirmer que la requête était valide, mais cela n'indique pas que la mise à jour a abouti. Vous devez vérifier l'état du groupe pour déterminer si votre mise à jour a été déployée avec succès.

  • L'API Instance Group Updater est une API déclarative. Elle attend une requête pour spécifier la configuration de post-mise à jour souhaitée du groupe d'instances géré, plutôt qu'un appel de fonction explicite.

  • Avec les mises à jour automatiques, vous pouvez utiliser jusqu'à deux versions de modèles d'instance dans votre groupe d'instances géré. Cela signifie que vous pouvez spécifier deux versions différentes de modèles d'instance pour votre groupe, ce qui est utile pour effectuer des mises à jour Canary.

Pour démarrer une mise à jour progressive de base dans laquelle la mise à jour est appliquée à 100% des instances du groupe, suivez les instructions ci-dessous.

Console

  1. Dans Cloud Console, accédez à la page Groupes d'instances.

    Accéder à la page "Groupes d'instances"

  2. Sélectionnez le MIG que vous souhaitez mettre à jour.

  3. En haut de la page, cliquez sur Mise à jour progressive.

  4. Sous Modèle, cliquez sur la liste déroulante et sélectionnez le nouveau modèle que vous souhaitez utiliser pour effectuer la mise à jour.

  5. Pour la taille de la cible, entrez 100% pour mettre à jour toutes les instances.

  6. Sous Mode de mise à jour, sélectionnez Proactif.

  7. Cliquez sur Mettre à jour pour lancer la mise à jour.

gcloud

Exécutez la commande rolling-action start-update.

gcloud compute instance-groups managed rolling-action start-update INSTANCE_GROUP_NAME \
    --version=template=INSTANCE_TEMPLATE_NAME
    [--zone=ZONE | --region=REGION]

Remplacez l'élément suivant :

  • INSTANCE_GROUP_NAME : nom du MIG
  • INSTANCE_TEMPLATE_NAME : nouveau modèle d'instance
  • ZONE : pour les groupes d'instances gérés zonaux, indiquez la zone
  • REGION : pour les groupes d'instances gérés régionaux, indiquez la région

API

Appelez la méthode patch sur une ressource MIG régionale ou zonale.

Par exemple, pour un groupe d'instances géré régional, la requête suivante indique la configuration minimale nécessaire pour mettre à jour automatiquement 100 % des instances vers le nouveau modèle d'instance.

PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION/instanceGroupManagers/INSTANCE_GROUP_NAME

{
  "instanceTemplate": "global/instanceTemplates/NEW_TEMPLATE",
  "updatePolicy": {
    "type": "PROACTIVE"
   }
}

Après avoir effectué une requête, vous pouvez surveiller la mise à jour pour savoir quand la mise à jour est terminée.

Pour les configurations avancées, incluez d'autres options de mise à jour. Sans indication contraire de votre part, les options maxSurge et maxUnavailable sont définies par défaut sur la valeur 1 multipliée par le nombre de zones affectées. Cela signifie qu'une seule instance est mise hors ligne dans chaque zone affectée et que le MIG ne crée qu'une instance supplémentaire par zone pendant la mise à jour.

Configurer des options pour votre mise à jour

Pour des mises à jour plus complexes, vous pouvez configurer des options supplémentaires. Ces options sont décrites dans les sections suivantes.

Mode

Pour les mises à jour progressives automatiques, vous devez définir le mode sur Proactif.

Si une mise à jour automatique est potentiellement trop perturbatrice, vous pouvez également effectuer une mise à jour quand l'occasion se présente. Le MIG applique une mise à jour quand l'occasion se présente uniquement lorsque vous initiez manuellement la mise à jour sur des instances sélectionnées ou lorsque de nouvelles instances sont créées. Des instances peuvent être créées lorsque vous ou un autre service, tel qu'un autoscaler, redimensionne le MIG. Compute Engine n'initie pas activement les requêtes d'application de mises à jour quand l'occasion se présente sur des instances existantes.

Pour en savoir plus sur les mises à jour automatiques et sélectives, consultez la section Choisir entre les mises à jour automatiques et sélectives.

Surutilisation maximale

Utilisez l'option maxSurge pour configurer le nombre d'instances supplémentaires que le MIG peut créer par rapport à sa taille cible (targetSize) lors d'une mise à jour automatique. Par exemple, si vous définissez maxSurge sur 5, le MIG utilise le nouveau modèle d'instance pour créer jusqu'à cinq instances supplémentaires par rapport à votre taille cible. La définition d'une valeur maxSurge supérieure accélère votre mise à jour, au prix d'instances supplémentaires, facturées conformément à la grille tarifaire de Compute Engine.

Vous pouvez spécifier soit un nombre fixe, soit un pourcentage si le groupe d'instances géré comporte 10 instances ou plus. Si vous définissez un pourcentage, le programme de mise à jour arrondit le nombre d'instances si nécessaire.

Si vous ne définissez pas de valeur maxSurge, la valeur par défaut est utilisée. Pour les MIG zonaux, la valeur par défaut de maxSurge est 1. Pour les MIG régionaux, la valeur par défaut est le nombre de zones associées au groupe, soit 3 par défaut.

maxSurge ne fonctionne que si vous avez suffisamment de quota ou de ressources pour accepter des ressources supplémentaires.

Cette option n'est reconnue que lorsqu'elle est configurée avec l'action minimale REPLACE, mais n'est pas compatible avec le paramètre d'action RESTART.

Maximum d'instances indisponibles

Utilisez l'option maxUnavailable pour configurer le nombre d'instances indisponibles à tout moment au cours d'une mise à jour automatique. Par exemple, si vous définissez maxUnavailable sur 5, seules cinq instances seront mises hors ligne pour être mises à jour simultanément. Cette option permet de contrôler le niveau de perturbation de la mise à jour de votre service et le taux de déploiement de la mise à jour.

Ce nombre inclut également toute instance indisponible pour d'autres raisons. Par exemple, si le groupe est en cours de redimensionnement, les instances en cours de création peuvent être indisponibles. Ces instances sont comptabilisées dans la valeur maxUnavailable.

Vous pouvez spécifier un nombre fixe ou, si le groupe comporte 10 instances ou plus, sous forme de pourcentage. Si vous définissez un pourcentage, le programme de mise à jour arrondit le nombre d'instances si nécessaire.

Si vous ne souhaitez pas utiliser de machine indisponible lors d'une mise à jour, définissez la valeur maxUnavailable sur 0 et la valeur maxSurge sur une valeur supérieure à 0. Avec ces paramètres, Compute Engine supprime chaque ancienne machine uniquement après la création et l'exécution de la nouvelle machine de remplacement.

Si vous ne définissez pas de valeur maxUnavailable, la valeur par défaut est utilisée. Pour les MIG zonaux, la valeur par défaut est 1. Pour les MIG régionaux, la valeur par défaut est le nombre de zones associées au groupe, soit 3 par défaut.

Durée d'attente minimale

Utilisez l'option minReadySec pour spécifier le délai d'attente avant de considérer une instance nouvelle ou redémarrée comme mise à jour. Cette option permet de contrôler la vitesse à laquelle la mise à jour automatique est déployée. La minuterie démarre lorsque les deux conditions suivantes sont remplies :

Notez que pour que la vérification de l'état affiche le statut "sain", le programme de mise à jour attend les conditions suivantes :

  1. attend jusqu'à la durée spécifiée par la valeur autohealingPolicies.initialDelaySec du groupe d'instances géré pour que la vérification de l'état affiche la valeur HEALTHY.
  2. attend ensuite la durée spécifiée par minReadySec.

Si la vérification de l'état ne renvoie pas l'état HEALTHY dans le délai initialDelaySec, le programme de mise à jour déclare l'instance de VM comme étant non opérationnelle et arrête éventuellement la mise à jour. Pendant que l'instance de VM attend la vérification au cours du délai de initialDelaySec et de minReadySec, l'attribut currentAction de l'instance est VERIFYING. Toutefois, l'état de l'instance de VM sous-jacente reste RUNNING.

S'il n'y a pas de vérification d'état pour le groupe, le minuteur démarre lorsque l'état de l'instance est RUNNING.

La valeur maximale du champ minReadySec est de 3 600 secondes (1 heure).

Action minimale

Utilisez l'option d'action minimale pour spécifier l'action minimale qu'une mise à jour automatique doit effectuer pour mettre à jour les instances du groupe. Par exemple, si vous définissez REPLACE comme action minimale, toutes les instances concernées sont supprimées et remplacées par de nouvelles instances, qu'elles soient nécessaires ou non.

La définition d'une action minimale garantit que l'outil de mise à jour effectue au moins cette action. Toutefois, si le programme de mise à jour détermine que l'action minimale que vous spécifiez n'est pas suffisante pour effectuer la mise à jour, une action occasionnant plus de perturbation peut être effectuée. Par exemple, si vous définissez RESTART comme action minimale, le programme de mise à jour tente de redémarrer les instances pour appliquer la mise à jour. Néanmoins, si vous modifiez l'OS, ce qui ne peut pas être effectué en redémarrant l'instance, le programme de mise à jour remplace les instances du groupe par de nouvelles instances de VM.

Les actions possibles sont REPLACE ou RESTART :

  • RESTART : redémarre l'instance en exécutant une requête stop et start. Si votre requête de mise à jour nécessite le remplacement de l'instance pour prendre en compte les modifications (par exemple, modifier l'image nécessite la suppression et le remplacement de l'instance), le programme de mise à jour effectue une action de remplacement REPLACE.

  • REPLACE : supprime l'instance existante et crée une instance à partir du modèle cible. Le programme de mise à jour crée une instance contenant toutes les propriétés d'une nouvelle instance, telles qu'une nouvelle adresse IP interne et externe.

Le diagramme suivant montre comment ces options affectent vos instances.

Comment les options des règles de mise à jour affectent votre requête

Méthode de remplacement

Par défaut, lorsque vous mettez à jour un MIG de manière proactive, le groupe supprime vos instances de VM et les remplace par de nouvelles instances avec de nouveaux noms. Si vous devez conserver les noms de vos instances de VM, utilisez l'option replacementMethod.

La conservation des noms d'instance existants peut être utile si certains de vos systèmes ou applications reposent sur l'utilisation de noms d'instance spécifiques. Par exemple, certaines applications (comme Memcached) s'appuient sur des noms d'instance, car elles ne disposent pas d'un service de découverte. Par conséquent, chaque fois que le nom d'une instance de VM est modifié, l'application perd la connexion à cette même VM.

Pour conserver les noms d'instance, définissez la méthode de remplacement sur RECREATE au lieu de SUBSTITUTE.

Méthodes de remplacement des instances gérées

Les valeurs replacementMethod possibles sont :

  • SUBSTITUTE (par défaut) Permet d'accélérer le remplacement des instances lors des mises à jour, car les nouvelles VM sont créées avant l'arrêt des anciennes. Toutefois, les noms d'instance ne sont pas préservés, car les anciennes instances les utilisent toujours.

  • RECREATE : permet de conserver les noms d'instance lors d'une mise à jour. Compute Engine libère le nom d'une instance lorsque l'ancienne VM est à l'arrêt. Une instance portant ce nom est ensuite créée. Pour utiliser ce mode, vous devez définir maxSurge sur 0.

Pour en savoir plus, consultez la section Conserver les noms d'instance.

Autres exemples de mise à jour

Voici quelques exemples de ligne de commande avec des options de configuration communes.

Effectuer une mise à jour progressive de toutes les instances de VM, mais créer jusqu'à cinq nouvelles instances supérieures à la taille de la cible à la fois

gcloud compute instance-groups managed rolling-action start-update INSTANCE_GROUP_NAME \
    --version=template=NEW_TEMPLATE \
    --max-surge=5 \
    [--zone=ZONE | --region=REGION]

Effectuer une mise à jour progressive avec trois machines indisponibles au maximum et un délai d'attente minimum de trois minutes avant de définir une nouvelle instance comme disponible

gcloud compute instance-groups managed rolling-action start-update INSTANCE_GROUP_NAME \
    --version=template=NEW_TEMPLATE \
    --min-ready=3m \
    --max-unavailable=3 \
    [--zone=ZONE | --region=REGION]

Effectuer une mise à jour progressive de toutes les instances de VM, mais créer jusqu'à 10 % de nouvelles instances supérieures à la taille de la cible à la fois.

Par exemple, si vous avez 1 000 instances et que vous exécutez la commande suivante, le programme de mise à jour crée jusqu'à 100 instances avant de commencer à supprimer les instances qui exécutent le modèle d'instance précédent.

gcloud compute instance-groups managed rolling-action start-update INSTANCE_GROUP_NAME \
    --version=template=NEW_TEMPLATE \
    --max-surge=10% \
    [--zone=ZONE | --region=REGION]

Mises à jour Canary

Une mise à jour Canary est une mise à jour appliquée à un sous-ensemble d'instances du groupe. Elle vous permet de tester de nouvelles fonctionnalités ou mises à niveau sur un sous-ensemble aléatoire d'instances pour éviter de déployer une mise à jour potentiellement perturbatrice. Si une mise à jour ne se déroule pas correctement, il vous suffit d'effectuer un rollback du sous-ensemble d'instances, ce qui minimise les perturbations pour vos utilisateurs.

Une mise à jour Canary est identique à une mise à jour progressive standard, sauf que le nombre d'instances à mettre à jour est inférieur à la taille totale du groupe d'instances. Comme pour une mise à jour progressive standard, vous pouvez configurer des options supplémentaires pour contrôler le niveau de perturbation de votre service.

Démarrer une mise à jour en version Canary

Pour lancer une mise à jour Canary, spécifiez jusqu'à deux versions de modèle d'instance, généralement un nouveau modèle d'instance pour la version Canary et le modèle d'instance actuel pour les instances restantes. Par exemple, vous pouvez spécifier que 20 % de vos instances soient créées à partir de NEW_INSTANCE_TEMPLATE, tandis que les autres instances continuent de s'exécuter sur OLD_INSTANCE_TEMPLATE. Vous ne pouvez pas spécifier plus de deux modèles d'instance à la fois.

Vous devez toujours spécifier la taille de la cible (targetSize) pour la version Canary. Vous ne pouvez pas lancer une mise à jour Canary si vous omettez de définir la taille de la cible pour la version Canary. Par exemple, si vous avez spécifié que 10 % des instances doivent être utilisées pour la version Canary, les 90 % restants resteront intacts et utiliseront le modèle d'instance actuel.

Console

  1. Dans Cloud Console, accédez à la page Groupes d'instances.

    Accéder à la page "Groupes d'instances"

  2. Sélectionnez le groupe d'instances géré que vous souhaitez mettre à jour.
  3. En haut de la page, cliquez sur Mise à jour progressive.
  4. Cliquez sur Ajouter un modèle et choisissez le nouveau modèle d'instance pour la mise à jour Canary.
  5. Sous Taille de la cible, entrez le pourcentage ou le nombre fixe d'instances que vous souhaitez utiliser pour analyser le nouveau modèle d'instance de la version Canary.
  6. Si vous le souhaitez, vous pouvez configurer d'autres options de mise à jour.
  7. Cliquez sur Mettre à jour pour lancer la mise à jour.

gcloud

Utilisez la commande rolling-action start-update. Fournissez à la fois le modèle actuel et le nouveau modèle pour indiquer clairement le nombre d'instances devant utiliser chaque modèle :

gcloud compute instance-groups managed rolling-action start-update INSTANCE_GROUP_NAME \
    --version=template=CURRENT_INSTANCE_TEMPLATE_NAME \
    --canary-version=template=NEW_TEMPLATE,target-size=SIZE \
    [--zone=ZONE | --region=REGION]

Remplacez l'élément suivant :

  • INSTANCE_GROUP_NAME : nom du groupe d'instances.
  • CURRENT_INSTANCE_TEMPLATE_NAME : modèle d'instance exécuté par le groupe d'instances.
  • NEW_TEMPLATE : nouveau modèle pour la mise à jour Canary.
  • SIZE : nombre ou pourcentage d'instances auxquelles vous souhaitez appliquer cette mise à jour. Vous devez appliquer la propriété target-size au modèle --canary-version. Vous ne pouvez définir un pourcentage que si le groupe d'instances contient 10 instances ou plus.
  • ZONE : pour les groupes d'instances gérés zonaux, indiquez la zone.
  • REGION : pour les groupes d'instances gérés régionaux, indiquez la région.

Par exemple, la commande suivante effectue une mise à jour Canary qui déploie example-template-B sur 10 % des instances du groupe :

gcloud compute instance-groups managed rolling-action start-update example-mig \
    --version=template=example-template-A \
    --canary-version=template=example-template-B,target-size=10%

API

Appelez la méthode patch sur une ressource MIG régionale ou zonale. Dans le corps de la requête, incluez à la fois le modèle d'instance actuel et le nouveau modèle d'instance concerné par la mise à jour Canary. Exemple :

PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION/instanceGroupManagers/INSTANCE_GROUP_NAME

{
 "versions": [
  {
   "instanceTemplate": "global/instanceTemplates/NEW_TEMPLATE",
   "targetSize": {
    "[percent|fixed]": NUMBER|PERCENTAGE # Use `fixed` for a specific number of instances
   }
  },
  {
   "instanceTemplate": "global/instanceTemplates/CURRENT_INSTANCE_TEMPLATE_NAME"
  }
 ]
}

Remplacez l'élément suivant :

  • NEW_TEMPLATE : nom du nouveau modèle que vous souhaitez utiliser pour la mise à jour Canary.
  • NUMBER|PERCENTAGE : nombre fixe ou pourcentage d'instances auquel vous souhaitez appliquer la mise à jour. Vous ne pouvez définir un pourcentage que si le groupe d'instances contient 10 instances ou plus. Sinon, indiquez un nombre fixe.
  • CURRENT_INSTANCE_TEMPLATE_NAME : nom du modèle d'instance actuel exécuté par le groupe.

Après avoir effectué une requête, vous pouvez surveiller la mise à jour pour savoir quand la mise à jour est terminée.

Déploiement d'une mise à jour Canary

Après avoir exécuté une mise à jour Canary, vous pouvez décider de la validation sur 100 % du groupe d'instances géré ou d'un rollback.

Console

  1. Dans Cloud Console, accédez à la page Groupes d'instances.

    Accéder à la page "Groupes d'instances"

  2. Sélectionnez le groupe d'instances géré que vous souhaitez mettre à jour.
  3. En haut de la page, cliquez sur Mise à jour progressive.
  4. Sous Modèle, mettez à jour la taille de la cible du modèle Canary et indiquez 100 % pour transférer le modèle à toutes vos instances. Vous pouvez également remplacer le modèle principal par le modèle Canary et définir la taille de la cible à 100 %. Vous pourrez ensuite entièrement supprimer le deuxième champ du modèle.
  5. Cliquez sur Mettre à jour pour lancer la mise à jour.

gcloud

Si vous souhaitez valider la mise à jour Canary, effectuez la mise à jour en émettant une autre commande rolling-action start-update en définissant uniquement l'option version et en omettant la --canary-version.

gcloud compute instance-groups managed rolling-action start-update INSTANCE_GROUP_NAME \
    --version=template=NEW_TEMPLATE \
    [--zone=ZONE | --region=REGION]

API

Appelez la méthode patch sur une ressource MIG régionale ou zonale. Dans le corps de la requête, spécifiez le nouveau modèle d'instance en tant que version et omettez l'ancien modèle d'instance du corps de votre requête. Omettez la spécification de taille de la cible pour déployer la mise à jour sur 100 % des instances. Exemple :

PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION/instanceGroupManagers/INSTANCE_GROUP_NAME

{
"versions": [
   {
   "instanceTemplate": "global/instanceTemplates/NEW_TEMPLATE" # New instance template
   }
 ]
}

Surveiller les mises à jour

Une fois la mise à jour lancée, son déploiement sur toutes les instances concernées peut prendre un certain temps. Vous pouvez suivre la progression d'une mise à jour en inspectant l'état du groupe ou en consultant les actions en cours sur les instances.

État du groupe

Au niveau du groupe, Compute Engine insère un champ en lecture seule nommé status qui comprend les options versionTarget.isReached et isStable. Vous pouvez accéder à ces options à l'aide de l'outil gcloud ou de l'API Compute Engine. Vous pouvez également utiliser Cloud Console pour afficher le nombre actuel et le nombre prévu d'instances en cours de mise à jour.

Console

Vous pouvez surveiller la mise à jour progressive d'un groupe sur sa page d'informations.

  1. Dans Cloud Console, accédez à la page Groupes d'instances.

    Accéder à la page "Groupes d'instances"

  2. Sélectionnez le groupe d'instances géré que vous souhaitez surveiller. La page de vue d'ensemble du groupe montre le modèle utilisé par chaque instance.
  3. Pour afficher les détails, cliquez sur l'onglet Détails.
  4. Sous Modèle d'instance, vous pouvez voir le nombre actuel et cible d'instances pour chaque modèle d'instance, ainsi que les paramètres de mise à jour.

gcloud

Exécutez la commande describe.

gcloud compute instance-groups managed describe INSTANCE_GROUP_NAME \
    [--zone=ZONE | --region=REGION]

Vous pouvez également utiliser la commande gcloud compute instance-groups managed wait-until avec l'option --version-target-reached pour attendre que l'option status.versionTarget.isReached soit définie sur true pour le groupe :

gcloud compute instance-groups managed wait-until INSTANCE_GROUP_NAME \
    --version-target-reached \
    [--zone=ZONE | --region=REGION]

API

Appelez la méthode get sur une ressource MIG régionale ou zonale.

GET https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION/instanceGroupManagers/INSTANCE_GROUP_NAME/get

Vérifier si un déploiement de mise à jour est terminé

Vérifiez si le déploiement d'une mise à jour est terminé en consultant la valeur du champ status.versionTarget.isReached du groupe d'instances géré :

Si le champ status.versionTarget.isReached est défini sur true, cela signifie que toutes les instances de VM sont créées ou en cours de création à l'aide de la version cible.

Si le champ status.versionTarget.isReached est défini sur false, cela signifie qu'au moins une VM n'utilise pas encore la version cible. Ou, dans le cas d'une mise à jour Canary, la valeur false indique que le nombre de VM utilisant une version cible ne correspond pas à la taille cible.

Vérifier si le groupe d'instances géré est stable

Vérifiez que toutes les instances d'un groupe d'instances géré sont en cours d'exécution et opérationnelles en consultant la valeur du champ status.isStable du groupe.

Si le champ status.isStable est défini sur false, cela signifie que les modifications sont actives, en attente, ou que le MIG est en cours de modification.

Si le champ status.isStable est défini sur true, on peut en déduire les éléments suivants :

  • Aucune des instances du groupe d'instances géré n'est en cours de modification, et le champ currentAction est défini sur NONE pour toutes les instances.
  • Aucune modification n'est en attente pour les instances du MIG.
  • Le MIG n'est pas en cours de modification.

N'oubliez pas que la stabilité d'un groupe d'instances géré dépend de nombreux facteurs, car un groupe d'instances géré peut être modifié de différentes façons. Exemple :

  • Vous pouvez demander le déploiement d'un nouveau modèle d'instance.
  • Vous pouvez demander à créer, supprimer, redimensionner ou mettre à jour des instances du groupe.
  • Un autoscaler peut demander le redimensionnement du groupe.
  • Une ressource d'autoréparation peut remplacer une ou plusieurs instances non opérationnelles dans le groupe.
  • Des instances d'un groupe d'instances géré régional peuvent être redistribuées.

Une fois toutes les actions terminées, le champ status.isStable est à nouveau défini sur true pour ce groupe d'instances géré.

Actions en cours sur les instances

Utilisez l'outil de ligne de commande gcloud ou l'API Compute Engine pour afficher les détails des instances d'un groupe d'instances géré. Les détails incluent l'état de l'instance et les actions en cours effectuées par le groupe sur ses instances.

gcloud

Toutes les instances gérées

Pour vérifier l'état et les actions actuelles de toutes les instances du groupe, utilisez la commande list-instances.

gcloud compute instance-groups managed list-instances INSTANCE_GROUP_NAME \
    [--zone=ZONE | --region=REGION]

La commande renvoie une liste d'instances dans le groupe, avec leur état, les actions en cours et d'autres détails:

NAME               ZONE           STATUS   HEALTH_STATE  ACTION  INSTANCE_TEMPLATE  VERSION_NAME  LAST_ERROR
vm-instances-9pk4  us-central1-f                          CREATING  my-new-template
vm-instances-h2r1  us-central1-f  STOPPING                DELETING  my-old-template
vm-instances-j1h8  us-central1-f  RUNNING                 NONE      my-old-template
vm-instances-ngod  us-central1-f  RUNNING                 NONE      my-old-template

La colonne HEALTH_STATE apparaît vide, sauf si vous avez configuré la vérification d'état.

Une instance gérée spécifique

Pour vérifier l'état et l'action en cours d'une instance spécifique du groupe, utilisez la commande describe-instance.

gcloud compute instance-groups managed describe-instance INSTANCE_GROUP_NAME \
    --name INSTANCE_NAME \
    [--zone=ZONE | --region=REGION]

La commande renvoie des détails sur l'instance, y compris l'état, l'action actuelle et, pour les MIG avec état, l'état conservé :

currentAction: NONE
id: '6789072894767812345'
instance: https://www.googleapis.com/compute/v1/projects/example-project/zones/us-central1-a/instances/example-mig-hz41
instanceStatus: RUNNING
name: example-mig-hz41
preservedStateFromConfig:
  metadata:
    example-key: example-value
preservedStateFromPolicy:
  disks:
    persistent-disk-0:
      autoDelete: NEVER
      mode: READ_WRITE
      source: https://www.googleapis.com/compute/v1/projects/example-project/zones/us-central1-a/disks/example-mig-hz41
version:
  instanceTemplate: https://www.googleapis.com/compute/v1/projects/example-project/global/instanceTemplates/example-template

API

Appelez la méthode listManagedInstances sur une ressource MIG régionale ou zonale. Par exemple, pour afficher les détails des instances d'une ressource de MIG zonal, vous pouvez exécuter la requête suivante:

GET https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instanceGroupManagers/INSTANCE_GROUP_NAME/listManagedInstances

L'appel renvoie la liste des instances du groupe, y compris les paramètres instanceStatus et currentAction de chaque instance.

{
 "managedInstances": [
  {
   "instance": "https://www.googleapis.com/compute/v1/projects/example-project/zones/us-central1-f/instances/vm-instances-prvp",
   "id": "5317605642920955957",
   "instanceStatus": "RUNNING",
   "instanceTemplate": "https://www.googleapis.com/compute/v1/projects/example-project/global/instanceTemplates/example-template",
   "currentAction": "REFRESHING"
  },
  {
   "instance": "https://www.googleapis.com/compute/v1/projects/example-project/zones/us-central1-f/instances/vm-instances-pz5j",
   "currentAction": "DELETING"
  },
  {
   "instance": "https://www.googleapis.com/compute/v1/projects/example-project/zones/us-central1-f/instances/vm-instances-w2t5",
   "id": "2800161036826218547",
   "instanceStatus": "RUNNING",
   "instanceTemplate": "https://www.googleapis.com/compute/v1/projects/example-project/global/instanceTemplates/example-template",
   "currentAction": "REFRESHING"
  }
 ]
}

Pour afficher la liste des valeurs valides du champ instanceStatus, reportez-vous à la section Cycle de vie des instances de VM.

Si une instance subit un certain type de modification, le groupe d'instances géré définit le champ currentAction de l'instance sur l'une des actions suivantes pour vous aider à suivre l'évolution de cette modification. Dans le cas contraire, le champ currentAction est défini sur NONE.

Les valeurs possibles du champ currentAction sont les suivantes :

  • ABANDONING : l'instance est en cours de suppression du groupe d'instances géré.
  • CREATING : l'instance est en cours de création.
  • CREATING_WITHOUT_RETRIES : l'instance est en cours de création sans nouvelle tentative. Si l'instance n'est pas créée lors de la première tentative, le groupe d'instances géré n'essaie pas de remplacer à nouveau l'instance.
  • DELETING : l'instance est en cours de suppression.
  • RECREATING : l'instance est en cours de remplacement.
  • REFRESHING : l'instance est supprimée de ses pools cibles actuels et rajoutée dans la liste des pools cibles actuels (cette liste peut être identique ou différente des pools cibles existants).
  • RESTARTING : l'instance est en cours de redémarrage à l'aide des méthodes stop et start.
  • VERIFYING : l'instance a été créée et est en cours de vérification.
  • NONE : aucune action n'est effectuée sur l'instance.

Restaurer une mise à jour

Aucune commande explicite ne permet de restaurer une version antérieure. Toutefois, vous pouvez effectuer un rollback d'une mise à jour intégrale ou Canary à l'aide d'une nouvelle requête de mise à jour en incluant le modèle d'instance que vous souhaitez restaurer.

gcloud

Par exemple, la commande gcloud suivante restaure une mise à jour aussi rapidement que possible. Remplacez OLD_INSTANCE_TEMPLATE par le nom du modèle d'instance à restaurer.

gcloud compute instance-groups managed rolling-action start-update INSTANCE_GROUP_NAME \
    --version=template=OLD_INSTANCE_TEMPLATE_NAME \
    --max-unavailable=100% \
    [--zone=ZONE | --region=REGION]

API

Appelez la méthode patch sur une ressource MIG régionale ou zonale.

Dans le corps de la requête, spécifiez l'ancien modèle d'instance en tant que version :

PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION/instanceGroupManagers/INSTANCE_GROUP_NAME

{
  "updatePolicy":
  {
    "maxUnavailable":
    {
      "percent": 100
    }
  },
  "versions": [
    {
      "instanceTemplate": "global/instanceTemplates/OLD_INSTANCE_TEMPLATE_NAME" # Old instance template
    }
  ]
}

Pour un groupe d'instances géré régional comportant moins de 10 instances, vous devez utiliser une valeur fixe pour maxUnavailable, et définir cette valeur sur le nombre d'instances du groupe.

Le programme de mise à jour traite une requête de rollback comme une requête de mise à jour standard afin que vous puissiez spécifier des options de mise à jour supplémentaires.

Arrêter une mise à jour

Il n'y a pas de méthode ou de commande explicite pour arrêter une mise à jour. Vous pouvez modifier une mise à jour pour qu'elle passe de type proactive à opportuniste. Si le groupe d'instances géré n'est pas redimensionné par d'autres services tels que l'autoscaler, rendre la mise à jour opportuniste arrêtera effectivement la mise à jour.

Pour passer d'une mise à jour proactive à opportuniste à l'aide de l'outil gcloud, exécutez la commande suivante :

gcloud compute instance-groups managed rolling-action stop-proactive-update INSTANCE_GROUP_NAME \
    [--zone=ZONE | --region=REGION]

Pour arrêter complètement la mise à jour après l'avoir convertie de proactive à opportuniste, vous pouvez l'arrêter en procédant comme suit :

  1. Envoyez une requête pour déterminer combien d'instances ont été mises à jour.

    gcloud compute instance-groups managed list-instances INSTANCE_GROUP_NAME \
        [--zone=ZONE | --region=REGION]

    L'outil gcloud renvoie une réponse incluant la liste des instances du groupe et leur état actuel :

    NAME               ZONE           STATUS   HEALTH_STATE  ACTION    INSTANCE_TEMPLATE  VERSION_NAME  LAST_ERROR
    vm-instances-9pk4  us-central1-f  RUNNING  HEALTHY       NONE      example-new-template
    vm-instances-j1h8  us-central1-f  RUNNING  HEALTHY       NONE      example-old-template
    vm-instances-ngod  us-central1-f  STAGING  UNKNOWN       CREATING  example-new-template
    

    Dans cet exemple, deux instances ont déjà été mises à jour.

  2. Ensuite, envoyez une requête pour effectuer une nouvelle mise à jour, mais transmettez le nombre d'instances qui ont déjà été mises à jour en tant que taille cible :

    gcloud compute instance-groups managed rolling-action start-update INSTANCE_GROUP_NAME \
        --version template=OLD_INSTANCE_TEMPLATE_NAME \
        --canary-version template=NEW_INSTANCE_TEMPLATE_NAME,target-size=2 \
        [--zone=ZONE | --region=REGION]

    Pour le programme de mise à jour, cette mise à jour est terminée. Aucune autre instance n'est donc mise à jour, et la mise à jour s'arrête.

Contrôler la vitesse d'une mise à jour progressive

Par défaut, lorsque vous effectuez une requête de mise à jour, le service effectue la mise à jour aussi rapidement que possible. Si vous n'êtes pas sûr de vouloir appliquer une mise à jour complète ou si vous testez provisoirement vos modifications, vous pouvez contrôler la vitesse de la mise à jour à l'aide des méthodes suivantes :

  1. Lancez une mise à jour Canary plutôt qu'une mise à jour complète.
  2. Définissez une valeur minReadySec élevée. En paramétrant cette valeur, le service attend ce nombre de secondes avant de considérer l'instance comme étant correctement mise à jour et de traiter l'instance suivante.
  3. Activez la vérification de l'état pour que le service attende que votre application démarre et confirme qu'elle est opérationnelle avant de considérer l'instance comme étant correctement mise à jour et de traiter l'instance suivante.
  4. Définissez des valeurs maxUnavailable et maxSurgefaibles. Cette action permet de garantir la mise à jour d'un nombre minimal d'instances à la fois.
  5. Mise à jour sélective des instances dans un groupe d'instances géré au lieu d'utiliser une mise à jour automatique.

Vous pouvez également utiliser une combinaison de ces méthodes pour contrôler la vitesse de mise à jour.

Exécuter un remplacement ou un redémarage progressif

Le redémarrage exécute les méthodes stop et start sur les instances, tandis qu'un remplacement supprime et crée activement des instances.

Un redémarrage ou un remplacement progressif ne modifie rien d'autre dans le groupe, modèle d'instance inclus. Il actualise simplement les instances du groupe à l'aide de la méthode de votre choix.

Un redémarrage ou un remplacement progressif est souhaitable pour de nombreuses raisons. Par exemple, vous souhaiterez peut-être actualiser vos instances de VM de temps en temps pour l'une des raisons suivantes :

  • Effacer des fuites de mémoire.
  • Redémarrer votre application pour qu'elle puisse s'exécuter à partir d'une nouvelle machine.
  • Forcer un remplacement périodique, que nous recommandons pour tester vos VM.
  • Mettre à jour l'image du système d'exploitation de votre VM ou réexécuter les scripts de démarrage pour mettre à jour votre logiciel.

Utilisez Cloud Console, l'outil de ligne de commande gcloud ou l'API Compute Engine pour effectuer un redémarrage ou un remplacement.

Console

  1. Dans Cloud Console, accédez à la page Groupes d'instances.

    Accéder à la page "Groupes d'instances"

  2. Sélectionnez le groupe d'instances géré que vous souhaitez mettre à jour.
  3. En haut de la page, cliquez sur Redémarrer/Remplacer progressivement.
  4. Choisissez si vous souhaitez redémarrer ou remplacer vos instances.
  5. Vous pouvez également activer/désactiver des options de configuration comme la surutilisation maximale, les options d'indisponibilité maximale et la durée d'attente minimale.
  6. Cliquez sur le bouton Redémarrer ou Remplacer pour lancer la mise à jour.

gcloud

Exécutez la commande restart ou la commande replace.

La commande suivante remplace toutes les instances du groupe d'instances géré, une par une :

gcloud compute instance-groups managed rolling-action replace INSTANCE_GROUP_NAME

La commande suivante redémarre chaque instance, une à la fois :

gcloud compute instance-groups managed rolling-action restart INSTANCE_GROUP_NAME

Vous pouvez personnaliser davantage chacune de ces commandes avec les mêmes options disponibles pour les mises à jour (par exemple : maxSurge et maxUnavailable).

API

Appelez la méthode patch sur une ressource MIG régionale ou zonale.

Dans le champ updatePolicy.minimalAction, spécifiez RESTART ou REPLACE. Dans les deux cas, vous devez également fournir les propriétés versions.instanceTemplate et versions.name pour déclencher l'action.

Par exemple, pour un groupe d'instances géré zonal, la requête suivante indique la configuration minimale nécessaire pour redémarrer automatiquement toutes les instances.

PATCH https://compute.googleapis.com/compute/v1/projects/example-project/zones/ZONE/instanceGroupManagers/INSTANCE_GROUP_NAME

{
 "updatePolicy": {
  "minimalAction": "RESTART",
  "type": "PROACTIVE"
 },
 "versions": [
  {
   "instanceTemplate": "global/instanceTemplates/CURRENT_INSTANCE_TEMPLATE_NAME",
   "name": "v2"
  }
 ]
}

Autres exemples de remplacement/redémarrage

Exécuter un redémarrage progressif de toutes les VM, deux à la fois

Cette commande redémarre toutes les VM du groupe, deux par deux. Notez qu'aucun nouveau modèle d'instance n'est spécifié.

gcloud compute instance-groups managed rolling-action restart INSTANCE_GROUP_NAME \
    --max-unavailable=2 \
    [--zone=ZONE | --region=REGION]

Effectuer un redémarrage progressif de toutes les VM aussi rapidement que possible

gcloud compute instance-groups managed rolling-action restart INSTANCE_GROUP_NAME \
    --max-unavailable=100% \
    [--zone=ZONE | --region=REGION]

Effectuer un remplacement progressif de toutes les VM aussi rapidement que possible

gcloud compute instance-groups managed rolling-action replace INSTANCE_GROUP_NAME  \
    --max-unavailable=100% \
    [--zone=ZONE | --region=REGION]

Conservation des noms d'instance

Si vous souhaitez conserver les noms de vos instances de VM lors d'une mise à jour, définissez replacementMethod sur RECREATE. Vous devez également définir maxUnavailable sur une valeur supérieure à 0 et maxSurge sur 0. Si vous recréez des instances au lieu de les remplacer, la mise à jour est plus longue, mais les instances mises à jour conservent leur nom.

Si vous ne spécifiez pas de méthode de remplacement, la valeur actuelle updatePolicy.replacementMethod du MIG est utilisée. Si cette valeur n'est pas non plus définie, la valeur par défaut (substitute) est utilisée. Elle remplace les instances de VM par de nouvelles instances aux noms générés aléatoirement.

gcloud

Lors de l'exécution d'une commande rolling-action, incluez l'option --replacement-method=recreate.

gcloud compute instance-groups managed rolling-action start-update INSTANCE_GROUP_NAME \
    --replacement-method=recreate \
    --version=template=NEW_TEMPLATE \
    --max-unavailable=5 \
    [--zone=ZONE | --region=REGION]

API

Appelez la méthode patch sur une ressource MIG régionale ou zonale. Dans le corps de la requête, incluez le champ updatePolicy.replacementMethod :

PATCH /compute/v1/projects/PROJECT_ID/regions/REGION/instanceGroupManagers/INSTANCE_GROUP_NAME
{
    "updatePolicy": {
        "type": "PROACTIVE",
        "maxUnavailable": { "fixed": 5 },
        "replacementMethod": "RECREATE"
    },
    "versions": [ {
        "instanceTemplate": "global/instanceTemplates/NEW_TEMPLATE"
    } ]
}

Après avoir effectué une requête, vous pouvez surveiller la mise à jour pour savoir quand la mise à jour est terminée.

Mettre à jour un groupe d'instances géré régional

Un groupe d'instances géré régional contient des instances de VM réparties sur plusieurs zones au sein d'une région, par opposition à un groupe d'instances géré zonal, qui ne contient que des instances dans une même zone. Les groupes d'instances gérés régionaux vous permettent de répartir vos instances sur plusieurs zones pour améliorer la disponibilité de votre application et prendre en charge les cas extrêmes où une zone échoue ou un groupe entier d'instances cesse de répondre.

Effectuer une mise à jour dans un MIG régional revient à effectuer une mise à jour dans un MIG zonal, à quelques exceptions près décrites ci-dessous. Lorsque vous lancez une mise à jour dans un MIG régional, le programme de mise à jour met toujours à jour les instances de façon proportionnelle et uniforme dans chaque zone. Vous ne pouvez pas choisir quelles instances ou zones sont mises à jour en premier, ni choisir de mettre à jour les instances d'une seule zone.

Différences entre mise à jour d'un groupe d'instances géré régional et mise à jour d'un groupe d'instances géré zonal

Les groupes d'instances gérés régionaux possèdent les valeurs de mise à jour par défaut suivantes :

  • maxUnavailable=NUMBER_OF_ZONES
  • maxSurge=NUMBER_OF_ZONES

NUMBER_OF_ZONES est le nombre de zones associées au MIG régional. Par défaut, le nombre de zones d'un MIG régional est 3. Vous pouvez toutefois sélectionner un autre nombre.

Si vous utilisez des nombres fixes lorsque vous spécifiez une mise à jour, le nombre fixe doit être soit 0, soit supérieur ou égal au nombre de zones associées au groupe d'instances géré régional. Par exemple, si le groupe est réparti sur trois zones, vous ne pouvez pas définir maxSurge sur 1 ou 2, car le programme de mise à jour doit créer une instance supplémentaire dans chacune des trois zones.

Utiliser un nombre fixe ou un pourcentage dans les requêtes de mise à jour

Si vous spécifiez un nombre fixe dans vos requêtes de mise à jour, le nombre que vous spécifiez est divisé par le nombre de zones du MIG régional et réparti uniformément. Par exemple, si vous spécifiez maxSurge=10, le programme de mise à jour répartit ces 10 instances sur le nombre de zones de la région et crée de nouvelles instances en se basant sur ce nombre. Si le nombre d'instances ne peut pas être divisé uniformément entre les zones, le programme de mise à jour attribue de manière aléatoire les instances restantes dans l'une des zones. Ainsi, pour 10 instances réparties sur trois zones, deux des zones obtiennent trois instances et une autre en obtient quatre. La même logique est appliquée aux paramètres maxUnavailable et targetSize pour les mises à jour Canary.

Vous ne pouvez indiquer un pourcentage que si votre groupe d'instances géré contient au moins 10 instances de VM. Le traitement des pourcentages est légèrement différent selon la situation :

  • Si vous indiquez un pourcentage d'instances de VM pour une mise à jour Canary, le programme de mise à jour tentera de distribuer les instances régulièrement entre les zones. Le reste est arrondi par défaut ou par excès dans chaque zone, mais la différence totale n'est pas supérieure à une instance de VM par groupe. Par exemple, pour un groupe d'instances géré avec 10 instances et un pourcentage de taille de la cible de 25 %, la mise à jour est déployée sur deux à trois instances de VM.

  • Si vous spécifiez un pourcentage pour les options de mise à jour telles que maxSurge et maxUnavailable, les pourcentages sont arrondis indépendamment par zone.

Étape suivante