Infrastructure as Code sur Scaleway : qui fait quoi

Deux outils officiels et une extension communautaire couvrent l'infrastructure as code sur Scaleway, et chacun échoue si on lui demande le travail d'un autre. Packer construit une image, Terraform provisionne l'infrastructure, Ansible exploite ce qui existe déjà. Cette leçon ouvre le volet : elle attribue chaque tâche au bon outil, donne les versions de référence avec leur date de publication, apprend à vérifier la signature de ce qu'on installe, et chiffre ce qu'un build coûte avant qu'on le lance. Elle ne construit rien : c'est la carte qu'on lit avant de partir, celle qui évite les décisions qu'on ne peut plus reprendre une fois la première ressource créée.

Ce que vous allez apprendre

• Attribuer chaque tâche au bon outil, et reconnaître les mélanges qui coûtent cher.
• Connaître les versions de référence, avec leur date de publication.
• Vérifier la signature de ce que vous installez, sur les trois outils.
• Estimer le coût d'un build d'image avant de le déclencher.

Prérequis du volet

Ce volet enseigne ce que Scaleway fait de Packer, Terraform et Ansible, pas ces trois outils. Chaque leçon suppose acquis ce qui suit, et renvoie vers la formation correspondante plutôt que de la réexpliquer :

• Terraform : écrire du HCL, comprendre l'état et les providers, enchaîner init, plan, apply et destroy (formation Terraform).
• Packer : un modèle HCL2, packer init et packer build (formation Packer).
• Ansible : un playbook, un inventaire, l'idempotence (formation Ansible).
• Un compte Scaleway avec un projet dédié et la CLI scw sur un profil isolé, comme au volet Prendre en main.

Packer, Terraform ou Ansible : lequel fait quoi ?

Chaque outil produit l'entrée du suivant. C'est ce qui rend l'ordre impératif plutôt que conventionnel.

	Packer	Terraform	Ansible
Produit	une image	des ressources	un changement d'état
Retient	rien, l'image est le produit	un état, comparé au réel	rien, il relit à chaque fois
Question posée	« cette image contient-elle ce qu'il faut ? »	« le réel correspond-il au code ? »	« cette ressource est-elle dans l'état voulu ? »
Détruit	non	oui, destroy	non, jamais

Glissez pour voir

Les trois mélanges qui coûtent le plus cher se reconnaissent à leur symptôme, et chacun fonctionne le premier jour :

• Configurer le système depuis Terraform, par remote-exec. Cela marche, et vous perdez l'idempotence : rejouer le apply ne rejoue pas la configuration, qui n'est pas dans l'état.
• Provisionner depuis Ansible. Cela marche aussi, et vous perdez le suivi d'état : rien ne détecte une ressource supprimée à la main, rien ne sait la détruire proprement.
• Installer les paquets au démarrage plutôt que dans l'image. Cela marche, et chaque machine met cinq minutes à devenir utile au lieu d'une, ce qui rend la mise à l'échelle automatique décorative.

La question qui départage, en une phrase

Demandez-vous qui possède la ressource. Terraform possède ce qu'il a créé et le détruira ; Ansible agit sur ce qu'il ne possède pas et ne détruira rien ; Packer ne possède qu'un artefact, l'image, que vous versionnez comme du code.

Ce critère règle presque tous les cas limites, y compris celui du volume de données qu'on hésite à déclarer dans Terraform : si vous ne voulez pas qu'un destroy l'emporte, il n'a rien à y faire.

Les versions de référence

Notez ces trois lignes, elles datent ce que vous lisez. Un guide d'infrastructure as code sans version est un guide qu'on ne peut pas reproduire.

Outil	Maintenu par	Version	Publiée le	Ce qu'elle apporte de notable
Provider Terraform scaleway/scaleway	Scaleway, organisation officielle	2.83.0	14 septembre 2026	destruction d'une interface privée attachée rétablie, cassée en 2.81.0 et 2.82.0 ; Instance Templates et groupes d'autoscaling depuis la 2.82.0
Plugin Packer scaleway/scaleway	Scaleway, organisation officielle	1.5.0	17 juin 2026	Windows Server, étiquettes du serveur temporaire, snapshot_name déplacé hors de la racine du bloc source
Collection Ansible stephrobert.scaleway	communauté, dépôt stephrobert	0.5.0	9 septembre 2026	attributs publiés, politique de rejeu, 50 modules
Collection Ansible scaleway.scaleway	organisation Scaleway, déclarée « Community »	2.7.2	19 février 2026	60 modules de provisionnement, inventaire dynamique, lookup Secret Manager
Collection Ansible community.general	communauté Ansible	11.4.7	publiée en continu	28 modules Scaleway et un inventaire, livrés avec le paquet ansible

