Terraform Fundamentals

Cześć, tu Alex z DEV STORIES DOT EU. Podstawy Terraform, odcinek 1 z 13. Dawniej provisioning serwerów oznaczał założenie ticketu w helpdesku i czekanie dwóch tygodni, aż ktoś wyklika to w konsoli chmurowej. Dziś dokładnie ten sam proces to prosty pull request, który bezpiecznie deployuje się w kilka minut. Ta zmiana jest w całości napędzana paradygmatem Infrastructure as Code, a HashiCorp Terraform jest jego głównym motorem napędowym. Infrastructure as Code to dokładnie to, na co wskazuje nazwa. Zarządzasz swoimi bazami danych, sieciami wirtualnymi i instancjami obliczeniowymi za pomocą zwykłych plików tekstowych zamiast ręcznego wyklikiwania. Te pliki mogą być wersjonowane, przechodzić code review i być testowane automatycznie. Aby zrozumieć, dlaczego to jest tak potężne, wyobraź sobie administratora systemów, który potrzebuje nowej maszyny wirtualnej na Azure. Używając imperatywnego workflow, mógłby napisać skomplikowany skrypt w PowerShellu. Ten skrypt musi jawnie definiować każdą akcję w odpowiedniej kolejności. Mówi systemowi, żeby się zalogował, sprawdził, czy sieć istnieje, utworzył ją, jeśli jej nie ma, przypisał publiczne IP i na koniec uruchomił serwer. Jeśli skrypt wyrzuci błąd na czwartym kroku, zostajesz z częściowo zbudowaną infrastrukturą. Odpalenie skryptu po raz drugi często powoduje błędy, ponieważ niektóre zasoby już istnieją. Terraform używa natomiast podejścia deklaratywnego. Nie piszesz sekwencji kroków. Po prostu definiujesz pożądany stan końcowy. Piszesz plik konfiguracyjny, w którym określasz, że chcesz maszynę wirtualną na Azure podpiętą do konkretnej sieci. Terraform porównuje twój pożądany stan z tym, co aktualnie istnieje w chmurze. Następnie oblicza dokładną sekwencję wywołań API potrzebną do zniwelowania tej różnicy. Jeśli sieć już istnieje, Terraform zostawia ją w spokoju i buduje tylko serwer. I tu jest kluczowa sprawa. Wielu inżynierów myli narzędzia do provisioningu infrastruktury, takie jak Terraform, z narzędziami do configuration management, takimi jak Chef, Puppet czy Ansible. To nie to samo. Terraform buduje dom. Narzędzia do configuration management ustawiają w nim meble. Terraform provisionuje surowe zasoby chmurowe, takie jak load balancery i maszyny wirtualne. Następnie Ansible lub Chef logują się na te maszyny, żeby zainstalować pakiety oprogramowania i uruchomić usługi w tle. Narzędzia do configuration management zostały w gruncie rzeczy zaprojektowane dla mutable infrastructure. Zakładają, że serwer będzie żył długo i będzie poddawany ciągłemu patchowaniu i modyfikacjom. Terraform pcha cię w stronę immutable infrastructure. Jeśli środowisko potrzebuje innej wersji systemu operacyjnego, Terraform nie loguje się i nie odpala skryptu aktualizującego. Niszczy stary serwer i provisionuje zupełnie nowy z odpowiednim obrazem. To rygorystyczne podejście gwarantuje, że twój kod zawsze pokrywa się z rzeczywistością, całkowicie eliminując configuration drift. Ten workflow jest szczególnie cenny, ponieważ jest platform agnostic. Duże firmy rzadko korzystają tylko z jednego vendora. Możesz uruchamiać swoje główne workloady na Azure, obsługiwać DNS przez Cloudflare i zarządzać routingiem incydentów w PagerDuty. Terraform zarządza tym wszystkim poprzez model providerów. Provider to po prostu plugin, który rozumie API konkretnego vendora. Używając wielu providerów, możesz zbudować jedną konfigurację, która jednocześnie stawia bazę danych na Azure, konfiguruje niezbędne rekordy DNS i ustawia alerty w monitoringu. Pod spodem wywołania API się zmieniają, ale twój workflow pozostaje dokładnie taki sam. Jeśli chcesz pomóc w tworzeniu kolejnych odcinków, wyszukaj DevStoriesEU na Patreon, aby wesprzeć nasz program. Narzędzie, które tylko automatyzuje zadania, sprawia, że pracujesz szybciej, ale narzędzie, które wymusza stan deklaratywny, sprawia, że cały twój system jest przewidywalny. Chciałbym poświęcić chwilę, żeby podziękować ci za słuchanie — to bardzo nam pomaga. Miłego dnia!

Cześć, tu Alex z DEV STORIES DOT EU. Podstawy Terraform, odcinek 2 z 13. Klikasz deploy, patrzysz w konsolę i trzymasz kciuki, mając nadzieję, że właśnie nie położyłeś środowiska produkcyjnego. Ten ślepy skok wiary to ogromne ryzyko i to jest dokładnie to, co eliminuje podstawowy workflow w Terraform. Ten workflow składa się z trzech ścisłych kroków: write, plan i apply. Każdy krok działa niezależnie, żeby przełożyć twoje wymagania na działające zasoby. Zaczynasz od fazy write. Tworzysz pliki konfiguracyjne, które deklarują dokładnie taką infrastrukturę, jakiej chcesz. Nie piszesz proceduralnego skryptu, który krok po kroku mówi, jak zbudować serwer. Opisujesz końcowy, pożądany stan swojego środowiska. Zapisujesz te pliki, a twój kod staje się jedynym źródłem prawdy o tym, co powinno istnieć. Nowi użytkownicy czasami myślą, że kolejnym krokiem jest po prostu sekwencyjne wykonanie tych plików z góry na dół. To narzędzie tak nie działa. Nie odpala komend w ciemno. Zamiast tego przechodzi do fazy plan. Faza plan to absolutna supermoc tego workflow. Kiedy odpalasz komendę plan, narzędzie ewaluuje twoją nową konfigurację w odniesieniu do obecnego, rzeczywistego stanu twojej infrastruktury. Oblicza precyzyjnego diffa między rzeczywistością a twoim pożądanym kodem. I tu jest kluczowa sprawa. Narzędzie czyta tego diffa i generuje bardzo szczegółowy dry run każdej pojedynczej akcji, którą zamierza wykonać. Pomyśl o inżynierze, który musi dodać Azure Load Balancer do środowiska live. Aktualizuje swoje pliki konfiguracyjne i odpala komendę plan. System łączy się z cloud providerem, sprawdza aktywny stan i wyświetla dokładne podsumowanie. Inżynier czyta output i widzi jeden zasób do dodania, zero do zmiany i zero do destroy. Output szczegółowo opisuje dokładne właściwości nowego load balancera. Inżynier waliduje ten dry run. Wie, że zmiana jest bezpieczna, zanim pojedynczy API call zmodyfikuje prawdziwą infrastrukturę. Nie ma tu zgadywania. Po zwalidowaniu outputu przechodzisz do fazy apply. To jest moment wykonania. Narzędzie bierze dokładnego diffa obliczonego podczas fazy plan i buduje ścisły graf wykonania. Mapuje wszystkie zależności. Jeśli twój nowy load balancer wymaga dedykowanego publicznego adresu IP, graf wykonania gwarantuje, że IP zostanie sprovisionowane jako pierwsze. System czeka, aż IP stanie się dostępne, pobiera jego nowy adres i dopiero wtedy tworzy load balancer. Automatycznie obsługuje timing i kolejność. Ponieważ faza apply ściśle trzyma się zatwierdzonego planu wykonania, nigdy nie masz sytuacji, w której zasoby podnoszą się w złej kolejności albo przypadkowo usuwasz istniejące bazy danych przez literówkę. Ten workflow wymusza na tobie oddzielenie intencji od wykonania. Najpotężniejszym aspektem tego procesu nie jest samo zautomatyzowane provisionowanie. Jest nim całkowita eliminacja operacyjnego niepokoju dzięki przewidywalnym, możliwym do zweryfikowania dry runom. To wszystko w tym odcinku. Dzięki za wysłuchanie i buduj dalej!

