Packer sur Scaleway : construire une image, et vérifier ce qu'elle laisse

Un build Packer démarre une vraie machine, produit un snapshot puis une image, et trois objets lui survivent : l'image, le snapshot, et un volume orphelin que rien ne signale. C'est ce qui rend Packer différent de Terraform et d'Ansible dans ce volet : il coûte à chaque exécution, et il laisse quelque chose derrière lui, y compris quand il échoue. Cette leçon construit une image durcie avec le plugin officiel 1.5.0, puis s'attarde longuement sur la vérification de sortie, parce que c'est là que se joue la facture. Vous en repartirez avec un modèle épinglé et vérifié, une image démarrable, et surtout la liste des objets à contrôler après chaque build, y compris ceux qu'un build interrompu laisse invisibles.

Ce que vous allez apprendre

• Épingler le plugin et vérifier ce que vous installez.
• Construire une image durcie, avec un provisionneur minimal.
• Reconnaître ce qu'un build laisse derrière lui, réussi ou interrompu.
• Nettoyer dans l'ordre qu'imposent les dépendances.

Plugin ou provider : comment Packer nomme-t-il les choses ?

Chez Packer on dit plugin et builder, jamais provider. Le terme provider appartient à Terraform, et le confondre coûte une recherche documentaire infructueuse.

Terraform	Packer
un provider	un plugin, qui expose un ou plusieurs builders
required_providers	required_plugins
resource "scaleway_instance_server"	source "scaleway" "…"

Glissez pour voir

Comment épingler et vérifier le plugin Packer Scaleway ?

Le plugin officiel est en version 1.5.0, publiée le 17 juin 2026. Il se déclare dans le modèle, ce qui le rend reproductible.

packer {
  required_plugins {
    scaleway = {
      source  = "github.com/scaleway/scaleway"
      version = ">= 1.5.0"
    }
  }
}

packer init .
packer plugins installed

La seconde commande liste les plugins réellement présents, avec leur version. C'est la réponse à la question qui ouvre tout dépannage : ai-je bien ce que je crois avoir ?

Vérifier la signature, comme pour le CLI

Le plugin est distribué avec un fichier SHA256SUMS et sa signature PGP .sig. C'est le même geste que celui appris pour le CLI scw, et il vaut d'autant plus ici que ce binaire va construire les images sur lesquelles tourneront vos machines.

Une somme de contrôle non vérifiée ne prouve rien : c'est la signature de la liste de sommes qui atteste de son origine, et la somme qui atteste du binaire. Les deux, dans cet ordre.

`snapshot_name` a changé de place en 1.5.0

Le champ n'a pas disparu, il a changé de niveau. La 1.5.0 le retire de la racine du bloc source, où il était inerte depuis un correctif antérieur, et il reste valide dans les blocs de volume, root_volume {} et block_volume {}. Un modèle écrit pour une version antérieure et qui déclare snapshot_name à la racine échoue donc sur la 1.5.0, alors que le même champ dans un bloc de volume continue de fonctionner.

C'est le genre de rupture qui se découvre au premier build après une mise à jour, et qui explique pourquoi la contrainte de version se déclare plutôt qu'elle ne se subit. Si vous héritez d'un modèle qui ne construit plus, c'est la première chose à regarder.

À quoi ressemble un modèle Packer Scaleway minimal ?

Le builder démarre une Instance, exécute vos commandes, en fait un snapshot, puis une image. Chacune de ces étapes se voit dans la sortie et se facture.

source "scaleway" "socle" {
  zone            = "fr-par-1"
  commercial_type = "DEV1-S"
  image           = "ubuntu_jammy"
  ssh_username    = "root"

  # Nommer explicitement, la raison est expliquée plus bas.
  image_name  = "socle-{{timestamp}}"
  server_name = "packer-socle-{{timestamp}}"
  server_tags = ["packer", "socle"]
}

build {
  sources = ["source.scaleway.socle"]

  provisioner "shell" {
    inline = [
      "apt-get update -qq",
      "apt-get install -y --no-install-recommends ca-certificates curl",
      "apt-get clean && rm -rf /var/lib/apt/lists/*",
    ]
  }
}

time packer build socle.pkr.hcl

Chronométrez le premier build. C'est la mesure qui décidera plus tard si votre mise à l'échelle automatique a un sens : une image qui contient déjà l'application démarre en une minute là où une installation au démarrage en demande cinq.

Mesuré le 2026-09-14 avec Packer 1.15.0 et le plugin 1.5.0, sur ubuntu_jammy et une DEV1-S en fr-par-1 : le build complet a pris 1 minute 9 secondes, de Creating server... à Destroying server..., et s'est terminé par la ligne qui compte :

