Module 2 — Prise en main (environnement et premiers blocs HCL)

Durée indicative du cours : 0h40–0h45 (matin Jour 1 — socle condensé)
Durée indicative de l’atelier : ~0h45–1h00 — Ateliers Jour 1
Durée totale (cours + atelier) : partagée avec le module 3 sur le matin Jour 1

Prérequis outils (rappel)

Outil	Rôle
Terraform CLI ≥ 1.10 (recommandé)	Moteur IaC — aligné avec la fiche Associate
VS Code + extension HashiCorp	Édition HCL (formatage / validation)
Git	Versioning des `.tf` et du lockfile
Azure CLI	Authentification pratique vers Azure (lab)

Vérifications rapides :

terraform version
az version
az login --tenant "<TENANT_ID>"
az account list --output table
az account set --subscription "<NOM_OU_ID>"
az account show

Souscription

Après az account set, vérifiez avec az account show que vous êtes sur la bonne souscription de lab avant le premier apply.

Anatomie d’un projet minimal

Un dossier, des fichiers *.tf. Terraform charge tous les .tf du répertoire de travail. Il n’y a pas d’imports comme en Python : tout le dossier forme une configuration.

Les trois blocs fondamentaux

1. Bloc `terraform`

Paramètres du core Terraform : version du binaire, providers à télécharger, et (plus tard) où stocker le state.

terraform {
  required_version = ">= 1.10.0"

  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~> 3.0"
    }
  }

  # backend "azurerm" { … }  ← Jour 2 : où vit le state distant
}

required_version impose une version minimale du binaire Terraform. Cela évite les surprises entre machines et agents CI.
required_providers déclare quels plugins Terraform doit télécharger au init. Ce n’est pas encore la connexion à Azure.
backend indique où Terraform stocke le fichier d’état. Sans bloc backend, le state est local (terraform.tfstate dans le dossier).

Backend — aujourd’hui local, demain distant

Toute la journée 1, vous travaillez en backend local. C’est volontaire : on maîtrise d’abord le workflow et la lecture du plan.

La configuration d’un backend distant (par exemple Azure Storage), la migration d’un state existant, et le state lock en équipe seront abordés au Jour 2.

Que met-on dans `required_providers` ?

Champ	Rôle	Exemple
Nom local (clé)	Comment on appellera le provider dans le code	`azurerm = { … }`
`source`	D’où le télécharger (Registry)	`"hashicorp/azurerm"`
`version`	Quelle plage de versions accepter	`"~> 3.0"`

Sans required_providers, Terraform peut encore « deviner », mais c’est fragile. En projet racine, toujours le déclarer.

Le source a la forme NAMESPACE/NAME sur le Terraform Registry. Pour Azure Resource Manager : hashicorp/azurerm.

required_providers ≠ bloc provider

required_providers (dans terraform { }) indique quel plugin télécharger et quelle version accepter.
provider "azurerm" { } indique comment se connecter à Azure (authentification, souscription, comportements).

Contraintes de version (rappel utile pour l’exam)

Opérateur	Signification	Exemple
`>=`	Minimum inclus	`>= 1.10.0`
`~>`	« pessimiste » : seul le dernier chiffre indiqué peut monter	`~> 3.0` → `>= 3.0.0` et `< 4.0.0`

Dans ce cours :

Pour le Terraform CLI, on fixe souvent un minimum avec >=.
Pour le provider en projet racine, on utilise souvent ~> : correctifs et mineures sans sauter une majeure fragile.

Documentation officielle : Version Constraints.

2. Bloc `provider`

Configure comment Terraform parle à un cloud une fois le plugin installé.

provider "azurerm" {
  features {}
}

Le bloc features { } est requis par AzureRM (même s’il est vide). Pour le lab du Jour 1, le vide suffit.

Authentification lab — `az login` ou variables `ARM_*`

Pour un lab en local, la méthode recommandée est l’Azure CLI :

az login --tenant "…"
az account set --subscription "…"
bloc provider minimal avec seulement features {}

Le provider reprend alors la session CLI. Ne pas coller de secret dans le code versionné.

Authentification pendant la formation

En conditions réelles, on n’écrit jamais client_id / client_secret dans des fichiers .tf versionnés.

Pendant la session, le formateur peut fournir un Service Principal temporaire. Vous définissez les variables dans le terminal uniquement :

