Przeszedłem z Terraform na CloudFormation - i żałowałem tego

Reprezentowanie infrastruktury jako kodu w powtarzalnym formacie tekstowym to prosta, najlepsza praktyka w przypadku systemów, które nie wymagają majstrowania przy myszach. Ta praktyka ma nazwę - Infrastruktura jako kodi jak dotąd istnieją dwa popularne narzędzia do jego implementacji, zwłaszcza w AWS: Terraform и Tworzenie chmury.

Przeszedłem z Terraform na CloudFormation - i żałowałem tego
Porównanie doświadczeń z Terraform i CloudFormation

Przed przyjściem Twitch (Aka Amazon Jr.) Pracowałem w jednym starcie i korzystałem z Terraform przez trzy lata. W nowym miejscu również z całych sił korzystałem z Terraform, a potem firma wypchnęła przejście na wszystko a la Amazon, łącznie z CloudFormation. Starannie opracowałem najlepsze praktyki w obu przypadkach i korzystałem z obu narzędzi w bardzo złożonych przepływach pracy obejmujących całą organizację. Później, po dokładnym rozważeniu konsekwencji migracji z Terraform do CloudFormation, doszedłem do przekonania, że ​​Terraform był prawdopodobnie najlepszym wyborem dla organizacji.

Terraforma okropna

Oprogramowanie w wersji beta

Terraform nie wypuścił jeszcze wersji 1.0, co jest dobrym powodem, aby z niej nie korzystać. Wiele się zmieniło, odkąd sam tego spróbowałem po raz pierwszy, ale wtedy terraform apply często psuł się po kilku aktualizacjach lub po prostu po kilku latach użytkowania. Powiedziałabym, że „teraz wszystko jest inne”, ale… chyba wszyscy tak mówią, prawda? Istnieją zmiany, które są niezgodne z poprzednimi wersjami, chociaż są odpowiednie, a nawet wydaje się, że składnia i abstrakcje magazynów zasobów są teraz tym, czego potrzebujemy. Wydaje się, że instrument naprawdę się poprawił, ale... :-0

Z drugiej strony AWS wykonał dobrą robotę, utrzymując kompatybilność wsteczną. Dzieje się tak prawdopodobnie dlatego, że ich usługi są często dokładnie testowane w organizacji i dopiero wtedy, ze zmienioną nazwą, są publikowane. Zatem „bardzo się starali” to mało powiedziane. Utrzymanie wstecznej kompatybilności z API dla systemu tak zróżnicowanego i złożonego jak AWS jest niezwykle trudne. Każdy, kto musiał utrzymywać publiczne interfejsy API, które są tak powszechnie używane, powinien zrozumieć, jak trudne jest to przez tyle lat. Ale, jak pamiętam, zachowanie CloudFormation nigdy się nie zmieniło na przestrzeni lat.

Poznaj nogę... to kula

O ile wiem, usuń zasób outsider Stos CloudFormation ze stosu CF nie jest możliwy. Podobnie jest z Terraformem. Umożliwia importowanie istniejących zasobów do stosu. Można powiedzieć, że ta funkcja jest niesamowita, ale z wielką mocą wiąże się wielka odpowiedzialność. Wystarczy dodać zasób do stosu, a podczas pracy ze stosem nie można usunąć ani zmienić tego zasobu. Któregoś dnia przyniosło to odwrotny skutek. Któregoś dnia na Twitchu ktoś przypadkowo zaimportował cudzą grupę zabezpieczeń AWS do własnego stosu Terraform, nie robiąc przy tym żadnych szkód. Wprowadziłem kilka poleceń i... grupa bezpieczeństwa (wraz z ruchem przychodzącym) zniknęła.

Terraforma Świetnie

Odzyskiwanie ze stanów niezupełnych

