Terraform in der Gemeinschaft: Planung der PR, Anwendung bei Fusion

In vielen Teams wird Terraform immer noch von jemandem's Laptop aus betrieben. Sie ziehen den neuesten Code, laufen planSchau, lauf! apply- Ich weiß . Es funktioniert, bis es nicht funktioniert: jemand bewirbt eine alte Niederlassung, zwei Personen gleichzeitig, der Laptop hat verschiedene Anbieterversionen oder die einzige Person mit Produktionsnachweisen ist im Urlaub.

Die Lösung ist ein einfacher, bekannter Workflow: Planung bei Pull-Anfrage, Anwendung bei Fusion- Ich weiß . Ich habe es so eingerichtet.

Der Arbeitsfluss

1. Ein Entwickler ändert den Infrastrukturcode auf einer Zweigstelle und öffnet eine Pull-Anfrage.
2. CI läuft terraform plan und veröffentlicht den Plan als Kommentar zur Pull-Anfrage.
3. Die Kritiker betrachten beide Codes und - Der Plan.
4. Nach Genehmigung wird die Anforderung zusammengeführt.
5. CI läuft terraform apply Mit dem Plan, vom Hauptzweig.

Alles wird überprüft, alles wird protokolliert, niemand braucht Produktionsinformationen auf seinem Laptop, und die Hauptniederlassung spiegelt immer wider, was eingesetzt wird.

Der Plan ist die echte Veränderung. Überprüfen Sie den Plan genauso sorgfältig wie den Code.

Option 1: Atlantis

Atlantis ist ein Open-Source-Server, der genau für diesen Workflow entwickelt wurde. Es hört auf, um Anforderung Ereignisse zu ziehen, und Sie steuern es mit Kommentaren:

• Wenn man eine PR-Anzeige macht, läuft Atlantis automatisch. plan und Kommentare zur Ausgabe.
• Kommentar atlantis apply und es gilt, dann kommentiert das Ergebnis.
• Es sperrt die betroffenen Verzeichnisse, so dass zwei PRs nicht den gleichen Zustand gleichzeitig ändern können.

Atlantis läuft in Ihrer eigenen Infrastruktur (oft auf Kubernetes), so dass Anmeldeinformationen niemals Ihre Umgebung verlassen. Es ist einfach, im Kampf getestet und kostenlos. Sie müssen es hosten und pflegen.

Option 2: GitHub-Aktionen (oder jede KI)

Sie können den gleichen Workflow in Ihrem normalen Informanten aufbauen. Eine vereinfachte GitHub-Actions-Version:

name: terraform

on:
  pull_request:
    paths: ["infrastructure/**"]
  push:
    branches: [main]
    paths: ["infrastructure/**"]

permissions:
  contents: read
  id-token: write
  pull-requests: write

jobs:
  terraform:
    runs-on: ubuntu-latest
    defaults:
      run:
        working-directory: infrastructure/live/production/network
    steps:
      - uses: actions/checkout@<sha> # v4
      - uses: hashicorp/setup-terraform@<sha> # v3
      - uses: aws-actions/configure-aws-credentials@<sha> # v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/terraform-${{ github.event_name == 'push' && 'apply' || 'plan' }}
          aws-region: eu-central-1
      - run: terraform init -input=false
      - run: terraform plan -input=false -out=tfplan
      - if: github.event_name == 'pull_request'
        run: terraform show -no-color tfplan > plan.txt
        # post plan.txt as a PR comment with your preferred action
      - if: github.event_name == 'push'
        run: terraform apply -input=false tfplan

Dinge , die man beachten sollte:

• Zwei verschiedene IAM-Rollen: eine nur-lesbare Rolle für Pläne bei Pull-Anfragen und eine Rolle mit Schreibzugriff nur für Anwendungen von main- Ich weiß . Die Vertrauenspolitik beschränkt, welche Zweigstelle welche Rolle übernehmen darf.
• OIDC, keine gespeicherten Cloud-Schlüssel.
• Nutzen Sie GitHub-Umgebungen Die Annahme von Vorschlägen für die Erstellung von Produkten mit den erforderlichen Prüfern gilt, wenn Sie einen zusätzlichen Genehmigungsschritt wünschen.

Eine Feinheit: Der Plan für die Pull-Anfrage und die Anwendung nach dem Merge können sich unterscheiden, wenn sich der Hauptbetrieb dazwischen ändert. Die sichere Lösung ist, die Fusion neu zu planen (wie oben) und diesen Plan anzuwenden.

Option 3: TACOS

"TACOS" (Terraform Automation and Collaboration Software) ist der Spitzname für Plattformen, die dafür entwickelt wurden: HCP Terraform, Raumfahrt, Umgebung, Scalr, Ausrüstung IaCM und andere. Sie fügen hinzu:

• Die Richtlinie als Code (OPA oder Sentinel) auf jedem Plan.
• Drift-Erkennung und geplante Fahrten.
• Stack-Abhängigkeiten, Kostenvoranschläge, Genehmigungen, Prüfprotokolle.
• Selbstbedienung und RBAC für viele Teams.

Sie kosten Geld, sparen aber für größere Organisationen viel Aufbau und Wartung.

Genehmigungen

Wer kann Änderungen der Infrastruktur genehmigen? Einige praktische Regeln:

• CODEOWNERS Das richtige Team überprüft Änderungen an ihrem Teil der Infrastruktur.
• Erforderliche Überprüfungen in der Zweigschutz.
• Für die Produktion gilt eine zusätzliche Genehmigung, über CI-Umgebungen oder die Plattform.
• Pläne, die den Prüfern sichtbar sind, ideal zusammengefasst: Anzahl der hinzugefügten, veränderten und vernichteten Ressourcen. Eine "Zerstörung" der Produktion sollte hervorheben.

Geheimnisse und Authentifizierung des OIDC

Verwahren Sie nie langlebige Cloud-Schlüssel in der Information für Terraform. Verwenden Sie OIDC mit jeder großen Cloud und definieren Sie die Rollen genau. Kombinieren Sie das mit Remote, verschlüsseltem, gesperrtem Zustand, und die empfindlichsten Teile Ihres Setups berühren nie den Laptop eines Entwicklers.

Wie fange ich an?

Wählen Sie einen Terraform-Stack, idealerweise einen mit geringem Risiko. Stellen Sie zuerst einen Plan-on-PR mit einer nur-lesbaren Rolle ein, damit sich das Team daran gewöhnt, Pläne zu überprüfen. Dann fügen Sie Apply-on-Merge mit einer separaten Rolle hinzu. Sobald es funktioniert, rollen Sie es auf die anderen Stapel aus und nehmen Sie den Produktions-Schreibzugriff von Laptops.

Meine Meinung: Infrastrukturänderungen verdienen die gleiche Pipeline-Disziplin wie Anwendungscode. Überprüfen Sie den Plan, verschmelzen Sie und lassen Sie den Roboter sich bewerben.

Desly