Wzorce infrastruktury jako kod

Dziedziczysz repozytorium Terraform z jednym 900-liniowym plikiem main.tf, zaszytymi na sztywno blokami CIDR, bez zdalnego backendu i z terraform apply, które chce wymienić produkcyjną instancję RDS. Agent AI z radością dołoży do tego kolejne 900 linii, jeśli mu na to pozwolisz. Umiejętnością, która pozwala dostarczać stabilną infrastrukturę, nie jest „zmuszenie AI do pisania HCL” — jest nią pokierowanie AI tak, by produkowało małe, łatwe do recenzji diffy, a następnie przeczytanie każdej linii planu, zanim cokolwiek dotknie prawdziwego konta.

Ten przepis pokazuje prompty i mechanizmy zabezpieczające, które zamieniają Cursor, Claude Code i Codex w ostrożnego partnera do IaC — dla Terraform, CloudFormation i Pulumi.

Co z tego wyniesiesz

• Wielokrotnego użytku prompt, który refaktoryzuje monolityczny plik Terraform na moduły ze zdalnym, blokowanym backendem
• Prompt „recenzji planu”, który zmusza agenta do wyjaśnienia każdej operacji destroy/replace przed wykonaniem apply
• Przepływ wykrywania dryfu i importu, który możesz uruchomić, gdy konsola i stan się rozjeżdżają
• Konfigurację MCP dla AWS/Azure/Kubernetes, dzięki której agent czyta żywe zasoby zamiast zgadywać
• Playbook naprawczy na trzy awarie, które naprawdę wyrywają ze snu: blokady stanu, dryf i przypadkowy zasięg rażenia

Najpierw skonfiguruj reguły i serwery MCP

Zanim wpiszesz jakikolwiek prompt, daj agentowi dwie rzeczy: plik z regułami, by przestał wymyślać Twoje konwencje na nowo, oraz dostęp przez MCP, by mógł czytać żywy stan chmury zamiast halucynować nazwy zasobów.

Konfiguracja MCP jest identyczna we wszystkich trzech narzędziach — wszystkie czytają ten sam rejestr serwerów. Zestaw AWS to grupa wyspecjalizowanych serwerów w Pythonie (uruchamianych przez uvx), a nie pojedynczy obraz Dockera:

# AWS — wybierz konkretny serwer awslabs, którego potrzebujesz (Python, przez uvx)
claude mcp add aws-api -- uvx awslabs.aws-api-mcp-server@latest
claude mcp add aws-core -- uvx awslabs.core-mcp-server@latest
# Przekazuj poświadczenia przez profil, nigdy klucze wpisane wprost:
#   AWS_PROFILE=prod claude mcp add aws-api -- uvx awslabs.aws-api-mcp-server@latest

# Azure (npm)
claude mcp add azure -- npx -y @azure/mcp@latest

# Kubernetes (npm)
claude mcp add k8s -- npx -y kubernetes-mcp-server

W Cursorze i Codeksie te same serwery trafiają do .mcp.json (lub ustawień MCP w IDE) z identycznymi command/args. Po podłączeniu serwera AWS zapytanie „wylistuj instancje RDS na tym koncie wraz z wersjami silnika” zwraca prawdziwe dane, dzięki czemu refaktoryzacja agenta celuje w zasoby, które naprawdę istnieją.

W przypadku reguł pomiń przestarzały plik .cursorrules (Cursor go wycofał). Użyj .cursor/rules/iac.mdc dla Cursora oraz CLAUDE.md / AGENTS.md dla Claude Code i Codeksa:

# .cursor/rules/iac.mdc  (CLAUDE.md / AGENTS.md dla Claude Code i Codex)
- Wyłącznie zdalny stan: backend S3 + tabela blokad DynamoDB. Nigdy stan lokalny.
- Przypinaj providery (~> 5.0) i przypinaj wersje silnika do aktualnie wspieranego wydania.
- Taguj każdy zasób etykietami Environment i ManagedBy.
- Żadnych zaszytych na sztywno bloków CIDR, regionów ani sekretów — używaj zmiennych i menedżera sekretów.
- Zaproponuj plan i poczekaj na akceptację przed jakimkolwiek apply.

Przepływ pracy: refaktoryzuj, zrecenzuj, wykonaj apply

Niebezpieczny moment w IaC wspomaganym przez AI to luka między „agent napisał HCL” a „uruchomiłem apply”. Zamknij ją trzema krokami: zakreśl zakres refaktoryzacji, wymuś recenzję planu, a potem wykonaj apply za bramką wymagającą człowieka.