Cześć, tu Alex z DEV STORIES DOT EU. Podstawy Terraform, odcinek 3 z 13. Sama w sobie, główna aplikacja Terraform nie wie tak naprawdę, jak zbudować Azure Virtual Machine ani jak utworzyć bazę danych. To po prostu silnik, który ewaluuje kod, określa zależności i zarządza state'em. Aby wykonać jakąkolwiek konkretną pracę, polega na tysiącach dostępnych do pobrania pluginów tłumaczących. To prowadzi nas do providerów i tego, jak łączysz swój kod z Azure. Częstym błędem jest myślenie, że sama aplikacja Terraform zawiera logikę dla każdej platformy chmurowej. Otóż nie. Binarka, którą instalujesz na swoim komputerze, jest całkowicie agnostyczna względem infrastruktury. Rozumie język konfiguracji i workflow deployu, ale nie ma absolutnie żadnej zahardkodowanej wiedzy o żadnym konkretnym API chmurowym. Zamiast tego, Terraform używa pluginów nazywanych providerami. Provider to samodzielny kawałek softu, który rozumie endpointy, metody uwierzytelniania i zachowania zasobów dla konkretnej platformy. Istnieje provider dla Microsoft Azure, kolejny dla Amazon Web Services, a także inne dla platform Software as a Service, takich jak GitHub czy Datadog. Te pluginy są publikowane i hostowane w centralnym katalogu o nazwie Terraform Registry. Kiedy zaczynasz nowy projekt infrastrukturalny, musisz jawnie zadeklarować, z jakich providerów będzie korzystał twój kod. Określasz też dokładną wersję providera, jakiej potrzebujesz. Lockowanie wersji to kluczowa praktyka. Dzięki temu masz pewność, że jeśli jutro zmieni się API chmurowe albo plugin providera dostanie duży update, twój deploy nie wysypie się niespodziewanie. To ty dokładnie kontrolujesz, kiedy zrobić upgrade. Samo zadeklarowanie providera w pliku tekstowym go nie instaluje. Musisz odpalić komendę inicjalizującą w terminalu. Ten krok inicjalizacji aktywnie łączy się z Terraform Registry, pobiera wymagane pluginy providera i cache'uje je w ukrytym lokalnym katalogu. Dopóki nie wykonasz tego kroku, twój projekt Terraform nie może wchodzić w interakcje z żadnym zewnętrznym systemem. Spójrzmy, jak to skonfigurować dla nowego projektu łączącego się z firmową subskrypcją Azure. Użyjesz oficjalnego providera Azure Resource Manager, znanego jako azurerm. Po zadeklarowaniu potrzebnej wersji, musisz skonfigurować specyficzne zachowanie providera. Każdy provider ma swoje własne wymagania konfiguracyjne oparte na bazowym API. W przypadku Azure, plugin wymaga od ciebie jawnego zadeklarowania, jak ma obsługiwać pewne zachowania zasobów. Na przykład, musisz powiedzieć providerowi, czy powinien trwale usuwać podpięte dyski storage'owe, gdy maszyna wirtualna jest niszczona. Provider wymaga tej konfiguracji z góry, aby destrukcyjne akcje były zawsze celowe. Po zainicjalizowaniu i skonfigurowaniu, provider działa jak warstwa tłumacząca typu plug-and-play. Kiedy wykonujesz swój kod, główny silnik Terraform oblicza różnicę między twoją obecną infrastrukturą a pożądanym state'em. Następnie przekazuje te ogólne instrukcje do plugina providera Azure. Plugin przejmuje stery, tłumacząc twoje intencje na uwierzytelnione requesty HTTP wysyłane bezpośrednio do API Azure Resource Manager. Plugin czeka, aż Azure skończy tworzyć lub modyfikować zasoby, tłumaczy odpowiedź API z powrotem na format zrozumiały dla Terraform i przekazuje końcowe dane z powrotem do głównego silnika. Sam Terraform nigdy nie gada bezpośrednio z twoim środowiskiem chmurowym; deleguje każdy pojedynczy API call do plugina providera, co czyni providera faktycznym mostem między twoim kodem a działającą infrastrukturą. To wszystko w tym odcinku. Dzięki za wysłuchanie i buduj dalej!

