Appliquer de nouvelles configurations de VM dans un MIG

Cette page explique comment configurer les instances de machine virtuelle (VM) d'un groupe d'instances géré (MIG) et les méthodes que vous pouvez utiliser pour appliquer la configuration à des VM existantes du groupe.

Vous spécifiez la configuration prévue pour les VM dans un MIG à l'aide des composants de configuration de VM suivants:

  • Obligatoire: modèle d'instance
  • Facultatif: Configuration de toutes les instances
  • Facultatif: Configuration avec état

Chaque fois que vous mettez à jour la configuration prévue à l'aide de ces composants, Compute Engine applique automatiquement votre configuration mise à jour aux nouvelles VM ajoutées au groupe.

Pour appliquer une configuration mise à jour aux VM existantes, utilisez les méthodes décrites sur cette page:

  • Déploiements automatiques avec un budget d'interruption et des mises à jour Canary facultatives des nouveaux modèles
  • Mises à jour sélectives et manuelles sur des VM spécifiques uniquement, afin de minimiser les perturbations
  • Recréer des VM spécifiques

Vous pouvez également configurer votre groupe d'instances géré pour appliquer la dernière configuration disponible aux VM lors des réparations des VM. Pour en savoir plus, consultez la section Appliquer les mises à jour de configuration lors des réparations.

Si vous avez uniquement besoin de redimensionner un groupe d'instances géré, consultez la documentation expliquant comment ajouter ou supprimer des VM dans un MIG. Si vous souhaitez en savoir plus sur la configuration des fonctionnalités de MIG, consultez la documentation sur l'autoscaling, l'autoréparation et l'équilibrage de charge. et les charges de travail avec état.

Avant de commencer

  • Si ce n'est pas déjà fait, configurez l'authentification. L'authentification est le processus permettant de valider votre identité pour accéder aux services et aux API Google Cloud. Pour exécuter du code ou des exemples depuis un environnement de développement local, vous pouvez vous authentifier auprès de Compute Engine comme suit :

    Select the tab for how you plan to use the samples on this page:

    Console

    When you use the Google Cloud console to access Google Cloud services and APIs, you don't need to set up authentication.

    gcloud

    1. Install the Google Cloud CLI, then initialize it by running the following command: 

      gcloud init
    2. Set a default region and zone.

      3. REST

      Pour utiliser les exemples d'API REST de cette page dans un environnement de développement local, vous devez utiliser les identifiants que vous fournissez à gcloud CLI.

        Install the Google Cloud CLI, then initialize it by running the following command: 

        gcloud init

      Pour en savoir plus, consultez la section S'authentifier pour utiliser REST dans la documentation sur l'authentification Google Cloud.

Composants de configuration pour les VM d'un MIG

Pour configurer les VM dans un MIG, utilisez les composants suivants:

ComposantPropriétésCas d'utilisation
Modèle d'instance Type de machine, image de disque de démarrage, libellés, script de démarrage et autres propriétés de VM Obligatoire: Utilisez un modèle d'instance pour définir les propriétés d'instance obligatoires et facultatives pour toutes les VM du groupe.

Facultatif: Si vous souhaitez tester la deuxième configuration de VM en version Canary, vous pouvez ajouter un deuxième modèle d'instance au groupe et l'appliquer à un sous-ensemble de VM du groupe.
Configuration de toutes les instances Libellés et métadonnées (Facultatif) Utilisez une configuration de toutes les instances pour remplacer rapidement les propriétés du modèle d'instance pour toutes les VM du groupe.
Configuration avec état Disques avec état, adresses IP et métadonnées Facultatif: Si vous devez gérer une charge de travail avec état, ajoutez une configuration avec état aux VM du groupe.

Si vous mettez à jour une configuration pour le groupe via ces composants, vous devez appliquer la configuration mise à jour aux VM existantes du groupe pour que la configuration mise à jour soit effective.

Méthodes d'application d'une nouvelle configuration aux VM existantes