An image was created: 'socle-1789403110' (ID: 252766f7-f667-4c9c-ae96-2bffd9646447)
in zone 'fr-par-1' based on snapshots [(: 600475ff-a1e1-4593-b4fb-bc286b49a4cf)]

Retenez l'UUID entre parenthèses, pas le nom : scw instance image get refuse socle-1789403110 avec 'socle-1789403110' is not a valid UUID, et c'est cet identifiant qu'il faudra pour supprimer l'image.

Ce que le build consomme	Tarif	Sur quinze minutes
une Instance DEV1-S	environ 0,009 €/h	moins d'un centime
une adresse publique, exigée le temps du build	0,005 €/h	négligeable
le snapshot produit	au gigaoctet	tant qu'il existe
l'image produite	au gigaoctet	tant qu'elle existe
le volume racine du serveur temporaire, laissé orphelin	au gigaoctet	tant qu'il existe

Glissez pour voir

Le build coûte des centimes. Ce sont les trois objets qui lui survivent qui coûtent, et ils ne se rappellent jamais à votre souvenir.

Que reste-t-il après un build réussi ?

Trois objets, dont un que la sortie de Packer ne mentionne pas. Relevé le 2026-09-14, une minute après le An image was created, en relistant les quatre familles concernées :

scw instance image list zone=fr-par-1
scw instance snapshot list zone=fr-par-1
scw block snapshot list zone=fr-par-1
scw block volume list zone=fr-par-1

Famille	Ce qu'on y trouve	Nom relevé
instance image	l'image, avec le nom donné par image_name	socle-1789403110
instance snapshot	rien, la liste est vide	-
block snapshot	le snapshot du volume racine, 10 Go, nom généré	snp-kind-mccarthy
block volume	un volume orphelin, references=[], nommé d'après l'image source	Ubuntu 22.04 Jammy Jellyfish_sbs_volume_0

Glissez pour voir

Le serveur temporaire et son adresse ont bien disparu, scw instance server list et scw instance ip list reviennent vides. Mais le volume racine du serveur lui a survécu : le plugin en a pris un snapshot, a créé l'image, puis a détruit le serveur sans supprimer le volume, qui reste facturé au gigaoctet alors qu'aucune image ni aucun snapshot ne pointe vers lui. Un script de nettoyage écrit d'après la famille historique instance snapshot conclut que tout est propre, et laisse deux objets sur trois.

Le point le plus utile de cette leçon

Un build qui échoue laisse le même volume facturé, et rien ne le signale, pas même une image. Après un build réussi, l'image et le snapshot rappellent au moins qu'un build a eu lieu ; après un échec, il ne reste que le volume. Mesuré le 2026-09-14 avec le plugin 1.5.0 et Packer 1.15.0.

Provoquez-le, c'est la seule façon de retenir le réflexe.

1. Faites échouer le provisionnement volontairement

   provisioner "shell" {
     inline = ["exit 1"]
   }

   packer build socle.pkr.hcl

   Packer détruit le serveur, et la sortie se termine sur une erreur nette :

   ==> scaleway.socle: Provisioning step had errors: Running the cleanup provisioner, if present...
   ==> scaleway.socle: Destroying server...
   Build 'scaleway.socle' errored after 24 seconds 552 milliseconds: Script exited with non-zero exit status: 1. Allowed exit codes are: [0]
   ==> Builds finished but no artifacts were created.

   Vingt-quatre secondes, code de retour 1, « no artifacts were created » : tout semble propre.

2. Regardez ce qui reste

   scw instance server list zone=fr-par-1
   scw block volume list zone=fr-par-1

   Dans les secondes qui suivent, le serveur packer-socle-echec-… peut encore apparaître, en cours de suppression, avec son volume marqué references=1. Quelques instants plus tard, la première liste est vide et la seconde ne l'est pas : le volume racine, Ubuntu 22.04 Jammy Jellyfish_sbs_volume_0, est orphelin, references=[], et ses 10 Go se facturent. Aucune image, aucun snapshot ne le signale : c'est le reste le plus discret de tout ce volet.

3. Supprimez ce qui traîne

   scw block volume delete volume-id=VOTRE_VOLUME_ID zone=fr-par-1

   La sortie doit afficher Volume has been successfully deleted.

4. Retenez la règle plutôt que le cas

   On reliste après chaque build, pas seulement après ceux qui échouent. Un Ctrl+C pendant le provisionnement produit exactement le même reste.

