Sposób zarządzania infrastrukturą przez zespoły IT zmienia się wraz z migracją całości lub części środowisk do modelu chmurowego. Zamiast zamawiać i instalować sprzęt, inżynierowie wybierają opcje maszyn wirtualnych w panelu dostawcy i maszyny są natychmiast tworzone. To samo dotyczy zwalniania zasobów. Ale to nie wystarczy, kiedy infrastruktura i stos aplikacji szybko ewoluują.
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ą.
Powoduje to, że oczekiwania stawiane przed liderami technologii w organizacjach przechodzą szybką ścieżkę ewolucji. Gartner w swoich prognozach na 2021 rok wyróżnia 6 trendów, które mają mieć kluczowy wpływ na obszar infrastruktury i operacji (I&O). Wśród nich znalazły się: optymalizacja 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 proc. departamentów I&O w organizacjach będzie obsługiwało pracę zdalną większości swoich pracowników. COVID-19 być może przyspieszył ten trend, ale jest to również rezultat zmieniającego się charakteru infrastruktury, spowodowanego przejściem do chmury.
– 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.
Sposób dostarczania i zarządzania infrastrukturą w organizacjach czeka przyspieszona ewolucja, pozwalająca na skok efektywności. Kluczową role odegrają tutaj tak ważne elementy kultury IT w firmie jak DevOps, ciągłe dostarczanie (continuous delivery) oraz infrastruktura zarządzana poprzez kod.
INFRASTRUKTURA W KODZIE
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.
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. 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. Obecnie – 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.
AUTOMATYZACJA I IDEMPOTENCJA
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.
Idąc dalej, liderzy IT mogą zdecydować o połączeniu podejścia IaC z konteneryzacją aplikacji, dzięki czemu aplikacja zostaje odseparowana od infrastruktury na poziomie systemu operacyjnego. 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ą.
Najważniejsze 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.
- Szybsze dostarczanie oprogramowania – szybkie, zautomatyzowane zapewnienie infrastruktury do rozwoju, testowania i wdrażania aplikacji wpływa na przyspieszenie procesu dostarczania oprogramowania. Ponieważ proces wdrażania jest zautomatyzowany, jest on również spójny i powtarzalny.
- Łatwa dokumentacja – stan infrastruktury jest określony w kodzie szablonu i może mieć różną postać w zależności od narzędzia. Jednak z reguły jest to notacja analogiczna do pliku JSON, który jest łatwy do odczytania przez każdego członka zespołu czy wdrażającego się specjalistę. Kiedy skrypty opisują bardzo rozbudowaną infrastrukturę może zachodzić konieczność dodatkowego dokumentowania kodu, jednak służy to lepszej orientacji i utrzymaniu kodu.
- Kontrola wersji – infrastruktura jako kod zmniejsza wysiłek i ryzyko związane z wprowadzaniem zmian w infrastrukturze, ponieważ można zastosować sprawdzone procesy i narzędzia zarządzania kodem. Mając pliki źródłowe umieszczone w kontroli wersji możemy śledzić wszystkie zmiany dokonane w infrastrukturze i w większości wypadków powrócić do poprzedniej wersji.
- Walidacja i testowanie – infrastruktura jako kod umożliwia częste testowanie i stosowanie małych zmian. Ponieważ mamy do czynienia z kodem, można sprawdzać błędy za pomocą analizy statycznej i testów automatycznych.
- Zwiększone bezpieczeństwo – IaC umożliwia statyczna analizę bezpieczeństwa i osadzenie zabezpieczeń od samego początku (jako element procesu DevSecOps), oraz zarządzanie zmianami przy zredukowanym ryzyku pojawienia się luki w bezpieczeństwie.
RÓŻNE NARZĘDZIA DLA RÓŻNYCH PODEJŚĆ
Pomimo swoich jednoznacznych zalet IaC stwarzać może 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.
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.
ORKIESTRACJA I KONFIGURACJA
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.
PODEJŚCIE IMPERATYWNE A DEKLARATYWNE
Deklaratywne podejście do programowania nakreśla pożądany, zamierzony stan infrastruktury, ale nie wymienia wyraźnie kroków prowadzących do osiągnięcia tego stanu. Przykładem takiego podejścia są szablony AWS CloudFormation napisane właśnie w modelu deklaratywnym. Do narzędzi deklaratywnych należą również Terraform, Puppet czy SaltStack.
Natomiast podejście imperatywne można porównać do działania skryptów powłoki i polega na wykonaniu sekwencji poleceń, które umożliwiają powołanie infrastruktury o założonych parametrach. Z narzędzi np. Chef czy Ansible mogą być używane w sposób deklaratywny i imperatywny, w zależności od potrzeb.
W obu podejściach kod powołujący infrastrukturę jest konfigurowany w szablonie, w którym użytkownik określa zasoby potrzebne dla każdego serwera w infrastrukturze.
INFRASTRUKTURA ZMIENNA I NIEZMIENNA
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.
DOBRE PRAKTYKI KODOWANIA INFRASTRUKTURY
Wdrażanie i zarządzanie infrastrukturą chmury poprzez IaC z wykorzystaniem takich narzędzi jak Terraform, AWS Cloud Formation czy Azure Resource Manager, umożliwia organizacji osiągnięcie kolejnego etapu zwinności (agility). Pozwala też na osadzenie zasad bezpieczeństwa we wcześniejszym etapie cyklu rozwoju aplikacji i ich weryfikację przed wdrożeniem infrastruktury. Przyjrzyjmy się typowym zagrożeniom związanym z IaC w praktyce – poniżej wybrane, choć nie jedyne, problemy i dobre praktyki pozwalające ich uniknąć bądź zminimalizować skutki.
NAJWIĘKSZE WYZWANIA I REKOMENDACJE DLA IAC
| PROBLEM | NA CZYM POLEGA | ZALECENIA |
| Udostępnianie kluczy w kodzie | Zakodowane dane uwierzytelniające to jedna z bardzo powszechnych praktyk. Polega na umieszczeniu w kodzie źródłowym danych uwierzytelniających takich jak klucze SSH lub hasła do kont, zwykłym tekstem. Ryzyko jest bardzo poważne, od nieautoryzowanych uprawnień po wyciek danych. Niestety, IaC ułatwia stosowanie tej praktyki. Skanowanie kodu skryptów pod kątem zakodowanych kluczy przed ich uruchomieniem na infrastrukturze chmurowej. | Skanowanie kodu skryptów pod kątem zakodowanych kluczy przed ich uruchomieniem na infrastrukturze chmurowej. |
| Dryf konfiguracji | Jeśli nagła sytuacja zmusza zespół operacji IT do zmiany konfiguracji w infrastrukturze chmury poza kodem skryptu łamie tym samym zasadę niezmienności infrastruktury po jej wdrożeniu. Powoduje to ryzyko utraty integralności infrastruktury i ewentualnych błędów np. w działaniu aplikacji testowanych na innej konfiguracji. | Wprowadzanie zmian w infrastrukturze tylko poprzez skrypty IaC i wdrożenie nowej konfiguracji z kodu. Monitorowanie różnic między konfiguracją infrastruktury a kodem szablonu IaC. |
| Eskalacja uprawnień | IaC jest używany do zapewnienia pełnych środowisk w chmurze tj. obejmujących również kontenery i mikrousługi. Ryzyko tzw. eskalacji uprawnień jest związane z częstym wykorzystywaniem przez inżynierów kont z uprawnieniami developerskimi do wdrażania aplikacji w różnych warstwach chmury. Jeśli towarzyszyć tej praktyce będzie dodatkowo ww. przypadek umieszczenia danych uwierzytelniających w kodzie to mamy poważne ryzyko ekspozycji na atak. | Stosowanie zasady najmniejszych uprawnień na poziomie szablonów IaC. Skanowanie kont i ich uprawnień w celu wykrycia ewentualnych naruszeń przed wdrożeniem na produkcji. |
| Wykrywanie podatności | Szablony IaC są używane do wdrażania instancji maszyn wirtualnych, instancji kontenerowych itp. poprzez wykorzystanie bazowych obrazów przechowywanych w zaufanych repozytoriach. Wykorzystanie obrazu posiadającej niewykrytą lukę bezpieczeństwa stwarza ryzyko ekspozycji na atak. Należy dążyć do wczesnego wykrycia i usunięcia wszelkich znanych luk w takich obrazach bazowych. | Regularna analiza obrazów wykorzystywanych w szablonach IaC pod kątem możliwych i potwierdzonych podatności. |
| Zaginione zasoby | Zaginione zasoby Zasoby tworzone i konfigurowane przy użyciu IaC, ale nie skatalogowane i otagowane, powodują powstawanie zbioru zasobów-widm. Te z kolei mogą powodować problemy w zakresie kontroli i widoczności w produkcyjnym środowisku w chmurze. Może mieć to konsekwencje dla bezpieczeństwa, kontroli kosztów czy efektywności. Tagowanie i katalogowanie zasobów chmurowych jest niezbędne do realizacji polityk zarządczych (governance). | Tagowanie i katalogowanie zasobów chmurowych jest niezbędne do realizacji polityk zarządczych (governance). |
| Naruszenie zasad zgodności z regulacjami | Wiele organizacji korzystających z infrastruktury chmury obliczeniowej jest zobowiązanych do przestrzegania regulacji branżowych jak GDPR, HIPAA, PCI DSS czy SOC2. Dlatego ważne jest posiadanie mechanizmów egzekwowania polityki zapewnienia zgodności na poziomie IaC. Przykładem może być SOC2, który wymaga istnienia zasad dotyczących haseł IAM, pominięcie implementacji tej polityki na etapie IaC skutkować będzie niezgodnością wdrożonej infrastruktury z regulacjami. | Wdrożenie polityki zapewnienia zgodności oraz wykonanie testów zgodności szablonów IaC na każdym etapie wydań (CI/CD). |
Infrastruktura definiowana poprzez kod jest podejściem oferującym wiele korzyści w porównaniu z manualnym wdrażaniem i konfiguracją – pozwala na wersjonowanie, testowanie, wspiera szybsze i częstsze dostarczanie oprogramowania.
Wiele organizacji zaczęło już stosować podejście IaC do budowy i zarządzania swoją infrastrukturą. Mając na uwadze, że IaC jest nie tyle samodzielnym złotym środkiem do osiągnięcia business agility a integralną częścią DevOps i kultury ciągłego dostarczania (CD), warto zadbać o wsparcie doświadczonego partnera. Takie, które pozwoli szybciej przebyć etap od wdrożenia do korzyści, jednocześnie dając okazję do równoległej budowy kompetencji w zespole wewnętrznym.
Ostatnie wpisy
Może zainteresują Cię także…
