Images, cloud-init et snapshots Scaleway : personnaliser et cloner vos Instances

Parcours en cours de construction

Ce parcours Scaleway est en cours de production. Les pages sortent par vagues ; certains volets sont encore en construction.

Une Instance n'a pas à être configurée à la main après chaque création. On part d'une image prête à l'emploi, on la personnalise au démarrage avec cloud-init, et on la sauvegarde ou la clone via des snapshots et des images custom. Ce guide, pour qui a déjà créé une Instance, vous fait maîtriser tout ce cycle avec scw : le catalogue du marketplace tel qu'il est aujourd'hui, le diagnostic d'un cloud-init qui « ne fait rien », ce que chaque état de l'Instance coûte, la différence entre snapshot, image et template, et surtout l'ordre de destruction, parce qu'une image verrouille son snapshot et qu'un snapshot oublié se facture indéfiniment.

Ce que vous allez apprendre

Niveau : débutant à intermédiaire. Prérequis : la CLI scw configurée et une clé SSH enregistrée.

À la fin de cette page, vous saurez :

• Choisir une image officielle ou une InstantApp dans le marketplace, et lire son label
• Personnaliser une Instance au boot avec cloud-init, et lire son journal en cas d'échec
• Gérer le cycle de vie (start, stop, reboot, standby) en sachant ce que chacun coûte
• Distinguer snapshot, image et Instance Template, et choisir l'outil selon le type de volume
• Exporter un snapshot vers Object Storage, et détruire dans l'ordre imposé

Voici le cycle complet, de l'image de base aux Instances préconfigurées.

Quelle image choisir dans le marketplace ?

Une image est le modèle à partir duquel démarre votre Instance : un système d'exploitation prêt à l'emploi, désigné par un label que vous passez à scw instance server create image=…. Scaleway maintient un marketplace d'images officielles :

scw marketplace image list

La sortie doit afficher une ligne par image avec son label. Relevé le 2026-09-08 avec scw 2.56.3 : 33 images, que l'on peut ranger en quatre familles. Le tableau se lit par la colonne Quand : elle dit quelle famille prendre.

Famille	Labels relevés	Quand
Distributions Linux	ubuntu_focal, ubuntu_jammy, ubuntu_noble, ubuntu_resolute, debian_bullseye, debian_bookworm, debian_trixie, almalinux_8 à _10, rockylinux_8 à _10, centos_stream_9, fedora_42 à _44, redhat_enterprise_linux_9 et _10	tout serveur classique ; prendre la version LTS la plus récente que vos outils supportent
Images GPU	ubuntu_jammy_gpu_os_12, ubuntu_noble_gpu_os_12, ubuntu_noble_gpu_os_13_nvidia	GPU Instances : pilotes NVIDIA et nvidia-docker préinstallés
Windows Server	windows_server_2022, windows_server_2025, et leurs variantes _core	licences facturées en plus, mot de passe admin chiffré par clé SSH IAM
InstantApps	docker, gitlab, nextcloud, openvpn, wordpress, kapsule, kapsule_noble	une application déjà installée, pour démarrer vite

Glissez pour voir

Un label est une référence : selon la zone et le type d'Instance, il pointe vers une image locale différente (scw marketplace local-image list image-label=ubuntu_noble les liste). C'est ce qui permet au même image=ubuntu_jammy de fonctionner dans les dix zones.

InstantApp : gagner du temps

Une InstantApp vous évite d'installer manuellement un logiciel courant : l'image docker, par exemple, vous livre une Instance avec Docker déjà en place. Idéal pour démarrer vite, à compléter ensuite par votre propre configuration. Une InstantApp reste une image : elle se personnalise par cloud-init comme les autres.

Comment personnaliser au démarrage avec cloud-init ?

cloud-init est l'outil standard de personnalisation au boot : il transforme une image générique en serveur configuré en quelques secondes, sans intervention manuelle. On lui fournit un fichier #cloud-config qui décrit ce qu'il faut faire au premier démarrage : écrire des fichiers, créer des utilisateurs, installer des paquets, lancer des commandes. D'autres formats existent (script shell commençant par #!, #include d'URL, archive MIME), mais le YAML #cloud-config couvre l'immense majorité des besoins.

