Tekst jest dla firmy, która zastanawia się, kiedy wdrożyć Terraform: ma już chmurę, słyszała, że "powinno się to trzymać w kodzie", i chce wiedzieć, co z tego wychodzi po roku.
Odpowiedź na pytanie, kiedy wdrożyć Terraform, sprowadza się do dwóch liczb: ile macie maszyn w chmurze i ile osób ma dostęp administracyjny. Terraform zapisuje kształt środowiska chmurowego w plikach w repozytorium, więc na pytanie, kto i kiedy to zmienił, odpowiada historia zmian, a nie pamięć administratora. Daje odtworzenie środowiska poleceniem, widoczną historię i wykrycie ręcznych zmian w panelu. Przy jednej maszynie jest kosztem bez zwrotu. Próg zwrotu to drugie środowisko albo druga osoba z dostępem administracyjnym.
Opis środowiska w kodzie brzmi jak temat dla programistów, a rozstrzyga się na pytaniu, ile kosztuje Was jeden dzień zgadywania po cudzej zmianie. Piszemy dla firmy, która ma już chmurę i słyszała, że powinno się to trzymać w kodzie. Niżej dwie decyzje: czy przekroczyliście próg opłacalności i czy opis ma powstać przed kolejną zmianą, czy po niej.
Awaria w środowisku chmurowym rzadko zaczyna się od pytania „co się zepsuło”. Zaczyna się od pytania, co się zmieniło, bo wczoraj to samo działało.
Panel dostawcy ma dziennik zdarzeń i ten dziennik pokaże, że o 23:40 ktoś zmodyfikował regułę w grupie zabezpieczeń. Nie pokaże, po co. Nie pokaże, czy zmiana była tymczasowa, czy docelowa, ani czy wolno ją cofnąć. Dziennik odpowie też na pytanie, kto, ale tylko przez trzydzieści albo dziewięćdziesiąt dni, zależnie od dostawcy i planu, a potem historia po prostu znika.
Koszt braku odpowiedzi jest niewidoczny w kosztorysie, bo rozkłada się na kilkanaście drobnych sytuacji w roku. Reguła otwarta „na chwilę” zostaje na rok, bo nikt nie ma pewności, co od niej zależy. Maszyna testowa pracuje przez kwartał, bo nikt nie wie, czy ktoś jej nie używa. Migracja stoi trzy dni, bo trzeba najpierw ustalić, jak środowisko jest naprawdę zbudowane.
Terraform nie zabiera nikomu prawa do złej zmiany. Zabiera możliwość wprowadzenia jej po cichu.
To jest cała różnica i warto ją nazwać wprost, zanim padnie pierwsze zdanie o automatyzacji.
Na budowie działa to od dawna i nikt tego nie kwestionuje. Budynek sam z siebie nie mówi, kto przesunął ścianę działową ani czy wolno ją cofnąć, bo ściana stoi i tyle. Od tego jest dziennik budowy: każdy wpis ma datę, autora i podpis, a kierownik czyta go, zanim cokolwiek zburzy. Terraform jest dziennikiem budowy dla środowiska w chmurze, z tą jedną przewagą, że dziennika nie prowadzi się tu z pamięci, bo wpis jest jednocześnie poleceniem, które wykonało zmianę.
Środowisko opisane kodem ma więc jedno źródło prawdy, historię z autorem i datą przy każdej linii oraz miejsce, w którym zmianę widać przed wykonaniem. Środowisko klikane ma tyle wersji prawdy, ile osób ma dostęp.
Zacznijmy od zdania, którego nie usłyszycie od nikogo, kto sprzedaje wdrożenia infrastruktury jako kodu.
Przy jednej maszynie w chmurze Terraform jest kosztem bez zwrotu. Opis takiego środowiska zajmie kilka godzin, a potem będzie wymagał, żeby każda zmiana szła przez repozytorium, przegląd i wykonanie kodu. Zysk jest zerowy, bo jedną maszynę odtwarza się z panelu w kwadrans, a historię zmian ma się w głowie, skoro robi je jedna osoba. Firma płaci wtedy za dyscyplinę, której nie potrzebuje, i zwykle porzuca ją po trzecim „to tylko szybka poprawka”.
Zwrot pojawia się wtedy, gdy zachodzi którykolwiek z czterech warunków:
Mogę Ci jakoś pomóc?
Odradzamy w trzech układach.
Pierwsze tygodnie po wdrożeniu są wolniejsze niż praca w panelu i mówimy o tym przed podpisaniem, a nie po. Zmiana, którą klikało się w minutę, zajmuje kwadrans, bo trzeba ją opisać, obejrzeć plan i zatwierdzić. Rachunek odwraca się przy kolejnym środowisku, kolejnym audycie i pierwszej pomyłce, którą trzeba cofnąć.
Sprzedaje się to jako narzędzie porządku i to jest prawda, ale porządek dotyczy zapisu, a nie treści decyzji. Sieć zaprojektowana źle, opisana w kodzie, jest dalej siecią zaprojektowaną źle. Różnica polega na tym, że teraz widać, kto ją taką zrobił i którego dnia.
Trzy złudzenia rozwiewamy na pierwszym spotkaniu.
Kod nie jest kopią zapasową. Odtworzy maszynę, sieć, reguły i uprawnienia, czyli kształt środowiska. Nie odtworzy zawartości bazy, plików na dysku ani skrzynek pocztowych. Firma, która skasuje dane i uruchomi odtworzenie z kodu, dostanie sprawne, puste środowisko w kwadrans. Kopie są osobną warstwą i osobną usługą, którą opisujemy przy backupie danych firmy .
Kod nie zastępuje projektu. Podział na podsieci, model uprawnień i to, co w ogóle ma być dostępne z internetu, są decyzjami, które podejmuje się przed pierwszą linią konfiguracji. Dlaczego ten podział ma znaczenie także w małej firmie, opisaliśmy przy segmentacji sieci .
Kod nie jest zabezpieczeniem przed pomyłką. Polecenie wykonujące zmiany zrobi rzecz błędną tak samo sprawnie jak słuszną, a przy dobrze napisanych modułach zrobi ją od razu we wszystkich środowiskach. Skala pomyłki rośnie razem z jakością automatyzacji i to jest cena, którą się płaci. Hamulcem jest przegląd planu przez drugiego człowieka, nie samo narzędzie.
Zostaje rzecz, którą Terraform daje naprawdę i której nie da się kupić inaczej. Odpowiedź na pytanie o autora i datę każdej linii konfiguracji, po roku i po trzech latach, także wtedy, gdy autor już z Wami nie pracuje.
Terraform ma cztery miejsca, w których firmy tracą czas i pieniądze, i wszystkie cztery są rozstrzygane w pierwszym tygodniu pracy. Później też da się je poprawić, tylko drożej.
Plik stanu. Terraform trzyma mapę między kodem a tym, co naprawdę stoi u dostawcy, w osobnym pliku stanu. Jest to spis inwentarza z numerami: bez niego widzicie w magazynie dziesięć identycznych regałów i nie wiecie, który z nich opisuje która pozycja w dokumentacji. Ten plik jest więc ważniejszy niż sam kod, bo kod da się odtworzyć z repozytorium, a przypisanie wpisów do istniejących zasobów trzeba by odbudować ręcznie, sztuka po sztuce.
Stan na laptopie jednej osoby kończy się dokładnie tak, jak to brzmi, a stan bez blokady kończy się dwiema osobami wykonującymi zmiany w tej samej minucie i uszkodzonym zapisem. Idzie do zdalnego magazynu z wersjonowaniem i blokadą, i to jest pierwsza rzecz, którą stawiamy.
Jest przy tym szczegół, który zaskakuje nawet zespoły pracujące z Terraformem od roku. Plik stanu przechowuje wartości w postaci jawnej, więc hasło początkowe bazy danych albo klucz wygenerowany przy tworzeniu zasobu leżą tam czytelne, nawet jeśli w kodzie ich nie ma.
Magazyn stanu chroni się więc z szyfrowaniem i wąską listą dostępu, jak sejf z sekretami, a nie jak katalog na pliki techniczne.
Mogę Ci jakoś pomóc?
źródło: magnific.comPowstaje zawsze, bo ktoś kiedyś kliknie w panelu, i to jest w porządku, o ile wychodzi na jaw w ciągu doby. Kłopot zaczyna się przy zasobach, które zmienia sam dostawca: etykiety, wersje obrazów, automatycznie dokładane reguły. Plan pokazuje wtedy różnice, których nikt nie wprowadził, ludzie przestają go czytać, a zignorowana lista różnic przestaje pełnić swoją funkcję. Obejściem jest wskazanie pojedynczych pól, których narzędzie ma nie pilnować, a nie wyciszanie całych zasobów.
Do repozytorium nie trafiają, i tu zgoda jest powszechna. Rzadziej pamięta się o dwóch pozostałych drogach wycieku: o stanie, opisanym wyżej, i o dziennikach z uruchomienia zmian, w których wartość potrafi wylądować przy włączonym trybie szczegółowym. Klucze trzymamy w menedżerze sekretów dostawcy albo w Vault, a potok pobiera je na czas wykonania.
Ten sam kod uruchomiony po pół roku, bez przypiętych wersji wtyczek dostawcy, potrafi dać inny wynik niż w dniu pisania. Gorsza odmiana tego problemu wygląda tak: aktualizacja wtyczki zmienia sposób obsługi jednego pola i zamiast zmiany zasobu plan proponuje jego skasowanie i utworzenie od nowa. Dla bazy danych albo adresu IP oznacza to przestój i nowy adres w połowie środowiska. Przypięte wersje i plik blokady wersji są obowiązkowe, a czytanie planu przed zatwierdzeniem jest obowiązkowe podwójnie.
Ostatnie zdanie tej sekcji jest krótkie i praktyczne. Plan czyta człowiek, który wie, co miało się zmienić.
Najczęstszy scenariusz nie zaczyna się od pustej chmury. Zaczyna się od środowiska, które ktoś zbudował klikaniem, które działa i którego nikt nie chce ruszać. Właśnie takie środowisko opisujemy najczęściej, a zasada nadrzędna brzmi: opis nie jest okazją do przebudowy. Poprawki architektury idą osobną ścieżką, po opisie, żeby przy pierwszym problemie było wiadomo, czy zawinił opis, czy zmiana.
źródło: magnific.comRama czasowa dla środowiska o wielkości typowej dla firmy na kilkanaście stanowisk, czyli jednej subskrypcji z kilkoma maszynami, siecią i zestawem uprawnień, to około dwóch dni pracy, tyle samo, ile stoi w wycenie na stronie usługi o Terraformie . Dwa dni pracy nie oznaczają dwóch dni kalendarzowych, bo między krokiem trzecim a szóstym potrzebujemy zwykle Waszych decyzji dostępowych.
Ta część interesuje właścicieli firm bardziej niż cała reszta, więc opisujemy ją pytaniami, które padają na spotkaniach.
Skąd w ogóle wiadomo, że ktoś coś kliknął? Z harmonogramu uruchamiamy sam plan, bez wykonania, i porównujemy kod z rzeczywistością. Pusty wynik znaczy, że nikt nic nie ruszył. Każda różnica staje się zgłoszeniem z nazwą zasobu i polem, które się rozjechało. To działa także wtedy, gdy zmiana została wprowadzona z konta, którego dziennik zdarzeń u dostawcy już nie pokazuje.
Mogę Ci jakoś pomóc?
Co robimy z wykrytą zmianą? Są trzy drogi i wybór należy do Was, a nie do nas:
Rekomendację podajemy przy zgłoszeniu, żeby decyzja zajmowała minutę, a nie spotkanie.
Czy to znaczy, że nie wolno klikać w panelu? Wolno, w awarii. Dostęp awaryjny istnieje właśnie po to i nikt o drugiej w nocy nie będzie czekał na przegląd kodu. Zasada brzmi: kliknij, a rano zgłoś, co zrobiłeś. Zmiana wprowadzona ręcznie i niezgłoszona wróci przy najbliższym wykonaniu kodu, zwykle w najgorszym momencie.
Czego ten mechanizm nie zobaczy? Wszystkiego, co jest poza zakresem opisu: zawartości dysków, konfiguracji wewnątrz systemu operacyjnego, danych w bazie i zasobów świadomie zostawionych poza kodem. Do tego służy osobna warstwa, czyli monitoring infrastruktury , i te dwie rzeczy się uzupełniają, zamiast zastępować.
Porównanie kodu z rzeczywistością jest tanie i to jest jego najlepsza cecha. Kosztuje kilka minut pracy maszyny na dobę i nie wymaga niczyjej uwagi, dopóki nic się nie rozjedzie.
Wdrożenie jest krótkie, utrzymanie trwa. Terraform w firmie bez informatyka na etacie żyje dokładnie tak długo, jak długo ktoś do niego zagląda. Kod opisujący infrastrukturę psuje się inaczej niż serwer: nic nie gaśnie, nic nie alarmuje, po prostu z każdym tygodniem coraz mniej odpowiada rzeczywistości. Po roku bez opieki bywa dokumentacją historyczną.
Pięć rzeczy, które robimy w cyklu rocznym:
Jest jeden objaw, który traktujemy jak alarm. Jeżeli w ciągu kwartału do repozytorium nie trafiła żadna zmiana, a środowisko ewidentnie żyje, to znaczy, że praca wróciła do panelu i kod właśnie stał się fikcją. Wtedy dzwonimy i pytamy, co poszło nie tak z procesem, bo problem nie jest wtedy techniczny.
Werdykt na początek, bo reszta sekcji jest jego uzasadnieniem. Domyślnie bierzemy Terraforma, OpenTofu proponujemy tam, gdzie tematem rozmowy jest licencja, a narzędzie natywne dostawcy zostawiamy firmom z jedną chmurą i własnym administratorem, który je zna.
Zanim przejdziemy do tabeli, trzeba wyjaśnić, o co w tym sporze o licencję w ogóle chodzi, bo w rozmowach pojawia się jako straszak, a dotyczy prawie wyłącznie firm, które sprzedają narzędzia.
W sierpniu 2023 roku Terraform przestał być programem na licencji otwartej i przeszedł na Business Source License. Nazwa brzmi groźnie, a zapis mówi rzecz dość wąską: nie wolno zbudować na tym kodzie produktu konkurencyjnego wobec komercyjnej oferty właściciela. Jest to ograniczenie skierowane w dostawców platform, nie w firmę, która opisuje własne serwery. Do tego każde wydanie po czterech latach od publikacji samo wraca na starą licencję otwartą. Prawa do narzędzia należą dziś do IBM, który przejął jego twórcę.
Praktyczny wniosek dla firmy na kilkanaście stanowisk jest więc krótki i idzie pod prąd temu, co słychać na konferencjach. Wasze użycie było i pozostaje dozwolone. Licencja przestaje być tematem technicznym, a staje się tematem zapisu w umowie. Liczy się nie to, czy Wam wolno, tylko czy Wasz klient albo regulamin zamówienia publicznego wymaga oprogramowania z licencją uznaną za otwartą. Jeśli tak, odpowiedzią jest OpenTofu , rozwijany pod Linux Foundation na tej samej licencji, którą Terraform miał wcześniej.
Narzędzie | Kiedy je bierzemy | Co trzeba o nim wiedzieć |
|---|---|---|
Terraform | domyślnie, w każdym środowisku, które prowadzimy | wygrywa liczbą ludzi, którzy go znają, i liczbą gotowych modułów, czego nie ma żadna alternatywa |
OpenTofu | gdy firma ma zapisany wymóg oprogramowania z licencją otwartą, na przykład w polityce zamówień albo w umowie z klientem publicznym | odgałęzienie ostatniej otwartej wersji Terraforma, rozwijane pod Linux Foundation na licencji MPL 2.0, robi to samo i tym samym językiem, a decyzja jest w praktyce odwracalna, choć bywa przedstawiana jako rozstrzygnięcie na lata |
Narzędzia natywne dostawcy (CloudFormation, Bicep) | firma stoi na jednej chmurze, ma tam wszystko i ma człowieka, który to narzędzie zna, więc nadkładanie warstwy niczego nie kupuje | przy dwóch dostawcach albo przy części lokalnej obok chmurowej wracamy do Terraforma, bo dwa języki opisu oznaczają dwa zestawy pomyłek |
Pulumi | odradzamy firmom bez własnego programisty | opis infrastruktury w zwykłym języku programowania zamienia elastyczność w kod, którego nie ma kto utrzymać, a rachunek przychodzi przy pierwszej zmianie po odejściu autora |
Ansible | obok Terraforma, nie zamiast niego | Terraform tworzy i zmienia zasoby u dostawcy, czyli sieci, maszyny i uprawnienia, a Ansible konfiguruje wnętrze systemu, który na tej maszynie już stoi |
Pierwszy wiersz mówi o ciągłości, a nie o technice, i dla firmy bez informatyka na etacie jest to cała treść tej tabeli. Kod, który potrafi przeczytać dowolny administrator z rynku, jest wart więcej niż kod elegancki, przy którym zależycie od jednej osoby.
Zestawienie Ansible obok Terraforma jest przy tym nieporozumieniem, które kosztuje najwięcej czasu na spotkaniach. W środowiskach, które prowadzimy, oba narzędzia pracują obok siebie, a nie zamiast siebie.
Kryterium, które rozstrzyga najczęściej, jest przy tym nietechniczne. Pytamy, kto będzie utrzymywał ten kod za dwa lata, i wybieramy narzędzie, na które ta odpowiedź istnieje.
Samo narzędzie nie ma opłaty licencyjnej i przy skali małej firmy nie ma jej też nic, co jest wokół niego niezbędne. Magazyn stanu to zwykłe miejsce na pliki u Waszego dostawcy chmury, liczone w złotówkach miesięcznie, a potok wykonujący zmiany mieści się w limitach, które macie już opłacone razem z repozytorium.
Producent prowadzi też własną usługę hostowaną i tu trzeba powiedzieć rzecz, która psuje wygodną narrację o oszczędzaniu.
Usługa ta ma warstwę bezpłatną obejmującą do 500 zarządzanych zasobów, czyli wielokrotnie więcej, niż ma środowisko firmy na kilkanaście stanowisk. Dla Was jest więc darmowa tak samo jak własny magazyn stanu, a płacić zaczyna się dopiero powyżej tego progu, od stawki liczonej za zasób miesięcznie. Wybór między nią a magazynem u dostawcy chmury nie jest zatem wyborem finansowym i nie należy go tak przedstawiać. Jest wyborem o to, gdzie leży stan i kto ma do niego dostęp, a przy stanie zawierającym hasła w postaci jawnej jest to pytanie o bezpieczeństwo, nie o rachunek. Uwaga na jedną datę: dawny bezpłatny plan tej usługi zakończył się 31 marca 2026, a organizacje zostały przeniesione na obecną warstwę bezpłatną. Jeśli ktoś u Was zakładał konto wcześniej, warunki mógł mieć inne.
Nasza praca jest przewidywalna i stoi jawnie w cenniku. Opisanie istniejącego środowiska zaczyna się od 3 900 zł netto jednorazowo, co odpowiada około dwóm dniom pracy, stan cennika na 30 lipca 2026. Bieżące prowadzenie mieści się w opiece nad chmurą, od 590 zł netto miesięcznie za subskrypcję plus 250 zł netto za maszynę wirtualną, stan na 31 lipca 2026. Warunki i zakres opisuje kategoria administracji chmurą , a kwota z tej strony jest liczona z konfiguracji, więc w razie różnicy obowiązuje strona, nie ten wpis.
Sześć pozycji, które w rozmowach o budżecie giną, a pojawiają się na rachunkach:
Odnowienia licencji tu nie ma i to jest realna różnica wobec większości narzędzi, o których piszemy w tej serii. Rachunek jest jednorazowy przy wejściu, a potem opłacacie utrzymanie, a nie prawo do używania.
Repozytorium jest Wasze od pierwszego dnia, nie od końca projektu. Konta u dostawcy chmury też są Wasze, a my pracujemy na dostępie imiennym z rolą ograniczoną do tego, co robimy, nadanym na czas umowy i odbieranym po jej zakończeniu. Nie zakładamy własnego konta technicznego, do którego tylko my znamy hasło.
Po naszej stronie leży pisanie kodu, przygotowanie planu, wykonanie zmiany po zatwierdzeniu, zgłaszanie różnic wykrytych automatem, kwartalna aktualizacja wtyczek i coroczny test odtworzenia.
Po Waszej stronie zostają trzy rzeczy i celowo nie chcemy ich przejmować. Decyzja architektoniczna, bo to Wasze pieniądze i Wasze ryzyko. Zatwierdzenie zmiany, która zmienia koszt albo dostęp, bo podpis pod taką zmianą ma mieć człowiek z firmy. Oraz lista osób, które mogą zatwierdzać, aktualizowana wtedy, gdy ktoś przychodzi albo odchodzi.
Rzecz, o którą warto pytać każdego dostawcę takiej usługi, brzmi: co zostaje, gdy się rozstaniemy.
U nas zostaje repozytorium z kodem i całą historią, magazyn stanu w Waszej subskrypcji, opis uruchomienia napisany tak, żeby wykonał go inny administrator, i procedura odtworzenia sprawdzona co najmniej raz. Nie zostaje zależność od naszego narzędzia, bo takiego nie ma, ani konto, którego nie umiecie odebrać. Kod pisany pod jedną firmę serwisową jest w tej branży realnym problemem i pytanie o to zadajecie nam tak samo jak każdemu innemu.
Pracujemy zdalnie, a przy odbiorze i przy pierwszym teście odtworzenia spotykamy się na miejscu, jeśli tego chcecie.
Osiem błędów, które widujemy najczęściej. Każdy kosztuje więcej niż praca, której wymagało jego uniknięcie.
Błąd | Czym się kończy |
|---|---|
Plik stanu na laptopie albo w repozytorium | utrata laptopa oznacza środowisko, którego kod już nie rozpoznaje, i import wszystkiego od nowa, a stan wrzucony do repozytorium to hasła w historii, których nie da się wymazać bez przepisania całej historii |
Jeden stan dla testu i produkcji | pomyłka w środowisku testowym przebudowuje produkcję, zwykle w godzinach pracy, a rozdzielenie kosztuje godzinę na starcie i nie kosztuje nic później |
Wykonywanie zmian z laptopa administratora | ślad po zmianie zostaje w jednej głowie, a klucz z pełnymi uprawnieniami leży na dysku, który wychodzi z biura codziennie |
Wersje wtyczek nieprzypięte | ten sam kod uruchomiony po kwartale daje inny wynik, a aktualizacja potrafi zaproponować skasowanie i utworzenie zasobu zamiast jego zmiany, co przy bazie danych oznacza przestój |
Plan czytany jak formalność | wynik przewijany do końca i zatwierdzany odruchowo jest wart tyle, co brak planu, bo linia mówiąca o skasowaniu zasobu wygląda niepozornie |
Moduł z internetu wzięty bez przeczytania | tworzy zasoby, których nikt nie zamawiał, podnosi rachunek u dostawcy i wprowadza do Waszego środowiska kod obcego autora, aktualizowany bez Waszej wiedzy |
Opisana część środowiska, bez zapisanej granicy zakresu | po pół roku nikt nie wie, co jest w kodzie, a co poza nim, więc kod przestaje być źródłem prawdy i zaczyna być jedną z wersji |
Wykonanie bez zatwierdzenia człowieka | literówka rozchodzi się na wszystkie środowiska w minutę, bo automatyzacja działa dokładnie tak szybko, jak obiecywała |
Dwa wiersze zasługują na rozwinięcie, bo brzmią jak drobiazgi.
Wspólny stan dla testu i produkcji jest najczęstszym skrótem w małych środowiskach i wygląda niewinnie, dopóki ktoś nie zmieni zmiennej i nie zatwierdzi planu, który dotyczy obu naraz. Zabezpieczeniem jest osobny stan, osobne konto dostępowe i osobna ścieżka zatwierdzania. Kosztuje to jedną dodatkową konfigurację i nic poza tym.
Moduł z internetu jest drugim takim miejscem. Nie chodzi o to, że cudzy kod jest zły, bo zwykle jest lepszy niż napisany naprędce. Chodzi o to, że wchodzi do Waszej infrastruktury z prawem tworzenia zasobów, a jego kolejne wydanie napisze ktoś, kogo nie znacie. Wersję przypinamy, kod czytamy, a moduły z zasobami płatnymi wymagają osobnej decyzji o koszcie, nie samej o funkcji.
Dziewięć rzeczy, sprawdzalnych po odbiorze, bez ani jednej pozycji w rodzaju „wsparcie i doradztwo”.
Punkt siódmy jest tym, o który prosimy Was, żebyście pytali także innych dostawców.
Ile trwa opisanie naszego środowiska w Terraformie? Środowisko wielkości jednej subskrypcji z kilkoma maszynami, siecią i uprawnieniami to około dwóch dni pracy. Dni kalendarzowych jest zwykle więcej, bo po drodze potrzebujemy Waszych decyzji o dostępach i o tym, co zostaje poza kodem. Termin podajemy po obejrzeniu środowiska, nie przed.
Czy przy wdrożeniu środowisko będzie niedostępne? Nie. Istniejące zasoby importujemy do stanu bez ich przebudowy, a dowodem poprawności jest plan, który po imporcie nie proponuje żadnej zmiany. Maszyny pracują przez cały czas trwania prac.
Ile kosztuje Terraform i za co właściwie płacimy? Samo narzędzie nie ma opłaty licencyjnej, a magazyn stanu i potok mieszczą się w tym, co macie już opłacone u dostawcy chmury i w repozytorium. Płacicie za pracę: opisanie istniejącego środowiska od 3 900 zł netto jednorazowo, stan cennika na 30 lipca 2026, oraz za utrzymanie w ramach opieki nad chmurą. Odnowień licencji tu nie ma.
Czy Terraform zastępuje kopie zapasowe? Nie i to jest najczęstsze nieporozumienie w tym temacie. Kod odtworzy kształt środowiska, czyli maszyny, sieci i uprawnienia, ale nie odtworzy danych z dysków, baz ani skrzynek. Kopie są osobną warstwą i osobnym kosztem.
Czy musimy mieć u siebie kogoś, kto zna Terraforma? Nie musicie mieć osoby, która pisze kod. Musicie mieć osobę, która potrafi przeczytać plan i zrozumieć, że linia o skasowaniu zasobu znaczy dokładnie to, co znaczy. Uczymy tego przy odbiorze i zajmuje to jedno spotkanie.
Czy Terraform pomaga przy audycie i przy NIS 2? Pomaga w jednym konkretnym miejscu: daje rozliczalność zmian w infrastrukturze, czyli autora, datę i treść każdej modyfikacji, także po latach. Nie jest to spełnienie wymogów dyrektywy, bo te dotyczą procesów, ryzyka i zgłaszania incydentów. Audytorowi pokazujecie jednak historię, a nie oświadczenie.
Czy Terraform w firmie z jedną maszyną w chmurze ma sens? Nie ma i mówimy to wprost, także wtedy, gdy klient przychodzi z gotową decyzją o wdrożeniu. Jedną maszynę odtworzycie z panelu szybciej, niż zdążycie opisać ją kodem. Wróćcie do tematu przy drugim środowisku albo przy drugiej osobie z dostępem administracyjnym.
Kiedy wdrożyć Terraform we własnej firmie? Zacznijcie od sprawdzenia, czy w ogóle przekroczyliście próg opłacalności. Policzcie zasoby w panelu, nie same maszyny, i sprawdźcie, ile osób ma dostęp administracyjny. Jeżeli wyjdzie jedno środowisko, jedna osoba i kilka zasobów, zamknijcie ten temat na rok i wróćcie do niego przy kolejnym projekcie.
Umówcie 30 minut rozmowy o Waszym środowisku i przygotujcie trzy rzeczy: nazwę dostawcy chmury, przybliżoną liczbę zasobów oraz listę osób z dostępem do panelu. Po rozmowie dostajecie pisemny werdykt, czy opis w kodzie się u Was zwróci, wraz z listą zasobów, które weszłyby do kodu, i tych, które zostałyby poza nim.
Pracujemy w całej Polsce, zdalnie i na miejscu. Biuro główne mamy w Gorzowie Wielkopolskim i stamtąd obsługujemy klientów lokalnie .
Mogę Ci jakoś pomóc?
Zestaw zmienia się codziennie, więc przy kolejnej wizycie zobaczysz inny wycinek bloga.
Luka CVE-2026-46817 w module Oracle Payments trafiła do katalogu podatności wykorzystywanych w atakach, prowadzonego przez CISA. Według producenta włamanie nie wymaga loginu ani hasła, a poprawka istnieje od maja 2026 roku. Tekst pokazuje, kogo dotyczy i co zrobić.
Czytaj artykułPodatność CVE-2026-15410 w konsoli zarządzania urządzeniami SonicWall SMA1000 trafiła do katalogu CISA podatności wykorzystywanych w atakach, a na naprawę wyznaczono zaledwie trzy dni. Sprawdź, na czym polega problem, co grozi firmie i o co zapytać dział IT.
Czytaj artykułCISA wpisała lukę w Microsoft SharePoint Server do katalogu podatności potwierdzonych jako wykorzystywane. Atak przebiega przez sieć, bez konta w systemie i bez klikania przez pracownika. Sprawdź, które wersje są zagrożone i jakie poprawki je zamykają.
Czytaj artykułKrótka rozmowa wystarczy, żeby ocenić zakres prac i podać widełki kosztu. Bez zobowiązań.
Klikając „Akceptuję”, zgadzasz się na przechowywanie plików cookie przez UXU w celu poprawy działania strony, analizy i wsparcia działań marketingowych.