Czasami CloudFormation nie może całkowicie przejść z jednego stanu do drugiego. Jednocześnie będzie próbował wrócić do poprzedniego. Szkoda, że ​​nie zawsze jest to wykonalne. Debugowanie tego, co wydarzyło się później, może być dość przerażające — nigdy nie wiadomo, czy CloudFormation będzie zadowolone, że zostało zhakowane — nawet po to, aby to naprawić. Czy uda mu się wrócić do poprzedniego stanu, naprawdę nie wie, jak to ustalić i domyślnie wisi godzinami, czekając na cud.

Z drugiej strony Terraform ma tendencję do znacznie łatwiejszego odzyskiwania danych po nieudanych przejściach i oferuje zaawansowane narzędzia do debugowania.

Bardziej przejrzyste zmiany stanu dokumentu

„OK, moduł równoważenia obciążenia, zmieniasz się. Ale jak?"

—zaniepokojony inżynier, gotowy do naciśnięcia przycisku „akceptuj”.

Czasami muszę wykonać pewne manipulacje przy użyciu modułu równoważenia obciążenia w stosie CloudFormation, na przykład dodać numer portu lub zmienić grupę zabezpieczeń. ClouFormation słabo wyświetla zmiany. Z bólem głowy sprawdzam plik yaml dziesięć razy, aby upewnić się, że nie usunąłem niczego niezbędnego i nie dodałem niczego niepotrzebnego.

Terraform jest pod tym względem znacznie bardziej przejrzysty. Czasem jest nawet zbyt przejrzysty (czytaj: irytujący). Na szczęście najnowsza wersja zawiera ulepszone wyświetlanie zmian, dzięki czemu możesz teraz dokładnie zobaczyć, co się zmienia.

Гибкость

Napisz oprogramowanie wstecz.

Mówiąc wprost, najważniejszą cechą oprogramowania trwałego jest zdolność dostosowywania się do zmian. Napisz dowolne oprogramowanie wstecz. Najczęściej popełniałem błędy, biorąc „prostą” usługę, a następnie zaczynając upychać wszystko w jednym stosie CloudFormation lub Terraform. I oczywiście kilka miesięcy później okazało się, że wszystko źle zrozumiałam, a obsługa w rzeczywistości nie była prosta! A teraz muszę jakoś podzielić duży stos na małe komponenty. Kiedy pracujesz z CloudFormation, można to zrobić tylko poprzez najpierw odtworzenie istniejącego stosu, a ja nie robię tego z moimi bazami danych. Z drugiej strony Terraform umożliwił rozbicie stosu i podzielenie go na bardziej zrozumiałe mniejsze części.

Moduły w gicie

Udostępnianie kodu Terraform na wielu stosach jest znacznie łatwiejsze niż udostępnianie kodu CloudFormation. Dzięki Terraform możesz umieścić swój kod w repozytorium git i uzyskać do niego dostęp za pomocą semantycznej kontroli wersji. Każdy, kto ma dostęp do tego repozytorium, może ponownie wykorzystać udostępniony kod. Odpowiednikiem CloudFormation jest S3, ale nie ma on takich samych korzyści i nie ma powodu, dla którego mielibyśmy w ogóle porzucać gita na rzecz S3.

Organizacja rozrosła się, a możliwość współdzielenia wspólnych stosów osiągnęła poziom krytyczny. Terraform sprawia, że ​​wszystko to jest łatwe i naturalne, podczas gdy CloudFormation sprawi, że będziesz skakał przez przeszkody, zanim uda ci się uruchomić coś takiego.

Operacje jako kod

„Napiszmy to i OK.”

—inżynier 3 lata przed wynalezieniem roweru Terraform.

Jeśli chodzi o tworzenie oprogramowania, program Go lub Java to nie tylko kod.

Przeszedłem z Terraform na CloudFormation - i żałowałem tego
Kod jak kod

Istnieje również infrastruktura, na której działa.

Przeszedłem z Terraform na CloudFormation - i żałowałem tego
Infrastruktura jako kod

