Czytanie planu: najważniejsza umiejętność w IaC

Większość początkujących użytkowników OpenTofu i Terraforma traktuje komendę plan jako formalność – coś, co trzeba "odklikać", żeby przejść do właściwego działania, czyli apply. To najprostsza droga do katastrofy na produkcji. W świecie Infrastructure as Code plan nie jest sugestią ani podsumowaniem Twoich intencji. Plan to jedyna zapora między Tobą a niekontrolowanym usunięciem infrastruktury, za którą ktoś będzie musiał zapłacić lub którą będzie musiał odtwarzać przez całą noc.

Jeśli nie rozumiesz każdego znaku w wyjściu komendy plan, nie masz kontroli nad swoim środowiskiem. Nie zarządzasz infrastrukturą – tylko liczysz na szczęście.

Anatomia planu: Symbole, które decydują o przetrwaniu

Kiedy uruchamiasz plan, silnik porównuje Twój kod z aktualnym stanem (state) i rzeczywistymi zasobami w chmurze. Wynik jest prezentowany za pomocą specyficznych symboli. Musisz je czytać instynktownie:

+ (Create): Dodanie nowego zasobu. Nowy koszt, nowa instancja, nowy endpoint.
- (Destroy): Usunięcie zasobu. To jest moment, w którym musisz zadać sobie pytanie: "Czy na pewno chciałem, żeby to zniknęło?".
~ (Update in-place): Modyfikacja istniejącego zasobu. Zmiana tagu, zmiana rozmiaru instancji (o ile dostawca na to pozwala bez restartu). To zazwyczaj najbezpieczniejsza operacja.
-/+ (Destroy and then create): To jest "czerwona flaga". Oznacza, że zmiana, którą wprowadziłeś, nie może zostać zastosowana do istniejącego zasobu. Silnik musi najpierw usunąć stary obiekt, a potem stworzyć nowy.

Pułapka "forces replacement"

To najważniejsza fraza, jaką kiedykolwiek przeczytasz w konsoli. Jeśli widzisz symbol -/+ lub komunikat "forces replacement", zatrzymaj się. To nie jest zwykła aktualizacja.

Przykład z życia: Chcesz zmienić nazwę bazy danych RDS lub zmienić ID podsieci (subnet), w której stoi Twoja kluczowa instancja EC2. Większość dostawców chmurowych (AWS, Azure, GCP) traktuje te parametry jako niezmienne (immutable). Nie da się "przepiąć" działającej bazy do innego parametru identyfikacyjnego.

Co zrobi OpenTofu? 1. Zobaczy zmianę. 2. Zauważy, że parametr jest niezmienny. 3. Wypisze: ~ subnet_id = "subnet-abc" -> "subnet-xyz" # forces replacement. 4. W momencie wykonania apply, Twoja baza danych zostanie skasowana, a po kilku minutach (lub godzinach) powstanie nowa, pusta baza.

Jeśli nie zauważysz tego napisu, właśnie spowodowałeś całkowitą utratę danych produkcyjnych. Zawsze szukaj frazy forces replacement przed zatwierdzeniem jakiejkolwiek zmiany.

"known after apply" – kiedy plan jest niepewny

Czasami w planie zobaczysz wartości oznaczone jako (known after apply). To sytuacja, w której silnik nie jest w stanie przewidzieć, co się stanie, dopóki nie wykona operacji.

Dzieje się tak najczęściej, gdy: * Tworzysz nowy zasób, który generuje własne ID (np. aws_instance.id). * Tworzysz zasób, którego parametry zależą od innego, nowo tworzonego zasobu.

To jest niebezpieczne, ponieważ nie widzisz pełnego obrazu. Jeśli tworzysz skomplikowaną sieć, a plan pokazuje (known after apply) dla kluczowych parametrów routingu, nie masz 100% pewności, jak ta sieć będzie wyglądać w rzeczywistości. W takich momentach warto rozważyć bardziej modularne podejście lub ręczne sprawdzenie zależności.

Profesjonalny workflow: Plan -> Plik -> Apply

W środowisku lokalnym często robimy plan, czytamy go i od razu wpisujemy apply. W profesjonalnym CI/CD (GitHub Actions, GitLab CI, Jenkins) to zachowanie jest niedopuszczalne i ryzykowne.

Dlaczego? Ponieważ między Twoim plan a apply może nastąpić tzw. drift. Ktoś inny może w tym samym czasie ręcznie zmienić coś w konsoli AWS lub uruchomić inny proces IaC. Jeśli zrobisz apply bez pliku planu, silnik wygeneruje nowy plan w locie, który może drastycznie różnić się od tego, który widziałeś.

Zasada brzmi: Planuj do pliku, a potem aplikuj dokładnie ten sam plik.

# 1. Generujesz plan i zapisujesz go do pliku binarnego
tofu plan -out=tfplan

# 2. (Opcjonalnie) Przeglądasz plan (w CI/CD to tutaj następuje zatwierdzenie przez człowieka)

# 3. Aplikujesz TYLKO i WYŁĄCZNIE ten konkretny plan
tofu apply "tfplan"

Dzięki temu masz gwarancję, że to, co sprawdziłeś i co zostało zaakceptowane, jest dokładnie tym, co zostanie wdrożone. Nie ma miejsca na niespodzianki.

Automatyzacja: Flaga `-detailed-exitcode`

Jeśli budujesz pipeline'y, które mają automatycznie wykrywać zmiany, nie polegaj na parsowaniu tekstu (to droga do błędów). Użyj flagi -detailed-exitcode.

Dzięki niej komenda plan zwraca specyficzne kody wyjścia: * 0: Brak zmian (infrastruktura jest zgodna z kodem). * 1: Wystąpił błąd. * 2: Istnieją zmiany, które wymagają zastosowania.

To pozwala Twojemu skryptowi CI/CD podjąć inteligentną decyzję: "Jeśli kod wyjścia to 2, wyślij powiadomienie na Slacka do DevOpsów, żeby sprawdzili plan".

Zasada niepodlegająca negocjacji: Nieprzeczytany plan to nieznana liczba zasobów do skasowania. Jeśli nie masz czasu przeczytać planu, nie masz prawa uruchamiać apply.

Czytanie planu: najważniejsza umiejętność w IaC