#terraform

Na czym polega opisanie infrastruktury w pliku

Zwykle serwer w chmurze powstaje przez klikanie w panelu dostawcy: wybór rozmiaru, dysku, sieci, reguł dostępu. Po pół roku nikt nie pamięta, dlaczego jedna maszyna ma otwarty port, którego nie ma druga, i czy to była decyzja, czy pomyłka.

Terraform odwraca kolejność. Zamiast klikać, opisuje się w pliku tekstowym stan, który ma zaistnieć: dwie maszyny takiego rozmiaru, sieć o takich adresach, reguła wpuszczająca ruch tylko z tych adresów, magazyn na kopie z blokadą kasowania. Plik trafia do repozytorium razem z kodem aplikacji, więc historia zmian infrastruktury wygląda tak samo jak historia zmian programu: widać, kto zmienił, kiedy i po co.

Warto podkreślić, że opis jest deklaracją stanu docelowego, a nie listą kroków. Nie pisze się „utwórz maszynę”, tylko „ma istnieć maszyna o takich cechach”, a narzędzie samo dochodzi do tego, co trzeba zrobić, żeby rzeczywistość się z tym zgodziła.

Jak to działa

Cykl ma trzy kroki. Najpierw narzędzie pobiera wtyczki dostawców, z którymi ma rozmawiać. Potem układa plan: odpytuje dostawcę, jak jest teraz, porównuje to z opisem i wypisuje różnicę w postaci listy, na której widać, co powstanie, co zostanie zmienione i co zniknie. Dopiero zatwierdzony plan jest wykonywany.

Ten środkowy krok jest sednem. Zmiana jednej linijki w opisie potrafi oznaczać odtworzenie maszyny od zera, bo część parametrów nie da się zmienić w locie. Plan pokazuje to przed wykonaniem, więc różnica między drobną poprawką a skasowaniem serwera produkcyjnego jest widoczna, zanim cokolwiek się wydarzy.

Plik stanu

Żeby wiedzieć, co już utworzył, Terraform prowadzi plik stanu, w którym zapisuje odwzorowanie między zasobami z opisu a identyfikatorami rzeczywistych zasobów u dostawcy. Ten plik jest najważniejszym i najbardziej wrażliwym elementem całości.

Jeżeli zginie, narzędzie przestaje wiedzieć, że coś już istnieje, i przy kolejnym uruchomieniu spróbuje utworzyć wszystko drugi raz. Jeżeli dwie osoby uruchomią zmianę jednocześnie na dwóch kopiach tego pliku, powstaną dwa rozjechane obrazy tej samej rzeczywistości. Dlatego stan trzyma się we wspólnym miejscu z blokadą na czas operacji, a nie na laptopie. Stan zawiera też wartości, które trafiły do zasobów, więc bywa, że mieszczą się w nim hasła, i z tego powodu nie należy do repozytorium.

Co się dzieje po zmianie ręcznej w panelu

Ktoś w pośpiechu dodaje regułę przez panel dostawcy, żeby odblokować pilną sprawę. Opis w plikach o tym nie wie. Przy następnym uruchomieniu narzędzie zobaczy różnicę i zaproponuje jej usunięcie, bo jego zadaniem jest doprowadzenie rzeczywistości do stanu z opisu. Jeżeli nikt nie przeczyta planu, poprawka zniknie i nikt nie połączy tego z awarią, która pojawi się dzień później.

Wniosek jest prosty i trudny zarazem. Jeśli infrastruktura jest opisana w kodzie, to kod musi być jedynym miejscem, w którym się ją zmienia. Środowisko obsługiwane raz tak, raz tak, jest gorsze niż obsługiwane wyłącznie ręcznie.

Czym różni się od Ansible

Terraform tworzy zasoby: maszyny, sieci, reguły, bazy danych u dostawcy. Ansible konfiguruje to, co już istnieje: instaluje pakiety, ustawia pliki konfiguracyjne, uruchamia usługi w środku systemu. Bywają zamiennie mylone, bo obie są narzędziami automatyzacji, ale odpowiadają na różne pytania: pierwsze na „co ma istnieć”, drugie na „jak to ma być ustawione”. W praktyce często pracują obok siebie.

Gdzie się to opłaca

Próg opłacalności nie leży w liczbie maszyn, tylko w liczbie powtórzeń. Środowisko, które powstaje raz i stoi latami, można zbudować ręcznie. Środowisko, które ma istnieć w trzech kopiach, testowej, przedprodukcyjnej i produkcyjnej, i różnić się między nimi wyłącznie rozmiarami, prosi się o opis, bo inaczej te trzy kopie rozjadą się w ciągu kilku miesięcy i nikt nie odtworzy, czym.

Na co uważać

Wtyczki dostawców zmieniają się i zmiana wersji potrafi zmienić znaczenie tego samego zapisu, więc wersje przypina się jawnie. Polecenie usuwające wszystko, co narzędzie utworzyło, istnieje i działa dokładnie tak, jak brzmi, dlatego uprawnienia do środowiska produkcyjnego nie powinny być takie same jak do testowego. Warto też pamiętać, że opis w kodzie nie jest kopią zapasową danych: odtworzy maszynę i sieć, ale nie zawartość bazy.

Kiedy lepiej bez tej warstwy

Firma z jednym serwerem w biurze i dwiema maszynami wirtualnymi obsłuży się prościej bez tej warstwy. Podobnie zespół, w którym nikt nie zna tego narzędzia: opis, którego nikt nie umie przeczytać, blokuje pracę mocniej niż jej brak, bo zwykłe kliknięcie w panelu przestaje być dozwolone, a poprawka w kodzie wymaga osoby, której akurat nie ma.