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 pour les nouveaux modèles
  • Mises à jour sélectives et manuelles pour 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 de VM. Pour en savoir plus, consultez 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, 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 permet 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 en sélectionnant l'une des options suivantes :

    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. Installez la Google Cloud CLI. Une fois que la Google Cloud CLI est installée, initialisez-la en exécutant la commande suivante : 

      gcloud init

      Si vous utilisez un fournisseur d'identité (IdP) externe, vous devez d'abord vous connecter à la gcloud CLI avec votre identité fédérée.

    2. Set a default region and zone.

    REST

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

      Installez la Google Cloud CLI. Une fois que la Google Cloud CLI est installée, initialisez-la en exécutant la commande suivante : 

      gcloud init

      Si vous utilisez un fournisseur d'identité (IdP) externe, vous devez d'abord vous connecter à la gcloud CLI avec votre identité fédérée.

    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, étiquettes, script de démarrage, interfaces réseau 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 une deuxième configuration de VM (test Canary), vous pouvez ajouter un deuxième modèle d'instance au groupe et l'appliquer à un sous-ensemble de VM du groupe.
Configuration applicable à toutes les instances Étiquettes et métadonnées Facultatif : Utilisez une configuration applicable à 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 cette configuration 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 à un sous-ensemble des 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 en appliquant une approche Canary. Pour utiliser cette méthode, définissez le type de mise à jour du MIG sur "proactif".
  • 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 Configurer une mise à jour proactive ou opportuniste.

Mise à jour automatique (proactive)

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

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

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

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

Pour en savoir plus sur les déploiements automatiques, consultez 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 "Quand l'occasion se présente", 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.

Définir le type de mise à jour du MIG sur "Quand l'occasion se présente" offre 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 l'API REST pour mettre à jour immédiatement toutes les instances.

Dans certains cas, une mise à jour sélective peut être utile, car il est préférable de ne pas provoquer d'instabilité sur le système si cela peut être évité. Cela s'applique aux 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 "Quand l'occasion se présente" et que vous ne forcez pas l'application des mises à jour lors des réparations, Compute Engine répare la VM en conservant la configuration utilisée 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 et sans caractère urgent. 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 "Quand l'occasion se présente". 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 Configurer une mise à jour proactive ou opportuniste.

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

Recréer des VM

Vous pouvez recréer n'importe quelle VM dans un MIG. En pareil cas, le MIG applique toute configuration mise à jour qui n'a pas encore été appliquée à la VM concernée. Pour plus d'informations, consultez 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 , la Google Cloud CLI ou l'API REST.

Console

  1. Dans la console Google Cloud , 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. Cliquez sur Modifier.

  4. Cliquez sur Règle de mise à jour pour développer la section.

  5. Choisissez la mise à jour sélective ou automatique.

  6. Facultatif : Si vous choisissez Automatique, vous pouvez définir des options supplémentaires ou utiliser les valeurs par défaut.

  7. Cliquez sur Enregistrer.

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 : nom du nouveau modèle défini pour le groupe
  • TYPE : 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 MIG. Pour un MIG zonal, remplacez regions/REGION par zones/ZONE.
  • INSTANCE_GROUP_NAME : nom du groupe.
  • NEW_TEMPLATE : nom du nouveau modèle défini pour le groupe.
  • TYPE : 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 actuellement configuré pour votre MIG ("quand l'occasion se présente" ou "proactif") et d'autres paramètres de règle de mise à jour à l'aide de la gCloud CLI ou de l'API REST.

gcloud

Exécutez la commande describe et ajoutez l'option --format pour ne lister 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 Configurer une mise à jour proactive ou opportuniste.

Mise à jour des VM suspendues et arrêtées

Si vous avez des pools de VM suspendues et arrêtées dans un MIG, vous pouvez mettre à jour de manière sélective (Quand l'occasion se présente) les VM suspendues ou arrêtées comme vous le faites pour les 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, VM suspendues et VM arrêtées
  2. VM présentant l'é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 de certaines VM du groupe, le MIG effectue les opérations suivantes :

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

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

  1. Il réactive ou démarre les VM.
  2. Il effectue la mise à jour sur les VM lorsqu'elles sont en cours d'exécution.
  3. Il 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 comporte des VM suspendues ou arrêtées, les règles suivantes s'appliquent :

  • En mode de règle 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 auquel vous souhaitez appliquer la mise à jour. Les VM suspendues et arrêtées restent dans les versions précédentes.
  • En mode de règle 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.

En termes de fonctionnalité, l'ancien champ instanceTemplate et le champ versions se recoupent, car tous deux 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.

À des fins de rétrocompatibilité, les MIG continuent d'accepter le champ instanceTemplate de niveau supérieur. Nous vous recommandons toutefois de n'utiliser que le champ versions. L'utilisation simultanée du champ instanceTemplate de premier niveau et du champ 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 spécifient le même modèle d'instance, différent du modèle actuel, de sorte que le MIG est 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 qui diffère 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 une erreur est renvoyée, 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 n'est pas modifié.

Si le champ versions contient deux modèles d'instance spécifiés, la méthode get() renvoie un champ instanceTemplate de niveau supérieur 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, en vous permettant de modifier le modèle utilisé par le MIG pour créer des VM. Lorsque vous appelez cette méthode, la valeur du champ versions est remplacée 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.

Étapes suivantes