Terraforme aide les développeurs à construire et à modifier l'infrastructure de manière sûre et efficace.

Il fonctionne avec Amazon Web Services (AWS) en tant que Partenaire de technologie avancée du réseau de partenaires AWS et aide les entreprises à “créer, mettre à jour et versionner [their] Infrastructure d'Amazon Web Services.

Dans cet article, vous apprendrez :

  • Comment tirer parti d'un fichier d'état distant dans Terraform
  • Comment configurer le backend
  • Comment diviser l'infrastructure mise en œuvre en composants distincts

Stockage sécurisé des informations d'état

Sans configuration appropriée, Terraform stocke l'état d'une infrastructure implémentée dans un fichier qu'il crée lors du lancement d'une opération d'application, à savoir terraform.tfstate dans le répertoire racine du projet.

Cependant, un fichier local n'est pas la meilleure idée, surtout lorsque nous effectuons des opérations Terraform à partir d'ordinateurs différents ou si chaque membre de l'équipe travaillant ensemble sur le projet veut profiter de ces opérations.

Bien sûr, on peut supposer que le système de contrôle de version sera utilisé et que les modifications seront entrées dans le référentiel. Cependant, cela n'est pas sûr et ne protège pas contre l'initiation de modifications en même temps par deux personnes différentes ou, pire, contre l'exploitation d'un fichier d'état obsolète.

Le plus souvent, ce problème est résolu en utilisant le soi-disant backend, c'est-à-dire le maintien de l'état dans un stockage distant, dont l'accès est disponible pour tous les membres de l'équipe et contrôlé lors de l'utilisation de Terraform.

Cet article présente une implémentation avec l'utilisation de Services Web Amazonc'est-à-dire le stockage S3 et la base de données DynamoDB.

Cela signifie qu'un ou plusieurs compartiments dans le magasin S3 sont utilisés pour stocker le ou les fichiers, ce qui éliminera une situation dans laquelle divers membres de l'équipe possèdent un état obsolète de Terraform.

À son tour, l'accès à cet état est contrôlé par un objet approprié (verrou) dans la table DynamoDB. Chaque tentative d'opérer sur une infrastructure gérée par Terraform va “prendre le contrôle” du verrou, ce qui empêchera d'autres de démarrer des opérations en même temps.

Hostersi estime que le principe DevOps ne serait pas DevOps s'il n'automatisait pas l'opération de création des ressources nécessaires à l'opération décrite ci-dessus.

Automatisation de la configuration d'un stockage backend

