Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Dieses Dokument enthält Richtlinien und Empfehlungen zum Testen von Terraform for Google Cloud-Modulen und ‑Konfigurationen.
Das Testen von Terraform-Modulen und -Konfigurationen folgt manchmal anderen Mustern und Konventionen als das Testen von Anwendungscode. Beim Testen von Anwendungscode geht es hauptsächlich darum, die Geschäftslogik von Anwendungen zu testen. Für den vollständigen Test von Infrastrukturcode müssen jedoch echte Cloud-Ressourcen bereitgestellt werden, um das Risiko von Produktionsausfällen zu minimieren. Beim Ausführen von Terraform-Tests sind einige Überlegungen zu beachten:
Durch das Ausführen eines Terraform-Tests wird eine echte Infrastruktur erstellt, geändert und gelöscht, sodass Ihre Tests möglicherweise zeitaufwendig und teuer sind.
Sie können für eine reine End-to-End-Architektur nicht nur Unittests ausführen. Der beste Ansatz besteht darin, Ihre Architektur in Module aufzuteilen und diese einzeln zu testen. Zu den Vorteilen dieses Ansatzes gehören eine schnellere iterative Entwicklung aufgrund einer schnelleren Testlaufzeit, geringere Kosten für jeden Test und eine geringere Wahrscheinlichkeit von fehlgeschlagenen Tests aufgrund von Faktoren, die außerhalb Ihrer Kontrolle liegen.
Vermeiden Sie nach Möglichkeit die Wiederverwendung des Zustands. Es kann Situationen geben, in denen Sie Tests mit Konfigurationen durchführen, die Daten mit anderen Konfigurationen teilen. Idealerweise sollte jedoch jeder Test unabhängig sein und den Zustand nicht testübergreifend wiederverwenden.
Zuerst kostengünstigere Testmethoden verwenden
Es gibt mehrere Methoden, mit denen Sie Terraform testen können. In aufsteigender Reihenfolge der Kosten, Laufzeit und Tiefe beinhalten sie Folgendes:
Statische Analyse: Testen der Syntax und Struktur Ihrer Konfiguration ohne Bereitstellung von Ressourcen und mit Tools wie Compilern, Linting und Probeläufen. Verwenden Sie dazu terraform validate.
Testen der Modulintegration: Testen Sie, ob die Module ordnungsgemäß funktionieren, indem Sie einzelne Module isoliert testen. Integrationstests für Module umfassen die Bereitstellung des Moduls in einer Testumgebung und die Überprüfung, ob erwartete Ressourcen erstellt werden. Es gibt mehrere Test-Frameworks, die das Schreiben von Tests erleichtern:
End-to-End-Tests: Wenn Sie den Ansatz für Integrationstests auf eine gesamte Umgebung erweitern, können Sie überprüfen, ob mehrere Module zusammenarbeiten.
Bei diesem Ansatz stellen Sie alle Module, aus denen die Architektur besteht, in einer neuen Testumgebung bereit. Idealerweise ist die Testumgebung Ihrer Produktionsumgebung so ähnlich wie möglich. Dies ist kostspielig, bietet jedoch die größte Sicherheit, dass Änderungen Ihre Produktionsumgebung nicht beeinträchtigen.
Klein anfangen
Achten Sie darauf, dass Ihre Tests iterativ aufeinander aufbauen. Erwägen Sie, zuerst kleinere Tests auszuführen und dann mit einem Fail-Fast-Ansatz zu komplexeren Tests überzugehen.
Projekt-IDs und Ressourcennamen zufällig festlegen
Um Namenskonflikte zu vermeiden, sollten Sie darauf achten, dass Ihre Konfigurationen innerhalb jedes Projekts eine global eindeutige Projekt-ID und nicht überlappende Ressourcennamen haben. Verwenden Sie dazu Namespaces für Ihre Ressourcen. Terraform hat dafür einen integrierten zufälligen Anbieter.
Separate Umgebung zum Testen verwenden
Während des Tests werden viele Ressourcen erstellt und gelöscht. Achten Sie darauf, dass die Umgebung von Entwicklungs- oder Produktionsprojekten isoliert ist, um versehentliches Löschen während der Ressourcenbereinigung zu vermeiden. Die beste Vorgehensweise besteht darin, für jeden Test ein neues Projekt oder einen neuen Ordner zu erstellen. Um Konfigurationsfehler zu vermeiden, sollten Sie Dienstkonten speziell für jede Testausführung erstellen.
Alle Ressourcen bereinigen
Wenn Sie Infrastrukturcode testen, stellen Sie tatsächliche Ressourcen bereit.
Implementieren Sie einen Bereinigungsschritt, um Gebühren zu vermeiden.
Verwenden Sie den Befehl terraform destroy, um alle von einer bestimmten Konfiguration verwalteten Remote-Objekte zu löschen. Einige Test-Frameworks haben einen integrierten Bereinigungsschritt für Sie. Wenn Sie beispielsweise Terratest verwenden, fügen Sie Ihrem Test defer terraform.Destroy(t, terraformOptions) hinzu. Wenn Sie Kitchen-Terraform verwenden, löschen Sie Ihren Arbeitsbereich mit terraform kitchen delete WORKSPACE_NAME.
Führen Sie nach Ausführung des Befehls terraform destroy auch weitere Bereinigungsvorgänge aus, um alle Ressourcen zu entfernen, die Terraform nicht löschen konnte. Löschen Sie dazu alle für die Testausführung verwendeten Projekte oder verwenden Sie ein Tool wie das project_cleanup-Modul.
Testlaufzeit optimieren
Gehen Sie so vor, um die Testausführungszeit zu optimieren:
Tests parallel ausführen. Einige Test-Frameworks unterstützen die gleichzeitige Ausführung mehrerer Terraform-Tests.
Mit Terratest ist dies beispielsweise durch Hinzufügen von t.Parallel() nach der Definition der Testfunktion möglich.
In Phasen testen. Teilen Sie Ihre Tests in unabhängige Konfigurationen auf, die separat getestet werden können. Bei diesem Ansatz müssen Sie nicht mehr alle Phasen eines Tests durchlaufen und beschleunigen den iterativen Entwicklungszyklus.
Teilen Sie in Kitchen-Terraform beispielsweise Tests in separate Suites auf. Führen Sie beim Iterieren jede Suite unabhängig aus.
Analog können Sie mit Terratest jede Phase des Tests mit stage(t, STAGE_NAME, CORRESPONDING_TESTFUNCTION) zusammenfassen.
Legen Sie Umgebungsvariablen fest, die angeben, welche Tests ausgeführt werden sollen. Beispiel: SKIPSTAGE_NAME="true"
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2024-12-22 (UTC)."],[[["\u003cp\u003eTesting Terraform requires deploying real cloud resources, which can be time-consuming and costly, therefore it's recommended to break down architectures into smaller modules for individual testing.\u003c/p\u003e\n"],["\u003cp\u003eStart with less expensive testing methods like static analysis and module integration testing before moving to end-to-end testing, using a fail-fast approach to catch errors quickly.\u003c/p\u003e\n"],["\u003cp\u003eUtilize unique project IDs and resource names, employing the Terraform random provider to avoid conflicts, and use isolated test environments separate from development or production.\u003c/p\u003e\n"],["\u003cp\u003eImplement cleanup procedures, including \u003ccode\u003eterraform destroy\u003c/code\u003e and other tools, to remove all resources created during testing to avoid unnecessary costs.\u003c/p\u003e\n"],["\u003cp\u003eOptimize test runtime by running tests in parallel and separating tests into stages for faster iteration, using frameworks like Terratest or Kitchen-Terraform for efficient test management.\u003c/p\u003e\n"]]],[],null,["# Best practices for testing\n\nThis document provides guidelines and recommendations for testing\nTerraform for Google Cloud modules and configurations.\n\nTesting Terraform modules and configurations sometimes follows different\npatterns and conventions from testing application code. While testing\napplication code primarily involves testing the business logic of applications\nthemselves, fully testing infrastructure code requires deploying real cloud\nresources to minimize the risk of production failures. There are a few\nconsiderations when running Terraform tests:\n\n- Running a Terraform test creates, modifies, and destroys real infrastructure, so your tests can potentially be time-consuming and expensive.\n- *You cannot purely unit test an end-to-end architecture*. The best approach is to break up your architecture into modules and test those individually. The benefits of this approach include faster iterative development due to faster test runtime, reduced costs for each test, and reduced chances of test failures from factors beyond your control.\n- *Avoid reusing state if possible*. There may be situations where you are testing with configurations that share data with other configurations, but ideally each test should be independent and should not reuse state across tests.\n\nUse less expensive test methods first\n-------------------------------------\n\nThere are multiple methods that you can use to test Terraform. In ascending\norder of cost, run time, and depth, they include the following:\n\n- **Static analysis:** Testing the syntax and structure of your configuration without deploying any resources, using tools such as compilers, linters, and dry runs. To do so, use [`terraform validate`](https://www.terraform.io/cli/commands/validate)\n- **Module integration testing** : To ensure that modules work correctly, test individual modules in isolation. Integration testing for modules involves deploying the module into a test environment and verifying that expected resources are created. There are several testing frameworks that make it easier to write tests, as follows:\n - [Google's blueprint testing framework](https://pkg.go.dev/github.com/GoogleCloudPlatform/cloud-foundation-toolkit/infra/blueprint-test)\n - [Terratest](https://terratest.gruntwork.io/)\n - [Kitchen-Terraform](https://newcontext-oss.github.io/kitchen-terraform/)\n - [InSpec](https://github.com/inspec/inspec-gcp)\n - [tftest](https://pypi.org/project/tftest/)\n- **End-to-end testing:** By extending the integration testing approach to an entire environment, you can confirm that multiple modules work together. In this approach, deploy all modules that make up the architecture in a fresh test environment. Ideally, the test environment is as similar as possible to your production environment. This is costly but provides the greatest confidence that changes don't break your production environment.\n\nStart small\n-----------\n\nMake sure that your tests iteratively build on each other. Consider running\nsmaller tests first and then working up to more complex tests, using a\n*fail fast* approach.\n\nRandomize project IDs and resource names\n----------------------------------------\n\nTo avoid naming conflicts, make sure that your configurations have a globally\nunique project ID and non-overlapping resource names within each project. To do\nthis, use namespaces for your resources. Terraform has a built-in\n[random provider](https://registry.terraform.io/providers/hashicorp/random/latest/docs)\nfor this.\n\nUse a separate environment for testing\n--------------------------------------\n\nDuring testing, many resources are created and deleted. Ensure that the\nenvironment is isolated from development or production projects to avoid\naccidental deletions during resource cleanup. The best approach is to have each\ntest create a fresh project or folder. To avoid misconfiguration, consider\ncreating service accounts specifically for each test execution.\n\nClean up all resources\n----------------------\n\nTesting infrastructure code means that you are deploying actual resources.\nTo avoid incurring charges, consider implementing a clean-up step.\n\nTo destroy all remote objects managed by a particular configuration, use the\n`terraform destroy` command. Some testing frameworks have a built-in cleanup\nstep for you. For example, if you are using Terratest, add\n`defer terraform.Destroy(t, terraformOptions)` to your test. If you're using\nKitchen-Terraform, delete your workspace using\n`terraform kitchen delete `\u003cvar translate=\"no\"\u003eWORKSPACE_NAME\u003c/var\u003e.\n\nAfter you run the `terraform destroy` command, also run additional clean-up\nprocedures to remove any resources that Terraform failed to destroy. Do this by\ndeleting any projects used for test execution or by using a tool like the\n[`project_cleanup`](https://github.com/terraform-google-modules/terraform-google-scheduled-function/tree/master/modules/project_cleanup) module.\n| **Warning:** Don't use such tools in a production environment.\n\nOptimize test runtime\n---------------------\n\nTo optimize your test execution time, use the following approaches:\n\n- **Run tests in parallel.** Some testing frameworks support running multiple Terraform tests simultaneously.\n - For example, with Terratest you can do this by adding `t.Parallel()` after the test function definition.\n- **Test in stages.** Separate your tests into independent configurations that can be tested separately. This approach removes the need to go through all stages when running a test, and accelerates the iterative development cycle.\n - For example, in Kitchen-Terraform, split tests into separate suites. When iterating, execute each suite independently.\n - Similarly, using Terratest, wrap each stage of your test with `stage(t, `\u003cvar translate=\"no\"\u003eSTAGE_NAME\u003c/var\u003e`, `\u003cvar translate=\"no\"\u003eCORRESPONDING_TEST\u003cem\u003eFUNCTION\u003c/em\u003e\u003c/var\u003e*)**.\n Set environment variables that indicate which tests to run. For example,\n `SKIP`* \u003cvar translate=\"no\"\u003eSTAGE_NAME\u003c/var\u003e`=\"true\"`.\n - The [blueprint testing framework](https://pkg.go.dev/github.com/GoogleCloudPlatform/cloud-foundation-toolkit/infra/blueprint-test) supports staged execution.\n\nWhat's next\n-----------\n\n- Learn about [general style and structure best practices for Terraform on Google Cloud](/docs/terraform/best-practices/general-style-structure).\n- Learn about [best practices when using Terraform root modules](/docs/terraform/best-practices/root-modules)."]]