Cześć, tu Alex z DEV STORIES DOT EU. Podstawy Terraforma, odcinek 4 z 13. Patrzysz na swój kod i widzisz bazę danych oznaczoną jako primary, ale po zalogowaniu się do konsoli chmurowej ta sama baza danych nazywa się zupełnie inaczej, na przykład db-cluster-node-one. Jeśli chcesz, żeby coś fizycznie istniało w twoim środowisku chmurowym, musisz o to poprosić, używając najważniejszej konstrukcji w Terraformie, ale musisz też zrozumieć, jak Terraform nazywa rzeczy. Dzisiaj porozmawiamy o deklarowaniu infrastruktury za pomocą resources. Resources to podstawowe komponenty twojej infrastruktury. Za każdym razem, gdy chcesz utworzyć, zaktualizować lub usunąć obiekt, piszesz blok resource. Ten obiekt może być fizycznym komponentem, takim jak instancja compute lub dysk storage, albo logicznym bytem, takim jak rekord DNS czy role assignment. Blok resource to sposób, w jaki tłumaczysz pomysł na komponent infrastruktury na API request, który twój provider chmurowy faktycznie rozumie. Deklarując blok resource, definiujesz jego tożsamość za pomocą dwóch różnych etykiet. Najpierw deklarujesz resource type. To mówi Terraformowi dokładnie, jaki rodzaj obiektu chcesz zbudować i który provider to zrobi. Typ zawsze zaczyna się od namespace'u providera, na przykład Azure lub AWS, po którym następuje konkretna usługa. W zasadzie mówisz Terraformowi, że potrzebujesz resource group w Azure albo storage bucketa w AWS. Zaraz po resource type definiujesz lokalny identyfikator. To po prostu taki pseudonim. Istnieje tylko w twojej konfiguracji Terraforma. Używasz tego pseudonimu, żeby odwoływać się do obiektu z innych części twojego kodu. Nie ma to absolutnie żadnego wpływu na to, co widzi twój provider chmurowy. To prowadzi nas do samego bloku konfiguracji. Kiedy zadeklarujesz typ i lokalny pseudonim, definiujesz argumenty dla tego resource'a. Argumenty to konkretne ustawienia i wartości, które konfigurują ten obiekt. To tutaj przekazujesz faktyczne parametry wymagane przez API providera chmurowego. Żeby złożyć to w całość, wyobraź sobie, że deployujesz resource group w Azure. Deklarujesz resource type dla Azure resource group i nadajesz mu lokalny pseudonim, na przykład main. Wewnątrz bloku konfiguracji podajesz faktyczne argumenty. Definiujesz argument name i ustawiasz go na rg-enterprise-prod, oraz definiujesz argument location, ustawiając go na konkretny region. Kiedy odpalasz swój deployment, Terraform używa resource type, żeby wiedzieć, które API providera wywołać. Używa twoich argumentów, żeby dokładnie powiedzieć API, jak skonfigurować ten resource. W portalu Azure twoja resource group pojawi się jako rg-enterprise-prod. Azure nie wie nic o pseudonimie main. Ale wracając do twojego kodu, za każdym razem, gdy musisz pobrać ID albo location tej resource group, żeby przekazać je do maszyny wirtualnej albo bazy danych, po prostu prosisz Terraforma o dane przechowywane przez lokalny resource o nazwie main. Każdy resource type ma swój własny, unikalny zestaw argumentów. Niektóre są obowiązkowe, jak location dla resource group albo instance size dla wirtualnego serwera. Inne są opcjonalne, jak tagowanie czy konkretne reguły routingu. Dokumentacja providera dokładnie określa, jakich argumentów możesz użyć. Po prostu mapujesz potrzebne wartości w bloku resource, a Terraform zajmuje się tłumaczeniem ich na API calls, które faktycznie provisionują twoją infrastrukturę. Twój lokalny identyfikator należy do Terraforma, żeby utrzymać czytelność twojego kodu, ale twoje argumenty należą do chmury, żeby definiować rzeczywistość. Dzięki za uwagę. Do następnego razu!

Cześć, tu Alex z DEV STORIES DOT EU. Podstawy Terraform, odcinek 5 z 13. Skoro baza danych musi istnieć, zanim serwer webowy będzie mógł się z nią połączyć, skąd narzędzie do infrastruktury wie, co zbudować najpierw, bez sekwencyjnych skryptów? Jeśli masz doświadczenie z imperatywnymi skryptami, takimi jak Bash czy Python, możesz szukać sposobów na wymuszenie egzekucji linijka po linijce. Ale w Terraformie kolejność linijek w pliku nie ma żadnego znaczenia. Jedyne, co się liczy, to relacje i zależności zasobów. Terraform to bardzo inteligentny silnik wykonawczy. Zanim cokolwiek utworzy, analizuje twoją konfigurację i buduje skierowany graf acykliczny. Ten graf dokładnie mapuje, jak każdy element infrastruktury łączy się z pozostałymi. Używa tej mapy, żeby określić najwydajniejszą kolejność tworzenia, budując niepowiązane zasoby równolegle i sekwencjonując te, które od siebie zależą. Nigdy nie piszesz ręcznych skryptów z wait albo sleep. Zazwyczaj Terraform automatycznie ustala tę kolejność poprzez implicit dependencies. Implicit dependency występuje, gdy jeden zasób odwołuje się do atrybutu innego zasobu. Wyobraź sobie scenariusz, w którym tworzysz Azure Virtual Network i Subnet. Subnet nie może istnieć bez Virtual Network. W swojej konfiguracji definiujesz blok Virtual Network, a potem blok Subnet. Wewnątrz bloku Subnet ustawiasz argument nazwy Virtual Network tak, aby wskazywał bezpośrednio na atrybut name zasobu Virtual Network, który właśnie zdefiniowałeś. Kiedy Terraform to parsuje, widzi to połączenie. Z automatu wie, że musi skończyć tworzenie Virtual Network i pobrać jego wygenerowaną nazwę, zanim w ogóle zacznie tworzyć Subnet. Nie musisz mu mówić, co ma robić. Po prostu przekazujesz dane, a Terraform zajmuje się timingiem. To jest najważniejsza część. Zawsze używaj implicit dependencies, jeśli tylko możesz. Odwołując się bezpośrednio do atrybutów, dajesz Terraformowi dokładne informacje, których potrzebuje, żeby bezpiecznie optymalizować twoje deploye. Czasami relacja między dwoma zasobami nie jest widoczna w kodzie. Możesz mieć sytuację, w której zasób wymaga, żeby inny zasób był w pełni aktywny, ale tak naprawdę nie musi pobierać z niego żadnych danych. Wyobraź sobie deploy maszyny wirtualnej, na której działa aplikacja, podczas gdy jednocześnie provisionujesz zarządzaną bazę danych. Aplikacja potrzebuje, żeby baza danych skończyła się bootować, zanim sama będzie mogła wystartować. Jednak konfiguracja maszyny wirtualnej nie odwołuje się do żadnych atrybutów z zasobu bazy danych. Ponieważ nie ma żadnego linku do danych, Terraform zakłada, że te dwa zasoby są całkowicie niepowiązane i spróbuje zbudować je w tym samym czasie. Aplikacja zbootuje się, poszuka bazy danych, która jeszcze nie istnieje, i zfailuje. Żeby to naprawić, używasz explicit dependencies. Terraform dostarcza meta-argument o nazwie depends on. Dodajesz ten argument do bloku maszyny wirtualnej i przekazujesz mu listę zawierającą zasób bazy danych. To explicite mówi Terraformowi, żeby wstrzymał tworzenie maszyny wirtualnej, aż baza danych całkowicie skończy się provisionować. Powinieneś traktować explicit dependencies jako ostateczność. Zmuszają one Terraforma do bardziej konserwatywnej egzekucji, co spowalnia twoje deploye. Mogą też sprawić, że twoja konfiguracja będzie trudniejsza w utrzymaniu z biegiem czasu, ponieważ rzeczywisty powód tej zależności nie zawsze jest oczywisty dla kolejnego inżyniera, który będzie czytał ten plik. Pozwolenie, by graf egzekucji odwalił czarną robotę, to coś, co odróżnia infrastrukturę deklaratywną od proceduralnych skryptów, więc przestań próbować mikrozarządzać kolejnością wykonywania i pozwól, żeby data flow dyktował sekwencję. Dzięki za spędzenie ze mną tych kilku minut. Do usłyszenia następnym razem, trzymaj się.