Glissez pour voir

Il existe trois collections Ansible pour Scaleway : laquelle pour quoi ?

Vous en avez déjà une sans le savoir, Scaleway en héberge une autre, et ce parcours en utilise une troisième. Le dire franchement vaut mieux que de laisser croire qu'il n'y a pas de choix : il y en a un, et il se justifie par le périmètre, pas par l'absence d'alternative.

Relevé le 11 septembre 2026, sur l'installation locale et sur les dépôts :

Critère	community.general	scaleway.scaleway	stephrobert.scaleway
Où elle vit	collection communautaire d'Ansible	organisation Scaleway	dépôt stephrobert
Installation	déjà présente avec le paquet ansible	à installer	à installer
Version relevée	11.4.7	2.7.2, 19 février 2026	0.5.0, 9 septembre 2026
Modules Scaleway	28, dont 9 en _info	60	50 : 29 _info, 17 gestion, 4 _action
Inventaire dynamique	oui, scaleway	oui, scaleway	oui, compute
Lookup Secret Manager	non	oui	non
Exploitation au jour 2	partielle : state: running, restarted, stopped sur scaleway_compute	non annoncée	famille _action dédiée
check_mode et diff_mode déclarés par module	pas systématiquement	non documenté ainsi	50 sur 50 et 17 sur 50

Glissez pour voir

Commencez par regarder ce que vous avez déjà. Si vous avez installé le paquet ansible, community.general est là, avec ses 28 modules Scaleway et son inventaire. Pour créer une Instance, poser une adresse ou redémarrer une machine, elle suffit, et elle n'ajoute aucune dépendance. Sa contrepartie est qu'elle suit le rythme d'une collection généraliste de plus de cinq cents modules, où Scaleway n'est qu'un fournisseur parmi beaucoup d'autres. Sept de ses anciens modules _facts y sont d'ailleurs passés en tombstone, c'est-à-dire supprimés, au profit des _info.

scaleway.scaleway est la plus fournie pour le provisionnement, avec ses 60 modules et son lookup vers Secret Manager, qui n'a d'équivalent nulle part ailleurs. C'est aussi celle dont le périmètre recoupe le plus Terraform, à qui ce parcours confie la création des ressources.

Le départage ne tient donc pas à la qualité mais à la doctrine. Superposer un second outil de provisionnement créerait deux sources de vérité sur les mêmes objets, ce que la leçon Ansible passe son temps à déconseiller. Le besoin qui restait découvert est le jour 2 avec des garanties explicites : savoir, avant de lancer un playbook, quels modules répondent au mode répétition et lesquels montrent un différentiel.

Deux réserves valables pour les trois

Aucune n'est un produit supporté contractuellement. scaleway.scaleway est hébergée par l'éditeur mais son README s'intitule « Scaleway Community Collection » et renvoie au Slack, pas au support. community.general est maintenue par la communauté Ansible. La troisième est communautaire sans ambiguïté.

Regardez les dates. La collection de Scaleway n'a pas publié depuis février 2026, sept mois avant cette mesure, quand le provider Terraform publie tous les mois. Une dépendance s'évalue sur son activité et sa réactivité aux changements d'API, pas sur le logo qui figure au-dessus du dépôt.

Comment vérifier la signature d'un provider ou d'un plugin ?

Les trois outils publient des sommes de contrôle signées, et presque personne ne les vérifie. Le site enseigne la sécurité de la chaîne d'approvisionnement : autant l'appliquer sur les outils qui déploient votre infrastructure.

1. Terraform vérifie tout seul, à condition de le laisser faire

   Le provider est distribué avec un fichier SHA256SUMS et sa signature PGP. Terraform contrôle les deux pendant terraform init, et enregistre le résultat dans le fichier de verrouillage.

   terraform init
   grep -A4 'scaleway' .terraform.lock.hcl

   Le fichier doit contenir les empreintes h1: du provider. Versionnez-le : c'est lui qui garantit que votre équipe et votre chaîne d'intégration installent exactement le même binaire.

