Lab fil rouge des Fondations : déployer une petite stack Scaleway de A à Z

Parcours en cours de construction

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

C'est le moment de tout relier. Ce lab de synthèse réutilise tout ce que vous avez appris dans le volet Fondations : vous isolez un environnement dans un projet, posez une alerte budget, provisionnez une Instance personnalisée par cloud-init, lui attachez un volume Block que vous montez, sauvegardez des données vers Object Storage et vérifiez que la restauration fonctionne, puis vous détruisez tout dans l'ordre que les dépendances imposent. À la fin, vous aurez déployé et démonté une petite stack complète, lu son coût réel dans la consommation du mois, et vous saurez quel objet bloque la suppression de quel autre.

Ce que vous allez faire

Niveau : débutant à intermédiaire. Prérequis : avoir suivi les leçons Fondations, la CLI scw configurée, une clé SSH enregistrée, et rclone installé.

Le déploiement cible tient en un schéma : une Instance configurée au boot, un volume Block attaché pour les données, et un bucket Object Storage pour les sauvegardes, le tout dans un projet dédié sous alerte budget.

Que va coûter ce lab, et pendant combien de temps ?

Ce lab coûte quelques centimes s'il est détruit dans l'heure, et la facturation minimale d'une heure par ressource fait que la vitesse n'y change rien. La FAQ facturation (validée le 2025-09-09) fixe la règle : chaque ressource est facturée pour un minimum de 60 minutes, Instance, Flexible IP, volume et snapshot compris. Autrement dit, que vous mettiez 20 ou 55 minutes, vous paierez une heure de chaque brique. Le tableau ci-dessous se lit comme un devis : la colonne Compteur dit ce qui démarre le compteur, et c'est aussi ce qui l'arrête.

Brique	Compteur	Ordre de grandeur pour une heure (relevé du 2026-09-08, scw 2.56.3)
Instance GP1-XS	démarrage à arrêt (power off)	0,0928 €
Flexible IPv4	réservation à libération, même détachée	environ 0,005 €
Volume Block sbs_5k de 10 Go	création à suppression	10 × 0,00013 € = 0,0013 €
Volume local racine (l_ssd) de l'Instance	création à suppression	inclus dans le type ou facturé au Go-heure selon le type
Bucket Object Storage, quelques Ko	stockage, egress au-delà de 75 Go par mois	0 € à cette échelle
Projet, alerte budget	rien	0 €

Glissez pour voir

Le coût de ce lab n'est pas dans le tableau, il est dans ce qu'on oublie. Une Flexible IP détenue coûte environ 3,65 € par mois, un volume de 10 Go environ 0,95 €, indéfiniment. Un bucket de quelques kilooctets ne coûte rien, mais un bucket versionné qu'on croit vide garde ses versions et refuse d'être supprimé. Un projet qui contient encore une seule de ces ressources refuse lui aussi de disparaître, et c'est une chance : c'est le signal qu'il reste quelque chose à payer. C'est pourquoi l'étape de destruction est la plus longue de cette page, pourquoi elle reliste cinq familles de ressources, et pourquoi elle se termine par une lecture de la consommation, seule preuve que rien ne tourne.

Étape 1 : comment isoler le lab et border le budget ?

On commence par cloisonner : un projet dédié évite de mélanger ce lab avec vos autres ressources et permet de tout retrouver au moment de nettoyer. L'alerte budget est le filet posé avant le premier saut.

1. Créer un projet pour le lab :

   scw account project create name=lab-fil-rouge description="Capstone Fondations"

   La sortie doit afficher un objet avec un champ id : c'est le Project ID, différent de celui de l'Organisation puisque ce projet n'est pas le projet par défaut.