Cześć, tu Alex z DEV STORIES DOT EU. Podstawy Terraforma, odcinek 6 z 13. Piszesz kod infrastruktury, odpalasz apply, a twoje serwery wstają idealnie. Ale jeśli odpalisz apply ponownie pięć minut później, nic się nie dzieje. Terraform wie, że robota została już zrobiona. W przeciwieństwie do prostych skryptów automatyzujących, które ślepo wykonują polecenia, Terraform ma pamięć. Bez niej byłby całkowicie ślepy na infrastrukturę, którą właśnie zbudował. Ta pamięć nazywa się Terraform State. Kiedy odpalasz Terraforma, tworzy on lokalny plik o nazwie terraform dot tfstate. Wielu inżynierów początkowo uważa ten plik za utrapienie. Wydaje się być kolejnym artefaktem, którym trzeba zarządzać i który trzeba zabezpieczać. Ale ten plik to absolutny rdzeń działania Terraforma. Terraform potrzebuje mechanizmu, żeby mapować logiczne resource'y zdefiniowane w twoich plikach konfiguracyjnych na fizyczne, zdalne obiekty w twoim środowisku chmurowym. Częstym błędem jest myślenie, że Terraform po prostu patrzy na tagi u cloud providera, żeby ogarnąć, czym zarządza. Możesz pomyśleć, że taguje serwer podczas tworzenia, a potem przeszukuje chmurę po tym konkretnym tagu, żeby wiedzieć, co zaktualizować. To podejście szybko przestaje się sprawdzać. Nie wszystkie resource'y w chmurze obsługują tagi. Co więcej, ktoś mógłby ręcznie zedytować lub usunąć tag, zrywając to połączenie. I wreszcie, przeszukiwanie ogromnego konta chmurowego w poszukiwaniu konkretnych tagów za każdym razem, gdy odpalasz plan, byłoby niesamowicie wolne. Ponieważ tagi są zawodne, Terraform używa dedykowanego, mocno ustrukturyzowanego pliku state. Plik state działa jak prywatna baza danych do mapowania. Kiedy deklarujesz resource w kodzie, Terraform tworzy go przez API providera. Provider zwraca unikalny, fizyczny identyfikator dla tego nowo utworzonego obiektu. Terraform bierze twoją logiczną nazwę resource'a z kodu, paruje ją z tym unikalnym cloud ID i zapisuje tę parę w pliku state. Weźmy praktyczny scenariusz. Decydujesz się zmienić rozmiar maszyny wirtualnej na Azure w swoim kodzie. Kiedy odpalasz apply, Terraform nie zgaduje, którą maszynę zmodyfikować. Sprawdza plik state, wyszukuje twoją logiczną nazwę resource'a i pobiera dokładny instance ID z Azure. Następnie wysyła request o aktualizację, celując w ten konkretny ID. Bez pliku state Terraform nie wiedziałby, czy ma zaktualizować istniejącą maszynę, czy po prostu utworzyć jej duplikat. Poza mapowaniem, state zajmuje się śledzeniem metadanych. Terraform musi znać dokładną kolejność, w jakiej resource'y zostały utworzone, żeby móc je bezpiecznie aktualizować lub usuwać. Jeśli serwer webowy wymaga bazy danych, ta zależność jest zapisana w twoim kodzie. Jednak jeśli usuniesz cały ten blok kodu, żeby zwinąć środowisko, Terraform nie będzie już w stanie odczytać kodu, by znaleźć tę zależność. Plik state przechowuje kopię tych historycznych metadanych, upewniając się, że Terraform usunie serwer webowy przed bazą danych. State zapewnia również kluczowy caching dla wydajności. Odpytywanie API cloud providera, żeby zebrać aktualny status tysięcy reguł sieciowych, storage bucketów i node'ów obliczeniowych, zajmuje mnóstwo czasu. Cloud providerzy narzucają też surowe API rate limity. Plik state działa jak cache atrybutów twojej infrastruktury. Odwołując się do tego cache'a, Terraform minimalizuje liczbę wolnych i kosztownych wywołań API potrzebnych do wyliczenia planu. Oto kluczowy wniosek. Twoja konfiguracja opisuje to, czego chcesz, cloud provider trzyma to, co faktycznie istnieje, a plik state to jedyny ostateczny most łączący te dwa światy. To tyle na dzisiaj. Do usłyszenia następnym razem!

