arrow-left

Only this pageAll pages
gitbookPowered by GitBook
1 of 15

Deutsch (German)

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Willkommen

Dieses Dokument ist ein Versuch, die besten Praktiken bei der Verwendung von Terraform systematisch zu beschreiben und Empfehlungen für die häufigsten Probleme zu geben.

Terraformarrow-up-right ist ein relativ neues Projekt (wie die meisten DevOps-Tools), das 2014 gestartet wurde.

Terraform ist leistungsfähig (wenn nicht sogar das leistungsfähigste, das es derzeit gibt) und eines der am häufigsten verwendeten Tools, das die Verwaltung der Infrastruktur als Code ermöglicht. Es erlaubt Entwicklern eine Menge Dinge zu tun und schränkt sie nicht ein, Dinge zu tun, die schwer zu unterstützen oder zu integrieren sind.

Einige der in diesem Buch beschriebenen Informationen mögen nicht als die besten Praktiken erscheinen. Ich weiß das, und um den Lesern zu helfen, zu unterscheiden, was bewährte Praktiken sind und was nur eine andere Art ist, Dinge zu tun, verwende ich manchmal Hinweise, um etwas Kontext zu liefern, und Symbole, um den Reifegrad jedes Unterabschnitts in Bezug auf bewährte Praktiken anzugeben.

Das Buch ist 2018 im sonnigen Madrid entstanden und ist hier kostenlos erhältlich - https://www.terraform-best-practices.com/arrow-up-right .

Ein paar Jahre später wurde es mit mehr aktuellen Best Practices aktualisiert, die mit Terraform 1.0 verfügbar waren. Letztendlich sollte dieses Buch die meisten der unbestrittenen besten Praktiken und Empfehlungen für Terraform-Nutzer enthalten.

hashtag
Sponsoren

Please if you want to become a sponsor.

hashtag
Übersetzungen

Kontaktieren Sie mich, wenn Sie bei der Übersetzung dieses Buches in andere Sprachen helfen wollen.

hashtag
Beiträge

Ich möchte immer Rückmeldungen erhalten und dieses Buch aktualisieren, wenn die Gemeinschaft reift und neue Ideen umgesetzt und überprüft werden.

Wenn Sie an bestimmten Themen interessiert sind, oder bewerten Sie ein Issue mit einem Daumen-hoch, von dem Sie möchten, dass es am meisten behandelt werden soll. Wenn Sie das Gefühl haben, dass Sie Inhalte haben und einen Beitrag leisten wollen, schreiben Sie einen Entwurf und reichen Sie einen Pull Request ein (machen Sie sich zu diesem Zeitpunkt keine Sorgen über einen guten Textstil!)

hashtag
Autoren

Dieses Buch wird von mit Hilfe verschiedener Mitwirkender und Übersetzer gepflegt.

hashtag
Lizenzen

Dieses Projekt steht unter der Apache-2-Lizenz. Siehe LICENSE für weitere Details.

Die Autoren und Mitwirkenden an diesem Inhalt können die Gültigkeit der hier gefundenen Informationen nicht garantieren. Bitte vergewissern Sie sich, dass Sie verstehen, dass die hier zur Verfügung gestellten Informationen frei zur Verfügung gestellt werden und dass keine Art von Vereinbarung oder Vertrag zwischen Ihnen und Personen, die mit diesem Inhalt oder Projekt in Verbindung stehen, entsteht. Die Autoren und Mitwirkenden übernehmen keine Haftung für Verluste, Schäden oder Störungen, die durch Fehler oder Auslassungen in den Informationen verursacht werden, die in diesem Inhalt enthalten sind, mit ihm in Verbindung stehen oder mit ihm verlinkt sind, unabhängig davon, ob solche Fehler oder Auslassungen auf Fahrlässigkeit, Unfälle oder andere Ursachen zurückzuführen sind.

Copyright © 2018-2023 Anton Babenko.

Terragrunt

arrow-up-right

Compliance.tfarrow-up-right — Terraform Compliance Simplified. Make your Terraform modules compliance-ready.

—

contact mearrow-up-right
العربية (Arabic)chevron-right
Bosanski (Bosnian)chevron-right
Português (Brazilian Portuguese)chevron-right
Englishchevron-right
Français (French)chevron-right
ქართული (Georgian)chevron-right
ελληνικά (Greek)chevron-right
עברית (Hebrew)chevron-right
हिंदी (Hindi)chevron-right
Bahasa Indonesia (Indonesian)chevron-right
Italiano (Italian)chevron-right
日本語 (Japanese)chevron-right
ಕನ್ನಡ (Kannada)chevron-right
한국어 (Korean)chevron-right
Polski (Polish)chevron-right
Română (Romanian)chevron-right
简体中文 (Simplified Chinese)chevron-right
Español (Spanish)chevron-right
Türkçe (Turkish)chevron-right
Українська (Ukrainian)chevron-right
اردو (Urdu)chevron-right
eröffnen Sie bitte ein Issuearrow-up-right
Anton Babenkoarrow-up-right

Grundlegende Konzepte

Die offizielle Terraform-Dokumentation beschreibt alle Aspekte der Konfiguration im Detailarrow-up-right. Lesen Sie sie sorgfältig, um den Rest dieses Abschnitts zu verstehen.

