CloudFormation vs. Terraform. Porównanie narzędzi do IaC

Dobór odpowiednich narzędzi to jedno z najczęstszych wyzwań z jakimi spotykają się DevOpsi w codziennej pracy. W dzisiejszym wpisie skupimy się na porównaniu dwóch najpopularniejszych narzędzi do zarządzania infrastrukturą na AWSie – natywnego CloudFormation i open-source’owego Terraforma. Obydwa umożliwiają zautomatyzowanie procesów związanych z definiowaniem konfiguracji infrastruktury w zgodzie z metodyką Infrastructure as Code. Jak wypadają w porównaniu? Sprawdźmy!

Infrastructure as Code, czyli nowoczesne podejście do zarządzania infrastrukturą

Zacznijmy od wyjaśnienia podstaw, czyli do czego w zasadzie służą CloudFormation i Terraform i dlaczego są (a przynajmniej powinny być) nieodzownymi narzędziami w techstacku każdego DevOpsa mającego do czynienia z bardziej złożonym projektem cloudowym. Mniej techniczne osoby wychodzą czasami z błędnego założenia, że migracja do chmury oznacza całkowite wyeliminowanie kosztów operacyjnych związanych z zarządzaniem infrastrukturą. Tymczasem infrastruktura serwisów danej aplikacji na chmurze również musi zostać skonfigurowana i może to być zadanie równie mozolne, jak ręczna konfiguracja fizycznych serwerów. Aby zautomatyzować powtarzalne zadania DevOpsi wykorzystują metodykę Infrastruktura jako kod (IaC), która pozwala na definiowanie konfiguracji serwisów pod postacią szablonów konfiguracyjnych.

Dylemat dotyczący doboru narzędzi czy metod konfigurowania chmury to problem, z którym spotyka się wielu DevOpsów zainteresowanych Infrastructure as Code. Narzędzi jest sporo, wiedzy dostępnej w Internecie jest jeszcze więcej – jak więc poruszać się w tym natłoku informacji? Rumble Fish wychodzi naprzeciw takim wyzwaniom i oferuje DevOpsom kompleksowy kurs wzbogacający ich wiedzę i umiejętności. Pod czujnym okiem doświadczonych doświadczonych mentorów poznasz wszystkie tajniki orkiestracji chmury i nie tylko. W naszym porównaniu narzędzi ekspertem technologicznym jest Marcin, Tech Lead z Rumble Fish.

Nie tylko automatyzacja, czyli o zaletach IaC

Poza oczywistym benefitem, jakim jest oszczędność czasu związana ze zautomatyzowaniem pewnych procesów, zastosowanie infrastruktury jako kodu ma też szereg innych zalet. Pliki konfiguracje mogą pełnić rolę dokumentacji, a jeżeli napisane są prawidłowo, można je uruchomić wszędzie – w chmurze publicznej, prywatnej czy na własnym serwerze. Również komunikacja w zespole znacznie zyskuje na przejrzystości – wszelkie zmiany w plikach konfiguracyjnych infrastruktury można w łatwy sposób prześledzić przez co szybciej identyfikujemy ewentualne błędy w konfiguracji. IaC daje również możliwość powrotu do dowolnej historycznej wersji kodu w repozytorium, co pozwala na płynne przełączanie się pomiędzy poszczególnymi wersjami.

Konfigurowanie IaC może być niezwykle skomplikowane dlatego dobór odpowiednich narzędzi, dostosowanych do naszych potrzeb i możliwości jest kluczowy. Przyjrzyjmy się bliżej najbardziej popularnym rozwiązaniom wykorzystywanym do zarządzania infrastrukturą w chmurze.

AWS CloudFormation vs. Terraform: co wybrać?

W naszej analizie weźmiemy pod uwagę szereg najważniejszych czynników wpływających na możliwości dwóch konkurencyjnych narzędzi. Spojrzymy również na łatwość pracy, elastyczność czy poziom bezpieczeństwa jaki zapewnia każde z nich. Zaczynajmy!

Dostawca i język

CloudFormation jest narzędziem stworzonym i utrzymywanym przez Amazona, skupia się więc na orkiestracji zasobów chmury AWS. Terraform daje możliwość współpracy z wieloma dostawcami i technologiami, co już na wstępie czyni go bardziej elastycznym niż konkurenta. CloudFormation jest rozwiązaniem własnościowym, nie daje więc możliwości zgłaszania pull requestów, co sprawia, że jesteśmy niejako skazani na Amazona. Dostawca ten oferuje oczywiście odpowiednie wsparcie, pod warunkiem, że mamy wykupiony odpowiedni plan zawierający support. W przypadku Terraform, narzędzia open-source’owego, dostępne jest prężnie działające community, każdy chętny może kontrybuować, zgłaszać błędy i requesty.