2. Packer demande une vérification explicite

   Le plugin publie lui aussi packer-plugin-scaleway_v1.5.0_SHA256SUMS et sa signature .sig. La vérification se fait avant l'installation, comme pour n'importe quel binaire téléchargé.

   packer plugins installed

   La sortie liste les plugins et leur version : c'est ce qu'il faut comparer à ce que votre modèle épingle.

3. La collection Ansible porte une signature sans clé

   L'archive est signée par cosign et accompagnée d'une attestation de provenance SLSA, toutes deux liées à l'identité du workflow qui l'a produite plutôt qu'à un secret à conserver.

   ansible-galaxy collection list stephrobert.scaleway

Ces trois commandes disent ce que vous avez réellement, ce qui n'est pas la même chose que ce que votre code déclare. C'est le premier réflexe à prendre quand un comportement diffère entre deux postes.

Pourquoi épingler la version n'est pas facultatif ?

Un outil d'infrastructure as code non épinglé rend votre code non reproductible, ce qui vide de son sens la raison même de l'écrire.

Ce n'est pas une précaution théorique. Mesuré le 2026-09-09 sur un compte Scaleway réel, avec une stack minimale d'un VPC, un Private Network, une instance DEV1-S et une interface privée : le provider 2.80.0 détruit l'ensemble en 7 secondes, code de sortie 0, tandis que 2.81.0 et 2.82.0 échouent tous deux sur une erreur 412 et laissent les quatre ressources en place. Une contrainte flottante aurait donc suffi à casser la destruction d'une infrastructure existante, sans le moindre changement de votre côté, le jour de la publication amont. La 2.83.0, publiée le 14 septembre 2026, rétablit la destruction : mesuré le même jour sur la même stack, code 0 en 13 secondes.

# Terraform : la contrainte va dans required_providers
terraform {
  required_providers {
    scaleway = {
      source  = "scaleway/scaleway"
      version = "2.83.0"
    }
  }
}

# Packer : la contrainte va dans required_plugins
packer {
  required_plugins {
    scaleway = {
      source  = "github.com/scaleway/scaleway"
      version = "1.5.0"
    }
  }
}

La contrepartie est connue et assumée : une version figée ne reçoit pas les correctifs de sécurité. C'est pourquoi l'épinglage s'accompagne d'un rythme de mise à jour, pas d'un oubli. Un provider qui n'a pas bougé depuis un an n'est pas stable, il est abandonné par son utilisateur.

Combien coûte un build d'image sur Scaleway ?

Terraform et Ansible ne coûtent rien par eux-mêmes ; Packer coûte à chaque exécution. C'est la différence qui surprend, et elle mérite d'être chiffrée avant le premier build.

Un build Packer démarre une vraie Instance, y exécute vos commandes, en prend un snapshot, produit une image, puis détruit la machine. Trois objets facturés, dont deux survivent au build.

Ce que le build consomme	Tarif	Sur un build de 15 minutes
une Instance DEV1-S	environ 0,009 €/h	moins d'un centime
une Flexible IP, exigée pour joindre la machine	0,005 €/h	négligeable
le snapshot produit	au gigaoctet stocké	tant qu'il existe
l'image produite	au gigaoctet stocké	tant qu'elle existe

Glissez pour voir

Le coût du build est dérisoire, celui de l'oubli ne l'est pas. Un snapshot et une image de dix gigaoctets laissés en place se facturent tous les mois, sans que rien ne les signale. C'est le poste que la leçon Packer apprend à contrôler après chaque build, réussi ou non.

Un build qui échoue laisse quelque chose derrière lui

Ce n'est pas une précaution théorique. Le plugin Packer porte un défaut ouvert depuis juillet 2025 : quand le provisionnement échoue, ou qu'on interrompt par Ctrl+C avant la création du snapshot, le serveur est bien détruit mais son volume Block racine reste orphelin, et il reste facturé.

La conséquence pratique tient en une phrase : après tout build, on reliste.

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

Les quatre listes doivent correspondre à ce que vous attendez, et pas seulement la première.

Regarder ce que vous avez déjà

Trois commandes de lecture, aucune ne crée rien, et elles répondent à la question qui commence tout dépannage : de quoi mon poste dispose-t-il réellement ?

