Compute Engine : déployer une VM Linux et Windows — tutoriel ACE 2026

Déployer une VM Linux et une VM Windows sur Compute Engine, comprendre les familles de machines E2/N2, choisir entre Persistent Disk et Hyperdisk, configurer SSH et RDP, prendre un snapshot et automatiser au démarrage. Tutoriel pas-à-pas du cluster Associate Cloud Engineer.

📍 Article principal du cluster : Devenir Google Cloud Associate Cloud Engineer (ACE) — Guide complet 2026
Cet article fait partie du cluster « GCP ACE ». Pour la vue d’ensemble, lire d’abord le pilier.

Introduction

Compute Engine est le service de virtualisation sur lequel reposent encore aujourd’hui la majorité des charges Google Cloud, et il est largement représenté à l’examen ACE — combien de questions débutent par « Quel type de machine choisiriez-vous pour … ? ». Ce tutoriel couvre la création d’une VM Linux et d’une VM Windows, le choix raisonné d’une famille de machine entre E2, N2 et plus exotiques, la différence Persistent Disk vs Hyperdisk introduite avec les nouvelles séries, et les opérations courantes : SSH, RDP, snapshot, restore et startup script. Tout est validé sur la documentation officielle Compute Engine d’avril 2026.

Prérequis

• Compte GCP Free Trial actif et VPC vpc-lab créé (cf. VPC GCP : subnets, firewall, Cloud NAT, peering).
• Subnet subnet-web-eu9 en europe-west9 disponible.
• Règles firewall fw-allow-web et fw-allow-ssh-bureau actives.
• gcloud CLI configuré ; OpenSSH client (Linux/macOS) ou Putty/Windows Terminal (Windows).
• Un client RDP pour la VM Windows (Microsoft Remote Desktop sur macOS/iOS, mstsc.exe sur Windows, Remmina sur Linux).
• Niveau attendu : intermédiaire en système. Temps estimé : 75 minutes.

Étape 1 — Choisir la famille de machine

Compute Engine offre une bonne trentaine de familles de machines en avril 2026. Pour un candidat ACE débutant, seules quelques-unes comptent vraiment. La famille E2 (général, économique) est l’entrée de gamme : machines partagées, parfaites pour les labs et les charges légères, jusqu’à 32 vCPU. La famille N2 (général, équilibrée) est le cheval de bataille de la production : performance prévisible, gamme large, jusqu’à 128 vCPU. La famille C3 est compute-optimized pour HPC et bases haute performance ; M3 est memory-optimized pour SAP HANA et Redis volumineux ; A3 et G2 embarquent des GPU pour ML et transcodage.

À l’examen, on attend que vous sachiez répondre rapidement : « charge web standard avec budget serré → E2 », « base PostgreSQL prod → N2 », « calcul scientifique → C3 », « inférence ML → A3 ou G2 ». Pour ce tutoriel, nous utiliserons e2-small (2 vCPU partagés, 2 Go RAM) qui rentre confortablement dans le crédit Free Trial.

Étape 2 — Choisir l’image système

Compute Engine maintient un catalogue d’images publiques officielles, mises à jour régulièrement par les éditeurs. Les plus utilisées pour ACE : debian-12, ubuntu-2404-lts, rhel-9, rocky-linux-9 côté Linux ; windows-server-2022-dc, windows-server-2025-dc côté Windows. Lister les images disponibles aide à choisir la dernière LTS au lieu d’une version périmée.

# Lister les familles d'images Ubuntu LTS recentes
gcloud compute images list --filter="family~ubuntu-2404" --limit=5

# Lister les Windows Server disponibles
gcloud compute images list --filter="family~windows-server" --limit=10

# Voir les details d'une image precise
gcloud compute images describe-from-family ubuntu-2404-lts \
  --project=ubuntu-os-cloud

Pointez toujours sur le family et non sur le nom complet de l’image (qui change à chaque release) : ubuntu-2404-lts pointera automatiquement vers la dernière révision sécurisée publiée par Canonical. Pour les images Windows, comptez environ 0,04 USD/heure de licence Microsoft en plus du coût de la VM elle-même — c’est le surcoût classique des images sous licence propriétaire.

Étape 3 — Créer une VM Linux

Première VM concrète. On la place dans le subnet subnet-web-eu9 créé précédemment, on lui attache un disque persistant balanced de 20 Go, on lui ajoute le tag ssh-allowed pour bénéficier de la règle firewall correspondante, et on la spécifie sans IP externe pour la sécurité.

