tl;dr

Infrastructure as Code (IaC) to:

• przeniesienie prac administratora do repozytorium
• redukcja błędów i niespójności, większa niezawodność
• automatyzacja i integracja z CI/CD - powtarzalność

Kierunek w IT

W ciągu ostatnich kilku lat technologie IT ewoluowały do zróżnicowanych struktur usług, aplikacji, urządzeń, sieci i innych zasobów. Pomiędzy tymi elementami nowoczesnej architektury informatycznej istnieje coraz to większa korelacja via przepływ danych bez względu na różne lokalizacje tych zasobów. Infrastructure as Code to jedna z praktyk do zarządzania takim potencjałem.

Infrastructure as Code (IaC)

IaC to jeden ze sposobów - praktyk tworzenia, modyfikacji i zarządzania zasobami. Definicję można rozbudować o zarządzanie zasobami takimi jak cokolwiek-aaS, IoT, aplikacje, klastry obliczeniowe, usługi, połączenia i urządzenia sieciowe czy to w środowisku on-premise czy w chmurze. Zarządzanie polega na kontrolowaniu zmian w środowiskach poprzez ich opis. Opisem jest oczekiwany stan - do tego wykorzystujemy opis deklaratywny. Podejście deklaratywne to wskazanie właściwości obiektu jakie są dla nas stanem oczekiwanym. Dla kontrastu można wymienić podejście imperatywne, gdzie nie opisujemy jaki efekt chcemy osiągnąć a w jaki sposób - można to opisać jako instrukcja rozkazów. Poniższy schemat obrazuje różnice.

           podejście 
_______________:______________
[deklaratywne] : [imperatywne]
     /\        :        |
    /  \       :       <A>-[B]
  [A]  [B]     :        |
  / \          :   [C]-<D>-[E]
[C] [D]        :    |   |      
    / \        :   [F] [G]
  [F] [G]      :       

Modelowanie infrastruktury za pomocą kodu jest naturalnym wynikiem powstawania coraz to większego nacisku na m. in. bezpieczeństwo, powtarzalność, złożoność rozwiązań, dostępność, szybkość wdrażania i redukcji kosztów.

Ta historia może być prawdziwa :)

Wyobraźmy sobie, że przed nami kolejny release i należy zmianę wdrożyć na środowiska (np. dev, sit, uat, etc.) w różnych lokalizacjach (np. regiony w chmurze, urządzenia mobilne, itp.). Sukcesem dokonania tych zmian będzie zautomatyzowanie procesów Continuous Integration, Delivery, Deployment (skrótowo CI/CD) ze wszelkimi dodatkowymi działaniami od strony DevOpsów. CI/CD pokazało, że owe procesy można opisać w repozytorium kodu. Teraz DevOps już wie, że podciągnięcie pozostałych działań do postaci kodu w gicie to wisienka na torcie automatyzacji przepływów pracy. I tak właśnie powstała Infrastructure as Code ;).

Rozwiązanie …

     Infrastructure as Code
   ___________________________
  |      |      |      |      |
(^_^)  [o_o]  (^.^)  (".")  ($.$)

W kontekście naszych rozważań najważniejszym wyzwaniem jest sprostanie budowania bezpiecznych i niezawodnych platform działających na wielu obszarach technologicznych a nawet i prawnych. Dzięki redukcji zagrożeń poprzez możliwość inspekcji i wersjonowania kodu kontrolujemy potrzebę tworzenia i optymalizacji jakości produktu. Wyzwaniem również jest zmieniająca się koncepcja wdrażania i integracji, która była optymalnym rozwiązaniem w chwili jej tworzenia jak i zbieżność środowisk.

0x00 nie dla każdego

Zarządzanie wieloma lokalizacjami / usługami / sieciami / sprzętem / oprogramowaniem itd. to duży nakład pracy podczas tworzenia opisu naszej infrastruktury. Utrzymanie rozbudowanego środowiska wymaga kompleksowej wiedzy i wielopłaszczyznowego doświadczenia inżynierów. Połączenie przeróżnych dostawców sprzętu i usług zewnętrznych (np. dostęp do sieci) i zapewnienie skalowalności tychże rozwiązań to dopiero fundament do dalszych integracji.

▄▄███▄▄·▄▄███▄▄·▄▄███▄▄·
██╔════╝██╔════╝██╔════╝
███████╗███████╗███████╗
╚════██║╚════██║╚════██║
███████║███████║███████║
╚═▀▀▀══╝╚═▀▀▀══╝╚═▀▀▀══╝

Zapewnienie wysokich wartości dla SLA to marzenie każdego, lecz tylko część posiada na to odpowiednie moce w postaci zasobów na ciągłą synchronizację konfiguracji środowisk i wprowadzania nowych elementów.

0xff nie na wszystko

