Déployer des mises à jour de MIG

Un groupe d'instances géré (MIG) contient une ou plusieurs instances de machine virtuelle (VM) créées à l'aide d'un modèle d'instance. Pour mettre à jour les instances d'un MIG, vous pouvez envoyer des requêtes de mise à jour au groupe dans son ensemble, à l'aide de la fonctionnalité MIG Updater.

Avec le programme de mise à jour de groupes d'instances gérés, vous pouvez 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, vous pouvez déployer les nouvelles versions du logiciel de deux façons : soit en créant un groupe d'instances géré avec une nouvelle version du logiciel, ce qui nécessite l'ajout d'une configuration à chaque mise à jour, soit via une recréation manuelle des instances initiée par l'utilisateur. Ces approches nécessitent d'importantes interventions manuelles tout au long du processus.

Avant de commencer

Lancer une mise à jour progressive de base

Une mise à jour progressive est une mise à jour 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 affiche 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 Updater est une API déclarative. Après la mise à jour, l'API attend une requête pour spécifier la configuration souhaitée du groupe d'instances géré, plutôt qu'un appel de fonction explicite.

  • Le programme de mise à jour supporte jusqu'à deux versions de modèle d'instance dans votre groupe d'instances géré. Vous pouvez donc 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. Dans Cloud Console, accédez à la page Groupes d'instances.

    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, accédez à la liste déroulante et sélectionnez le nouveau modèle à utiliser pour la mise à jour.
  5. Pour la taille de la cible, saisissez 100 % pour mettre à jour toutes les instances.
  6. Vous pouvez également activer les options de configuration, par exemple choisir entre une 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 un délai d'attente minimal.
  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-name \
        --version template=instance-template-name
        [--zone zone | --region region]
    

Remplacez les éléments suivants :

  • instance-group-name : nom du groupe d'instances à mettre à jour.
  • instance-template-name : nouveau modèle d'instance qui sera utilisé pour mettre à jour le groupe d'instances.
  • zone : zone de ce groupe d'instances, si le groupe d'instances est un groupe d'instances zonal.
  • region : région de ce groupe d'instances, si le groupe d'instances est un groupe d'instances régional.

API

Dans l'API, envoyez une requête PATCH à la ressource du gestionnaire de groupe d'instances :

    PATCH 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 :

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 être informé lorsqu'elle se termine.

Configurer des options pour votre mise à jour

Pour des mises à jour plus complexes, vous pouvez configurer des options supplémentaires dans 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 correspond au nombre de zones associées au groupe d'instances géré régional.

Cette option est reconnue uniquement lorsqu'elle est configurée avec l'action minimale REPLACE, mais n'est pas prise en charge 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

Configurez maxUnavailable afin que seul un certain nombre d'instances soit indisponible pendant toute la durée de la mise à jour. Par exemple, si vous définissez maxUnavailable sur 5, seules cinq instances seront mises hors ligne simultanément pour être mises à jour. Utilisez ce paramètre pour contrôler le niveau de perturbation de service de la mise à jour et pour contrôler son taux de déploiement.

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.

Délai d'attente minimal

Définissez la valeur de minReadySeconds pour spécifier le délai d'attente requis avant qu'une instance nouvellement créée ou redémarrée soit considérée comme à 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 :

  • Le statut de l'instance est RUNNING.
  • La vérification de l'état affiche la valeur HEALTHY (si cette option est activée).

Pour que la vérification de l'état affiche le statut HEALTHY, le programme de mise à jour :

  1. attend jusqu'au délai maximum spécifié 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 n'affiche pas l'état HEALTHY dans le délai initialDelaySec, le programme de mise à jour considère l'instance de VM comme 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 spécifiée ne suffit pas à effectuer la mise à jour, une action occasionnant davantage de perturbations 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

Méthode de remplacement (version bêta)

beta feature

Par défaut, lorsque vous mettez à jour un MIG, le groupe supprime vos instances de VM et les remplace par de nouvelles instances avec de nouveaux noms. Si vous souhaitez conserver les noms existants de vos instances de VM, vous pouvez utiliser le paramètre 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 de replacementMethod valides pour le programme de mise à jour sont les suivantes :

  • 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 minimal de trois minutes avant qu'une nouvelle instance soit considérée 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 simultanément jusqu'à 10 % de nouvelles instances au-delà de la taille de la cible

    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

