Przepisy DevOps i infrastruktury

Przepisy DevOps to pięć stron promptów do skopiowania dla Claude Code, Codeksa i Cursora: Dockerfile, manifesty Kubernetes, pipeline’y CI/CD, infrastruktura jako kod i monitoring. Każdy przepis trzyma się jednej zasady: agent pisze konfigurację, a maszynowa kontrola potwierdza ją, zanim człowiek zatwierdzi zmianę.

Ta strona jest dla programistów, którzy oddają agentowi pisanie konfiguracji dostarczania, i dla tech leadów odpowiedzialnych za pipeline, przez który ta konfiguracja przechodzi. Znasz ten scenariusz: obraz o rozmiarze 1,2 GB, rollout zawieszony w CrashLoopBackOff albo zielony pipeline, bo agent po cichu osłabił skan, który nie przechodził.

Który przepis DevOps pasuje do twojego zadania?

Ostatnia kolumna to dowód, który agent dołącza, żebyś nie musiał czytać YAML-a.

Twoje zadanie	Przepis	Bramka, która to udowadnia
Napisać lub odchudzić Dockerfile, plik Compose albo CI obrazów	Wzorce Docker i kontenerów	hadolint, skan Trivy i smoke test zbudowanego obrazu
Deploymenty, charty Helm, autoskalowanie, GitOps	Wzorce orkiestracji Kubernetes	helm lint, potem kubectl diff na prawdziwym klastrze w CI
Pipeline’y GitHub Actions, GitLab CI lub Jenkins	Wzorce pipeline’ów CI/CD	actionlint, zizmor i testowy pull request, który musi się wyłożyć
Zmiany w Terraform, CloudFormation lub Pulumi	Wzorce infrastruktury jako kod	terraform plan bez żadnego nieoczekiwanego zastąpienia ani usunięcia
Instrumentacja, reguły alertów, dashboardy, pipeline’y logów	Wzorce monitorowania i logowania	promtool test rules i zapytanie, które zwraca prawdziwe dane

Pełny proces dostarczania opisuje przegląd i wdrożenie, a pracę z produkcją po wdrożeniu — DevOps z AI.

Daj agentowi reguły dostarczania przed każdym przepisem

Bez reguł agent pisze to, co przeciętny tutorial: tagi :latest, użytkownika root, akcje bez przypiętej wersji. Zapisz reguły raz, tam, skąd każde narzędzie wczytuje je automatycznie.

## Delivery rules
- Never read, print, or write secrets. Use the secret store; no credentials in ENV, ARG, YAML, or HCL.
- Pin every base image, action, chart, and provider to an explicit version.
- Never delete, skip, or soften a failing check (scanner severity, .trivyignore, `continue-on-error`,
  `|| true`, `-target`). Report the finding and stop.
- You do not run `terraform apply`, `kubectl apply`, `helm upgrade`, or any deploy. CI does that after approval.
- After any change, run the gates in scripts/verify-delivery.sh and paste the full output in your summary.

Claude Code

Trzymaj kanoniczny blok w AGENTS.md, a CLAUDE.md w katalogu głównym repozytorium ogranicz do jednej linii @AGENTS.md, która go importuje. Claude Code wczytuje go w każdej sesji, także w trybie headless (claude -p).

Codex

Dodaj blok do AGENTS.md w katalogu głównym repozytorium. Od Codeksa 0.150.0 niezaufany projekt nie dostarcza swojego AGENTS.md, więc oznacz repozytorium jako zaufane: zaakceptuj pytanie Trust this folder? przy pierwszym uruchomieniu codex w repozytorium albo ustaw trust_level = "trusted" w sekcji [projects."/bezwzględna/ścieżka"] w ~/.codex/config.toml (zobacz konfigurację Codeksa).

Cursor

Zapisz blok jako regułę projektu (reguły Cursora). Aktualizuj tę kopię przy każdej zmianie kanonicznego bloku.

Najważniejsza jest reguła o wdrożeniach: bez produkcyjnych poświadczeń zły przepis kosztuje nieudany pull request, a nie incydent. Jak ją wymusić, opisuje strona o uprawnieniach i sandboksach.

Prompt do skopiowania: audyt konfiguracji dostarczania przed zmianą

Read-only pass: do not edit files. Inventory every Dockerfile, Compose file,
Kubernetes manifest or Helm chart, CI workflow, and Terraform module in this
repository. For each, list: unpinned versions (images, actions, charts,
providers), containers running as root, checks that cannot fail (continue-on-error,
|| true, severity filters that exclude HIGH), and secrets referenced outside the
secret store. Output one table sorted by risk, with file:line for every finding,
and name the recipe fix you would apply first.

Jak zweryfikować zmiany DevOps od agenta bez czytania każdej linii?

Przepis jest skończony, gdy jego bramka przechodzi, a agent dołącza jej wynik — nie wtedy, gdy YAML dobrze wygląda.

• Bramki statyczne uruchamia agent w swojej sesji. Nie potrzebują żadnych poświadczeń.
• Bramki na prawdziwym środowisku działają w CI. terraform plan i kubectl diff wymagają dostępu do chmury i klastra, więc job CI z dostępem tylko do odczytu publikuje ich wynik w pull requeście, a agent go czyta.
• Udowodnij, że bramka potrafi zawieść. Przepis CI/CD otwiera testowy pull request, który musi się wyłożyć.
• Człowiek zatwierdza zasięg zmian. Recenzent czyta podsumowanie planu (zasoby dodane, zmienione, usunięte) i komendę wycofania, a nie każdą linię. Oba trafiają do pakietu dowodów pull requesta, a zgoda na produkcję pozostaje granicą po stronie człowieka.

