Terraform-Module verstehen - AWS Präskriptive Leitlinien

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Terraform-Module verstehen

Im Bereich Infrastructure as Code (IaC) ist ein Modul ein eigenständiger Codeblock, der isoliert und zur Wiederverwendung zusammengepackt wird. Das Konzept der Module ist ein unausweichlicher Aspekt der Terraform-Entwicklung. Weitere Informationen finden Sie unter Module in der Terraform-Dokumentation. AWS CloudFormation unterstützt auch Module. Weitere Informationen finden Sie unter Einführung in AWS CloudFormation Module im AWS Cloud Operations and Migrations Blog.

Der Hauptunterschied zwischen Modulen in Terraform besteht CloudFormation darin, dass CloudFormation Module mithilfe eines speziellen Ressourcentyps () importiert werden. AWS::CloudFormation::ModuleVersion In Terraform hat jede Konfiguration mindestens ein Modul, das als Root-Modul bezeichnet wird. Terraform-Ressourcen, die sich in der main.tf-Datei oder in Dateien in einer Terraform-Konfigurationsdatei befinden, werden als im Root-Modul befindlich betrachtet. Das Root-Modul kann dann andere Module aufrufen, um sie in den Stack aufzunehmen. Das folgende Beispiel zeigt ein Root-Modul, das mithilfe des Open-Source-EKS-Moduls einen Amazon Elastic Kubernetes Service (Amazon EKS) -Cluster bereitstellt.

terraform { required_providers { helm = { source = "hashicorp/helm" version = "2.12.1" } } required_version = ">= 1.2.0" } module "eks" { source = "terraform-aws-modules/eks/aws" version = "20.2.1" vpc_id = var.vpc_id } provider "helm" { kubernetes { host = module.eks.cluster_endpoint cluster_ca_certificate = base64decode(module.eks.cluster_certificate_authority_data) } }

Möglicherweise haben Sie bemerkt, dass die obige Konfigurationsdatei den Provider nicht enthält. AWS Das liegt daran, dass Module eigenständig sind und ihre eigenen Anbieter enthalten können. Da Terraform-Anbieter global sind, können Anbieter aus einem untergeordneten Modul im Root-Modul verwendet werden. Dies gilt jedoch nicht für alle Modulwerte. Andere interne Werte innerhalb eines Moduls sind standardmäßig nur auf dieses Modul beschränkt und müssen als Ausgaben deklariert werden, damit sie im Root-Modul zugänglich sind. Sie können Open-Source-Module nutzen, um die Erstellung von Ressourcen innerhalb Ihres Stacks zu vereinfachen. Das eks-Modul leistet beispielsweise mehr als die Bereitstellung eines EKS-Clusters — es stellt eine voll funktionsfähige Kubernetes-Umgebung bereit. Wenn Sie es verwenden, müssen Sie nicht Dutzende zusätzlicher Codezeilen schreiben, vorausgesetzt, die Konfiguration des EKS-Moduls entspricht Ihren Anforderungen.

Module aufrufen

Zwei der wichtigsten Terraform-CLI-Befehle, die Sie während der Terraform-Bereitstellung ausführen, sind terraform init und terraform apply. Einer der Standardschritte, die der terraform init Befehl ausführt, besteht darin, alle untergeordneten Module zu suchen und sie als Abhängigkeiten in das Verzeichnis zu importieren. .terraform/modules Wenn Sie während der Entwicklung ein neues Modul aus externen Quellen hinzufügen, müssen Sie es erneut initialisieren, bevor Sie den apply Befehl verwenden können. Wenn Sie einen Verweis auf ein Terraform-Modul hören, bezieht sich das auf die Pakete in diesem Verzeichnis. Genau genommen ist das Modul, das Sie in Ihrem Code deklarieren, das aufrufende Modul. In der Praxis ruft das Schlüsselwort module also das eigentliche Modul auf, das als Abhängigkeit gespeichert ist.