# Bash / macOS / Linux
export ARM_CLIENT_ID="..."
export ARM_CLIENT_SECRET="..."
export ARM_TENANT_ID="..."
export ARM_SUBSCRIPTION_ID="..."

# PowerShell (Windows)
$env:ARM_CLIENT_ID="..."
$env:ARM_CLIENT_SECRET="..."
$env:ARM_TENANT_ID="..."
$env:ARM_SUBSCRIPTION_ID="..."

Le bloc provider reste minimal (features {} seulement). Terraform lit ces variables automatiquement. Identifiants dédiés au lab — ne pas les committer.

Autres modes (aperçu — détail Jour 2) : Service Principal en CI, Managed Identity, OIDC / Workload Identity Federation. Documentation utile : Authenticating via the Azure CLI.

3. Bloc `resource`

Déclare une ressource gérée.

resource "azurerm_resource_group" "lab" {
  name     = "rg-tfassoc-lab-alice"
  location = "switzerlandnorth"

  tags = {
    course = "tf-associate"
    env    = "lab"
  }
}

La syntaxe est : resource "<TYPE>" "<NOM_LOCAL>" { ... }

TYPE — défini par le provider (azurerm_resource_group)
NOM_LOCAL — identifiant dans votre code (lab, main…) — ce n’est pas forcément le nom Azure
Adresse Terraform — azurerm_resource_group.lab

flowchart TB
  subgraph config [Configuration]
    TF[Bloc terraform]
    PROV[Bloc provider azurerm]
    RES[resource …]
  end

  subgraph azure [Azure]
    API[API Azure]
  end

  TF --> PROV --> RES --> API

Registry et documentation

Le Terraform Registry est la source standard des providers (et des modules publics). Pour chaque ressource AzureRM :

Ouvrez la page du provider hashicorp/azurerm.
Choisissez la même version majeure que votre contrainte (ici 3.x).
Lisez les arguments Required / Optional et les notes de cycle de vie (ForceNew, etc.).

Réflexe exam

Savoir où trouver la doc d’une ressource (Registry) et ce que signifie required_providers compte autant que mémoriser la syntaxe d’un seul type Azure.

Identifiants HCL : snake_case

Les noms locaux (labels de resource, variable, output, locals) suivent en pratique le snake_case recommandé par HashiCorp : lab, web_api, project_name.

Ne confondez pas :

Monde	Exemple	Qui décide ?
Identifiant HCL	`resource "…" "web_api"`	Style Terraform (snake_case)
Nom cloud (`name = "…"`)	`rg-tfassoc-lab-alice`	Conventions Azure + naming d’équipe

Pour la règle d’équipe détaillée (exemples, anti-patterns), voir Terraform Basics — Conventions de nommage.

`terraform fmt` — premier réflexe qualité

fmt réécrit les fichiers .tf selon le style officiel HashiCorp. Il ne touche pas Azure.

terraform fmt
terraform fmt -check    # utile en CI : échoue s’il reste quelque chose à formater

À lancer après un copier-coller depuis le Registry, et avant un commit. Le détail de fmt / validate dans le cycle complet se trouve au module 3.

Premiers fichiers du fil rouge

Pour le lab Associate Jour 1, un découpage minimal suffit :

Fichier	Contenu typique
`versions.tf` (ou `terraform.tf`)	Bloc `terraform` + `required_providers`
`providers.tf`	Bloc `provider "azurerm"`
`main.tf`	Resource Group (et plus tard le reste)

Vous pouvez tout mettre dans un seul fichier au début. L’important est de versionner les .tf et le .terraform.lock.hcl, pas le state ni le dossier .terraform/.

Aller plus loin — même atelier d’esprit en Basics

Une prise en main très détaillée (contraintes de version, features avancés, aperçu data) se trouve dans Terraform Basics — module 2. L’atelier Associate Jour 1 condense l’esprit des ateliers Basics 1 et 2 : projet + Resource Group + cycle complet.

Points à retenir

Un projet = un dossier de .tf lus ensemble.
Trois blocs à maîtriser tout de suite : terraform, provider, resource.
Auth lab : az login ou variables ARM_* en session — jamais de secrets dans Git.
Registry = source de vérité pour providers et arguments de ressources.
Identifiants HCL en snake_case ; noms Azure = autre convention.

Suite

Théorie suivante : module 3 — Workflow.
Pratique : Ateliers — Jour 1.