Czy IaC to przepis na spokojny sen szefa infrastruktury IT?

Sposób dostarczania i zarządzania infrastrukturą w organizacjach czeka przyspieszona transformacja, której celem jest skok efektywności. Kluczową role odegrają tu tak ważne elementy kultury IT w firmie jak DevOps, continuous delivery oraz infrastruktura zarządzana poprzez kod.

Wyzwania, przed jakimi stoją współcześnie architekci i administratorzy infrastruktury IT w środowiskach chmurowych i hybrydowych, są determinowane przez wciąż te same oczekiwania biznesowe: więcej, szybciej, taniej. Przełożyć te oczekiwania w pewnym uproszczeniu można na: więcej funkcjonalności aplikacji, częściej dostarczanych i weryfikowanych (z rynkiem, klientami), przy zachowaniu kosztów pod kontrolą.

Do głównych trendów na 2021 rok, które mają mieć kluczowy wpływ na obszar infrastruktury i operacji (I&O), Gartner zalicza: optymalizację infrastruktury, zachowanie ciągłości operacyjnej i zarządzanie rozproszonymi operacjami.

Zdaniem ekspertów firmy badawczej, praca zdalna i przejście do chmury będą nadal główną siłą napędową w infrastrukturze w ciągu najbliższych 12 do 18 miesięcy. Do końca 2023 r. ponad 90% departamentów I&O w organizacjach będzie obsługiwało pracę zdalną większości swoich pracowników. Jest to rezultat zmieniającego się charakteru infrastruktury, spowodowanego przejściem do chmury, a COVID-19 tylko przyspieszył ten trend.

– Trendy takie jak rozproszone operacje (anywhere operations) czy modernizacja podstawowej infrastruktury (core modernization) od lat wysuwają się na czoło priorytetów I&O w organizacjach, ale pandemia przyspieszyła je do tego stopnia, że w niedalekiej przyszłości będą miały wpływ transformacyjny – mówi Jeffrey Hewitt, wiceprezes ds. badań, Gartner.

Ewolucja zarządzania infrastrukturą

Przez lata zarządzanie jednym bądź kilkoma serwerami było pracą na pełny etat. Administratorzy starannie opiekowali się swoimi krytycznymi systemami i zapewniali sprawne funkcjonowanie firmy poprzez ich utrzymanie, aktualizację i zabezpieczenie.

Dziś, wraz z migracją całości lub części środowisk do modelu chmurowego, infrastruktura to panel zarządzania środowiskiem wirtualnym. A często nawet nie panel sterowania, lecz automatycznie wykonujący się kod skryptu.

– Ostatnie 10 lat zrewolucjonizowało sposób, w jaki przedsiębiorstwa zarządzają swoją krytyczną infrastrukturą. Serwery nie są już czymś, co trzyma się w ciemnym, zimnym pomieszczeniu w piwnicy. – wyjaśnia Maciej Kuźniar, COO w Oktawave. – Obecnie dostawcy usług w chmurze zarządzają krytyczną infrastrukturą biznesową dla setek, a nawet tysięcy klientów, utrzymując rozległe sieci centrów danych. Rozwój kolokacji, a przede wszystkim chmury publicznej i prywatnej, zmienił sposób, w jaki inżynierowie zarządzają infrastrukturą. Minęły już czasy, gdy administrator systemu był odpowiedzialny za jeden czy kilka serwerów. Dziś, wspierając osiąganie krytycznych celów biznesowych, inżynierowie operacji IT zarządzają kilkudziesięcioma serwerami, a w największych organizacjach często kilkuset.

Ta zmiana skali zmienia również sposób, w jaki specjaliści I&O zapewniają prawidłową konfigurację swoich systemów. Jeśli spotkaliście się już z w praktyce z metodykami zarządzania środowiskami IT takimi jak DevOps czy SRE (Site Reliability Engineering), to infrastruktura zarządzana poprzez kod jest podstawą ich funkcjonowania, i jest wykorzystywana przez wszystkich członków zespołów.

