Czym jest infrastruktura jako kod (i dlaczego ręczne serwery się nie skalują)?
Każda infrastruktura zaczyna się tak samo: ktoś loguje się do konsoli chmury, przeklikuje się przez kilka formularzy i uruchamia serwer. Działa. Pół roku później ten serwer trzeba odtworzyć – po awarii albo żeby postawić identyczne środowisko stagingowe – i nikt nie pamięta dokładnie wszystkich ustawień wyklikanych za pierwszym razem. Infrastruktura jako kod istnieje po to, żeby taki scenariusz stał się niemożliwy.
Podstawowa idea
Infrastruktura jako kod, w skrócie IaC, oznacza, że serwery, sieci, bazy danych i inne zasoby chmurowe są zdefiniowane w plikach konfiguracyjnych – przechowywanych w systemie kontroli wersji, tak samo jak kod aplikacji – zamiast być konfigurowane ręcznie w konsoli webowej. Zamiast klikać „utwórz instancję” i wybierać ustawienia z list rozwijanych, piszecie plik dokładnie opisujący, co ma istnieć, a narzędzie odczytuje ten plik i dostosowuje do niego rzeczywistą infrastrukturę.
Najpopularniejszym narzędziem do tego celu jest Terraform, który działa u wszystkich głównych dostawców chmury w oparciu o to samo podejście; każda z dużych chmur ma też własną natywną opcję (AWS CloudFormation, szablony Azure Resource Manager). Podstawowa zasada jest taka sama niezależnie od narzędzia: źródłem prawdy jest plik, a nie stan, który akurat istnieje w konsoli.
Dlaczego to ważniejsze, niż się wydaje
- Powtarzalność. Potrzebujecie identycznego środowiska stagingowego albo odtworzenia produkcji po awarii? Uruchamiacie tę samą konfigurację jeszcze raz. To nie nadzieja, że pamiętaliście o każdym ustawieniu – to gwarancja wynikająca z samej definicji.
- Code review dla zmian w infrastrukturze. Zmiana reguły firewalla czy rozmiaru bazy danych staje się pull requestem, który ktoś z zespołu przegląda przed zastosowaniem – tak samo jak zmiana w kodzie aplikacji – a nie kliknięciem w konsoli, którego nikt inny nie widział.
- Prawdziwa ścieżka audytu. System kontroli wersji pokazuje dokładnie, co się zmieniło, kiedy i kto to zmienił. Pytanie „dlaczego ta grupa zabezpieczeń jest otwarta na cały internet?” rozwiązuje git blame, a nie wykopaliska archeologiczne.
- Wykrywanie dryfu konfiguracji. Narzędzia IaC potrafią porównać plik konfiguracyjny z tym, co faktycznie działa, i oznaczyć różnice – wyłapując ręczną „szybką poprawkę”, którą ktoś wprowadził bezpośrednio w konsoli i która nigdy nie trafiła z powrotem do plików, a w przeciwnym razie zostałaby po cichu nadpisana albo, co gorsza, coraz bardziej rozjeżdżałaby się z resztą.
Od czego zespoły zwykle zaczynają
Nikt nie opisuje całej infrastruktury w Terraformie pierwszego dnia – i nie ma w tym nic złego. Częstą, rozsądną ścieżką jest rozpoczęcie od elementów, których utrata byłaby bolesna albo których ręczne odtworzenie trwa długo – konfiguracji sieci, bazy danych, głównych zasobów obliczeniowych – i stopniowe rozszerzanie zakresu, w miarę jak pojawiają się nowe problemy. Celem nie jest dosłownie zerowe korzystanie z konsoli; chodzi o to, by zasoby, których naprawdę nie możecie stracić albo które musicie niezawodnie odtwarzać, były zdefiniowane w pliku, a nie istniały wyłącznie w czyjejś pamięci o tym, co zostało wyklikane.
Pułapka, na którą trzeba uważać
Najczęstszą przyczyną porażki we wdrażaniu IaC nie są narzędzia, tylko połowiczne wdrożenie, które po cichu gnije. Zespół pisze w Terraformie konfigurację początkową, potem w trakcie incydentu wprowadza pilne poprawki bezpośrednio w konsoli (co w danej chwili często jest słuszną decyzją) i nigdy nie wraca, by odzwierciedlić te zmiany w plikach. Pół roku później pliki opisują infrastrukturę, która nie odpowiada już rzeczywistości, i nikt im w pełni nie ufa – a to dokładnie ten problem, który IaC miało rozwiązać. Trwałość zapewnia dopiero traktowanie zasady „pliki opisują rzeczywistość” jako obowiązującej reguły, a nie pobożnego życzenia.
Konfigurowanie infrastruktury w ten sposób od samego początku to standard w pracach z zakresu chmury i DevOps, które realizujemy w Burncode – dzięki temu odtworzenie środowiska, jego skalowanie czy przekazanie go innemu inżynierowi to rutynowe, bezstresowe zadanie, a nie zgadywanka.