Le programme de mise à jour vous permet d'effectuer des mises à jour Canary pour tester vos mises à jour sur un sous-ensemble aléatoire d'instances avant leur déploiement final.

Les mises à jour Canary s'appliquent à un nombre limité d'instances du groupe d'instances. Elles vous permettent de tester de nouvelles fonctionnalités ou mises à jour 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 de 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. Comme les mises à jour progressives standard, les mises à jour Canary perturbent les instances concernées. Cela signifie que les instances affectées sont supprimées et remplacées par de nouvelles instances de VM pendant la mise à jour.

Démarrer une mise à jour en version Canary

Pour lancer une mise à jour Canary :

  • Spécifiez jusqu'à deux versions de modèle d'instance. En général, il s'agira du nouveau modèle d'instance pour les instances Canary et du 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 modèle new-instance-template tandis que les instances restantes continueront d'exécuter le modè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. Dans Cloud Console, accédez à la page Groupes d'instances.

    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 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 un délai d'attente minimal.
  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]
    

Remplacez les éléments suivants :

  • instance-group-name : nom du groupe associé à l'instance.
  • current-template : 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 : une zone associée à ce groupe d'instances. Si le groupe d'instances est un groupe d'instances zonal, indiquez la zone.
  • region : une région associée à ce groupe d'instances. Si le groupe d'instances est régional, vous devez indiquer une 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 requête PATCH à la ressource du gestionnaire de groupe d'instances :

    PATCH 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"
      }
     ]
    }

Remplacez les éléments suivants :

  • 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 cette 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-template : nom du modèle d'instance 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. Dans Cloud Console, accédez à la page Groupes d'instances.

    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 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 requête PATCH à la ressource du gestionnaire de groupe d'instances :

    PATCH 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. Par exemple, le corps de votre requête pourrait ressembler à ceci : Remplacez new-template par le nom du nouveau modèle d'instance à déployer.

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

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 lorsque le groupe d'instances géré crée des instances. Le groupe d'instances géré 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. Lors du redimensionnement, l'autoscaler arrête de préférence les instances de l'ancien modèle ainsi que les instances qui ne sont pas encore à l'état RUNNING.

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. Dans Cloud Console, accédez à la page Groupes d'instances.

    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 : Remplacez new-template par le nom du nouveau modèle que vous utilisez pour la mise à jour Canary. Pour une mise à jour opportuniste, remplacez PROACTIVE par OPPORTUNISTIC.

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

Mettre à jour une sélection d'instances (version bêta)

beta feature

Lorsque vous lancez une mise à jour opportuniste, vous devez attendre que Compute Engine déploie la mise à jour à mesure que les 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 et manuellement 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 de perturbation 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 VM 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 options 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 options acceptent les actions suivantes :

ActionDescriptionQuelles propriétés de l'instance peuvent être mises à jour ?
NONEN'affecte pas du tout l'instance.Aucune.
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'option minimal-action est définie sur NONE. Si votre mise à jour nécessite une action plus perturbatrice que celle définie à l'aide de cette option, 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 cette option, 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-name \
        --instances instance-names \
        --most-disruptive-allowed-action disruption-level \
        --minimal-action disruption-level
    

Où :

  • instance-group-name 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 affiche 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 à l'aide de la méthode de votre choix.

Un remplacement ou un redémarrage progressif est souhaitable pour de nombreuses raisons. Par exemple, il permet d'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 exécuter à nouveau les scripts de démarrage pour mettre à jour votre logiciel.

Vous pouvez effectuer un remplacement avec suppression et remplacement de toutes les instances par de nouvelles instances à l'aide de Google Cloud Console, de l'outil de ligne de commande gcloud ou de l'API :

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 à 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. Un 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 le délai d'attente minimal.
  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-name
    

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

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/my-project/zones/zone/instanceGroupManagers/instance-group-name

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

Pour un redémarrage progressif :

    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]

Conserver les noms d'instances (version bêta)

beta feature

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 définissez maxSurge sur 0, la mise à jour prend plus de temps à se terminer, mais replacementMethod:recreate permet aux instances mises à jour de conserver 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.

Spécifiez la méthode de remplacement à l'aide de l'outil de ligne de commande gcloud ou de l'API.

gcloud

Lors de l'envoi d'une commande rolling-action, ajoutez --replacement-method=recreate.