Cześć, tu Alex z DEV STORIES DOT EU. Podstawy Terraform, odcinek 7 z 13. Hardcodowanie wartości jest w porządku do szybkiego testu, ale co się stanie, gdy musisz zrobić deploy dokładnie tego samego setupu zarówno na środowisko deweloperskie, jak i produkcyjne? Nie możesz duplikować i przepisywać swojego kodu przy każdym nowym deploymencie. Mechanizmem, który rozwiązuje ten problem, jest parametryzacja za pomocą input variables. Input variables służą jako parametry dla modułu Terraform. Pozwalają ci one dostosować aspekty twojej infrastruktury bez zmiany kodu źródłowego. To dokładnie ten etap, w którym twój kod przechodzi od proof of concept do szablonu production-ready. Używając zmiennych, piszesz konfigurację raz i reużywasz jej wszędzie. Zanim przejdziemy do mechaniki, musimy wyjaśnić częste nieporozumienie. Istnieje wyraźna różnica między deklaracją zmiennej a przypisaniem do niej wartości. Deklaracja zmiennej po prostu informuje Terraform, że dany parametr istnieje i definiuje jego reguły. Przypisanie wartości to faktyczne przekazanie mu danych podczas deploymentu. Deklarujesz zmienną używając bloku variable, po którym podajesz unikalną nazwę. Wewnątrz tego bloku definiujesz oczekiwany typ danych. Terraform obsługuje kilka typów. String to po prostu zwykły tekst. List to uporządkowana sekwencja wartości, jak na przykład wiele availability zones. Map to zbiór par key-value, co jest idealne do aplikowania standardowych tagów dla zasobów. Wewnątrz bloku variable możesz również ustawić wartość defaultową. Jeśli podasz default, zmienna staje się opcjonalna. Jeśli użytkownik nie poda wartości podczas deploymentu, Terraform po prostu użyje defaultu. Jeśli nie ustawisz defaultu, Terraform wymusi na użytkowniku podanie wartości, zanim przejdzie dalej. Przełóżmy to na praktyczny scenariusz. Załóżmy, że masz deployment na Azure. W tym momencie twoja konfiguracja jawnie wymaga małego rozmiaru maszyny wirtualnej o nazwie Standard B2s i hardcoduje tag środowiska jako dev. Aby zrobić to reużywalnym, zastępujesz ten zhardcodowany tekst referencją. W Terraform odwołujesz się do input variable wpisując var kropka, a następnie nazwę zmiennej. Więc zamiast pisać Standard B2s, piszesz var kropka vm size. Zamiast dev, piszesz var kropka environment. Teraz twój kod jest elastyczny, ale Terraform nadal musi wiedzieć, jakich wartości użyć, gdy faktycznie się uruchomi. I tutaj do gry wchodzą pliki definicji zmiennych. Są to pliki kończące się na kropka tfvars. Plik tfvars to po prostu lista nazw zmiennych i odpowiadających im wartości. Dla twojego produkcyjnego deploymentu tworzysz plik o nazwie prod kropka tfvars. Wewnątrz niego ustawiasz zmienną environment na prod, a zmienną vm size na większą instancję, taką jak Standard D4s. Kiedy uruchamiasz Terraform, wskazujesz mu ten plik. Terraform czyta plik tfvars, wstrzykuje te wartości w twoje referencje var kropka i provisionuje środowisko produkcyjne. Jutro możesz wskazać dokładnie ten sam kod Terraform na plik dev kropka tfvars, aby postawić małe środowisko testowe. Oto kluczowy wniosek. Trzymanie logiki całkowicie oddzielnie od danych specyficznych dla środowiska sprawia, że infrastruktura jest naprawdę powtarzalna. Jeśli uważasz te odcinki za pomocne i chcesz wesprzeć podcast, możesz wyszukać DevStoriesEU na Patreonie. To wszystko w tym odcinku. Dzięki za słuchanie i buduj dalej!

Cześć, tu Alex z DEV STORIES DOT EU. Podstawy Terraform, odcinek 8 z 13. Twój deploy infrastruktury chmurowej kończy się idealnie, ale nadal masz jeden poważny problem: musisz znać jej publiczny adres IP, żeby w ogóle się z nią połączyć. Przeszukiwanie dashboardów dostawcy chmury mija się z celem automatyzacji. Potrzebujesz sposobu na wyciągnięcie tych konkretnych danych bezpośrednio z Terraform. I tu z pomocą przychodzi wystawianie danych za pomocą wartości output. Wartości output to w zasadzie wartości zwracane przez konfigurację Terraform. Kiedy definiujesz i tworzysz zasób, dostawca chmury dynamicznie generuje pewne atrybuty. To rzeczy, których nie możesz znać przed deployem, takie jak przypisany adres IP, wygenerowane hasło do bazy danych czy konkretna nazwa domeny. Używasz bloków output, żeby przechwycić te dynamicznie generowane atrybuty i wystawić je na zewnątrz. Aby go zdefiniować, piszesz blok output, a po nim etykietę. Ta etykieta to po prostu nazwa, którą chcesz przypisać do tego outputu. Wewnątrz bloku definiujesz jeden wymagany argument o nazwie value. Ten argument wskazuje na konkretne dane, które chcesz wyciągnąć. Na przykład, jeśli tworzysz maszynę wirtualną, możesz ustawić argument value tak, żeby wskazywał bezpośrednio na atrybut publicznego IP tego konkretnego zasobu maszyny. Weźmy konkretny scenariusz. Masz zautomatyzowany pipeline, który robi deploy nowego klastra Azure Kubernetes Service. Kiedy deploy się kończy, twoi developerzy potrzebują automatycznie wygenerowanego, surowego endpointu Kubernetes, żeby skonfigurować swoje lokalne narzędzia do połączeń. Bez outputu ktoś musiałby zalogować się do portalu chmurowego, znaleźć klaster i ręcznie skopiować URL. Zamiast tego piszesz blok output o nazwie cluster endpoint. Ustawiasz jego value tak, żeby odwoływało się do atrybutu fully qualified domain name nowo zbudowanego klastra Kubernetes. Kiedy Terraform skończy aplikować twoją konfigurację, zbiera wszystkie zdefiniowane wartości output i wypisuje je bezpośrednio w command line interface. Twój pipeline automatyzacji może wtedy odczytać ten tekst i przekazać endpoint prosto do developerów. Możesz też pobrać te wartości później, bez odpalania nowego deployu. Po prostu odpalasz komendę Terraform output w swoim terminalu. W przypadku skryptów automatyzacji, możesz nawet kazać tej komendzie zwrócić dane jako surowy tekst albo w formacie JSON, co ułatwia ich parsowanie innym narzędziom. Czasami dane, które musisz wyrzucić na output, są poufne, jak hasło do bazy danych czy klucz prywatny. Nie chcesz, żeby te stringi przewijały się na współdzielonym ekranie terminala albo siedziały na stałe w logach twojego continuous integration. Żeby temu zapobiec, dodajesz argument sensitive wewnątrz bloku output i ustawiasz go na true. Terraform ukryje wtedy rzeczywistą wartość w konsoli, zastępując ją placeholderem wskazującym, że wartość jest sensitive. Oto kluczowa sprawa. Ustawienie outputu na sensitive ukrywa go tylko na ekranie terminala. Nie szyfruje to ani nie ukrywa danych w pliku state Terraform. Hasło lub klucz nadal są przechowywane jako plain text w twoich danych state na dysku albo w zdalnym backendzie. Flaga sensitive to wyłącznie filtr wyświetlania dla command line interface, a nie mechanizm bezpieczeństwa dla twojego storage'u. Wartości output ostatecznie działają jak API twojej konfiguracji. To ustrukturyzowany, przewidywalny sposób na przekazanie kluczowych informacji z powrotem ludziom lub narzędziom automatyzacji w momencie zakończenia runa. To wszystko w tym odcinku. Dzięki za wysłuchanie i buduj dalej!