2. Cibler ce projet pour la session (avec l'ID renvoyé) :

   scw config set default-project-id=VOTRE_PROJECT_ID
   scw config get default-project-id

   La seconde commande doit renvoyer exactement l'identifiant que vous venez de passer.

3. Poser une alerte de budget depuis la console (Facturation, onglet Consommation, Alertes de facturation), par exemple 5 € avec un seuil à 80 %. Si votre CLI est en version 2.58.3 ou plus récente, la même chose se fait en ligne de commande avec scw billing budget create puis scw billing budget-alert create ; la leçon Facturation détaille les deux voies et l'écart de version.

Étape 2 : préparer le stockage de données

Notre Instance aura un disque de données séparé du système : un volume Block, qu'on pourra snapshotter, redimensionner et détacher indépendamment. Créer le volume avant l'Instance permet de l'attacher dès la création, en une seule commande.

Avant de créer, la question « où vont les données ? » se tranche une fois ; le tableau se lit par la colonne Choix.

Besoin	Choix	Pourquoi
Le système et les paquets	volume local ou Block de démarrage, fourni avec l'Instance	recréable depuis l'image, rien à sauvegarder
Les données de l'application	volume Block attaché (fil-rouge-data)	survit à l'Instance, se snapshotte, s'agrandit, se rattache ailleurs dans la zone
La sauvegarde hors machine	bucket Object Storage	découplé de toute machine, régional, restaurable de partout
Des fichiers partagés en écriture par plusieurs Instances	File Storage, hors du périmètre de ce lab	disponibilité générale depuis le 16 juillet 2026

Glissez pour voir

scw block volume create name=fil-rouge-data perf-iops=5000 from-empty.size=10GB zone=fr-par-1
scw block volume list zone=fr-par-1

La liste doit afficher fil-rouge-data, type sbs_5k, statut available. Notez l'ID du volume : on l'attache à l'Instance à l'étape suivante. Rappel de la leçon Block Storage : l'unité est obligatoire (10GB), et un volume se facture dès cet instant, attaché ou non.

Étape 3 : provisionner l'Instance avec cloud-init et le volume attaché

On crée l'Instance en une commande : image, cloud-init pour la configurer au boot, et additional-volumes.0 pour lui attacher le volume Block dès la création. Le volume apparaît alors dans l'Instance comme un disque vierge, que l'on formate et monte comme sur n'importe quel serveur Linux.

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

   #cloud-config
   write_files:
     - path: /root/fil-rouge-ok.txt
       content: "Instance provisionnée et configurée par cloud-init"

2. Créer l'Instance avec le volume attaché :

   scw instance server create image=ubuntu_jammy type=GP1-XS name=fil-rouge \
     ip=new cloud-init=@cloudinit.yaml additional-volumes.0=VOTRE_VOLUME_ID \
     zone=fr-par-1 -w

   La sortie doit afficher l'Instance à l'état running, avec public_ip.address renseignée. C'est cette adresse qu'on utilise ensuite.

3. Se connecter et vérifier que cloud-init a tourné et que le volume est bien attaché :

   ssh root@VOTRE_IP "cat /root/fil-rouge-ok.txt; lsblk -d -o NAME,SIZE"

   Vous devez voir votre message, puis deux disques : sda (le système) et sdb (le volume Block de 10 Go). Si le marqueur est absent, lisez /var/log/cloud-init-output.log sur l'Instance : c'est là que cloud-init consigne ses erreurs.

4. Formater et monter le disque de données, avec un label et l'option nofail :

   ssh root@VOTRE_IP "mkfs.ext4 -L data /dev/sdb && mkdir -p /mnt/data && mount /dev/sdb /mnt/data \
     && echo 'LABEL=data /mnt/data ext4 defaults,nofail 0 2' >> /etc/fstab \
     && date > /mnt/data/premiere-donnee.txt && df -h /mnt/data"

   La dernière ligne de sortie doit montrer /mnt/data monté avec environ 10 Go. Deux détails comptent : nofail dans /etc/fstab évite que l'Instance reste bloquée au démarrage si le volume est un jour détaché, et le montage par label (LABEL=data) plutôt que par /dev/sdb résiste à un changement de lettre de périphérique.

La prochaine fois, dans cloud-init

Les commandes de l'étape 4 sont exactement celles qu'un bloc runcmd de cloud-init peut exécuter au premier démarrage. Un serveur configuré par cloud-init est reproductible : le même fichier produit le même serveur demain, dans une autre zone, ou vingt fois pour une flotte. Un serveur configuré en SSH ne l'est pas. C'est le réflexe que cette formation cherche à installer avant Terraform ; ce lab garde l'étape en SSH pour que vous voyiez le disque avant et après.

Étape 4 : sauvegarder vers Object Storage, et prouver la restauration

Nos données méritent une sauvegarde hors de l'Instance, et une sauvegarde ne vaut que si l'on a vérifié qu'on sait la restaurer. On crée un bucket, on y envoie le contenu de /mnt/data, puis on le récupère ailleurs pour comparer.

1. Créer un bucket (nom unique, sans point) :

   scw object bucket create fil-rouge-sauvegardes-42 region=fr-par
   scw object bucket list

   La liste doit afficher le bucket dans la région fr-par.

2. Générer la config rclone sur votre poste et envoyer la sauvegarde depuis l'Instance vers le bucket :

   scw object config install type=rclone name=cap region=fr-par
   ssh root@VOTRE_IP "tar czf /root/data-backup.tgz -C /mnt/data ."
   scp root@VOTRE_IP:/root/data-backup.tgz ./
   rclone copy data-backup.tgz cap:fil-rouge-sauvegardes-42/backups/
   rclone ls cap:fil-rouge-sauvegardes-42/

   Votre archive apparaît sous backups/ avec sa taille. La boucle calcul, stockage, sauvegarde est bouclée.

3. Restaurer dans un répertoire vide et comparer :

   mkdir -p restore && rclone copy cap:fil-rouge-sauvegardes-42/backups/data-backup.tgz restore/
   tar tzf restore/data-backup.tgz

   La sortie doit lister ./premiere-donnee.txt. Sans cette étape, vous avez un fichier dans un bucket ; avec elle, vous avez une sauvegarde.

Ce lab envoie l'archive par votre poste pour rester lisible. En exploitation, rclone s'installe sur l'Instance et pousse directement vers le bucket, avec une clé API dédiée à la sauvegarde et limitée à l'Object Storage : c'est l'objet du volet Sécurité.

Étape 5 : dans quel ordre tout détruire, et comment le vérifier ?

C'est l'étape qui protège votre facture, et elle est aussi importante que le déploiement. L'ordre n'est pas libre : le tableau ci-dessous dit quel objet en bloque un autre, et c'est lui qui dicte la séquence. Il se lit de haut en bas.

Objet à supprimer	Ce qui le bloque	Ce qu'il emporte si on lui demande
Objets du bucket	rien	rien
Bucket	ses objets : BucketNotEmpty tant qu'il n'est pas vide	rien
Instance	son état running : should be powered off sans -w sur le stop ou sans force-shutdown=true	ses volumes avec with-volumes=all, sa Flexible IP avec with-ip=true
Volume Block	son attachement à une Instance en marche	rien
Flexible IP	rien, elle survit à l'Instance sauf with-ip=true	rien
Projet	toute ressource restante	rien

Glissez pour voir

1. Vider et supprimer le bucket :

   rclone delete cap:fil-rouge-sauvegardes-42/
   scw object bucket delete fil-rouge-sauvegardes-42 region=fr-par
   scw object bucket list

   La liste ne doit plus contenir le bucket. Un BucketNotEmpty signifie que rclone delete n'a pas tout retiré, par exemple des versions si le versioning était activé.

2. Détruire l'Instance, ses volumes et son IP (with-volumes=all emporte aussi le volume Block attaché, with-ip=true libère l'adresse) :

   scw instance server stop VOTRE_SERVER_ID zone=fr-par-1 -w
   scw instance server delete VOTRE_SERVER_ID zone=fr-par-1 with-volumes=all with-ip=true

   L'argument with-volumes accepte none, local, block, root ou all (aide de scw instance server delete -h, 2.56.3). Sans lui, le volume Block survit à l'Instance ; sans with-ip=true, l'adresse aussi.