In diesem Abschnitt werden die wichtigsten Konzepte beschrieben, die in diesem Buch verwendet werden.

hashtag
Ressource

aws_vpc, aws_db_instance und andere sind Beispiele für Ressourcen. Eine Ressource gehört zu einem Provider, akzeptiert Argumente, gibt Attribute aus und hat Lebenszyklen. Eine Ressource kann erstellt, abgerufen, aktualisiert und gelöscht werden.

hashtag
Ressourcenmodule

Ein Ressourcenmodul ist eine Sammlung zusammenhängender Ressourcen, die gemeinsam eine Aktion durchführen (z. B. erstellt das VPC, Subnetze, NAT-Gateway usw.). Es hängt von der Konfiguration des Providers ab, die darin oder in übergeordneten Strukturen (z. B. im Infrastrukturmodul) definiert werden kann.

hashtag
Infrastrukturmodule

Ein Infrastrukturmodul ist eine Sammlung von Ressourcenmodulen, die nicht zwingend logisch miteinander verbunden sein müssen, aber in der aktuellen Situation/im aktuellen Projekt/im aktuellen Setup demselben Zweck dienen. Es definiert die Konfiguration für Provider, die an die nachgelagerten Ressourcenmodule und an Ressourcen weitergegeben wird. Normalerweise ist die Arbeit auf eine Einheit pro logischer Begrenzung beschränkt (z. B. AWS Region, Google Project).

Das Modul verwendet beispielsweise Ressourcenmodule wie und , um die für den Betrieb von auf erforderliche Infrastruktur zu verwalten.

Ein weiteres Beispiel ist das Modul, bei dem mehrere Module von zusammen verwendet werden, um die Infrastruktur zu verwalten und Docker-Ressourcen zu nutzen, um Docker-Images zu erstellen, zu pushen und zu verteilen. Alles in einem Modul.

hashtag
Komposition

Eine Komposition ist eine Sammlung von Infrastrukturmodulen, die sich über mehrere logisch getrennte Bereiche erstrecken kann (z. B. AWS-Regionen, mehrere AWS-Konten). Eine Komposition wird verwendet, um die komplette Infrastruktur zu beschreiben, die für das gesamte Unternehmen oder Projekt erforderlich ist.

Eine Komposition besteht aus Infrastrukturmodulen, die aus Ressourcenmodulen bestehen, die einzelne Ressourcen implementieren.

hashtag
Datenquellen

Eine Datenquelle führt einen Lese-Vorgang durch und ist abhängig von der Konfiguration des Providers; sie wird in einem Ressourcenmodul und einem Infrastrukturmodul verwendet.

Die Datenquelle terraform_remote_state dient als Bindeglied für übergeordnete Module und Kompositionen.

Die ermöglicht es einem externen Programm, als Datenquelle zu fungieren und beliebige Daten zur Verwendung in der Terraform-Konfiguration freizugeben. Hier ist ein Beispiel aus dem , bei dem der Dateiname durch den Aufruf eines externen Python-Skripts berechnet wird.

Die führt eine HTTP-GET-Anfrage an die angegebene URL durch und exportiert Informationen über die Antwort, was oft nützlich ist, um Informationen von Endpunkten zu erhalten, für die kein eigener Terraform-Provider existiert.

hashtag
Remote-Status

Infrastrukturmodule und Kompositionen sollten ihren an einem entfernten Ort aufbewahren, wo er von anderen kontrolliert (z.B. mittels ACL, Versionierung und Logging) abgerufen werden kann.

hashtag
Provider, Provisioner, ...

Provider, Provisioner und einige andere Begriffe sind in der offiziellen Dokumentation sehr gut beschrieben und es macht keinen Sinn, sie hier zu wiederholen. Meiner Meinung nach haben sie wenig mit dem Schreiben guter Terraform-Module zu tun.

hashtag
Warum so kompliziert?

Während einzelne Ressourcen wie Atome in der Infrastruktur sind, sind Ressourcenmodule Moleküle. Ein Modul ist die kleinste versionierte und gemeinsam nutzbare Einheit. Es hat eine genaue Liste von Argumenten und implementiert die grundlegende Logik für eine solche Einheit, um die erforderliche Funktion auszuführen. Beispielsweise erstellt das Modul aws_security_group und aws_security_group_rule Ressourcen basierend auf der Eingabe. Dieses Ressourcenmodul selbst kann zusammen mit anderen Modulen verwendet werden, um das Infrastrukturmodul zu erstellen.

Der übergreifende Zugriff auf die Daten einzelner Moleküle (Ressourcenmodule und Infrastrukturmodule) erfolgt über die Ausgaben und Datenquellen der Module.

Der Zugriff zwischen Kompositionen erfolgt häufig über Remote state Datenquellen. Für die gibt es mehrere Möglichkeiten.

Wenn man die oben beschriebenen Konzepte in Pseudo-Beziehungen zueinander setzt, kann das so aussehen:

Code-Styling

