#infrastruktura jako kod

Infrastruktura jako kod to sposób budowania środowisk informatycznych, w którym serwery, sieci, dyski i uprawnienia opisuje się w plikach tekstowych, a narzędzie tworzy je na podstawie tego opisu. Zamiast klikać w panelu dostawcy, zapisuje się, jak środowisko ma wyglądać, i uruchamia program, który doprowadza je do tego stanu.

Opis stanu zamiast listy czynności

Kluczowa jest tu forma opisu. Skrypt instalacyjny wymienia czynności do wykonania po kolei: zainstaluj, skopiuj, uruchom. Opis deklaratywny podaje wynik: trzy serwery tej wielkości, w tej sieci, z takim dyskiem.

Różnica jest taka jak między przepisem kucharskim a zamówieniem w restauracji. Przepis trzeba wykonać od początku i wykonanie go dwa razy daje dwie porcje. Zamówienie opisuje, co ma stać na stole, więc złożenie go po raz drugi, gdy danie już stoi, nie zmienia niczego.

Ta właściwość ma własną nazwę i to na niej stoi całe podejście: uruchomienie narzędzia na środowisku zgodnym z opisem nie robi nic. Uruchomienie go na środowisku niekompletnym uzupełnia brakujące elementy. Dzięki temu ten sam plik służy do zbudowania środowiska od zera, do naprawienia go po zmianach i do sprawdzenia, czy jeszcze się zgadza.

Jak to działa w praktyce

Narzędzie prowadzi trzy rzeczy naraz. Pierwszą jest opis, czyli pliki pisane przez człowieka. Drugą jest rzeczywistość, czyli to, co faktycznie stoi u dostawcy. Trzecią, najmniej oczywistą, jest zapis stanu: wewnętrzna notatka narzędzia o tym, które zasoby utworzyło i pod jakimi identyfikatorami.

Zanim cokolwiek się zmieni, narzędzie zestawia te trzy rzeczy i wypisuje plan: co utworzy, co zmieni, a co skasuje. Czytanie tego planu jest najważniejszą czynnością w całym procesie, bo to jedyny moment, w którym widać, że drobna poprawka w pliku pociąga za sobą skasowanie i odtworzenie bazy danych.

Pliki leżą w repozytorium razem z historią zmian, więc każda modyfikacja środowiska ma autora, datę i uzasadnienie. Odtworzenie po awarii przestaje być rekonstrukcją z pamięci, a środowisko testowe da się postawić z tego samego opisu i porównać z produkcyjnym.

Czym to nie jest

Podejście to bywa mylone z automatyzacją instalacji na serwerach, czyli z narzędziami do zarządzania konfiguracją systemu. Granica przebiega tam, gdzie kończy się sprzęt, a zaczyna jego zawartość.

Infrastruktura jako kod odpowiada za istnienie zasobów: maszyn, sieci, dysków, reguł dostępu. Zarządzanie konfiguracją odpowiada za to, co jest w środku maszyny: pakiety, pliki, usługi. Oba podejścia często występują razem i oba używają plików, ale odpowiadają na inne pytanie.

Na co uważać

Całość opiera się na jednym założeniu, które łatwo naruszyć: opis ma być jedynym źródłem prawdy. Wystarczy, że ktoś dokona zmiany ręcznie w panelu dostawcy, a opis przestaje odpowiadać rzeczywistości, przy czym nic o tym nie informuje aż do najbliższego uruchomienia narzędzia. Wtedy zmiana zostaje cofnięta jako niezgodna z deklaracją albo, w gorszym wariancie, zasób utworzony ręcznie zostaje pominięty, bo narzędzie nigdy o nim nie wiedziało.

Druga pułapka dotyczy zapisu stanu. Ten plik zawiera identyfikatory zasobów, a czasem także wartości, które powinny pozostać tajne. Trzymany na komputerze jednej osoby blokuje pracę zespołu i ginie razem z komputerem, dlatego przenosi się go do wspólnego, zabezpieczonego miejsca z blokadą jednoczesnych zapisów.

Trzecia to sekrety. Hasła i klucze nie mają czego szukać w plikach opisu, bo repozytorium pamięta wszystko, co kiedykolwiek w nim było, także usunięte. Sekrety trzyma się w osobnym magazynie, a w opisie zostaje odwołanie do nich.

Komu to się nie opłaci

Środowisko zbudowane jednorazowo i stojące potem latami bez zmian nie odda tego, co kosztuje nauka narzędzia oraz utrzymanie opisu. Podobnie wygląda to przy pojedynczym serwerze, gdzie cały opis mieści się na jednej kartce, a każda zmiana i tak wymaga rozmowy z jedną osobą. Podejście zaczyna zarabiać na siebie wtedy, gdy środowisk jest kilka, muszą być do siebie podobne, a zmiany wprowadza więcej niż jedna osoba.