Variables spécifiques à l'environnement Terraform

Question

Quelqu'un sait-il s'il existe un moyen de renseigner des variables dans Terraform en fonction de l'environnement/espace de travail? De préférence, un qui

• remplit l'espace de noms var (et non d'une source de données externe),
• ne nécessite pas d'emballage
  • comme tf(){ terraform --var-file=$(get_tf_env).tfvars
• prend effet en changeant une terraform env/workspace, sans étapes manuelles supplémentaires (c'est-à-dire les étapes qui ne sont pas déclenchées par l'exécution de terraform env)?

Answer 1

Il n'y a pas de façon native de le faire avec Terraform que je connaisse. Si vous cherchez autour de vous verrez que beaucoup de gens auront différentes structures de dossiers pour les points d'entrée dans leurs configurations TF, chaque dossier différent peut avoir des valeurs différentes dans le fichier tfvars. Une option qui peut vous aider à utiliser Terraform Workspaces, introduite dans 0.10.

J'ai implémenté quelque chose de similaire à ce que vous suggérez en utilisant OctopusDeploy. Si vous ne l'avez pas déjà utilisé, Octopus est bon pour la gestion des variables spécifiques à l'environnement. J'ai un fichier tfvars par défaut et une liste de valeurs de variables correspondantes dans Octopus, par environnement.

J'ai une étape de base qui parcourt toutes les variables de tfvars et recherche une variable Octopus du même nom et la remplace si elle est trouvée.

J'ai trouvé que c'était un bon moyen de travailler car il donne une bonne séparation entre le fichier Terraform tfvars (quelles valeurs sont nécessaires) et les valeurs variables dans Octopus (quelles sont les valeurs réelles).

E.g. Si je le fichier contenant tfvars

instance_size = "Medium" 

Et je 2 environnements dans Octopus, Mise en scène et la production. Je peux ajouter une variable à Octopus appelée 'instance_size' et définir une valeur différente par environnement (par exemple "Big" et "Biggest" respectivement).

Le modèle étape j'ai écrit trouveront une valeur correspondantes pour les « instance_size » si cela veut dire que quand je le lance pour la mise en scène je recevrais:

instance_size = "Big" 

et pour la production

instance_size = "Biggest" 

Answer 2

Terraform workspaces

Un espace de travail est un conteneur nommé pour l'état Terraform. Avec plusieurs espaces de travail, un seul répertoire de configuration Terraform peut être utilisé pour gérer plusieurs ensembles distincts de ressources d'infrastructure.

Dans la version 0.9 des versions Terraform, ce concept était connu sous le nom de «environnement». Il a été renommé en 0.10 sur la base de commentaires sur la confusion causée par la surcharge du mot "environnement" à la fois dans Terraform lui-même et dans les organisations qui utilisent Terraform.

La référence à l'espace de travail actuel est utile pour modifier le comportement en fonction de l'espace de travail. Par exemple, pour les espaces de travail non définis par défaut, il peut être utile de générer des tailles de cluster plus petites. Par exemple:

resource "aws_instance" "example" { 
    count = "${terraform.workspace == "default" ? 5 : 1}" 

    # ... other arguments 
} 

Answer 3

Je recommande de prendre un « Stacks » approche basée pour votre projet Terraform afin que vous puissiez configurer et gérer le « Stacks » et l'État à distance par l'espace de travail (aka Environnement). Cela limite le rayon d'action de vos modifications du point de vue du risque, simplifie le flux de travail et fournit également une base de code plus propre et plus facile à maintenir.

Qu'est-ce qui rendra votre journée encore meilleure?

• Un design objectivement simple qui vous permet de raisonner sur la plate-forme et ses parties mobiles. (aka Stacks)
• Une implémentation qui vous offre de la flexibilité tout en limitant les risques de changements. (alias Limiter le rayon de souffle)
• Une solution qui offre de la valeur aujourd'hui et continue de s'améliorer tout en créant une dynamique à long terme. (Aka modèles, workflow)

Voici une liste rapide des bonnes pratiques

• Gérer "Etat" séparément pour "Stacks" à travers "Workspaces"

• Mettre en oeuvre « Stacks "pour une" configuration "cohérente à travers" Workspaces "

• Gardez-le objectif et simple avec de bons" Patterns "et" Workflow ".

Exemple Terraform projet en utilisant une approche fondée sur Stacks

/ 
    /scripts 
    <shell scripts> 
    <terraform wrapper functions> 

    /stacks 
    /application_1 # Provisions Application 1 and its dependencies 
    /application_2 # Provisions Application 2 and its dependencies 
    /application_n # Provisions Application N and its dependencies 
     backend.tf  # Remote State 
     data.tf   # Data Sources 
     stack.tf   # Stack Variables and Defaults 
     aws_resource.tf 
     ... 
     ...  
    /network # Provisions VPC, Subnets, Route Tables, Route53 Zones 
    /security # Provisions Security Groups, Network ACLs, IAM Resources 
    /storage # Provisions Storage Resources like S3, EFS, CDN 

    global.tf  # Global Variables 
    dev.tfvars # Development Environment Variables 
    tst.tfvars # Testing Environment Variables 
    stg.tfvars # Staging Environment Variables 
    prd.tfvars # Production Environment Variables 
    terraform.sh # Wrapper Script for Executing Terraform (Workflow) 

Quelques réflexions plus

À mesure que votre mise en œuvre se développe, il est beaucoup plus simple d'intégrer les exigences futures en piles existantes ou comme de nouvelles piles si elles sont une dépendance partagée. Terraform permet l'utilisation de l'état distant en tant que source de données. Configuration de votre propre sortie Les variables par pile rendent la configuration et l'utilisation des attributs de ressources exportées beaucoup plus propres. La configuration de votre projet pour que vous puissiez définir des variables et des valeurs par défaut raisonnables au niveau de la pile vous permet de les remplacer au niveau de l'espace de travail pour répondre aux exigences des différents environnements tels que Dev, Test, Production, etc. tout en gardant la configuration cohérente et l'état distant géré séparément par environnement.

Voici quelques-unes des pratiques que nous avons développées et déployées dans notre équipe pour améliorer notre expérience de travail avec Terraform pour gérer notre plate-forme AWS.

À la votre!