Ostatnie lata to wzrost popularności architektury mikrousługowej i chmur obliczeniowych. Pociąga to za sobą nowe możliwości. Zmieniają się także wymagania dotyczące zarządzania infrastrukturą. Czemu i jakie zmiany zachodzą w tej dziedzinie, dowiesz się z tego wpisu.

Co rozumiemy przez infrastrukturę?

Definicji infrastruktury jest wiele. Dla jednych jest to hardware, inni rozumieją ją jako maszyny wirtualne, a jeszcze inni, słysząc to słowo, mają przed oczami konfigurację chmury. Na potrzeby tego artykułu załóżmy, że wszystkie powyższe definicje są prawidłowe.  A my zajmiemy się najszerszym określeniem, jakie przychodzi mi do głowy, czyli:

infrastruktura to wszystko, czego potrzebujemy do uruchomienia aplikacji,
poza samą aplikacją.

Zastanówmy się zatem, co takiego, poza kodem samej aplikacji, jest niezbędne do jej uruchomienia. Na pewno fizyczne serwery są podstawą wszystkiego. Na tej warstwie z reguły działa hypervisor czy też cloud, który zarządza działającymi komponentami, takimi jak maszyny wirtualne bądź elementy platformowe (PaaS). Jeżeli opieramy swój system właśnie na wirtualnych instancjach, otrzymujemy gotowy system operacyjny. Należy go natomiast odpowiednio skonfigurować, dodając użytkowników, instalując oprogramowanie czy definiując serwisy aplikacyjne. Czy to już pozwala nam uruchomić naszą aplikację? Nie tak szybko – nie mamy przecież jeszcze co wdrażać. Naszą aplikację należy wcześniej zbudować – tylko jak? Tu pojawia się kolejny element naszej infrastruktury, czyli właśnie konfiguracja serwerów automatyzacji. Po zbudowaniu wystarczy już tylko ją wdrożyć. I tutaj pojawiają się ostatnie trzy komponenty: pipeline’y (rury) wdrożeniowe, konfiguracja aplikacji (hasła do bazy danych, parametryzacja etc.) i skrypty wdrożeniowe.  W formie bardziej przystępnej dla wzrokowców wygląda to następująco:

  • hardware
  • hypervisor / cloud
  • maszyny wirtualne
  • konfiguracja systemu operacyjnego
  • skrypty budujące i pipeline’y wdrożeniowe
  • parametryzacja aplikacji i skrypty wdrożeniowe (deploymentowe).

Co daje nam automatyzacja?

Skoro już wiemy, co można rozumieć przez infrastrukturę, zastanówmy się, po co w ogóle myśleć o jej automatyzacji. Rosnąca popularność systemów rozproszonych z mikroserwisami na czele, powoduje zwiększenie granulacji komponentów, którymi musimy zarządzać. W związku z tym ich liczba wzrasta. Ręczna aktualizacja, np. wersji Java na 10 serwerach, jest jak najbardziej wykonalna. Jednak w przypadku kilkudziesięciu maszyn, wydaje się to zadaniem karkołomnym i, delikatnie mówiąc, nieoptymalnym. Do tego stopień podatności manualnych czynności na błędy wzrasta wraz z liczbą powtórzeń. A brak aktualizacji – powiedzmy łatającej krytyczną podatność – to proszenie się o kłopoty. W przypadku powierzenia obsługi automatom zyskujemy już na wstępie. Po pierwsze, skala przestaje być już tak dużą przeszkodą, zarówno pod względem czasu potrzebnego na utrzymanie infrastruktury, jak i jej jakości i szybkości reakcji. Estymacja w przypadku maszyn także jest trafniejsza i prostsza. Po drugie, wykonywanie wszystkich zmian sprowadza się do edycji wykorzystywanych automatów. To z kolei powoduje, że sytuacja, „kto i czemu coś zmienił”, odchodzi do lamusa.  Oczywiście, aby być tego pewnym w 100%, należałoby zastosować niezmienną (immutable) infrastrukturę. Jednak już samo prawidłowe zarządzanie uprawnieniami zapewnia wysoki poziom spójności. Przy okazji zyskaliśmy także pełne wersjonowanie i audytowalność zmian. A świadomość, że żadne zmiany nie wchodzą na serwery bokiem, powoduje, że jedynym prawdziwym źródłem konfiguracji są właśnie nasze automaty. Dzięki temu bardzo upraszcza się procedura tworzenia kopii zapasowych, ponieważ całą konfigurację maszyny możemy bez problemu w dowolnym czasie wykonać ponownie. Jedynym wrażliwym elementem stają się dane. A te skopiować i odtworzyć jest już dużo prościej, niż całe maszyny. To w perspektywie skraca czas potrzebny do odzyskania (recovery) całego systemu i poprawia jego przenoszalność. Możemy dość prosto dzięki temu migrować pomiędzy różnymi dostawcami infrastruktury. Ostatnim, chociaż nie mniej istotnym plusem zarządzania infrastrukturą za pomocą kodu, jest poprawa jej czytelności. Aby dowiedzieć się, przykładowo, jakie porty są otwarte na firewallu, nie muszę przeczesywać serwerów – wystarczy zajrzeć do odpowiedniego miejsca w repozytorium. Podsumowując, zalety są takie:

  • większa prostota i jakość utrzymania,
  • hermetyzacja / enkapsulacja,
  • uproszczenie procedur tworzenia kopii zapasowych,
  • większa przenoszalność,
  • większy stopień czytelności / przejrzystości.