circle-info
  • Beispiele und Terraform-Module sollten eine Dokumentation enthalten, in der die Funktionen und deren Verwendung erklärt werden.

  • Alle Links in README.md-Dateien sollten absolut sein, damit die Terraform Registry Website sie korrekt anzeigt.

  • Die Dokumentation kann mit erstellte Diagramme und mit erstellte Blueprints enthalten.

  • Verwenden Sie , um sicherzustellen, dass der Code gültig, richtig formatiert und automatisch dokumentiert ist, bevor er nach Git gepusht und von Menschen überprüft wird.

hashtag
Dokumentation

hashtag
Automatisch erstellte Dokumentation

ist ein Framework für die Verwaltung und Pflege von Pre-Commit-Hooks für mehrere Programmiersprachen. Es ist in Python geschrieben und ist ein leistungsfähiges Werkzeug, um auf dem Rechner eines Entwicklers automatisch etwas zu tun, bevor der Code in ein Git-Repository übertragen wird. Normalerweise wird es verwendet, um Linter auszuführen und Code zu formatieren (siehe ).

Mit Terraform-Konfigurationen kann pre-commit verwendet werden, um Code zu formatieren und zu validieren, sowie um die Dokumentation zu aktualisieren.

Schauen Sie sich das an, um sich damit vertraut zu machen, sowie bestehende Repositories (z.B. ), in denen dies bereits verwendet wird.

hashtag
terraform-docs

ist ein Werkzeug, das die Dokumentation von Terraform-Modulen in verschiedenen Ausgabeformaten erzeugt. Sie können es manuell ausführen (ohne pre-commit hooks), oder verwenden, um die Dokumentation automatisch zu aktualisieren.

@todo: Document module versions, release, GH actions

hashtag
Ressourcen

  1. Blog post von :

mermaidarrow-up-right
cloudcraft.coarrow-up-right
Terraform Pre-Commit Hooksarrow-up-right
pre-commitarrow-up-right
unterstützte Hooksarrow-up-right
pre-commit-terraform Repositoryarrow-up-right
terraform-aws-vpcarrow-up-right
terraform-docsarrow-up-right
pre-commit-terraform hooksarrow-up-right
pre-commit framework homepagearrow-up-right
Collection of git hooks for Terraform to be used with pre-commit frameworkarrow-up-right
Dean Wilsonarrow-up-right
pre-commit hooks and terraform - a safety net for your repositoriesarrow-up-right

Terraform

AWS VPC Terraform-Modularrow-up-right
terraform-aws-atlantisarrow-up-right
terraform-aws-vpcarrow-up-right
terraform-aws-security-grouparrow-up-right
Atlantisarrow-up-right
AWS Fargatearrow-up-right
terraform-aws-cloudqueryarrow-up-right
terraform-aws-modulesarrow-up-right
externe Datenquellearrow-up-right
terraform-aws-lambda Modularrow-up-right
http-Datenquellearrow-up-right
Terraform-Statusarrow-up-right
terraform-aws-security-grouparrow-up-right
gemeinsame Nutzung von Daten zwischen Konfigurationenarrow-up-right
Einfache Infrastruktur Komposition
composition-1 {
  infrastructure-module-1 {
    data-source-1 => d1

    resource-module-1 {
      data-source-2 => d2
      resource-1 (d1, d2)
      resource-2 (d2)
    }

    resource-module-2 {
      data-source-3 => d3
      resource-3 (d1, d3)
      resource-4 (d3)
    }
  }

}

Workshop

Es gibt auch einen Workshop für alle, die einige der in diesem Leitfaden beschriebenen Dinge üben wollen.

Der Inhalt ist hier zu finden - https://github.com/antonbabenko/terraform-best-practices-workshoparrow-up-right

FAQ - Häufig gestellte Fragen

FTP (Frequent Terraform Problems) - Häufige Probleme mit Terraform

hashtag
Welche Werkzeuge sollte ich kennen und nutzen?

  • Terragruntarrow-up-right - Orchestrierungswerkzeug

  • - Code linter

  • - Terraform Versionsverwaltung

  • - Pull Request Automatisierung

  • - Sammlung von Git-Hooks für Terraform, die mit dem verwendet werden können

  • - Cloud-Kostenschätzungen für Terraform in Pull Requests. Funktioniert auch mit Terragrunt, Atlantis und pre-commit-terraform.

hashtag
Was sind Lösungen für die bei Modulen?

Die Versionen der Ressourcen- und Infrastrukturmodule sollten angegeben werden. Provider sollten außerhalb von Modulen konfiguriert werden, aber nur in der Komposition. Die Versionen von Providern und Terraform können auch fixiert werden.

Es gibt kein Master-Tool für die Verwaltung von Abhängigkeiten, aber es gibt einige Tipps, um die Abhängigkeitshölle weniger problematisch zu machen. Zum Beispiel kann verwendet werden, um die Aktualisierung von Abhängigkeiten zu automatisieren. Dependabot erstellt Pull Requests, um Ihre Abhängigkeiten sicher und aktuell zu halten. Dependabot unterstützt Terraform-Konfigurationen.

Mittlere Infrastruktur mit Terraform

Quellcode: https://github.com/antonbabenko/terraform-best-practices/tree/master/examples/medium-terraformarrow-up-right