Cześć, tu Alex z DEV STORIES DOT EU. Podstawy Terraform, odcinek 9 z 13. Nie każdy element infrastruktury w twoim środowisku chmurowym został zbudowany przez kod Terraform, który właśnie piszesz. Mimo to twój kod nadal potrzebuje sposobu na bezpieczne połączenie się z tymi istniejącymi systemami, bez ich przypadkowej modyfikacji. Odpytywanie za pomocą Data Sources to dokładnie sposób, w jaki sobie z tym radzisz. Częstym powodem do nieporozumień podczas nauki Terraform jest różnica między blokiem resource a blokiem data. Wyjaśnijmy to sobie od razu. Blok resource mówi Terraformowi, żeby utworzył, zaktualizował i przejął na własność obiekt infrastruktury. Blok data wykonuje tylko wyszukiwanie read-only. Prosi API providera o znalezienie istniejącego obiektu i zwrócenie jego szczegółów, aby twoja konfiguracja mogła je odczytać. Ta funkcja read-only to fundament architektury decoupled. Weźmy pod uwagę standardowy setup enterprise. Scentralizowany zespół sieciowy buduje i zarządza korporacyjną siecią Virtual Network. Jako deweloper aplikacji musisz zrobić deploy Azure Virtual Machine i podłączyć ją do tej konkretnej sieci. Nie jesteś właścicielem kodu tej sieci. Nie powinieneś też hardcodować unikalnego ID sieci w swoich plikach Terraform, ponieważ zahardcodowane ID łatwo się psują, jeśli środowiska są kiedykolwiek odtwarzane. Zamiast tego, po prostu wyszukujesz tę sieć. Robisz to, definiując blok data. Składnia wygląda bardzo podobnie do bloku resource. Zaczynasz od słowa kluczowego data. Następnie określasz typ Data Source, na przykład azurerm virtual network. Potem nadajesz mu lokalną nazwę, na przykład corporate, której użyjesz do odwoływania się do niego później w swoim kodzie. Wewnątrz bloku definiujesz argumenty wyszukiwania. Działają one jak ścisłe filtry. Możesz przekazać czytelną dla człowieka nazwę Virtual Network i Resource Group, do której należy. Terraform używa tych argumentów do skonstruowania query. Kiedy odpalasz Terraform plan, Terraform łączy się z Azure API i szuka Virtual Network, która pasuje do twoich filtrów. Jeśli API zwróci dokładnie jedno dopasowanie, Terraform pobiera właściwości tej sieci do pamięci. Jeśli query zwróci zero dopasowań, albo jeśli filtry są zbyt luźne i zwrócą wiele dopasowań, Terraform natychmiast się zatrzymuje i rzuca błąd. Ta rygorystyczność jest celowa. Zapobiega to przypadkowemu zrobieniu deployu twojej aplikacji do złej podsieci lub środowiska. Kiedy Data Source pomyślnie pobierze informacje, możesz wyciągnąć z niego dowolny wyeksportowany atrybut. Składnia odwoływania się do Data Source jest bardzo ustrukturyzowana. Zaczynasz od słowa data, po którym następuje kropka, typ Data Source, kropka, twoja lokalna nazwa i na końcu konkretny atrybut, którego potrzebujesz. W naszym scenariuszu wpisałbyś data kropka azurerm virtual network kropka corporate kropka id. Przekazujesz ten konkretny string prosto do bloku resource swojej maszyny wirtualnej, całkowicie omijając potrzebę hardcodowania statycznej wartości. A oto najważniejsza część. Data Sources pozwalają ci traktować otaczającą infrastrukturę jako dynamiczną usługę. Nie musisz budować środowiska, żeby z nim wchodzić w interakcję, i możesz bezpiecznie łączyć ze sobą niezależne workspaces, po prostu odpytując o dokładne identyfikatory, których potrzebujesz w runtime. Dzięki za wspólnie spędzony czas. Mam nadzieję, że dowiedziałeś się czegoś nowego.

Cześć, tu Alex z DEV STORIES DOT EU. Podstawy Terraforma, odcinek 10 z 13. Jeśli musisz zdeployować pięćdziesiąt identycznych serwerów WWW, ostatnią rzeczą, na jaką masz ochotę, jest kopiowanie i wklejanie tego samego bloku kodu pięćdziesiąt razy. Możesz szukać tradycyjnej pętli while lub for, ale Terraform tak nie działa. Zamiast tego zarządzasz skalą na poziomie bloku, używając count i for each. Domyślnie blok resource konfiguruje dokładnie jeden obiekt infrastruktury. Aby sprowizjonować wiele obiektów, dodajesz meta-argument count wewnątrz tego bloku. Przyjmuje on liczbę całkowitą. Jeśli ustawisz count na trzy, Terraform sprowizjonuje trzy obiekty z tego jednego bloku konfiguracji. W prawdziwym świecie te obiekty zazwyczaj nie mogą być w stu procentach identyczne. Potrzebują unikalnych nazw lub adresów IP. Aby to obsłużyć, Terraform udostępnia obiekt count kropka index. To specjalna zmienna dostępna tylko w blokach, które mają argument count. Załóżmy, że deployujesz trzy maszyny wirtualne w Azure. Piszesz jeden blok resource dla maszyny wirtualnej i ustawiasz count na trzy. Wewnątrz bloku przypisujesz nazwę maszyny, łącząc słowo web, myślnik i wartość count kropka index. Ponieważ index zaczyna się od zera, Terraform przetwarza ten blok i tworzy trzy oddzielne maszyny o nazwach web-zero, web-one i web-two. Dodanie count zmienia sposób, w jaki Terraform wewnętrznie śledzi dany resource. Pojedynczy resource jest adresowany po prostu przez jego typ i nadaną nazwę. Gdy dodasz count, ten adres staje się arrayem. Teraz odwołujesz się do konkretnych instancji w innych miejscach kodu, używając ich numerów index w nawiasach kwadratowych. Count jest bardzo wydajny, ale wiąże się z pewnym mechanicznym ryzykiem, związanym z kolejnością na liście. Oto kluczowa sprawa. Count identyfikuje resources wyłącznie na podstawie ich pozycji jako integer. Jeśli użyjesz listy wartości do skonfigurowania bloku z count, pozycja index to jedyna rzecz, która obchodzi Terraforma. Jeśli masz trzy elementy i zmienisz count na dwa, Terraform zniszczy ostatni element w arrayu, czyli index dwa. Jeśli wstrzykniesz nowy string w środek swojej listy źródłowej, wszystkie kolejne pozycje index przesuną się w dół. Terraform zauważy, że konfiguracja dla index jeden się zmieniła, dla index dwa się zmieniła i tak dalej. Prawdopodobnie zniszczy i odtworzy w pełni sprawną infrastrukturę tylko dlatego, że zmieniła się kolejność na liście źródłowej. Aby wyeliminować ten słaby punkt, używasz zamiast tego meta-argumentu for each. Podczas gdy count przyjmuje liczbę całkowitą, for each przyjmuje mapę lub set stringów. Zamiast tworzyć array obiektów indeksowanych kolejnymi numerami, for each tworzy mapę obiektów śledzonych za pomocą jawnych kluczy typu string. Jeśli przekażesz mu set zawierający stringi frontend i backend, Terraform utworzy resources adresowane dokładnie tymi nazwami. Jeśli później dodasz nowy string lub jakiś usuniesz, Terraform doda lub zniszczy tylko ten konkretny resource. Reszta pozostanie nietknięta, ponieważ ich identyfikatory to stałe klucze typu string, a nie kruche pozycje liczbowe. Używaj count, gdy obiekty infrastruktury są naprawdę wymienne, ale przełącz się na for each w momencie, gdy te obiekty wymagają odrębnych tożsamości, które muszą przetrwać zmiany na twojej liście konfiguracyjnej. Dzięki za wysłuchanie. Do następnego razu!