Staramy się ulepszać sposób w jaki pracujemy, podróż wydaje się nie mieć końca i to może być nasz przysłowiowy gwóźdź do trumny.

     _                    _       _          _   _             
  __| | ___  _ __   ___  (_)___  | |__   ___| |_| |_ ___ _ __  
 / _` |/ _ \| '_ \ / _ \ | / __| | '_ \ / _ \ __| __/ _ \ '__| 
| (_| | (_) | | | |  __/ | \__ \ | |_) |  __/ |_| ||  __/ |    
 \__,_|\___/|_| |_|\___| |_|___/ |_.__/ \___|\__|\__\___|_|    
  _   _                                    __           _      
 | |_| |__   __ _ _ __    _ __   ___ _ __ / _| ___  ___| |_    
 | __| '_ \ / _` | '_ \  | '_ \ / _ \ '__| |_ / _ \/ __| __|   
 | |_| | | | (_| | | | | | |_) |  __/ |  |  _|  __/ (__| |_    
  \__|_| |_|\__,_|_| |_| | .__/ \___|_|  |_|  \___|\___|\__|   
                         |_|                                   

Ciągłe prace nad optymalizacją mogą i w większości przypadków prowadzą do błędnego koła, gdyż za każdym razem znajdzie się coś co można zrobić lepiej. Oczywiście należy starać się napisać kod tak dobrze na ile nasz stan wiedzy na to pozwala, lecz czynnikiem istotnym przy tworzeniu takiego bytu jest czas, jakim dysponujemy i trzeba go mieć na uwadze. Zauważyć należy, że multipla to też nie jest idealne auto, ale spełnia swoje zadanie jako pojazd - dość przejaskrawione porównanie ;p.

Ścieżka rozwoju

IaC to racjonalna ścieżka rozwoju nowoczesnego ekosystemu IT, kolejny krok w tworzeniu nowych platform i w rzeczywistości solidny model biznesowy. Zwrócić należy uwagę, że pierwotną ideą tego rozwiązania jest umożliwienie współpracy zespołów zajmujących się programowaniem z rozwojem infrastruktury. Jak tylko do tego dodamy takie idee jak: kod powinien być samodokumentujący się, rozwiązanie powinno być zgodne z duchem KISS, uniwersalność i skalowalność to mamy gotowy przepis na sukces, teoretycznie.

Rzeczywistość jest trochę inna. Zauważamy, że zbyt kompleksowe rozwiązania zabijają produktywność - staramy się z tym walczyć redukując złożoność. Optymalizacja w postaci czytelności kodu - zapewnia to lepszą dokumentację, tutaj stosujemy dobre praktyki, aby narzucić większą klarowność kodu i go ustandaryzować (składnię). Nieustannie dążymy do otrzymania stanu a nie programować - deklaratywne myślenie a więc powtarzalność nie zmienia kodu to oczekiwany stan a droga ku temu potrafi być wyboista. Kolejny ważny element poprawnie działającego kodu to ciągłe testowanie (Continuous Testing). CT jest krytycznym elementem rozbudowanych środowisk, podobnie jak przy każdym releasie oprogramowania i tu należy wystrzegać się błędów konfiguracyjnych, aby uniknąć problemów przy wdrożeniu.

IaC - nie dziękuję

W firmie mamy kilka scenariuszy ustandaryzowanych działań np.: skrypty, notatki w katalogu ICE-produkcja, mamy również zespół ludzi, którzy znają środowisko doskonale, bo pracują tu od 30 lat. Na co dzień radzimy sobie, gdyż nasze systemy nie zmieniły się od dwóch dekad.

Próby wdrożenia podejścia IaC dla takich środowisk jest ogólnie ujmując niemożliwe (teoretycznie realne), gdyż wiąże się to z bardzo dużymi kosztami, które mogą przekroczyć budżet a czas ich realizacji będzie liczony w nieakceptowalnych terminach. Kolejny przesadny przykład, którego przesłaniem jest zobrazowanie, że nie wszystko można automatyzować w duchu Infrastructure as Code. Poniesione koszty nie są adekwatne do korzyści z nich wynikających. Elementy infrastruktury (systemy operacyjne, aplikacje, sprzęt warstwy sieciowej, etc.), które nie są już mocno rozwijane należy pozostawić w spokoju, gdyż próby spisania ich stanów i działań mogą być nieopłacalne. Dodatkowo ich szczątkowe użycie w obecnym świecie może działać niekorzystnie na ich bezpieczeństwo (dbanie o aktualizacje, naprawa na bieżąco błędów), integracje z aktualnymi zasobami (np. porzucenie starych protokołów komunikacji) czy utrzymanie (specjalistów starych technologii ubywa lub są bardzo drodzy).

Narzędzia

Wybór narzędzi jest uwarunkowany zasobami, jakie chcemy spisać. Część z tych aplikacji jest (w różnym stopniu) uniwersalna, może jednocześnie zapisać stan infrastruktury, konfigurację aplikacji czy usług chmurowych. O narzędziach będzie osobny artykuł, lecz tylko wspomnę o kilku, niektóre są specyficznym rozszeżeniem IaC (np. IaC Security)

Best Practice

Lista z ważniejszymi metodami pracy z Infrastructure as Code.

• właściwe jest wykonywanie drobnych zmian, gdyż takie działania są łatwiejsze do wycofania się w przypadku natrafienia na błędy
• jak już kodujemy to wszystko - starajmy się tylko w wyniku konieczności wykorzystywać źródła zewnętrzne (np. wykonania aplikacji, której wynik można opisać w kodzie)
• dokumentujemy jak najmniej, gdyż sam kod odpowiednio zapisany będzie pełnił taką funkcję
• staramy się utrzymywać kod w modułach, podział sprzyja rozbudowie i jest klarowny w obsłudze
• wskazane jest przechowywanie każdej wersji konfiguracji
• skrupulatne testowanie to mniej czasu na obsługę błędów podczas wdrożenia
• używaj właściwego narzędzia do tego nad czym zarządzasz
• tagowanie w rozbudowanej infrastrukturze jest jak wygrać los na loterii
• staramy się, aby nasze szablony były jak najbardziej przydatne w przyszłości do ponownego użycia
• nie opieramy wywołań poprzez aplikacje pośrednie bez konieczności takich działań
• zadbaj o maksymalną przenośność kodu (np. Multi Cloud)