Dieses Beispiel enthält Code als Beispiel für die Strukturierung von Terraform-Konfigurationen für eine mittelgroße Infrastruktur, dazu werden verwendet:

  • 2 AWS-Konten

  • 2 separate Umgebungen (prod und stage, die sich nichts teilen). Jede Umgebung befindet sich in einem separaten AWS-Konto.

  • Jede Umgebung verwendet eine andere Version des Standard-Infrastrukturmoduls (alb), das aus der stammt.

  • Jede Umgebung verwendet die gleiche Version eines internen Moduls modules/network, da es aus einem lokalen Verzeichnis stammt.

circle-check
  • Perfekt für Projekte, bei denen die Infrastruktur logisch getrennt ist (separate AWS-Konten)

  • Gut, wenn keine Notwendigkeit besteht, zwischen AWS-Konten geteilte Ressourcen zu ändern (eine Umgebung = ein AWS-Konto = eine Statusdatei)

circle-exclamation

Je größer das Projekt wird, desto schwieriger wird es, diese Umgebungen untereinander auf dem neuesten Stand zu halten. Erwägen Sie den Einsatz von Infrastrukturmodulen (von der Stange oder intern) für wiederholbare Aufgaben.

hashtag

Referenzen

circle-info

Es gibt eine Menge Leute, die großartige Inhalte erstellen und Open-Source-Projekte verwalten, die für die Terraform-Gemeinschaft relevant sind, aber ich weiß nicht, wie ich diese Links hier am besten auflisten kann, ohne Sammlungen wie awesome-terraformarrow-up-right zu kopieren.

https://twitter.com/antonbabenko/lists/terraform-expertsarrow-up-right - Liste von Leuten, die sehr aktiv mit Terraform arbeiten und Ihnen eine Menge erzählen können (wenn Sie sie fragen).

https://github.com/shuaibiyy/awesome-terraformarrow-up-right - Kuratierte Liste von Ressourcen zu HashiCopr Terraform.

http://bit.ly/terraform-youtubearrow-up-right - "Your Weekly Dose of Terraform" YouTube Kanal von Anton Babenko. Live-Streams mit Reviews, Interviews, Fragen und Antworten, Live-Coding und ein wenig Hacking mit Terraform.

- Terraform Weekly Newsletter. Verschiedene Neuigkeiten aus der Terraform-Welt (Projekte, Ankündigungen, Diskussionen) von Anton Babenko.

Aufbau des Codes

Fragen, die sich auf die Terraform-Code-Struktur beziehen, sind mit Abstand die häufigsten in der Community. Jeder hat sich irgendwann einmal Gedanken über die beste Codestruktur für das Projekt gemacht.

hashtag
Wie sollte ich meine Terraform-Konfigurationen strukturieren?

Dies ist eine der Fragen, für die es viele Lösungen gibt, und es ist sehr schwer, allgemeingültige Ratschläge zu erteilen, also sollten wir zunächst einmal verstehen, womit wir es zu tun haben.

Größere Infrastruktur mit Terraform

Quellcode:

Dieses Beispiel enthält Code als Beispiel für die Strukturierung von Terraform-Konfigurationen für eine groß angelegte Infrastruktur, dazu werden verwendet:

  • 2 AWS-Konten

  • 2 Regionen

Schreiben von Terraform-Konfigurationen

hashtag
Verwenden Sie locals, um explizite Abhängigkeiten zwischen Ressourcen zu spezifizieren

Hilfreiche Möglichkeit, Terraform einen Hinweis zu geben, dass einige Ressourcen vorher gelöscht werden sollten, auch wenn es keine direkte Abhängigkeit in Terraform-Konfigurationen gibt.

Kleinere Infrastruktur mit Terraform

Quellcode:

Dieses Beispiel enthält Code als Beispiel für die Strukturierung von Terraform-Konfigurationen für eine kleine Infrastruktur, in der keine externen Abhängigkeiten verwendet werden.

circle-check
  • Perfekt für den Einstieg und zum Refactoring im laufenden Betrieb

tflintarrow-up-right
tfenvarrow-up-right
Atlantisarrow-up-right
pre-commit-terraformarrow-up-right
Pre-Commit-Frameworkarrow-up-right
Infracostarrow-up-right
dependency hellarrow-up-right
Dependabotarrow-up-right