gcloud compute instances create vm-web-linux \
  --zone=europe-west9-b \
  --machine-type=e2-small \
  --image-family=ubuntu-2404-lts \
  --image-project=ubuntu-os-cloud \
  --subnet=subnet-web-eu9 \
  --no-address \
  --tags=ssh-allowed,web-server \
  --boot-disk-size=20GB \
  --boot-disk-type=pd-balanced \
  --metadata=enable-oslogin=TRUE \
  --service-account=$SA_EMAIL \
  --scopes=cloud-platform \
  --project=lab-ace-2026

Quelques options méritent un commentaire. --no-address retire l’IP publique : la VM restera invisible d’Internet, mais sortira via Cloud NAT pour ses apt update. enable-oslogin=TRUE active OS Login, qui mappe les comptes utilisateurs Linux à votre identité Google IAM — vous n’avez plus à gérer de clés SSH manuellement. --service-account attache un service account dédié à la VM, ce qui évite le default Compute SA trop permissif. Le boot disk en pd-balanced est un bon compromis prix/performance ; pour une base de données préférez pd-ssd.

Étape 4 — Se connecter en SSH avec OS Login

Avec OS Login activé, gcloud gère automatiquement la génération et la rotation des clés SSH derrière le décor. Vous n’avez littéralement rien à configurer côté local — pas de ~/.ssh/authorized_keys à maintenir.

# Se connecter via Cloud Shell ou gcloud local
gcloud compute ssh vm-web-linux --zone=europe-west9-b --tunnel-through-iap

# Verifier les infos de la VM
hostnamectl
cat /etc/os-release
ip addr show
sudo apt update && sudo apt install -y nginx

L’option --tunnel-through-iap utilise Identity-Aware Proxy pour établir le SSH sans avoir besoin d’IP publique sur la VM ni de règle firewall ouverte au monde. C’est la méthode recommandée pour accéder à des VMs privées sur GCP — une question régulièrement posée à l’examen. Au lieu d’ouvrir SSH à votre IP, vous accordez le rôle roles/iap.tunnelResourceAccessor à votre utilisateur et vous accédez via IAP.

Pour que IAP fonctionne, ajoutez aussi une règle firewall qui autorise IAP à atteindre la VM en TCP/22 :

gcloud compute firewall-rules create fw-allow-iap-ssh \
  --network=vpc-lab \
  --direction=INGRESS \
  --action=ALLOW \
  --rules=tcp:22 \
  --source-ranges=35.235.240.0/20 \
  --target-tags=ssh-allowed

Le range 35.235.240.0/20 est la plage officielle d’Identity-Aware Proxy — elle est documentée et stable. Toutes les VMs taguées ssh-allowed deviennent accessibles via IAP, sans IP publique. C’est un pattern de production très propre.

Étape 5 — Créer une VM Windows Server

Pour la VM Windows, on prend une famille N2 plus à l’aise avec Windows Server (qui consomme plus de RAM qu’un Linux minimal), un disque pd-ssd pour le système, et l’image Windows Server 2025 Datacenter.

gcloud compute instances create vm-app-windows \
  --zone=europe-west9-b \
  --machine-type=n2-standard-2 \
  --image-family=windows-server-2025-dc \
  --image-project=windows-cloud \
  --subnet=subnet-app-eu9 \
  --no-address \
  --boot-disk-size=64GB \
  --boot-disk-type=pd-ssd \
  --tags=rdp-allowed \
  --project=lab-ace-2026

Côté firewall, créez une règle qui autorise RDP (3389) depuis votre IP uniquement, ou via IAP. Comptez 4 à 5 minutes pour le boot initial Windows — c’est plus long que Linux à cause des mises à jour Windows en arrière-plan. Les Windows Datacenter facturent une licence Microsoft additionnelle ; vous la voyez sur le détail de la facture sous le libellé « Premium image – Microsoft Windows Server ».

Étape 6 — Définir un mot de passe Windows et se connecter en RDP

Sur GCP, le mot de passe administrateur d’une VM Windows n’est pas créé à la volée — vous le générez après la création de la VM via une API qui injecte une nouvelle paire user/password.

# Generer un mot de passe Administrateur pour la VM Windows
gcloud compute reset-windows-password vm-app-windows \
  --zone=europe-west9-b \
  --user=admin

# Recuperer l'IP interne (la VM n'a pas d'IP externe)
gcloud compute instances describe vm-app-windows \
  --zone=europe-west9-b \
  --format="get(networkInterfaces[0].networkIP)"

# Pour la connexion RDP via IAP TCP forwarding :
gcloud compute start-iap-tunnel vm-app-windows 3389 \
  --local-host-port=localhost:3389 \
  --zone=europe-west9-b