Après avoir mis à jour la configuration des VM d'un MIG, vous pouvez appliquer la nouvelle configuration aux VM existantes du groupe à l'aide des méthodes suivantes:

  • Automatique (proactive): utilisez cette méthode si vous souhaitez que le MIG applique automatiquement de nouvelles configurations à toutes les VM ou au sous-ensemble de VM existantes du groupe. Le niveau de perturbation des VM en cours d'exécution dépend de la règle de mise à jour que vous configurez. Vous pouvez utiliser cette méthode pour mettre à jour les nouveaux modèles d'instances de manière Canary. Pour utiliser cette méthode, définissez le type de mise à jour du MIG sur "proactif".
  • Mise à jour sélective (opportuniste) : utilisez cette méthode si vous souhaitez appliquer la mise à jour manuellement ou mettre à jour toutes les VM existantes du groupe simultanément. Vous ciblez tout ou partie des VM à mettre à jour vers la dernière configuration. Pour utiliser cette méthode, définissez le type de mise à jour du MIG sur "Quand l'occasion se présente".
  • Recréation de VM: appliquez de nouvelles configurations en recréant des VM spécifiques.

Pour en savoir plus sur la définition du type de mise à jour d'un MIG, consultez la page Configurer une mise à jour proactive ou opportuniste.

Automatique (proactive)

Un type de mise à jour automatique est également appelé type de mise à jour proactive. Lorsque vous définissez le type de mise à jour du MIG sur de manière proactive, le MIG applique automatiquement les configurations mises à jour aux VM si nécessaire.

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.

Pour savoir comment définir le type de mise à jour du MIG, consultez la page Configurer une mise à jour proactive ou opportuniste.

Pour en savoir plus sur les déploiements automatiques, consultez la page Appliquer automatiquement les mises à jour de configuration de VM dans un MIG.

Mise à jour sélective (opportuniste)

Un type de mise à jour sélective est également appelé type de mise à jour opportuniste. Lorsque vous définissez le type de mise à jour du MIG sur le modèle opportuniste, le MIG n'applique les nouvelles configurations aux VM existantes que lorsque vous ciblez de manière sélective des VM spécifiques à mettre à jour.

La définition du type de mise à jour du MIG sur le modèle opportuniste présente les avantages suivants:

  • Vous pouvez choisir les VM que vous souhaitez mettre à jour.
  • Vous pouvez contrôler la planification et la séquence des mises à jour.
  • Vous pouvez utiliser la gcloud CLI ou REST pour mettre à jour immédiatement toutes les instances.

Dans certains cas, un type de mise à jour sélective 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, s'il s'agit des cas suivants :

  • L'une des VM de votre MIG est défaillante et doit être réparée, mais vous ne souhaitez pas que sa configuration soit modifiée. Si vous définissez le type de mise à jour du MIG sur opportuniste et que vous ne forcez pas l'application des mises à jour lors des réparations, Compute Engine répare la VM à partir de la même configuration que celle utilisés pour créer cette VM, même si le modèle d'instance d'origine n'existe plus.

  • Vous disposez d'un MIG avec autoscaling et vous souhaitez appliquer une mise à jour non critique sans urgence. Pour vous assurer que Compute Engine n'arrête pas vos VM existantes pour appliquer la mise à jour, définissez le type de mise à jour du MIG sur opportuniste. Lors d'un scaling vertical, l'autoscaler arrête de préférence les VM avec l'ancienne configuration. Lorsque le groupe effectue un scaling horizontal, il crée des VM avec la dernière configuration.

Pour savoir comment définir le type de mise à jour du MIG, consultez la page Configurer une mise à jour proactive ou opportuniste.

Pour en savoir plus sur la mise à jour sélective des VM, consultez la page Appliquer de manière sélective les mises à jour de configuration de VM dans un MIG.

Recréation des VM

Vous pouvez recréer n'importe quelle VM dans un MIG. Dans ce cas, le MIG applique toute configuration mise à jour qui n'a pas encore été appliquée à cette VM. Pour plus d'informations, consultez la section Recréer des VM dans un MIG.

Configurer une mise à jour proactive ou opportuniste

Pour appliquer automatiquement de nouvelles configurations aux VM existantes, définissez le type de mise à jour du MIG sur "proactif". Pour appliquer de nouvelles configurations aux VM existantes uniquement lorsque vous sélectionnez une VM à mettre à jour, définissez le type de mise à jour du MIG sur "Quand l'occasion se présente".

