Wzorce infrastruktury jako kod

Wzorce infrastruktury jako kod dla agentów AI to cztery receptury (podział monolitu Terraform, bramka na planie, przejęcie dryfu, utwardzenie CloudFormation lub Pulumi) wykonywane przez Claude Code, Codex albo Cursor z poświadczeniami chmurowymi tylko do planu. Maszynowo sprawdzana bramka planu, a nie człowiek czytający HCL, blokuje każde usunięcie lub zastąpienie do zgody wskazanego właściciela.

Ta strona jest dla programistów, którzy odpowiadają za infrastrukturę swojej usługi, i dla liderów technicznych, którzy decydują, czego agent może dotknąć na koncie chmurowym. Dziedziczysz repozytorium Terraform z jednym 900-liniowym main.tf, zaszytymi na sztywno blokami CIDR, providerem przypiętym dwie wersje główne wstecz i terraform plan, który chce zastąpić produkcyjną instancję RDS. Agent podzieli ten plik w kilka minut. Pytanie brzmi: skąd wiesz, że podział niczego nie niszczy, skoro plan ma 400 linii i nikt nie chce go czytać?

Co dają ci te receptury infrastrukturalne

• Konfigurację uprawnień, w której agent może uruchomić terraform plan, ale nie ma poświadczeń, którymi dałoby się zrobić apply
• Krótki plan-gate.sh, który kończy się błędem przy każdym usunięciu lub zastąpieniu, więc przegląd zaczyna się od krótkiej listy, a nie od całego planu
• Prompty do skopiowania: podział na moduły z blokami moved, przegląd planu, przejęcie dryfu blokami import i utwardzenie szablonu CloudFormation
• Tabelę bramek (format, lint, polityki, testy, plan), które dowodzą poprawności zmiany bez czytania każdej linii
• Kroki naprawcze dla blokady stanu, która nie chce się zwolnić, dryfu, przypadkowych zastąpień, podbicia wersji głównej providera i utkniętego wycofania CloudFormation

Ogranicz agenta przed pierwszym promptem

Zabezpieczeniem, które naprawdę trzyma, jest poświadczenie, nie prompt. Agent, który ma tylko rolę do planu, nie zrobi apply, cokolwiek postanowi uruchomić. Skonfiguruj to raz na repozytorium, w tej kolejności.

1. Utwórz tożsamość tylko do planu. W AWS dołącz ReadOnlyAccess oraz dostęp do bucketu ze stanem: odczyt klucza stanu tego stosu i s3:PutObject / s3:DeleteObject wyłącznie na kluczu *.tflock. To wystarcza do terraform plan z natywnym blokowaniem w S3. ReadOnlyAccess daje też s3:GetObject na każdym buckecie w koncie, łącznie z plikami stanu innych stosów, więc dodaj jawny Deny na s3:GetObject dla każdego klucza stanu, który nie należy do tego stosu. Apply działa w CI na innej roli, której agent nigdy nie widzi. Ten sam podział działa w Azure (Reader plus konto magazynu ze stanem) i w Google Cloud (Viewer plus bucket ze stanem). Tożsamości tylko do odczytu dla każdej chmury opisuje strona serwery MCP dla chmur.

