Wprowadzenie

Od wielu lat złożoność systemów systematycznie rośnie. Gdy zaczynałem swoją zawodową przygodę z programowaniem w .NET w okolicach 2007, większość systemów była bardzo prosta. Był to na ogół Windows Server z IIS oraz baza danych MS SQL Server. Aktualnie, w szczególności w rozwiązaniach chmurowych, ilość używanych komponentów jest dość spora, nawet przy prostej aplikacji. Dlatego coraz większą popularność zdobywają rozwiązania Infrastructure as Code (IaC), których przykładem jest Terraform.

Tym wpisem chciałbym rozpocząć mini serię artykułów poświęconych Terraformowi. Jako programista .NET skupię się tutaj w szczególności na wykorzystaniu Terraforma w kontekście infrastruktury działającej w Azure.

Infrastructure as Code

Infrastructure as Code jest procesem, w którym automatycznie zarządzamy zasobami aplikacji z wykorzystaniem jakiegoś kodu (np. plików json). Na ogół w sposób deklaratywny, określamy jak mają wyglądać zasoby (ich liczebność, ustawienia). Następnie wykorzystujemy jakieś rozwiązanie (np. Terraform), które na podstawie aktualnego stanu odpowiednio zmienia infrastrukturę, aby dojść do stanu docelowego.

Takie podejście ma kilka plusów. Przede wszystkim poszczególne środowiska, które wykorzystujemy w projekcie (np. test, stage, prod), są identyczne. Nie przeoczymy żadnego istotnego ustawienia jakiejś usługi, o którym przy ręcznej konfiguracji, wcześniej, czy później moglibyśmy zapomnieć (a znając życie, byłoby to na środowisku produkcyjnym).

Oczywiście poszczególne środowiska odrobinę różnią się między sobą. Na ogół są to jednak głównie ustawienia określające wielkość danego zasobu. Na przykład w środowisku testowym nie potrzebujemy tak samo mocnej maszyny jak w środowisku produkcyjnym. Dostępne rozwiązania udostępniają mechanizmy zmiennych lub parametrów, za pomocą których możemy określać różnice między środowiskami. Fajne jest, że tutaj wyraźnie widać, w których miejscach poszczególne elementy infrastruktury różnią się.

Kolejnym plusem jest dużo łatwiejsze stawianie nowych środowisk. Na przykład, gdy potrzebujemy nowego środowiska do testów, czy środowiska dla nowego klienta (aplikacja multi tenant). W takiej sytuacji wystarczy tylko określić nowe wartości zmiennych/parametrów i uruchomić cały proces.

Kształt infrastruktury przechowujemy w kodzie, co też ma swoje plusy. Mamy historię zmian, możemy je powiązać z określonymi wymaganiami/zadaniami. Dzięki temu z czasem dużo łatwiej dojść do tego, dlaczego coś zmieniliśmy, niż ma to miejsce w przypadku ręcznej zmiany jednego z środowisk.

Infrastructure as Code – minusy

Jak każde rozwiązanie również i Infrastructure as Code ma swoje minusy. Ale w mojej ocenie plusów jest jednak dużo więcej niż minusów.

Przede wszystkim jest to dodatkowy element w całej układance. Każde narzędzie/rozwiązanie ma jednak swój próg wejścia, który w przypadku Infrastructure as Code jest jednak relatywnie wysoki. Musimy poświęcić trochę czasu, aby poznać dane narzędzie, zidentyfikować typowe problemy i znaleźć na nie rozwiązania. A to zajmuje czas i warto to odpowiednio zaplanować.

Na początku również przygotowanie całego opisu infrastruktury jest bardziej czasochłonne niż ręcznie jej wyklikanie. Szczególnie, gdy przy okazji dopiero uczymy się danego rozwiązania. W niektórych sytuacjach można sobie ten proces trochę ułatwić. Na przykład używając ARM Templates możemy w pierwszej kolejności utworzyć zasób w portalu Azure, a następnie wygenerować na jego podstawie szablon. Później ten szablon możemy zmieniać.