terraform providers
packer plugins installed
ansible-galaxy collection list stephrobert.scaleway

La première liste les providers exigés par votre configuration et ceux réellement installés. La deuxième liste les plugins Packer présents, avec leur version. La troisième dit quelle version de la collection Ansible répondra, ce qui n'est pas toujours celle que vous croyez avoir installée.

Le décalage silencieux le plus fréquent

ansible-galaxy collection install ne met pas à jour une version déjà présente : il répond « Nothing to do. All requested collections are already installed. If you want to reinstall them, consider using --force. » et rend la main, code de sortie 0. Constaté en septembre 2026 avec la 0.1.0 en place alors que la 0.5.0 était publiée. Ce comportement vient du code d'ansible-galaxy, la documentation officielle ne le décrivant pas : elle documente --upgrade, qui est l'option qui débloque.

La commande qui met à jour le dit :

ansible-galaxy collection install stephrobert.scaleway --upgrade

Le même piège n'existe pas côté Terraform, où le fichier de verrouillage rend l'écart visible, ni côté Packer, où required_plugins déclenche l'installation.

Qu'est-ce que chaque outil ne sait pas faire ?

Connaître les limites évite de chercher pendant une heure une capacité qui n'existe pas. Les trois en ont, et elles sont documentées par leurs auteurs.

Outil	Ce qu'il ne fait pas aujourd'hui
Packer	construire depuis un réseau privé sans adresse publique : une Flexible IP reste exigée
Terraform	il ne configure pas le système ; remote-exec existe et n'est pas un substitut à Ansible
Collection Ansible	elle ne crée ni ne supprime aucune ressource, et ne découvre que les machines, pas les services managés

Glissez pour voir

Quel outil choisir pour la tâche que vous avez en main

La confusion la plus coûteuse consiste à faire faire à Terraform le travail d'Ansible, en enchaînant des provisionneurs remote-exec dans une ressource. Le résultat marche une fois, puis devient impossible à rejouer : Terraform ne sait pas si la commande a déjà tourné, et son état ne décrit pas le contenu de la machine. Le tableau ci-dessous se lit par la colonne de gauche : identifiez la tâche que vous avez réellement à faire, sans anticiper la suivante.

Besoin	Choix	Pourquoi
Figer un système durci, réutilisable par toute la flotte	Packer	l'image devient l'unité livrable, identique à chaque démarrage
Créer, modifier ou supprimer des ressources Scaleway	Terraform	il tient un état, donc il sait ce qu'il possède et sait le détruire
Configurer une machine qui existe déjà, ou la remettre en conformité	Ansible	il relit l'état réel à chaque exécution, sans mémoire à maintenir
Appliquer un correctif de sécurité sur une flotte en production	Ansible, puis Packer pour la suite	on répare tout de suite, puis on refait l'image pour que les prochaines machines naissent corrigées
Installer un paquet au premier démarrage d'une machine jetable	cloud-init, via Terraform	pour une machine éphémère, une image dédiée coûte plus cher qu'elle ne rapporte

Glissez pour voir

Les décisions du volet qu'on ne peut plus reprendre

Trois choix se prennent une seule fois, et se paient longtemps. Ils n'apparaissent dans aucun message d'erreur, ce qui les rend faciles à escamoter au moment où on les prend.

Décision	Pourquoi elle est difficile à reprendre
L'emplacement de l'état Terraform	migrer un état vivant demande terraform init -migrate-state sur toutes les copies, et une erreur laisse deux états divergents pour la même infrastructure
La granularité des stacks	découper une stack existante impose de déplacer les ressources une à une avec terraform state mv, sans se tromper
La convention de nommage et d'étiquetage	elle conditionne le tri de la facture ; renommer après coup casse la continuité des rapports de coût

Glissez pour voir

Limites, quotas et plafonds du volet

Ce volet crée des ressources, donc il rencontre des plafonds. Les valeurs ci-dessous viennent de la page officielle des quotas d'Organisation Scaleway, dont la date de validation est le 29 octobre 2025. Elles sont à connaître avant d'écrire une boucle : un count qui les dépasse casse à mi-parcours de l'apply, avec des ressources déjà créées et facturées.