Et le nettoyage par préfixe ne vous sauvera pas

Le réflexe naturel est d'écrire un script de nettoyage qui supprime tout ce qui commence par packer-. Il laissera des restes, parce que les noms ne suivent aucune convention unique. Relevé le 2026-09-14 sur un seul build :

Objet	Nom relevé	D'où il vient
image	socle-1789403110	celui que vous donnez dans image_name
snapshot du volume racine	snp-kind-mccarthy	généré, différent à chaque build
volume racine orphelin	Ubuntu 22.04 Jammy Jellyfish_sbs_volume_0	le nom de l'image source, pas le vôtre
serveur temporaire	packer-socle-1789403110	celui que vous donnez dans server_name, le seul à porter packer-

Glissez pour voir

Quatre noms pour un seul build, et le seul qui porte le préfixe qu'on filtrerait est celui qui a déjà disparu. La parade tient en deux gestes : nommer explicitement ce que le modèle crée, avec image_name, server_name et server_tags, puis relister par famille plutôt que filtrer sur un préfixe.

Deux limites à connaître

Une adresse publique est exigée. Le builder joint la machine temporaire par une adresse publique, Using SSH communicator to connect: 203.0.113.20 dans la sortie du build, et le cas « construire depuis un réseau privé, sans exposition Internet » n'est pas couvert aujourd'hui, sans échéance annoncée. L'adresse est libérée à la fin du build, scw instance ip list revient vide, mais le temps du build elle se facture et le trafic passe par Internet.

cloud-init passe par user_data, et il n'y a pas de raccourci. Le builder expose bien un argument user_data, une table de clés, et la clé réservée cloud-init y reçoit votre configuration. Ce qui manque est le confort :

user_data = {
  cloud-init = file("cloud-init.yaml")
}

Ce qui manque côté plugin est un argument dédié du type user_data_file et un exemple documenté, pas le support lui-même. Ne concluez donc pas que cloud-init est hors de portée du builder : il fonctionne, il se déclare simplement par cette porte.

La question mérite d'être posée dans le bon ordre, parce qu'elle recoupe ce que vous avez appris au volet Fondations : cloud-init personnalise une machine au démarrage, Packer personnalise l'image dont elle démarre. Ce qui doit valoir pour toutes les machines va dans l'image ; ce qui dépend de la machine, son nom, ses clés, son rôle, reste dans cloud-init.

Dans quel ordre supprimer une image et son snapshot ?

L'ordre n'est pas libre : une image verrouille le snapshot dont elle est issue. Tenter de supprimer le snapshot en premier échoue, relevé le 2026-09-14, et c'est le même piège qu'en ligne de commande :

scaleway-sdk-go: precondition failed: , Snapshot is currently in use, deletion is not permitted.

1. L'image d'abord

   scw instance image list zone=fr-par-1
   scw instance image delete VOTRE_IMAGE_ID zone=fr-par-1

   La sortie doit afficher Image has been successfully deleted. L'identifiant est l'UUID de la ligne An image was created, pas le nom.

2. Le snapshot ensuite, avec la bonne commande

   Le choix dépend du type du volume d'origine, exactement comme au volet Fondations. Sur ubuntu_jammy et une DEV1-S, le volume racine est un volume Block : scw instance snapshot list renvoie une liste vide, et le snapshot vit dans block snapshot.

   scw instance snapshot list zone=fr-par-1
   scw instance snapshot delete VOTRE_SNAPSHOT_ID zone=fr-par-1
   
   scw block snapshot list zone=fr-par-1
   scw block snapshot delete snapshot-id=VOTRE_SNAPSHOT_ID zone=fr-par-1

   La sortie doit afficher Snapshot has been successfully deleted.

3. Les restes du build, s'il en subsiste

   scw instance server list zone=fr-par-1
   scw block volume list zone=fr-par-1
   scw instance ip list zone=fr-par-1

4. La vérification de sortie

   Six listes, et six doivent correspondre à ce que vous attendez :

   scw instance image list
   scw instance snapshot list zone=fr-par-1
   scw block snapshot list zone=fr-par-1
   scw block volume list zone=fr-par-1
   scw instance ip list zone=fr-par-1
   scw instance server list zone=fr-par-1

Gardez l'image si elle vous sert, et gardez alors son snapshot avec elle : tant que l'image existe, l'API refuse de supprimer le snapshot dont elle est issue, c'est le message relevé plus haut. Le volume orphelin, lui, se supprime tout de suite et dans tous les cas : rien n'en dépend, et rien ne le signale.

Image dorée ou cloud-init : que faut-il figer dans l'image ?

