Głównym celem zespołów DevOps jest zapewnienie efektywności i bezpieczeństwa na każdym etapie tworzenia oprogramowania. W naszej serii artykułów przedstawiliśmy kilka narzędzi DevOps dedykowanych kontenerom i orkiestracji kontenerów. Teraz skupimy się na narzędziach IaC i ich roli w cyklu życia tworzenia oprogramowania.
Czym jest IaC?
IaC oznacza Infrastructure as Code - sposób zarządzania infrastrukturą poprzez opisywanie jej w kodzie i wykorzystanie kontroli źródła, podobnie jak zespół DevOps i produktowy zarządzają swoim kodem. Mówiąc prosto, Infrastructure as Code (IaC) to zarządzanie i udostępnianie infrastruktury za pomocą kodu zamiast ręcznych procesów. Dzięki IaC tworzone są pliki konfiguracyjne, które zawierają specyfikacje infrastruktury, ułatwiające edycję i dystrybucję konfiguracji. Zapewnia to też, że za każdym razem uruchamiane jest to samo środowisko. Poprzez kodowanie i dokumentowanie specyfikacji konfiguracji, IaC wspiera zarządzanie konfiguracją i pomaga uniknąć nieudokumentowanych, doraźnych zmian konfiguracji.
Infrastructure as Code i automatyzacja są ze sobą ściśle powiązane, ale to dwie różne rzeczy. IaC przechowuje konfigurację lub stan infrastruktury centrum danych w określony sposób. Automatyzacja to proces automatycznego zastosowania tego stanu w infrastrukturze.
Wartość IaC opiera się na 3 filarach: koszt, szybkość i redukcja ryzyka. Redukcja kosztów odnosi się nie tylko do finansów, ale także do czasu poświęcanego na rutynowe operacje. Zasady IaC pozwalają nie skupiać się na rutynie, lecz na ważniejszych zadaniach. Automatyzacja infrastruktury lepiej wykorzystuje istniejące zasoby. Automatyzacja minimalizuje również ryzyko błędu ludzkiego. Wszystko to jest częścią kultury DevOps.
Istnieją dwa podejścia do IaC - Deklaratywne vs Imperatywne
- Deklaratywne: To podejście przechowuje listę aktualnego stanu obiektów, co ułatwia zarządzanie infrastrukturą.
- Imperatywne: Zamiast tego podejścia, definiuje się konkretne polecenia potrzebne do osiągnięcia pożądanej konfiguracji, które muszą być wykonane we właściwej kolejności.
Wiele narzędzi IaC używa podejścia deklaratywnego i automatycznie tworzy pożądaną infrastrukturę. Jeśli wprowadzisz zmiany w pożądanym stanie, deklaratywne narzędzie IaC je zastosuje. Narzędzie imperatywne wymaga od Ciebie określenia, jak te zmiany powinny zostać wdrożone.
Narzędzia IaC często mogą działać w obu podejściach, ale mają preferencję dla jednego z nich. Przed dalszą analizą warto wyjaśnić pojęcie stanu, ponieważ jest ono rdzeniem i jednym z najważniejszych konceptów IaC.
Koncepcja stanu w IaC
Stan to po prostu szczegóły / zapis wszystkich konfiguracji dokonanych w Twojej infrastrukturze. Za każdym razem, gdy Ty lub członek zespołu dokonujecie zmian w infrastrukturze za pomocą IaC, jest to rejestrowane w pliku stanu. Każde narzędzie IaC ma własny sposób zarządzania stanem/plikiem stanu, ale najważniejsze jest to, że przechowują listę obiektów systemu oraz ich aktualną reprezentację w rzeczywistym świecie. Idealnie plik stanu powinien pokazywać aktualną konfigurację naszej infrastruktury, dlatego ważne jest, aby był on aktualny i zsynchronizowany z infrastrukturą. Praca ze stanem i plikami stanu to jedna z najważniejszych umiejętności do opanowania przy wyborze IaC.
Korzyści z IaC
Używanie IaC do provisioning’u infrastruktury niesie ze sobą wiele korzyści, w tym:
-
Większa produktywność dzięki automatyzacji: Administratorzy i operatorzy nie muszą już wykonywać ręcznych kroków konfiguracyjnych przy zmianach w infrastrukturze centrum danych. Dzięki automatyzacji zespoły oszczędzają dużo czasu i wysiłku, umożliwiając szybkie provisionowanie i skalowanie infrastruktury.
-
Niezawodność: Zespoły, które nie korzystają z Infrastructure as Code, muszą ręcznie utrzymywać ustawienia różnych środowisk wdrożeniowych. Jednak gdy zasoby zaczynają rosnąć, każde środowisko ma unikalną konfigurację, której nie da się łatwo odtworzyć automatycznie, co bardzo utrudnia manualne zarządzanie. W efekcie pojawiają się różnice między środowiskami, prowadząc do problemów z wdrożeniami. Ten problem jest bezpośrednio powiązany z wprowadzeniem IaC.
-
Lepsza ponowna używalność: Starsze infrastruktury nie pozwalały na ponowne używanie zakodowanych elementów w różnych środowiskach. Dlatego zespoły musiały tworzyć je od nowa za każdym razem. Infrastructure as Code eliminuje ten problem, pozwalając na wielokrotne wykorzystanie tych samych zasobów.
-
Optymalizacja kosztów: Oczywiste jest, że ręczne tworzenie każdego środowiska IT jest kosztowne. Potrzebne są nie tylko zespoły inżynierów odpowiedzialnych za konfigurację sprzętu i oprogramowania, ale także nadzorcy i własne centra danych, co dramatycznie podnosi koszty. Korzystając z Infrastructure as Code, masz scentralizowane narzędzie do konfiguracji środowiska i płacisz tylko za zasoby.
Wady IaC
-
Niezgodność konfiguracji: Często określana jako „dryf konfiguracji” - występuje, gdy istnieją różnice między konfiguracją infrastruktury jako kodu a rzeczywistą infrastrukturą, np. przez ręczne lub zewnętrzne aktualizacje zabezpieczeń. Może to prowadzić do niezgodności lub nawet awarii usług z czasem. Powoduje niespodziewane zachowania i trudności w debugowaniu. Rozwiązaniem jest używanie narzędzi IaC, które pomagają wykrywać i zapobiegać dryfowi konfiguracji.
-
Zarządzanie RBAC: Ponieważ infrastruktura jako kod jest często przechowywana w centralnym repozytorium (np. GitHub), brak właściwego zarządzania RBAC (Role-Based Access Control) może prowadzić do problemów z bezpieczeństwem.
-
Złożoność, logika, konwencje i brak umiejętności: Jednym z wyzwań IaC jest złożoność definiowania konfiguracji infrastruktury, co utrudnia firmom zrozumienie i utrzymanie kodu infrastruktury. Dodatkowo, definiowanie IaC wymaga przestrzegania surowych standardów, co podnosi poziom skomplikowania. Ponadto trudno jest znaleźć wykwalifikowany personel. Firmy bez doświadczenia z IaC mogą nie wiedzieć, od czego zacząć ani jak prowadzić rozmowy kwalifikacyjne. Rozwiązaniem jest inwestowanie w szkolenia IaC i ciągłe programy edukacyjne dla zespołu.
-
Gdy wykonanie gdzieś zawiedzie, nie zawsze łatwo jest wznowić je od tego samego punktu, a ponowne uruchomienie od początku może zająć dużo czasu.
-
Luki w narzędziach i opóźnienia funkcji: Często narzędzia IaC nie mają wszystkich potrzebnych funkcji. Nowe funkcje i możliwości mogą pojawiać się z opóźnieniem. W takim wypadku trzeba czekać na wsparcie dostawcy albo samemu rozszerzać funkcjonalność bądź wprowadzać nowe zależności. Rozwiązaniem jest inwestowanie w narzędzia IaC, które są stale aktualizowane i rozwijane.
Przegląd najczęściej używanych narzędzi IaC
-
Terraform: Produkt HashiCorp, Terraform to open-source’owe narzędzie Infrastructure as Code używane w praktykach DevOps do definiowania zasobów chmurowych i lokalnych, ich wersjonowania, ponownego użycia i współdzielenia. Przebieg pracy Terraform składa się z trzech etapów:
- Write - definiowanie zasobów, które mogą być z różnych chmur lub usług
- Plan - tworzenie planu provisionowania infrastruktury wraz z opisem, co się zmieni
- Apply - po akceptacji developera Terraform wdraża operacje we właściwej kolejności z uwzględnieniem zależności zasobów.
Terraform tworzy i zarządza zasobami za pomocą API, co oznacza, że może współpracować z wieloma platformami i usługami korzystającymi z API.
- Terragrunt: Stworzony w 2016 roku przez Gruntwork, Terragrunt to „cienka powłoka” - dodatkowe narzędzie IaC uzupełniające Terraform. Służy do zarządzania stanem zdalnym, pracy z wieloma modułami i redukcji powtórzeń. Wszystko po to, by kod Terraform był zgodny z zasadą DRY (Don’t Repeat Yourself).
- Pulumi: Podobnie jak Terraform, Pulumi to open-source’owe narzędzie IaC do tworzenia, wdrażania i zarządzania infrastrukturą. Używa popularnych języków programowania, aby uprościć provisioning infrastruktury chmurowej i zarządzanie zasobami. Pulumi, zaprezentowane w 2017 roku, było swoistą rewolucją w praktykach DevOps i podejściu do narzędzi IaC. Zamiast języków specyficznych dla domeny pozwala zespołowi korzystać z prawdziwych języków programowania przy provisioningu infrastruktury cloud-native. Oznacza to, że użytkownik nie musi uczyć się nowego języka tylko do zarządzania infrastrukturą.
- CloudFormation: CloudFormation to narzędzie Infrastructure as Code od AWS do tworzenia, provisionowania i zarządzania kolekcjami zasobów chmury Amazon i innych zasobów w pliku tekstowym. Podobnie jak Pulumi, jego celem jest uproszczenie tych procesów. Grupuje zasoby AWS w stosy infrastruktury, dzięki czemu użytkownicy mogą usuwać lub modyfikować zależności zbiorczo. Po usunięciu aplikacji CloudFormation usuwa też stos. Zarządzając stanem stosu, można modyfikować provisionowane zasoby bez całkowitego przebudowywania.
- CDK: CDK to kolejne narzędzie zespołu AWS, które jest open-source. CDK to framework deweloperski, który pozwala definiować zasoby aplikacji chmurowych z użyciem znanych języków programowania. AWS CDK korzysta z mocy i wyrazistości języków programowania do modelowania aplikacji. Dostarcza wysokopoziomowe komponenty zwane konstruktami, które prekonfigurują zasoby chmurowe sprawdzonymi ustawieniami, umożliwiając łatwe budowanie aplikacji chmurowych.
Wybór narzędzia IaC dla twojego projektu
Przy ogromnym wyborze narzędzi nie ma jednej uniwersalnej odpowiedzi. Jednak rozważając opcje, oceń te proste fakty, a znajdziesz odpowiedzi.
- Czy Twoje rozwiązanie jest proste i szczególnie bezserwerowe — AWS CloudFormation może pomóc (szczególnie AWS SAM).
- Czy AWS jest Twoim ostatecznym wyborem i planujesz pozostać na AWS — CloudFormation / CDK.
- Czy chcesz pionowo rozpowszechniać najlepsze praktyki i orkiestrację — Terraform / CDK.
- Czy chcesz orkiestrację zasobów poza AWS — Terraform / CDK for Terraform.
- Czy planujesz środowisko multi-cloud — Terraform.
W każdym przypadku wybór odpowiedniego narzędzia IaC jest wymagającym procesem, który wymaga przemyślenia. Jednak bez względu na wybór, jedynym naprawdę złym rozwiązaniem jest nieużywanie narzędzi, które maksymalnie usprawniają procesy tworzenia i dostarczania oprogramowania.