Jak zabrać się do pracy?

Wdrożenie opisywanego podejścia nie jest niestety proste. W przypadku młodego, małego systemu jedyną barierą może być brak kompetencji, ale nic prostszego niż nauka odpowiednich narzędzi (o tym w dalszej części wpisu) nie zaproponuję. Kłopoty zaczynają się natomiast, kiedy zabieramy się za automatyzację ogromnych, żyjących kilka, kilkanaście lat systemów. W tym przypadku złożoność oraz niespójność infrastruktury będzie balastem, którego trzeba się jak najszybciej pozbyć. Jeżeli ma się to udać, należy w pierwszej kolejności wszystko uprościć. Utrzymywanie trzech wersji MySQL, trzech PosgreSQL, a do tego jeszcze dwóch baz Oracle nie ułatwi ich automatyzacji. Nie inaczej jest w przypadku serwerów aplikacji. Przygotowanie skryptów deploymentowych dla jednego typu zajmuje dużo mniej czasu niż dla pięciu różnych. W dużej mierze to właśnie to, jak bardzo pilnowaliśmy porządku do tej pory, będzie miało wpływ na pracochłonność i sukces automatyzacji. Poziom złożoności skryptów wzrasta, jeżeli w systemie brakuje konwencji i nawet najmniejsze elementy (jak choćby nazwy użytkowników aplikacyjnych) trzeba konfigurować.

Narzędzia

Popularność opisywania infrastruktury za pomocą kodu powoduje, że kolejne narzędzia pojawiają się jak grzyby po deszczu. Niemożliwością byłoby opisanie ich wszystkich, jednak skupię się na tych, które są według mnie najważniejsze. Zacznijmy „od dołu”, czyli od definicji hypervisora, maszyn wirtualnych czy infrastruktury chmurowej. Dwa najpopularniejsze narzędzia to Terraform i CloudFormation (ten drugi wspiera tylko AWS). Do przygotowania obrazów, które później posłużą do utworzenia maszyn wirtualnych wykorzystuje się Packera. W przypadku konfiguracji systemu operacyjnego i realizacji wdrożeń prym wiedzie Ansible. Ma on świetną krzywą uczenia i zdecydowanie najprostszą architekturę, która nie wymaga instalowania niczego na zarządzanych instancjach (agentless). Na podium znajdują się także Puppet i Chef. Inne podejście polega na zastosowaniu konteneryzacji. Tutaj technologie takie, jak Docker czy Kubernetes zdecydowanie nie mogą zostać pominięte.

Stosujesz podejście „infrastruktura jako kod”? A może chcesz polecić jakieś świetne narzędzie? Zapraszam do dyskusji w komentarzach!

Dodaj komentarz

avatar
  Subscribe  
Powiadom o