Devrais-je valider des fichiers .tfstate dans Git?

Question

Je suis un peu perplexe sur la question de savoir si de commettre .tfstate fichiers Git ou pas. Le Terraform documentation états:

Terraform également de l'état dans l' terraform.tfstate le fichier par défaut. Ce fichier d'état est extrêmement important; il cartes différentes métadonnées de ressources réelles Id de ressource, de sorte que Terraform sait ce que c'est de la gestion. Ce fichier doit être enregistré et distribué à une personne qui pourrait exécuter Terraform. Nous conseillons tout simplement de le mettre dans le contrôle de version, car il n'est généralement pas trop grand.

Maintenant, en revanche, accepté et upvoted réponse sur les Meilleures pratiques lors de l'utilisation de Terraform états:

Terraform config peut être utilisé à disposition beaucoup de boîtes sur les différentes infrastructures, ce qui aurait, dans 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.

(Les italiques par l'auteur original, pas par moi)

Qui est droit, et si oui, pourquoi?

Answer 1

Il ya quelques raisons de ne pas stocker votre .tfstate fichiers dans Git:

1. Vous êtes susceptible d'oublier de s'engager et de pousser vos modifications après l'exécution de l' terraform apply, de sorte que vos coéquipiers auront out-of-date, .tfstate fichiers. Aussi, sans verrouillage sur ces fichiers de l'état, si deux membres de l'équipe de courir transformer le terrain en même temps sur le même .tfstate fichiers, vous risquez d'écraser les uns des autres changements. Vous pouvez résoudre les deux problèmes à la fois) de stocker .tfstate fichiers dans un compartiment S3 à l'aide de Terraform à distance de l'état, qui va pousser/tirer l' .tfstate automatiquement les fichiers chaque fois que vous exécutez terraform apply , et b) à l'aide d'un outil comme terragrunt de fournir de verrouillage pour votre .tfstate fichiers.
2. L' .tfstate fichiers peuvent contenir des secrets. Par exemple, si vous utilisez le aws_db_instance de ressources, vous devez spécifier une base de données de mot de passe, et de transformer le terrain sera magasin qui, en clair, en .tfstate le fichier. C'est une mauvaise pratique sur Terraform nom pour commencer et stockage non chiffrés secrets dans le contrôle de version ne fait qu'empirer les choses. Au moins si vous stockez .tfstate fichiers dans S3, vous pouvez activer le chiffrement au repos (SSL fournit le cryptage, tout en mouvement) et de configurer IAM des politiques visant à limiter les droits d'accès. C'est très loin d'être idéale et nous allons voir si la voir ouvrir la question de discuter de ce problème à ce sujet n'est jamais fixe.

Pour plus d'infos, découvrez Comment gérer Terraform de l'état et de transformer le terrain: Haut & en cours d'Exécution.

Answer 2

Yevgeniy la réponse est bonne. La question est un peu moins controversée maintenant que Terraform ont mis à jour leurs docs de l'etat:

Terraform aussi met de l'etat dans le terraform.tfstate fichier par par défaut. Ce fichier d'état est extrêmement important; il cartes diverses les métadonnées de ressources réelles Id de ressource, de sorte que Terraform sait ce qu' il est le directeur. Ce fichier doit être enregistré et distribué à toute personne qui peut exécuter Terraform. Il est généralement recommandé pour le programme d'installation à distance de l'état lorsque vous travaillez avec des Terraform. Cela signifie que la possibilité de secrets stocké dans le fichier d'état de l', ne sera pas vérifiée dans le contrôle de version

Donc, il n'y a plus d'un désaccord entre les bonnes pratiques et les recommandations officielles.

Answer 3

C'est probablement à la baisse de préférence, mais je dirais git (ou de toute autre source de contrôle) n'est pas une option particulièrement intéressante pour le stockage de fichiers de l'état, car ils sont d'une sortie de code que vous écrivez comme un binaire compilé ou même minimisé JS ou MOINS compilé en CSS.

Sur le dessus de que les choses peuvent changer très rapidement dans les fichiers de l'état comme un résultat de choses en cours d'exécution plutôt que de choses que l'on a réellement changé dans le code qui rend le truc assez bizarre.

Cependant, vous avez besoin d'une manière de partager ces fichiers avec n'importe qui à distance les membres de l'équipe ou d'autres appareils si vous êtes en développement sur différents ordinateurs portables/ordinateurs. Vous voudrez aussi une certaine façon de stocker et de ces parce que tu vas avoir un vraie douleur si vous perdez un fichier d'état comme Terraform utilise les fichiers de l'état pour savoir quels sont les choses dont il a la charge afin de ne pas marcher sur les orteils de l'outillage.

Je dirais S3 est probablement le meilleur endroit où vous pouvez les mettre dès maintenant. C'est à peu près libre, la durabilité sont excellentes, tout comme la disponibilité, il y a une très bonne prise en charge native pour en transformer le terrain à l'aide de la télécommande de l'état de la ressource. Et probablement plus important encore, vous n'avez qu'à créer un compartiment S3 pour commencer. Avoir à construire un Consul ou etcd cluster d'abord sans Terraform (sinon vous avez un oeuf et de la poule problème de l'endroit où stockez-vous de l'état pour la création de ceux-là?) c'est un peu une douleur, même si vous avez l'intention d'utiliser l'un de ces produits.

Évidemment, si vous êtes en utilisant OpenStack puis Swift devrait faire une bonne alternative (bien que je n'ai pas utilisé). J'ai aussi utilisé pas Hashicorp de l' Atlas , mais si vous êtes heureux de payer pour ce service, il pourrait être tout aussi utile.

Answer 4

Je vois un avantage à partager terraform.tfstate par d'autres moyens, plutôt que de Git.

Par exemple, S3, Dropbox, etc.. (avec gestion des versions est activée).

Ensuite, il sera possible de faire la restauration de l'infrastructure précédent de l'état.

Par exemple, vous rollback référentiel de commettre B, dos à commettre A. Si terraform.tfstate est inchangé - terraform permettra de réfléchir à la manière de la restauration de toutes les choses que vous avez ajoutés au cours de commettre B. Et de restauration sera facile.

En cas terraform.tfstate a également été restaurée à commettre Un - alors terraform pense que terraform.tfstate la synchronisation de la configuration requise et ne s'appliquera pas la restauration de votre infrastructure.