Mettre à jour des instances dans un groupe d'instances géré

Ce document vous aide à décider comment appliquer les mises à jour de modèle d'instance et de configuration par instance aux instances de machine virtuelle (VM) d'un groupe d'instances géré.

Vous pouvez être amené à mettre à jour le modèle d'instance d'un MIG pour les raisons suivantes :

  • Pour mettre à jour votre application ou le système d'exploitation sur chaque instance.
  • Pour effectuer un test A/B afin de comparer différentes versions de la même application.
  • Pour effectuer une mise à jour Canary afin de minimiser les perturbations lors du test d'une nouvelle version.
  • Pour modifier d'autres spécifications relatives aux instances de votre MIG, telles que le type de machine ou les options de disque.

Appliquez une nouvelle version d'un modèle d'instance en utilisant l'une des méthodes suivantes :

  • Mise à jour progressive automatisée. Le MIG déploie automatiquement une nouvelle version d'un modèle d'instance sur l'ensemble des instances ou sur un sous-ensemble aléatoire d'instances gérées du MIG. Le champ d'application de la mise à jour et le niveau de perturbation dépendent de la règle de mise à jour que vous configurez.
  • Mise à jour sélective d'instances spécifiques. Vous pouvez cibler spécifiquement des instances choisies pour une mise à jour. Utilisez cette méthode pour les MIG avec état ou si vous souhaitez orchestrer la mise à jour manuellement.

Si vous disposez d'un MIG avec état, vous pouvez également utiliser une mise à jour sélective pour appliquer les modifications que vous apportez aux configurations par instance.

Si vous avez uniquement besoin de redimensionner un groupe d'instances géré, consultez la documentation expliquant comment ajouter ou supprimer des instances dans un MIG.

Limites

  • Vous ne pouvez pas utiliser de mise à jour progressive automatisée si votre groupe d'instances géré utilise une configuration avec état. Au lieu de cela, contrôlez les mises à jour et limitez les interruptions en mettant à jour des instances spécifiques de manière sélective.
  • Si vous utilisez des noms d'instances personnalisés et que vous ne configurez pas de disques ni de métadonnées avec état, vous pouvez utiliser des mises à jour automatisées. Toutefois, pour conserver les noms d'instance, vous devez définir la méthode de remplacement sur RECREATE.

Choisir entre les mises à jour automatiques et sélectives

Pour déployer automatiquement un nouveau modèle sur l'ensemble des instances ou sur un sous-ensemble d'instances d'un MIG sans état, définissez le type de mise à jour du MIG sur PROACTIVE. Si vous avez un MIG avec état ou si une mise à jour automatique est potentiellement trop perturbatrice, définissez le type de mise à jour du MIG sur OPPORTUNISTIC, puis mettez à jour des instances spécifiques.

Mises à jour automatisées et proactives

Définir le type de mise à jour du MIG sur PROACTIVE présente deux avantages principaux :

  • Le déploiement d'une mise à jour se fait automatiquement selon vos spécifications, sans nécessiter d'action supplémentaire après la requête initiale. Vous pouvez spécifier la vitesse de déploiement, le niveau de perturbation de votre service et le champ d'application de la mise à jour.
  • Vous pouvez automatiser des déploiements partiels pour des tests en version Canary.

Lorsque vous démarrez une mise à jour progressive proactive, le MIG planifie activement les actions afin d'appliquer les mises à jour demandées aux instances, le cas échéant. Dans de nombreux cas, cela signifie souvent supprimer et recréer des instances de manière proactive.

Pour plus d'informations, consultez la section Déployer automatiquement les mises à jour sur les instances d'un MIG.

Mises à jour sélectives

La mise à jour sélective d'instances spécifiques présente les avantages suivants :

  • Vous pouvez choisir les instances que vous souhaitez mettre à jour.
  • Vous pouvez appliquer une mise à jour en réduisant le niveau de perturbation au strict minimum nécessaire. 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. Par défaut, l'action minimale nécessaire est automatiquement effectuée.
  • Vous pouvez aussi choisir de redémarrer ou recréer l'instance même si ces actions ne sont pas nécessaires à la mise à jour. Par exemple, vous pouvez choisir 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.
  • Vous pouvez empêcher une mise à jour si celle-ci entraîne plus de perturbations que ce que vous pouvez vous permettre.

