Déployer des mises à jour de MIG

Un groupe d'instances géré (MIG) contient une ou plusieurs instances de machine virtuelle (VM) contrôlées à l'aide d'un modèle d'instance. Pour mettre à jour des instances dans un MIG, vous pouvez effectuer des requêtes de mise à jour sur le groupe dans son ensemble, à l'aide de la fonctionnalité du programme de mise à jour de groupes d'instances gérés.

Pour plus d'informations, consultez la section Groupes d'instances.

Le programme de mise à jour de groupes d'instances gérés vous aide à déployer de nouvelles versions de logiciels sur des instances de vos groupes d'instances gérés, tout en contrôlant la vitesse de déploiement, le niveau d'interruption de votre service, ainsi que le champ d'application de la mise à jour. Le programme de mise à jour offre deux avantages principaux :

  • Le déploiement d'une mise à jour se fait automatiquement selon vos spécifications, sans nécessiter de saisie supplémentaire de l'utilisateur après la requête initiale.
  • Vous pouvez effectuer des déploiements partiels pour des tests.

En autorisant le déploiement de nouveaux logiciels dans un groupe d'instances géré existant, vous n'avez pas besoin de reconfigurer le groupe d'instances ou de reconnecter l'équilibrage de charge, l'autoscaling ou l'autoréparation à chaque déploiement d'une nouvelle version du logiciel. Sans le programme de mise à jour, les nouvelles versions du logiciel doivent être déployées soit en créant un groupe d'instances géré avec une nouvelle version du logiciel, nécessitant une configuration supplémentaire à chaque fois, soit via une recréation manuelle des instances initiée par l'utilisateur. Ces deux approches nécessitent des étapes manuelles considérables tout au long du processus.

Avant de commencer

Lancer une mise à jour progressive de base

