Terragrunt s'attend à ce que vous exécutiez terragrunt et sous le capot, il exécute terraform des commandes, en transmettant TF_VAR_* variables d'environnement . TFC gère également terraform directement les commandes. Par conséquent, vous ne pouvez pas exécuter Terragrunt au sein de TFC - il n'exécutera pas la commande terragrunt binaire, seul le terraform binaire.
Toutefois, vous pouvez utiliser Terragrunt à partir de l'interface CLI pour exécuter des exécutions Terraform sur TFC à l'aide d'une commande backend distant . Dans ce mode, vous exécutez les commandes Terragrunt comme d'habitude, et lorsque Terraform est appelé, il s'exécute en fait dans TFC. Vous pouvez consulter les exécutions dans l'interface utilisateur de TFC, l'état est stocké dans TFC, etc. Cependant, en raison de la limitation décrite ci-dessus, vous ne pouvez pas réellement exécuter Terragrunt à partir de l'interface utilisateur.
Pour le mettre en place, vous devez d'abord obtenir un jeton d'API et configurer le CLI avec un credentials bloc en .terraformrc .
Ensuite, vous devrez générer a backend bloc :
generate "remote_state" {
path = "backend.tf"
if_exists = "overwrite_terragrunt"
contents = <<EOF
terraform {
backend "remote" {
hostname = "app.terraform.io" # Change this to your hostname for TFE
organization = "your-tfc-organization"
workspaces {
name = "your-workspace"
}
}
}
EOF
}
Ce code génère un fichier appelé backend.tf à côté de votre module Terraform. Ceci indique à Terraform d'utiliser TFC comme backend distant. Il utilisera un espace de travail appelé your-workspace . Si cet espace de travail n'existe pas, TFC le créera automatiquement à l'aide de la fonction création d'un espace de travail implicite . Vous aurez un espace de travail pour chaque module que vous appelez dans Terragrunt.
TFC ne prend pas en charge le TF_VAR_* variables d'environnement que Terraform "standard" prend en charge. Par conséquent, l'outil Terragrunt inputs qui est la méthode standard utilisée par Terragrunt pour transmettre des variables à Terraform, ne fonctionne pas.
Au lieu de cela, vous pouvez créer un *.auto.tfvars fichier . Vous pouvez également générer ce fichier dans Terragrunt :
generate "tfvars" {
path = "terragrunt.auto.tfvars"
if_exists = "overwrite"
disable_signature = true
contents = <<-EOF
name = "your-name"
EOF
}
Toutes les variables requises pour un module doivent être transmises dans le champ contents heredoc ci-dessus. Un modèle plus flexible consiste à utiliser un locals bloc pour configurer les variables, puis il suffit de les passer dans la fonction content bloc.
Un dernier problème est que lorsque l'espace de travail est créé automatiquement, il ne dispose pas des informations d'identification de l'API (par ex. AWS_ACCESS_KEY_ID y AWS_SECRET_ACCESS_KEY ) qui sont nécessaires pour s'interfacer avec le fournisseur de nuages. Vous pouvez définir cela dans la configuration du fournisseur en créant un fichier provider.tf mais les informations d'identification sont alors statiques et en texte clair. Ce n'est pas bon.
Au lieu de cela, vous pouvez soit définir manuellement les variables d'environnement dans chaque espace de travail, soit utiliser la fonction tfe_workspace y tfe_variable ressources pour les créer à l'avance avec Terraform. Cette dernière méthode est recommandée car elle est programmatique, ce qui facilite grandement la mise à jour si vous devez faire tourner vos références.
Dans les deux cas, vous devrez avoir un espace de travail pour chaque module appelé par Terragrunt.
Voir aussi : cet article de blog sur le sujet et ce contenu sur l'intégration avec Terragrunt.