2. Zablokuj destrukcyjne polecenia w narzędziu. To tylko siatka na pomyłki, nie zamiennik poświadczenia.

   Claude Code

   W .claude/settings.json (w repozytorium, więc dostaje go cały zespół):

   {
     "permissions": {
       "allow": ["Bash(terraform fmt *)", "Bash(terraform validate *)",
                 "Bash(terraform plan *)", "Bash(terraform show *)", "Bash(tflint *)"],
       "ask":   ["Bash(terraform state *)", "Bash(terraform import *)"],
       "deny":  ["Bash(terraform apply *)", "Bash(terraform destroy *)",
                 "Bash(terraform force-unlock *)", "Bash(terraform state rm *)"]
     }
   }

   Reguły deny są sprawdzane przed ask i allow. Dopasowują tekst polecenia, więc sh -c 'terraform apply' to inna pisownia: dlaczego prawdziwą granicą są piaskownica i poświadczenie, wyjaśnia strona uprawnienia i piaskownica.

   Codex

   # Terminal, katalog główny repozytorium: zgody na żądanie, zapis tylko w workspace
   codex -a on-request -c default_permissions=":workspace"

   Profile uprawnień są w Codex 0.157.1 w wersji beta i to je OpenAI preferuje zamiast --sandbox; nie łącz obu mechanizmów. Codex przekazuje poleceniom zmienne środowiskowe, których nazwy zawierają KEY, SECRET lub TOKEN, chyba że shell_environment_policy stanowi inaczej, więc uruchamiaj Codex z powłoki, w której jest wyłącznie rola do planu.

   Cursor

   Trzymaj agenta Cursora w trybie uruchamiania, który pyta przed poleceniami terminala (strona Run modes w sekcji Agent security dokumentacji Cursora), i uruchamiaj Cursor z powłoki lub profilu, w którym jest wyłącznie rola do planu. Niezależnie od wybranego trybu granicą jest poświadczenie tylko do planu; tryb uruchamiania łapie jedynie pomyłki.

3. Spisz konwencje raz. Umieść je w AGENTS.md (Codex go czyta; Claude Code czyta go, gdy w repozytorium nie ma CLAUDE.md, od wersji 2.1.277 w kanale latest) albo w CLAUDE.md, oraz w regule projektu Cursora:

   ## Infrastructure rules
   - Terraform >= 1.11. S3 backend with `use_lockfile = true`. No new DynamoDB lock tables.
   - Pin providers to the current major (`~> 6.0` for hashicorp/aws) and commit .terraform.lock.hcl.
   - Renames and module moves use `moved` blocks. Never `terraform state mv` in a PR.
   - Adopt existing resources with `import` blocks, not `terraform import`.
   - No hardcoded CIDRs, regions, account IDs or secrets: variables and a secrets manager.
   - You may run fmt, validate, tflint, plan and show. You never run apply or destroy.

Receptura 1: podziel monolit Terraform, niczego nie niszcząc

Podział na moduły zmienia adres każdego zasobu. Bez bloków moved Terraform czyta to jako „usuń stary adres, utwórz nowy”, co w przypadku bazy danych oznacza utratę danych. Z nimi poprawny plan czystej refaktoryzacji to zero zmian: ta jedna liczba jest twoim kryterium akceptacji.

Claude Code

# Terminal, katalog główny repozytorium. Tryb Manual, żeby każda edycja była pokazana przed zapisem
claude --permission-mode manual

Wklej prompt poniżej. Claude Code edytuje pliki, uruchamia terraform plan i czyta jego wynik w tej samej sesji, więc pętla „zero zmian” domyka się bez kopiowania czegokolwiek.

Codex

Zapisz prompt poniżej jako prompts/split-monolith.txt, a potem uruchom:

codex -a on-request -c default_permissions=":workspace" "$(cat prompts/split-monolith.txt)"

Trzymaj prompt w repozytorium, żeby następny podział używał tych samych słów. Jeśli piaskownica blokuje sieć, Codex zapyta, zanim uruchomi terraform plan poza nią; zatwierdzaj plan, nigdy apply.

Cursor

Otwórz agenta w Plan Mode, wklej prompt i zatwierdź granice modułów, zanim zapisze pliki. Przełącz się na Agent, żeby wykonać plan, i uruchom terraform plan w zintegrowanym terminalu, gdy o to poprosi.

Prompt do skopiowania: podział main.tf na moduły bez zmian w planie

Refactor main.tf into three local modules: modules/network (VPC, subnets,
NAT, route tables), modules/data (RDS, ElastiCache) and modules/compute
(ASG, ALB, launch template). Rules:
1. Before writing files, list every resource with its current address and
   its new address, and the variables each module needs. Wait for my OK.