1. Zrefaktoryzuj monolit na moduły. Wskaż agentowi konkretny plik i jawnie nazwij providery oraz backend, by dostać diff, który możesz recenzować moduł po module, zamiast przepisania od zera.

2. Każ agentowi zrelacjonować plan. Niech uruchomi terraform plan i wyjaśni każdą linię ~ (aktualizacja w miejscu), -/+ (wymiana) i - (zniszczenie). Wymiany na zasobach stanowych (RDS, EBS) to miejsce, gdzie zaczynają się incydenty o trzeciej w nocy.

3. Wykonaj apply za bramką. Nigdy nie pozwalaj agentowi wykonywać apply autonomicznie na prawdziwym koncie. Uruchom apply samodzielnie albo zabezpiecz go w CI za wymaganą recenzją.

Oto krok refaktoryzacji we wszystkich trzech narzędziach. To prompt jest elementem nośnym — narzędzia różnią się tylko tym, jak przekazujesz im plik i jak agent uruchamia plan.

Cursor

W trybie Agent dodaj plik do kontekstu i pozwól mu edytować w nowych plikach modułów z checkpointami, dzięki czemu możesz cofnąć błędny podział:

@main.tf Refactor this into modules: network (VPC, subnets, NAT),
data (RDS, ElastiCache), and compute (ASG, ALB). Move every hardcoded
CIDR and region into variables.tf with sensible defaults. Add an S3
backend with a DynamoDB lock table in backend.tf. Tag every resource
with Environment and ManagedBy. Show me the module boundaries before
writing files.

Gdy zapisze pliki, poproś Cursora, by uruchomił terraform plan w zintegrowanym terminalu i podsumował zmiany. Zrób checkpoint przed zaakceptowaniem, dzięki czemu błędny podział podsieci to jedno kliknięcie do cofnięcia.

Claude Code

Claude Code edytuje pliki i uruchamia plan w jednej sesji terminala, co jest idealne dla pętli recenzji:

claude "Refactor main.tf into network, data, and compute modules.
Move hardcoded CIDRs and regions into variables. Add an S3 backend
with DynamoDB state locking. Then run 'terraform plan' and walk me
through every resource that will be replaced or destroyed — I have
not approved an apply."

Ponieważ sam uruchamia plan i czyta jego wynik, oznaczy na przykład, że zmiana engine_version w RDS wymusza wymianę — zanim przekonasz się o tym w bolesny sposób.

Codex

Użyj Codex CLI z bramką akceptacji, by nie mógł wykonać apply bez Ciebie, albo przekaż refaktoryzację do Codex Cloud na worktree, żeby dostać PR do recenzji:

codex --ask-for-approval on-request \
  "Split main.tf into network/data/compute modules, extract CIDRs and
   regions into variables, add an S3 + DynamoDB locked backend, then run
   terraform plan and explain every replace/destroy. Do not apply."

W przypadku większych repozytoriów odpal go w Codex Cloud na worktree gałęzi — produkuje podział na moduły jako pull request, który recenzujesz jak każdy inny, trzymając apply za istniejącymi regułami ochrony gałęzi.

Ta sama pętla działa dla CloudFormation (aws cloudformation deploy --no-execute-changeset, by uzyskać change set, który agent wyjaśni) i Pulumi (pulumi preview zamiast terraform plan). Narzędzie się zmienia; dyscyplina „wyjaśnij diff, zanim dotkniesz konta” pozostaje ta sama.

Prompty gotowe do skopiowania

Wskazówka

Bezpiecznie zrefaktoryzuj monolit Terraform:

“Refactor @main.tf into three modules — network, data, and compute. Move every hardcoded CIDR block and AWS region into variables.tf with documented defaults. Add a remote backend in backend.tf using an S3 bucket plus a DynamoDB table for state locking. Tag every resource with Environment and ManagedBy = "terraform". Pin the AWS provider to ~> 5.0. Output the proposed module boundaries and variable list first; wait for my approval before writing files.”

Wskazówka

Wymuś recenzję planu przed jakimkolwiek apply:

“Run terraform plan and produce a table of every resource change grouped by action: update-in-place, replace (-/+), and destroy. For each replace or destroy, state which attribute change triggered it and whether it causes downtime or data loss (call out RDS, EBS volumes, and anything stateful explicitly). Do not run terraform apply. End with a one-line go/no-go recommendation.”

Wskazówka

Pogódź dryf między konsolą a stanem:

