Generator potoku Terraform

Plik YAML dla GitHub Actions lub GitLab CI: fmt, validate, plan na PR, apply na main i szablon backend.tf

Bezpieczne (SSL)

Przetwarzanie Lokalne

100% Darmowe

Przejdź do narzędzia

Instrukcja

1

Wprowadź dane
Wpisz treść, wklej tekst lub załaduj plik z dysku.
2

Kliknij przycisk
Narzędzie natychmiast przetworzy Twoje dane w przeglądarce.
3

Pobierz wynik
Skopiuj gotowy tekst lub zapisz plik na urządzeniu.

                                                function runTool() {

                                                  return "Wynik gotowy w 0.1s";

                                                }

System CI

Wersja Terraform

Backend stanu

Katalog z kodem Terraform

Środowiska (jedno w linii)

Dla każdego środowiska powstanie osobne wdrożenie apply (macierz).

Zachowanie

Plan na Pull Request

Apply na main

Ręczna akceptacja apply

Dołącz wskazówki Infracost

Zadania w potoku

fmt, validate, plan, apply

Linii YAML

Środowiska (apply)

dev, staging, prod

Backend stanu

AWS S3

Blokada stanu przez tabelę DynamoDB (jest w szablonie)

Apply

Do zabezpieczenia

Uwaga

Włącz Required reviewers w Environments repozytorium

Potok: .github/workflows/terraform.yml

name: Terraform on: pull_request: paths: - "infra/**" push: branches: [main] paths: - "infra/**" permissions: id-token: write contents: read pull-requests: write env: TF_VERSION: 1.9.0 TF_WORKING_DIR: infra jobs: fmt: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: hashicorp/setup-terraform@v3 with: terraform_version: ${{ env.TF_VERSION }} - run: terraform fmt -check -recursive working-directory: ${{ env.TF_WORKING_DIR }} validate: runs-on: ubuntu-latest needs: fmt steps: - uses: actions/checkout@v4 - uses: hashicorp/setup-terraform@v3 with: terraform_version: ${{ env.TF_VERSION }} - run: terraform init -backend=false working-directory: ${{ env.TF_WORKING_DIR }} - run: terraform validate working-directory: ${{ env.TF_WORKING_DIR }} plan: runs-on: ubuntu-latest needs: validate if: github.event_name == 'pull_request' steps: - uses: actions/checkout@v4 - uses: hashicorp/setup-terraform@v3 with: terraform_version: ${{ env.TF_VERSION }} - run: terraform init working-directory: ${{ env.TF_WORKING_DIR }} env: AWS_ROLE_ARN: ${{ secrets.AWS_ROLE_ARN }} - run: terraform plan -no-color -out=tfplan working-directory: ${{ env.TF_WORKING_DIR }} apply: runs-on: ubuntu-latest needs: validate if: github.ref == 'refs/heads/main' strategy: matrix: environment: [dev, staging, prod] environment: ${{ matrix.environment }} steps: - uses: actions/checkout@v4 - uses: hashicorp/setup-terraform@v3 with: terraform_version: ${{ env.TF_VERSION }} - run: terraform init working-directory: ${{ env.TF_WORKING_DIR }} - run: terraform apply -auto-approve working-directory: ${{ env.TF_WORKING_DIR }} env: TF_WORKSPACE: ${{ matrix.environment }}

2 033 znaków · 182 słów · 79 linii

Backend stanu (AWS S3): infra/backend.tf

terraform { backend "s3" { bucket = "NAZWA-BUCKETA" key = "infra/terraform.tfstate" region = "eu-central-1" encrypt = true dynamodb_table = "NAZWA-TABELI-BLOKAD" } }

223 znaków · 22 słów · 9 linii

Wartości wielkimi literami (nazwa bucketa, grupy zasobów, tabeli blokad) uzupełnij swoimi. Konfiguracja backendu nie przyjmuje zmiennych.

Czego ten szkielet nie robi

Szkielet nie zawiera kroku logowania do chmury. Dodaj uwierzytelnienie dla swojego dostawcy (najlepiej krótkotrwałe poświadczenia zamiast stałych kluczy).
Zadanie apply wykonuje własne „terraform apply -auto-approve” i nie korzysta z zapisanego planu.
Ręczną akceptację apply w GitHub ustawiasz w repozytorium: Settings → Environments → Required reviewers (dla każdego środowiska z listy). Sam plik YAML jej nie wymusza.

