Testinfrastrukturcode

Fragen Sie einen Entwickler, ob er Anwendungscode ohne Tests zusammenführen würde, und er wird Sie seltsam ansehen. Wenn man das gleiche über Terraform fragt, dann schütteln viele Teams mit den Schultern: plan und schau es dir an".

Ein Plan zu lesen ist nützlich, aber es ist nicht dasselbe wie zu testen. Es zeigt nicht, ob das Modul wie vorgesehen funktioniert, ob eine Änderung etwas anderes verletzt oder ob Sicherheitsregeln befolgt werden. Der Infrastrukturcode braucht auch Tests, nur eine andere Art.

Die Testpyramide für Infrastruktur

Wie bei Anwendungs-Tests gibt es auch bei Infrastruktur-Tests Schichten, von billig und schnell bis langsam und teuer:

1. Statische Kontrollen: Formatierung, Validierung, Linting, Sicherheitsscan. Sekunden, keine Wolke nötig.
2. Politikprüfungen: Regeln, denen jeder Plan folgen muss. Sekunden, mit der Planleistung.
3. Prüfungen nach Einheitsart: Überprüfung der Modullogik mit einem Plan oder mit verhöhten Anbietern. - Schnell. - Ich weiß.
4. IntegrationsprüfungenWir haben eine Reihe von Möglichkeiten, um die Daten zu verarbeiten. Minuten, das kostet Geld.

Der größte Teil des Wertes stammt aus den ersten beiden Schichten. Das letzte ist es wert für wichtige gemeinsame Module.

Erstmal billige Schecks .

Diese Tests sollten bei jedem Commit durchgeführt werden, vorzugsweise als Pre-Commit-Hooks und in CI:

terraform fmt -check -recursive
terraform validate
tflint --recursive
checkov -d .          # or: trivy config .

• fmt und validate Syntax und Formatierungsprobleme.
• Schnapp erfasst anbieterspezifische Fehler: ungültige Instanztypen, veraltete Argumente, fehlende Tags.
• - Ich weiß. oder Trivy Sicherheitsfehler erkennen: öffentliche Buckets, offene Sicherheitsgruppen, fehlende Verschlüsselung.

Sie sind schnell, frei und fangen eine überraschende Anzahl von echten Problemen auf.

Der beste Infrastrukturfehler ist der, der vorher erwischt wurde. terraform plan Ich habe nie mit deiner Wolke gesprochen.

Terraformprüfung

Seit Version 1.6 verfügt Terraform über ein integriertes Test-Framework (OpenTofu hat ein Äquivalent mit tofu test) Die Tests werden in HCL, in .tftest.hcl Akten:

# tests/bucket.tftest.hcl
variables {
  name        = "acme-test-logs"
  environment = "staging"
}

run "bucket_is_private_and_encrypted" {
  command = plan

  assert {
    condition     = aws_s3_bucket_public_access_block.this.block_public_acls == true
    error_message = "Bucket must block public ACLs."
  }

  assert {
    condition     = aws_s3_bucket.this.tags["environment"] == "staging"
    error_message = "Bucket must be tagged with its environment."
  }
}

Mit command = planDie Tests gehen gegen den Plan, ohne etwas zu schaffen. Mit command = apply, sie schaffen echte Ressourcen und zerstören sie danach. Sie können auch Schein-Anbieter, wodurch die Einheitstests schnell und kostenlos werden.

Für Modul-Autoren ist dies der einfachste Weg, um mit dem Testen zu beginnen. Keine neue Sprache, keine zusätzlichen Werkzeuge.

Terratest

Terratest, von Gruntwork, ist eine Go-Bibliothek für Integrationstests. Es setzt echte Infrastruktur ein, führt Kontrollen gegen sie durch (HTTP-Anfragen, SSH-Befehle, API-Aufrufe) und zerstört sie.

func TestWebModule(t *testing.T) {
    opts := &terraform.Options{TerraformDir: "../examples/web"}
    defer terraform.Destroy(t, opts)
    terraform.InitAndApply(t, opts)

    url := terraform.Output(t, opts, "url")
    http_helper.HttpGetWithRetry(t, url, nil, 200, "OK", 30, 10*time.Second)
}

Es ist mächtig, weil es testet, ob die Infrastruktur tatsächlich funktioniert, nicht nur, ob sie richtig konfiguriert ist. Es ist auch langsamer, braucht Go-Kenntnisse und kostet echtes Geld für jeden Lauf.

Politikprüfungen

Die Richtlinien antworten "Ist das erlaubt?" für jede Änderung, unabhängig davon, wer sie geschrieben hat:

• OPA / Conftest mit Richtlinien in Rego geschrieben, gegen den Plan im JSON-Format laufen.
• Zollpolitik von Checkov in Python oder YAML.
• Der Wachmann in HCP Terraform oder OPA Integration in andere Plattformen.

Beispielregeln: keine öffentlichen S3-Buckets, alle Ressourcen müssen ein Eigentümertag haben, nur genehmigte Instanztypen, Produktionsdatenbanken müssen Löschschutz haben.

terraform plan -out=plan.out
terraform show -json plan.out > plan.json
conftest test plan.json --policy policies/

Bezahlung von Testumgebungen

Integrationstests kosten Geld. Möglichkeiten, es unter Kontrolle zu halten:

• Ein eigenes Testkonto mit Budgets und Warnungen.
• Immer zerstören Nach Tests und nachts eine Reinigung durchführen (Tools wie Cloud-Nuke oder Aws-Nuke) für alles, was zurückbleibt.
• Kleine, billige Ressourcen in Prüfbeispielen.
• Integrationstests auf Merge oder nächtlich ausführenNicht bei jedem Kommit.
• Testmodule, nicht ganze Umgebungen.

Also, wo fange ich an?

Fügen Sie heute statische Kontrollen an CI hinzu. Schreib ein paar . terraform test Behauptungen für Ihr am häufigsten verwendetes Modul. Fügen Sie ein oder zwei Richtlinien zu Ihren wichtigsten Regeln hinzu. Nur dann wird Terratest hinzugefügt, wenn ein Modul kritisch genug ist, um die Zeit und Kosten zu rechtfertigen.

Meine Meinung: Infrastruktur versagt auf kostspielige Weise. Ein paar billige Tests sparen jetzt eine sehr teure Lektion später.

Desly