Je suis également en train de migrer l'infrastructure AWS existante vers Terraform, je vais donc essayer de mettre à jour la réponse au fur et à mesure de mon développement.
Je me suis fortement appuyé sur les exemples officiels de Terraform et sur de multiples essais et erreurs pour étoffer les domaines dans lesquels j'étais incertain.
.tfstate
des dossiers
Terraform config peut être utilisé pour provisionner de nombreuses boîtes sur différentes infrastructures, chacune pouvant avoir un état différent. Comme il peut également être exécuté par plusieurs personnes, cet état doit être dans un emplacement centralisé (comme S3) mais pas git.
Cela peut être confirmé en regardant le Terraform .gitignore
.
Contrôle développeur
Notre objectif est de fournir plus de contrôle de l'infrastructure aux développeurs tout en maintenant un audit complet (git log) et la possibilité de vérifier les modifications (pull requests). Dans cet esprit, le nouveau flux de travail d'infrastructure que je vise est:
- Base de base des AMI communes qui incluent des modules réutilisables, par exemple des marionnettes.
- Infrastructure de base fournie par DevOps à l'aide de Terraform.
- Les développeurs modifient la configuration de Terraform dans Git selon les besoins (nombre d'instances; nouveau VPC; ajout de région / zone de disponibilité, etc.).
- La configuration Git a été poussée et une demande d'extraction soumise à une vérification de validité par un membre de l'équipe DevOps.
- S'il est approuvé, appelle le webhook à CI pour créer et déployer (ne sait pas comment partitionner plusieurs environnements pour le moment)
Edit 1 - Mise à jour sur l'état actuel
Depuis que j'ai commencé cette réponse, j'ai écrit beaucoup de code TF et je me sens plus à l'aise dans notre situation. Nous avons rencontré des bogues et des restrictions en cours de route, mais j'accepte que ce soit une caractéristique de l'utilisation de nouveaux logiciels en évolution rapide.
Disposition
Nous avons une infrastructure AWS compliquée avec plusieurs VPC, chacun avec plusieurs sous-réseaux. La clé pour gérer facilement cela était de définir une taxonomie flexible qui englobe la région, l'environnement, le service et le propriétaire que nous pouvons utiliser pour organiser notre code d'infrastructure (à la fois terraform et marionnette).
Modules
L'étape suivante a été de créer un référentiel git unique pour stocker nos modules terraform. Notre structure de répertoire de niveau supérieur pour les modules ressemble à ceci:
tree -L 1 .
Résultat:
├── README.md
├── aws-asg
├── aws-ec2
├── aws-elb
├── aws-rds
├── aws-sg
├── aws-vpc
└── templates
Chacun définit des valeurs par défaut saines mais les expose comme des variables qui peuvent être écrasées par notre "glue".
La colle
Nous avons un deuxième référentiel avec notre glue
qui utilise les modules mentionnés ci-dessus. Il est présenté conformément à notre document de taxonomie:
.
├── README.md
├── clientA
│ ├── eu-west-1
│ │ └── dev
│ └── us-east-1
│ └── dev
├── clientB
│ ├── eu-west-1
│ │ ├── dev
│ │ ├── ec2-keys.tf
│ │ ├── prod
│ │ └── terraform.tfstate
│ ├── iam.tf
│ ├── terraform.tfstate
│ └── terraform.tfstate.backup
└── clientC
├── eu-west-1
│ ├── aws.tf
│ ├── dev
│ ├── iam-roles.tf
│ ├── ec2-keys.tf
│ ├── prod
│ ├── stg
│ └── terraform.tfstate
└── iam.tf
Au niveau du client, nous avons des .tf
fichiers spécifiques au compte AWS qui fournissent des ressources globales (comme les rôles IAM); Vient ensuite le niveau de la région avec les clés publiques EC2 SSH; Enfin , dans notre environnement ( dev
, stg
, prod
etc.) sont nos configurations de VPC, la création d'instance et de connexions de peering etc. sont stockés.
Note latérale: comme vous pouvez le voir, je vais à l'encontre de mes propres conseils ci-dessus en gardant terraform.tfstate
dans git. C'est une mesure temporaire jusqu'à ce que je passe à S3 mais me convient car je suis actuellement le seul développeur.
Prochaines étapes
Il s'agit toujours d'un processus manuel et pas encore dans Jenkins, mais nous portons une infrastructure assez grande et compliquée et jusqu'à présent tout va bien. Comme je l'ai dit, peu de bugs mais ça va bien!
Edit 2 - Modifications
Cela fait presque un an que j'ai écrit cette première réponse et l'état de Terraform et de moi-même a considérablement changé. Je suis maintenant à une nouvelle position en utilisant Terraform pour gérer un cluster Azure et Terraform l'est maintenant v0.10.7
.
Etat
Les gens m'ont dit à plusieurs reprises que l'État ne devrait pas entrer dans Git - et ils ont raison. Nous avons utilisé cela comme mesure provisoire avec une équipe de deux personnes qui reposait sur la communication et la discipline des développeurs. Avec une équipe plus importante et distribuée, nous exploitons désormais pleinement l'état distant dans S3 avec le verrouillage fourni par DynamoDB. Idéalement, cela sera migré vers consul maintenant, c'est la v1.0 pour couper les fournisseurs de cloud cross.
Modules
Auparavant, nous avons créé et utilisé des modules internes. C'est toujours le cas, mais avec l'avènement et la croissance du registre Terraform, nous essayons de les utiliser au moins comme base.
Structure des fichiers
La nouvelle position a une taxonomie beaucoup plus simple avec seulement deux environnements infx - dev
et prod
. Chacun a ses propres variables et sorties, réutilisant nos modules créés ci-dessus. Le remote_state
fournisseur aide également à partager les sorties des ressources créées entre les environnements. Notre scénario consiste en des sous-domaines de différents groupes de ressources Azure vers un TLD géré globalement.
├── main.tf
├── dev
│ ├── main.tf
│ ├── output.tf
│ └── variables.tf
└── prod
├── main.tf
├── output.tf
└── variables.tf
Planification
Encore une fois, avec les défis supplémentaires d'une équipe distribuée, nous sauvegardons désormais toujours notre sortie de la terraform plan
commande. Nous pouvons inspecter et savoir ce qui sera exécuté sans risque de changements entre les étapes plan
et apply
(bien que le verrouillage aide à cela). N'oubliez pas de supprimer ce fichier de plan car il pourrait contenir des variables "secrètes" en texte brut.
Dans l'ensemble, nous sommes très satisfaits de Terraform et continuons à apprendre et à nous améliorer grâce aux nouvelles fonctionnalités ajoutées.
Nous utilisons beaucoup Terraform et notre configuration recommandée est la suivante:
Disposition des fichiers
Nous vous recommandons fortement de stocker le code Terraform pour chacun de vos environnements (par exemple, stage, prod, qa) dans des ensembles séparés de modèles (et par conséquent, des
.tfstate
fichiers séparés ). Ceci est important pour que vos environnements séparés soient réellement isolés les uns des autres lors des modifications. Sinon, tout en jouant avec du code lors de la mise en scène, il est trop facile de faire exploser quelque chose en prod. Voir Terraform, VPC et pourquoi vous voulez un fichier tfstate par env pour une discussion colorée sur pourquoi.Par conséquent, notre disposition de fichier typique ressemble à ceci:
Tout le code Terraform pour le VPC de scène va dans le
stage
dossier, tout le code pour le VPC prod va dans leprod
dossier, et tout le code qui vit en dehors d'un VPC (par exemple les utilisateurs IAM, les sujets SNS, les compartiments S3) va dans leglobal
dossier .Notez que, par convention, nous divisons généralement notre code Terraform en 3 fichiers:
vars.tf
: Variables d'entrée.outputs.tf
: Variables de sortie.main.tf
: Les ressources réelles.Modules
En règle générale, nous définissons notre infrastructure dans deux dossiers:
infrastructure-modules
: Ce dossier contient de petits modules réutilisables et versionnés. Considérez chaque module comme un modèle pour créer une seule infrastructure, telle qu'un VPC ou une base de données.infrastructure-live
: Ce dossier contient l'infrastructure réelle en cours d'exécution, qu'il crée en combinant les modules dansinfrastructure-modules
. Considérez le code de ce dossier comme les maisons que vous avez construites à partir de vos plans.Un module Terraform est n'importe quel ensemble de modèles Terraform dans un dossier. Par exemple, nous pourrions avoir un dossier appelé
vpc
dansinfrastructure-modules
qui définit toutes les tables de routage, sous-réseaux, passerelles, ACL, etc. pour un seul VPC:Nous pouvons ensuite utiliser ce module dans
infrastructure-live/stage
etinfrastructure-live/prod
pour créer la scène et produire des VPC. Par exemple, voici ce queinfrastructure-live/stage/main.tf
pourrait ressembler:Pour utiliser un module, vous utilisez la
module
ressource et pointez sonsource
champ vers un chemin local sur votre disque dur (par exemplesource = "../infrastructure-modules/vpc"
) ou, comme dans l'exemple ci-dessus, une URL Git (voir les sources du module ). L'avantage de l'URL Git est que nous pouvons spécifier un git sha1 ou une balise (ref=v0.0.4
) spécifique . Désormais, non seulement nous définissons notre infrastructure comme un ensemble de petits modules, mais nous pouvons également mettre à jour ces modules et les mettre à jour ou les restaurer soigneusement si nécessaire.Nous avons créé un certain nombre de produits réutilisables, testés et documentés packages d'infrastructure pour créer des VPC, des clusters Docker, des bases de données, etc., et sous le capot, la plupart d'entre eux ne sont que des modules Terraform versionnés.
Etat
Lorsque vous utilisez Terraform pour créer des ressources (par exemple, des instances EC2, des bases de données, des VPC), il enregistre des informations sur ce qu'il a créé dans un
.tfstate
fichier. Pour apporter des modifications à ces ressources, tous les membres de votre équipe doivent avoir accès à ce même.tfstate
fichier, mais vous ne devez PAS l'archiver dans Git (voir ici pour une explication ).Au lieu de cela, nous vous recommandons de stocker les
.tfstate
fichiers dans S3 en activant Terraform Remote State , qui va automatiquement pousser / extraire les derniers fichiers chaque fois que vous exécutez Terraform. Assurez-vous d' activer la gestion des versions dans votre compartiment S3 afin de pouvoir revenir aux.tfstate
fichiers plus anciens au cas où vous corrompriez d'une manière ou d'une autre la dernière version. Cependant, une remarque importante: Terraform ne fournit pas de verrouillage . Donc, si deux membres de l'équipe courentterraform apply
en même temps sur le même.tfstate
fichier, ils peuvent finir par écraser les modifications de l'autre.Pour résoudre ce problème, nous avons créé un outil open source appelé Terragrunt , qui est un wrapper léger pour Terraform qui utilise Amazon DynamoDB pour fournir le verrouillage (qui devrait être totalement gratuit pour la plupart des équipes). Consultez Ajouter le verrouillage automatique de l'état à distance et la configuration à Terraform avec Terragrunt pour plus d'informations.
Lectures complémentaires
Nous venons de commencer une série d'articles de blog intitulée Un guide complet de Terraform qui décrit en détail toutes les meilleures pratiques que nous avons apprises pour utiliser Terraform dans le monde réel.
Mise à jour: la série d'articles de blog Guide complet de Terraform est devenue si populaire que nous l'avons développée dans un livre intitulé Terraform: Up & Running !
la source
remote config
si vous venez de vérifier vos configurations Terraform ou si vous souhaitez modifier une configuration distante précédente. Terraform 0.9 introduira le concept debackends
, ce qui simplifiera beaucoup de choses. Voir ce PR pour plus de détails.remote config
commande pour pointer sur l'état prod. En supposant un état différent par environnement. Est-ce correct? J'attends avec impatience la v0.9..tf
fichiers dans deux environnements différents, oui, vous devez exécuterremote config
chaque fois que vous basculez. Ceci est évidemment très sujet aux erreurs, donc je ne recommande pas d'utiliser cette technique. Au lieu de cela, consultez la disposition de fichier Terraform recommandée dans cet article de blog et comment utiliser les modules Terraform dans cet article de blog .Auparavant
remote config
autorisé, cela a maintenant été remplacé par " backends ", donc terraform remote n'est plus disponible.Consultez la documentation pour plus de détails.
la source
Couvert plus en profondeur par @Yevgeny Brikman mais répondant spécifiquement aux questions du PO:
Utilisez git pour les fichiers TF. Mais ne archivez pas les fichiers State (c'est-à-dire tfstate). Utilisez plutôt
Terragrunt
pour la synchronisation / le verrouillage des fichiers d'état sur S3.Non.
Oui
la source
Je sais qu'il y a beaucoup de réponses ici, mais mon approche est assez différente.
Modules
Gestion de l'environnement
IaC a rendu le processus SDLC pertinent pour la gestion de l'infrastructure et il n'est pas normal de s'attendre à avoir une infrastructure de développement ainsi que des environnements d'applications de développement.
Séparation des tâches
Si vous êtes dans une petite organisation ou que vous exécutez une infrastructure personnelle, cela ne s'applique pas vraiment, mais cela vous aidera à gérer vos opérations.
Cela aide également à résoudre les problèmes de publication, car vous constaterez que certaines ressources changent rarement tandis que d'autres changent tout le temps. La séparation élimine les risques et la complexité.
Cette stratégie établit des parallèles avec la stratégie multi-comptes d'AWS. Lisez pour plus d'informations.
CI / CD
C'est un sujet qui lui est propre, mais Terraform fonctionne très bien dans un bon pipeline. L'erreur la plus courante ici est de traiter l'IC comme une solution miracle. Techniquement, Terraform ne doit provisionner l'infrastructure qu'au cours des étapes d'un pipeline d'assemblage. Cela serait distinct de ce qui se passe dans les étapes de CI où l'on valide et teste généralement les modèles.
NB Écrit sur mobile, veuillez donc excuser toute erreur.
la source
Recommandations courantes pour structurer le code
Il est plus facile et plus rapide de travailler avec un plus petit nombre de ressources:
terraform plan
etterraform
apply effectuent tous deux des appels d'API cloud pour vérifier l'état des ressources.Le rayon de l'explosion est plus petit avec moins de ressources:
Démarrez votre projet en utilisant l'état distant:
tfstate
fichier dans git est un cauchemar.Essayez de pratiquer une structure cohérente et une convention de dénomination:
Gardez les modules de ressources aussi simples que possible.
Ne codez pas en dur les valeurs qui peuvent être transmises en tant que variables ou découvertes à l'aide de sources de données.
Utilisez des
data
sources et enterraform_remote_state
particulier comme un lien entre les modules d'infrastructure au sein de la composition.( article de référence: https://www.terraform-best-practices.com/code-structure )
Exemple:
NOTE: juste comme référence à ne pas suivre strictement puisque chaque projet a ses propres spécificités
la source
Je pense qu'il y a peu de bonnes pratiques à suivre lors de l'utilisation de terraform pour orchestrer l'infrastructure
Gérez plusieurs environnements
La plupart du temps, la méthode recommandée consiste à utiliser l '«espace de travail» de terraform pour gérer les multiples environnements, mais je pense que l'utilisation de l'espace de travail peut varier en fonction du mode de travail dans une organisation. L'autre consiste à stocker le code Terraform pour chacun de vos environnements (par exemple, stage, prod, QA) pour séparer les états de l'environnement. Cependant, dans ce cas, nous copions simplement le même code à plusieurs endroits.
J'ai suivi une approche différente pour gérer et éviter la duplication du même code terraform en conservant dans chaque dossier d'environnement car je pense que la plupart du temps, tout l'environnement serait à 90% identique.
Configuration liée aux environnements
Gardez la configuration et les paramètres liés à l'environnement séparés dans un fichier de variables et transmettez cette valeur pour configurer l'infrastructure. par exemple comme ci-dessous
dev.backend.tfvar
dev.variable.tfvar
Saut conditionnel de la partie infrastructure
Créez une configuration dans un fichier de variable spécifique à env et en fonction de cette variable, décidez de créer ou d'ignorer cette partie. De cette manière, en fonction des besoins, la partie spécifique de l'infrastructure peut être ignorée.
La commande ci-dessous est requise pour initialiser et exécuter les modifications infra pour chaque environnement, cd dans le dossier d'environnement requis.
la source
Je n'aime pas l'idée de sous-dossiers car cela entraînera des sources différentes par environnement et cela a tendance à dériver.
La meilleure approche est d'avoir une seule pile pour tous les environnements (disons dev, preprod et prod). Pour travailler sur un seul environnement, utilisez
terraform workspace
.Cela crée un nouvel espace de travail. Cela inclut un fichier d'état dédié et la variable que
terraform.workspace
vous pouvez utiliser dans votre code.De cette façon, vous obtiendrez des seaux appelés
après avoir appliqué aux espaces de travail ci-dessus (à utiliser
terraform workspace select <WORKSPACE>
pour changer d'environnement). Pour rendre le code même résistant à plusieurs régions, procédez comme suit:pour obtenir (pour la région us-east-1)
la source
Quelques bonnes pratiques Terraform à suivre:
Évitez le codage en dur: parfois, les développeurs ont créé manuellement des ressources directement. Vous devez marquer ces ressources et utiliser l'importation terraform pour les inclure dans les codes. Un échantillon:
account_number = "123456789012" account_alias = "mycompany"
Exécutez Terraform à partir d'un conteneur Docker: Terraform publie un conteneur Docker officiel qui vous permet de contrôler facilement la version que vous pouvez exécuter.
Il est recommandé d'exécuter le conteneur Terraform Docker lorsque vous définissez votre tâche de génération dans le pipeline CI / CD.
Pour en savoir plus, veuillez consulter mon blog: https://medium.com/tech-darwinbox/how-darwinbox-manages-infrastructure-at-scale-with-terraform-371e2c5f04d3
la source
J'aimerais contribuer à ce fil.
Dans certains cas particuliers, un accès manuel aux fichiers d'état Terraform sera requis. Des opérations telles que la refactorisation, la rupture de modifications ou la correction de défauts nécessiteront l'exécution d'opérations d'état Terraform par le personnel d'exploitation. Pour de telles occasions, prévoyez un accès contrôlé extraordinaire à l'état Terraform à l'aide d'un hôte bastion, d'un VPN, etc.
Consultez un blog de bonnes pratiques plus long qui couvre cela en détails, y compris des instructions pour les pipelines CI / CD.
la source
Si vous êtes toujours à la recherche de la meilleure solution, jetez un œil aux espaces de travail qui peuvent remplacer le maintien de différentes structures de dossiers d'environnement peuvent avoir des variables spécifiques à l'espace de travail.
Comme Yevgeniy Brikman l'a mentionné, il est préférable d'avoir une structure de modules.
la source
Utilisez le cloud terraform pour gérer et enregistrer les états, ainsi que les conseils ci-dessus.
la source