Czym jest Infrastructure as Code i po co ci ona

Wyobraź sobie taką sytuację: jest wtorek, godzina 2:15 w nocy. Twoja aplikacja produkcyjna właśnie przestała odpowiadać. Logi wskazują na błąd połączenia z bazą danych. Szybka analiza i diagnoza: reguła w Security Group (firewallu) została przypadkowo zmieniona lub usunięta. Wchodzisz do konsoli AWS/Azure/GCP, odnajdujesz odpowiednią grupę, klikasz "Add Rule", wpisujesz port 5432 i klikasz "Save". Problem rozwiązany. System wstaje, zespół śpi spokojnie.

Rano budzisz się z poczuciem dobrze wykonanego zadania. Ale to jest właśnie moment, w którym zaczyna się Twój największy problem. Właśnie stworzyłeś dług technologiczny, który prędzej czy później doprowadzi do katastrofy.

Pułapka "ClickOpsu"

Podejście, które opisałem powyżej, nazywamy ClickOpsem. Polega ono na ręcznym konfigurowaniu zasobów poprzez interfejs graficzny (GUI) dostawcy chmury. Choć w małych projektach lub podczas szybkiego prototypowania wydaje się to najszybszą drogą, w środowisku produkcyjnym jest to prosta droga do chaosu.

Dlaczego ClickOps nie skaluje się i jest niebezpieczny?

Brak powtarzalności: Jeśli musisz postawić identyczne środowisko testowe, stagingowe i produkcyjne, musisz powtórzyć te same dziesiątki kliknięć. Każde kliknięcie to szansa na błąd – zapomnisz o jednym checkboxie, pomylisz region lub wybierzesz inny typ instancji.
Brak dokumentacji: Konsola nie mówi Ci, dlaczego dana reguła została dodana. Po pół roku nikt nie będzie pamiętał, czy ten otwarty port to konieczność, czy efekt nocnej paniki.
Brak historii zmian: W konsoli nie masz "git log". Nie wiesz, kto, kiedy i co zmienił. Jeśli ktoś zmieni konfigurację i wszystko padnie, nie masz możliwości szybkiego powrotu do poprzedniego, działającego stanu (rollback).
Niemożność odtworzenia stanu: Gdy całe Twoje centrum danych (region chmury) ulegnie awarii, nie jesteś w stanie odtworzyć infrastruktury w innym miejscu w rozsądnym czasie. Będziesz klikać przez dni, modląc się, by nie popełnić błędu.

Infrastructure as Code (IaC) to przejście od "klikania" do "programowania" Twojej infrastruktury. Zamiast manualnych operacji, tworzysz pliki tekstowe, które opisują, jak Twoja sieć, serwery i bazy danych mają wyglądać.

Imperatywne vs Deklaratywne: Klucz do zrozumienia IaC

Aby zrozumieć, dlaczego narzędzia takie jak Terraform czy OpenTofu są rewolucyjne, musisz zrozumieć różnicę między podejściem imperatywnym a deklaratywnym.

Podejście Imperatywne (Jak to zrobić?) To podejście przypomina instrukcję gotowania lub skrypt Bash. Mówisz systemowi dokładnie, jakie kroki ma wykonać: 1. Stwórz sieć VPC. 2. Stwórz podsieć w tej sieci. 3. Uruchom instancję EC2. 4. Podepnij dysk do instancji.

Problem pojawia się, gdy skrypt zostanie przerwany w połowie lub gdy uruchomisz go drugi raz. Skrypt spróbujący stworzyć sieć, która już istnieje, wyrzuci błąd i zatrzyma proces. Musisz sam napisać skomplikowaną logikę sprawdzającą: if network_exists then skip else create.

Podejście Deklaratywne (Co ma być zrobione?) To podejście, które stosujemy w OpenTofu/Terraformie. Nie mówisz narzędziu, jak ma coś zrobić. Mówisz mu, jaki ma być stan docelowy. Twój kod wygląda tak:

resource "aws_instance" "web_server" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"
}

Ty nie prosisz o "stworzenie instancji". Ty deklarujesz: "Chcę, aby w moim środowisku istniała instancja typu t2.micro o tym konkretnym obrazie".

Jeśli uruchomisz ten kod pierwszy raz – narzędzie stworzy instancję. Jeśli uruchomisz go drugi raz – narzędzie sprawdzi stan rzeczywisty, zobaczy, że instancja już jest, i nie zrobi nic. To zjawisko nazywamy idempotentnością. To fundament stabilności.

Dryf (Drift) – Gdy rzeczywistość odjeżdża od kodu

Największym wrogiem inżyniera IaC jest Dryf (Drift). Dryf występuje w momencie, gdy ktoś (często w dobrej wierze, jak w przykładzie z nocną awarią) dokona zmiany w infrastrukturze ręcznie, omijając kod.

W tym momencie Twój kod przestaje być "Single Source of Truth" (jedynym źródłem prawdy). Kod mówi: "Port 80 jest zamknięty", a rzeczywistość mówi: "Port 80 jest otwarty".

Narzędzia takie jak OpenTofu rozwiązują ten problem dzięki mechanizmowi planowania (plan). Zanim jakakolwiek zmiana zostanie wprowadzona, narzędzie porównuje trzy elementy: 1. Twój kod (to, co chcesz mieć). 2. Stan zapisany w pliku state (to, co narzędzie myśli, że ma). 3. Rzeczywistość w chmurze (to, co faktycznie tam jest).

Jeśli wykryje różnicę (dryf), narzędzie powie Ci: "Uwaga, ktoś ręcznie otworzył port 80. Jeśli teraz uruchomisz apply, zamknę go, aby przywrócić stan zgodny z Twoim kodem". IaC pozwala Ci na ciągłe przywracanie porządku i eliminowanie niekontrolowanych zmian.

Mapa narzędzi: Gdzie jest miejsce dla OpenTofu?

W świecie IaC często myli się pojęcia. Abyś nie błądził, musisz rozróżnić dwie główne kategorie:

Provisioning (Provisioning Tools): Narzędzia do budowania "szkieletu" infrastruktury. Tworzą sieci, maszyny wirtualne, bazy danych, load balancery. Tu królują Terraform i OpenTofu.
Configuration Management (Narzędzia do zarządzania konfiguracją): Narzędzia do instalowania oprogramowania wewnątrz już stworzonych maszyn. Np. instalacja Nginx, konfiguracja użytkowników w Linuxie, kopiowanie plików konfiguracyjnych. Tu królują Ansible, Chef czy Puppet.

Możesz użyć Ansible do zainstalowania bazy danych na serwerze, ale to OpenTofu powinno tym serwerem "zarządzać" – wiedzieć, czy on w ogóle istnieje i czy ma odpowiednią ilość RAM-u.

Podsumowując: OpenTofu to Twój architekt i budowniczy. Ansible to Twój ekip remontowy, który maluje ściany w już zbudowanym domu.

Zasada do zapamiętania: Jeśli konfiguracja infrastruktury nie znajduje się w systemie kontroli wersji (Git), to znaczy, że ta infrastruktura nie istnieje – istnieje tylko jej tymczasowy, niepewny i nieodtwarzalny cień.