Instance Template est un modèle immuable de VM (machine type, disque, réseau, image, compte de service, métadonnées) que Compute Engine instancie à la demande. Il ne crée aucune VM par lui-même : c’est le Managed Instance Group (MIG) qui le consomme au runtime (autohealing, autoscaling, rolling update) directement via l’API GCP — pas besoin de repasser par Terraform à chaque recréation d’instance. Équivalent GCP du Launch Template AWS.
Résolution de l’image de boot
Trois paramètres, dans cet ordre de priorité :
| Paramètre | Rôle |
|---|---|
source_image | Version figée d’une image — prioritaire si renseigné, résultat prévisible (les VMs recréées par le MIG utilisent toujours la même version) |
source_image_family | Dernière version d’une famille au moment de la création de chaque VM — les VMs recréées plus tard par le MIG peuvent donc différer entre elles. La famille elle-même n’est pas un champ dynamique : elle est fixée à la création de l’image (voir Création d’une image custom) — l’Instance Template ne fait que suivre la dernière image portant cette étiquette |
source_image_project | Projet GCP où chercher l’image/la famille — piège courant : pour une image custom il faut explicitement pointer vers son propre projet, sinon la résolution retombe sur un projet public par défaut et échoue en “not found” |
Si l’image vit dans un projet centralisé (image factory) :
- le compte de service qui déploie a besoin de
roles/compute.imageUsersur ce projet, - l’org policy
constraints/compute.trustedImageProjectsdoit lister ce projet — sinon l’apply échoue même avec les bons rôles IAM.
Type de disque de boot
| Type | Caractéristique |
|---|---|
| pd-standard | Disque réseau HDD — lent, à éviter pour un boot disk |
| pd-balanced | Bon compromis perf/coût — recommandé par défaut |
| pd-ssd | SSD réseau, plus performant, plus cher |
| pd-extreme | IOPS provisionnées, cas très exigeants |
| hyperdisk-* | Nouvelle génération — seule option compatible avec certaines familles de machines récentes (compatibilité exacte par machine_type à vérifier dans la doc GCP) |
| local-ssd | Attaché physiquement à l’hôte, éphémère — jamais pour un disque de boot |
Contraintes de scheduling forcées
Certaines combinaisons imposent des valeurs qui priment sur ce qui est demandé ailleurs :
- Spot / Preemptible →
automatic_restart = falseeton_host_maintenance = TERMINATE(jamais de live migration, la VM est simplement tuée) - GPU attaché → mêmes contraintes que le spot (pas de live migration possible avec un GPU)
- Confidential VM en mode SEV-SNP → force
min_cpu_platform = "AMD Milan"
En relation avec
- Managed Instance Group (MIG) — consomme le template au runtime, gère autohealing/autoscaling/rolling update
- Compute Engine — l’instance elle-même une fois créée
- Persistent Disk — détail du stockage bloc attaché
- Firewall Rules — les tags réseau posés par le template doivent matcher les règles firewall