Étant donné que, dans ce cas, le fournisseur de services est AWS, nous exécutons le fournisseur avec des options de base (le profil constitue le nom de profil spécifié dans les informations d'identification de configuration AWS) :

Comment tirer parti d'un fichier d'état distant dans l'environnement Terraform

le seau en S3dans lequel les fichiers d'état Terraform seront placés, doit remplir les conditions suivantes :

  • Être crypté
  • Posséder le versionnage activé
  • Ne pas autoriser la suppression manuelle

Le code ci-dessous fournit une clé KMS utilisée pour le chiffrement et le seau lui-même :

Comment tirer parti d'un fichier d'état distant dans l'environnement Terraform

Dans le code ci-dessus, l'option permettant de définir un préfixe (Bucket_prefix) a été utilisée à la place d'un nom de compartiment ; dans ce cas, le nom sera complété par un identifiant numérique généré, facilitant la création d'un bucket unique.

Il s'agit d'une option recommandée en raison du fait que les noms dans S3 sont globalement uniques à l'échelle de l'ensemble de S3, et non d'un seul compte.

La configuration est en outre accompagnée de la ligne force_destroy = vrai – Cette facilitation technique permettra à Terraform de détruire l'opération pour supprimer le bucket si des fichiers s'y trouvent. À la fin du code, il a été assuré que le nom du bucket sera exporté.

UNE Table DynamoDB y compris un verrou est configuré de manière assez similaire, bien que :

  • Le nom de la table peut être personnalisé
  • Il doit y avoir un attribut nommé ID de verrouillage du chaîne de caractères type (Terraform y fera référence),
  • Le minimum red_capacity et capacité_écriture Doit être réglé.

Les recommandations ci-dessus seront implémentées à l'aide du code :

Comment tirer parti d'un fichier d'état distant dans l'environnement Terraform

Le code ci-dessus contient des références au nom_déploiement variable, afin de maintenir la convention de nommage et de permettre une situation dans laquelle un compte est utilisé par plusieurs environnements (bien que nous vous recommandons d'ouvrir des comptes séparés dans ce cas !).

Comme avant, nous nous assurons que le nom de la serrure sera exporté.

Comment tirer parti d'un fichier d'état distant dans l'environnement Terraform : notes techniques

Le backend est initialement configuré à l'aide d'un fichier d'état local. Bien qu'il soit également possible de transférer l'état exécuté ci-dessus vers le backend, HashiCorp, la société qui a créé Terraform, propose que l'infrastructure backend de base soit simplement enregistrée dans le référentiel sous contrôle de version.

Cela est dû au fait qu'il sera très rarement nécessaire de modifier précisément ce composant d'infrastructure (plutôt que pour la destruction), et la séparation du projet réel est tout à fait conseillée.

Configuration du backend dans un nouvel environnement

Pour l'environnement, ou un composant déjà destiné à tirer profit du backend, nous complétons la configuration avec des données issues de l'infrastructure implémentée :

Comment tirer parti d'un fichier d'état distant dans l'environnement Terraform

Le code présenté nécessite quelques commentaires :

  • Le paramètre de clé défini détermine la clé dans laquelle les fichiers d'état seront enregistrés (il peut être considéré comme un dossier dans le bucket). Cela permettra d'utiliser le même backend avec divers composants d'infrastructure.
  • Le paramètre region détermine la région dans laquelle le compartiment a été créé. Ce sont des objets globaux mais qui existent dans une région respective.
  • Malheureusement, les paramètres backend ne peuvent pas être définis comme des variables ni être calculés sur la base de plusieurs variables. Cela est dû au fait que le backend est configuré très tôt lors du processus de lancement de Terraform et que l'interpolation variable n'est pas encore disponible.

Comment tirer parti d'un fichier d'état distant dans l'environnement Terraform

La seule façon d'automatiser est d'utiliser Terraform initialiser opération avec des paramètres qui peuvent être définis dans le script de démarrage, comme dans l'exemple ci-dessus.

Partage d'informations sur les ressources entre des composants lancés séparément

L'utilisation d'un backend distant nous permet d'obtenir des avantages supplémentaires.

Grâce à cela, il est possible de diviser l'infrastructure implémentée en composants séparés, dont chacun possède son propre état dans une clé séparée et en même temps peut tirer parti des informations contenues dans les fichiers d'état des autres composants, s'ils utilisent le même backend. Cette méthode s'appelle état_distant.

Par conséquent, nous définissons séparément le composant responsable de la mise en œuvre (et de la maintenance) de l'infrastructure réseau (réseau VPC, sous-réseaux, routes de routage, passerelle, etc.) et séparément le composant responsable de la configuration du domaine (dans le cas d'AWS – Route53) ou des machines virtuelles (de même – EC2).

La structure qui permet la mise en œuvre d'une telle tâche est une source de données nommée terraform_remote_state. La source de données n'est pas une ressource en soi, c'est-à-dire que la définir ne créera pas de ressource, mais cela va se traduire par une tentative de téléchargement des données la concernant, si elle existe.

Terraform_remote_statecomme son nom l'indique, télécharge les données d'un autre fichier d'état Terraform (qui ont été définis comme des sorties).

La situation est mieux illustrée par l'exemple suivant (quelque peu idéalisé):

Comment tirer parti d'un fichier d'état distant dans l'environnement Terraform

Dans l'exemple présenté, la source de données (data) nommée “net” nous permet de télécharger des données à partir de la clé deploy1/net, dans laquelle un réseau VPC a été créé avec un sous-réseau, et le vpc_id également assubnet_id ont été fournis en sortie.

Ensuite, dans l'environnement actuel, une machine EC2 est créée dans le réseau, dont l'ID est téléchargé précisément depuis terraform_remote_state.

Récapitulatif : ce que nous avons fait avec un état distant dans l'environnement Terraform

A l'aide du code présenté, on peut automatiser la mise en place des éléments nécessaires au fonctionnement d'un backend, c'est-à-dire un stockage distant sur le fichier d'état de l'infrastructure géré par Terraform.

Grâce à ça:

  • Toutes les personnes impliquées dans le travail sur l'infrastructure possèdent l'état actuel de Terraform
  • L'accès à cet état est contrôlé, et toute tentative d'intervention sur l'infrastructure gérée par Terraform va « reprendre » le verrou, ce qui empêchera d'autres de démarrer des opérations en même temps.
  • Il est possible de diviser l'infrastructure en parties (composants), chacune pouvant obtenir des informations sur l'état des autres composants.

Bonne Terraformation !