1. Écrire un fichier cloud-init (cloudinit.yaml) :

   #cloud-config
   write_files:
     - path: /root/cloud-init-ok.txt
       content: "cette Instance a été configurée par cloud-init"
   runcmd:
     - [ sh, -c, "apt-get update && apt-get install -y nginx" ]

2. Créer l'Instance en fournissant ce fichier (@ charge son contenu) :

   scw instance server create image=ubuntu_jammy type=GP1-XS name=web \
     ip=new cloud-init=@cloudinit.yaml zone=fr-par-1 -w

   La sortie doit afficher l'Instance en running avec public_ip.address.

3. Vérifier en SSH que cloud-init a bien tourné :

   ssh root@VOTRE_IP "cat /root/cloud-init-ok.txt; systemctl is-active nginx; cloud-init status"

   La sortie doit afficher votre message, active, puis status: done. Vous venez de provisionner un serveur configuré sans y toucher à la main.

Quand cloud-init « ne fait rien », la réponse est presque toujours dans deux fichiers de l'Instance : /var/log/cloud-init-output.log (la sortie des commandes) et /var/log/cloud-init.log (le déroulé des modules). cloud-init status --long résume l'état ; une erreur d'indentation YAML ou un #cloud-config manquant en première ligne y apparaissent en clair.

IP flexible réutilisée : la clé d'hôte change

Scaleway recycle les IP publiques : votre nouvelle Instance peut hériter d'une IP déjà vue, mais avec une nouvelle clé d'hôte SSH. Votre client SSH refuse alors la connexion avec « REMOTE HOST IDENTIFICATION HAS CHANGED ». La parade : effacer l'ancienne empreinte avec ssh-keygen -R VOTRE_IP, puis reconnectez-vous.

Le cycle de vie d'une Instance : que coûte chaque état ?

Une Instance ne se résume pas à « créée » ou « supprimée » ; on la pilote au fil de son usage, et chaque état a sa facture (page « Understanding Instance states », validée le 2026-04-03).

# Power-off : archive le volume local et libère la machine physique
scw instance server stop VOTRE_ID
# Standby (veille) : l'Instance reste allouée, données locales conservées
scw instance server standby VOTRE_ID
# Rallumer, puis redémarrer
scw instance server start VOTRE_ID
scw instance server reboot VOTRE_ID
scw instance server get VOTRE_ID

La dernière commande doit afficher l'état courant dans le champ state. Le tableau se lit par la colonne Facturé :

Action	État obtenu	Ce qui se passe	Facturé
stop	stopped	le volume local est archivé vers un snapshot (ou conservé), l'hyperviseur libéré ; durée proportionnelle aux données	stockage + IP, plus de calcul
standby	stopped in place	l'Instance est halted mais reste allouée, données locales en place	comme une Instance allumée
reboot	running	redémarrage électrique, données locales conservées	calcul + stockage + IP
start	running	restauration du volume local archivé, démarrage	calcul + stockage + IP
mode rescue	running sur un système minimal	dépannage d'un système qui ne boote plus, accès à tous les disques	calcul + stockage + IP

Glissez pour voir

Ne confondez pas les deux façons d'arrêter, car elles n'ont pas le même effet sur la facture. La commande stop correspond au power-off : seuls les volumes et l'IP flexible restent alors facturés. Le standby garde l'Instance allouée : elle continue d'être facturée, calcul compris. Le standby ne sert qu'à un arrêt de quelques minutes où le temps d'archivage du volume local serait plus long que l'arrêt lui-même.

Snapshot, image ou template : lequel choisir ?

Trois objets permettent de sauvegarder, cloner ou standardiser, et ils ne répondent pas à la même question. Le tableau se lit par la colonne Choix.

Besoin	Choix	Pourquoi
Sauvegarder un volume avant une opération risquée	snapshot	copie d'un seul volume à un instant donné, facturée au Go-heure
Restaurer ou cloner une Instance entière, tous volumes compris	image	composée d'un snapshot par volume, sert de modèle à server create image=
Redéployer la même configuration (type, image, réseau, cloud-init) sans ressaisie	Instance Template	disponible depuis le 15 juillet 2026, immuable : on en crée un nouveau pour changer quoi que ce soit
Une flotte qui se répare et grandit seule	Autoscaling Group à partir d'un template	bêta publique depuis le 25 août 2026 (fr-par, nl-ams, pl-waw) : pas encore un choix de production
Déplacer un volume vers une autre zone ou un autre projet	snapshot exporté vers Object Storage	seul chemin entre zones, au format QCOW2