Auf diese Weise dient das aufrufende Modul als prägnantere Darstellung des vollständigen Moduls, das bei der Bereitstellung ersetzt werden muss. Sie können sich diese Idee zunutze machen, indem Sie Ihre eigenen Module innerhalb Ihrer Stacks erstellen, um logische Trennungen von Ressourcen zu erzwingen, indem Sie beliebige Kriterien verwenden. Denken Sie daran, dass das Endziel dabei darin bestehen sollte, die Komplexität Ihres Stacks zu reduzieren. Da die gemeinsame Nutzung von Daten zwischen Modulen erfordert, dass Sie diese Daten innerhalb des Moduls ausgeben, kann es manchmal zu kompliziert werden, wenn Sie sich zu stark auf Module verlassen.

Das Root-Modul

Da jede Terraform-Konfiguration mindestens ein Modul hat, kann es hilfreich sein, die Moduleigenschaften des Moduls zu untersuchen, mit dem Sie sich am häufigsten befassen werden: des Root-Moduls. Wann immer Sie an einem Terraform-Projekt arbeiten, besteht das Root-Modul aus allen .tf (oder.tf.json) Dateien in Ihrem Verzeichnis auf oberster Ebene. Wenn Sie terraform apply in diesem Verzeichnis der obersten Ebene ausführen, versucht Terraform, jede Datei auszuführen, die es dort findet. .tf Alle Dateien in Unterverzeichnissen werden ignoriert, es sei denn, sie werden in einer dieser Konfigurationsdateien der obersten Ebene aufgerufen.

Dies bietet eine gewisse Flexibilität bei der Strukturierung Ihres Codes. Dies ist auch der Grund, warum es genauer ist, Ihre Terraform-Bereitstellung als Modul als als Datei zu bezeichnen, da mehrere Dateien an einem einzigen Prozess beteiligt sein können. Es gibt eine Standardmodulstruktur, die Terraform als Best Practices empfiehlt. Wenn Sie jedoch eine .tf Datei in Ihrem Verzeichnis auf oberster Ebene ablegen würden, würde sie zusammen mit den übrigen Dateien ausgeführt. Tatsächlich werden alle .tf Dateien der obersten Ebene in einem Modul bereitgestellt, wenn Sie es ausführen. terraform apply Welche Datei wird also zuerst von Terraform ausgeführt? Die Antwort auf diese Frage ist sehr wichtig.

Es gibt eine Reihe von Schritten, die Terraform nach der Initialisierung und vor der Stack-Bereitstellung ausführt. Zuerst werden die vorhandenen Konfigurationen analysiert und dann wird ein Abhängigkeitsdiagramm erstellt. Das Abhängigkeitsdiagramm bestimmt, welche Ressourcen benötigt werden und in welcher Reihenfolge sie adressiert werden sollten. Ressourcen, die Eigenschaften enthalten, auf die in anderen Ressourcen verwiesen wird, würden beispielsweise vor ihren abhängigen Ressourcen behandelt. In ähnlicher Weise würden Ressourcen, die mithilfe des depends_on Parameters explizit Abhängigkeit deklarieren, erst nach den Ressourcen behandelt, die sie angeben. Wenn möglich, kann Terraform Parallelität implementieren und gleichzeitig unabhängige Ressourcen verarbeiten. Sie können das Abhängigkeitsdiagramm vor der Bereitstellung mit dem Befehl terraform graph sehen.

Nachdem das Abhängigkeitsdiagramm erstellt wurde, bestimmt Terraform, was während der Bereitstellung getan werden muss. Es vergleicht das Abhängigkeitsdiagramm mit der neuesten Statusdatei. Das Ergebnis dieses Prozesses wird als Plan bezeichnet und ist einem CloudFormation Änderungssatz sehr ähnlich. Sie können den aktuellen Plan mit dem Befehl Terraform Plan anzeigen.

Als bewährte Methode wird empfohlen, so nah wie möglich an der Standardmodulstruktur zu bleiben. In Fällen, in denen Ihre Konfigurationsdateien zu lang werden, um sie effizient zu verwalten, und logische Trennungen die Verwaltung vereinfachen könnten, können Sie Ihren Code auf mehrere Dateien verteilen. Denken Sie daran, wie das Abhängigkeitsdiagramm und der Planungsprozess funktionieren, damit Ihre Stacks so effizient wie möglich ausgeführt werden.