Przejdź do głównej zawartości

Infrastruktura jako kod z Cursor

Twoja aplikacja działa idealnie na laptopie. Teraz musi działać na produkcji: z load balancerem w wielu regionach, zarządzaną bazą danych, CDN dla zasobów statycznych, konfiguracją specyficzną per środowisko i automatycznym rollbackiem. Inżynier infrastruktury, który konfigurował ostatni projekt, odszedł z firmy i nikt nie jest pewien, które pliki Terraform są faktycznie używane, a które to resztki eksperymentów. Musisz zdefiniować infrastrukturę jako kod i potrzebujesz, żeby była poprawna za pierwszym razem — bo źle skonfigurowana security group lub otwarty bucket S3 dzieli jedno wdrożenie od nagłówka w mediach.

Cursor Agent jest zaskakująco skuteczny w infrastrukturze jako kod, ponieważ IaC jest fundamentalnie problemem generowania kodu. Moduły Terraform, konfiguracje Dockera i manifesty Kubernetes podlegają dobrze zdefiniowanym schematom, co oznacza, że AI może generować syntaktycznie poprawne, logicznie sensowne konfiguracje, gdy otrzyma odpowiedni kontekst.

  • Prompty do generowania modułów Terraform dla typowych wzorców infrastrukturalnych
  • Workflow do iterowania na konfiguracjach Dockera z wieloetapowymi buildami
  • Techniki generowania manifestów Kubernetes z istniejących konfiguracji Dockera
  • Reguły projektu, które utrzymują świadomość Cursor na temat twojego dostawcy chmury, konwencji nazewnictwa i polityk bezpieczeństwa
  • Strategia walidacji wygenerowanego kodu infrastrukturalnego przed zastosowaniem

Przed generowaniem jakiegokolwiek kodu infrastrukturalnego zakoduj ograniczenia swojego środowiska. To zapobiega generowaniu zasobów AWS przez Agenta, gdy używasz GCP, lub sugerowaniu otwartych security group w środowisku regulowanym pod kątem compliance.

.cursor/rules/infrastructure.md
# Konwencje infrastrukturalne
## Dostawca chmury
- Główny: AWS (us-east-1, eu-west-1)
- Wersja Terraform: 1.7+
- Wersja providera AWS: ~> 5.0
- Backend stanu: bucket S3 "myapp-tf-state" z blokowaniem DynamoDB
## Konwencja nazewnictwa
- Zasoby: {env}-{service}-{resource} (np. prod-api-alb)
- Wymagane tagi na wszystkich zasobach: Environment, Service, Team, ManagedBy=terraform
## Polityki bezpieczeństwa
- Brak publicznych bucketów S3
- Brak security group z ingress 0.0.0.0/0 (poza ALB na 80/443)
- Wszystkie instancje RDS muszą mieć włączone szyfrowanie at rest
- Wszystkie instancje EC2 muszą używać IMDSv2
- Brak zahardkodowanych poświadczeń w jakimkolwiek pliku konfiguracyjnym
- SSL/TLS wymagany dla wszystkich publicznych endpointów
## Struktura modułów
- Moduły wielokrotnego użytku w modules/
- Konfiguracje środowisk w environments/{env}/
- Wspólne zmienne w variables.tf, outputy w outputs.tf
- Używaj terraform-docs do dokumentacji

Najczęstsze zadanie IaC to tworzenie nowego modułu dla konkretnego komponentu infrastrukturalnego. Cursor doskonale sobie z tym radzi, ponieważ składnia HCL Terraform ma jasne wzorce.

Po wygenerowaniu, zwaliduj moduł przed zastosowaniem:

Okno terminala
cd infrastructure/modules/api-service
terraform init
terraform validate
terraform plan -var-file=../../environments/staging/terraform.tfvars

Możesz przeprowadzić tę walidację w terminalu Cursor, a jeśli terraform validate zawiedzie, wklej błąd z powrotem do trybu Agent, aby go naprawić.

Błędy Terraform są często enigmatyczne. Gdy terraform plan zawiedzie, użyj trybu Ask do diagnozy:

terraform plan zawiódł z:
Error: Invalid reference
on main.tf line 23, in resource "aws_ecs_service" "api":
23: cluster = aws_ecs_cluster.main.arn
Zasób aws_ecs_cluster.main nie jest zdefiniowany w tym module.
Jest w module networking. Jak się do niego odwołać?
@infrastructure/modules/networking/outputs.tf

Tryb Ask wyjaśni, że musisz przekazać ARN klastra jako zmienną z outputów modułu networking, i pokaże dokładnie, jak to połączyć.

Docker to kolejna domena, w której Agent generuje solidne konfiguracje, ponieważ Dockerfile’e podlegają przewidywalnym wzorcom. Kluczem jest podanie Agentowi kontekstu twojej aplikacji.

Jeśli twoim celem wdrożeniowym jest Kubernetes, Cursor może wygenerować manifesty z twojej konfiguracji Dockera:

