Terraform contre feint : Scaleway, Outscale et le refus Exoscale

Terraform et OpenTofu s'appliquent contre feint sans compte cloud, sur deux des trois fournisseurs émulés. Vous changez une ligne de configuration, le reste est le code que vous déploierez en production, et un cycle apply puis destroy complet passe sans créer la moindre ressource facturée. Cette page donne les blocs provider exacts pour Scaleway et Outscale, explique pourquoi le provider Exoscale est refusé, et traite le cas du volume racine qui a longtemps bloqué les configurations Scaleway.

Ce que vous allez apprendre

• Détourner le provider Scaleway avec un seul réglage, api_url.
• Piloter Outscale avec son bloc api, dont le chemin complet est un piège.
• Comprendre le refus du provider Exoscale, et ce qu'il protège.
• Écrire un root_volume que le provider accepte enfin.

Deux des trois fournisseurs se pilotent par Terraform contre l'émulateur : Scaleway et Outscale. Le troisième, Exoscale, est refusé volontairement, et la raison vaut d'être lue avant de chercher à contourner le garde-fou. Chaque cas est traité ci-dessous.

Terraform sur Scaleway

Le provider Scaleway se détourne avec un seul réglage, api_url. Le reste de la configuration reste celle que vous écririez pour le vrai fournisseur, ce qui est tout l'intérêt : vous testez le code que vous déploierez.

terraform {
  required_providers {
    scaleway = {
      source  = "scaleway/scaleway"
      version = "~> 2.79"
    }
  }
}

provider "scaleway" {
  access_key      = "SCWXXXXXXXXXXXXXXXXX"
  secret_key      = "11111111-1111-1111-1111-111111111111"
  project_id      = "11111111-1111-1111-1111-111111111111"
  organization_id = "99999999-9999-4999-8999-999999999999"
  region          = "fr-par"
  zone            = "fr-par-1"

  api_url = "http://127.0.0.1:4599"
}

resource "scaleway_vpc" "lab" {
  name = "lab-feint"
}

resource "scaleway_vpc_private_network" "lab" {
  name   = "reseau-interne"
  vpc_id = scaleway_vpc.lab.id
}

resource "scaleway_instance_server" "web" {
  name  = "web-terraform"
  type  = "DEV1-S"
  image = "ubuntu_jammy"
}

L'application se déroule sans adaptation particulière :

terraform init
terraform apply -auto-approve

Apply complete! Resources: 3 added, 0 changed, 0 destroyed.

Outputs:

private_network_id = "fr-par/a0fa6f82-2aad-4f82-985a-2abeb65f05f7"
server_id = "fr-par-1/d2303f04-8ab3-4e71-a682-ad91c81286b7"

Les identifiants renvoyés portent le préfixe de région ou de zone, comme chez Scaleway. Un terraform destroy fonctionne symétriquement, ce qui permet de valider un cycle complet dans une CI sans créer la moindre ressource facturée. Pour la construction des configurations elles-mêmes, la section Terraform du site couvre le sujet en profondeur.

Un avertissement à ne pas confondre avec une erreur

Si vous avez déjà un compte Scaleway configuré, Terraform affiche Multiple variable sources detected. Le provider a trouvé à la fois votre ~/.config/scw/config.yaml et le bloc provider, et il vous dit lequel il retient : celui du bloc. C'est le comportement voulu, mais vérifiez la colonne Currently using avant de conclure que vous testez bien contre l'émulateur.

Terraform sur Outscale

Le provider officiel outscale/outscale pilote l'émulateur de bout en bout, avec un bloc api au lieu de l'argument api_url de Scaleway. La différence de forme compte : ici l'adresse porte le chemin complet de l'API, segment de version inclus.

terraform {
  required_providers {
    outscale = {
      source  = "outscale/outscale"
      version = "~> 1.7"
    }
  }
}