Plafond	Valeur	Portée
Instances DEV1-S	10 sans vérification d'identité, 20 avec	par Organisation
VPC	256	par Organisation
Private Networks	100 par VPC, 255 par Organisation	le plus bas des deux s'applique
Seaux Object Storage	100	par Organisation, l'état Terraform en consomme un
Clés API	50	par Organisation, mais voir la note ci-dessous

Glissez pour voir

Une de ces valeurs est contredite par une autre page officielle, et la règle de cette formation est de le dire plutôt que de choisir celle qui arrange le propos. La FAQ IAM de Scaleway annonce « up to 100 API keys by default » là où la page des quotas dit 50. La page des quotas étant la plus récemment validée, au 29 octobre 2025, c'est elle qui fait foi ici, et l'écart est à vérifier sur votre propre compte avant de dimensionner vos automatisations.

Le plafond des instances mérite une lecture attentive, car il ne dépend pas du crédit disponible mais de la vérification d'identité du compte. Un compte dont seul le moyen de paiement est validé plafonne à dix machines DEV1-S, et plusieurs gammes ne sont pas ouvertes du tout avant vérification. La conséquence pratique est déroutante : terraform plan accepte sans broncher une stack qui déclare douze machines, parce que le plan ne consulte pas les quotas ; c'est l'apply qui échoue, après avoir créé les dix premières. Vous vous retrouvez alors avec une infrastructure à moitié construite, un état qui la décrit fidèlement, et une facture qui court. Vérifiez le plafond avant d'écrire la boucle, pas après l'avoir lancée.

Pièges courants du volet

Ces messages sont ceux que vous verrez réellement, relevés en lab sur un compte Scaleway les 8 et 9 septembre 2026. Les reconnaître fait gagner l'heure de recherche qui suit habituellement leur première apparition.

Symptôme	Cause	Solution
b_ssd volumes are no longer supported. Use Scaleway Block Storage (SBS) volumes instead	l'API Instance ne crée plus de volumes de cette gamme	passer à la ressource scaleway_block_volume, ce n'est pas un changement de valeur mais de ressource
Can't delete a private network interface attached to a server	régression du provider en 2.81.0 et 2.82.0 : la route v2alpha1 refuse une interface attachée	passer en 2.83.0 ou revenir à 2.80.0, ou supprimer l'interface avec scw instance private-nic delete avant de relancer le destroy
Le plugin Packer refuse snapshot_name	l'option a quitté la racine du bloc source en 1.5.0	la déplacer dans root_volume {} ou block_volume {}, où elle reste valide
terraform plan réussit, terraform apply échoue sur un quota	le plan ne consulte pas les quotas de l'Organisation	relever le plafond de la gamme visée avant d'écrire un count
403 intermittents au rafraîchissement, rapportés sur scaleway_baremetal_server	cause non confirmée par Scaleway ; le rapporteur soupçonne un rythme d'appels trop élevé (#3616)	terraform plan -parallelism=1 quand le symptôme apparaît, SCW_DEBUG=1 pour observer les appels

Glissez pour voir

Antipatterns à éviter

Ces quatre erreurs partagent une même racine : elles confondent le rôle des outils. Chacune produit un résultat qui fonctionne le premier jour, et qui devient impossible à rejouer ou à détruire ensuite. C'est ce décalage entre le succès immédiat et le coût différé qui les rend difficiles à repérer en revue.

Antipattern	Conséquence	Discipline
Configurer les machines avec remote-exec dans Terraform	l'état ne décrit pas le contenu de la machine, et rien n'est rejouable	Terraform crée, Ansible configure
Faire détruire des ressources par Ansible	aucun état ne suit ce qui existe, les restes deviennent invisibles	seul Terraform détruit ce que Terraform a créé
Rebâtir une image à chaque déploiement	le temps de build s'ajoute à chaque livraison, et les snapshots s'accumulent en facturation	une image par version applicative, pas par déploiement
Contraintes de version flottantes sur les trois outils	une publication amont change le comportement sans commit de votre côté	épingler les trois, et mettre à jour sciemment

Glissez pour voir

L'infrastructure as code sous l'angle Well-Architected

Le code d'infrastructure déplace le risque : il ne le supprime pas. Les deux piliers ci-dessous posent la question qu'un auditeur poserait sur ce volet, et la discipline qui y répond.

Excellence opérationnelle

Question clé : combien de temps faut-il pour reconstruire à l'identique ce qui tourne aujourd'hui ? Si la réponse dépend d'une personne, d'un poste de travail ou d'un souvenir, le code d'infrastructure n'a pas rempli son office.