Infrastructure as Code (IaC) czyli infrastruktura jako kod to podejście do zarządzanie infrastrukturą (sieciami, maszynami wirtualnymi, systemami równoważenia obciążenia czy topologią połączeń w chmurze wirtualnej) z wykorzystaniem modelu opisowego, przy użyciu tych samych narzędzi do kontroli wersji, których zespół DevOps używa do zarządzania kodem źródłowym aplikacji.

Analogicznie do zasady, że ten sam kod źródłowy generuje ten sam kod binarny, model opisany w szablonie IaC generuje to samo środowisko za każdym razem, gdy jest uruchamiany. Dzięki temu, że pozwala administratorom systemów zautomatyzować proces tworzenia, uruchamiania i konfiguracji maszyny wirtualnej za pomocą kodu, zapewnia szybką i powtarzalną procedurę replikowania całego procesu.

Oznacza to, że np. po zbudowaniu środowiska wirtualnego z wykorzystaniem skryptu pozwalającego uruchomić i przetestować aplikację, nad którą pracujemy, można powtórzyć proces tworzenia wymaganego środowiska na etapie wdrożenia, uruchamiając ten sam kod. W porównaniu z np. skryptami powłoki (również istotnym narzędziem automatyzacji procesów IT), IaC oferuje większą elastyczność dla bardziej złożonych procesów powoływania infrastruktury.

W kierunku automatyzacji

W wielu pozycjach literatury profesjonalnej podejście IaC jest często zawężane do aspektu automatyzacji, ponieważ jego praktyki obejmują inteligentne wykorzystanie skryptów i szablonów, pozwalających na automatyzację procesów manualnych. Jednak infrastruktura jako kod jest koncepcją, która zdecydowanie wykracza poza ramy prostej automatyzacji dostarczania infrastruktury i jest integralną częścią praktyk DevOps.

Dzięki konfiguracji infrastruktury jako kodu, może ona przejść przez tę samą kontrolę wersji, zautomatyzowane testy oraz inne kroki procesu ciągłej integracji i ciągłego dostarczania (CI/CD), wykorzystywanego przez developerów do kontroli kodu aplikacji.

–  Liderzy IT często decydują o połączeniu podejścia IaC z konteneryzacją aplikacji, dzięki czemu aplikacja zostaje odseparowana od infrastruktury na poziomie systemu operacyjnego. – zauważa COO Oktawave. – Obie technologie okazują się komplementarne dla płynnego zarządzania różnymi fazami wdrożeniowymi od developmentu do produkcji. Zdaniem praktyków, zarządzanie infrastrukturą poprzez kod oferuje wiele korzyści, nie tylko w porównaniu z manualnym tworzeniem i konfiguracją. – dodaje Maciej Kuźniar.

Wybrane korzyści zarządzania infrastrukturą poprzez kod:

• Samoobsługa – ponieważ infrastruktura jest zdefiniowana jako kod, cały proces wdrażania jest zautomatyzowany przez co może być uruchamiany przez każdego członka zespołu DevOps samodzielnie. Użytkownicy otrzymują w rezultacie zasoby, których potrzebują i kiedy ich potrzebują.
• Idempotencja (z ang. idempotency, tłumaczone również jako idempotentność) – jedna z kluczowych cech podejścia IaC. Oznacza definiowanie pożądanego wyniku końcowego / stanu docelowego infrastruktury. Wykonanie skryptu powoduje sprawdzenie stanu aktualnego, porównanie z docelowym i wykonanie operacji, które są niezbędne do osiągnięcia zdefiniowanej konfiguracji infrastruktury. Niezależnie od tego, ile razy uruchomimy skrypt powołujący infrastrukturę, rezultat będzie zawsze ten sam. W przypadku skomplikowanych konfiguracji, osiągnięcie analogicznego efektu (np. za pomocą skryptów powłoki) może być bardzo trudne, natomiast narzędzia takie jak Ansible czy Terraform mają wbudowaną taką funkcjonalność.
• Obniżone koszty – skrócenie czasu i nakładu pracy specjalistów wymaganych do zapewnienia zdefiniowanej infrastruktury w porównaniu z procesem manualnym.

Infrastruktura zmienną jest