provider "outscale" {
  access_key_id = "AAAAAAAAAAAAAAAAAAAA"
  secret_key_id = "BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB"

  api {
    endpoint = "http://127.0.0.1:4599/api/v1"
    region   = "eu-west-2"
  }
}

resource "outscale_net" "lab" {
  ip_range = "10.70.0.0/16"

  tags {
    key   = "name"
    value = "lab-feint"
  }
}

resource "outscale_subnet" "lab" {
  net_id   = outscale_net.lab.net_id
  ip_range = "10.70.1.0/24"
}

resource "outscale_vm" "web" {
  image_id  = "ami-12345678"
  vm_type   = "tinav4.c2r2p1"
  subnet_id = outscale_subnet.lab.subnet_id
}

Le cycle complet passe, y compris le second plan vide qui est le vrai révélateur d'une émulation correcte : si l'API renvoie ses ressources autrement qu'elle ne les a acceptées, Terraform propose une modification fantôme à chaque exécution.

outscale_net.lab: Creation complete after 0s [id=vpc-4e93695a]
outscale_subnet.lab: Creation complete after 1s [id=subnet-348a9987]
outscale_vm.web: Creation complete after 0s [id=i-ef8f6fe1]

Apply complete! Resources: 3 added, 0 changed, 0 destroyed.

No changes. Your infrastructure matches the configuration.

Le segment /api/v1 n'est pas facultatif

Oublier /api/v1 dans endpoint ne produit pas une erreur lisible : le provider réessaie avec temporisation jusqu'à expiration, et l'échec ressemble à un émulateur lent plutôt qu'à un client mal dirigé. Comptez six minutes perdues avant le premier indice. Les arguments region, endpoints et insecure au niveau racine sont par ailleurs dépréciés au profit de ce bloc api, et les utiliser coûte un avertissement à chaque commande.

Pourquoi le provider Terraform Exoscale est refusé

feint refuse les appels du provider Terraform Exoscale, et répond 400 avec l'explication. Ce n'est pas une lacune, c'est une protection de votre facture.

{"message":"the Exoscale Terraform provider only honours EXOSCALE_API_ENDPOINT
for half of its calls: the rest reach the real cloud and create billable
resources. feint refuses rather than serve half an apply. Set
FEINT_EXOSCALE_ALLOW_TERRAFORM=1 if you understand that and want the half it can
serve. See docs/limits.md."}

La cause est mesurée : ce provider n'honore le point d'accès que pour une partie de ses appels, et les autres partent vers le vrai cloud avec les identifiants trouvés dans l'environnement. Un apply se retrouverait donc partagé entre l'émulateur et un compte payant, et un demi-succès est indiscernable d'un fonctionnement normal jusqu'à la facture. Refuser tôt et bruyamment est le seul comportement honnête.

L'échappatoire existe, nommée plutôt que cachée, pour qui accepte ce partage en connaissance de cause :

FEINT_EXOSCALE_ALLOW_TERRAFORM=1 feint serve

Le CLI exo n'est pas concerné : la détection porte sur le seul agent utilisateur Exoscale-Terraform-Provider, donc elle refuse un client, pas un fournisseur.

À retenir

• Scaleway se détourne avec api_url, Outscale avec un bloc api dont le chemin porte /api/v1.
• Le second plan vide est le vrai test : sans lui, l'émulation renvoie ses ressources autrement qu'elle ne les accepte.
• Le provider Exoscale est refusé en 400 : il partagerait l'apply entre l'émulateur et un compte facturé.
• root_volume accepte sbs_volume depuis la 0.8.0, ce qui débloque les configurations qui le déclarent.
• Un cycle complet ne coûte rien : apply, plan vide, destroy, sans ressource facturée.

Prochaines étapes

Machines réelles et SSH Faire tourner de vraies machines derrière l'API, et s'y connecter.

Terraform Écrire les configurations que vous testerez contre l'émulateur.

Cloud Outscale Le fournisseur réel, une fois vos configurations validées en local.

×

📖 Voir la documentation →