2. For every address change, add a `moved` block in moved.tf. Do not use
   terraform state mv.
3. Move hardcoded CIDRs and the region into variables.tf with the current
   values as defaults, so the plan does not change.
4. Run terraform fmt -recursive, terraform validate, then
   terraform plan -out=tfplan -input=false.
5. Done means the plan reports "No changes". If it does not, show me each
   resource the plan would change and why, fix it, and plan again.
Never run terraform apply.

Jeśli plan nadal pokazuje zmiany, przyczyna to prawie zawsze jedna z trzech rzeczy: brakujący blok moved, wartość domyślna inna niż stary literał albo zamiana count na for_each (indeks zmienia się z [0] na ["name"] i to też wymaga bloku moved). Poproś agenta, żeby dla każdego zasobu wskazał, która to z nich.

Receptura 2: zamień plan w bramkę, której nie czytasz linia po linii

Plan na 400 linii to miejsce, w którym przegląd zawodzi, bo jedno -/+ na bazie danych ginie wśród 60 zmian tagów. Odwróć kolejność: skrypt wyciąga destrukcyjne akcje z planu w formacie maszynowym, a człowiek przegląda tylko tę listę.

#!/usr/bin/env bash
# scripts/plan-gate.sh: exit 2 when the plan deletes or replaces anything
set -euo pipefail
terraform plan -out=tfplan -input=false -lock-timeout=60s
terraform show -json tfplan > plan.json
jq -r '.resource_changes[]?
  | select(.change.actions | index("delete"))
  | "\(.change.actions | join("/"))\t\(.address)"' plan.json > destructive.txt
jq '[.resource_changes[]? | {address, actions: .change.actions,
  replace_paths: .change.replace_paths}]' plan.json > plan-summary.json
jq -r '[.resource_changes[]?.change.actions | join("/")] | group_by(.)
  | map("\(.[0]): \(length)") | .[]' plan.json
if [ -s destructive.txt ]; then
  echo "Delete or replace needs a named approver:"; cat destructive.txt; exit 2
fi

W terraform show -json zastąpienie pojawia się jako ["delete","create"] albo ["create","delete"], więc dopasowanie do delete łapie oba przypadki. Uruchamiaj skrypt w sesji agenta i ponownie w CI. W CI zapisz destructive.txt jako wynik zadania (job output); gdy nie jest pusty, zadanie apply trafia do chronionego środowiska, którego wymaganym recenzentem jest właściciel usługi, a apply działa wyłącznie z zapisanego i przejrzanego tfplan.

Plan i stan przechowują sekrety otwartym tekstem

tfplan, plan.json i plik stanu zawierają wartości wrażliwe (hasła do baz danych, wygenerowane klucze) bez maskowania; flaga sensitive ukrywa je tylko w wyjściu CLI. Dodaj tfplan, plan.json i plan-summary.json do .gitignore, nigdy nie publikuj plan.json ani tfplan jako publicznego artefaktu CI i ogranicz s3:GetObject roli do planu do klucza stanu tego stosu. Dlatego bramka zapisuje plan-summary.json (adresy, akcje i ścieżki atrybutów wymuszających zastąpienie, bez wartości): agent czyta ten plik i destructive.txt, a nie plan.json.

Prompt do skopiowania: przegląd planu, zanim ktokolwiek go zatwierdzi

Run scripts/plan-gate.sh, then read destructive.txt and plan-summary.json.
Do not open plan.json, tfplan or the state: they hold secrets. Produce:
1. The action summary the script printed.
2. For every line in destructive.txt: the attribute that forces it
   (from replace_paths and the provider docs), whether it loses
   data or causes downtime, and a way to avoid it (moved block,
   lifecycle { prevent_destroy = true }, create_before_destroy, or an
   attribute that can change in place).