Zbierz bramki statyczne w jednym skrypcie, który uruchamia każde narzędzie i każdy człowiek. Usuń linie, których twoje repozytorium nie potrzebuje:

#!/usr/bin/env bash
# scripts/verify-delivery.sh: static gates only; no cloud or cluster credentials.
set -euo pipefail
for f in $(git ls-files '*Dockerfile*'); do docker run --rm -i hadolint/hadolint < "$f"; done
actionlint
uvx zizmor .github/workflows/
for c in charts/*/; do helm lint "$c"; done
terraform -chdir=infra init -backend=false -input=false >/dev/null
terraform -chdir=infra validate
promtool check rules monitoring/rules/*.yml
echo "PASS all static delivery gates"

Prompt do skopiowania: poprawiaj, aż bramki przejdą, nie osłabiając ich

Run exactly: scripts/verify-delivery.sh. For each failing gate, fix the configuration,
not the gate: do not edit the script, scanner ignore files, severity lists, or
CI step conditions. Rerun after each fix. Stop after three rounds or when all
gates pass. Then give me: the full final script output, a list of files you
changed with one line each on why, and any finding you could not fix, with the
reason. Do not run apply, upgrade, or deploy commands.

Zapisz go jako prompts/devops-gates.txt i uruchom w każdym narzędziu tak samo:

Claude Code

# Terminal, on a trusted branch. Edits allowed; shell limited to the gate script.
claude -p "$(cat prompts/devops-gates.txt)" \
  --permission-mode dontAsk \
  --allowedTools "Read,Grep,Glob,Edit,Bash(scripts/verify-delivery.sh)" \
  --output-format json > gates.json

Reguła Bash(scripts/verify-delivery.sh) pasuje tylko do dokładnie tej pisowni, dlatego prompt mówi „Run exactly”. Jeśli agent wywoła ./scripts/verify-delivery.sh albo bash scripts/verify-delivery.sh, wywołanie zostanie odrzucone (--permission-mode dontAsk odrzuca wszystko, co wymagałoby pytania, a w trybie -p i tak nie miałby kto odpowiedzieć), więc podsumowanie może przyjść bez wyniku bramek. Odrzuć każde podsumowanie bez końcowej linii PASS.

Codex

# Terminal. The sandbox limits writes to the workspace; -o saves the final summary.
codex exec --sandbox workspace-write -o gates.md "$(cat prompts/devops-gates.txt)"

Sandbox workspace-write domyślnie nie ma dostępu do sieci (sandbox_workspace_write.network_access to false w codex-cli 0.157.1), więc uvx zizmor, terraform init i docker run hadolint zawiodą w jego wnętrzu. Zamiast tego zainstaluj narzędzia wcześniej w obrazie deweloperskim: przypiętą wersję zizmora, cache providerów przez TF_PLUGIN_CACHE_DIR i hadolinta jako plik binarny.

Cursor

Wklej prompt do agenta. Agent uruchomi skrypt w zintegrowanym terminalu, zgodnie z ustawieniami Run modes. Zaakceptuj diff dopiero wtedy, gdy terminal pokaże końcową linię PASS.

Co się psuje, gdy agenci piszą konfigurację DevOps?

Typowe awarie przepisów DevOps i jak z nich wyjść

• Zielony pipeline, bo agent osłabił bramkę. Diff dodaje || true, usuwa HIGH z listy poziomów ważności albo edytuje .trivyignore. Wyjście: cofnij te linie i wymagaj zgody code ownera na zmiany w plikach bramek.
• Zmyślone lub nieaktualne wersje. Agenci powtarzają tagi z danych treningowych i zgadują SHA commitów. Wyjście: sprawdź każdą wersję w rejestrze, a digesty oddaj Renovate’owi lub Dependabotowi.
• Plan, który zastępuje zasób zamiast go zmienić. Przemianowany zasób Terraform albo zmienione pole niemutowalne kończy się usunięciem i ponownym utworzeniem. Wyjście: blokuj merge przy każdym nieoczekiwanym zastąpieniu, a zmianę nazwy zapisz blokiem moved zamiast nowego zasobu.
• Zalecenia hardeningu ze starszej platformy. PodSecurityPolicy usunięto w Kubernetes 1.25, a agenci wciąż ją generują. Wyjście: podaj w prompcie wersję klastra i waliduj przez kubectl diff na prawdziwym serwerze API.
• Agent prosi o poświadczenia, żeby „sprawdzić, czy działa”. Wyjście: odmów i przenieś tę kontrolę do joba CI z dostępem tylko do odczytu. Nigdy nie odpowiadaj flagą --dangerously-skip-permissions ani sandboksem z pełnym dostępem poza jednorazowym środowiskiem z ograniczoną siecią.

Dokąd dalej z przepisami DevOps

Wzorce Docker i kontenerów

Wzorce orkiestracji Kubernetes

Wzorce pipeline'ów CI/CD

Wzorce infrastruktury jako kod

Wzorce monitorowania i logowania

Proces konteneryzacji

Proces pipeline'ów CI/CD

Proces infrastruktury jako kod

Serwery MCP dla infrastruktury Serwery Terraform, Kubernetes i chmurowe, które opierają agenta na prawdziwych danych dostawcy.

Agenci bezgłowi w CI Uruchamiaj te przepisy jako joby CI bezpiecznie, tylko na zaufanych refach.