3. Vérifier le retour à zéro, famille par famille :

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

   Les cinq 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.

4. Supprimer le projet de lab, désormais sans ressource, et revenir au projet par défaut :

   scw account project delete project-id=VOTRE_PROJECT_ID
   scw config set default-project-id=VOTRE_ID_DE_PROJET_PAR_DEFAUT

   Un projet ne se supprime que vide ; si la commande est refusée, l'une des cinq listes ci-dessus n'était pas vide.

La vérification n'est pas optionnelle

Un déploiement qui touche à plusieurs services laisse facilement une traînée : une IP flexible, un volume, un bucket. Chacun facture en silence, et chacun a sa propre commande de liste. Le réflexe de fin de lab, c'est de relister chaque famille de ressources et de confirmer le zéro. C'est ce qui distingue une pratique maîtrisée d'une facture surprise.

Étape 6 : combien ce lab a-t-il coûté ?

Le dernier geste du lab est de lire la consommation, parce que c'est la seule preuve qui compte. La commande suivante affiche la consommation du mois, produit par produit, avec l'unité de facturation de chacun :

scw billing consumption list -o json \
  | python3 -c 'import sys,json; [print(round(x["value"]["units"]+x["value"]["nanos"]/1e9,2), "EUR |", x["product_name"], "|", x["billed_quantity"], x["unit"]) for x in json.load(sys.stdin)]'