Glissez pour voir

Deux règles techniques structurent tout cela (FAQ Instances et concepts). Une image est composée de snapshots de volumes, et un snapshot ne se restaure que vers un volume du même type : un snapshot de volume local (l_ssd) redonne un volume local, un snapshot Block (sbs) redonne un volume Block. Et l'architecture doit être précisée à la création d'une image, parce qu'ARM et x86 n'ont pas le même jeu d'instructions.

Créer une image custom en ligne de commande

Le plus simple pour créer une image custom est la console (page de l'Instance, action « Créer une image »). En ligne de commande, la démarche se fait en deux temps, avec une subtilité selon le type de volume :

# 1) Snapshotter le volume racine (la syntaxe diffère selon le type de volume) :
#    Volume LOCAL (l_ssd) :   scw instance snapshot create volume-id=<id> name=base
#    Volume BLOCK (sbs)   :   scw block snapshot create <id> name=base
# 2) Construire l'image à partir du snapshot
scw instance image create name=mon-modele snapshot-id=VOTRE_SNAPSHOT_ID arch=x86_64
scw instance image list

La dernière commande doit afficher mon-modele avec son identifiant. Des volumes supplémentaires s'ajoutent à l'image avec additional-volumes.0.id=<snapshot> ; l'argument public=true la rend visible par d'autres comptes, ce qui ne se fait jamais par accident.

Le bon outil selon le volume

La commande scw instance snapshot ne fonctionne que sur les volumes locaux (l_ssd). Sur un volume Block (sbs), elle échoue avec « cannot find resource 'instance_volume' » : utilisez alors scw block snapshot. Attention aussi à la syntaxe : scw block snapshot create accepte l'identifiant en argument positionnel (scw block snapshot create <id>) ou sous la forme volume-id=, là où scw instance snapshot create n'accepte que volume-id=. Vérifiez le type du volume racine de votre Instance (scw instance server get, champ volumes) avant de choisir la commande.

Une fois l'image créée, vous démarrez de nouvelles Instances identiques avec scw instance server create image=VOTRE_IMAGE_ID : c'est la façon de cloner un serveur de référence.

Exporter un snapshot vers Object Storage

Un snapshot est zonal ; pour changer de zone ou de projet, on l'exporte au format QCOW2 vers un bucket de la même région, puis on l'importe ailleurs.

scw block snapshot export-to-object-storage zone=fr-par-1 snapshot-id=VOTRE_SNAPSHOT_ID \
  bucket=VOTRE_BUCKET key=base.qcow2
scw block snapshot import-from-object-storage name=base-par2 bucket=VOTRE_BUCKET \
  key=base.qcow2 size=20GB zone=fr-par-2

Après l'import, scw block snapshot list zone=fr-par-2 doit afficher base-par2. Pour un snapshot de volume local, la commande équivalente est scw instance snapshot export-to-object-storage ; l'import se fait avec scw instance snapshot create bucket= key= size= (la taille doit être un multiple de 512). C'est aussi ainsi qu'on convertit un ancien volume b_ssd en volume sbs.

Le cycle de vie des types d'Instances

Les types d'Instances ont eux aussi un cycle de vie, et il vaut mieux le connaître avant de bâtir une image sur une gamme en fin de carrière (page « Understanding Instances lifecycle », validée le 2026-03-12). Un type passe par Private Beta, Public Beta (sans SLA), General Availability (SLA standard), puis End of New Features, End of Growth (plus de nouveaux clients), End of Sales (plus aucune commande, les Instances existantes tournent) et End of Life (arrêt et migration automatique vers une offre équivalente). Scaleway prévient par e-mail et dans la console à l'entrée en End of Sales. Une image custom, elle, survit à ces transitions : elle se redéploie sur la gamme suivante.

Nettoyer

Cette leçon est la plus coûteuse du volet si vous l'arrêtez ici. Une Instance se remarque sur la facture ; une image custom et son snapshot, non. Ils occupent quelques gigaoctets, se facturent au stockage (0,000049 € par Go et par heure pour un snapshot sbs_5k, relevé du 2026-09-08), et rien dans la console ne vous rappellera leur existence dans six mois.

L'ordre compte, et il n'est pas celui qu'on devine : une image verrouille le snapshot dont elle est issue. Tenter de supprimer le snapshot en premier échoue.

1. Supprimez l'image custom, en premier donc

   scw instance image list
   scw instance image delete VOTRE_IMAGE_ID

2. Supprimez le snapshot, maintenant libéré

   Selon le type du volume d'origine, la commande n'est pas la même, comme vu plus haut :

   scw instance snapshot list
   scw instance snapshot delete VOTRE_SNAPSHOT_ID   # volume local (l_ssd)
   scw block snapshot list zone=fr-par-1
   scw block snapshot delete VOTRE_SNAPSHOT_ID zone=fr-par-1   # volume Block (sbs)

3. Supprimez l'Instance avec ses volumes et son IP

   Les deux options sont essentielles : sans elles, le volume et l'adresse survivent à la machine et continuent d'être facturés.

   scw instance server stop VOTRE_SERVER_ID -w
   scw instance server delete VOTRE_SERVER_ID with-volumes=all with-ip=true

4. Vérifiez le retour à zéro

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

   Les six listes doivent être vides. C'est le seul contrôle qui vaut : une commande de suppression qui s'est bien passée ne dit rien de ce qu'elle a laissé derrière elle.

Limites, quotas et plafonds

Ces valeurs viennent du marketplace, des FAQ, des pages de cycle de vie et de l'aide de la CLI ; elles disent ce qu'une image et un snapshot peuvent faire, et ce qu'ils coûtent.

Plafond	Valeur	Source
Images du marketplace	33 relevées le 2026-09-08, dont 7 InstantApps et 3 images GPU	scw marketplace image list
Volume système minimal	10 Go, 125 Go pour une image GPU	FAQ Instances
Restauration d'un snapshot	vers un volume du même type uniquement (local vers local, Block vers Block)	FAQ Instances, concepts
Architecture d'une image	à préciser : x86_64, arm, arm64	aide de scw instance image create
Prix d'un snapshot Block	0,000049 €/Go/h (sbs_5k), 0,000044 (sbs_15k), relevé du 2026-09-08	scw block volume-type list
Taille d'un snapshot importé	multiple de 512 octets	aide de scw instance snapshot create
Instance Template	immuable après création	changelog du 15 juillet 2026, concepts
Autoscaling Groups	bêta publique, fr-par, nl-ams, pl-waw	changelog du 25 août 2026
Standby	facturé comme une Instance allumée	FAQ Instances
Ordre de suppression	image, puis snapshot, puis Instance	établi en lab le 2026-07-18

Glissez pour voir

Antipatterns à éviter

Ces erreurs ont en commun de coûter au stockage, en silence, ou de rendre un serveur impossible à reproduire.

Antipattern	Conséquence	Discipline
Configurer le serveur en SSH après création	rien n'est rejouable, la deuxième Instance diffère de la première	tout dans #cloud-config, l'Instance ne se touche pas
Créer une image « au cas où » et l'oublier	image + snapshot facturés indéfiniment	nom daté, revue mensuelle des listes image et snapshot
Supprimer le snapshot avant l'image	refus, puis abandon avec les deux objets en place	image d'abord, snapshot ensuite
Mettre une Instance en standby « pour économiser »	facturée comme allumée	stop, qui archive et libère
Bâtir une image sur un type en End of Sales	impossible de recréer l'Instance sur ce type demain	vérifier le cycle de vie du type, viser la gamme courante
Rendre une image publique pour la partager avec un collègue	image visible de tous les comptes, avec ses secrets éventuels	image privée, partage par export QCOW2 vers un bucket du bon projet

Glissez pour voir

Images et snapshots sous l'angle Well-Architected

Operational Excellence : le serveur est un fichier

Pouvez-vous recréer ce serveur sans vous souvenir de ce que vous avez tapé ? Oui, si l'image du marketplace, le fichier cloud-init et la commande scw sont versionnés ensemble. La discipline est cloud-init pour tout ce qui se configure, une image custom seulement quand le temps d'installation le justifie, et depuis juillet 2026 un Instance Template pour figer l'ensemble.

Reliability : un snapshot est un point de retour daté

Que se passe-t-il si la mise à jour de ce soir casse tout ? On recrée un volume depuis le snapshot pris juste avant, si on l'a pris. La discipline est un snapshot nommé par sa date avant chaque changement, un test de restauration trimestriel, et un export vers Object Storage pour ce qui doit survivre à la zone.

Cost Optimization : le stockage dormant

Combien coûtent les images et snapshots que personne n'utilise ? scw instance image list, scw instance snapshot list et scw block snapshot list le disent en trois commandes. La discipline est une rétention écrite, et l'ordre image puis snapshot au moment de faire le ménage.

Pièges courants

Le tableau se lit par la colonne Symptôme : c'est ce que vous voyez à l'écran, message exact compris quand il y en a un ; la colonne Cause dit ce qui se passe réellement, et la colonne Solution la commande ou le geste qui débloque.

Symptôme	Cause	Solution
SSH : REMOTE HOST IDENTIFICATION HAS CHANGED	IP recyclée avec une nouvelle clé d'hôte	ssh-keygen -R VOTRE_IP puis reconnexion
cannot find resource 'instance_volume'	snapshot d'un volume Block via l'API Instance	utiliser scw block snapshot pour un volume sbs
cloud-init « ne fait rien »	fichier mal formé (indentation, #cloud-config manquant)	cloud-init status --long et /var/log/cloud-init-output.log sur l'Instance
Impossible de supprimer un snapshot	une image le référence encore	supprimer d'abord l'image (scw instance image delete), puis le snapshot
Image custom qui facture	image ou snapshot oublié	lister et supprimer (scw instance image list, snapshots)
L'image ne démarre pas sur le nouveau type	architecture différente (ARM contre x86), ou snapshot d'un autre type de volume	image par architecture, snapshot du bon type
Le stop prend de longues minutes	archivage du volume local proportionnel aux données	volume Block pour les données, local léger pour le système

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

• Une image est le modèle de démarrage ; le marketplace en compte 33 (distributions, images GPU, Windows, InstantApps), listées par scw marketplace image list.
• cloud-init (cloud-init=@fichier) configure l'Instance au boot ; cloud-init status --long et /var/log/cloud-init-output.log disent pourquoi il n'a rien fait.
• Attention à l'IP recyclée : clé d'hôte changée, corrigée par ssh-keygen -R.
• stop archive et cesse de facturer le calcul ; standby garde l'Instance allouée et facturée comme allumée.
• Un snapshot copie un volume et ne se restaure que vers le même type ; une image est un jeu de snapshots avec une architecture ; un Instance Template (depuis le 15 juillet 2026) fige toute la configuration et ne se modifie pas.
• Le type de volume décide de l'outil : scw instance snapshot (local) ou scw block snapshot (Block).
• Un snapshot change de zone par export-to-object-storage puis import-from-object-storage (QCOW2).
• Une image verrouille son snapshot : on supprime l'image d'abord, le snapshot ensuite ; un snapshot sbs_5k coûte 0,000049 €/Go/h tant qu'il existe.
• with-volumes=all et with-ip=true ne sont pas optionnels à la suppression d'une Instance.

Pour aller plus loin

• Lab fil rouge des Fondations : cloud-init, un volume attaché à la création et le teardown vérifié, dans un seul enchaînement.
• VPC et Private Networks : La prochaine chose que cloud-init n'a pas à faire, le réseau privé, géré par la plateforme.
• IAM : donner le droit minimal à une CI : L'identité qui exécutera vos scripts de création d'images, limitée à un seul projet.

Ressources externes

Les pages officielles sur lesquelles cette leçon s'appuie, avec ce qu'on y cherche ; leur champ de validation date chaque fait cité.

• Instances concepts : image, snapshot, Instance Template, standby, power-off, rescue mode.
• Understanding Instance states : les états et ce que chacun facture.
• Understanding Instances lifecycle : de la bêta privée à l'End of Life d'un type.
• Moving Instances between Availability Zones and Projects : export et import de snapshot en QCOW2.
• How to use cloud-init : la référence officielle du bootstrap au démarrage.

×

📖 Voir la documentation →