W kwestii obsługiwanego języka – CloudFormation daje możliwość tworzenia w YAMLu, co jest sporym ułatwieniem przy ręcznym pisaniu kodu, za pomocą tego języka kod pisze się szybciej. Terraform natomiast obsługuje własny język o nazwie HCL (HashiCorp Configuration Language), który zawiera w sobie wszystkie funkcjonalności JSONa, może się do JSONa przekompilować, a dodatkowo ma kilka wbudowanych abstrakcji, takich jak pętle czy instrukcje warunkowe. Dzięki temu z pomocą HCL możemy tworzyć konfiguracje bardziej ekspresyjnie, intencjonalnie.

Narzędzia

Aby rozpocząć pracę na Terraformie niezbędne jest pobranie binarki TF oraz wtyczek, które umożliwią nam połączenie się z wybraną chmurą, bazą danych czy innym zasobem, którym chcemy zarządzać z poziomu TF. W związku z tym, to na DevOpsie leży odpowiedzialność za wersjonowanie poszczególnych dostawców i zarządzanie nimi. W przypadku CloudFormation ten problem jest rozwiązany automatycznie – ponieważ CF jest wbudowane w AWSa, nie potrzebujemy dodatkowych narzędzi aby rozpocząć konfigurowanie. Przydatne może się okazać AWS CLI (Command Line Interface), ale jest to rozwiązanie opcjonalne.

Parametryzacja

W Terraformie parametryzacja ma podstawowy zakres – mamy możliwość określenia zmiennych i przypisania im jakiejś wartości. TF oferuje nam też możliwość walidacji oraz określenia opcjonalnych parametrów. To samo oferuje nam CloudFormation, a dodatkowo daje również możliwość integracji z usługami AWS. – Przykładowo, mamy możliwość określenia, że dany parametr jest kluczem SSH do instancji, a CF sam zaproponuje nam jeden z dostępnych kluczy, które mamy na koncie. To bardzo przydatne, inteligentne rozwiązanie, które niezwykle ułatwia konfigurację – mówi Marcin, Tech Lead z krakowskiego software house’u Rumble Fish.

Dzielenie się rozwiązaniami

Ten aspekt jest szczególnie ważny dla początkujących DevOpsów czy osób, które dopiero rozpoczynają swoją przygodę z Infrastructure as Code. Łatwość dzielenia się wypracowanymi rozwiązaniami czy prześledzenia logiki kodu to coś, co bardzo docenią wszyscy, którzy uczą się zarządzania IaC. Jak to wygląda w analizowanych przez nas narzędziach? Terraform jest pod tym względem zdecydowanie bardziej “surowy”, a próg wejścia jest wyższy. – W TF pracujemy na modułach, których idea polega na tym, że za pomocą kodu możemy wygenerować całe zestawy spiętych ze sobą komponentów (zarówno zasobów jak i innych modułów TF) – tłumaczy Marcin z Rumble Fish.

Każdy moduł posiada jednocześnie parametry wejściowe, jak i outputy (na przykład VPC id z VPC wygenerowanego w module). Moduły mogą być przechowywane lokalnie (jako osobny katalog w istniejącym repozytorium), jako ścieżka osobnego repozytorium Gita, lub w Terraform Registry, gdzie zazwyczaj trzymane są publiczne moduły. W CloudFormation sprawa wygląda zupełnie inaczej – modularyzacja polega na tworzeniu tak zwanych Nested Stacks, czyli zagnieżdżonych stacków, domyślnie przechowywanych na S3. Takim stackiem możemy się podzielić – jeżeli, przykładowo, publikujemy artykuł, to możemy utworzyć sobie guzik “Launch Stack”, który automatycznie przeniesie nas do odpowiedniego stacku i pozwoli prześledzić jego logikę i strukturę. Taka transparentność to coś, co bardzo doceniają początkujący użytkownicy CloudFormation.

To jednak nie wszystkie opcje jakie daje nam AWS w tym zakresie. Kolejną jest AWS Service Catalog, który pozwala na tworzenie w ramach danej organizacji całej listy produktów. Produktem jest w tym przypadku konkretna formatka CloudFormation, którą możemy skonfigurować tak, aby tworzyła lambdę, API gateway, zdefiniujemy wszystkie wymagane uprawnienia, a następnie za pomocą Service Catalog udostępnimy naszym deweloperom. Tak przygotowaną, sprawdzoną i przetestowaną formatkę można łatwo wyszukać i użyć jej bez zastanawiania się czy zadziała. To rozwiązanie sprawdzające się w dużych projektach czy organizacjach, bo w bezpieczny sposób pozwala na delegowanie uprawnień poszczególnym członkom zespołu.