Zadania w wygenerowanym potoku

Co robi każde zadanie przy wybranych opcjach
Zadanie	Kiedy się uruchamia	Co robi	Polecenia
fmt	Pull Request i push na main	Sprawdza formatowanie kodu	terraform fmt -check -recursive
validate	Po zadaniu fmt	Sprawdza składnię i spójność konfiguracji (bez łączenia z backendem)	terraform init -backend=false, terraform validate
plan	Tylko Pull Request, po validate	Pokazuje, co Terraform zmieni, zanim kod trafi do main	terraform init, terraform plan -no-color -out=tfplan
apply	Push na main, po validate; osobno dla każdego środowiska	Wdraża zmiany	terraform init, terraform apply -auto-approve

Uwierzytelnianie bez stałych kluczy

Zamiast długotrwałych kluczy w sekretach pozwól runnerowi uzyskać krótkotrwały token od dostawcy chmury (OIDC). W wariancie GitHub Actions plik ma już uprawnienie id-token: write, ale zaufanie po stronie chmury i krok logowania musisz skonfigurować sam.

Zdalny stan z blokadą

Runner CI jest tymczasowy, więc lokalny plik stanu zniknie po zakończeniu zadania. Zdalny backend trzyma stan w jednym miejscu, a blokada chroni przed równoległymi zmianami tej samej infrastruktury.

Apply bez pytania

Flaga -auto-approve wdraża zmiany bez potwierdzenia, dlatego zabezpiecz apply: w GitHub ochroną środowiska z wymaganymi recenzentami, w GitLab ręcznym uruchomieniem. Macierz środowisk w GitHub startuje je równolegle, każde z własnym TF_WORKSPACE.

Przypięta wersja

Stała wersja Terraform w potoku daje powtarzalne wyniki na każdym runnerze. Podnoś ją świadomie, a plik .terraform.lock.hcl dodaj do repozytorium, żeby wersje dostawców też były stałe.

Oceń to narzędzie:

Powiązane narzędzia

Inne narzędzia, które mogą Ci się przydać

Generator potoku Terraform

Generator tworzy plik potoku Terraform dla GitHub Actions (.github/workflows/terraform.yml) lub GitLab CI (.gitlab-ci.yml) oraz szablon backend.tf. Potok sprawdza formatowanie i składnię, uruchamia plan na Pull Requeście i apply po scaleniu do main, więc każda zmiana infrastruktury przechodzi przegląd i zostaje w historii repozytorium.

Etapy potoku

Etap	Kiedy (GitHub Actions)	Kiedy (GitLab CI)	Cel
fmt	Pull Request i push na main	w zadaniu validate	spójne formatowanie (`terraform fmt -check -recursive`)
validate	po zadaniu fmt	każdy potok	poprawność konfiguracji
plan	tylko Pull Request	tylko merge request	podgląd zmian w infrastrukturze
apply	push na main, osobno dla każdego środowiska	gałąź main, ręcznie lub automatycznie	wdrożenie zmian