Ale skąd ona jest? Jak to monitorować? Gdzie znajduje się Twój kod? Czy programiści potrzebują uprawnień dostępu?

Przeszedłem z Terraform na CloudFormation - i żałowałem tego
Operacje jako kod

Bycie programistą nie oznacza tylko pisania kodu.

AWS nie jest jedyny: prawdopodobnie korzystasz z usług innych dostawców. SignalFx, PagerDuty lub Github. Być może masz wewnętrzny serwer Jenkins do CI/CD lub wewnętrzny pulpit nawigacyjny Grafana do monitorowania. Infra as Code wybiera się z różnych powodów, a każdy z nich jest równie ważny dla wszystkiego, co jest związane z oprogramowaniem.

Kiedy pracowałem w Twitchu, przyspieszyliśmy usługi w mieszanych systemach Amazon Embedded i AWS. Wyprodukowaliśmy i wspieraliśmy wiele mikrousług, zwiększając koszty operacyjne. Dyskusje wyglądały mniej więcej tak:

  • Я: Cholera, dużo gestów, jak na podkręcenie jednej mikrousługi. Będę musiał użyć tych śmieci, aby utworzyć konto AWS (przeszliśmy do 2 kont na mikroserwis), potem ten do konfigurowania alertów, ten do repozytorium kodów i ten do listy e-mailowej, a potem ten...
  • Prowadzić: Napiszmy to i OK.
  • Я: OK, ale sam scenariusz ulegnie zmianie. Będziemy potrzebować sposobu, aby sprawdzić, czy wszystkie wbudowane gadżety Amazon są aktualne.
  • Prowadzić: Brzmi dobrze. I napiszemy do tego scenariusz.
  • Я: Świetnie! Skrypt prawdopodobnie nadal będzie musiał ustawić parametry. Czy je zaakceptuje?
  • Prowadzić: Niech bierze, dokąd idzie!
  • Я: Proces może ulec zmianie i kompatybilność wsteczna zostanie utracona. Wymagany będzie pewien rodzaj semantycznej kontroli wersji.
  • Prowadzić: Świetny pomysł!
  • Я: Narzędzia można zmieniać ręcznie w interfejsie użytkownika. Będziemy potrzebować sposobu, aby to sprawdzić i naprawić.

…3 lata później:

  • Prowadzić: I mamy terraformę.

Morał z tej historii jest taki: nawet jeśli po uszy we wszystkim, co Amazon, nadal używasz czegoś innego niż AWS, a te usługi mają stan, który używa języka konfiguracyjnego, aby zapewnić synchronizację tego stanu.

CloudFormation lambda vs moduły git terraform

lambda to rozwiązanie CloudFormation dotyczące problemu z logiką niestandardową. Dzięki lambdzie możesz tworzyć makra lub zasób użytkownika. To podejście wprowadza dodatkowe komplikacje, których nie ma w semantycznym wersjonowaniu modułów git w Terraform. Dla mnie najbardziej palącym problemem było zarządzanie uprawnieniami dla wszystkich tych lambd użytkowników (a są to dziesiątki kont AWS). Kolejnym ważnym problemem był problem „co było pierwsze, kura czy jajko?”: był on powiązany z kodem lambda. Ta funkcja sama w sobie jest infrastrukturą i kodem i sama wymaga monitorowania i aktualizacji. Ostatnim gwoździem do trumny była trudność w semantycznej aktualizacji zmian w kodzie lambda; musieliśmy się także upewnić, że akcje stosu bez bezpośredniego polecenia nie zmieniły się pomiędzy uruchomieniami.