Relevé le 2026-09-08 sur l'organisation de test de cette formation, après plusieurs labs dans le mois : 3,04 € répartis sur 13 lignes, dont Block Storage Volume facturé en gigabyte_hour, Zonal Flexible IP en ip_minute, DEV1-S en minute et VPC Public Gateway S en minute. Deux enseignements se lisent dans cette sortie. D'abord, l'unité dit ce qui coûte : un volume se paie au gigaoctet-heure, donc à la taille, pas à l'usage. Ensuite, la ligne Zonal Flexible IP apparaît même si aucune Instance ne tourne : c'est la trace d'une adresse détenue, la brique qu'on oublie le plus.

Ce que ce lab a prouvé

En un seul enchaînement, vous avez réutilisé tout le volet Fondations, et vérifié six choses que la plupart des lecteurs supposent sans les avoir vues.

• Organisations et Projets : un projet dédié isole les ressources et refuse de disparaître tant qu'il en contient une.
• Facturation et budget : chaque brique a son compteur et son unité, lisibles dans scw billing consumption list, et l'alerte prévient sans bloquer.
• Instances et cloud-init : un serveur se provisionne et se configure au démarrage, disque de données compris, sans une seule commande en SSH.
• Block Storage : additional-volumes.0=<id> attache un volume existant à la création ; il apparaît en /dev/sdb ; il survit à l'Instance sauf with-volumes=all.
• Object Storage : un bucket reçoit une archive et la rend ; la restauration a été testée, pas supposée.
• Discipline de coûts : cinq listes vides, puis une lecture de consommation qui confirme.

Limites, quotas et plafonds

Ces valeurs bornent ce lab sur un compte neuf ; elles viennent de la page des quotas d'Organisation (validée le 2025-10-29), des FAQ et des leçons du volet.

Plafond	Valeur	Source
Quota GP1-XS	1 avant vérification d'identité, 4 après : une seule Instance de ce type sur un compte non vérifié	quotas d'Organisation
Facturation minimale par ressource	60 minutes	FAQ facturation
Volumes Block par Instance	15 en plus du volume de démarrage	FAQ Block Storage
Taille minimale du volume système	10 Go	FAQ Instances
Adresses IP d'Instances	20 avant vérification, 50 après	quotas d'Organisation
Projets par Organisation	25	quotas d'Organisation
Nom de bucket	63 caractères, unique sur toute la plateforme, sans point	FAQ Object Storage
Consommation du mois sur l'organisation de test	3,04 € sur 13 lignes, relevé du 2026-09-08	scw billing consumption list

Glissez pour voir

Antipatterns à éviter

Ces erreurs sont celles qu'on commet précisément parce que le lab a bien marché : la confiance fait sauter une étape.

Antipattern	Conséquence	Discipline
Supprimer l'Instance sans with-volumes=all ni with-ip=true	volume et adresse facturés indéfiniment	les deux options à chaque suppression, puis les listes
Considérer l'archive envoyée comme une sauvegarde	restauration jamais testée, découverte le jour de la perte	restaurer dans un répertoire vide et comparer, à chaque lab
Monter le volume à la main en SSH	serveur non reproductible, geste oublié à la prochaine création	formater et monter dans cloud-init, nofail et montage par label
Utiliser sa clé API personnelle sur l'Instance pour pousser la sauvegarde	la machine porte tous vos droits	clé dédiée, limitée à l'Object Storage (volet Sécurité)
Vérifier la facture seulement en fin de mois	trente jours de Flexible IP ou de volume oubliés	scw billing consumption list en fin de session
Chercher à finir en moins d'une heure pour payer moins	aucun gain : facturation minimale de 60 minutes par ressource	prendre le temps de vérifier, le coût est identique

