Terraform i infrastruktura jako kod Poznań

Dlaczego cztery lokalizacje robią to samo na cztery sposoby

W firmie z centralą w Poznaniu i oddziałami w Wielkopolsce środowisko nie powstaje z jednej decyzji. Pierwszą lokalizację uruchamiał ktoś przy okazji wdrożenia systemu handlowego. Drugą dokładał informatyk pracujący wtedy na pół etatu. Trzecia przyszła razem z przejętą spółką i została podłączona tak, żeby działała do poniedziałku. Czwartą stawiał już inny dostawca, po swojemu, bo poprzedniego nie było jak zapytać.

Każde z tych rozwiązań działa. Problem zaczyna się przy pytaniach, które padają później. Dlaczego reguła w jednym oddziale przepuszcza ruch, którego dwa pozostałe nie przepuszczają. Kto założył konto z pełnymi uprawnieniami w środowisku przejętej spółki. Ile potrwa odtworzenie sieci, jeśli ktoś skasuje ją przez pomyłkę w tygodniu przed kampanią sprzedażową. Na żadne z tych pytań nie odpowiada dokumentacja, ponieważ jej rolę pełnił panel, a ten pokazuje wyłącznie bieżące ustawienia.

Opis w kodzie odwraca tę zależność. Zamiast efektu czyichś kliknięć dostajecie pliki, które da się przeczytać, zestawić z poprzednią wersją i uruchomić jeszcze raz.

Co dzieje się przy otwarciu kolejnego oddziału

Największy zysk widać nie przy pierwszym opisie, tylko przy trzecim otwarciu. Poniżej rozbicie takiego uruchomienia na kroki, razem ze wskazaniem, skąd bierze się konfiguracja i kto faktycznie wykonuje daną czynność.

Krok otwarcia lokalizacji	Skąd bierze się konfiguracja	Kto wykonuje
Sieć i adresacja	moduł lokalizacji, parametr z nazwą oddziału	potok, po zatwierdzeniu planu
Maszyna z aplikacją używaną na miejscu	ten sam opis co w centrali	potok
Role i uprawnienia zespołu oddziału	grupa w katalogu, zakres z modułu	potok
Oznaczenia kosztowe	schemat tagów, numer lokalizacji	potok
Łącze operatora i sprzęt sieciowy	umowa, dostawa, montaż	człowiek, poza kodem
Odbiór i zapis decyzji	historia zmian w repozytorium	osoba odpowiedzialna po Waszej stronie

Dwa ostatnie wiersze są tu najważniejsze, bo pokazują granicę. Kod nie skróci czasu oczekiwania na operatora ani nie zamontuje przełącznika w szafie. Skraca natomiast tę część, która w praktyce zabiera najwięcej godzin i najczęściej kończy się drobną różnicą wobec pozostałych lokalizacji.

Na co idą dwa dni tej pracy

Pierwszy ruch to przeniesienie do kodu tego, co już pracuje. Zasoby wchodzą do stanu bez przebudowy, więc w firmie nic nie gaśnie, a po tym kroku widać wreszcie pełną listę: także pozycje, o których nikt nie pamiętał, i takie, których nikt nie potrafi przypisać do żadnej lokalizacji.

Drugi to wyodrębnienie powtarzalnych elementów. Sieć, maszyna, zestaw ról i schemat oznaczeń kosztowych trafiają do jednego klocka, który przyjmuje kilka wartości na wejściu. Trzeci to wspólny plik stanu, zamknięty blokadą i umieszczony w zabezpieczonym magazynie, bo dwie osoby pracujące tego samego popołudnia potrafią bez niego skasować sobie nawzajem zmiany.

Czwarty dotyczy sekretów. Klucze i hasła wychodzą z plików do menedżera sekretów u dostawcy albo do Vault, ponieważ dostęp zapisany w repozytorium trzeba uznać za dostęp jawny. Ostatni element to potok wykonujący zatwierdzone zmiany, żeby żadna z nich nie startowała z prywatnego komputera.

Kalendarzowo rozkłada się to zwykle na dwa tygodnie, choć samej pracy jest około dwóch dni. Nie potrzebujemy okna serwisowego ani przerwy w pracy biura, bo pierwsze uruchomienie następuje dopiero wtedy, gdy plan zawiera same rzeczy zaplanowane świadomie.

Co daje plan pokazywany przed wykonaniem

To jest element, który najczęściej przekonuje osoby nietechniczne, więc warto go opisać po ludzku. Przed każdą zmianą powstaje lista trzech rodzajów pozycji: co zostanie dodane, co zmienione i co usunięte. Lista dotyczy konkretnych zasobów z nazwami, a nie ogólnego opisu prac.

Dla firmy oznacza to dwie rzeczy. Osoba odpowiedzialna po Waszej stronie zatwierdza konkret, a nie zaufanie, i widzi na przykład, że przy okazji drobnej poprawki miała zniknąć reguła, o której nikt nie wspominał. Po wykonaniu zostaje natomiast ślad: kto zaproponował zmianę, kto ją przyjął i co dokładnie zrobiła. Przy środowisku obsługującym sprzedaż jest to różnica między odtwarzaniem przebiegu zdarzeń z pamięci a odczytaniem go z historii.

Co robimy z częścią stojącą przy magazynie

Rzadko która firma dystrybucyjna trzyma wszystko u dostawcy chmury. Maszyny wirtualne na Proxmoksie w budynku magazynu, sieć i reguły na brzegu opisujemy tym samym zestawem plików, dzięki czemu układ rozpięty między halą a chmurą nie wymaga dwóch osobnych sposobów pracy. W dniu awarii sprowadza się to do jednej procedury zamiast dwóch, a druga zawsze bywa tą, którą opisano gorzej. Sam podział na dwa końce przedstawiliśmy przy chmurze hybrydowej.

Dwie rzeczy zostawiamy poza kodem świadomie: zawartość maszyn oraz same dane. Terraform odtwarza kształt środowiska, a nie to, co w nim leży, więc kopie i próbne odtworzenia prowadzimy jako osobne zadanie. Opisuje je backup danych firmy.

Kiedy odradzamy tę pracę

Gdy w firmie stoi jedno środowisko, od lat nietknięte, a otwarcie kolejnej lokalizacji jest luźnym planem bez daty. Gdy nikt u Was nie zamierza czytać opisu infrastruktury, a jednocześnie nie chcecie oddawać utrzymania na zewnątrz. Gdy budżet na najbliższe półrocze jest już rozdysponowany na sprzęt, bo wtedy lepiej zacząć od kopii i porządnej dokumentacji.

Odradzamy również dopisywanie tej pracy do innego zlecenia jako pozycji dodatkowej. Zapis środowiska wymaga własnych godzin i własnych prób, a robiony przy okazji rozjeżdża się z rzeczywistością w ciągu kilku tygodni. Opis, któremu nie można ufać, szkodzi bardziej niż jego brak, bo ktoś kiedyś podejmie na jego podstawie decyzję.

Bieżące prowadzenie zasobów opisaliśmy przy administracji chmurą, subskrypcję Microsoftu przy obsłudze Azure, a aplikacje uruchamiane na tak opisanych maszynach pakujemy wcześniej zgodnie z tym, co pokazujemy przy konteneryzacji Docker. Zakres ustalimy przez kontakt.

Treść sprawdzona i zaktualizowana: 31 lipca 2026