Discipline : versionner les modèles Packer, le HCL Terraform et les playbooks Ansible dans le même dépôt que l'application ; épingler les trois outils à une version exacte ; et vérifier les signatures à l'installation, ce que les trois publient.

Optimisation des coûts

Question clé : qui paie ce que le volet a laissé derrière lui ? Les instances se remarquent, les snapshots et les images non. Ils se facturent au gigaoctet stocké, indéfiniment, et n'apparaissent sur aucun tableau de bord tant qu'on ne les cherche pas.

Discipline : détruire ce qui a été créé dans la foulée du lab ; contrôler les familles discrètes, images et snapshots en tête ; et relire la facturation 48 heures plus tard, délai au-delà duquel la consommation est consolidée.

FAQ : questions fréquentes sur l'infrastructure as code Scaleway

Ces cinq réponses reprennent les questions posées le plus souvent au moment de choisir un outil, et ne contiennent que des faits mesurés ou sourcés dans ce volet : la matrice de destruction du 2026-09-09, les quotas d'Organisation validés au 29 octobre 2025, et la grille tarifaire relevée le 2026-09-08.

Terraform ou Ansible sur Scaleway : quelle différence ?

Terraform crée et détruit des ressources dont il tient l'état ; Ansible agit sur des ressources existantes sans rien retenir. La collection stephrobert.scaleway ne contient d'ailleurs aucun module de création ni de suppression.

Faut-il Packer si on utilise déjà cloud-init ?

Les deux se complètent. Packer personnalise l'image dont la machine démarre, cloud-init personnalise la machine au démarrage. Ce qui vaut pour toute la flotte va dans l'image ; ce qui dépend de la machine reste dans cloud-init.

Quelle version du provider Terraform Scaleway faut-il utiliser ?

La 2.83.0, publiée le 14 septembre 2026. Les 2.81.0 et 2.82.0 ne savent pas détruire une interface réseau privée attachée à un serveur : elles échouent en erreur 412 et laissent tout facturé, quand 2.80.0 et 2.83.0 détruisent en quelques secondes.

Le provider Terraform Scaleway est-il gratuit ?

Oui, le provider, le plugin Packer et la collection Ansible sont gratuits et open source. Ce qui se facture, ce sont les ressources qu'ils créent : instances, load balancers, passerelles, volumes, snapshots et images.

Combien coûte un build d'image Packer sur Scaleway ?

Le build lui-même coûte quelques centimes : une instance DEV1-S à environ 0,009 EUR/h et une Flexible IP à 0,005 EUR/h, sur une quinzaine de minutes. Ce qui coûte, c'est le snapshot et l'image conservés ensuite.

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

• Chaque outil produit l'entrée du suivant : Packer l'image, Terraform l'infrastructure, Ansible l'état courant.
• La question qui départage est « qui possède la ressource » : Terraform la détruira, Ansible non.
• Versions de référence : provider Terraform 2.83.0, plugin Packer 1.5.0, collection Ansible 0.5.0.
• Chez Packer on dit plugin et builder, jamais provider.
• Les trois publient des sommes de contrôle signées ; Terraform les vérifie seul, les deux autres demandent un geste.
• Un fichier de verrouillage se versionne : c'est lui qui rend le déploiement reproductible.
• Terraform et Ansible ne coûtent rien, Packer coûte à chaque build : une Instance, une adresse, un snapshot et une image.
• Un build interrompu laisse un volume orphelin facturé. On reliste après chaque build, pas seulement après ceux qui échouent.
• ansible-galaxy install ne met pas à jour sans --upgrade.

Pour aller plus loin

• Ansible : exploiter ce que Terraform a provisionné : le troisième temps du triptyque, avec l'inventaire dynamique et l'idempotence mesurée.

Ressources externes

• Provider Terraform Scaleway sur le registre : la référence des ressources, version par version.
• Plugin Packer scaleway/scaleway : les notes de version, où se lisent les options retirées avant qu'elles ne cassent un modèle.
• Quotas d'Organisation Scaleway : les plafonds cités ici, à vérifier pour votre propre compte.
• Collection Ansible stephrobert.scaleway : les modules, leur documentation et le suivi des correctifs.

×

📖 Voir la documentation →