Tout ce qu'on met dans l'image se paie au stockage et se refait à chaque mise à jour ; tout ce qu'on laisse à cloud-init s'exécute à chaque démarrage et ralentit la mise à disposition. L'arbitrage se fait donc sur la fréquence de changement, pas sur la commodité. Le tableau ci-dessous se lit par la colonne de gauche : partez de ce que vous voulez installer, et regardez à quelle vitesse cet élément change dans votre contexte.

Besoin	Choix	Pourquoi
Durcissement système, agents de supervision, dépôts internes	dans l'image, avec Packer	change rarement, et doit être identique sur toute la flotte dès le premier démarrage
Version applicative, artefact de livraison	dans l'image, une image par version	rend le déploiement reproductible, et le retour arrière possible en repointant l'image précédente
Clés d'hôte SSH, identifiants, secrets	jamais dans l'image	l'image se duplique, le secret aussi ; il arrive au démarrage ou par un coffre
Configuration propre à l'environnement, nom d'hôte, adresses	cloud-init, au démarrage	ces valeurs diffèrent par machine, les figer imposerait une image par environnement
Correctif de sécurité urgent sur une flotte en production	Ansible tout de suite, puis Packer	reconstruire et redéployer prend plus longtemps que la fenêtre d'exposition

Glissez pour voir

Limites, quotas et plafonds

Ce qui vous arrêtera n'est pas le nombre d'images, c'est leur poids cumulé. Les valeurs ci-dessous viennent de la page officielle des quotas d'Organisation de Scaleway, dont la date de validation est le 29 octobre 2025. Elles expliquent pourquoi un build qui laisse des restes ne pose aucun problème pendant des semaines, puis bloque brutalement.

Plafond	Sans vérification d'identité	Avec vérification
Snapshots	99 999	99 999
Images	99 999	99 999
Volumes	200	5 000
Stockage Block total	500 Go	5 000 Go
Stockage local total	1 000 Go	5 000 Go

Glissez pour voir

L'asymétrie entre ces lignes est le vrai enseignement. Le nombre de snapshots et d'images est si haut qu'on peut le considérer comme non contraignant, mais le volume total est plafonné à 500 Go tant que l'identité du compte n'est pas vérifiée. Une image de système durci pèse couramment une dizaine de gigaoctets, et un build en laisse potentiellement deux, l'image et son snapshot. À raison de quelques builds par semaine sans ménage, le plafond de stockage est atteint en un ou deux mois, et le message d'erreur porte alors sur le quota, pas sur l'oubli qui l'a rempli. Personne ne fait le lien avec les builds interrompus des semaines précédentes.

Deux autres limites viennent du plugin lui-même. Un build exige une adresse publique sur le serveur temporaire : construire depuis un réseau privé sans exposition Internet n'est pas possible aujourd'hui, et aucune échéance n'est annoncée. Et cloud-init passe par user_data sans raccourci : le passage fonctionne, c'est l'argument dédié et l'exemple officiel qui manquent.

Antipatterns à éviter

Ces erreurs ont en commun de rendre l'image non reproductible ou non traçable, c'est-à-dire de lui retirer la seule chose qui justifiait de la construire. Une image dont on ne sait ni ce qu'elle contient ni comment la refaire est plus dangereuse qu'une installation manuelle, parce qu'elle se duplique.

Antipattern	Conséquence	Discipline
Contrainte de plugin flottante (>= 1.5.0)	une publication amont déplace une option et casse le modèle sans commit de votre côté, comme snapshot_name sorti de la racine du bloc source en 1.5.0	épingler la version exacte dans required_plugins
Secrets ou clés d'hôte SSH cuits dans l'image	chaque machine née de cette image partage le même secret, et le révoquer impose de tout reconstruire	secrets au démarrage, jamais à la construction
Reconstruire une image à chaque déploiement	le stockage s'accumule contre le plafond de 500 Go, et le temps de build s'ajoute à chaque livraison	une image par version applicative
Ne pas vérifier après un build échoué	le volume racine reste orphelin et facturé, sans image ni snapshot pour le signaler	vérification de sortie systématique, y compris et surtout après un échec
Supprimer le snapshot avant l'image	l'API refuse, l'image verrouille son snapshot	supprimer l'image d'abord, le snapshot ensuite

Glissez pour voir

Packer sous l'angle Well-Architected

Une image est un livrable, avec les mêmes exigences qu'un binaire. Les trois piliers ci-dessous posent la question qu'un auditeur poserait, et la discipline qui y répond.

Excellence opérationnelle