Z drugiej strony z czasem ten problem staje się coraz mniejszy. W kolejnych projektach możemy już bazować na definicji infrastruktury z wcześniejszych projektów. Dzięki temu ten problem jest minimalizowany, a nawet jesteśmy w stanie szybciej postawić środowiska w nowym projekcie niż ręcznie je wyklikać.

Kolejnym problemem jest ręczna edycja infrastruktury. Na ogół pojawia się ona, gdy na przykład na środowisku testowym pojawia się jakiś problem. Wtedy w pierwszej kolejności na ogół chcemy ręcznie zmienić konfigurację i go rozwiązać, a później zmianę przenieść do kodu. Niestety wtedy często okazuje się, że jednak zapomnieliśmy przenieść jakąś zmianę ustawienia do kodu i wdrożenie zmian w innym środowisku powoduje znowu wystąpienie problemu. Tutaj jednak warto zawsze zmiany realizować przez kod, dzięki czemu ta sytuacja się nie pojawi.

W przypadku Infrastructure as Code również pewnym wyzwaniem jest przechowywanie haseł. Tworząc jakiś zasób, bardzo często musimy podać login i hasło dla administratora danego zasobu. Nie chcemy tego trzymać w kodzie i musimy znaleźć jakieś rozwiązanie tego problemu (np. użyć zmienne do tego typu ustawień).

Oczywiście rozwiązanie, które wybierzemy może nieść dodatkowo jakieś minusy i problemy, z którymi trzeba żyć. Ale tak jak pisałem wcześniej, w mojej ocenie plusy zdecydowanie przeważają nad minusami.

Azure i Infrastructure as Code

Na co dzień w projektach, które realizuję, wykorzystuję chmurę Azure. Dlatego w tej mini serii skupię się na Infrastructure as Code w kontekście tego rozwiązania.

W przypadku Azure podstawowym rozwiązaniem są szablony ARM (ARM Templates). We wpisie poświęconym wdrażaniu Azure Logic App wykorzystałem właśnie to rozwiązanie. Szablony ARM są to pliki json, które definiują konfigurację poszczególnych zasobów. Największym ich plusem jest to, że możemy je wygenerować na podstawie istniejących zasobów, a później możemy je edytować lub dodawać kolejne parametry. Osobiście średnio mi się pracuje z tymi szablonami. Ich czytelność nie jest zbyt dobra oraz dość ciężko się je parametryzuje.

Od jakiegoś czasu Microsoft pracuje nad alternatywą dla ARM Templates, którą jest Bicep. Rozwiązanie to ma usunąć problemy, które mają szablony ARM i ułatwić wykorzystanie Infrastructure as Code w Azure. Pod spodem składnia Bicep jest zamieniana na szablon ARM i wykonywana. Jest również możliwość dekompilacji istniejących szablonów do kodu Bicep. Osobiście jeszcze nie bawiłem się Bicep, ale mam to na liście ToDo 🙂

W firmie, w której aktualnie pracuję, wykorzystujemy Terraforma do stawiania infrastruktury projektów. Terraform ma wsparcie dla Azure i właśnie w tej mini serii artykułów na tym się skupię. Więcej w kolejnych artykułach.

Alternatywnymi rozwiązaniami jest na przykład skorzystanie z Azure CLI, za pomocą którego możemy stworzyć skrypty, które utworzą i skonfigurują zasoby w Azure. W sytuacji gdy zamiast skryptów chcielibyśmy skorzystać z C# i .NET, możemy w tym celu użyć Azure Management Libraries for .NET. Obie te metody wykorzystują trochę inne podejście (imperatywne). Określamy tutaj kroki, jakie mają się wykonać, a nie stan docelowy – jak to było w rozwiązaniach wcześniejszych.

Rozwiązań jest kilka i myślę, że każdy znajdzie coś dla siebie.

Podsumowanie

Tym wpisem zaczynam mini serię artykułów poświęconych użyciu Terraform do stawiania infrastruktury w Azure. Wprowadziłem Cię w tematykę Infrastructure as Code oraz wspomniałem o rozwiązaniach, które możemy wykorzystać w Azure. W kolejnym artykule zajmiemy się już stricte podstawami Terraforma.