La commande start-iap-tunnel ouvre un tunnel local sur 127.0.0.1:3389 qui forwarde vers le port RDP de la VM via IAP. Côté client, lancez votre RDP sur localhost:3389 avec l’utilisateur admin et le mot de passe affiché par reset-windows-password. Vous obtenez une session graphique sur la VM sans jamais l’exposer à Internet — pattern de prod recommandé.

Étape 7 — Ajouter un disque persistant secondaire

Cas typique : votre VM Linux héberge une application qui stocke des fichiers utilisateurs ; vous voulez les isoler du disque système pour pouvoir les détacher/réattacher en cas de crash.

# Creer un disque pd-balanced de 50 Go
gcloud compute disks create disk-data-vm-web \
  --zone=europe-west9-b \
  --size=50GB \
  --type=pd-balanced

# Attacher le disque a la VM
gcloud compute instances attach-disk vm-web-linux \
  --disk=disk-data-vm-web \
  --zone=europe-west9-b

# Sur la VM, formater puis monter
sudo lsblk
sudo mkfs.ext4 -m 0 /dev/sdb
sudo mkdir /mnt/data
sudo mount -o discard,defaults /dev/sdb /mnt/data
echo "/dev/sdb /mnt/data ext4 discard,defaults 0 2" | sudo tee -a /etc/fstab

Le flag -m 0 à mkfs économise 5 % d’espace réservé inutile sur un disque non-système. Le montage discard active TRIM, indispensable sur SSD pour éviter la dégradation de performance au fil du temps. Pour les nouvelles séries de machines (C4, N4, X4), Persistent Disk n’est pas disponible — il faut utiliser Hyperdisk Balanced à la place, qui se commande de la même façon mais avec --type=hyperdisk-balanced et permet de configurer indépendamment la capacité, les IOPS et le débit.

Étape 8 — Snapshot et restore

Un snapshot est une copie incrémentale du disque, stockée dans Cloud Storage côté Google et restaurable en quelques minutes. C’est la sauvegarde minimum vitale d’une VM Compute Engine.

# Prendre un snapshot du boot disk
gcloud compute disks snapshot vm-web-linux \
  --zone=europe-west9-b \
  --snapshot-names=snap-vm-web-$(date +%Y%m%d) \
  --storage-location=europe-west9

# Restaurer le snapshot dans un nouveau disque
gcloud compute disks create vm-web-restored \
  --source-snapshot=snap-vm-web-20260428 \
  --zone=europe-west9-b \
  --type=pd-balanced

# Politique de snapshot automatique horaire (production)
gcloud compute resource-policies create snapshot-schedule daily-snap \
  --region=europe-west9 \
  --max-retention-days=14 \
  --on-source-disk-delete=apply-retention-policy \
  --daily-schedule \
  --start-time=02:00

Le snapshot incrémental ne re-stocke que les blocs modifiés depuis le snapshot précédent. Le coût mensuel d’un snapshot est faible (autour de 0,026 USD/Go-mois pour le standard storage, à vérifier sur la page de tarification officielle). Une politique resource-policies automatise les snapshots quotidiens — c’est la bonne pratique pour toute VM importante en production.

Étape 9 — Startup script pour automatiser le boot

Un startup script s’exécute à chaque démarrage de la VM. Cas d’usage type : installer Nginx, déployer une app, attacher des disques. Vous le passez via --metadata=startup-script=... ou depuis un fichier.

cat > /tmp/startup.sh <<'EOF'
#!/bin/bash
set -euo pipefail
apt-get update
apt-get install -y nginx
echo "<h1>Bonjour depuis $(hostname)</h1>" > /var/www/html/index.html
systemctl enable --now nginx
EOF

gcloud compute instances create vm-web-auto \
  --zone=europe-west9-b \
  --machine-type=e2-small \
  --image-family=ubuntu-2404-lts \
  --image-project=ubuntu-os-cloud \
  --subnet=subnet-web-eu9 \
  --tags=web-server \
  --metadata-from-file=startup-script=/tmp/startup.sh \
  --project=lab-ace-2026

La sortie du startup script atterrit dans Cloud Logging sous le nom de log google.compute.instances.startup et dans /var/log/syslog sur la VM. Pour déboguer un script qui ne fait pas ce qu’il devrait, vérifier ces deux endroits dans cet ordre. Pour des configurations plus complexes, préférez un instance template + managed instance group avec startup script — pattern standard en production.

Étape 10 — Cleanup

# Supprimer les VMs et leurs disques
gcloud compute instances delete vm-web-linux vm-app-windows vm-web-auto \
  --zone=europe-west9-b --delete-disks=all --quiet

