Infrastructure as a Code (IaC) – dlaczego infrastruktura jako kod jest dla nas ważna? 

Firmy coraz częściej korzystają z rozwiązań chmur publicznych. Również my, zamiast zamawiać i instalować sprzęt, korzystamy z chmury Azure. Dzięki temu bez problemu możemy dostosować się do wszelkich zmian oraz pojawiających się na bieżąco potrzeb, a także zapewnić sobie elastyczny model pracy – każdy z nas może równie dobrze pracować zdalnie, jak i stacjonarnie. Przeniesienie środowiska do chmury wymaga jednak odpowiedniego dostosowania charakteru infrastruktury, co ma ułatwić podejście do zarządzania systemami, maszynami wirtualnymi, sieciami nazywane infrastrukturą w kodzie. 

Czym jest infrastruktura jako kod? 

Przez bardzo długi okres jedna osoba była w stanie zarządzać góra kilkoma serwerami. Ostatni czas przyniósł rewolucję w tym zakresie, a dostawcy usług w chmurze kierują infrastrukturą setek firm. Przykładem takiej metody zarządzania środowiskami może być wykorzystanie pipeline w Azure DevOps, którego używamy w Hued.me. Jego podstawą jest właśnie infrastruktura jako kod. Co jednak dokładnie oznacza to sformułowanie? 

Infrastructure as a Code (IaC) to pewien sposób zarządzania infrastrukturą. IaC generuje identyczne środowisko (np. developerskie lub produkcyjne) z możliwością dostosowania zasobów (np. rodzaju wirtualnej maszyny) do niego. W ten sposób developerzy lub DevOpsi korzystają z automatyzacji tworzenia, uruchamiania i konfiguracji systemu, a procedura replikowania środowiska jest dużo szybsza i prostsza. IaC charakteryzuje się elastycznością w zakresie tworzenia (budowania) infrastruktury oraz podejściem z natury deklaratywnym.  

Z czym się to wiąże? Automatyzacja deklaratywna skupia się na konkretnym celu. Określamy, co jest potrzebne, i czekamy, aż system utworzy pożądaną funkcję. W podejściu imperatywnym natomiast tworzymy wszystko „na piechotę”, opisujemy każdą czynność konfiguracyjną i, co za tym idzie, narażamy się na powtarzanie całego procesu w przypadku konieczności dokonania jakiejś zmiany. 

Warto wspomnieć też o idempotencji, czyli pojęciu nierozerwalnie powiązanym z IaC. Chodzi o powtarzalność rezultatu, którą uzyskamy bez względu na to, ile razy uruchomimy skrypt. Podczas tego procesu aktualny stan skryptu jest sprawdzany, porównywany z pożądanym wynikiem, jaki został określony, i dostosowywany do jego osiągnięcia. 

Jakie są korzyści z zastosowania Infrastructure as a Code? 

Przede wszystkim zaoszczędzamy zasoby. Zarówno ludzkie, ponieważ jeden pracownik może zajmować się wieloma infrastrukturami, jak i pieniężne, bo czas wykonywania zadań jest znacznie krótszy, a nakład pracy specjalistów mniejszy. Jak widać, dostarczenie oprogramowania może być szybsze i łatwiejsze.  

IaC znacząco ułatwia pracę zespołu. Sam proces wdrażania jest automatyczny, więc każdy może go uruchomić na własną rękę. Skrypt opisujący stan infrastruktury jest prosty do odczytania dla wszystkich osób z teamu, a dodatkowa dokumentacja jest potrzebna jedynie w przypadku bardzo skomplikowanych procesów. Dzięki temu nie musimy dokładnie pamiętać poszczególnych kroków i łatwo nam wrócić do projektu nawet po dwóch latach od jego zakończenia. Infrastruktura jako kod oferuje też wysoki poziom bezpieczeństwa i możliwość wprowadzania zabezpieczeń już od samego początku, co zmniejsza ryzyko powstania luk. IaC upraszcza również testowanie i kontrolowanie powstającej infrastruktury, ponieważ umożliwia śledzenie zmian, powroty do poprzednich wersji oraz sprawdzanie błędów za pomocą np. analizy statycznej. 

Jakie narzędzia są najlepsze podczas wdrażania Infrastructure as a Code? 

Można by pomyśleć, że IaC nie stawia przed zespołem developerskim zbyt wielkich wyzwań. Wszystko jest zautomatyzowane, dopasowywane i maksymalnie uproszczone. Jednak infrastruktura jako kod wymaga stosowania adekwatnych narzędzi, które pozwolą na zarządzanie konfiguracją i orkiestracją. Bez wysokich kompetencji w tym zakresie, team naraża infrastrukturę na błędy spowodowane w głównej mierze właśnie automatyzacją – wszystko należy na bieżąco kontrolować i testować. Dzisiaj tylko wspomnę o trzech narzędziach: ARM, Terraform i BICEP.

ARM 

Azure Resource Manager (ARM) obsługuje wdrażanie i zarządzanie na platformie Azure. Odbiera żądania, sprawdza je i dopiero wtedy kieruje do odpowiedniej usługi platformy. Dzięki niemu możemy tworzyć, aktualizować i usuwać zasoby na koncie, a funkcje takie jak kontrola dostępu, blokady i tagi pozwalają zabezpieczyć i lepiej zorganizować infrastrukturę po wdrożeniu 

Terraform 

To narzędzie od HashiCorp pozwalające zespołowi na używanie języka HCL, czyli na konfigurację wysokiego poziomu. Umożliwia bezpieczną i efektywną automatyzację infrastruktury, a także zaopatruje środowiska chmury hybrydowej lub multicloud, takie jak AWS, Azure czy GCP. Korzystanie z Terraform daje przestrzeń do osiągnięcia kolejnego poziomu zwinności w zarządzaniu infrastrukturą. 

BICEP 

Ten język jest ściśle powiązany z podejściem deklaratywnym, stanowi pewnego rodzaju połączenie ARM z Terraform. Niektórzy twierdzą, że BICEP jest poniekąd wynikiem ewolucji ARM, co widać w składni. Służy m.in. do wdrażania zasobów na platformie Azure, można określić w nim wygląd końcowy infrastruktury, a potem stosować go przez cały proces programowania. Zwięzła składnia, wysoki poziom bezpieczeństwa i pierwszeństwo w aktualizowaniu nowych funkcjonalności to tylko niektóre z zalet, które oferuje to środowisko do tworzenia infrastruktury jako kodu. 

Czy na pewno warto inwestować w infrastrukturę jako kod? 

Wydaje się, że często szybciej i łatwiej nam coś wyklikać niż przemyśleć całą infrastrukturę. Choć jest to niewątpliwie wyzwanie, z pewnością będzie dla firmy opłacalne. Uważam, że w perspektywie długofalowej korzyści płynące z IaC są jednak na tyle duże, że warto zacząć ją stosować. Może nie dostrzeżemy zalet tego rozwiązania od razu, ale po jakimś czasie zobaczymy, ile kłopotu, czasu i pieniędzy sobie zaoszczędziliśmy.