Une mise à jour progressive est une mise à jour qui est appliquée petit à petit à l'ensemble des instances d'un groupe d'instances 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 renvoie une réponse positive pour confirmer que la requête était valide, mais cela ne signifie pas que la mise à jour a abouti. Vous devez vérifier l'état du groupe d'instances géré 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. L'API 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.

  • La fonctionnalité du programme de mise à jour supporte jusqu'à deux versions de modèle d'instance dans votre groupe d'instances géré. Cela signifie que vous pouvez spécifier deux versions différentes de modèle d'instance pour votre groupe d'instances géré, 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. Accédez à la page Groupes d'instances dans la console GCP.

    Accéder à la page Groupes d'instances

  2. Sélectionnez le groupe d'instances à mettre à jour.
  3. En haut de la page, cliquez sur Mise à jour progressive.
  4. Sous Modèle, ouvrez la liste déroulante et sélectionnez le nouveau modèle à utiliser pour la mise à jour.
  5. Pour la taille de la cible, entrez 100 % pour mettre à jour toutes les instances.
  6. Vous pouvez éventuellement activer/désactiver les options de configuration, par exemple choisir si la mise à jour est proactive (le groupe remplace activement les instances) ou opportuniste (le groupe ne remplace pas activement les instances, mais applique la mise à jour lorsque les instances sont remplacées par d'autres moyens). Vous pouvez également indiquer la surutilisation maximale, des options d'indisponibilité maximale et une durée d'attente minimale.
  7. Cliquez sur Mettre à jour pour lancer la mise à jour.

gcloud

À l'aide de l'outil de ligne de commande gcloud, exécutez la commande rolling-action start-update :

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

où :

  • [INSTANCE_GROUP] est le nom du groupe d'instances à mettre à jour.
  • [INSTANCE_TEMPLATE] est le nouveau modèle d'instance qui sera utilisé pour mettre à jour le groupe d'instances.
  • Une [ZONE] ou [REGION] pour ce groupe d'instances. Si le groupe d'instances est un groupe d'instances zonal, indiquez la zone. S'il s'agit d'un groupe d'instances régional, indiquez la région.

API

Dans l'API, effectuez une requête PATCH à l'URL suivante :

https://compute.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[ZONE]/instanceGroupManagers/[MANAGED_INSTANCE_GROUP_NAME]

Si le groupe d'instances est un groupe d'instances géré régional, remplacez zones/[ZONE] par regions/[REGION] :

La charge utile de la requête contient :

  • Le modèle d'instance qui sera utilisé pour mettre à jour le groupe.
  • Une règle de mise à jour pour la requête et d'autres options de mise à jour.

L'exemple suivant indique la configuration minimale nécessaire pour lancer une mise à jour dans l'API.

Sans indication contraire de votre part, les propriétés maxSurge et maxUnavailable seront définies sur 1, multipliées par le nombre de zones affectées, ce qui signifie que le programme de mise à jour ne rend qu'une instance indisponible dans chaque zone affectée et ne crée qu'une instance supplémentaire par zone, pendant la mise à jour.

Cet exemple de requête met à jour 100 % des instances dans le nouveau modèle d'instance.

{
  "instanceTemplate": "global/instanceTemplates/example-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.

Configurer des options pour votre mise à jour

Pour des mises à jour plus complexes, vous pouvez configurer des options supplémentaires pour une requête de mise à jour spécifique. Ces options sont décrites ci-dessous.

Surutilisation maximale

Définissez la propriété maxSurge pour permettre au programme de mise à jour de créer temporairement de nouvelles instances supérieures à targetSize lors de la mise à jour. Par exemple, si vous définissez maxSurge sur 5, le groupe d'instances géré crée jusqu'à cinq instances supérieures à la taille de la cible avec le nouveau modèle d'instance. 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.

Si vous ne définissez pas de valeur maxSurge, la valeur par défaut est utilisée. Pour les groupes d'instances gérés zonaux, la valeur par défaut de maxSurge est 1. Pour les groupes d'instances gérés régionaux, la valeur par défaut est [NUMBER_OF_ZONES], où [NUMBER_OF_ZONES] est le nombre de zones associées au groupe d'instances géré régional.

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

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

Maximum d'instances indisponibles

Définissez la configuration de maxUnavailable afin que seul un certain nombre d'instances soit indisponible à tout moment pendant la mise à jour. Par exemple, si vous définissez maxUnavailable sur 5, seules cinq instances seront mises hors ligne pour être mises à jour à la fois. Utilisez ce paramètre pour contrôler le niveau de perturbation de la mise à jour de votre service et pour contrôler 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 d'instances est en cours de redimensionnement, les instances en cours de création peuvent être indisponibles et, par conséquent, incluses dans le nombre maxUnavailable. 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.

La valeur par défaut de maxUnavailable dans un groupe d'instances géré zonal est 1. Dans un groupe d'instances géré régional, la valeur par défaut pour [NUMBER_OF_ZONES] (le nombre de zones sélectionnées) est définie sur 3.

Durée d'attente minimale

Définissez le paramètre minReadySeconds pour spécifier le délai d'attente avant de considérer une instance nouvellement créée ou redémarrée comme mise à jour. Utilisez cette fonctionnalité pour contrôler la vitesse à laquelle la mise à jour est déployée. La minuterie démarre lorsque les deux conditions suivantes sont remplies :

Pour que la vérification de l'état affiche l'état "opérationnel", le programme de mise à jour :

  1. attend la durée spécifiée par autohealingPolicies.initialDelaySec pour que la vérification de l'état affiche la valeur HEALTHY ;
  2. attend ensuite la durée spécifiée par minReadySeconds.

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 fiable 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 minReadySeconds, 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 d'instances, le minuteur démarre lorsque l'état de l'instance est RUNNING. La valeur maximale de la propriété minReadySeconds est de 3 600 secondes (1 heure).

Action minimale

Définissez la propriété d'action minimale pour contrôler l'action minimale que le programme de mise à jour doit effectuer pour mettre à jour les instances dans le groupe. Par exemple, si vous définissez REPLACE comme action minimale, toutes les instances affectées sont supprimées et remplacées par une nouvelle instance, que cela soit nécessaire ou non.

La définition d'une action minimale garantit l'exécution minimale de cette action par le programme de mise à jour. 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. Toutefois, si la mise à jour nécessite une action plus perturbatrice, le programme de mise à jour effectue cette action. Ainsi, il n'est pas possible de modifier le système d'exploitation d'une instance en redémarrant l'instance afin que le programme de mise à jour remplace les instances du groupe d'instances par de nouvelles instances de VM.

Les actions applicables sont REPLACE ou RESTART :

  • RESTART : redémarre l'instance (effectue 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), elle est forcée d'effectuer un 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 de mise à jour affectent votre requête

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 temps 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]]

Par exemple, si vous avez 1 000 instances et que vous avez exécuté cette commande, 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.

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.

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

Démarrer une mise à jour en version Canary

La fonctionnalité Instance Group Updater vous permet d'effectuer des mises à jour Canary afin de tester vos mises à jour sur un sous-ensemble aléatoire d'instances avant de vous engager pleinement dans la mise à jour.

Une mise à jour Canary est une mise à jour appliquée à un nombre partiel d'instances du groupe d'instances. Les mises à jour Canary vous permettent de tester de nouvelles fonctionnalités ou mises à niveau sur un sous-ensemble d'instances, plutôt que de procéder à une mise à jour potentiellement perturbatrice de toutes vos instances. Si une mise à jour ne se déroule pas correctement, vous pouvez restaurer un nombre limité d'instances, ce qui minimise les perturbations pour vos utilisateurs. Du point de vue du serveur, 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. À l'instar d'une mise à jour standard, une mise à jour Canary perturbe les instances concernées, c'est-à-dire que les instances affectées sont supprimées et remplacées par de nouvelles instances de VM pendant la mise à jour.

Pour lancer une mise à jour Canary, procédez comme suit :

  • 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 seront créées sur la base du new-instance-template tandis que les instances restantes continueront d'exécuter le 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. Accédez à la page Groupes d'instances dans la console GCP.

    Accéder à la page Groupes d'instances

  2. Sélectionnez le groupe d'instances à 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. Vous pouvez également activer les options de configuration, par exemple choisir entre une activation de la mise à jour proactive (le groupe supprime et remplace activement les instances) ou opportuniste (le groupe ne remplace pas activement les instances mais applique la mise à jour lorsque des instances sont créées pour d'autres raisons). Vous pouvez également indiquer la surutilisation maximale, des options d'indisponibilité maximale et une durée d'attente minimale.
  7. Cliquez sur Mettre à jour pour lancer la mise à jour.

