De mes connaissances actuelles, il n'y a aucune raison .terraform.lock.hcl doit être inclus dans le .gitignore . Rien sur ce fichier n'est privé, ou n'y a-t-il?
3 Réponses :
par la documentation Terraform sur le fichier de verrouillage de dépendance :
terraform crée ou met automatiquement à jour le fichier de verrouillage de dépendance Chaque fois que vous exécutez la commande Terraform init. Vous devriez inclure ceci fichier dans votre référentiel de contrôle de version afin que vous puissiez discuter Modifications potentielles à vos dépendances externes via l'examen du code, juste Comme vous discuteriez des modifications potentielles de votre configuration elle-même.
La clé pour comprendre pourquoi vous devez commettre ce fichier se trouve dans la section suivante sur le comportement d'installation de la dépendance:
Quand Terraform Init travaille à l'installation de tous les fournisseurs nécessaire pour une configuration, terraform considère à la fois la version contraintes dans la configuration et les sélections de versions enregistrées Dans le fichier de verrouillage .
Si un fournisseur particulier n'a pas de sélection enregistrée existante, terraform sélectionnera la dernière version disponible qui correspond au Contrainte de version, puis mettez à jour le fichier de verrouillage pour inclure cela sélection.
Si un fournisseur particulier a déjà une sélection enregistrée dans la serrure Fichier, Terraform réélectionnera toujours cette version pour l'installation, Même si une version plus récente est devenue disponible . Vous pouvez remplacer cela comportement en ajoutant l'option -upgrade lorsque vous exécutez Terraform init, dans Quel cas Terraform ne tiendra pas compte des sélections existantes et une fois Sélectionnez à nouveau la dernière version disponible correspondant à la version contrainte.
essentiellement, il est destiné à ce que Terraform continue d'utiliser la version du fournisseur sélectionné lorsque vous l'avez ajouté. Si vous ne vérifiez pas le fichier de verrouillage, vous serez toujours automatiquement mis à niveau vers la dernière version qui obéit à la contrainte du code, ce qui pourrait conduire à des conséquences imprévues.
Remarque: Vous pouvez forcer Terraform à mettre à niveau lorsque L'appel init en passant l'indicateur -upgrade
terraform providers lock \ -platform=windows_amd64 \ # 64-bit Windows -platform=darwin_amd64 \ # 64-bit macOS -platform=linux_amd64 # 64-bit Linux Copy
mise à jour du développement multiplateforme
de la documentation Terraform sur Le Commandement de verrouillage des fournisseurs :
Spécification des plates-formes cibles dans votre environnement Vous pouvez, par exemple, ont les deux développeurs qui travaillent avec votre configuration Terraform sur leurs postes de travail Windows ou macOS et systèmes automatisés qui s'appliquent la configuration tout en fonctionnant sur Linux.
Dans cette situation, vous pouvez choisir de vérifier que tous vos Les fournisseurs prennent en charge toutes ces plates-formes et pour pré-populer la serrure dossier avec les sommes de contrôle nécessaires, en exécutant le verrouillage des fournisseurs de terraform et spécifier ces trois plates-formes:
terraform init -upgrade
L'exemple ci-dessus utilise la syntaxe d'emballage de shell de style Unix pour la lisibilité. Si vous courez
La commande sur Windows vous devrez ensuite remplacer les barres arrière par des carets (pour cmd ) ou des backticks (pour PowerShell).
vous devez donc vérifier le fichier de verrouillage dans le contrôle de la version, mais vous devez vous assurer que le fichier de verrouillage contient les sommes de contrôle pour les fournisseurs sur toutes les plates-formes.
Il y a des considérations spéciales si vous avez plusieurs personnes dans une équipe qui utilisent Mac / Linux / Windows et que vous essayez de partager un fichier de verrouillage unique github.com/hashicorp/terraform/issues/28041
Qu'en est-il lorsque vous utilisez Terraform Cloud? Ne serait-il pas nécessaire dans ce cas?
Je pense que les conseils ci-dessus ne sont utiles que si votre référentiel de contrôle source est utilisé par un ensemble homogène d'ingénieurs et / ou un seul ingénieur. Sur un grand groupe hétérogène, il échouera avec l'erreur suivante:
│ Error: Failed to install provider │ │ Error while installing hashicorp/null v3.1.1: the local package for registry.terraform.io/hashicorp/null 3.1.1 doesn't match any of the checksums previously recorded in the dependency lock file │ (this might be because the available checksums are for packages targeting different platforms)
Pour résoudre cette erreur, supprimez le fichier .terraform.lock.hcl et réinitialisez. Il régénera le fichier pour votre propre poste de travail.
Je suis prêt à divertir que nous le faisons mal, mais au moins dans notre cas, nous devons l'ajouter à .gitignore, ou chaque fois L'ingénieur se engage, tous les ingénieurs utilisant un système d'exploitation différent obtiendront cette erreur et devront à nouveau terraform init .
Vous pouvez également exécuter la commande suivante pour établir avec des plates-formes est présente dans votre environnement:
terraform providers lock -platform=darwin_amd64 -platform=darwin_arm64 -platform=linux_amd64
Il doit être engagé: il est nécessaire pour conserver les versions des plugins en synchronisation.
La confidentialité semble être un critère étrange. Pour moi, la raison de .gitignore est qu'il y a des fichiers (éditeurs temporaires, sauvegardes, sortie de build, source générée) que je ne veux pas être conservé dans le repo.
Ma préoccupation est à la fois des fichiers de confidentialité et indésirables dans le dépôt en général.
Comme je n'ai pas assez de réputation, je ne suis pas en mesure de commenter. Comme zerkms a déclaré que cela devrait être engagé pour la synchronisation du plugin. Traitez-le comme un package.lock (ou similaire pour d'autres langues ... Composer.Lock, cargo-lock ...)
Ceci est entièrement basé sur le flux de travail et le style de collaboration de votre équipe, ainsi que sur les gammes que vous spécifiez dans vos versions de fournisseur. Si les versions sont vastes, vous devriez probablement le commettre. Si l'équipe est moins pratique, alors vous devriez probablement le commettre. Ce serait le même raisonnement derrière d'autres fichiers
.lockpour d'autres langues.Pour moi, c'est toujours différent parce que j'utilise un Mac (Office) et Linux (PC domestique, ordinateur portable) alternativement, donc j'exclus ce fichier de verrouillage du référentiel.
@Zoltanszabo: Cela signifie-t-il que le
.terraform.lock.hcln'est pas compatible en plateforme? Je suppose que le fichier lui-même est compatible, mais les binaires du fournisseur ne le sont évidemment pas - Terraform ne détecte-t-il pas le système d'exploitation et ne sélectionne-t-il pas? Jamais utilisé TF sur Linux, c'est pourquoi je demande ...@iggy Si nous étirons la définition de la «confidentialité» pour inclure les préoccupations liées à la sécurité, qu'en est-il des fichiers de points comme
.envqui pourraient contenir des variables d'environnement liées à l'authentification? Nous ne voudrions pas que des fichiers comme celui-ci soient conservés dans le dépôt pour des raisons de "confidentialité", dans le sens où je veux garder mes clés API privées.Vous pouvez également utiliser tfenv et .terraform-version plutôt pour contrôler la version de votre terraform