# Supprimer les disques orphelins
gcloud compute disks delete disk-data-vm-web vm-web-restored \
  --zone=europe-west9-b --quiet

# Supprimer les snapshots et la politique
gcloud compute snapshots delete snap-vm-web-20260428 --quiet
gcloud compute resource-policies delete daily-snap --region=europe-west9 --quiet

Erreurs fréquentes

Adaptation au contexte ouest-africain

Choix de zone et coût. Pour Dakar, Abidjan, Bamako, la zone optimale est europe-west9-a/b/c (Paris). Pour Casablanca/Tunis, europe-west1 (Belgique) est légèrement moins cher pour certaines familles. Vérifiez les prix unitaires sur la page tarification Compute Engine, qui varie sensiblement de 5 à 15 % entre régions européennes.

Surveillance facture. Les VMs N2 et plus coûtent vite : un n2-standard-2 24h/24 sur 30 jours dépasse les 70 USD. Pour un lab, créez/détruisez les VMs au lieu de les laisser tourner. Activez systématiquement un budget alert à 50 USD comme indiqué dans le tutoriel Compte GCP gratuit.

Coupures électriques côté client. Un délestage à Dakar coupe votre Cloud Shell mais pas la VM en cours d’exécution sur GCP. Si vous avez un script qui tourne, lancez-le avec nohup ou dans un tmux sur la VM elle-même, pas depuis Cloud Shell ; sinon le SIGHUP de la coupure tue le process.

Déploiement local d’apps PME. Pour une PME ivoirienne qui héberge un ERP Odoo, une VM N2-standard-4 (4 vCPU, 16 Go) en europe-west9 avec un Cloud SQL Postgres et un disque pd-balanced de 100 Go suffit pour une équipe de 30 personnes. Coût mensuel total typique : 120-160 USD soit ~ 75 000 à 100 000 FCFA, beaucoup moins qu’un serveur on-prem amorti sur 3 ans.

Tutoriels frères

• Cloud Storage : buckets, versioning, lifecycle, sécurité — où stocker les fichiers de l’app que tourne sur ces VMs.
• VPC GCP : subnets, firewall, Cloud NAT, peering — le réseau qui rend ces VMs accessibles.

Pour aller plus loin

• 🔝 Retour au pilier : Devenir Google Cloud Associate Cloud Engineer (ACE) — Guide complet 2026
• Doc Compute Engine : cloud.google.com/compute/docs
• Doc machine families : cloud.google.com/compute/docs/machine-resource
• Doc disques : cloud.google.com/compute/docs/disks
• Suggestion suivante : Cloud Storage — buckets, versioning, lifecycle

FAQ

E2 ou N2 pour un lab ACE ?
E2 sans hésiter pour le lab : machines partagées, suffisamment performantes pour Nginx, Postgres léger, Docker. Passez à N2 uniquement quand vous voulez tester des charges plus représentatives de la production.

Persistent Disk ou Hyperdisk pour une nouvelle VM ?
Si la machine series le supporte (C4, N4, X4 et au-delà), prendre Hyperdisk : performances configurables indépendamment de la taille, plus modernes. Pour les anciennes séries (E2, N1, N2, N2D), Persistent Disk reste obligatoire et fait très bien le travail.

Comment réduire la facture d’une VM toujours allumée ?
Trois leviers cumulables : sustained-use discount automatique, committed-use discount sur 1 ou 3 ans, ou Spot VM si la charge tolère les interruptions (jusqu’à 91 % de remise). Pour une VM lab non critique, Spot est imbattable.

OS Login ou clés SSH manuelles ?
OS Login systématiquement en 2026 : centralise la gestion des accès via IAM, permet de retirer un accès en supprimant le rôle plutôt qu’en mettant à jour les authorized_keys. C’est la bonne réponse à l’examen.

IAP TCP forwarding fonctionne-t-il pour SSH et RDP en même temps ?
Oui. IAP est un proxy générique qui forwarde du TCP arbitraire. Vous l’utiliserez pour SSH (port 22), RDP (3389), MySQL (3306), Postgres (5432) — tous les ports peuvent passer.

Combien de VMs puis-je créer pour préparer ACE ?
Quota Free Trial : 8 vCPU partagés sur certains régions par défaut. Pour 4 VMs e2-small simultanées (chacune 2 vCPU partagés), vous êtes dans les clous. Au-delà, demandez une augmentation de quota ; pour le lab ACE, ce ne sera jamais nécessaire.

Mots-clés : Compute Engine, VM GCP, e2-small, n2-standard, OS Login, IAP TCP forwarding, Persistent Disk, Hyperdisk, snapshot Compute Engine, ACE certification