W GitHub Actions potok startuje tylko wtedy, gdy zmiana dotyczy plików w katalogu z kodem Terraform (filtr paths, domyślnie infra/**). Push na gałąź roboczą bez otwartego Pull Requesta niczego nie uruchamia.

Backend stanu

Stan Terraform trzymaj zdalnie (S3, GCS, Azure RM) z blokadą — zapobiega równoległym operacjom i pozwala pracować zespołowo. Nigdy nie commituj pliku terraform.tfstate.

Generator dokłada szablon backend.tf dla wybranego backendu, a klucz stanu bierze z nazwy katalogu, np. infra/terraform.tfstate dla S3 albo infra.tfstate dla Azure RM. Wartości wielkimi literami (bucket, grupa zasobów, tabela blokad) uzupełniasz sam, bo blok backend nie przyjmuje zmiennych. Szablon S3 blokuje stan przez tabelę DynamoDB; od Terraform 1.10 backend S3 potrafi też blokować stan plikiem w buckecie (use_lockfile = true). Backend lokalny nadaje się tylko do testów: runner CI jest tymczasowy i stan zniknie po zakończeniu zadania.

Bezpieczeństwo

używaj OIDC zamiast długotrwałych kluczy dostępowych; plik dla GitHub ma już uprawnienie id-token: write, ale krok logowania do chmury i zaufanie po stronie dostawcy dodajesz sam,
sekrety przekazuj przez mechanizm CI, nie do kodu,
dodaj ręczną akceptację przed apply na produkcji, bo zadanie apply działa z flagą -auto-approve,
plan przeglądają inni członkowie zespołu.

Jak generator składa potok Terraform krok po kroku

Generator działa jak kreator szablonu, a nie analizator kodu. Nie skanuje plików .tf ani nie wykrywa zależności między modułami. Przyjmuje zestaw opcji: system CI, wersję Terraform (np. 1.9.0 lub 1.10.0-rc1), backend stanu, katalog z kodem, listę do 10 środowisk oraz cztery przełączniki: plan na Pull Request, apply na main, ręczna akceptacja apply i wskazówki Infracost. Na tej podstawie powstaje plik YAML z zadaniami i regułami ich uruchamiania, a podgląd odświeża się przy każdej zmianie opcji.

Mechanizm opiera się na dwóch zasadach. Pierwsza to separacja zdarzeń: Pull Request i push na main mają przypisane inne etapy. Dzięki temu plan nigdy nie wykonuje zmian, a apply nie startuje przed scaleniem. Druga zasada to macierz środowisk w GitHub Actions: jeśli wpiszesz dev, staging i prod, jedno zadanie apply rozdziela się na trzy równoległe przebiegi, każdy z własnym TF_WORKSPACE i środowiskiem GitHub o tej samej nazwie. Zadania fmt, validate i plan działają raz dla całego potoku. W GitLab CI lista środowisk nie wpływa na plik: powstają zadania validate, plan i apply.

Kafelek „Zadania w potoku” pokazuje, ile zadań zdefiniowano w pliku: przy domyślnych opcjach 4 w GitHub Actions (fmt, validate, plan, apply) i 3 w GitLab CI. Liczba przebiegów w GitHub zależy od zdarzenia: Pull Request uruchamia 3 zadania (fmt, validate, plan), a push na main 2 + liczba środowisk.

Przykład: repozytorium z trzema środowiskami

W generatorze wybierasz GitHub Actions, backend S3, katalog infra i trzy środowiska: dev, staging oraz prod. Zostawiasz włączony plan na PR, apply na main i ręczną akceptację.
Programista robi push na branch feature. Nic się nie uruchamia, bo potok reaguje tylko na Pull Request i push na main.
Powstaje Pull Request ze zmianą w infra/. Uruchamiają się 3 zadania: fmt, validate i plan. Apply zostaje pominięty, bo warunek github.ref == 'refs/heads/main' nie jest spełniony.
Recenzent prosi o poprawkę. Kolejny push w ramach PR uruchamia ponownie te same 3 zadania. Poprzedni plan nie jest już aktualny.
Pull Request zostaje scalony do main. Uruchamiają się fmt, validate i 3 przebiegi apply. Jeśli w Settings → Environments ustawiłeś wymaganych recenzentów tylko dla prod, przebiegi dev i staging ruszają od razu, a prod czeka na akceptację wskazanej osoby.
Pełny cykl bez poprawek to 3 + 5 = 8 przebiegów zadań. Jeśli w PR były dwie poprawki, dochodzi 2 × 3 = 6, razem 14. Liczba przebiegów rośnie liniowo wraz z liczbą poprawek.

Zdarzenia w repozytorium a liczba zadań

Wariant GitHub Actions z domyślnymi opcjami i trzema środowiskami.

Zdarzenie	Zadania potoku	Przebiegi przy 3 środowiskach
push na branch bez PR	brak	0
pull_request (otwarcie lub nowy commit)	fmt, validate, plan	3
zmiana tylko poza katalogiem `infra`	brak (filtr paths)	0
push na main (scalenie)	fmt, validate, apply w macierzy	2 + 3 = 5
apply na prod przed akceptacją	zadanie wstrzymane	0 wykonanych
pełny cykl bez poprawek	PR, scalenie	3 + 5 = 8
jedna poprawka w PR	ponowny plan po pushu	3 dodatkowe
pull_request zamknięty bez scalenia	brak apply	0

Praktyczne wskazówki dla potoku Terraform

Apply nie używa planu z PR. Wygenerowane zadanie apply liczy plan od nowa i wdraża go z -auto-approve. Między PR a main zakres zmian może się przesunąć, zwłaszcza gdy w międzyczasie ktoś zmodyfikował infrastrukturę ręcznie. Jeśli to ryzyko jest dla ciebie istotne, zapisz plan jako artefakt i wykonaj terraform apply tfplan.
Dwa równoległe apply na tym samym stanie to ryzyko konfliktu. Blokada backendu przerwie drugi przebieg, a klucz concurrency w GitHub Actions albo resource_group w GitLab CI ustawi przebiegi w kolejce.
Dev, staging i prod nie powinny dzielić jednego stanu. Potok GitHub korzysta z workspace'ów o nazwach środowisk, więc utwórz je wcześniej (terraform workspace new prod). Przy surowszej izolacji użyj osobnych backendów lub katalogów.
Kontrola polityk po planie (OPA, Sentinel, checkov) może zatrzymać apply, jeśli plan łamie reguły organizacji. Generator jej nie wbudowuje, dopinasz ją sam.
Ręczne zmiany w chmurze wykryje cykliczny plan na main, uruchamiany z harmonogramu (schedule z wyrażeniem cron, które ułoży generator wyrażeń cron). Bez tego stan i rzeczywistość mogą się rozjechać niezauważenie, a kolejny apply nadpisze nieoczekiwane zmiany.

Ograniczenia generatora

Potok działa w jednym katalogu (pole „Katalog z kodem Terraform”, domyślnie infra). Przy kilku rootach wdrażanych osobno powielasz zadania albo dodajesz własną macierz katalogów.
Plan w GitHub Actions jest jeden, w domyślnym workspace, a nie osobno dla każdego środowiska. Nie trafia też do komentarza PR: plik ma uprawnienie pull-requests: write, ale krok publikujący plan dodajesz sam.
Bucket S3 lub GCS, konto magazynu Azure i tabela blokad muszą istnieć wcześniej. Generator tylko wpisuje odwołanie do nich w backend.tf, nie tworzy tych zasobów.
W GitLab CI terraform init z backendem działa w before_script każdego zadania, także validate, więc dostęp do stanu jest potrzebny już na etapie walidacji.
Ręczna akceptacja w GitHub nie wynika z pliku YAML: ustawiasz ją w Settings → Environments → Required reviewers dla każdego środowiska z listy. W GitLab CI ta sama opcja dodaje when: manual do zadania apply.
Opcja Infracost dodaje tylko komentarz z przykładowym poleceniem infracost breakdown, bez instalacji narzędzia. Skanery bezpieczeństwa i polityki podłączasz osobno.

Najczęstsze pytania

Czy generator obsługuje Terraform Cloud?

Nie w trybie natywnym. Narzędzie tworzy pliki dla GitHub Actions i GitLab CI, a Terraform Cloud wymaga własnej integracji i konfiguracji remote backendu. Możesz jednak użyć wygenerowanego potoku do wywołania Terraform Cloud przez API.

Jak przekazać zmienne TF_VAR do potoku?

Najprościej przez sekrety lub zmienne CI. W GitHub Actions ustawiasz je w sekcji env, a w GitLab CI jako masked variables. Nie commituj plików tfvars z danymi wrażliwymi.

Czy potok zadziała z OpenTofu?

Tak, po ręcznej korekcie YAML: w GitHub Actions zamień akcję hashicorp/setup-terraform na opentofu/setup-opentofu, w GitLab CI obraz hashicorp/terraform na obraz OpenTofu, a polecenia terraform na tofu. Logika etapów, macierz środowisk i akceptacja przed apply pozostają takie same.

Jak zabezpieczyć apply na produkcji?

Użyj environment z wymaganymi recenzentami, OIDC zamiast kluczy oraz osobnego stanu dla prod. Dodatkowo ogranicz uprawnienia roli do niezbędnego minimum.

Co zrobić, gdy stan Terraform jest zablokowany?

Sprawdź, czy nie trwa inny apply lub czy poprzedni przebieg nie zakończył się błędem. Blokadę zwalniaj poleceniem terraform force-unlock ID_BLOKADY tylko wtedy, gdy masz pewność, że żaden proces nie modyfikuje stanu.

Jaką wersję Terraform wpisać?

Tę samą, której zespół używa lokalnie (sprawdzisz ją poleceniem terraform version). Przypięta wersja daje powtarzalne wyniki, a plik .terraform.lock.hcl w repozytorium utrzymuje stałe wersje dostawców.