gcloud

À l'aide de l'outil de ligne de commande gcloud, indiquez à 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_TEMPLATE] \
    --canary-version template=[NEW_TEMPLATE],target-size=[SIZE] \
    [--zone [ZONE] | --region [REGION]]

où :

  • [CURRENT_TEMPLATE] est le modèle actuellement exécuté par le groupe d'instances.
  • [NEW_TEMPLATE] est le nouveau modèle pour la mise à jour Canary.
  • [SIZE] est le nombre ou le pourcentage d'instances auquel 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.
  • Une [ZONE] ou [REGION] pour ce groupe d'instances. Si le groupe d'instances est un groupe d'instances zonal, indiquez la zone. S'il est géré par région, indiquez la région.

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

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

API

Dans l'API, envoyez une demande PATCH à l'adresse URI suivante :

https://compute.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[ZONE]/instanceGroupManagers/[INSTANCE_GROUP_NAME]

La charge utile de la requête doit contenir à la fois le modèle d'instance actuel et le nouveau modèle d'instance que vous souhaitez utiliser pour la mise à jour Canary. Exemple :

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

où :

  • [NEW_TEMPLATE] est le nom du nouveau modèle que vous souhaitez utiliser pour la mise à jour Canary.
  • [NUMBER|PERCENTAGE] est le nombre fixe ou le pourcentage d'instances à utiliser pour cette mise à jour Canary. Vous ne pouvez définir un pourcentage que si le groupe d'instances contient 10 instances ou plus. Sinon, indiquez un nombre fixe.
  • [CURRENT_TEMPLATE] est le nom du modèle actuellement exécuté par le groupe d'instances

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 ou de l'annulation de la mise à jour.

Console

  1. Accédez à la page Groupes d'instances dans la console GCP.

    Accéder à la page Groupes d'instances

  2. Sélectionnez le groupe d'instances à 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 même mise à jour en lançant la même requête de mise à jour mais en ne définissant que la version version et en omettant la version --canary-version. Utilisez l'outil de ligne de commande gcloud :

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

API

Dans l'API, envoyez une demande PATCH à l'adresse URI suivante :

https://compute.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[ZONE]/instanceGroupManagers/[INSTANCE_GROUP_NAME]

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. Voici à quoi ressemblerait le corps de votre requête pour cet exemple :

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

Remplacez [NEW_TEMPLATE] par le nom du nouveau modèle d'instance à déployer.

Lancer une mise à jour opportuniste ou proactive

Par défaut, les mises à jour effectuées à l'aide de l'outil de ligne de commande gcloud sont proactives et les mises à jour lancées dans l'API sont opportunistes.

Pour les mises à jour proactives, Compute Engine planifie activement les actions pour appliquer aux instances les mises à jour demandées, le cas échéant. Dans de nombreux cas, cela signifie souvent supprimer et recréer des instances de manière proactive.

Vous pouvez également décider d'effectuer une mise à jour opportuniste si une mise à jour proactive est potentiellement trop perturbatrice. Une mise à jour opportuniste n'est appliquée que lorsque vous initiez manuellement la mise à jour sur des instances sélectionnées ou lors de la création d'instances par le groupe d'instances géré. Ce dernier crée des instances lorsqu'il est redimensionné par un autre service, tel qu'un autoscaler, ou manuellement par un utilisateur. Compute Engine n'initie pas activement les requêtes d'application de mises à jour opportunistes.

Dans certains cas, une mise à jour opportuniste est utile car il est préférable de ne pas provoquer d'instabilité sur le système si cela peut être évité. Par exemple, si vous avez une mise à jour non critique et non urgente, qui peut être appliquée au besoin, et que vous avez un groupe d'instances géré en cours d'analyse automatique, vous pouvez effectuer une mise à jour opportuniste afin que Compute Engine ne désactive pas activement vos instances existantes pour appliquer la mise à jour.

Pour déterminer si une mise à jour est opportuniste ou proactive, définissez la propriété type sur OPPORTUNISTIC ou PROACTIVE à l'aide de l'outil de ligne de commande gcloud ou de l'API.

Console

  1. Accédez à la page Groupes d'instances dans la console GCP.

    Accéder à la page Groupes d'instances

  2. Sélectionnez le groupe d'instances à mettre à jour.
  3. En haut de la page, cliquez sur Mise à jour progressive.
  4. Sous Modèle, sélectionnez un modèle pour mettre à jour votre groupe d'instances et sélectionnez la taille de la cible pour le modèle.
  5. Sous Mode de mise à jour, choisissez la mise à jour opportuniste ou proactive.
  6. Cliquez sur Mettre à jour pour lancer la mise à jour.

gcloud

Utilisez l'outil de ligne de commande gcloud :

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

API

Dans la charge utile de la requête pour lancer une mise à jour, incluez la propriété type dans votre updatePolicy :