“The AWS console shows a security group rule and two subnet tags that are not in our Terraform state. Using the AWS MCP server, list the real resources, then tell me for each one whether to (a) terraform import it, (b) add it to config to match reality, or (c) revert it in the console. Generate the exact terraform import commands for anything in category (a). Do not modify state until I confirm the list.”

Wskazówka

Utwardź wygenerowany szablon CloudFormation:

“Review @infrastructure.yaml for production-readiness. Check that the RDS instance has DeletionPolicy: 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). Output a prioritized list of fixes with the exact YAML to change, highest-risk first.”

MCP i Skille, które zmieniają ten przepływ pracy

Zestaw MCP dla AWS (awslabs/mcp) to dodatek o największej dźwigni: serwery aws-api i cost-analysis pozwalają agentowi czytać żywe zasoby i cenniki, dzięki czemu wykrywanie dryfu i dobór rozmiaru zasobów opierają się na Twoim prawdziwym koncie, a nie na założeniach. Serwery Azure i Kubernetes robią to samo dla tych platform.

Gdy potrzebujesz tylko jednozadaniowego wzbogacenia — powiedzmy, konwencji układu modułów Terraform z określonym zdaniem — Agent Skill jest lżejszy niż trwałe połączenie MCP. Skille instalują się jednym uniwersalnym poleceniem i działają w Claude Code, Cursorze i Codeksie:

npx skills add <owner/repo>

Zasada kciuka: sięgaj po serwer MCP, gdy agent potrzebuje żywego, trwałego połączenia (odczyt konta, zapytanie o cennik); sięgaj po Skill, gdy chcesz po prostu wstrzyknąć wielokrotnego użytku konwencje lub listę kontrolną.

Kiedy to się sypie

Uwaga

Blokada stanu nie chce się zwolnić. Padnięty job CI lub ubity apply zostawia blokadę w DynamoDB i każdy plan kończy się błędem Error acquiring the state lock. Upewnij się, że żaden apply faktycznie nie jest w toku, a następnie wykonaj terraform force-unlock <LOCK_ID> (identyfikator znajduje się w komunikacie błędu). Jeśli force-unlock nie chce zadziałać, usuń element blokady bezpośrednio: aws dynamodb delete-item --table-name terraform-state-lock --key '{"LockID":{"S":"<LOCK_ID>"}}'. Nigdy nie wykonuj force-unlock, gdy prawdziwy apply jest w trakcie — możesz uszkodzić stan.

Uwaga

Dryf: plan agenta walczy z rzeczywistością. Ktoś zmienił zasób w konsoli, więc plan pokazuje zmiany, których nie napisałeś. Uruchom terraform plan -refresh-only, by zobaczyć dokładnie, co się rozjechało, a potem zdecyduj per zasób: terraform import, by go przyjąć, edycja konfiguracji, by dopasować, albo cofnięcie ręcznej zmiany. Nie pozwól agentowi na ślepo zrobić apply ponad dryfem — tak właśnie kasuje się ręcznie dodaną regułę firewalla, która powstrzymywała incydent.

Uwaga

Zasięg rażenia: jednoliniowa zmiana chce wymienić pół VPC. Zmiana tagu lub nazewnictwa może wymusić wymianę podsieci i wszystkiego, co w nich jest. Przed wykonaniem apply zakreśl zakres: terraform plan -target=module.network, by wyizolować, a linie -/+ w planie powiedzą Ci, co jest odtwarzane. Jeśli refaktoryzacja agenta zmienia nazwy zasobów, użyj terraform state mv old.name new.name, by przenieść je w stanie, zamiast niszczyć i tworzyć od nowa.

CloudFormation ma ten sam kształt awarii z innej strony: stos utknięty w UPDATE_ROLLBACK_FAILED zwykle wymaga continue-update-rollback z problematycznym zasobem w --resources-to-skip. Poproś agenta, by najpierw przeczytał zdarzenia stosu i wskazał zasób, który zablokował wycofanie, zanim go ruszysz.

Co dalej

Potoki CI/CD Zabezpiecz terraform apply za zrecenzowanym potokiem, zamiast uruchamiać go z własnego laptopa.

Wzorce Kubernetes Gdy klaster już istnieje, prowadź obciążenia i GitOps z tą samą dyscypliną recenzji.

Wzorce Dockera Buduj obrazy, które wdraża Twój IaC, z pomocą AI przy buildach wieloetapowych i odchudzaniu.

Monitoring i logowanie Wepnij obserwowalność w infrastrukturę, którą właśnie udostępniłeś.