Initialiser un projet Terraform pour GCP et Azure

Utiliser les services de stockage objets pour stocker le tfstate

Terraform utilise un fichier appelé le tfstate pour stocker l'état de l'infrastructure. Ce fichier peut contenir des informations sensibles comme par exemple les identifiants utilisateur pour se connecter à GCP ou aux bases de données SQL managées dans Azure. C'est l'une des raisons pour lesquelles un dépôt Git, par exemple, n'est pas adapté pour stocker l'état de l'infrastructure : le fichier tfstate .

Nous pouvons également collaborer à plusieurs sur le code Terraform. Pour que cela soit possible, Terraform doit s'assurer qu'une seule modification à la fois peut être effectuée sur l'infrastructure. Pour y parvenir, Terraform maintient un fichier .lock dans le backend de stockage chaque fois qu'une modification est appliquée à l'infrastructure. Une fois les modifications appliquées, le fichier .lock est supprimé et d'autres modifications peuvent à nouveau être appliquées par d'autres utilisateurs. Le fichier .lock contient des informations sur l'utilisateur effectuant la modification et d'autres métadonnées.

Les Comptes de stockage Azure ainsi que les Bucket GCP (services de stockage objets) sont vos meilleures options lorsque vous travaillez avec Azure et GCP. Ils prennent tous deux en charge nativement le verrouillage du fichier tfstate ainsi que l'authentification des utilisateurs pour la lecture du tfstate, ce qui est très utile pour faciliter la collaboration sur le code Terraform et s'assurer que seules les personnes autorisées ont accès au fichier tfstate. Une fois les services de stockage créés, nous devons dire à Terraform de les utiliser pour stocker le fichier tfstate. Voici quelques exemples de configuration de backends Azure et GCP pour le stockage du tfstate. Voir Configuration du backend Azure pour le Tfstate ainsi que Configuration du backend GCP pour le Tfstate pour plus de détails ou des extraits de configuration pour d'autres versions de Terraform.

• Azure

terraform {
  backend "azurerm" {
    resource_group_name  = "example-resource-group"
    storage_account_name = "example-storage-account"
    container_name       = "tfstate"
    key                  = "prod.terraform.tfstate"
  }
}

Nous pouvons demander à Terraform de s'authentifier auprès du compte de stockage Azure à l'aide d'une clé d'accès ou d'un jeton SAS en définissant les variables d'environnement suivantes avant d'utiliser les commandes Terraform :

# Use Storage Account Access Key for authentication
(bash)$ export ARM_ACCESS_KEY=<azure_storage_account_access_key>

# Use Storage Account SAS Token for authentication
(bash)$ export ARM_SAS_TOKEN=<azure_storage_account_sas_token>

• GCP

terraform {
  backend "gcs" {
    bucket  = "example-bucket"
    prefix  = "terraform/state"
  }
}

Avant d’exécuter les commandes Terraform avec cette configuration de backend, assurez-vous que l’utilisateur GCP ou le compte de service utilisé par Terraform dispose des autorisations de lecture et d’écriture sur le bucket configuré.

Utiliser des versions de providers fixes

Les providers Terraform contiennent du code distinct géré soit par l'équipe Terraform, soit par la communauté Terraform, soit par des fournisseurs d'infrastructures Cloud tels que Google pour Google Cloud Platform, Microsoft pour Azure Cloud Platform ou Amazon pour Amazon Web Services. Ils définissent un ensemble de ressources Terraform qui peuvent être utilisées pour facilement créer des ressources sur les plateformes des différents fournisseurs de Cloud, en exploitant les API REST qu'ils mettent à disposition. Voici des exemples de configuration de providers Terraform pour Azure et GCP.

Azure

provider "azurerm" {
  features {}
}

Pour plus de détails et d'options de configuration, voir Provider Terraform Azure

GCP

provider "google" {
  project     = "my-project-id"
  region      = "us-central1"
}

Pour plus de détails et d'options de configuration, voir Provider Terraform GCP et Référence de configuration du provider Terraform GCP

Une fois les ressources d'infrastructure créées avec une version de provider spécifique, il est important de figer cette version pour garantir que le code fonctionne de la même manière qu'avant lors des prochaines exécutions. Sinon, Terraform utilisera la dernière version disponible du provider à chaque exécution du code et une nouvelle version du provider signifie la plupart du temps de nouvelles fonctionnalités, des dépréciations et des modifications de codes des ressources Terraform associées. Voici comment vous assurer que Terraform utilise toujours une version de fournisseur spécifique.

• Utiliser le bloc de définition des providers requis