Pour empêcher la mise en concurrence d'une mise à jour proactive avec vos mises à jour sélectives, définissez le type de mise à jour du MIG sur OPPORTUNISTIC.

Mises à jour opportunistes

Lorsque le type de mise à jour est défini sur OPPORTUNISTIC, le MIG n'applique les mises à jour que lorsque vous appliquez une mise à jour de manière sélective sur des instances spécifiques ou lorsque le groupe d'instances géré crée des instances. Un MIG crée des instances lorsqu'il est redimensionné pour ajouter des instances, que ce soit automatiquement ou manuellement. 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 qui peut être appliquée au besoin sans aucune urgence et que vous avez un MIG en cours d'autoscaling, procédez à une mise à jour opportuniste afin que Compute Engine n'arrête pas activement des instances existantes pour appliquer la mise à jour. Lors du redimensionnement, l'autoscaler arrête de préférence les instances avec l'ancien modèle ainsi que les instances qui ne sont pas encore dans l'état RUNNING.

Pour plus d'informations, consultez la section Mettre à jour des instances dans un MIG.

Configurer une mise à jour opportuniste ou proactive

Par défaut, les mises à jour lancées à l'aide de Cloud Console ou de l'outil de ligne de commande gcloud sont proactivesce qui signifie qu'elles démarrent automatiquement. Les mises à jour lancées à l'aide de l'API Compute Engine sont opportunistes, ce qui signifie que le groupe d'instances géré n'applique pas de manière proactive le nouveau modèle aux instances existantes.

Pour déterminer si une mise à jour est opportuniste ou proactive, définissez le mode sur opportuniste ou proactif à l'aide de Cloud Console, de l'outil de ligne de commande gcloud ou de l'API Compute Engine.

Console

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

    Accéder à la page Groupes d'instances

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

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

  4. Sous Mode de mise à jour, choisissez la mise à jour opportuniste ou proactive.

gcloud

Exécutez la commande rolling-action start-update, puis définissez l'option --type sur opportunistic ou proactive.

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

API

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

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

{
  "updatePolicy": {
    "type": "TYPE" # Choose an opportunistic or proactive update
  },
  "versions": [{
    "instanceTemplate": "global/instanceTemplates/NEW_TEMPLATE",
    }]
}

Remplacez l'élément suivant :

  • NEW_TEMPLATE : le nom du nouveau modèle du groupe
  • TYPE : le type de mise à jour, OPPORTUNISTIC ou PROACTIVE

Pour en savoir plus sur la configuration d'un nouveau modèle et l'application de ce modèle aux instances nouvelles et existantes d'un MIG, consultez les pages suivantes :

Relation entre les champs versions et instanceTemplate

Si vous utilisez l'API Compute Engine, nous vous recommandons d'utiliser les champs instanceGroupManagers.versions et regionInstanceGroupManagers.versions pour configurer des modèles d'instance pour les MIG zonaux et régionaux.

Les fonctionnalités de l'ancien champ instanceTemplate se recoupent avec le champ versions car les deux champs permettent de spécifier le modèle d'instance que le MIG 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 MIG continuent d'accepter le 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 sur 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 MIG.

    Par exemple, dans la requête suivante, le champ de niveau supérieur instanceTemplate et le champ versions indiquent un même modèle d'instance qui diffère du modèle actuel et le MIG est donc mis à jour vers le nouveau modèle d'instance :

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

    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 update() et fournissez les deux champs, mais un seul champ est mis à jour :

    {
     "instanceTemplate": "global/instanceTemplates/CURRENT_TEMPLATE",
     "versions": [
      {
       "instanceTemplate": "global/instanceTemplates/NEW_TEMPLATE"
      }
     ],
     "updatePolicy": {
       "type": "PROACTIVE"
     }
    }
    
  • Vous définissez les deux champs sur des valeurs qui ne correspondent pas et ces deux valeurs sont différentes du modèle d'instance actuel du MIG.

    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 la méthode get() dans le champ instanceTemplate ne change pas.

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 la rétrocompatibilité, la méthode setInstanceTemplate() se comporte comme auparavant et vous permet de modifier le modèle utilisé par le MIG 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 MIG de déployer activement un modèle d'instance qui n'est pas explicitement spécifié dans le champ versions.

Étape suivante