Cześć, tu Alex z DEV STORIES DOT EU. Podstawy Terraforma, odcinek 11 z 13. Twój pojedynczy plik konfiguracyjny Terraforma był w porządku dla prostego serwera WWW, ale w miarę rozrostu infrastruktury szybko staje się on chaotycznym, nieczytelnym monolitem. Kopiujesz i wklejasz te same resource blocki w kółko, tylko po to, by zmienić pojedynczy string z nazwą lub tag środowiska. Czas przestać się powtarzać i zacząć budować reużywalne komponenty za pomocą modułów. Moduł to kontener na wiele zasobów, które są używane razem. Jeśli znasz jakikolwiek język programowania, możesz myśleć o module jak o funkcji. Piszesz złożoną logikę raz, enkapsulujesz ją, a potem wywołujesz wielokrotnie z innych miejsc. W Terraformie każda konfiguracja ma już co najmniej jeden moduł. Pliki znajdujące się w twoim głównym katalogu roboczym tworzą tak zwany root module. Kiedy twój root module odwołuje się do innego zestawu plików konfiguracyjnych, ten drugi zestaw nazywany jest child module. Rozważmy konkretny scenariusz. Scentralizowany zespół DevOps chce mieć pewność, że każde storage account tworzone w firmie jest domyślnie bezpieczne, z wymuszonym szyfrowaniem, prywatnymi endpointami i logowaniem diagnostycznym. Zamiast ufać, że każdy deweloper aplikacji poprawnie skonfiguruje dziesięć różnych, skomplikowanych zasobów, zespół DevOps tworzy standardowy moduł Secure Azure Storage. Kiedy zespół aplikacji potrzebuje storage'u, nie pisze ogromnego bloku z definicjami zasobów. Po prostu pisze module block w swojej głównej konfiguracji. Wewnątrz tego module blocku, pierwszą rzeczą, którą definiują, jest argument source. Source mówi Terraformowi dokładnie, gdzie znaleźć pliki child module, niezależnie od tego, czy jest to ścieżka do lokalnego katalogu, czy zdalne repozytorium. Poniżej source, zespół aplikacji przekazuje argumenty. Podobnie jak przy przekazywaniu argumentów do funkcji, dostarczają oni konkretne dane, których child module potrzebuje do działania, takie jak unikalna nazwa aplikacji czy identyfikator środowiska. Te argumenty mapują się bezpośrednio na input variables zdefiniowane wewnątrz child module. Child module pobiera te inputy, wykonuje pod spodem konfiguracje zasobów i buduje infrastrukturę. Zespół aplikacji automatycznie otrzymuje zgodny storage, całkowicie odizolowany od ukrytej pod spodem złożoności. A oto kluczowa sprawa. Ludzie często mylą się co do tego, jak Terraform obsługuje scope między tymi modułami. Kiedy wywołujesz child module, zasoby w nim zawarte są ściśle zaenkapsulowane. Twój root module nie może bezpośrednio odczytać adresu IP, connection stringa ani storage ID wygenerowanego wewnątrz tego child module. Child module to czarna skrzynka. Jeśli twój root module potrzebuje danych wygenerowanych wewnątrz child module, child module musi je jawnie wyeksportować za pomocą output blocku. Zmienne działają jak parametry wejściowe, a outputy jak wartości zwracane. Tworzą one ścisły interfejs. Kiedy child module wyeksportuje te dane jako output, root module może je w końcu odczytać. Uzyskujesz dostęp do tych danych, odwołując się do słowa module, po którym następuje konkretna nazwa przypisana do twojego module blocku, a następnie nazwa outputu. Jeśli child module zwraca wygenerowane storage account ID, twój root module może je pobrać za pomocą tej składni i przekazać do bazy danych lub maszyny wirtualnej, która musi się z nim połączyć. Prawdziwa siła modułów to nie tylko oszczędność linii kodu. To możliwość jednorazowego zdefiniowania standardu architektonicznego, ukrycia złożoności i zaprezentowania czystego, przewidywalnego interfejsu reszcie twojej organizacji. Dzięki za wysłuchanie. Trzymajcie się.