# Azure

terraform {
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "=3.26.0"
    }
  }
}

# GCP

terraform {
  required_providers {
    google = {
      source  = "hashicorp/google"
      version = "=4.39.0"
    }
  }
}

En plus des contraintes de version correspondant au numéro de version exact à utiliser pour un provider, il existe d'autres variantes que nous pourrions utiliser. Voir Syntaxe des contraintes de version de Terraform pour en savoir plus.

Dans les versions Terraform à partir de 0.14un fichier de verrouillage de dépendances est automatiquement créé lorsque la commande terraform init est exécutée. Ce fichier est nommé .terraform.lock.hcl et contient les versions des providers sélectionnées pour être utilisées, en fonction des contraintes de versions définies dans les fichiers de configuration Terraform.

S'il n'y a aucune contrainte de version spécifiée à l'intérieur du bloc required_providers , bloc où nous définissons quels providers nous souhaitons utiliser, le fichier .terraform.lock.hcl contiendra la dernière version disponible des providers. .terraform.lock.hcl peut ensuite être partagé avec le code Terraform (via Git par exemple) afin de garantir que les autres personnes qui l'utilisent obtiennent les mêmes versions de providers.

Lorsqu'aucune contrainte de version n'est définie dans les fichiers de configuration Terraform mais qu'un fichier .terraform.lock.hcl existe déjà, vous pouvez ignorer les versions des fournisseurs définies dans ce fichier de dépendances et utiliser les dernières versions disponibles grâce à la commande terraform init -upgrade .

Configurer les versions Terraform requises

Afin de contraindre les utilisateurs de nos codes Terraform à utiliser des versions Terraform spécifiques pour exécuter les codes, nous pouvons définir des contraintes de version comme suit :

terraform {
  required_version = "~> 1.3.6"
}

La routine shell ~> permet uniquement au composant de version le plus à droite d'être incrémenté, ce qui signifie que pour cet exemple, nous pourrions utiliser les versions Terraform 1.3.x au x >= 6 pour exécuter les codes. Il existe d'autres formes de contraintes de version que nous pourrions utiliser. Voir Syntaxe des contraintes de versions Terraform pour en savoir plus.

Options de configuration de l'authentification

Authentification avec nos propres comptes utilisateurs

Il s'agit naturellement de la méthode d'authentification à utiliser lorsque nous exécutons nous-mêmes les codes Terraform. Les autorisations requises pour mettre à jour l'infrastructure sont accordées à de vraies personnes, et les informations sur les personnes ayant effectué les modifications et à quel moment peuvent être facilement récupérées à partir des journaux d'audit de la plateforme contenant l'infrastructure.

Google Cloud Platform (GCP)

• Pré-requis : Installer gcloud
• Exécutez ensuite les commandes suivantes :

$ gcloud auth login <gcp_user_account_email>

$ gcloud auth application-default login
(...)
Credentials saved to file: [/home/<user>/.config/gcloud/application_default_credentials.json]
(...)

$ export GOOGLE_APPLICATION_CREDENTIALS=/home/<user>/.config/gcloud/application_default_credentials.json

• Après cela, nous devrions pouvoir utiliser Terraform pour créer des ressources dans Google Cloud Platform (si nous disposons bien évidemment des permissions requises)

• La première commande de connexion lancera un navigateur Web pour l'authentification. Si vous préférez ou si vous êtes dans un environnement où le navigateur ne peut être lancé, vous pouvez ajouter l'option --no-launch-browser à cette commande. Exécuter gcloud auth login -h pour lister toutes les options disponibles

Plateforme cloud Microsoft Azure

• Pré-requis : Installer Azure CLI
• Ensuite, lancez la commande az login -u <azure_user_account_email> .
• Un navigateur Web sera lancé pour l'authentification
• Après l'authentification, nous devrions être en mesure de créer les ressources nécessaires via Terraform (à condition d'avoir les autorisations requises côté Azure, bien évidemment)

Authentification avec des comptes de service dédiés

Si nous ne voulons pas utiliser nos propres comptes utilisateurs pour exécuter du code Terraform, par exemple lorsque nous déléguons l'exécution à des applications CI/CD sur des modifications de code, il est possible de le faire sur GCP en utilisant un compte de service Google Cloud et Azure en utilisant des identités gérées (UMI : User Managed Identity) par exemple. Voici les documentations des fournisseurs Google Cloud et Azure sur la façon d'utiliser ces types de comptes pour exécuter du code Terraform : Identités gérées (UMI) Azure pour Terraform et Compte de service GCP pour Terraform