Rollback

Rollback to możliwość wycofywania wprowadzonych zmian, czyli rzecz niezwykle istotna gdy chcemy być pewni wdrożeń na produkcję. W Terraform rollbacki nie są wspierane, co nie oznacza, że są niemożliwe do wykonania. Metodą na obejście tego ograniczenia jest zastosowanie np. Git Revert, które cofa stan środowiska do poprzedniego commita. Osoba odpowiedzialna za infrastrukturę przywraca kod do poprzedniej wersji (np. za pomocą Gita), a następnie musi go zaaplikować. Minusem tego rozwiązania jest fakt, że jest wykonywane manualnie i z wielu względów może się nie udać. CloudFormation natomiast w przypadku niepowodzenia aktualizacji sam próbuje cofnąć zmiany.

Obsługa wielu kont AWS

Terraform obsługuje wszystkich liczących się dostawców chmury i pozwala na definiowanie wielu kont w różnych konfiguracjach. Niestety, trzeba to robić ręcznie. CloudFormation, mimo ograniczania się do obsługi jedynie AWSa, ma tutaj wiele przewag. W zakresie chmury Amazona pozwala na integrację z AWS Control Tower i AWS Landing Zone, które pomagają w zarządzaniu środowiskiem składającym się z wielu kont AWS. – Narzędzia te sprawdzają konfigurację infrastruktury pod kątem najlepszych praktyk, a wszystkie eventy związane z bezpieczeństwem gromadzą na wybranym koncie security. Dla nowo zakładanych kont automatycznie stosują wybraną templatkę, co bardzo usprawnia zarządzanie projektami, zwłaszcza tymi dużymi. Innym ciekawym rozwiązaniem CF jest StackSets, które pozwala na zaimplementowanie jednej formatki do wielu kont AWS – mówi Marcin, który na co dzień używa zasobów i narzędzi AWSa.

Planowanie zmian

W CloudFormation pracujemy na templatkach i tworzonym na ich bazie stacku, lockowanie jest po stronie AWSa. W Terraform wersjonowanie kodu mamy w Gicie, mamy też dzielony stan, do którego dostęp może mieć wiele osób. Dodatkowo, TF oferuje możliwość targetowania – jeżeli pracujemy na dużym środowisku złożonym z setek zasobów, możemy usprawnić i przyspieszyć pracę targetując tylko jeden z nich. Dzięki temu nie musimy długo czekać na odświeżenie stanu i dostajemy niemal natychmiastowy feedback odnośnie wprowadzanych zmian.

Zarówno CF, jak i TF mają opcję podejrzenia co właściwie będzie zmienione. W CloudFormation usługa ta nazywa się ChangeSets i działa dla wszystkich zasobów z wyjątkiem NestedSets (nie widzimy co się stanie w zagnieżdżonych modułach). W Terraform natomiast, dostajemy plan, który zawiera wszystkie zmiany jakie powstaną w modyfikowanym środowisku. Widzimy absolutnie wszystko, transparentność w Terraform jest zdecydowanie większa.

CloudFormation czy Terraform: wynik pojedynku

Jak to często bywa, tak i w tym przypadku ciężko jest jednoznacznie wskazać na zwycięzcę pojedynku – zarówno CloudFormation, jak i Terraform mają swoje mocne i słabe strony i to, które narzędzie wybierzemy powinno być dostosowane do specyfiki konkretnego projektu. Terraform jest rozwiązaniem bardziej elastycznym, pozwala na kontrolę niemal każdego elementu środowiska. Cena jaką płacimy za tak duży stopień kontrolowania to złożoność narzędzia. TF jest zdecydowanie trudniejsze do opanowania jeżeli jesteśmy początkującymi DevOpsami. Trudność ta oczywiście maleje wraz z nabytym doświadczeniem i osoby pracujące na Terraformie od dłuższego czasu, bardzo chwalą sobie jego bogate możliwości i elastyczność. CloudFormation natomiast bardzo ułatwia dzielenie się rozwiązaniami, nauka jest zdecydowanie łatwiejsza, a możliwość integracji z przeróżnymi zasobami AWSa jest imponująca.

Oczywiście kluczowym czynnikiem przy wybieraniu między CF a TF jest rodzaj zasobów jakich będziemy używać – jeżeli nasza infrastruktura to multicloud od wielu dostawców lepiej jest wybrać Terraform, natomiast jeżeli korzystamy z chmury AWS – CloudFormation daje nam zdecydowanie więcej możliwości.

Źródła:

• aws.amazon.com/cloudformation
• terraform.io
• cncf.io
• youtube.com.

Zdjęcie główne artykułu pochodzi z unsplash.com.