{
"updatePolicy": {
  "type": "PROACTIVE" # Performs a proactive update
},
"versions": [{
  "instanceTemplate": "global/instanceTemplates/[NEW_TEMPLATE]",
  }]
}

[NEW_TEMPLATE] est le nom du nouveau modèle que vous souhaitez utiliser pour la mise à jour Canary. Pour une mise à jour opportuniste, remplacez PROACTIVE par OPPORTUNISTIC.

Mettre à jour les instances sélectionnées

Lorsque vous lancez une mise à jour opportuniste, vous devez attendre que Compute Engine déploie la mise à jour lorsque des opportunités se présentent. Toutefois, si vous souhaitez davantage de contrôle sur le déploiement, vous pouvez lancer cette mise à jour immédiatement de manière manuelle sur des instances spécifiques de votre groupe d'instances géré.

La mise à jour manuelle autorise les opérations suivantes :

  • Sélectionner les instances que vous souhaitez mettre à jour.
  • Appliquer une mise à jour avec le niveau d'interruption le plus faible, uniquement nécessaire à sa réalisation. Par exemple, si vous ne mettez à jour que des métadonnées, il n'est peut-être pas utile de redémarrer l'instance pour terminer la mise à jour. Lors du lancement manuel de la mise à jour, l'action minimale nécessaire est automatiquement effectuée.
  • Appliquer le redémarrage ou la recréation de l'instance même si ces actions ne sont pas nécessaires à la mise à jour. Par exemple, il peut être utile de redémarrer une machine virtuelle même si vous ne mettez à jour que ses métadonnées, car votre logiciel invité doit récupérer les nouvelles métadonnées au démarrage de la VM.
  • Empêcher une mise à jour si elle entraîne plus de perturbations que ce que vous pouvez vous permettre.
  • Effectuer immédiatement une mise à jour de toutes les instances sélectionnées, sans appliquer de contraintes maxSurge et maxUnavailable au déploiement.

Action minimale et action autorisée la plus perturbatrice

Selon la nature de la mise à jour, l'état de l'instance peut être perturbé. Par exemple, la modification du type de machine d'une instance nécessite le redémarrage de la VM, tandis que la modification de son image de démarrage nécessite la suppression et le remplacement de l'instance.

Vous pouvez contrôler le niveau de perturbation à l'aide des indicateurs minimal-action et most-disruptive-allowed-action :

  • minimal-action : permet de forcer une action plus perturbatrice que nécessaire.
  • most-disruptive-allowed-action : permet d'empêcher une mise à jour si celle-ci entraîne plus de perturbations que ce que vous pouvez vous permettre.

Lors de la mise à jour des instances sélectionnées, ces deux indicateurs acceptent les actions suivantes :

ActionDescriptionQuelles propriétés de l'instance peuvent être mises à jour ?
NONEN'affecte pas du tout l'instance.Aucun
REFRESHNe provoque pas l'arrêt de l'instance.Disques secondaires, métadonnées d'instances, libellés.
RESTARTArrête l'instance, puis la redémarre.Type de machine.
REPLACESupprime l'instance, puis la crée de nouveau.Toutes les propriétés de l'instance stockées dans le modèle d'instance.

Par défaut, l'indicateur minimal-action est défini sur NONE. Si votre mise à jour nécessite une action plus perturbatrice que celle définie avec cet indicateur, Compute Engine effectue l'action nécessaire à l'exécution de la mise à jour.

Par défaut, la valeur most-disruptive-allowed-action est définie sur REPLACE. Si votre mise à jour nécessite une action plus perturbatrice que celle définie à l'aide de cet indicateur, la demande de mise à jour échoue. Par exemple, si vous avez défini "redémarrage" comme action autorisée la plus perturbatrice, une tentative de mise à jour de l'image du disque de démarrage échoue. En effet, une mise à jour de ce type nécessite la recréation de l'instance, ce qui constitue une action plus perturbatrice qu'un redémarrage.

Vous pouvez mettre à jour les instances sélectionnées à l'aide de l'outil gcloud ou de l'API.

gcloud

Après avoir lancé une mise à jour opportuniste, appliquez-la à des instances spécifiques à l'aide de la sous-commande update-instances.

gcloud beta compute instance-groups managed update-instances [INSTANCE_GROUP] \
    --instances [INSTANCE_NAMES] \
    --most-disruptive-allowed-action [DISRUPTION_LEVEL] \
    --minimal-action [DISRUPTION_LEVEL]

Où :

  • [INSTANCE_GROUP] est le nom du groupe d'instances avec des mises à jour en attente.
  • [INSTANCE_NAMES] est une liste d'instances à mettre à jour immédiatement.
  • [DISRUPTION_LEVEL] est le niveau de perturbation minimal ou maximal. Il peut être défini sur NONE, REFRESH, RESTART ou REPLACE.
    • La valeur minimal-action par défaut est NONE.
    • La valeur most-disruptive-allowed-action par défaut est REPLACE.

Si vous devez attendre que toutes les instances spécifiées soient mises à jour, vérifiez l'état du groupe et attendez que celui-ci soit stable.

API

