Wydawałoby się, że programiści Terraform oferują dość wygodne najlepsze praktyki pracy z infrastrukturą AWS. Jest tylko niuans. Z biegiem czasu liczba środowisk rośnie, a każde z nich ma swoje własne funkcje. Prawie kopia stosu aplikacji pojawia się w sąsiednim regionie. A kod Terraform trzeba dokładnie skopiować i edytować zgodnie z nowymi wymaganiami lub przekształcić w płatek śniegu.
Mój raport na temat wzorców w Terraformie służących walce z chaosem i ręczną rutyną w dużych i długich projektach.
Video:
Mam 40 lat, pracuję w IT od 20 lat. Pracuję w Ixtens od 12 lat. Angażujemy się w rozwój oparty na e-commerce. Od 5 lat praktykuję praktyki DevOps.
Moja historia będzie dotyczyć mojego doświadczenia w projekcie w firmie, której nazwy nie zdradzę, ukrywającej się za umową o zachowaniu poufności.
Liczby na slajdzie zostały wskazane w celu zrozumienia skali projektu. I wszystko, co powiem dalej, jest związane z Amazonem.
Dołączyłem do tego projektu 4 lata temu. Refaktoryzacja infrastruktury szła pełną parą, ponieważ projekt się rozrósł. A wzorce, które były używane, nie były już odpowiednie. Biorąc pod uwagę cały planowany rozwój projektu, konieczne było wymyślenie czegoś nowego.
Dziękujemy Matveyowi, który wczoraj opowiedział nam, co wydarzyło się w Dodo Pizza. To samo wydarzyło się tutaj 4 lata temu.
Przyszli programiści i zaczęli tworzyć kod infrastruktury.
Najbardziej oczywistym powodem, dla którego było to konieczne, był czas wprowadzenia produktu na rynek. Należało zadbać o to, aby zespół DevOps nie stanowił wąskiego gardła podczas rolloutu. Między innymi Terraform i Puppet zostały wykorzystane na pierwszym poziomie.
Terraform to projekt open source firmy HashiCorp. A dla tych, którzy nawet nie wiedzą co to jest, kilka kolejnych slajdów.
Infrastruktura jako kod oznacza, że możemy opisać naszą infrastrukturę i poprosić jakieś roboty, aby upewniły się, że otrzymamy opisane przez nas zasoby.
Na przykład potrzebujemy maszyny wirtualnej. Opiszemy i dodamy kilka wymaganych parametrów.
Następnie skonfigurujemy dostęp do Amazon w konsoli. I poprosimy o plan Terraform. Plan Terraform powie: „OK, możemy zrobić te rzeczy dla twoich zasobów”. I co najmniej jeden zasób zostanie dodany. I nie należy spodziewać się żadnych zmian.
Gdy wszystko będzie już gotowe, możesz poprosić Terraform o złożenie wniosku, a Terraform utworzy dla Ciebie instancję, a Ty otrzymasz maszynę wirtualną w swojej chmurze.
Dalej nasz projekt się rozwija. Dodajemy tam pewne zmiany. Prosimy o więcej instancji, dodajemy 53 wpisy.
I powtarzamy. Proszę zaplanować. Widzimy, jakie zmiany są planowane. Stosujemy. I tak rozwija się nasza infrastruktura.
Terraform używa czegoś, co nazywa się plikami stanu. Oznacza to, że wszystkie zmiany trafiające do Amazona są zapisywane w pliku, w którym dla każdego zasobu, który opisałeś, odpowiadają zasoby utworzone w Amazon. Dzięki temu, gdy zmienia się opis zasobu, Terraform dokładnie wie, co należy zmienić w Amazon.
Te pliki stanu były pierwotnie tylko plikami. I przechowywaliśmy je w Git, co było wyjątkowo niewygodne. Zawsze ktoś zapominał o dokonaniu zmian i pojawiało się wiele konfliktów.
Teraz można skorzystać z backendu, czyli Terraform określa w jakim zasobniku i jakim kluczem ma być zapisany plik stanu. A Terraform sam zajmie się uzyskaniem tego pliku stanu, wykonując całą magię i przywracając końcowy wynik.
Nasza infrastruktura się rozwija. Oto nasz kod. A teraz nie chcemy tylko tworzyć maszyny wirtualnej, chcemy mieć środowisko testowe.
Terraform pozwala na stworzenie czegoś takiego jak moduł, czyli opisanie tego samego w jakimś folderze.
I na przykład podczas testowania wywołaj ten moduł i uzyskaj to samo, jak gdybyśmy uruchomili Terraform Apply w samym module. Do testów będzie ten kod.
Na produkcję możemy wysłać tam pewne zmiany, ponieważ w testowaniu nie potrzebujemy dużych instancji, na produkcji duże instancje są po prostu przydatne.
A potem wrócę do projektu. Było to trudne zadanie, planowana infrastruktura była bardzo duża. I trzeba było jakoś ułożyć cały kod tak, żeby był wygodny dla wszystkich: zarówno dla tych, którzy zajmują się konserwacją tego kodu, jak i dla tych, którzy wprowadzają zmiany. Zaplanowano, że każdy programista będzie mógł naprawić infrastrukturę zgodnie z potrzebami swojej części platformy.
Jest to drzewo katalogów zalecane przez samą HashiCorp, jeśli masz duży projekt i warto podzielić całą infrastrukturę na kilka małych części i opisać każdy element w osobnym folderze.
Mając obszerną bibliotekę zasobów, możesz wywołać mniej więcej to samo w testowaniu i na produkcji.
W naszym przypadku nie było to do końca odpowiednie, ponieważ stos testowy dla programistów lub do testów trzeba było uzyskać w jakiś prostszy sposób. Nie chciałem jednak przeglądać folderów i stosować ich w wymaganej kolejności, martwiąc się, że baza danych wzrośnie, a następnie wzrośnie instancja korzystająca z tej bazy danych. Dlatego też wszystkie testy zostały uruchomione z jednego folderu. Tam wywoływano te same moduły, ale wszystko odbyło się za jednym razem.
Terraform dba o wszystkie zależności. I zawsze tworzy zasoby po kolei, żeby można było pobrać adres IP np. z nowo utworzonej instancji i uzyskać ten adres IP w rekordzie Route53.
Poza tym platforma jest bardzo duża. A uruchomienie stosu testowego, nawet jeśli na godzinę, nawet jeśli na 8 godzin, jest przedsięwzięciem dość kosztownym.
I zautomatyzowaliśmy tę kwestię. A zadanie Jenkinsa pozwoliło nam uruchomić stos. W nim konieczne było uruchomienie żądania ściągnięcia ze zmianami, które programista chce przetestować, określenie wszystkich niezbędnych opcji, komponentów i wymiarów. Jeśli chce testów wydajnościowych, może wziąć więcej instancji. Jeśli musi tylko sprawdzić, czy otwiera się jakiś formularz, może zacząć od płacy minimalnej. A także wskaż, czy klaster jest potrzebny, czy nie itp.
Następnie Jenkins uruchomił skrypt powłoki, który nieznacznie zmodyfikował kod w folderze Terraform. Usunąłem niepotrzebne pliki i dodałem niezbędne pliki. A potem, po jednym uruchomieniu Terraforma, stos się podniósł.
A potem były jeszcze inne kroki, w które nie chcę wchodzić.
Z uwagi na to, że do testów potrzebowaliśmy trochę więcej opcji niż na produkcji, musieliśmy wykonać kopie modułów, aby w tych kopiach móc dodać te funkcje, które były potrzebne tylko do testów.
I tak się złożyło, że podczas testów chcę w pewnym sensie przetestować te zmiany, które ostatecznie trafią do produkcji. Ale tak naprawdę testowano jedno, a w produkcji zastosowano nieco inną. I nastąpiła mała przerwa w schemacie, że na produkcji wszystkie zmiany wprowadzał zespół operacyjny. I czasami okazywało się, że te zmiany, które miały przejść z testów do produkcji, pozostały w innej wersji.
Dodatkowo pojawił się taki problem, że dodano nową usługę, która nieco różniła się od tej już istniejącej. Zamiast modyfikować istniejący moduł, musieliśmy wykonać jego kopię i dodać niezbędne zmiany.
Zasadniczo Terraform nie jest prawdziwym językiem. To jest deklaracja. Jeżeli musimy coś zadeklarować, to to deklarujemy. I to wszystko działa.
W pewnym momencie, gdy omawiano jeden z moich pull requestów, jeden z moich kolegów powiedział, że nie ma potrzeby tworzenia płatków śniegu. Zastanawiałem się, co miał na myśli. Istnieje naukowy fakt, że na świecie nie ma dwóch identycznych płatków śniegu, każdy jest nieco inny. Gdy tylko to usłyszałem, od razu poczułem cały ciężar kodu Terraform. Ponieważ gdy trzeba było przejść z wersji na wersję, Terraform wymagał zerwania łańcucha zmian, czyli kod nie był już kompatybilny z kolejną wersją. Musieliśmy także wysłać żądanie ściągnięcia, które objęło prawie połowę plików w infrastrukturze, aby przenieść infrastrukturę do następnej wersji Terraform.
A kiedy pojawił się taki płatek śniegu, cały kod Terraformu, który zamieniliśmy w wielką, wielką kupę śniegu.
Dla zewnętrznego programisty, który jest poza operacją, nie ma to dla niego większego znaczenia, ponieważ wykonał żądanie ściągnięcia, jego zasób został uruchomiony. I tyle, to już nie jego zmartwienie. A zespół DevOps, który pilnuje, żeby wszystko było w porządku, musi dokonać tych wszystkich zmian. A koszt tych zmian bardzo, bardzo rósł z każdym dodatkowym płatkiem śniegu.
Jest taka historia o tym, jak student na seminarium rysuje kredą dwa idealne koła na tablicy. A nauczyciel jest zaskoczony, jak udało mu się tak płynnie rysować bez kompasu. Uczeń odpowiada: „Bardzo proste, dwa lata służyłem w wojsku, obracając maszynę do mięsa”.
Z czterech lat, kiedy jestem zaangażowany w ten projekt, zajmuję się Terraformem od około dwóch. I oczywiście mam kilka trików, kilka rad, jak uprościć kod Terraform, pracować z nim jak z językiem programowania i odciążyć programistów, którzy muszą aktualizować ten kod.
Pierwszą rzeczą, od której chciałbym zacząć, są Symlinks. Terraform ma dużo powtarzalnego kodu. Przykładowo wywołanie dostawcy w niemal każdym miejscu, w którym tworzymy fragment infrastruktury jest takie samo. Logiczne jest umieszczenie go w osobnym folderze. I wszędzie tam, gdzie dostawca jest zobowiązany do utworzenia dowiązań symbolicznych do tego pliku.
Na przykład w produkcji wykorzystujesz rolę „przejmij rolę”, która pozwala uzyskać prawa dostępu do jakiegoś zewnętrznego konta Amazon. Po zmianie jednego pliku wszystkie pozostałe w drzewie zasobów będą miały wymagane uprawnienia, dzięki czemu Terraform będzie wiedział, do którego segmentu Amazon ma uzyskać dostęp.
Gdzie zawodzą dowiązania symboliczne? Jak powiedziałem, Terraform ma pliki stanowe. I są bardzo, bardzo fajne. Rzecz w tym, że Terraform w pierwszej kolejności inicjuje backend. I nie może używać żadnych zmiennych w tych parametrach, zawsze muszą być zapisane tekstem.
W rezultacie, gdy ktoś tworzy nowy zasób, kopiuje część kodu z innych folderów. I może się pomylić z kluczem lub wiadrem. Na przykład tworzy piaskownicę z piaskownicy, a następnie wprowadza ją do produkcji. I tak może się okazać, że produkowane wiadro będzie wykorzystywane z piaskownicy. Oczywiście, szybko go znajdą. Można to jakoś naprawić, ale mimo to jest to strata czasu i, w pewnym stopniu, zasobów.
Co możemy zrobić dalej? Przed rozpoczęciem pracy z Terraformem należy go zainicjować. Podczas inicjalizacji Terraform pobiera wszystkie wtyczki. W pewnym momencie odeszli od monolitu do architektury bardziej mikrousługowej. I zawsze musisz wykonać inicjację Terraform, aby pobrała wszystkie moduły i wszystkie wtyczki.
Możesz także użyć skryptu powłoki, który po pierwsze może pobrać wszystkie zmienne. Skrypt powłoki nie jest w żaden sposób ograniczony. Po drugie, ścieżki. Jeśli zawsze będziemy używać ścieżki znajdującej się w repozytorium jako klucza do pliku stanu, wówczas odpowiednio błąd tutaj zostanie wyeliminowany.
Gdzie mogę uzyskać dane? plik JSON. Terraform pozwala na pisanie infrastruktury nie tylko w hcl (HashiCorp Configuration Language), ale także w JSON.
JSON można łatwo odczytać ze skryptu powłoki. W związku z tym możesz umieścić plik konfiguracyjny z wiadrem w jakimś miejscu. I użyj tego segmentu zarówno w kodzie Terraform, jak i w skrypcie powłoki do inicjalizacji.
Dlaczego posiadanie wiadra do Terraform jest ważne? Ponieważ istnieje coś takiego jak pliki stanu zdalnego. Oznacza to, że kiedy pozyskuję jakiś zasób, aby powiedzieć Amazonowi: „Proszę podnieść instancję”, muszę określić wiele wymaganych parametrów.
I te identyfikatory są przechowywane w innym folderze. Mogę iść i powiedzieć: „Terraform, proszę, przejdź do pliku stanu tego zasobu i podaj mi te identyfikatory”. I tak następuje pewna unifikacja pomiędzy różnymi regionami czy środowiskami.
Nie zawsze jest możliwe użycie pliku stanu zdalnego. Na przykład ręcznie utworzyłeś VPC. A kod Terraform, który tworzy VPC, tworzy tak różne VPC, że zajmie to bardzo dużo czasu i będziesz musiał dostosować jedno do drugiego, więc możesz zastosować następującą sztuczkę.
Oznacza to, że utwórz moduł, który wydaje się tworzyć VPC i niejako podaje identyfikatory, ale w rzeczywistości istnieje po prostu plik z zakodowanymi na stałe wartościami, których można użyć do utworzenia tej samej instancji.
Nie zawsze konieczne jest zapisanie pliku stanu w chmurze. Na przykład podczas testowania modułów można zastosować inicjalizację backendu, gdzie plik zostanie po prostu zapisany na dysku w momencie testowania.
Teraz trochę o testowaniu. Co możesz przetestować w Terraformie? Pewnie wiele jest możliwych, ale ja opowiem o tych 4 rzeczach.
HashiCorp rozumie, jak powinien być formatowany kod Terraform. Terraform fmt umożliwia formatowanie edytowanego kodu zgodnie z tym przekonaniem. W związku z tym testy muszą koniecznie sprawdzić, czy formatowanie odpowiada temu, co przekazał HashiCorp, aby nie było potrzeby zmiany położenia nawiasów itp.
Następnym krokiem jest sprawdzenie Terraform. Robi niewiele więcej niż sprawdzenie składni - niestety, czy wszystkie nawiasy są sparowane. Co jest tu ważne? Nasza infrastruktura jest bardzo rozbudowana. Jest w nim wielu różnych tatusiów. W każdym z nich musisz uruchomić Terraform sprawdzania poprawności.
W związku z tym, aby przyspieszyć testowanie, uruchamiamy wiele procesów równolegle, korzystając z opcji równoległych.
Równoległość to bardzo fajna rzecz, wykorzystaj ją.
Ale za każdym razem, gdy Terraform się inicjuje, trafia do HashiCorp i pyta: „Jakie są najnowsze wersje wtyczek? A wtyczka, którą mam w pamięci podręcznej – czy jest właściwa, czy zła?” A to zwalniało na każdym kroku.
Jeśli powiesz Terraformowi, gdzie znajdują się wtyczki, Terraform powie: „OK, to prawdopodobnie najnowsza rzecz, jaką tam mamy. Nigdzie nie pójdę, natychmiast rozpocznę sprawdzanie poprawności Twojego kodu Terraform.
Aby wypełnić folder niezbędnymi wtyczkami, mamy bardzo prosty kod Terraform, który wystarczy zainicjować. Tutaj oczywiście musisz określić wszystkich dostawców, którzy w jakiś sposób uczestniczą w Twoim kodzie, w przeciwnym razie Terraform powie: „Nie znam konkretnego dostawcy, ponieważ nie ma go w pamięci podręcznej”.
Następny jest plan Terraform. Jak mówiłem, rozwój ma charakter cykliczny. Wprowadzamy zmiany w kodzie. A potem trzeba dowiedzieć się, jakie zmiany planowane są w infrastrukturze.
A kiedy infrastruktura jest bardzo, bardzo duża, można zmienić jeden moduł, naprawić jakieś środowisko testowe lub jakiś konkretny region i zepsuć jakiś sąsiedni. Dlatego też należy wykonać plan Terraform dla całej infrastruktury i pokazać jakie zmiany są planowane.
Można to zrobić mądrze. Na przykład napisaliśmy skrypt w języku Python, który rozwiązuje zależności. I w zależności od tego, co zostało zmienione: moduł Terraform lub tylko konkretny komponent, tworzy plany dla wszystkich zależnych folderów.
Na żądanie należy sporządzić plany terenu. Przynajmniej to właśnie robimy.
Oczywiście dobrze jest zrobić testy dla każdej zmiany, dla każdego zatwierdzenia, ale plany to dość kosztowna rzecz. W żądaniu ściągnięcia mówimy: „Proszę, daj mi plany”. Robot uruchamia się. I wysyła komentarze lub dołącza wszystkie plany, których oczekujesz od twoich zmian.
Plan to dość kosztowna rzecz. Zajmuje to trochę czasu, ponieważ Terraform udaje się do Amazona i pyta: „Czy ta instancja nadal istnieje? Czy to automatyczne skalowanie ma dokładnie te same parametry?” Aby to przyspieszyć, możesz użyć parametru takiego jak odświeżanie=false. Oznacza to, że Terraform pobierze stan z S3. I uwierzy, że stan będzie dokładnie odpowiadał temu, co jest w Amazonie.
Taki plan Terraforma idzie znacznie szybciej, ale stan musi odpowiadać Twojej infrastrukturze, czyli gdzieś, kiedyś musi się rozpocząć odświeżanie Terraforma. Odświeżanie Terraform robi dokładnie to: stan odpowiada temu, co znajduje się w rzeczywistej infrastrukturze.
I musimy porozmawiać o bezpieczeństwie. Od tego musieliśmy zacząć. Tam, gdzie uruchamiasz Terraform, a Terraform działa na Twojej infrastrukturze, istnieje luka w zabezpieczeniach. Oznacza to, że zasadniczo wykonujesz kod. A jeśli żądanie ściągnięcia zawiera jakiś złośliwy kod, można je wykonać w infrastrukturze, która ma zbyt duży dostęp. Uważaj więc, gdzie uruchamiasz plan Terraform.
Następną rzeczą, o której chciałbym porozmawiać, jest testowanie danych użytkownika.
Co to są dane użytkownika? W Amazonie, tworząc instancję, możemy wysłać z instancją określony list – metadane. Po uruchomieniu instancji zwykle init chmury jest zawsze obecny w tych instancjach. Cloud init czyta ten list i mówi: „OK, dzisiaj jestem modułem równoważenia obciążenia”. I zgodnie z tymi przymierzami wykonuje pewne działania.
Ale niestety, kiedy tworzymy plan Terraform i stosujemy Terraform, dane użytkownika wyglądają jak papka liczbowa. Oznacza to, że po prostu wysyła ci skrót. W planie możesz jedynie sprawdzić, czy będą jakieś zmiany lub czy skrót pozostanie taki sam.
A jeśli nie zwrócisz na to uwagi, jakiś uszkodzony plik tekstowy może trafić na Amazon, na prawdziwą infrastrukturę.
Alternatywnie podczas wykonywania możesz określić nie całą infrastrukturę, a jedynie szablon. A w kodzie powiedz: „Proszę wyświetlić ten szablon na moim ekranie”. Dzięki temu możesz otrzymać wydruk tego, jak będą wyglądać Twoje dane na Amazonie.
Inną opcją jest użycie modułu do generowania danych użytkownika. Zastosujesz ten moduł. Otrzymasz plik na dysku. Porównaj go z referencyjnym. I tak, jeśli ktoś zdecyduje się nieco poprawić dane użytkownika, testy powiedzą: „OK, tu i tam są pewne zmiany – to normalne”.
Następną rzeczą, o której chciałbym porozmawiać, jest zastosowanie automatyzacji Terraform.
Oczywiście, stosowanie Terraformu w trybie automatycznym jest dość przerażające, bo kto wie, jakie zmiany tam zaszły i jak destrukcyjne mogą być dla żywej infrastruktury.
W środowisku testowym jest to normalne. Oznacza to, że praca tworząca środowisko testowe jest tym, czego potrzebują wszyscy programiści. A wyrażenie takie jak „wszystko zadziałało” nie jest śmiesznym memem, ale dowodem na to, że ktoś się zdezorientował, podniósł stos i przeprowadził pewne testy na tym stosie. Upewnił się, że wszystko jest w porządku i powiedział: „OK, kod, który udostępniam, został przetestowany”.
W środowiskach produkcyjnych, piaskownicowych i innych, które są bardziej krytyczne dla biznesu, można częściowo bezpiecznie korzystać z niektórych zasobów, ponieważ nie powoduje to śmierci nikogo. Są to: grupy automatycznego skalowania, grupy zabezpieczeń, role, Route53, a lista tam może być dość duża. Ale miej oko na to, co się dzieje, czytaj automatyczne raporty z aplikacji.
Tam, gdzie zastosowanie jest niebezpieczne lub przerażające, na przykład jeśli są to trwałe zasoby z bazy danych, otrzymasz raporty o niezastosowanych zmianach w jakimś fragmencie infrastruktury. A inżynier pod nadzorem rozpoczyna zadania do zastosowania lub robi to ze swojej konsoli.
Amazon ma coś takiego jak ochrona przed terminacją. I może chronić w niektórych przypadkach przed zmianami, które nie są dla Ciebie wymagane. Oznacza to, że Terraform poszedł do Amazona i powiedział: „Muszę zabić tę instancję, aby stworzyć kolejną”. A Amazon mówi: „Przepraszam, nie dzisiaj. Mamy ochronę przed terminacją.”
Wisienką na torcie jest optymalizacja kodu. Pracując z kodem Terraform musimy przekazać do modułu bardzo dużą liczbę parametrów. Są to parametry niezbędne do stworzenia pewnego rodzaju zasobu. Kod zamienia się w dużą listę parametrów, które należy przekazywać z modułu do modułu, z modułu do modułu, szczególnie jeśli moduły są zagnieżdżone.
I bardzo trudno się to czyta. Bardzo trudno to zrecenzować. I bardzo często okazuje się, że niektóre parametry są poddawane przeglądowi i nie są dokładnie takie, jakie są potrzebne. A to wymaga czasu i pieniędzy, aby później to naprawić.
Dlatego sugeruję użycie czegoś takiego jak parametr złożony, który zawiera określone drzewo wartości. Oznacza to, że potrzebujesz jakiegoś folderu, w którym znajdziesz wszystkie wartości, które chciałbyś mieć w jakimś środowisku.
A wywołując ten moduł można otrzymać drzewo, które jest generowane w jednym wspólnym module, czyli we wspólnym module, który działa tak samo dla całej infrastruktury.
W tym module możesz wykonać pewne obliczenia, korzystając z najnowszej funkcji Terraform, jaką są obliczenia lokalne. A następnie, mając jedno wyjście, podaj złożony parametr, który może zawierać skróty tablicowe itp.
Tutaj skończyły się wszystkie najlepsze znaleziska. Chciałbym opowiedzieć historię o Kolumbie. Kiedy szukał pieniędzy na swoją wyprawę do Indii (tak jak wtedy myślał), nikt mu nie wierzył i uważali, że to niemożliwe. Następnie powiedział: „Uważajcie, żeby jajko nie spadło”. Wszyscy bankierzy, bardzo bogaci i prawdopodobnie mądrzy ludzie, próbowali jakoś umieścić jajko, a ono spadało. Następnie Kolumb wziął jajko i lekko je ucisnął. Skorupa zgniotła się, a jajo pozostało nieruchome. Powiedzieli: „Och, to zbyt proste!” A Kolumb odpowiedział: „Tak, to zbyt proste. A kiedy otworzę Indie, wszyscy będą korzystać z tego szlaku handlowego”.
A to, co właśnie powiedziałem, to prawdopodobnie dość proste i trywialne rzeczy. A kiedy się o nich dowiesz i zaczniesz z nich korzystać, wszystko jest w porządku. Więc skorzystaj. A jeśli są to dla Ciebie zupełnie normalne rzeczy, to przynajmniej wiesz, jak ułożyć jajko, aby nie spadło.
Podsumujmy:
- Staraj się unikać płatków śniegu. Im mniej płatków śniegu, tym mniej zasobów będziesz potrzebować do wprowadzenia jakichkolwiek zmian w całej dużej infrastrukturze.
- Ciągłe zmiany. Oznacza to, że gdy w kodzie pojawią się zmiany, należy jak najszybciej dostosować infrastrukturę do tych zmian. Nie powinno być sytuacji, w której ktoś przychodzi zajrzeć do Elasticsearch dwa, trzy miesiące później, robi plan Terraform i jest mnóstwo zmian, których się nie spodziewał. A przywrócenie wszystkiego do porządku zajmuje dużo czasu.
- Testy i automatyzacja. Im bardziej Twój kod jest pokryty testami i funkcjami, tym większą masz pewność, że robisz wszystko poprawnie. A automatyczna dostawa wielokrotnie zwiększy Twoją pewność siebie.
- Kod środowiska testowego i produkcyjnego powinien być prawie taki sam. Praktycznie, bo produkcja nadal wygląda trochę inaczej i nadal będą pewne niuanse, które wyjdą poza środowisko testowe. Niemniej jednak, plus lub minus, można to zapewnić.
- A jeśli masz dużo kodu Terraform i aktualizacja tego kodu zajmuje dużo czasu, nigdy nie jest za późno na refaktoryzację i doprowadzenie go do dobrego stanu.
- Niezmienna infrastruktura. Dostawa AMI zgodnie z harmonogramem.
- Struktura dla Route53, gdy masz dużo wpisów i chcesz, żeby były w spójnej kolejności.
- Walka z limitami stawek API. W tym momencie Amazon mówi: „To wszystko, nie mogę przyjąć więcej próśb, proszę czekać”. A połowa urzędu czeka, aż będzie mogła uruchomić swoją infrastrukturę.
- Wykryj przypadki. Amazon nie jest tanią imprezą, a spoty pozwalają zaoszczędzić całkiem sporo. I tam możesz opowiedzieć o tym całą relację.
- Role zabezpieczeń i uprawnień.
- Szukając utraconych zasobów, gdy w Amazone znajdziesz egzemplarze niewiadomego pochodzenia, zjadają pieniądze. Nawet jeśli instancje kosztują 100–150 dolarów miesięcznie, to ponad 1 dolarów rocznie. Znalezienie takich zasobów to dochodowy biznes.
- I instancje zarezerwowane.
To wszystko dla mnie. Terraform jest bardzo fajny, używasz go. Dziękuję!
pytania
Dziękujemy za raport! Twój plik stanu znajduje się w S3, ale jak rozwiązać problem polegający na tym, że kilka osób może pobrać ten plik stanu i próbować go rozszerzyć?
Po pierwsze, nie spieszymy się. Po drugie, są flagi, w których informujemy, że pracujemy nad jakimś fragmentem kodu. Czyli pomimo tego, że infrastruktura jest bardzo duża, nie oznacza to, że ktoś ciągle z czegoś korzysta. A kiedy była faza aktywna, był to problem; przechowywaliśmy pliki stanu w Git. Było to ważne, w przeciwnym razie ktoś utworzyłby plik stanu i musieliśmy ręcznie złożyć je w całość, aby wszystko mogło działać dalej. Teraz nie ma takiego problemu. Ogólnie rzecz biorąc, Terraform rozwiązał ten problem. A jeśli coś ciągle się zmienia, możesz użyć blokad, które uniemożliwiają to, co powiedziałeś.
Czy korzystasz z oprogramowania typu open source czy Enterprise?
Żadnego przedsiębiorstwa, czyli wszystko, co możesz pobrać i pobrać za darmo.
Nazywam się Stanisław. Chciałem zrobić mały dodatek. Mówiłeś o funkcji Amazon, która pozwala uczynić instancję niemożliwą do zabicia. Dzieje się tak również w samym Terraformie; w bloku Drugie Życie możesz określić zakaz zmian lub zakaz niszczenia.
Czas był ograniczony. Słuszna uwaga.
Chciałem też zapytać o dwie rzeczy. Po pierwsze, mówiłeś o testowaniu. Czy korzystałeś z jakichś narzędzi testujących? Słyszałem o wtyczce Test Kitchen. Być może jest coś więcej. Chciałbym także zapytać o wartości lokalne. Czym zasadniczo różnią się od zmiennych wejściowych? I dlaczego nie mogę sparametryzować czegoś tylko poprzez wartości lokalne? Próbowałem rozgryźć ten temat, ale jakoś sam nie mogłem tego rozgryźć.
Możemy porozmawiać bardziej szczegółowo poza tym pokojem. Nasze narzędzia testowe są całkowicie samodzielnie wykonane. Nie ma tam nic do testowania. Ogólnie rzecz biorąc, istnieją opcje, gdy automatyczne testy wychwytują gdzieś infrastrukturę, sprawdzają, czy jest OK, a następnie niszczą wszystko, wysyłając raport, że Twoja infrastruktura jest nadal w dobrym stanie. Nie mamy tego, ponieważ stosy testowe są uruchamiane codziennie. I to wystarczy. A jeśli coś zacznie się psuć, zacznie się psuć bez sprawdzania tego gdzie indziej.
Jeśli chodzi o wartości lokalne, kontynuujmy rozmowę poza salą.
Cześć! Dziękujemy za raport! Bardzo informujące. Powiedziałeś, że masz dużo tego samego typu kodu do opisu infrastruktury. Czy rozważałeś wygenerowanie tego kodu?
Świetne pytanie, dzięki! Chodzi o to, że kiedy używamy infrastruktury jako kodu, zakładamy, że patrzymy na kod i rozumiemy, jaka infrastruktura kryje się za tym kodem. Jeśli zostanie wygenerowany kod, musimy wyobrazić sobie, jaki kod zostanie wygenerowany, aby zrozumieć, jaki rodzaj infrastruktury będzie tam dostępny. Albo generujemy kod, zatwierdzamy go i zasadniczo dzieje się to samo. Poszliśmy więc ścieżką, którą napisaliśmy, i mamy to. Generatory Plus pojawiły się nieco później, kiedy zaczęliśmy je produkować. A na zmiany było już za późno.
Czy słyszałeś coś o jsonnet?
Nie.
Słuchaj, to bardzo fajna rzecz. Widzę konkretny przypadek, w którym można go zastosować i wygenerować strukturę danych.
Generatory są dobre, jeśli je masz, jak w dowcipie o maszynce do golenia. Oznacza to, że za pierwszym razem twarz jest inna, ale potem wszyscy mają tę samą twarz. Generatory działają bardzo dobrze. Ale niestety nasze twarze są nieco inne. To jest problem.
Spójrz. Dziękuję!
Nazywam się Maxim, jestem z Sbierbanku. Mówiłeś trochę o tym, jak próbowałeś doprowadzić Terraform do odpowiednika języka programowania. Czy nie łatwiej jest użyć Ansible?
To są bardzo różne rzeczy. Możesz tworzyć zasoby w Ansible, a Puppet może tworzyć zasoby w Amazon. Ale Terraform jest po prostu zaostrzony.
Czy masz tylko Amazon?
To nie tak, że mamy tylko Amazon. Mamy prawie tylko Amazon. Ale kluczową cechą jest to, że Terraform pamięta. Jeśli w Ansible powiesz: „Daj mi 5 instancji”, wówczas podniesie się, a następnie powiesz: „A teraz potrzebuję 3”. A Terraform powie: „OK, zabiję 2”, a Ansible powie: „OK, oto 3 dla ciebie”. Razem 8.
Cześć! Dziękujemy za raport! Bardzo interesująco było usłyszeć o Terraformie. Chciałbym od razu poczynić mały komentarz na temat faktu, że Terraform nadal nie ma stabilnej wersji, dlatego traktuj Terraform z dużą ostrożnością.
Dobra łyżka na obiad. Oznacza to, że jeśli potrzebujesz rozwiązania, czasami odkładasz to, co jest niestabilne itp., Ale działa i nam pomogło.
Pytanie jest takie. Używasz zdalnego backendu, używasz S 3. Dlaczego nie korzystasz z oficjalnego backendu?
Urzędnik?
Chmura Terraformowa.
Kiedy się pojawił?
4 miesiące temu.
Gdyby pojawił się 4 lata temu, prawdopodobnie odpowiedziałbym na Twoje pytanie.
Istnieje już wbudowana funkcja i blokady oraz można przechowywać plik stanu. Spróbuj. Ale też tego nie testowałem.
Jedziemy dużym pociągiem, który porusza się z dużą prędkością. Nie można po prostu wziąć kilku samochodów i wyrzucić ich.
Mówiłeś o płatkach śniegu, dlaczego nie użyłeś gałęzi? Dlaczego to nie zadziałało w ten sposób?
Nasze podejście polega na tym, że cała infrastruktura znajduje się w jednym repozytorium. Terraform, Puppet, wszystkie skrypty, które są w jakiś sposób z tym powiązane, wszystkie znajdują się w jednym repozytorium. W ten sposób możemy mieć pewność, że zmiany przyrostowe będą testowane jedna po drugiej. Gdyby było to kilka oddziałów, utrzymanie takiego projektu byłoby prawie niemożliwe. Minęło sześć miesięcy, a oni różnią się tak bardzo, że jest to po prostu jakaś kara. Właśnie od tego chciałem uciec przed refaktoryzacją.
Więc to nie działa?
To w ogóle nie działa.
W gałęzi wyciąłem slajd folderu. Oznacza to, że jeśli zrobisz to dla każdego stosu testowego, na przykład zespół A ma swój własny folder, zespół B ma swój własny folder, to również nie zadziała. Stworzyliśmy ujednolicony kod środowiska testowego, który był na tyle elastyczny, że pasował każdemu. Oznacza to, że podaliśmy jeden kod.
Cześć! Mam na imię Yura! Dziękujemy za raport! Pytanie o moduły. Mówisz, że używasz modułów. Jak rozwiązać problem, jeśli w jednym module wprowadzono zmiany, które nie są kompatybilne ze zmianami dokonanymi przez inną osobę? Czy w jakiś sposób wersjonujesz moduły lub próbujesz stworzyć wunderwaffle, aby spełniał dwa wymagania?
Jest to duży problem z zalegającym śniegiem. Właśnie na to cierpimy, gdy jakaś nieszkodliwa zmiana może uszkodzić jakąś część infrastruktury. A to będzie zauważalne dopiero po pewnym czasie.
To znaczy, że sprawa nie została jeszcze rozwiązana?
Tworzysz moduły uniwersalne. Unikaj płatków śniegu. I wszystko się ułoży. Druga część raportu dotyczy tego, jak tego uniknąć.
Cześć! Dziękujemy za raport! Chciałbym wyjaśnić. Za kulisami był duży stos, po który przyszedłem. W jaki sposób zintegrowane są marionetki i podział ról?
Dane użytkownika.
Oznacza to, że po prostu wypluwasz plik i jakoś go uruchamiasz?
Dane użytkownika to notatka, czyli kiedy robimy klon obrazu, Daemon podnosi się tam i próbując dowiedzieć się kim jest, czyta notatkę, że jest modułem równoważenia obciążenia.
To znaczy, czy jest to jakiś odrębny proces, który jest rozdawany?
Nie my to wymyśliliśmy. Używamy tego.
Cześć! Mam tylko pytanie dotyczące danych użytkownika. Mówiłeś, że są problemy, że ktoś może wysłać coś w niewłaściwe miejsce. Czy istnieje sposób na przechowywanie danych użytkownika w tym samym Gicie, aby zawsze było jasne, do czego odnoszą się dane użytkownika?
Generujemy dane użytkownika z szablonu. Oznacza to, że używana jest tam pewna liczba zmiennych. A Terraform generuje wynik końcowy. Dlatego nie można po prostu spojrzeć na szablon i powiedzieć, co się stanie, ponieważ wszystkie problemy wiążą się z tym, że programista myśli, że przekazuje w tej zmiennej ciąg znaków, a używana jest tam tablica. A on – bam i ja – taki a taki, taki a taki, następna linijka i wszystko się zepsuło. Jeśli jest to nowy zasób, a osoba go podnosi i widzi, że coś nie działa, wówczas problem jest szybko rozwiązywany. A jeśli ta grupa automatycznego skalowania zostanie zaktualizowana, w pewnym momencie instancje w grupie automatycznego skalowania zaczną być zastępowane. No i bum, coś nie gra. To boli.
Okazuje się, że jedynym rozwiązaniem jest przetestowanie?
Tak, widzisz problem, dodajesz tam kroki testowe. Oznacza to, że można również testować dane wyjściowe. Może nie jest to zbyt wygodne, ale możesz też umieścić jakieś oznaczenia - sprawdź, czy w tym miejscu są przybite dane użytkownika.
Nazywam się Timur. Bardzo fajnie, że pojawiają się raporty jak prawidłowo zorganizować Terraform.
Nawet nie zacząłem.
Myślę, że może na następnej konferencji będzie. Mam proste pytanie. Dlaczego kodujesz wartość w osobnym module, zamiast używać tfvars, tj. dlaczego moduł z wartościami jest lepszy niż tfvars?
Czyli mam tu napisać (slajd: Produkcja/środowisko/ustawienia.tf): domena = zmienna, domena vpcnetwork, zmienna vpcnetwork i stvars – czy mogę dostać to samo?
Właśnie to robimy. Mamy na myśli na przykład moduł źródła ustawień.
Zasadniczo jest to taki tfvars. Tfvars jest bardzo wygodny w środowisku testowym. Mam tfvars dla dużych instancji i dla małych. I wrzuciłem jeden plik do folderu. I dostałem to, czego chciałem. Redukując infrastrukturę, chcemy, aby można było na wszystko spojrzeć i od razu zrozumieć. I tak okazuje się, że trzeba zajrzeć tutaj, a potem zajrzeć do tfvars.
Czy da się mieć wszystko w jednym miejscu?
Tak, tfvars ma miejsce, gdy masz jeden kod. Jest używany w kilku różnych miejscach z różnymi niuansami. Wtedy rzuciłbyś tfvars i dostałbyś swoje niuanse. Jesteśmy infrastrukturą jako kod w najczystszej formie. Spojrzałem i zrozumiałem.
Cześć! Czy spotkałeś się z sytuacjami, w których dostawca chmury ingeruje w to, co stworzyłeś Terraform? Załóżmy, że edytujemy metadane. Istnieją klucze ssh. Google stale umieszcza tam swoje metadane i klucze. A Terraform zawsze pisze, że ma zmiany. Po każdym uruchomieniu, nawet jeśli nic się nie zmienia, zawsze mówi, że teraz zaktualizuje to pole.
Z kluczami, ale tak, część infrastruktury jest tym dotknięta, tj. Terraform nie może niczego zmienić. Rękami też niczego nie zmienimy. Na razie będziemy z tym żyć.
To znaczy spotkałeś się z czymś takim, ale nic nie wymyśliłeś, jak on to robi i robi to sam?
Niestety tak.
Cześć! Nazywam się Starkov Stanislav. Poczta. grupa ru. Jak rozwiązać problem generowania tagu na..., jak przekazać go do środka? Jak rozumiem, poprzez User - dane do określenia nazwy hosta, ustawić Puppet? I druga część pytania. Jak rozwiązać ten problem w SG, tzn. gdy generujesz SG setki instancji tego samego typu, jaka jest dla nich poprawna nazwa?
Te przypadki, które są dla nas bardzo ważne, pięknie je nazywamy. Te, które nie są potrzebne, znajduje się uwaga, że jest to grupa autoskalowania. Teoretycznie można go przybić i kupić nowy.
Jeśli chodzi o problem z tagiem to nie ma takiego problemu, ale jest takie zadanie. I używamy tagów bardzo, bardzo intensywnie, ponieważ infrastruktura jest duża i kosztowna. Musimy także sprawdzić, dokąd idą pieniądze, więc tagi pozwalają nam rozbić, co dokąd poszło. I w związku z tym szuka się czegoś, co oznacza, że wydaje się tu dużo pieniędzy.
O co jeszcze chodziło w pytaniu?
Czy kiedy SG tworzy setki instancji, należy je w jakiś sposób rozróżnić?
Nie, nie. W każdej instancji jest agent, który zgłasza, że mam problem. Jeśli agent zgłosi się, oznacza to, że agent o nim wie i co najmniej istnieje jego adres IP. Możesz już uciec. Po drugie, używamy Consul for Discovery, gdzie Kubernetes nie jest. Consul pokazuje także adres IP instancji.
To znaczy, czy skupiasz się konkretnie na adresie IP, a nie na nazwie hosta?
Nawigacja po nazwie hosta nie jest możliwa, tzn. jest ich dużo. Są identyfikatory instancji - AE itp. Można to gdzieś znaleźć, można wrzucić w wyszukiwarkę.
Cześć! Zdałem sobie sprawę, że Terraform to dobra rzecz, dostosowana do chmur.
Nie tylko.
Właśnie to pytanie mnie interesuje. Jeśli zdecydujesz się na masowe przejście, powiedzmy, do Bare Metal ze wszystkimi swoimi instancjami? Czy będą jakieś problemy? A może nadal będziesz musiał używać innych produktów, na przykład tego samego Ansible, o którym tu wspomniano?
Ansible dotyczy czegoś innego. Oznacza to, że Ansible działa już po uruchomieniu instancji. A Terraform działa przed uruchomieniem instancji. Przejście na Bare Metal - nie.
Nie teraz, ale biznes przyjdzie i powie: „No dalej”.
Przejście na inną chmurę – tak, ale tutaj jest nieco inny trik. Musisz napisać kod Terraform w taki sposób, aby przy mniejszym wysiłku móc przejść na inną chmurę.
Początkowo postawiono sobie zadanie, że cała nasza infrastruktura będzie agnostyczna, czyli każda chmura powinna być odpowiednia, jednak w pewnym momencie biznes się poddał i powiedział: „Ok, przez najbliższe N lat nigdzie nie będziemy jechać, możemy korzystać z usług z Amazona”
Terraform pozwala na tworzenie zadań Front-End, konfigurowanie PagerDuty, dokumentów danych itp. Ma wiele ogonów. Potrafi praktycznie kontrolować cały świat.
Dziękujemy za raport! Ja również korzystam z Terraform od 4 lat. Na etapie płynnego przejścia do Terraformu, do infrastruktury, do opisu deklaratywnego, stanęliśmy przed sytuacją, gdy ktoś coś robił ręcznie, a Ty próbowałeś ułożyć plan. I tam mam jakiś błąd. Jak sobie radzicie z takimi problemami? Jak znaleźć utracone zasoby, które zostały wymienione?
Głównie rękami i oczami, jeśli widzimy w raporcie coś dziwnego, to analizujemy, co się tam dzieje, lub po prostu zabijamy. Ogólnie rzecz biorąc, żądania ściągnięcia są powszechną rzeczą.
Jeśli wystąpi błąd, czy wycofujesz? Czy próbowałeś to zrobić?
Nie, to jest decyzja danej osoby w momencie, gdy widzi problem.
Źródło: www.habr.com