Utilisez la console Google Cloud, Google Cloud CLI ou REST.

Console

  1. Dans Google 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 Mettre à jour les VM.

  4. Pour définir un autre modèle pour le groupe, sélectionnez le modèle d'instance que vous souhaitez utiliser sous Nouveau modèle.

  5. Sous Mettre à jour la configuration, sélectionnez la mise à jour automatique ou sélective.

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=NEW_TEMPLATE \
    --type=TYPE

Vous pouvez également utiliser la commande bêta update et inclure l'option --update-policy-type.

gcloud beta compute instance-groups managed update INSTANCE_GROUP_NAME \
    --update-policy-type=TYPE

Remplacez les éléments suivants :

  • INSTANCE_GROUP_NAME : nom du groupe
  • NEW_TEMPLATE : le nom du nouveau modèle du groupe
  • TYPE : le type de mise à jour, opportunistic ou proactive

REST

Appelez la méthode patch pour une ressource de MIG zonal ou régional.

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 les éléments suivants :

  • PROJECT_ID: projet dans lequel le MIG existe.
  • REGION: région où se trouve le groupe d'instances géré. Pour un groupe d'instances géré zonal, remplacez regions/REGION par zones/ZONE.
  • INSTANCE_GROUP_NAME : nom du groupe.
  • 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 VM nouvelles et existantes d'un MIG, consultez les pages suivantes :

Vérifier le type de règle de mise à jour de votre groupe

Vous pouvez afficher le type de règle de mise à jour de votre MIG actuellement configuré ("opportuniste" ou "proactif") et d'autres paramètres de stratégie de mise à jour à l'aide de gCloud CLI ou de REST.

gcloud

Exécutez la commande describe et ajoutez l'option --format pour ne répertorier que les paramètres updatePolicy.

gcloud beta compute instance-groups managed describe INSTANCE_GROUP_NAME \
    --format="(updatePolicy)"

REST

Envoyez une requête GET sur un MIG zonal ou régional, puis vérifiez le champ updatePolicy.

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

Pour modifier le type de règle, consultez la page Configurer une mise à jour proactive ou opportuniste.

Mises à jour pour les VM suspendues et arrêtées

Si vous avez suspendu et arrêté des pools de VM dans un MIG, vous pouvez mettre à jour de manière sélective (opportuniste) des VM suspendues ou arrêtées, comme vous mettez à jour d'autres VM en cours d'exécution. Si vous configurez des mises à jour automatiques (proactives), le MIG met à jour les VM dans l'ordre suivant:

  1. VM en cours d'exécution, suspendues et arrêtées
  2. VM avec état SUSPENDING ou STOPPING

Pour une mise à jour automatique, le MIG calcule la surutilisation maximale et la limite maximale d'indisponibilité en fonction du nombre cible de VM en cours d'exécution uniquement, et ne prend pas en compte les VM du pool de secours.

Si la mise à jour automatique nécessite le remplacement des VM du groupe, le MIG effectue les opérations suivantes:

  1. Il supprime les VM suspendues et arrêtées.
  2. Crée des VM avec le nouveau modèle d'instance.
  3. Effectue le processus d'initialisation.
  4. Suspend ou arrête les VM.

Si la mise à jour automatique ne nécessite que l'actualisation ou le redémarrage des VM du groupe, le MIG effectue les opérations suivantes:

  1. Réactive ou démarre les VM.
  2. Effectue la mise à jour sur les VM lorsqu'elles sont en cours d'exécution.
  3. Effectue le processus d'initialisation.
  4. Il suspend ou arrête les VM.

Mises à jour Canary

Si vous souhaitez lancer des mises à jour Canary dans un MIG qui a suspendu ou arrêté des VM, les points suivants s'appliquent :

  • En mode de stratégie de secours manual, le MIG ne met à jour que les VM en cours d'exécution en fonction du nombre ou du pourcentage de VM auxquelles vous souhaitez appliquer la mise à jour. Les VM suspendues et arrêtées restent dans les versions précédentes.
  • En mode de stratégie de secours scale-out-pool, vous ne pouvez pas lancer de mise à jour Canary dans le MIG.

Relation entre les champs versions et instanceTemplate

Si vous utilisez REST, 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 VM. 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 VM. 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