Après avoir lancé une mise à jour opportuniste, envoyez une requête POST à la méthode regionInstanceGroupManagers.applyUpdatesToInstances en version bêta. Pour un groupe d'instances géré zonal, utilisez la méthode instanceGroupManagers.applyUpdatesToInstances.

POST https://compute.googleapis.com/compute/beta/projects/[PROJECT]/regions/[REGION]/instanceGroupManagers/[INSTANCE_GROUP_NAME]/applyUpdatesToInstances
{
  "instances": "zones/[ZONE]/instances/[INSTANCE_NAME]","zones/[ZONE]/instances/[INSTANCE_NAME]"
  "minimalAction": [DISRUPTION_LEVEL],
  "mostDisruptiveAllowedAction": [DISRUPTION_LEVEL]
}

Où :

  • [INSTANCE_GROUP_NAME] est le nom du groupe d'instances avec des mises à jour en attente.
  • [ZONE] est la zone d'une instance à mettre à jour immédiatement.
  • [INSTANCE_NAME] est le nom d'une instance à mettre à jour immédiatement.
  • [DISRUPTION_LEVEL] est le niveau de perturbation minimal ou maximal. Il peut être défini sur NONE, REFRESH, RESTART ou REPLACE.
    • La valeur minimalAction par défaut est NONE.
    • La valeur mostDisruptiveAllowedAction par défaut est REPLACE.

Semblable à d'autres méthodes de groupes d'instances gérés, la méthode applyUpdatesToInstances est basée sur l'intention, ce qui signifie qu'elle renvoie une réponse à l'opération. Une fois que l'opération est terminée (DONE), listManagedInstances contient la liste des instances avec les champs currentAction définis sur REFRESHING, RESTARTING ou RECREATING. Si l'opération échoue, par exemple en raison de modifications apportées simultanément au groupe, l'échec est noté dans le champ lastAttempt.errors.

Si vous devez attendre que toutes les instances spécifiées soient mises à jour, vérifiez l'état du groupe et attendez que celui-ci soit stable.

Exécuter un remplacement ou un redémarrage progressif

Vous pouvez également utiliser les commandes restart ou replace pour effectuer un redémarrage ou un remplacement progressif des instances de VM dans le groupe d'instances géré. Comme pour la commande start-update, vous pouvez spécifier l'une des options de configuration pour un redémarrage ou un remplacement. Un redémarrage ou un remplacement progressif ne modifie en rien le groupe d'instances, modèle d'instance inclus. Il actualise simplement les instances du groupe en utilisant la méthode de votre choix.

Un remplacement ou un redémarrage progressif est souhaitable pour de nombreuses raisons. Par exemple, pour actualiser de temps en temps vos instances de VM afin d'effectuer les opérations 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.

Pour effectuer un remplacement avec suppression et remplacement de toutes les instances par de nouvelles instances :

Console

  1. Accédez à la page Groupes d'instances dans la console GCP.

    Accéder à la page Groupes d'instances

  2. Sélectionnez le groupe d'instances à 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. 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.
  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

gcloud compute instance-groups managed rolling-action replace [INSTANCE_GROUP]

Cette commande remplace toutes les instances du groupe d'instances géré, une à la fois. Si un remplacement complet est trop perturbateur, vous pouvez spécifier un redémarrage progressif à la place afin de ne supprimer aucune instance et de simplement redémarrer chaque instance.

gcloud compute instance-groups managed rolling-action restart [INSTANCE_GROUP]

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

API

Dans l'API, effectuez une requête PATCH pour le groupe et définissez une updatePolicy proactive où minimalAction est RESTART ou REPLACE, selon que vous souhaitez effectuer un remplacement progressif dans lequel chaque instance est supprimée et remplacée par une nouvelle instance, ou un redémarrage continu dans lequel chaque instance est arrêtée et redémarrée. Qu'il s'agisse de RESTART ou de REPLACE, vous devez toujours spécifier les propriétés versions.instanceTemplate et versions.name (par exemple, v2) pour déclencher l'action.

Voici à quoi un remplacement progressif peut ressembler :

PATCH https://compute.googleapis.com/compute/v1/projects/myproject/zones/[ZONE]/instanceGroupManagers/[INSTANCE_GROUP_NAME]

{
 "updatePolicy": {
  "minimalAction": "REPLACE",
  "type": "PROACTIVE"
 },
 "versions": [
  {
   "instanceTemplate": "global/instanceTemplates/example-template",
   "name": "v2"
  }
 ]
}

Pour un redémarrage progressif, procédez comme suit :

PATCH https://compute.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[ZONE]/instanceGroupManagers/[INSTANCE_GROUP_NAME]