Question clé : sauriez-vous refaire à l'identique l'image qui tourne aujourd'hui en production ? Si le modèle n'est pas versionné, ou si le plugin n'est pas épinglé, la réponse est non, et l'image devient un artefact irremplaçable au lieu d'un livrable reproductible.

Discipline : versionner le modèle avec le code applicatif, épingler le plugin à la version exacte, et étiqueter chaque image avec la référence du commit qui l'a produite.

Sécurité

Question clé : que contient cette image que vous n'y avez pas mis ? Le plugin est distribué avec un fichier SHA256SUMS et sa signature PGP : ne pas les vérifier revient à exécuter du code non authentifié sur la machine qui fabrique vos images de production.

Discipline : vérifier la signature avant l'installation, ne jamais cuire de secret dans l'image, et régénérer les clés d'hôte SSH au premier démarrage plutôt que de les hériter du modèle.

Optimisation des coûts

Question clé : combien vous coûtent les builds du trimestre, ratés ou non ? Un build réussi laisse un volume Block orphelin à côté de l'image et du snapshot ; un build interrompu laisse le même volume, sans image ni snapshot pour le signaler. Mesuré le 2026-09-14 avec le plugin 1.5.0 : 10 Go par build, dans les deux cas.

Discipline : contrôler les volumes après chaque build, y compris et surtout après un échec, supprimer les images de version obsolète, et surveiller le stockage cumulé plutôt que le nombre d'objets.

Pièges courants

Symptôme	Cause	Solution
Un modèle qui construisait ne construit plus	snapshot_name retiré de la racine du bloc source en 1.5.0	le déplacer dans root_volume {} ou block_volume {}, où il reste valide
Un volume facturé après un build, réussi ou échoué	le plugin ne supprime pas le volume racine du serveur temporaire, mesuré avec la 1.5.0	relister scw block volume list après chaque build
Un nettoyage par préfixe laisse des objets	quatre noms pour un build, un seul avec le préfixe packer-	nommer explicitement, puis relister par famille
'socle-…' is not a valid UUID	scw instance image get et delete attendent l'identifiant, pas le nom	reprendre l'UUID de la ligne An image was created
packer build refuse de démarrer sans adresse	une adresse publique est exigée	limite actuelle, prévoir l'adresse et son coût
Snapshot is currently in use, deletion is not permitted.	une image le verrouille	supprimer l'image d'abord
cannot find resource 'instance_volume'	snapshot d'un volume Block par l'API Instance	utiliser scw block snapshot
Recherche documentaire infructueuse	« provider Packer » n'existe pas	chercher plugin et builder

Glissez pour voir

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

À retenir

• Packer coûte à chaque exécution, contrairement à Terraform et Ansible : une Instance, une adresse, un snapshot et une image.
• Trois objets survivent à un build réussi : l'image, un snapshot Block au nom généré, et un volume racine orphelin de 10 Go au nom de l'image source, mesuré le 2026-09-14.
• Un build interrompu laisse le même volume orphelin, sans image ni snapshot pour le signaler : on reliste après chaque build, réussi ou non.
• Le nettoyage par préfixe ne fonctionne pas : sur un seul build, seul le serveur temporaire, déjà détruit, porte le préfixe packer-.
• Une image verrouille son snapshot : Snapshot is currently in use, deletion is not permitted. On supprime l'image d'abord, par son UUID.
• snapshot_name a quitté la racine du bloc source en 1.5.0 : il reste valide dans root_volume {} et block_volume {}.
• Une adresse publique est exigée pour joindre la machine temporaire ; construire en réseau privé n'est pas couvert.
• L'image porte ce qui vaut pour toutes les machines, cloud-init ce qui dépend de chacune.
• Vérifiez la signature du plugin : c'est lui qui fabrique les images de vos machines.

Pour aller plus loin

• Lab fil rouge IaC : Packer construit, Terraform provisionne, Ansible vérifie : l'image que vous venez de construire y devient une Instance, et vous y mesurez ce que terraform destroy ne supprime pas.

Ressources externes

• Formation Packer complète : HCL2, variables, provisionneurs et post-processeurs, applicables à toute plateforme au-delà de Scaleway.

• Dépôt scaleway/packer-plugin-scaleway : les notes de version, où se lisent les options déplacées ou retirées avant qu'elles ne cassent un modèle.

• Documentation du plugin Packer Scaleway : la référence des arguments du builder, version par version.

• Quotas d'Organisation Scaleway : les plafonds de stockage cités ici, à vérifier pour votre propre compte.

×

📖 Voir la documentation →