Backend

Configuration des Backends Terraform

#

Les backends définissent où Terraform stocke ses fichiers d’état.

Terraform utilise des données d’état persistantes pour suivre les ressources qu’il gère. La plupart des configurations Terraform non triviales intègrent soit Terraform Cloud, soit utilisent un backend pour stocker l’état à distance. Cela permet à plusieurs personnes d’accéder aux données d’état et de collaborer sur cette collection de ressources d’infrastructure.

Remarque: Dans les versions Terraform avant 1.1.0, nous classifions les backends comme standard ou amélioré. L’étiquette “amélioré” différenciait le backend distant, qui pouvait à la fois stocker l’état et effectuer des opérations Terraform. Cette classification a été supprimée.

Backends disponibles

#

Par défaut, Terraform utilise un backend appelé local, qui stocke l’état sous forme de fichier local sur le disque. Vous pouvez également configurer l’un des backends intégrés inclus dans cette documentation.

Certains de ces backends agissent comme des disques distants simples pour les fichiers d’état, tandis que d’autres prennent en charge le verrouillage de l’état pendant les opérations en cours. Cela aide à prévenir les conflits et les incohérences. Les backends intégrés répertoriés sont les seuls backends. Vous ne pouvez pas charger de backends supplémentaires sous forme de plugins.

Utilisation d’un Bloc backend

#

Vous n’avez pas besoin de configurer un backend lorsque vous utilisez Terraform Cloud car Terraform Cloud gère automatiquement l’état dans les espaces de travail associés à votre configuration. Si votre configuration inclut un bloc cloud, il ne peut pas inclure un bloc backend.

Pour configurer un backend, ajoutez un bloc backend imbriqué dans le bloc terraform de niveau supérieur. L’exemple suivant configure le backend distant.

terraform {
  backend "remote" {
    organization = "example_corp"

    workspaces {
      name = "my-app-prod"
    }
  }
}

Il existe certaines limitations importantes de la configuration du backend :

• Une configuration ne peut fournir qu’un seul bloc backend.
• Un bloc backend ne peut pas faire référence à des valeurs nommées (comme les variables d’entrée, les locals ou les attributs des sources de données).

Identifiants et Données Sensibles

#

Les backends stockent l’état dans un service distant, ce qui permet à plusieurs personnes d’y accéder. L’accès à l’état distant nécessite généralement des informations d’identification, car les données d’état contiennent des informations extrêmement sensibles.

Terraform écrit la configuration du backend en texte clair dans deux fichiers distincts.

• Le fichier .terraform/terraform.tfstate contient la configuration du backend pour le répertoire de travail actuel.
• Tous les fichiers de plan capturent les informations de .terraform/terraform.tfstate au moment où le plan a été créé. Cela permet de s’assurer que Terraform applique le plan au bon ensemble d’infrastructures.

Lors de l’application d’un plan que vous avez précédemment enregistré dans un fichier, Terraform utilise la configuration du backend stockée dans ce fichier au lieu des paramètres de backend actuels. Si cette configuration contient des informations d’identification à durée limitée, elles peuvent expirer avant que vous ayez terminé d’appliquer le plan. Utilisez des variables d’environnement pour transmettre les informations d’identification lorsque vous devez utiliser des valeurs différentes entre les étapes de planification et d’application.

Types de Backends

#

L’étiquette de bloc du bloc backend (“remote”, dans l’exemple ci-dessus) indique le type de backend à utiliser. Terraform dispose d’une sélection intégrée de backends, et le backend configuré doit être disponible dans la version de Terraform que vous utilisez.

Les arguments utilisés dans le corps du bloc sont spécifiques au type de backend choisi ; ils configurent où et comment le backend stockera l’état de la configuration, et dans certains cas configurent d’autres comportements.

Certains backends permettent de fournir des informations d’identification d’accès directement dans la configuration, dans des situations inhabituelles, pour des raisons pragmatiques. Cependant, dans une utilisation normale, nous ne recommandons pas d’inclure les informations d’identification d’accès dans la configuration du backend. Au lieu de cela, laissez ces arguments complètement non définis et fournissez les informations d’identification à l’aide des fichiers d’informations d’identification ou des variables d’environnement conventionnels pour le système cible, comme décrit dans la documentation de chaque backend.

Reportez-vous à la page de chaque type de backend pour plus de détails et pour les arguments de configuration propres à ce type.

Backend par défaut

#

Si une configuration n’inclut aucun bloc backend, Terraform utilise par défaut le backend local, qui stocke l’état sous forme de fichier simple dans le répertoire de travail actuel: .terraform/terraform.tfstate

Initialisation

#

Lorsque vous modifiez la configuration d’un backend, vous devez exécuter à nouveau terraform init pour valider et configurer le backend avant de pouvoir effectuer des plans, des applications ou des opérations sur l’état.

Après l’initialisation, Terraform crée un répertoire .terraform/ localement. Ce répertoire contient la configuration de backend la plus récente, y compris les paramètres d’authentification que vous avez fournis à la CLI Terraform.

La configuration de backend local est différente et entièrement séparée du fichier terraform.tfstate qui contient les données d’état de votre infrastructure réelle. Terraform stocke le fichier terraform.tfstate dans votre backend distant.

Lorsque vous changez de backend, Terraform vous donne la possibilité de migrer votre état vers le nouveau backend. Cela vous permet d’adopter des backends sans perdre l’état existant.