3. Any update to a security group, IAM policy or KMS key, listed separately.
End with GO or NO-GO and one sentence of reason. Do not run apply and do
not edit any .tf file in this step.

W ramach receptury 1 dodaj lifecycle { prevent_destroy = true } do zasobów stanowych (bazy danych, buckety z danymi, klucze KMS). Terraform odrzuci wtedy każdy plan, który je usuwa, więc najdroższy błąd staje się błędem planu.

Receptura 3: przejmij dryf z konsoli blokami import

Ktoś w trakcie incydentu dodał w konsoli regułę grupy zabezpieczeń i teraz każdy plan chce ją usunąć. Nie pozwól agentowi nadpisać dryfu przez apply: ta reguła może być tym, co powstrzymuje incydent.

Uruchom terraform plan -refresh-only, żeby zobaczyć dokładnie, co zmieniło się poza Terraformem. Potem zdecyduj dla każdego zasobu: przejąć go, cofnąć zmianę w konsoli czy dopasować konfigurację. Przy przejmowaniu Terraform 1.5 i nowszy zapisuje import jako kod, więc przechodzi on przegląd jak każda inna zmiana.

Prompt do skopiowania: uzgodnienie dryfu po incydencie

Run terraform plan -refresh-only -input=false and list every drifted
attribute. For each resource the console created that is not in state,
write an `import` block in imports.tf and run
terraform plan -generate-config-out=generated.tf to draft its config.
Then move each generated resource into the right module, remove computed
and default-valued arguments, and re-run plan until the only actions are
imports. Put each drifted item in one of three buckets (adopt, revert in
the console, change config to match) with a one-line reason. Do not run
terraform import, terraform state commands or apply.

Serwer MCP chmury przyspiesza tę pracę: z dostępem do odczytu agent sam wylistuje prawdziwe zasoby, zamiast prosić cię o wklejenie wyników z konsoli. Podłącz go tylko do odczytu, tak jak pokazuje strona serwery MCP dla chmur.

Receptura 4: utwardź szablon CloudFormation lub stos Pulumi

Ta sama dyscyplina działa z innym poleceniem podglądu. W CloudFormation aws cloudformation deploy --no-execute-changeset tworzy zestaw zmian (change set), który agent może przeczytać bez jego wykonania. W Pulumi planem dla człowieka jest pulumi preview --diff, a dla bramki pulumi preview --json: kroki, których op to delete, replace, create-replacement lub delete-replaced, odfiltruj do destructive.txt, tak samo jak robi to plan-gate.sh. Bramka jest ta sama: wypisz zastąpienia i blokuj do zgody właściciela.

Prompt do skopiowania: przegląd gotowości produkcyjnej szablonu CloudFormation

Review infrastructure.yaml for production. Check that every RDS instance
and EBS volume has DeletionPolicy: Snapshot and UpdateReplacePolicy:
Snapshot, storage encryption and Multi-AZ; that security groups reference
each other instead of 0.0.0.0/0 on internal ports; and that no secret is a
plaintext parameter (move DatabasePassword to Secrets Manager with a
dynamic reference). Output the fixes highest risk first, each with the
exact YAML change. Then create a change set with
aws cloudformation deploy --no-execute-changeset and list every resource
whose Replacement is True or Conditional. Do not execute the change set.

Jak zweryfikować infrastrukturę napisaną przez agenta bez czytania każdej linii?

Ułóż kontrole tak, żeby każda mechanicznie łapała jedną klasę błędów, a człowiek patrzył tylko na to, co przez nie przejdzie. Uruchamiaj je w tej kolejności, od najtańszej, w sesji agenta i ponownie w CI.

