Infrastructure as Code z Terraform w chmurze: praktyczne porównanie podejść

Infrastructure as Code (IaC) to opisywanie infrastruktury chmurowej w plikach tekstowych, które trafiają do repozytorium, przechodzą przegląd i są wdrażane narzędziem zamiast ręcznie. Wybór narzędzia przestał być decyzją czysto techniczną: liczą się licencja, sposób przechowywania stanu, zależność od jednego dostawcy i to, czy produkt jest nadal rozwijany.

Na skróty

Czego dowiesz się z artykułu:

• Jak działa Terraform: stan, blokady stanu, plan i apply
• Co zmieniła licencja Terraform i czym jest OpenTofu
• Czym różnią się natywne narzędzia dostawców chmury
• Jak dobrać podejście do zespołu i liczby chmur

Dla kogo jest ten artykuł:

• Inżynierowie DevOps i zespoły platformowe
• Architekci chmury i liderzy zespołów infrastruktury
• Menedżerowie IT wybierający standard IaC dla organizacji

Czas czytania: 8 minut

Jak działa Terraform: stan, plan i apply

Terraform opisuje zasoby deklaratywnie, a wdrożenie odbywa się w dwóch krokach. Polecenie terraform plan pokazuje, co zostanie utworzone, zmienione albo usunięte. Polecenie terraform apply wykonuje zmiany. Według dokumentacji na developer.hashicorp.com plan bez opcji -out=FILE jest planem spekulacyjnym: służy do przeglądu, a przed wdrożeniem trzeba sprawdzić plan ostateczny, bo stan infrastruktury mógł się w międzyczasie zmienić. W potoku CI/CD zapisuje się więc plan do pliku i stosuje dokładnie ten plik.

Podstawą działania jest plik stanu (state). Jego głównym zadaniem jest przechowywanie powiązań między obiektami w chmurze a zasobami zadeklarowanymi w konfiguracji. Stan może zawierać wartości poufne, na przykład klucze dostępu — zwraca na to uwagę dokumentacja OpenTofu o szyfrowaniu stanu. Dlatego w pracy zespołowej trzyma się go w zdalnym backendzie z kontrolą dostępu.

Drugie kluczowe pojęcie to blokada stanu (state locking). Jeżeli backend ją obsługuje, Terraform zakłada blokadę przy każdej operacji, która może zapisać stan, i nie kontynuuje, gdy jej nie uzyska. Flaga -lock=false ją wyłącza, ale dokumentacja tego nie zaleca. Polecenie terraform force-unlock służy wyłącznie do zdjęcia własnej blokady, która nie zwolniła się automatycznie — zdjęcie cudzej grozi jednoczesnym zapisem stanu przez kilka procesów. Nie każdy backend obsługuje blokady, co warto sprawdzić przed wyborem.

Licencja Terraform i fork OpenTofu

Według manifestu opublikowanego na opentofu.org Terraform był od 2014 r. udostępniany na licencji Mozilla Public License 2.0, a HashiCorp zmienił ją na Business Source License (BUSL), która nie jest licencją open source. W odpowiedzi firmy z ekosystemu utworzyły fork pod nazwą OpenTofu, rozwijany pod opieką Linux Foundation. FAQ projektu podkreśla, że warunki BUSL i dodatkowego zezwolenia są niejednoznaczne przy zastosowaniach komercyjnych, a według wstępnej oceny projektu dla użytku niekomercyjnego licencja nie wprowadza ograniczeń.

Status forka sprawdzisz na www.cncf.io: OpenTofu przyjęto do CNCF 23 kwietnia 2025 r. na poziomie Sandbox. Dla zespołów ważne są trzy fakty praktyczne:

• OpenTofu używa tych samych dostawców (providers) co Terraform i ma własny rejestr modułów i dostawców.
• Według FAQ na opentofu.org działa z plikami stanu utworzonymi przez Terraform w wersjach do 1.5.x włącznie, co ma znaczenie przy migracji.
• Polecenia mają odpowiedniki, np. tofu plan, a OpenTofu obsługuje szyfrowanie plików stanu i planu w spoczynku, także w zdalnym backendzie.

W ocenie autora wybór między Terraform a OpenTofu jest więc w dużej mierze decyzją prawną i strategiczną, nie składniową. Dział prawny powinien ocenić warunki licencji wobec sposobu, w jaki firma korzysta z narzędzia.