gcloud beta 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]
    

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

Envoyez une requête à la méthode patch du groupe d'instances géré en incluant le champ updatePolicy.replacementMethod. Pour un MIG régional, utilisez la méthode régionale patch.

PATCH /compute/beta/projects/project/zones/zone/instanceGroupManagers/instance-group-name
    {
        "updatePolicy": {
            "type": "PROACTIVE",
            "maxUnavailable": { "fixed": 5 },
            "replacementMethod": "RECREATE"
        },
        "versions": [ {
            "instanceTemplate": "global/instanceTemplates/new-template"
        } ]
    }

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 d'une même zone. Les groupes d'instances gérés régionaux vous permettent de répartir vos instances sur plusieurs zones. Cela permet d'améliorer la disponibilité de votre application et de 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 du programme de mise à jour é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 n'est pas possible de choisir quelles instances ou zones sont 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 régional géré, à 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, elle 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 options versionTarget.isReached et isStable. Vous pouvez accéder à ces options à l'aide de l'outil gcloud ou de l'API. 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. Dans Cloud Console, accédez à la page Groupes d'instances.

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

Pour vérifier que la mise à jour du groupe d'instances est terminée, exécutez la commande describe et 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.

gcloud compute instance-groups managed describe instance-group-name \
        [--zone zone | --region zone]
    

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

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

Pour vérifier que la mise à jour du groupe d'instances est terminée, utilisez le gestionnaire du groupe d'instances get et 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.

GET https://compute.googleapis.com/compute/v1/projects/project-d/zones/zone/instanceGroupManagers/instance-group-name/get

Si le groupe d'instances est un groupe d'instances géré régional, remplacez zones/<var>zone</var></code> with par regions/region.

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

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

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.

Pour vérifier si le déploiement d'une mise à jour est terminé, récupérez la valeur du champ status.versionTarget.isReached :

  • 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 par 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 status.versionTarget.isReached est défini sur false lorsque le nombre de VM utilisant une version cible (versions[].instanceTemplates) ne correspond pas à la taille de la cible (versions[].targetSize).

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

Vous pouvez vérifier qu'un groupe d'instances géré est actif et opérationnel en vérifiant la valeur du champ status.isStable.

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

Vous pouvez consulter l'action currentAction en cours et le status de chaque instance d'un groupe d'instances géré à l'aide de l'outil de ligne de commande gcloud ou de l'API.

gcloud

gcloud compute instance-groups managed list-instances instance-group-name \
    [--filter="zone:(zone)" | --filter="region:(region)"]

gcloud affiche la liste des instances présentes dans le groupe, avec 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 GET à la méthode regionInstanceGroupManagers.listManagedInstances. Pour un groupe d'instances géré zonal, utilisez la méthode instanceGroupManagers.listManagedInstances.

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

L'API affiche la 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 valides du champ instanceStatus, reportez-vous à la section Vérifier l'état d'une instance.

Si l'instance subit une quelconque 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 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.

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]

Remplacez old-instance-template-name par le nom du modèle d'instance à restaurer.

Dans l'API, envoyez une requête PATCH à la ressource du gestionnaire de groupe d'instances :

PATCH 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 programme de mise à jour traite cette demande comme une mise à jour standard. Ainsi, toutes les options de mise à jour décrites dans ce document peuvent ê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 la fin de ce délai en secondes avant de considérer que l'instance est bien à jour et de passer au traitement de 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 que l'instance est bien mise à jour et de passer au traitement de l'instance suivante.
  4. Définissez des valeurs maxUnavailable et maxSurge faibles. Cela 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 l'ampleur 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 convertir le type d'une mise à jour de proactif à opportuniste. Si le groupe d'instances géré n'est pas redimensionné par d'autres services tels que l'autoscaler, le passage à une 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 affiche une réponse avec la liste des instances du 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 s'arrête.

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.

Les fonctionnalités de l'ancien champ instanceTemplate et du champ versions se superposent, 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 avancée à deux modèles (dite "Canary").

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, aucune ambiguïté n'existe 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 affiche une erreur, car l'intention n'est pas 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() affiche 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, aucune modification n'est apportée à ce que get() affiche dans le champ instanceTemplate.

Si le champ versions contient deux modèles d'instance spécifiés, la méthode get() affiche 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.

Étape suivante