Bramka	Polecenie	Łapie	Blokuje build, gdy
Format i składnia	terraform fmt -check -recursive i terraform validate	Wymyślone argumenty, błędy typów, złe referencje	jest jakikolwiek błąd
Lint	tflint --recursive	Nieistniejące typy instancji, przestarzałą składnię, nieużywane deklaracje	jest jakikolwiek błąd
Polityki statyczne	checkov -d .	Publiczne buckety, niezaszyfrowane magazyny, otwarte grupy zabezpieczeń	kontrola nie przechodzi i nie ma jej na przejrzanej liście wyjątków
Zachowanie	terraform test	Moduł, który przestał spełniać swój kontrakt	którykolwiek przebieg testu się nie powiedzie
Polityki planu	conftest test plan.json	Twoje własne reguły zastosowane do faktycznie planowanych wartości	pojawi się jakikolwiek deny
Destrukcja	scripts/plan-gate.sh	Usunięcia i zastąpienia	destructive.txt ma choć jedną linię

Wersje sprawdzone 26 września 2026: Terraform 1.16.4, provider hashicorp/aws 6.66.0, tflint 0.64.0, checkov 3.3.19, conftest 0.70.1. Polityka planu dla conftest to kilka linii Rego nad plan.json:

policy/no_public_ssh.rego

package main
import rego.v1

deny contains msg if {
  some rc in input.resource_changes
  rc.type == "aws_security_group_rule"
  rc.change.after.type == "ingress"
  "0.0.0.0/0" in rc.change.after.cidr_blocks
  rc.change.after.from_port <= 22
  rc.change.after.to_port >= 22
  msg := sprintf("%s opens SSH to the internet", [rc.address])
}

Kto zatwierdza. Agent może stwierdzić, że kontrole są zielone. Nie może zatwierdzać. Pull request, który przechodzi wszystkie bramki i ma pusty destructive.txt, potrzebuje jednego recenzenta diffu. Pull request z jakąkolwiek destrukcyjną linią wymaga, żeby właściciel usługi zatwierdził tę listę imiennie, a apply rusza w CI z przejrzanego tfplan. Dołącz wynik bramek do pull requesta jako jego pakiet dowodów, żeby recenzent czytał sześć wyników i krótką listę zamiast HCL.

Niech agent korzysta z rejestru, a nie z pamięci

Częstym źródłem zepsutego HCL są argumenty providera, które agent pamięta ze starszej wersji głównej. Naprawiają to dwa dodatki, a pełną konfigurację opisuje strona serwery MCP dla infrastruktury.

Serwer Terraform MCP od HashiCorp bez tokenu rejestruje tylko narzędzia rejestru, które sprawdzają aktualną dokumentację providerów i modułów. Z samej konstrukcji działa więc tylko do odczytu:

Claude Code

claude mcp add terraform -s project -- docker run -i --rm hashicorp/terraform-mcp-server:1.3.0

Codex

codex mcp add terraform -- docker run -i --rm hashicorp/terraform-mcp-server:1.3.0

Cursor

W .cursor/mcp.json:

{ "mcpServers": { "terraform": {
  "command": "docker",
  "args": ["run", "-i", "--rm", "hashicorp/terraform-mcp-server:1.3.0"] } } }

Umiejętności agentowe HashiCorp (hashicorp/agent-skills, MPL-2.0) zawierają konwencje: refactor-module do receptury 1, terraform-search-import do receptury 3, terraform-test i terraform-style-guide do bramek. W Claude Code zainstaluj plugin, a w Codex i Cursorze pojedyncze umiejętności przez CLI skills (1.7.0):

# Claude Code
claude plugin marketplace add hashicorp/agent-skills
claude plugin install terraform@hashicorp
# Codex, Cursor i inni agenci: wybieraj umiejętności pojedynczo
npx skills add hashicorp/agent-skills/plugins/terraform/skills/refactor-module