Pamiętam, że kiedyś chciałem stworzyć wdrożenie typu canary dla środowiska Elastic Beanstalk z klasycznym modułem równoważenia obciążenia. Najłatwiej byłoby przeprowadzić drugie wdrożenie dla EB obok środowiska produkcyjnego, idąc o krok dalej: łącząc grupę wdrożeniową Canary z automatycznym skalowaniem z wdrożeniem LB w środowisku produkcyjnym. A ponieważ Terraform używa Podsumowanie ASG beantalk, będzie to wymagało 4 dodatkowych linii kodu w Terraform. Kiedy zapytałem, czy w CloudFormation istnieje porównywalne rozwiązanie, wskazali mi całe repozytorium git z potokiem wdrażania i wszystkim, a wszystko po to, aby zrobić coś, co mogłyby zrobić biedne 4 linie kodu Terraform.

Lepiej wykrywa dryf

Upewnij się, że rzeczywistość odpowiada oczekiwaniom.

Wykrywanie dryfu to bardzo potężna funkcja operacji w kodzie, ponieważ pomaga zapewnić, że rzeczywistość odpowiada oczekiwaniom. Jest dostępny zarówno w CloudFormation, jak i Terraform. Jednak w miarę wzrostu stosu produkcyjnego poszukiwanie dryfu w CloudFormation powodowało coraz więcej fałszywych wykryć.

Dzięki Terraform masz znacznie bardziej zaawansowane haki cyklu życia do wykrywania dryfu. Na przykład wprowadzasz polecenie ignorować_zmiany bezpośrednio w definicji zadania ECS, jeśli chcesz zignorować zmiany w definicji konkretnego zadania bez ignorowania zmian w całym wdrożeniu ECS.

CDK i przyszłość CloudFormation

CloudFormation jest trudne do zarządzania w dużych skalach obejmujących wiele infrastruktur. Wiele z tych trudności zostało rozpoznanych i narzędzie potrzebuje takich rzeczy aws-cdk, framework do definiowania infrastruktury chmurowej w kodzie i uruchamiania jej za pośrednictwem AWS CloudFormation. Ciekawie będzie zobaczyć, jaka przyszłość przyniesie aws-cdk, ale będzie mu trudno konkurować z innymi mocnymi stronami Terraform; aby zaktualizować CloudFormation, wymagane będą globalne zmiany.

Aby Terraform nie zawiódł

To „infrastruktura jako kod”, a nie „jako tekst”.

Moje pierwsze wrażenie o Terraformie było raczej złe. Chyba po prostu nie zrozumiałem podejścia. Prawie wszyscy inżynierowie mimowolnie postrzegają go jako format tekstowy, który należy przekonwertować na pożądaną infrastrukturę. NIE RÓB TEGO W TEN SPOSÓB.

Truizmy dobrego tworzenia oprogramowania dotyczą także Terraform.

Widziałem wiele praktyk przyjętych do tworzenia dobrego kodu, które były ignorowane w Terraform. Uczyłeś się przez lata, aby zostać dobrym programistą. Nie rezygnuj z tego doświadczenia tylko dlatego, że pracujesz z Terraform. Truizmy dobrego tworzenia oprogramowania dotyczą Terraform.

Jak kod może nie zostać udokumentowany?

Widziałem ogromne stosy Terraform bez żadnej dokumentacji. Jak można pisać kod na stronach - bez żadnej dokumentacji? Dodaj dokumentację wyjaśniającą Twój kod Terraform (z naciskiem na słowo „kod”), dlaczego ta sekcja jest tak ważna i czym się zajmujesz.

Jak możemy wdrożyć usługi, które kiedyś były jedną dużą funkcją main()?

Widziałem bardzo złożone stosy Terraform prezentowane jako pojedynczy moduł. Dlaczego nie wdrażamy oprogramowania w ten sposób? Dlaczego dzielimy duże funkcje na mniejsze? Te same odpowiedzi dotyczą Terraformu. Jeśli Twój moduł jest za duży, musisz podzielić go na mniejsze moduły.

Twoja firma nie korzysta z bibliotek?