Gut, wenn kein Bedarf an der Orchestrierung von Änderungen zwischen den Umgebungen besteht

  • Gut, wenn die Infrastrukturressourcen pro Umgebung absichtlich unterschiedlich sind und nicht verallgemeinert werden können (z. B. sind einige Ressourcen in einer Umgebung oder in einigen Regionen nicht vorhanden)

  • Terraform-Registryarrow-up-right
    https://weekly.tfarrow-up-right

    2 separate Umgebungen (prod und stage, die sich nichts teilen). Jede Umgebung befindet sich in einem separaten AWS-Konto und verteilt die Ressourcen auf 2 Regionen.

  • Jede Umgebung verwendet eine andere Version des Standard-Infrastrukturmoduls (alb), das aus der Terraform-Registryarrow-up-right stammt.

  • Jede Umgebung verwendet die gleiche Version eines internen Moduls modules/network, da es aus einem lokalen Verzeichnis stammt.

  • circle-info

    In einem großen Projekt wie dem hier beschriebenen werden die Vorteile der Verwendung von Terragrunt sehr deutlich. Siehe Beispiele für Code-Strukturen mit Terragrunt.

    circle-check
    • Perfekt für Projekte, bei denen die Infrastruktur logisch getrennt ist (separate AWS-Konten)

    • Gut, wenn keine Notwendigkeit besteht, zwischen AWS-Konten geteilte Ressourcen zu ändern (eine Umgebung = ein AWS-Konto = eine Statusdatei)

    • Gut, wenn kein Bedarf an der Orchestrierung von Änderungen zwischen den Umgebungen besteht

    • Gut, wenn die Infrastrukturressourcen pro Umgebung absichtlich unterschiedlich sind und nicht verallgemeinert werden können (z. B. sind einige Ressourcen in einer Umgebung oder in einigen Regionen nicht vorhanden)

    circle-exclamation

    Je größer das Projekt wird, desto schwieriger wird es, diese Umgebungen untereinander auf dem neuesten Stand zu halten. Erwägen Sie den Einsatz von Infrastrukturmodulen (von der Stange oder intern) für wiederholbare Aufgaben.

    hashtag

    https://github.com/antonbabenko/terraform-best-practices/tree/master/examples/large-terraformarrow-up-right
  • Perfekt für kleine Ressourcenmodule

  • Gut für kleine und lineare Infrastrukturmodule (z.B. terraform-aws-atlantisarrow-up-right)

  • Gut geeignet für eine kleine Anzahl von Ressourcen (weniger als 20-30)

  • circle-exclamation

    Eine einzige Statusdatei für alle Ressourcen kann den Arbeitsprozess mit Terraform verlangsamen, wenn die Anzahl der Ressourcen wächst (erwägen Sie die Verwendung des Arguments -target, um die Anzahl der Ressourcen zu begrenzen)

    https://github.com/antonbabenko/terraform-best-practices/tree/master/examples/small-terraformarrow-up-right
    hashtag
    Terraform 0.12 - Erforderliche und optionale Argumente
    1. Das erforderliche Argument index_document muss gesetzt werden, wenn var.website keine leere map() ist.

    2. Das optionale Argument error_document kann weggelassen werden.

    https://raw.githubusercontent.com/antonbabenko/terraform-best-practices/master/snippets/locals.tfarrow-up-right
    terraform.tfvars
    website = {
      index_document = "index.html"
    }
    main.tf
    variable "website" {
      type    = map(string)
      default = {}
    }
    
    resource "aws_s3_bucket" "this" {
      # omitted...
    
      dynamic "website" {
        for_each = length(keys(var.website)) == 0 ? [] : [var.website]
    
        content {
          index_document = website.value.index_document
          error_document = lookup(website.value, "error_document", null)
        }
      }
    }

    Wie komplex ist Ihr Projekt?

    • Anzahl der zugehörigen Ressourcen

    • Anzahl der Terraform-Provider (siehe Hinweis unten über "logische Provider")

  • Wie oft ändert sich Ihre Infrastruktur?

    • Von einmal pro Monat/Woche/Tag

    • Bis kontinuierlich (jedes Mal, wenn es einen neuen Commit gibt)

  • Initiatoren von Codeänderungen? Lassen Sie den CI-Server das Repository aktualisieren, wenn ein neues Artefakt erstellt wird?

    • Nur Entwickler können Änderungen am Infrastruktur-Repository vornehmen.

    • Jeder kann eine Änderung vorschlagen, indem er einen PR öffnet (einschließlich automatisierter Aufgaben, die auf dem CI-Server laufen)

  • Welche Einsatzplattform oder welchen Einsatzdienst verwenden Sie?

    • AWS CodeDeploy, Kubernetes oder OpenShift erfordern einen etwas anderen Ansatz

  • Wie sind die Umgebungen gruppiert?

    • Nach Umgebung, Region, Projekt

  • circle-info

    Logische Provider arbeiten vollständig innerhalb der Terraform-Logik und interagieren sehr oft nicht mit anderen Diensten, so dass wir ihre Komplexität als O(1) betrachten können. Zu den häufigsten logischen Providern gehören randomarrow-up-right, localarrow-up-right, terraformarrow-up-right, nullarrow-up-right und timearrow-up-right.

    hashtag
    Erste Schritte bei der Strukturierung von Terraform-Konfigurationen

    Es ist eine gute Idee, den gesamten Code in die Datei main.tf zu packen, wenn Sie gerade erst anfangen oder einen Beispielcode schreiben. In allen anderen Fällen ist es besser, mehrere Dateien zu haben, die logisch aufgeteilt sind, wie hier:

    • main.tf - ruft Module, lokale Variablen und Datenquellen auf, um alle Ressourcen zu erstellen

    • variables.tf - enthält die Deklarationen der in main.tf verwendeten Variablen

    • outputs.tf - enthält die Ausgaben der in main.tf erstellten Ressourcen

    • versions.tf - enthält die Versionsanforderungen für Terraform und Provider

    terraform.tfvars sollte nur in der Komposition verwendet werden.

    hashtag
    Wie sollte man über die Struktur von Terraform-Konfigurationen nachdenken?

    circle-info

    Vergewissern Sie sich, dass Sie die grundlegenden Konzepte - Ressourcenmodul, Infrastrukturmodul und Komposition - verstehen, da sie in den folgenden Beispielen verwendet werden.

    hashtag
    Allgemeine Empfehlungen für die Strukturierung von Code

    • Es ist einfacher und schneller, mit einer kleineren Anzahl von Ressourcen zu arbeiten

      • terraform plan und terraform apply machen beide Cloud-API-Aufrufe, um den Status der Ressourcen zu überprüfen

      • Wenn Sie Ihre gesamte Infrastruktur in einer einzigen Komposition haben, kann dies einige Zeit dauern

    • Der Blast-Radius ("Explosionsradius") ist kleiner mit weniger Ressourcen

      • Die Isolierung nicht zusammenhängender Ressourcen voneinander, indem sie in getrennten Kompositionen untergebracht werden, verringert das Risiko, wenn etwas schief geht.

    • Beginnen Sie Ihr Projekt mit einem Remote-Status, denn:

      • Ihr Laptop ist kein Ort für Ihre Infrastruktur als "Quelle der Wahrheit"

      • Die Verwaltung einer tfstate-Datei in Git ist ein Alptraum

    • Achten Sie auf eine einheitliche Struktur und :

      • Wie prozeduraler Code sollte auch Terraform-Code so geschrieben werden, dass ihn Entwickler gut lesen können; Konsistenz ist hilfreich, wenn sechs Monaten später Änderungen vorgenommen werden müssen

      • Es ist möglich, Ressourcen innerhalb der Terraform-Statusdatei zu verschieben, aber es kann schwieriger sein, wenn Sie eine inkonsistente Struktur und Namenskonvention haben

    • Halten Sie die Ressourcenmodule so einfach wie möglich

    • Geben Sie keine Werte fest ein, die als Variablen übergeben oder über Datenquellen ermittelt werden können

    • Verwenden Sie Datenquellen und terraform_remote_state speziell als Verbindung zwischen Infrastrukturmodulen innerhalb der Komposition

    In diesem Buch sind die Beispielprojekte nach Komplexität gruppiert - von kleinen bis zu sehr großen Infrastrukturen. Diese Trennung ist nicht strikt, probieren Sie daher auch Strukturen.

    hashtag
    Orchestrierung von Infrastrukturmodulen und Kompositionen

    Eine kleine Infrastruktur bedeutet, dass es nur eine geringe Anzahl von Abhängigkeiten und wenige Ressourcen gibt. Wenn das Projekt wächst, wird die Notwendigkeit deutlich, die Ausführung von Terraform-Konfigurationen zu verketten, verschiedene Infrastrukturmodule zu verbinden und Werte innerhalb einer Komposition zu übergeben.

    Es gibt mindestens 5 verschiedene Gruppen von Orchestrierungslösungen, die Entwickler verwenden:

    1. Nur Terraform. Sehr einfach, Entwickler müssen nur Terraform kennen, um die Arbeit zu erledigen.

    2. Terragrunt. Ein reines Orchestrierungstool, mit dem die gesamte Infrastruktur orchestriert und Abhängigkeiten gehandhabt werden können. Terragrunt arbeitet nativ mit Infrastrukturmodulen und Kompositionen und reduziert so die Duplizierung von Code.

    3. Interne Skripte. Dies geschieht oft als Ausgangspunkt für die Orchestrierung und bevor Terragrunt entdeckt wird.

    4. Ansible oder ein ähnliches Allzweck-Automatisierungswerkzeug. Wird normalerweise verwendet, wenn Terraform nach Ansible eingeführt wird oder wenn die Ansible UI aktiv genutzt wird.

    5. und andere Kubernetes-inspirierte Lösungen. Manchmal ist es sinnvoll, das Kubernetes-Ökosystem zu nutzen und eine Reconciliation-Schleife einzusetzen, um den gewünschten Zustand Ihrer Terraform-Konfigurationen zu erreichen. Sehen Sie sich das Video für weitere Informationen an.

    Vor diesem Hintergrund werden in diesem Buch die ersten beiden dieser Projektstrukturen, Terraform only und Terragrunt, vorgestellt.

    Beispiele für Codestrukturen für Terraform oder Terragrunt finden Sie im nächsten Kapitel.

    Beispiele für Code-Strukturen

    hashtag
    Terraform-Code Strukturen

    circle-info

    Diese Beispiele zeigen den AWS-Anbieter, aber die meisten der in den Beispielen gezeigten Prinzipien können auch auf andere öffentliche Cloud-Anbieter und andere Arten von Anbietern (DNS, Datenbanken, Monitoring usw.) angewendet werden.

    Typ
    Beschreibung
    Einsatzbereitschaft

    hashtag
    Terragrunt-Code Strukturen

    Typ
    Beschreibung
    Einsatzbereitschaft

    Später, wenn die Infrastrukturebenen in verschiedene Richtungen wachsen (Anzahl der Abhängigkeiten oder Ressourcen), wird es einfacher sein, die Dinge unter Kontrolle zu halten

    Namenskonvention
    Crossplanearrow-up-right
    Crossplane vs. Terraformarrow-up-right

    Viele AWS-Konten, viele Regionen. Dringender Bedarf, Copy-Paste zu reduzieren, benutzerdefinierte Infrastrukturmodule, starke Nutzung von Compositions. Verwendung von Terraform.

    In Arbeit

    sehr groß

    Mehrere Anbieter (AWS, GCP, Azure). Multi-Cloud-Einsatz. Verwendung von Terraform.

    Nein

    sehr groß

    Mehrere Anbieter (AWS, GCP, Azure). Multi-Cloud-Einsätze. Verwendung von Terragrunt.

    Nein

    klein

    Wenige Ressourcen, keine externen Abhängigkeiten. Ein AWS-Konto. Eine Region. Eine Umgebung.

    Ja

    mittel

    Mehrere AWS-Konten und Umgebungen, handelsübliche Infrastrukturmodule mit Terraform.

    Ja

    mittel

    Mehrere AWS-Konten und Umgebungen, handelsübliche Infrastrukturmodule, Kompositionsmuster mit Terragrunt.

    Nein

    groß

    Many AWS accounts, many regions, urgent need to reduce copy-paste, custom infrastructure modules, heavy usage of compositions. Using Terragrunt. Viele AWS-Konten, viele Regionen. Dringender Bedarf, Copy-Paste zu reduzieren, benutzerdefinierte Infrastrukturmodule, starke Nutzung von Kompositionen. Verwendung von Terragrunt.

    Nein

    groß

    Namenskonventionen

    hashtag
    Allgemeine Konventionen

    circle-info

    Es sollte keinen Grund geben, nicht wenigstens diese Konventionen zu befolgen :)

    circle-info

    Beachten Sie, dass die tatsächlichen Cloud-Ressourcen oft Einschränkungen bei den zulässigen Namen haben. Einige Ressourcen dürfen zum Beispiel keine Bindestriche enthalten, andere müssen in Kamelschreibweise geschrieben werden. Die Konventionen in diesem Buch beziehen sich auf die Terraform-Namen selbst.

    1. Verwenden Sie überall _ (Unterstrich) anstelle von - (Bindestrich) (Ressourcennamen, Datenquellennamen, Variablennamen, Ausgaben usw.).

    2. Verwenden Sie vorzugsweise Kleinbuchstaben und Zahlen (auch wenn UTF-8 unterstützt wird).

    hashtag
    Argumente für Ressourcen und Datenquellen

    1. Wiederholen Sie den Ressourcentyp nicht im Ressourcennamen (weder teilweise noch vollständig):

      circle-check

      resource "aws_route_table" "public" {}

      triangle-exclamation

    hashtag
    Code-Beispiele für resource

    hashtag
    Verwendung von count / for_each

    circle-check
    triangle-exclamation

    hashtag
    Platzierung von tags

    circle-check
    triangle-exclamation

    hashtag
    Bedingungen in count

    circle-check

    hashtag
    Variablen

    1. Erfinden Sie das Rad in Ressourcenmodulen nicht neu: Verwenden Sie den Namen, die Beschreibung und den Standardwert für Variablen, wie sie im Abschnitt "Argumentreferenz" für die Ressource, mit der Sie arbeiten, definiert sind.

    2. Die Unterstützung für die Validierung von Variablen ist ziemlich begrenzt (z.B. kann nicht auf andere Variablen zugegriffen werden oder Lookups durchgeführt werden). Planen Sie entsprechend, denn in vielen Fällen ist diese Funktion nutzlos.

    3. Verwenden Sie die Pluralform in einem Variablennamen, wenn der Typ list(...)

    hashtag
    Ausgaben

    Machen Sie Ausgaben konsistent und verständlich außerhalb des Moduls (wenn ein Benutzer ein Modul verwendet, sollte es offensichtlich sein, welchen Typ und welches Attribut der Wert hat, den es zurückgibt).

    1. Der Name der Ausgabe sollte die darin enthaltene Eigenschaft beschreiben und weniger frei formuliert sein, als Sie es normalerweise wünschen würden.

    2. Eine gute Struktur für den Namen der Ausgabe sieht aus wie {name}_{type}_{attribute} , wobei:

      1. {name}

    hashtag
    Code-Beispiele für output

    Höchstens eine ID einer Security-Gruppe ausgeben:

    circle-check

    Wenn mehrere Ressourcen desselben Typs vorhanden sind, sollte this im Namen der Ausgabe weggelassen werden:

    triangle-exclamation

    Pluralname verwenden, wenn der Rückgabewert eine Liste ist:

    circle-check

    resource "aws_route_table" "public_route_table" {}

    triangle-exclamation

    resource "aws_route_table" "public_aws_route_table" {}

  • Der Ressourcenname sollte this benannt werden, wenn kein beschreibender und allgemeiner Name verfügbar ist, oder wenn das Ressourcenmodul eine einzelne Ressource dieses Typs erstellt (z. B. gibt es im AWS VPC-Modularrow-up-right eine einzelne Ressource des Typs aws_nat_gateway und mehrere Ressourcen des Typs aws_route_table, daher sollte aws_nat_gateway this benannt werden und aws_route_table sollte beschreibendere Namen haben - wie private, public oder database).

  • Verwenden Sie bei Namen immer die Einzahl.

  • Verwenden Sie - innerhalb von Argumenten und an Stellen, an denen der Wert für einen Menschen sichtbar ist (z. B. innerhalb des DNS-Namens der RDS-Instanz).

  • Fügen Sie das Argument count / for_each innerhalb des Ressourcen- oder Datenquellenblocks als erstes Argument oben ein und trennen Sie es danach durch einen Zeilenumbruch.

  • Fügen Sie das Argument tags, falls von der Ressource unterstützt, als letztes echtes Argument ein, gefolgt von depends_on und lifecycle, falls erforderlich. Alle diese Argumente sollten durch eine einzelne Leerzeile getrennt werden.

  • Bei der Verwendung von Bedingungen in einem count / for_each Argument sind boolesche Werte zu bevorzugen, anstatt length oder andere Ausdrücke zu verwenden.

  • oder
    map(...)
    ist.
  • Ordnen Sie die Schlüssel in einem Variablenblock wie folgt an: description , type, default, validation

  • Fügen Sie immer eine description allen Variablen hinzu, auch wenn Sie denken, dass es offensichtlich ist (Sie werden es in Zukunft brauchen).

  • Verwenden Sie lieber einfache Typen (number, string, list(...), map(...), any) als spezifische Typen wie object(), es sei denn, Sie müssen strenge Einschränkungen für jeden Schlüssel haben.

  • Verwenden Sie spezifische Typen wie map(map(string)), wenn alle Elemente der Map denselben Typ haben (z. B. string) oder in diesen umgewandelt werden können (z. B. kann der Typ number in string umgewandelt werden).

  • Verwenden Sie type any, um die Typüberprüfung ab einer bestimmten Tiefe zu deaktivieren oder wenn mehrere Typen unterstützt werden sollen.

  • Der Wert {} ist manchmal eine map() und manchmal ein object(). Verwenden Sie tomap(...), um eine map() zu erstellen, da es keine Möglichkeit gibt, ein object() zu erstellen.

  • ein Ressourcen- oder Datenquellenname ohne Provider-Präfix ist.
    {name}
    für
    aws_subnet
    ist
    subnet
    , für
    aws_vpc
    ist es
    vpc
    .
  • {type} ist ein Typ einer Ressourcenquelle

  • {attribute} ist ein Attribut, das von der Ausgabe zurückgegeben wird.

  • Siehe Beispiele.

  • Wenn die Ausgabe einen Wert mit Interpolationsfunktionen und mehreren Ressourcen zurückgibt, sollten {name} und {type} dort so allgemein wie möglich sein (this sollte als Präfix weggelassen werden). Siehe Beispiel.

  • Wenn der zurückgegebene Wert eine Liste ist, sollte er einen Pluralnamen haben. Siehe Beispiel.

  • Geben Sie immer eine description für alle Ausgaben an, auch wenn Sie denken, dass es offensichtlich ist.

  • Vermeiden Sie es, sensitive Argumente zu setzen, es sei denn, Sie kontrollieren die Verwendung dieser Ausgabe an allen Stellen in allen Modulen vollständig.

  • Bevorzugen Sie try() (verfügbar seit Terraform 0.13) gegenüber element(concat(...)) (Legacy-Ansatz für die Version vor 0.13)

  • main.tf
    resource "aws_route_table" "public" {
      count = 2
    
      vpc_id = "vpc-12345678"
      # ... remaining arguments omitted
    }
    
    resource "aws_route_table" "private" {
      for_each = toset(["one", "two"])
    
      vpc_id = "vpc-12345678"
      # ... remaining arguments omitted
    }
    main.tf
    resource "aws_route_table" "public" {
      vpc_id = "vpc-12345678"
      count  = 2
    
      # ... remaining arguments omitted
    }
    main.tf
    resource "aws_nat_gateway" "this" {
      count = 2
    
      allocation_id = "..."
      subnet_id     = "..."
    
      tags = {
        Name = "..."
      }
    
      depends_on = [aws_internet_gateway.this]
    
      lifecycle {
        create_before_destroy = true
      }
    }   
    main.tf
    resource "aws_nat_gateway" "this" {
      count = 2
    
      tags = "..."
    
      depends_on = [aws_internet_gateway.this]
    
      lifecycle {
        create_before_destroy = true
      }
    
      allocation_id = "..."
      subnet_id     = "..."
    }
    outputs.tf
    resource "aws_nat_gateway" "that" {    # Best
      count = var.create_public_subnets ? 1 : 0
    }
    
    resource "aws_nat_gateway" "this" {    # Good
      count = length(var.public_subnets) > 0 ? 1 : 0
    }
    outputs.tf
    output "security_group_id" {
      description = "The ID of the security group"
      value       = try(aws_security_group.this[0].id, aws_security_group.name_prefix[0].id, "")
    }
    outputs.tf
    output "this_security_group_id" {
      description = "The ID of the security group"
      value       = element(concat(coalescelist(aws_security_group.this.*.id, aws_security_group.web.*.id), [""]), 0)
    }
    outputs.tf
    output "rds_cluster_instance_endpoints" {
      description = "A list of all cluster instance endpoints"
      value       = aws_rds_cluster_instance.this.*.endpoint
    }