{
 "updatePolicy": {
  "minimalAction": "RESTART",
  "type": "PROACTIVE"
 },
 "versions": [
  {
   "instanceTemplate": "global/instanceTemplates/example-template",
   "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 d'instances, deux à la fois. 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]]

Redémarrer progressivement toutes les VM le plus rapidement possible

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

Remplacer progressivement toutes les VM le plus rapidement possible

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

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.

La mise à jour d'un groupe d'instances géré régional à l'aide de la fonctionnalité Instance Group Updater équivaut à effectuer une mise à jour sur un groupe d'instances géré zonal, à quelques exceptions près décrites ci-dessous. Lorsque vous lancez une mise à jour vers un groupe d'instances géré régional, le programme de mise à jour met toujours à jour les instances de façon proportionnelle et uniforme dans chaque zone. Il est impossible de choisir les instances ou les zones mises à jour en premier ou 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

Avant de lancer une mise à jour d'un groupe d'instances géré régional, vous devez savoir qu'un certain nombre d'éléments se comportent différemment des groupes d'instances gérés zonaux :

  • Les paramètres de mise à jour par défaut des groupes d'instances gérés régionaux sont maxUnavailable=[NUMBER_OF_ZONES] et maxSurge=[NUMBER_OF_ZONES], où [NUMBER_OF_ZONES] correspond au nombre de zones sélectionnées pour le groupe d'instances géré régional, à savoir 3 par défaut.

  • Si vous utilisez des nombres fixes lors de la spécification d'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 d'instances 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, ce nombre est divisé par le nombre de zones du groupe d'instances géré 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 se divise pas uniformément d'une zone à l'autre, le programme de mise à jour attribue les instances à une zone aléatoire. Ainsi, pour 10 instances réparties sur trois zones, deux des zones obtiennent trois instances et une zone 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 10 instances de VM ou plus. 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é comprenant 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. Les mêmes règles applicables à la mise à jour des groupes d'instances gérés zonaux s'appliquent ici.

Surveiller les mises à jour

Une fois la mise à jour progressive lancée, l'opération peut prendre un certain temps. Vous pouvez suivre la progression d'une mise à jour en examinant l'état (status) du groupe d'instances géré, ou en vérifiant l'action en cours (currentAction) sur chaque instance dans le groupe d'instances géré.

État du groupe

Au niveau du groupe, Compute Engine insère un champ en lecture seule nommé status, qui comprend les indicateurs versionTarget.isReached et isStable. Vous pouvez accéder à ces indicateurs à l'aide de l'outil gcloud ou de l'API.

Pour vérifier que la mise à jour du groupe d'instances est terminée, assurez-vous que l'état status.versionTarget.isReached==true est affiché. Pour vérifier que toutes les instances du groupe sont en cours d'exécution et opérationnelles (c'est-à-dire que le champ currentAction de chaque instance gérée est défini sur NONE), assurez-vous que status.isStable==true est affiché. N'oubliez pas que la stabilité d'un groupe d'instances géré dépend de la configuration du groupe au-delà du programme de mise à jour. Par exemple, si votre groupe est soumis à l'autoscaling et qu'il est en train d'évoluer, l'état renvoyé est isStable==false en raison de l'opération effectuée par l'autoscaler.

Vous pouvez également utiliser la console pour afficher le nombre actuel et le nombre cible d'instances en cours de mise à jour.

Console

Vous pouvez surveiller une mise à jour progressive pour un groupe en accédant à la page des détails du groupe d'instances concerné.

  1. Accédez à la page Groupes d'instances dans la console GCP.

    Accéder à la page Groupes d'instances

  2. Sélectionnez le groupe d'instances que vous souhaitez surveiller. La page de vue d'ensemble du groupe d'instances montre le modèle utilisé par chaque instance.
  3. Pour afficher les détails, cliquez sur l'onglet Détails.

La page Détails affiche le nombre actuel et le nombre cible d'instances mises à jour pour chaque modèle d'instance et affiche également les paramètres de mise à jour.

gcloud

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

L'outil gcloud renvoie des informations détaillées sur le groupe d'instances, y compris les champs status.versionTarget.isReached et status.isStable.

API

Dans l'API, envoyez une demande POST à l'adresse URI suivante :

POST https://compute.googleapis.com/compute/beta/projects/[PROJECT_ID]/zones/[ZONE]/instanceGroupManagers/[INSTANCE_GROUP_NAME]/get

Si le groupe d'instances est un groupe d'instances géré régional, remplacez zones/[ZONE] par regions/[REGION] :

L'API renvoie des informations détaillées sur le groupe d'instances, y compris les champs status.versionTarget.isReached et status.isStable.

status.versionTarget.isReached (version bêta)

Le déploiement d'une mise à jour est considéré comme étant terminé lorsque toutes les instances de VM du groupe sont créées ou en cours de création dans leur version cible. Dans le cas d'un déploiement complet, toutes les instances sont configurées pour utiliser le nouveau modèle d'instance. Dans le cas d'un déploiement partiel, les instances sont configurées en fonction de la répartition cible spécifiée sur les modèles d'instance.

Vous pouvez vérifier si le déploiement d'une mise à jour est terminé en consultant la valeur du champ status.versionTarget.isReached d'une ressource instanceGroupManagers (ou regionInstanceGroupManagers) :

  • Le champ status.versionTarget.isReached est défini sur true si toutes les instances de VM sont créées ou en cours de création à l'aide de la version cible (versions[]).
  • Le champ status.versionTarget.isReached est défini sur false lorsqu'au moins une VM n'utilise pas encore la version cible (versions[]). Dans le cas d'une mise à jour Canary, le champ est défini sur false lorsque le nombre de VM utilisant une version cible (versions[].instanceTemplates) ne correspond pas à la taille cible (versions[].targetSize).

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

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

status.isStable

Vous pouvez vérifier qu'un groupe d'instances géré est en cours d'exécution et opérationnel en vérifiant la valeur du champ status.isStable de la ressource instanceGroupManagers ou regionInstanceGroupManagers associée.

Vous pouvez également utiliser la commande wait-until de l'outil de ligne de commande gcloud avec l'option --stable jusqu'à ce que le champ status.isStable soit défini sur true pour le groupe :

gcloud beta compute instance-groups managed wait-until INSTANCE_GROUP_NAME \
    --stable \
    [--zone [ZONE] | --region [REGION]]

Si le champ status.isStable est défini sur false, cela signifie que les modifications sont actives, en attente ou que le groupe d'instances géré est lui-même 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 groupe d'instances géré.
  • Le groupe d'instances géré n'est pas en cours de modification.

Les groupes d'instances gérés peuvent être modifiés 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 d'instances géré.
  • 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

Pour afficher l'action currentAction effectuée et l'état status de chaque instance dans un groupe d'instances géré, vous pouvez utiliser l'outil de ligne de commande gcloud ou l'API.

gcloud

gcloud compute instance-groups managed list-instances [INSTANCE_GROUP_NAME] [--filter="zone:([ZONE])" | --filter="region:([REGION])"]

gcloud renvoie une liste des instances présentes dans le groupe, ainsi que leurs états et actions en cours. Exemple :

NAME               ZONE           STATUS    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

API

Dans l'API, envoyez une requête POST à la méthode regionInstanceGroupManagers.listManagedInstances. Pour un groupe d'instances géré zonal, utilisez la méthode instanceGroupManagers.listManagedInstances.

POST https://compute.googleapis.com/compute/v1/projects/project-id/regions/region/instanceGroupManagers/instance-group-name/listManagedInstances

L'API renvoie une liste des instances présentes dans le groupe, y compris les champs instanceStatus et currentAction de chaque instance.

{
 "managedInstances": [
  {
   "instance": "https://compute.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[ZONE]/instances/vm-instances-prvp",
   "id": "5317605642920955957",
   "instanceStatus": "RUNNING",
   "instanceTemplate": "https://compute.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/instanceTemplates/[INSTANCE_TEMPLATE_NAME]",
   "currentAction": "REFRESHING"
  },
  {
   "instance": "https://compute.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[ZONE]/instances/vm-instances-pz5j",
   "currentAction": "DELETING"
  },
  {
   "instance": "https://compute.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[ZONE]/instances/vm-instances-w2t5",
   "id": "2800161036826218547",
   "instanceStatus": "RUNNING",
   "instanceTemplate": "https://compute.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/instanceTemplates/[INSTANCE_TEMPLATE_NAME]",
   "currentAction": "REFRESHING"
  }
 ]
}

Vous pouvez consulter l'état de chaque instance d'un groupe d'instances géré à l'aide du champ instanceStatus. Pour afficher la liste des valeurs de champ instanceStatus valides, consultez la section Consulter l'état d'une instance.

Si l'instance subit un certain type de modification, l'une des actions suivantes est insérée dans le champ currentAction 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 a été supprimée et 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

Il n'y a pas de commande explicite pour restaurer une mise à jour vers une version précédente, mais si vous décidez de restaurer une mise à jour (soit une mise à jour entièrement validée ou Canary), vous pouvez effectuer une nouvelle requête de mise à jour et transférer le modèle d'instance à restaurer.

Par exemple, la commande suivante restaure une mise à jour aussi rapidement que possible :

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

Remplacez [OLD_INSTANCE_TEMPLATE] par le nom du modèle d'instance à restaurer.

Dans l'API, envoyez une requête PATCH à l'adresse URI suivante :

https://compute.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[ZONE]/instanceGroupManagers/[INSTANCE_GROUP_NAME]

Si le groupe d'instances est un groupe d'instances géré régional, remplacez zones/[ZONE] par regions/[REGION].

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

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

S'il s'agit d'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 :

{ "updatePolicy":
  {
    "maxUnavailable":
    {
      "fixed": [NUMBER_OF_INSTANCES_IN_GROUP]
    }
  },
 "versions": [
    {
      "instanceTemplate": "global/instanceTemplates/[OLD_TEMPLATE]" # Old instance template
    }
   ]
}

Le service Instance Group Updater traite cela comme une requête de mise à jour standard afin que toutes les options de mise à jour décrites dans ce document puissent être spécifiées avec votre requête.

Contrôler la vitesse d'une mise à jour

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 minReadySeconds é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 maxSurge faibles. Cette action permet de garantir la mise à jour d'un nombre minimal d'instances à la fois.
  5. Initiez manuellement des mises à jour sur des instances spécifiques pour mettre à jour ces instances immédiatement.

Vous pouvez également utiliser une combinaison de ces paramètres pour contrôler la vitesse de votre mise à jour.

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 qu'une mise à jour proactive devienne opportuniste, 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 avec la liste des instances dans le groupe d'instances et leur état actuel :

    NAME               ZONE           STATUS   ACTION    INSTANCE_TEMPLATE  VERSION_NAME  LAST_ERROR
    vm-instances-9pk4  us-central1-f  RUNNING  NONE      my-new-template
    vm-instances-j1h8  us-central1-f  RUNNING  NONE      my-new-template
    vm-instances-ngod  us-central1-f  RUNNING  NONE      my-old-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 indiquez le nombre d'instances qui ont déjà été mises à jour en tant que taille de la cible :

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

    Pour le service de mise à jour, cette mise à jour apparaît "complète". Ainsi, aucune autre instance n'est mise à jour et la mise à jour est interrompue.

Relation entre les propriétés de versions et d'instanceTemplate pour un groupe d'instances géré

Nous vous recommandons d'utiliser le champ versions pour configurer des modèles d'instance pour les groupes d'instances gérés.

L'ancien champ instanceTemplate et le champ versions chevauchent dans les fonctionnalités, car les deux champs permettent de spécifier le modèle d'instance que le groupe d'instances géré utilise pour créer des instances. Toutefois, seul le champ versions vous permet de spécifier une configuration (Canary) avancée à deux modèles.

Pour assurer la rétrocompatibilité, les groupes d'instances gérés continuent à accepter la définition du champ instanceTemplate de premier niveau, même si nous vous recommandons de n'utiliser que le champ versions. L'utilisation simultanée des deux champs instanceTemplate et versions peut entraîner ambiguïté et confusion.

Si vous spécifiez à la fois le champ instanceTemplate et le champ versions lors de l'appel de la méthode update() ou patch(), trois cas sont possibles :

  • Vous définissez les deux champs à la même valeur.

    Ceci est une requête valide. Dans ce cas, il ne crée aucune ambiguïté et le nouveau modèle d'instance est appliqué au groupe d'instances géré.

    Par exemple, dans la requête suivante, le champ instanceTemplate de premier niveau et le champ versions spécifient le même modèle d'instance, différent du modèle actuel. Le groupe d'instances géré est mis à jour selon le nouveau modèle d'instance :

    {
     "instanceTemplate": "global/instanceTemplates/new-template",
     "versions": [
      {
       "instanceTemplate": "global/instanceTemplates/new-template"
      }
     ],
     "updatePolicy": {
       "type": "PROACTIVE"
     }
    }
    
  • Vous définissez deux champs sur des valeurs qui ne correspondent pas, mais une seule valeur est différente du modèle d'instance actuel dans le groupe d'instances géré.

    Ceci est une requête valide. Le champ différent du paramètre actuel est considéré comme la valeur souhaitée. Par exemple, vous appelez la méthode get(), modifiez l'un des deux champs, puis appelez update() avec un seul champ modifié :

    {
     "instanceTemplate": "global/instanceTemplates/current-template",
     "versions": [
      {
       "instanceTemplate": "global/instanceTemplates/new-template"
      }
     ],
     "updatePolicy": {
       "type": "PROACTIVE"
     }
    }
    
  • Vous définissez deux champs sur des valeurs qui ne correspondent pas, et ces deux valeurs sont différentes du modèle d'instance actuel dans le groupe d'instances géré.

    Ce paramètre n'est pas valide et renvoie une erreur, car il n'y a pas d'intention claire.

    {
     "instanceTemplate": "global/instanceTemplates/new-template",
     "versions": [
      {
       "instanceTemplate": "global/instanceTemplates/a-different-new-template"
      }
     ],
     "updatePolicy": {
       "type": "PROACTIVE"
     }
    }
    

Le champ versions, le champ instanceTemplate et la méthode get()

Si vous ne spécifiez qu'un seul modèle d'instance, via le champ instanceTemplate de premier niveau ou via le champ versions ou les deux, la méthode get() renvoie les deux champs dans sa réponse. Cela rend le nouveau champ versions rétrocompatible. Tant que vous spécifiez un modèle d'instance unique dans l'un de ces champs, ce que renvoie get() dans le champ instanceTemplate n'est pas modifié.

Si le champ versions contient deux modèles d'instance spécifiés, la méthode get() renvoie un champ instanceTemplate de premier niveau vide. Il n'y a aucun moyen d'exprimer sans ambiguïté une configuration Canary à deux modèles d'instance dans un champ instanceTemplate de premier niveau, et ce champ n'est donc pas utilisé lors d'une mise à jour Canary.

Le champ versions et la méthode setInstanceTemplate()

Pour assurer une rétrocompatibilité, la méthode setInstanceTemplate() se comporte comme précédemment, vous permettant de modifier le modèle utilisé par le groupe d'instances géré pour créer des instances. Lorsque vous appelez cette méthode, le champ versions est remplacé par le modèle d'instance spécifié par la méthode setInstanceTemplate().

La méthode setInstanceTemplate() définit également updatePolicy sur OPPORTUNISTIC. Cela empêche le groupe d'instances géré de déployer activement un modèle d'instance qui n'était pas explicitement spécifié dans le champ versions.

Étapes suivantes

Cette page vous a-t-elle été utile ? Évaluez-la :

Envoyer des commentaires concernant…

Documentation Compute Engine