Widziałem, jak inżynierowie, tworząc nowy projekt za pomocą Terraforma, głupio kopiowali ogromne fragmenty z innych projektów do swoich, a następnie majstrowali przy nich, aż zaczęło działać. Czy pracowałbyś tak z kodem „bojowym” w swojej firmie? Nie tylko korzystamy z bibliotek. Tak, nie wszystko musi być biblioteką, ale gdzie w zasadzie jesteśmy bez bibliotek współdzielonych?!

Nie używasz PEP8 lub gofmt?

Większość języków ma standardowy, akceptowany schemat formatowania. W Pythonie jest to PEP8. W Go - gofmt. Terraform ma swoje własne: terraform fmt. Ciesz się tym dla swojego zdrowia!

Czy będziesz używać Reacta nie znając JavaScriptu?

Moduły Terraform mogą uprościć część złożonej infrastruktury, którą tworzysz, ale to nie znaczy, że w ogóle nie można przy tym majstrować. Chcesz poprawnie korzystać z Terraform bez zrozumienia zasobów? Jesteś skazany: czas upłynie i nigdy nie opanujesz Terraformu.

Czy kodujesz za pomocą singletonów czy zastrzyku zależności?

Wstrzykiwanie zależności jest uznaną najlepszą praktyką w zakresie tworzenia oprogramowania i jest preferowane w stosunku do singletonów. Jak jest to przydatne w Terraform? Widziałem moduły Terraform zależne od stanu zdalnego. Zamiast pisać moduły pobierające stan zdalny, napisz moduł pobierający parametry. A następnie przekaż te parametry do modułu.

Czy wasze biblioteki robią dziesięć rzeczy dobrze, czy jedną świetnie?

Biblioteki, które sprawdzają się najlepiej, to te, które skupiają się na jednym zadaniu, które wykonują bardzo dobrze. Zamiast pisać duże moduły Terraform, które próbują robić wszystko na raz, zbuduj z nich części, które dobrze wykonują jedną rzecz. A następnie połącz je według potrzeb.

Jak wprowadzać zmiany w bibliotekach bez kompatybilności wstecznej?

Typowy moduł Terraform, podobnie jak zwykła biblioteka, musi w jakiś sposób komunikować użytkownikom zmiany, nie zapewniając kompatybilności wstecznej. Jest to denerwujące, gdy te zmiany zachodzą w bibliotekach, i jest równie denerwujące, gdy w modułach Terraform wprowadzane są zmiany, które nie są kompatybilne wstecz. Podczas korzystania z modułów Terraform zaleca się używanie tagów git i semver.

Czy Twoja usługa produkcyjna działa na Twoim laptopie czy w centrum danych?

Hashicorp ma takie narzędzia jak chmura terraformowa aby uruchomić swój terraform. Te scentralizowane usługi ułatwiają zarządzanie, kontrolowanie i zatwierdzanie zmian w terraformie.

Nie piszesz testów?

Inżynierowie zdają sobie sprawę, że kod wymaga przetestowania, ale sami często zapominają o testowaniu podczas pracy z Terraformem. Dla infrastruktury jest to obarczone zdradliwymi momentami. Moja rada to „testowanie” lub „tworzenie przykładowych” stosów przy użyciu modułów, które można poprawnie wdrożyć na potrzeby testów podczas CI/CD.

Terraforma i mikroserwisy

Życie i śmierć firm zajmujących się mikrousługami zależy od szybkości, innowacyjności i zakłóceń nowych stosów mikrousług.

Najczęstszy negatywny aspekt związany z architekturami mikroserwisowymi, którego nie można wyeliminować, dotyczy pracy, a nie kodu. Jeśli myślisz o Terraform tylko jako o sposobie zautomatyzowania jedynie infrastruktury w architekturze mikrousług, tracisz prawdziwe zalety systemu. Teraz to już jest wszystko jest jak kod.

Źródło: www.habr.com

Dodaj komentarz