Cały plugin ładuje 16 umiejętności i kosztuje około 2150 tokenów stale obecnych w każdej sesji (claude plugin details terraform@hashicorp, 26 września 2026); każda umiejętność dokłada 0,5k–7k, gdy się uruchomi. Szerszy przegląd znajdziesz na stronie serwery MCP dla infrastruktury. Nie instaluj dodatkowo terraform@claude-plugins-official: rejestruje drugi serwer MCP terraform przypięty do starszego obrazu 0.4.0. Sięgaj po umiejętność, gdy chcesz konwencji, a po serwer MCP, gdy agent potrzebuje aktualnych danych z rejestru.

Kiedy Terraform prowadzony przez agenta się psuje

Blokada stanu nie chce się zwolnić

Zabite zadanie CI albo przerwany plan zostawia blokadę i każde uruchomienie kończy się Error acquiring the state lock. Sprawdź w CI, że żaden apply nie trwa. Potem człowiek z rolą do apply uruchamia terraform force-unlock LOCK_ID, z identyfikatorem z komunikatu błędu. Przy use_lockfile = true blokada to obiekt S3 obok stanu o nazwie <key>.tflock; przy przestarzałym ustawieniu dynamodb_table to element w DynamoDB. Lista deny agenta celowo blokuje force-unlock: zdjęcie blokady w trakcie prawdziwego apply psuje stan.

Jednolinijkowa zmiana chce zastąpić pół VPC

Zmiana nazwy zasobu, przejście z count na for_each albo zmieniony tag nazwy w launch template potrafią wywołać kaskadę zastąpień. plan-gate.sh pokazuje ich listę. Naprawa: dodaj bloki moved dla zmian nazw, cofnij atrybut wymuszający zastąpienie albo podziel zmianę. -target używaj tylko do diagnozy, nigdy jako sposobu wdrożenia zmiany: sam Terraform ostrzega, że służy do wyjątkowych sytuacji.

Agent podbija wersję główną providera razem z refaktoryzacją

Przejście hashicorp/aws z ~> 5.0 na ~> 6.0 zmienia argumenty i wartości domyślne. Wmieszane w refaktoryzację sprawia, że kontrola „zero zmian” traci sens. Wprowadź podbicie w osobnym pull requeście: terraform init -upgrade, commit .terraform.lock.hcl, bramki, a agent wyjaśnia każdy zmieniony zasób na podstawie przewodnika aktualizacji providera pobranego przez serwer Terraform MCP.

Po incydencie plan walczy z rzeczywistością

Plan chce usunąć regułę, której nikt nie zapisał w kodzie. Zatrzymaj się i wykonaj recepturę 3. Nigdy nie każ agentowi „wyczyścić planu” bez wcześniejszego widoku refresh-only: usunie zmianę z konsoli, co może ponownie otworzyć incydent.

CloudFormation utknął w UPDATE_ROLLBACK_FAILED

Poproś agenta, żeby przeczytał aws cloudformation describe-stack-events i wskazał zasób, który zablokował wycofanie, oraz powód. Jeśli możesz, usuń przyczynę poza stosem. W przeciwnym razie człowiek uruchamia aws cloudformation continue-update-rollback z tym zasobem w --resources-to-skip, a potem przywraca zgodność zasobu z szablonem.

Co dalej z infrastrukturą jako kodem

Warunkiem wstępnym tych receptur jest środowisko pracy agenta, które trzyma granice: uprawnienia i piaskownica. Następny krok to umieszczenie bramek i apply w potoku.

Wzorce potoków CI/CD Uruchamiaj plan-gate.sh przy każdym pull requeście i rób apply tylko z przejrzanego planu.

Infrastruktura jako kod z asystentami AI Pełny przepływ: ograniczenia, generowanie, przegląd bezpieczeństwa i polityki kosztowe.

Serwery MCP dla infrastruktury Serwery Terraform i Kubernetes MCP w trybie tylko do odczytu, z kosztem kontekstu.

Wzorce orkiestracji Kubernetes Zarządzaj obciążeniami na świeżo utworzonym klastrze z tą samą dyscypliną przeglądu.