Glissez pour voir

Le lab fil rouge sous l'angle Well-Architected

Operational Excellence : tout ce qui a été fait peut être refait

Pourriez-vous rejouer ce déploiement demain, dans une autre zone, sans relire la page ? Oui, si tout tient dans deux fichiers : le cloud-init et un script qui enchaîne les commandes scw. La discipline est de ne rien faire en SSH que cloud-init ne puisse faire, et de garder le script avec ses sorties. Le volet Infrastructure as Code transformera ce script en Terraform ; le gain sera immédiat parce que la logique existe déjà.

Cost Optimization : le compteur s'arrête à la suppression, pas à l'arrêt

Qu'est-ce qui tourne encore une heure après la fin du lab ? Rien, si les cinq listes sont vides et si la consommation le confirme. La discipline est le trio with-volumes=all, with-ip=true, listes vides, complété par l'alerte budget posée avant de commencer. La facturation minimale d'une heure rend inutile de courir ; elle rend indispensable de ne rien laisser.

Reliability : une sauvegarde est une restauration réussie

Que reste-t-il si l'Instance disparaît maintenant ? L'archive dans le bucket, et la certitude qu'elle se lit, puisque vous l'avez restaurée. La discipline est la règle 3-2-1 (trois copies, deux supports, une hors site) et un test de restauration à chaque changement de procédure. Le volume Block, lui, se protège par snapshot ; ce lab ne l'a pas fait pour rester court, la leçon Block Storage montre comment.

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
/mnt/data absent après le démarrage	runcmd a échoué, ou le volume n'était pas encore visible	lire /var/log/cloud-init-output.log ; vérifier lsblk ; relancer mount -a
should be powered off à la suppression	Instance encore running	scw instance server stop … -w d'abord, ou force-shutdown=true
BucketNotEmpty à la suppression du bucket	objets ou versions restants	rclone delete puis vérifier avec rclone ls ; rclone purge vide et supprime d'un coup
Le projet refuse d'être supprimé	une ressource subsiste dans le projet	relister les cinq familles, supprimer ce qui reste
Une ligne Zonal Flexible IP apparaît dans la consommation sans Instance	adresse détenue, non libérée	scw instance ip list puis scw instance ip delete
size must be defined using the G or GB unit	taille du volume sans unité	from-empty.size=10GB
Les commandes ciblent le mauvais projet	default-project-id non remis après le lab	scw config get default-project-id, puis le remettre

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

• On isole un déploiement dans un projet dédié et on pose une alerte budget avant de provisionner ; le projet refuse d'être supprimé tant qu'il contient une ressource.
• additional-volumes.0=<id> attache un volume Block existant à la création ; il apparaît en /dev/sdb et se formate et se monte dans cloud-init, avec nofail et un montage par label.
• Une sauvegarde n'existe qu'après une restauration testée dans un répertoire vide.
• Le teardown with-volumes=all with-ip=true emporte volumes et IP ; with-volumes accepte none, local, block, root, all.
• Cinq listes vides (serveurs, volumes, snapshots, IP, buckets), puis scw billing consumption list, sont la seule preuve de fin de lab.
• Chaque ressource est facturée 60 minutes au minimum : ne courez pas, vérifiez.
• Relevé le 2026-09-08 : 3,04 € pour un mois de labs sur l'organisation de test, et une ligne Zonal Flexible IP sans Instance, la trace classique d'une adresse oubliée.

Pour aller plus loin

• VPC et Private Networks : Donner à cette Instance un réseau privé, première étape pour lui retirer son adresse publique.
• IPAM et Flexible IP : Comprendre pourquoi l'adresse survit à l'Instance, et comment la déplacer plutôt que la recréer.
• IAM : donner le droit minimal à une CI : Remplacer la clé personnelle utilisée ici par une identité de sauvegarde limitée à l'Object Storage.

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é.

• Billing FAQ : les événements de début et de fin de facturation par ressource, et la facturation minimale de 60 minutes.
• Understanding Instance pricing : ce qui continue d'être facturé quand une Instance est éteinte.
• Block Storage FAQ : ce qui arrive aux volumes quand une Instance est supprimée par l'API.
• How to use cloud-init : la référence officielle du bootstrap au démarrage.

×

📖 Voir la documentation →