Natywne narzędzia dostawców chmury

Druga droga to narzędzia, które dostawca chmury rozwija dla własnej platformy:

• AWS CloudFormation — szablony i stosy (stacks) wdrażane w AWS, z możliwością automatyzacji w potoku CI/CD (aws.amazon.com).
• Azure Bicep — język dziedzinowy o składni deklaratywnej, prostszy od szablonów ARM w JSON. Według learn.microsoft.com Bicep nie wymaga zarządzania plikami stanu, bo stan przechowuje Azure.
• Google Cloud — Deployment Manager stracił wsparcie 31 marca 2026 r., a od 30 czerwca 2026 r. nowi użytkownicy nie mogą go włączyć. Usługa działa dla istniejących klientów do 30 czerwca 2027 r., a nowi użytkownicy są przekierowywani do Infrastructure Manager, który wdraża konfiguracje Terraform (cloud.google.com).

Przykład Google pokazuje ryzyko natywnego podejścia: decyzja o wycofaniu narzędzia należy do dostawcy, a migracja do zespołu klienta.

Jak wybrać podejście

• Pojedyncza chmura, mały zespół — narzędzie natywne upraszcza start, a w Azure odpada utrzymanie stanu.
• Kilka chmur albo usługi spoza chmury — Terraform lub OpenTofu pozwala opisać zasoby wielu dostawców jednym językiem i jednym procesem przeglądu.
• Wymagania licencyjne i kontrola nad stanem — OpenTofu z szyfrowaniem stanu albo Terraform po ocenie BUSL przez dział prawny.

Niezależnie od narzędzia podział ról jest podobny. Zespół platformowy utrzymuje moduły, backend stanu i potok plan → przegląd → apply. Zespoły aplikacyjne korzystają z modułów, a zespół bezpieczeństwa przegląda plany zmian dla zasobów krytycznych.

Czytaj także

• Strategia multi-cloud — checklist wdrożenia — od czego zacząć z kilkoma chmurami
• FinOps i kontrola kosztów chmury — koszty infrastruktury opisanej w kodzie
• Bezpieczeństwo tożsamości w chmurze (IAM) — uprawnienia dla potoków IaC

Rozwijaj kompetencje

Temat rozwijają szkolenia Terraform / OpenTofu — Infrastructure as Code oraz IaC zaawansowany — Terraform vs Pulumi vs AWS CDK. Pierwsze to warsztat od podstaw do CI/CD z zarządzaniem stanem, modułami i migracją do OpenTofu, drugie porównanie narzędzi IaC na poziomie zaawansowanym. Skontaktuj się z nami, żeby dopasować zakres do swojego zespołu.

Najczęściej zadawane pytania (FAQ)

Czym jest infrastruktura jako kod?

Infrastruktura jako kod (IaC) to opisywanie serwerów, sieci, baz danych i innych zasobów w plikach konfiguracyjnych, które przechowuje się w repozytorium i wdraża narzędziem. Zmiany przechodzą przegląd jak kod aplikacji, a to samo środowisko da się odtworzyć wielokrotnie.

Czym Terraform różni się od OpenTofu?

OpenTofu powstał jako fork Terraform po zmianie licencji Terraform z MPL 2.0 na BUSL i jest rozwijany pod opieką Linux Foundation, a od 2025 r. jako projekt CNCF na poziomie Sandbox (www.cncf.io). Oba narzędzia używają tych samych dostawców i podobnych poleceń. Różnią się licencją, rozwojem funkcji (np. szyfrowanie stanu w OpenTofu) i tym, kto decyduje o kierunku projektu.

Jak zarządzać infrastrukturą w kilku chmurach?

Narzędzia takie jak Terraform i OpenTofu pozwalają opisać zasoby wielu dostawców w jednej konfiguracji, z jednym procesem przeglądu i wdrożenia. Warto rozdzielić stan per środowisko i per obszar, utrzymywać wspólne moduły w zespole platformowym i pilnować uprawnień tożsamości, z których korzysta potok.

Od czego zacząć naukę Terraform?

Zacznij od cyklu terraform plan i terraform apply na małym, testowym środowisku, a potem przejdź do zdalnego stanu z blokadą, modułów i uruchamiania planu w potoku CI/CD. Równolegle warto poznać OpenTofu, bo polecenia i pojęcia są wspólne, a wybór narzędzia w firmie może zależeć od licencji.