IaC może stwarzać też wyzwania, którym zespół DevOps musi stawić czoła. Przede wszystkim wymaga stosowania narzędzi do zarządzania konfiguracją oraz zarządzania orkiestracją, co stwarza potencjalnie przestrzeń na błędy i powinno zostać wsparte odpowiednimi kompetencjami zespołu. –

– Nawet najmniejsze błędy mogą się szybko rozprzestrzeniać szczególnie tam, gdzie istnieje rozległa automatyzacja infrastruktury. Z tego powodu niezbędna jest ścisła kontrola wersji i przeprowadzanie kompleksowych testów przed wydaniem – podkreśla Maciej Kuźniar.

Jeśli z kolei zdarzy się, że administratorzy zmienią konfigurację serwera poza ustalonym szablonem IaC, istnieje zagrożenie tzw. dryfu konfiguracji (configuration drift) poza zakres kontrolowany za pomocą narzędzi do zarządzania konfiguracjami. Ważne jest, aby w pełni zintegrować podejście IaC z administracją systemów, operacjami IT i praktykami DevOps za pomocą dobrze udokumentowanych polityk i procedur.

Tworzenie infrastruktury

Narzędzia do zarządzania konfiguracją są przeznaczone do administracji, zarządzania użytkownikami, instalowania, aktualizacji i zarządzania oprogramowaniem czy narzędziami na istniejących serwerach. Do najczęściej używanych narzędzi konfiguracyjnych należą Chef, Puppet, Ansible i SaltStack.

Z kolei narzędzia takie jak Terraform, AWS CloudFormation, Azure Resource Manager (ARM) czy Google Cloud Deployment Manager służą do orkiestracji infrastruktury, tzn. powoływania instancji serwerów, tworzenia baz danych, systemów równoważenia obciążenia, podsieci, firewalli i wszystkich innych elementów infrastruktury. Narzędzia te komunikują się poprzez API dostawców.

Typową praktyką jest wykorzystanie dwóch narzędzi dedykowanych do każdego z zadań. Na przykład, można wykorzystać Terraform do powołania infrastruktury VPC, podsieci, maszyn wirtualnych itp., a następnie użyć Ansible do konfiguracji i wdrożenia usług na utworzonych instancjach.

Zarządzanie zmianą infrastruktury

Infrastrukturą można zarządzać dopuszczając zmiany jej konfiguracji po udostępnieniu bądź zakładając jej niezmienność. W pierwszym przypadku wykorzystuje się narzędzia automatyzacji jak Chef, Ansible, Puppet czy SaltStack, przeznaczone do instalacji i aktualizacji oprogramowania na istniejących instancjach serwerów czy innych elementów infrastruktury.

Konieczność ingerencji w ich konfigurację może mieć miejsce wielokrotnie w ciągu całego cyklu użytkowania serwera prowadząc do różnic pomiędzy serwerami powoływanymi w poszczególnych fazach projektu i powodując wspomniany już wcześniej dryf konfiguracji. Nie zawsze prowadzi to do poważnych problemów, zwłaszcza jeśli zarządzanie zmianą jest pod kontrolą narzędzi monitorujących. Jednak w skrajnych przypadkach może prowadzić do sytuacji, kiedy np. aplikacja przetestowana w środowisku testowym nie uruchamia się prawidłowo na niektórych maszynach w środowisku produkcyjnym.

Alternatywą jest podejście oparte na koncepcji niezmienności infrastruktury, przy wsparciu wspomnianych już narzędzi takich jak Terraform czy AWS CloudFormation. Nowa instancja serwera z obrazu maszyny lub obrazu kontenera jest tworzona za każdym razem, kiedy następuje modyfikacja. Innymi słowy – jeśli instancje maszyn wymagają aktualizacji, zastępujemy je nowymi instancjami. Kiedy nowe maszyny są gotowe, można wyłączyć poprzednie instancje i uwolnić zasoby. Oczywiście takie podejście może mieć również swoje wady, np. kiedy modyfikacje mają miejsce często (codziennie), a infrastruktura obejmuje setki instancji – wówczas powoływanie i zwalnianie instancji będzie czasochłonne.