Important: Avant de migrer vers un nouveau backend, nous recommandons vivement de sauvegarder manuellement votre état en copiant votre fichier terraform.tfstate dans un autre emplacement.

Configuration partielle

#

Vous n’avez pas besoin de spécifier tous les arguments requis dans la configuration du backend. L’omission de certains arguments peut être souhaitable si certains arguments sont fournis automatiquement par un script d’automatisation exécutant Terraform. Lorsque certains ou tous les arguments sont omis, nous appelons cela une configuration partielle.

Avec une configuration partielle, les arguments de configuration restants doivent être fournis dans le cadre du processus d’initialisation.

Il existe plusieurs façons de fournir les arguments restants :

• Fichier : Un fichier de configuration peut être spécifié via la ligne de commande init. Pour spécifier un fichier, utilisez l’option -backend-config=PATH lors de l’exécution de terraform init. Si le fichier contient des secrets, il peut être conservé dans un magasin de données sécurisé, tel que Vault, auquel cas il doit être téléchargé sur le disque local avant d’exécuter Terraform.

• Paires clé/valeur en ligne de commande : Les paires clé/valeur peuvent être spécifiées via la ligne de commande init. Notez que de nombreux shells conservent les drapeaux de ligne de commande dans un fichier d’historique, il n’est donc pas recommandé d’utiliser cette méthode pour les secrets. Pour spécifier une seule paire clé/valeur, utilisez l’option -backend-config="KEY=VALUE" lors de l’exécution de terraform init.

• Interaction interactive : Terraform vous demandera de manière interactive les valeurs requises, sauf si l’entrée interactive est désactivée. Terraform ne vous demandera pas de valeurs optionnelles.

Si les paramètres du backend sont fournis à partir de plusieurs emplacements, les paramètres de niveau supérieur sont fusionnés de telle sorte que toutes les options en ligne de commande remplacent les paramètres de la configuration principale, puis les options en ligne de commande sont traitées dans l’ordre, les options ultérieures remplaçant les valeurs définies par les options antérieures.

La configuration finale et fusionnée est stockée sur le disque dans le répertoire .terraform, qui doit être ignoré par le contrôle de version. Cela signifie que les informations sensibles peuvent être exclues du contrôle de version, mais elles seront présentes en texte clair sur le disque local lors de l’exécution de Terraform.

Lors de l’utilisation d’une configuration partielle, Terraform exige au minimum qu’une configuration de backend vide soit spécifiée dans l’un des fichiers de configuration Terraform racine, pour spécifier le type de backend. Par exemple :

terraform {
  backend "consul" {}
}

Fichier

#

Un fichier de configuration de backend a le contenu du bloc backend comme attributs de niveau supérieur, sans avoir besoin de l’envelopper dans un autre bloc terraform ou backend :

address = "demo.consul.io"
path    = "example_app/terraform_state"
scheme  = "https"

Le modèle de nommage recommandé est *.backendname.tfbackend (par exemple, config.consul.tfbackend). Terraform ne vous empêchera pas d’utiliser d’autres noms, mais suivre cette convention permettra à votre éditeur de comprendre le contenu et fournira probablement une meilleure expérience d’édition en conséquence.

Paires clé/valeur en ligne de commande

#

Les mêmes paramètres peuvent également être spécifiés en ligne de commande comme suit :

$ terraform init \
    -backend-config="address=demo.consul.io" \
    -backend-config="path=example_app/terraform_state" \
    -backend-config="scheme=https"

Le backend Consul nécessite également un jeton d’accès Consul. Conformément à la recommandation précédente d’omettre les informations d’identification de la configuration et d’utiliser d’autres mécanismes, le jeton Consul serait fourni en définissant les variables d’environnement CONSUL_HTTP_TOKEN ou CONSUL_HTTP_AUTH. Consultez la documentation de votre backend choisi pour savoir comment fournir des informations d’identification à celui-ci en dehors de sa configuration principale.

Modification de la configuration

#

Vous pouvez modifier la configuration de votre backend à tout moment. Vous pouvez changer à la fois la configuration elle-même et le type de backend (par exemple, de “consul” à “s3”).

Terraform détectera automatiquement toute modification de votre configuration et demandera une réinitialisation. Dans le cadre du processus de réinitialisation, Terraform demandera si vous souhaitez migrer votre état existant vers la nouvelle configuration. Cela vous permet de basculer facilement d’un backend à un autre.

Si vous utilisez plusieurs espaces de travail, Terraform peut copier tous les espaces de travail vers la destination. Si Terraform détecte que vous avez plusieurs espaces de travail, il vous demandera si c’est ce que vous souhaitez faire.

Si vous ne faites que reconfigurer le même backend, Terraform vous demandera quand même si vous souhaitez migrer votre état. Vous pouvez répondre “non” dans ce scénario.

Désactivation d’un Backend

#

Si vous ne souhaitez plus utiliser de backend, vous pouvez simplement supprimer la configuration du fichier. Terraform détectera cela comme tout autre changement et vous demandera de réinitialiser.

Dans le cadre de la réinitialisation, Terraform demandera si vous souhaitez migrer à nouveau votre état vers l’état local normal. Une fois cela terminé, Terraform fonctionnera à nouveau comme il le fait par défaut.