@Dockerfile @infrastructure/modules/api-service
Wygeneruj manifesty Kubernetes w k8s/ do wdrożenia tej aplikacji:
1. Deployment:
- 3 repliki ze strategią rolling update
- Limity zasobów: 256Mi pamięci, 250m CPU
- Requesty zasobów: 128Mi pamięci, 100m CPU
- Sonda liveness na /health (HTTP, co 10s)
- Sonda readiness na /ready (HTTP, co 5s)
- Zmienne środowiskowe z ConfigMap i Secrets
2. Service:
- Serwis ClusterIP na porcie 80 celujący w port kontenera 8080
3. Ingress:
- Ingress NGINX z terminacją TLS
- Host: api.myapp.com
- Adnotacje rate limitingu
4. HorizontalPodAutoscaler:
- Min 3, max 15 replik
- Docelowe wykorzystanie CPU: 70%
5. Szablony ConfigMap i Secret:
- ConfigMap dla niewrażliwych zmiennych środowiskowych
- External Secrets Operator dla wrażliwych wartości z AWS Secrets Manager
Użyj struktury Kustomize z base/ i overlays/staging/ oraz overlays/production/.

Jedną z najtrudniejszych części IaC jest zarządzanie różnicami między środowiskami. Agent może pomóc w stworzeniu konfiguracji DRY, która różni się tylko tam, gdzie trzeba.

@infrastructure/environments/staging @infrastructure/environments/production
Nasze środowiska staging i production współdzielą te same moduły Terraform,
ale różnią się w:
- Rozmiarach instancji (staging: t3.small, production: t3.large)
- Liczbie replik (staging: 1, production: 3)
- Rozmiarze bazy danych (staging: db.t3.micro, production: db.r6g.large)
- Nazwach domen (staging: staging.myapp.com, production: myapp.com)
- Progach monitoringu (staging: luźne, production: ścisłe)
Utwórz plik terraform.tfvars dla każdego środowiska, który:
1. Definiuje tylko wartości różniące się między środowiskami
2. Używa tych samych nazw zmiennych (zdefiniowanych w variables.tf modułu)
3. Zawiera komentarze wyjaśniające, dlaczego każda wartość się różni
4. Stosuje naszą konwencję nazewnictwa: {env}-{service}-{resource}
@infrastructure/modules/api-service/main.tf
Dodaj zarządzanie sekretami do naszego serwisu ECS:
1. Przechowuj sekrety w AWS Secrets Manager (nie SSM Parameter Store)
2. Odwołuj się do sekretów w definicji tasku ECS jako secrets, nie environment
3. Polityka IAM: rola tasku może tylko czytać sekrety z prefiksem "myapp/{env}/"
4. Automatycznie rotuj poświadczenia bazy danych za pomocą rotacji Secrets Manager
5. Aplikacja czyta sekrety ze zmiennych środowiskowych w runtime
NIE dołączaj żadnych prawdziwych wartości sekretów. Używaj tylko referencji placeholder.
Pokaż mi, jak utworzyć początkowe sekrety za pomocą AWS CLI (jednorazowa konfiguracja).

Agent generuje nieprawidłową składnię HCL. HCL Terraform ma subtelne reguły składniowe (jak to, że końcowe przecinki nie są dozwolone w pewnych miejscach). Zawsze uruchamiaj terraform validate po wygenerowaniu. Jeśli zawiedzie, wklej pełny błąd do trybu Agent — zazwyczaj naprawia składnię HCL za pierwszym razem.

Security groups są zbyt permisywne. Agent domyślnie preferuje wygodę nad bezpieczeństwo. Wygeneruje reguły ingress 0.0.0.0/0, chyba że twoje reguły projektu jawnie tego zabraniają. Reguły infrastrukturalne na początku tego artykułu temu zapobiegają, ale zawsze ręcznie weryfikuj reguły security group.

Wygenerowane zasoby kolidują z istniejącym stanem. Jeśli poprosisz Agenta o utworzenie zasobu, który już istnieje w twoim stanie Terraform, zastosowanie zawiedzie. Użyj najpierw trybu Ask: “Biorąc pod uwagę naszą istniejącą infrastrukturę, jakie zasoby już mamy i co muszę dodać?” Odwołaj się do pliku stanu lub istniejących modułów.

Buildy Dockera są zbyt duże. Agent czasem kopiuje niepotrzebne pliki do obrazu. Sprawdź, czy .dockerignore wyklucza testy, dokumentację i pliki źródłowe. Wieloetapowe buildy powinny kopiować tylko skompilowany output i zależności produkcyjne.

Konfiguracje środowisk rozsynchronizowują się. Gdy aktualizujesz moduł, musisz zaktualizować wszystkie konfiguracje środowisk. Poproś Agenta: “Zmieniłem moduł api-service, dodając nową zmienną ‘enable_waf’. Zaktualizuj wszystkie pliki tfvars środowisk, aby zawierały tę zmienną z odpowiednimi wartościami.”