Cześć, tu Alex z DEV STORIES DOT EU. Podstawy Terraform, odcinek 12 z 13. Lokalny state file na twoim dysku twardym działa idealnie, gdy budujesz sam. Ale w momencie, gdy dwóch inżynierów próbuje zaktualizować tę samą infrastrukturę w tej samej sekundzie, masz gotową receptę na uszkodzenie środowiska. To granica między indywidualnymi eksperymentami a współpracą w zespole, która prowadzi nas do enterprise readiness: remote state i locking. Domyślnie Terraform zapisuje swój aktualny widok twojej infrastruktury do lokalnego pliku o nazwie terraform dot tfstate. Ten plik to kluczowe source of truth, mapujące twój kod konfiguracyjny na rzeczywiste zasoby. Problem pojawia się, gdy dodajesz do projektu więcej osób. Jeśli twój współpracownik wprowadzi zmianę ze swojej maszyny, twój laptop nie ma pojęcia, że środowisko właśnie się zmieniło. Operujesz na nieaktualnych informacjach. Czasami zespoły próbują to rozwiązać, commitując state file do swojego systemu kontroli wersji. To poważne zagrożenie bezpieczeństwa. State files rutynowo przechowują wrażliwe dane, takie jak hasła do baz danych czy klucze prywatne, w plain text. Prawidłowym podejściem jest skonfigurowanie remote backendu. Zamiast zapisywać state file na lokalnej maszynie, Terraform odczytuje i zapisuje te dane w bezpiecznym, scentralizowanym data store. Zazwyczaj jest to usługa object storage, taka jak bucket Amazon S3, kontener Azure Blob Storage, czy bucket Google Cloud Storage. Kiedy używasz remote backendu, za każdym razem, gdy ktoś odpala komendę, Terraform odpytuje ten centralny storage, aby pobrać najdokładniejszy, najbardziej aktualny obraz infrastruktury. Przejście na taki setup wymaga dodania bloku konfiguracji backendu do twojego kodu, definiującego, gdzie ten state powinien żyć. Zwróć na to szczególną uwagę. Bardzo częstym błędem jest napisanie tej konfiguracji, zapisanie pliku i założenie, że state jest teraz remote. Otóż nie jest. Po dodaniu bloku backendu, musisz ponownie odpalić terraform init. Odpalenie tej komendy inicjalizacyjnej to trigger, który mówi Terraformowi, żeby fizycznie skopiował twój istniejący lokalny state file i zmigrował go do cloud backendu. Przeniesienie state file do współdzielonej lokalizacji rozwiązuje problem z widocznością, ale wystawia cię na concurrent modifications. Jeśli dwa deployment pipelines ztriggerują update jednocześnie, oba mogą próbować zapisać dane do remote state file w tym samym czasie, całkowicie go uszkadzając. Właśnie dlatego remote backendy wspierają state locking. Rozważmy środowisko korzystające z Azure Blob Storage dla swojego remote state. Dwóch inżynierów pracuje nad różnymi update'ami. Inżynier A odpala apply. Przed wprowadzeniem jakichkolwiek zmian w rzeczywistych zasobach chmurowych, Terraform uderza do kontenera Azure storage i zakłada locka na remote state file. Ułamek sekundy później Inżynier B próbuje odpalić swoje własne apply. Terraform sprawdza remote backend, wykrywa aktywnego locka i natychmiast przechwytuje run Inżyniera B. Zamiast doprowadzić do kolizji, Terraform bezpiecznie się zatrzymuje i zwraca błąd, wyjaśniając, że inny proces aktualnie trzyma locka. Kiedy pierwszy run zakończy się sukcesem, Terraform automatycznie zwalnia locka. Wdrożenie remote backendu z lockiem to decydujący krok dla enterprise infrastructure as code. Zabezpiecza twoje wrażliwe dane i eliminuje niebezpieczne race conditions. Remote state gwarantuje, że niezależnie od tego, kto i skąd odpala kod, cały twój zespół jest mocno zakotwiczony w dokładnie tej samej rzeczywistości. Dzięki za wysłuchanie, happy coding wszystkim!

Cześć, tu Alex z DEV STORIES DOT EU. Terraform Fundamentals, odcinek 13 z 13. Napisałeś konfigurację, przetestowałeś ją lokalnie i zdeployowałeś swoje zasoby. Ale odpalanie zmian w infrastrukturze z laptopa developera to wąskie gardło, a nie strategia. Manualne apply prowadzi do konfliktów w state, zmian bez review i ryzyk bezpieczeństwa. Prawdziwa automatyzacja działa bezpiecznie w pipeline'ie, triggerowanym automatycznie przez kontrolę wersji. To prowadzi nas do Enterprise Workflows i CI/CD. Kiedy przechodzisz z pracy solo do zespołu, główny workflow Write, Plan i Apply całkowicie znika z twojej lokalnej maszyny. Kontrola wersji staje się absolutnym source of truth. Przestajesz odpalać komendy bezpośrednio i pozwalasz, żeby pipeline'y CI orkiestrowały zmiany w state. Oto kluczowa sprawa. Pipeline dzieli tradycyjną fazę plan na dwa odrębne koncepty: speculative plans i concrete plans. Zrozumienie tej różnicy jest kluczowe przy projektowaniu pipeline'u. Wyobraź sobie developera, który musi zwiększyć rozmiar maszyny wirtualnej na Azure. Aktualizuje rozmiar instancji w konfiguracji, robi commit kodu i otwiera Pull Request. W tym dokładnie momencie, pipeline automatycznie triggeruje speculative plan. Speculative plan po prostu pokazuje, co Terraform zamierza zrobić. Sprawdza proponowany kod z remote state, żeby obliczyć deltę, ale jest to operacja stricte read-only. Nie można na nim zrobić apply w żadnych okolicznościach. Pipeline bierze output tego speculative plan i wrzuca go bezpośrednio jako tekstowy komentarz do Pull Requesta. Kiedy senior engineer robi code review, nie widzi tylko zmiany w składni. Widzi dokładny wpływ na infrastrukturę. Dokładnie wie, które zasoby na Azure zostaną zmodyfikowane, utworzone lub usunięte, zanim da approve'a. Kiedy Pull Request dostanie approve'a i zostanie zmergowany do main brancha, pipeline triggeruje drugą fazę. Generuje concrete plan dla tego main brancha. To jest wykonywalny plik planu. Ponieważ main branch jest zaufanym source of truth, pipeline bierze ten concrete plan i od razu robi apply. Infrastruktura live jest aktualizowana automatycznie przez robota, a nie przez człowieka. Odpalanie Terraforma w automatyzacji otwiera drzwi do zaawansowanych kontroli typu enterprise. Policy-as-code, używając frameworków takich jak Sentinel, integruje się bezpośrednio z tym pipeline'em. Sentinel ewaluuje plan, zanim w ogóle dojdzie do apply. Jeśli developer przypadkowo zażąda instancji bazy danych, która narusza restrykcje kosztowe albo zasady compliance, policy engine oflaguje to i natychmiast zatrzyma pipeline. Ten zautomatyzowany workflow to coś, co umożliwia model infrastruktury self-service. Platform engineerowie budują i testują reużywalne moduły, podczas gdy developerzy aplikacji po prostu wystawiają Pull Request, prosząc o zasoby, których potrzebują. Pipeline robi plan zmiany, policy-as-code weryfikuje compliance, a ktoś z zespołu robi review intencji. Zespół aplikacyjny szybko dostaje swoją infrastrukturę, a zespół platformowy egzekwuje bezpieczeństwo, nie będąc manualnym blokerem. To kończy naszą serię o podstawach. Wiesz już, jak Terraform skaluje się od pojedynczej lokalnej komendy do zautomatyzowanego silnika enterprise. Najlepszym sposobem na utrwalenie tej wiedzy jest zbudowanie czegoś, czytanie oficjalnej dokumentacji i samodzielne eksperymentowanie z tymi pipeline'ami. Jeśli masz pomysły na przyszłe tematy, wejdź na DEV STORIES DOT EU. Chciałbym poświęcić chwilę, żeby podziękować ci za słuchanie — to bardzo nam pomaga. Miłego dnia!