Dois-je valider des fichiers .tfstate dans Git?
Je suis un peu perplexe sur la question de savoir si engager .tfstate fichiers vers Git ou non. La documentation Terraform indique:
Terraform a également mis un certain état dans le
terraform.tfstatefichier par défaut. Ce fichier d'état est extrêmement important; il mappe diverses métadonnées de ressource aux ID de ressource réels afin que Terraform sache ce qu'il gère. Ce fichier doit être enregistré et distribué à toute personne susceptible d'exécuter Terraform. Nous vous recommandons simplement de le placer dans le contrôle de version, car il n'est généralement pas trop volumineux.
Maintenant, d'autre part, la réponse acceptée et votée sur Meilleures pratiques lors de l'utilisation de Terraform indique:
La configuration Terraform peut être utilisée pour provisionner de nombreuses boîtes sur différentes infrastructures, chacune pouvant avoir un état différent. Comme il peut également être géré par plusieurs personnes, cet état devrait être dans un emplacement centralisé (comme S3) mais pas git.
(Souligné par l'auteur original, pas par moi)
Qui a raison et si oui, pourquoi?
TL; DR:
Important ! Le stockage dans le contrôle de code source pourrait exposer données potentiellement sensibles et risque d'exécuter Terraform contre une ancienne version de l'état. Ne le faites pas.
Terraform ne recommande plus de stocker l'état dans le contrôle de source. Vos "bonnes" options sont distantes ou locales.
L'État distant offre des avantages significatifs par rapport au local et au stockage dans le contrôle de source. Les détails de ceux-ci sont ci-dessous.
Réponse originale:
La réponse de Yevgeniy est bonne. Le problème est un peu moins controversé maintenant que Terraform a mis à jour ses documents pour indiquer:
Terraform place également un état dans le fichier terraform.tfstate par défaut. Ce fichier d'état est extrêmement important; il mappe diverses métadonnées de ressource aux ID de ressource réels afin que Terraform sache ce qu'il gère. Ce fichier doit être enregistré et distribué à toute personne susceptible d'exécuter Terraform. Il est généralement recommandé de configurer l'état à distance lorsque vous travaillez avec Terraform. Cela signifie que les secrets potentiels stockés dans le fichier d'état ne seront pas vérifiés dans le contrôle de version
Il n'y a donc plus de désaccord entre les meilleures pratiques établies et les recommandations officielles.
Mise à jour 2019-05-17
Dans la version la plus récente des documents cela a été changé pour dire:
... Cet état est stocké par défaut dans un fichier local nommé "terraform.tfstate", mais il peut également être stocké à distance, ce qui fonctionne mieux dans un environnement d'équipe. ...
Je ne m'attends pas à ce que les conseils reviennent jamais au contrôle de code source comme méthode préférée de stockage de l'état.
Malgré la citation des documents ci-dessus l'état distant est toujours bénéfique en tant que développeur solo
L'état à distance permet au développeur solo de:
- Travailler sur/exécuter leur code Terraform à partir de plusieurs appareils
- Sauvegardez et protégez facilement contre la perte du fichier d'état, selon le backend choisi
- Séparez les sections de leur architecture via sorties
- Crypter automatiquement le fichier d'état au repos , selon le backend choisi
Il y a plusieurs raisons de ne pas stocker votre .tfstate fichiers dans Git:
- Vous risquez d'oublier de valider et de pousser vos modifications après avoir exécuté
terraform apply, afin que vos coéquipiers soient obsolètes.tfstatedes dossiers. De plus, sans aucun verrouillage sur ces fichiers d'état, si deux membres de l'équipe exécutent Terraform en même temps sur le même.tfstatefichiers, vous pouvez remplacer les modifications les uns des autres. Vous pouvez résoudre les deux problèmes à la fois a) en stockant.tfstatefichiers dans un compartiment S3 en utilisant état distant Terraform , qui poussera/tirera le.tfstatefichiers automatiquement à chaque fois que vous exécutezterraform applyet b) en utilisant un outil comme terragrunt pour assurer le verrouillage de votre.tfstatedes dossiers. - Le
.tfstateles fichiers peuvent contenir des secrets. Par exemple, si vous utilisez la ressource aws_db_instance , vous devez spécifier un mot de passe de base de données et Terraform le stockera, en clair, dans le.tfstatefichier. C'est une mauvaise pratique au nom de Terraform pour commencer et le stockage de secrets non chiffrés dans le contrôle de version ne fait qu'empirer les choses. Au moins si vous stockez.tfstatefichiers dans S3, vous pouvez activer le chiffrement au repos (SSL fournit le chiffrement en mouvement) et configurer les stratégies IAM pour limiter les accès. C'est très loin d'être idéal et nous devrons voir si le voir problème ouvert discutant de ce problème à ce sujet est jamais résolu.
Pour plus d'informations, consultez Comment gérer l'état Terraform et Terraform: Up & Running.
Cela va probablement revenir à la préférence, mais je dirais que git (ou tout autre contrôle de source) n'est pas une option particulièrement bonne pour stocker des fichiers d'état car ils sont une sortie du code que vous écrivez un peu comme un binaire compilé ou même JS minimisé ou moins compilé en CSS.
En plus de cela, les choses peuvent changer assez rapidement dans les fichiers d'état en tant que sortie des choses en cours d'exécution plutôt que des choses réellement modifiées dans le code, ce qui rend le tout plutôt gênant.
Cependant, vous avez besoin d'un moyen de partager ces fichiers d'état avec les membres d'une équipe distante ou même d'autres appareils si vous développez sur différents ordinateurs portables/machines. Vous voudrez également un moyen de les stocker et de les sauvegarder, car vous allez avoir vraiment mal si vous perdez un fichier d'état car Terraform utilise les fichiers d'état pour déterminer ce qu'il gère afin de ne pas marcher sur les orteils de autre outillage.
Je dirais que S3 est probablement le meilleur endroit où vous pouvez les mettre en ce moment. C'est à peu près gratuit, la durabilité est excellente tout comme la disponibilité, il y a un très bon support natif pour cela dans Terraform en utilisant la ressource état distant . Et surtout, il vous suffit de créer un compartiment S3 pour commencer. Devoir construire un Consul ou etcd cluster d'abord sans Terraform (sinon vous avez un problème de poulet et d'oeufs où stockez-vous l'état pour les créer?) Est un peu une douleur même si vous avez l'intention d'utiliser l'un de ces produits.
Évidemment, si vous utilisez OpenStack, alors Swift devrait faire une bonne alternative (même si je ne l'ai pas utilisé). Je n'ai pas non plus utilisé Hashicorp Atlas mais si vous êtes heureux de payer pour ce service, il pourrait être tout aussi utile.
Je vois un avantage à partager terraform.tfstate par d'autres moyens, plutôt que Git.
Par exemple: S3, Dropbox, etc. (avec versioning activé)
Il sera alors possible de revenir à l'état d'infrastructure précédent.
Par exemple, vous restaurez le référentiel à partir de la validation B, retournez à la validation A. Si terraform.tfstate est inchangé - terraform pensera comment restaurer toutes les choses que vous avez ajoutées pendant la validation B. Et la restauration sera être facile.
Dans le cas où terraform.tfstate a également été annulé pour valider A - alors terraform pensera que terraform.tfstate est synchronisé avec la configuration requise et n'appliquera pas la restauration à votre infrastructure .