21 lip 2025·8 min
Terraform i Vagrant: łączenie infrastruktury z procesem dostarczania
Dowiedz się, jak narzędzia Mitchella Hashimoto (Terraform i Vagrant) pomagają zespołom ustandaryzować infrastrukturę i stworzyć powtarzalne procesy dostarczania.
Dowiedz się, jak narzędzia Mitchella Hashimoto (Terraform i Vagrant) pomagają zespołom ustandaryzować infrastrukturę i stworzyć powtarzalne procesy dostarczania.
Powtarzalne dostarczanie to nie tylko wysyłanie kodu. Chodzi o umiejętność pewnej odpowiedzi na pytania: co się zmieni? dlaczego się zmieni? i czy możemy to powtórzyć jutro? Gdy infrastrukturę buduje się ręcznie — albo gdy maszyny deweloperskie dryfują z czasem — dostarczanie staje się zgadywanką: różne środowiska, różne wyniki i wiele „działa na moim laptopie”.
Terraform i Vagrant pozostają istotni, bo redukują tę nieprzewidywalność z dwóch stron: współdzielonej infrastruktury i współdzielonych środowisk deweloperskich.
Terraform opisuje infrastrukturę (zasoby w chmurze, sieci, zarządzane usługi, a czasem nawet konfigurację SaaS) jako kod. Zamiast klikać w konsoli, definiujesz, czego chcesz, przeglądasz plan i stosujesz zmiany konsekwentnie.
Celem nie jest „być fancy”. Chodzi o to, by zmiany infrastruktury były widoczne, możliwe do przeglądu i powtarzalne.
Vagrant tworzy spójne środowiska deweloperskie. Pozwala zespołom uruchamiać tę samą bazową konfigurację — system operacyjny, pakiety i ustawienia — niezależnie od tego, czy pracują na macOS, Windows czy Linux.
Nawet jeśli na co dzień nie używasz maszyn wirtualnych, podstawowa idea Vagranta jest nadal ważna: deweloperzy powinni zaczynać od znanego, działającego środowiska, które odpowiada temu, jak oprogramowanie faktycznie działa.
To praktyczny przewodnik skierowany do osób nietechnicznych, które potrzebują mniej buzzwordów, a więcej jasności. Omówimy:
Na końcu powinieneś móc ocenić, czy Terraform, Vagrant, czy oba pasują do twojego zespołu — i jak je wdrożyć, nie tworząc nowej warstwy złożoności.
Mitchell Hashimoto jest najbardziej znany jako twórca Vagranta i współzałożyciel HashiCorp. Trwały wkład to nie pojedynczy produkt, lecz idea, że narzędzia mogą zakodować przepływ pracy zespołu w coś, co da się współdzielić, przeglądać i powtarzać.
Gdy mówi się „narzędzia są mostem”, chodzi o zamknięcie luki między dwiema grupami, które chcą tego samego rezultatu, ale na co dzień mówią różnymi językami:
Perspektywa Hashimoto — powtarzana w narzędziach HashiCorp — mówi, że most to przepływ pracy widoczny dla wszystkich. Zamiast przekazywać instrukcje przez tickety lub wiedzę tribalną, zespoły zapisują decyzje w plikach konfiguracyjnych, wrzucają je do kontroli wersji i uruchamiają te same polecenia w tej samej kolejności.
Narzędzie staje się sędzią: standaryzuje kroki, rejestruje, co się zmieniło i redukuje kłótnie typu „działa na moim komputerze”.
Wspólne przepływy pracy zamieniają infrastrukturę i środowiska w interfejs podobny do produktu:
Takie ujęcie utrzymuje fokus na dostarczaniu: narzędzia nie służą tylko automatyzacji, ale też uzgodnieniu. Terraform i Vagrant pasują do tego podejścia, bo czynią stan docelowy oczywistym i zachęcają do praktyk (wersjonowanie, przegląd, powtarzalne uruchomienia), które skalują się poza pamięć pojedynczej osoby.
Większość problemów w dostarczaniu nie wynika z „złego kodu”. Wynikają z niedopasowanych środowisk i niewidocznych, ręcznych kroków, których nikt w pełni nie potrafi opisać — aż coś się zepsuje.
Zespoły często zaczynają od działającej konfiguracji, a potem wprowadzają drobne, rozsądne zmiany: upgrade pakietu tu, tweak firewall’a tam, doraźna poprawka na serwerze bo „pilne”. Po tygodniach laptop deva, VM stagingowa i produkcja są lekko różne.
Te różnice objawiają się jako błędy trudne do odtworzenia: testy przechodzą lokalnie, ale zawodzą w CI; staging działa, a produkcja zwraca 500; rollback nie przywraca poprzedniego zachowania, bo system bazowy się zmienił.
Gdy środowiska tworzy się ręcznie, rzeczywisty proces żyje w pamięci tribalnej: które pakiety OS zainstalować, które usługi uruchomić, jakie ustawienia jądra zmienić, które porty otworzyć — i w jakiej kolejności.
Nowi członkowie zespołu tracą dni na składanie „wystarczająco podobnej” maszyny. Seniorzy stają się wąskim gardłem w podstawowych sprawach konfiguracyjnych.
Problemy bywają prozaiczne:
.env lokalnie, a w produkcji pobierane inaczej — deployy zawodzą lub, co gorsza, sekrety wyciekną.Te problemy przekładają się na wolniejsze wdrożenia, dłuższe lead time’y, niespodziewane awarie i bolesne rollbacki. Zespoły publikują rzadziej, z mniejszą pewnością i spędzają więcej czasu na diagnozowaniu „dlaczego to środowisko jest inne”, zamiast poprawiać produkt.
Terraform to Infrastruktura jako Kod (IaC): zamiast klikać w konsoli chmurowej i polegać na pamięci, opisujesz infrastrukturę w plikach.
Te pliki zwykle żyją w Git, więc zmiany są widoczne, możliwe do przeglądu i powtarzalne.
Pomyśl o konfiguracji Terraform jak o „przepisie budowlanym” dla infrastruktury: sieci, bazy danych, load balancery, rekordy DNS i uprawnienia. Nie dokumentujesz tego, co zrobiłeś po fakcie — definiujesz, co ma istnieć.
Ta definicja ma znaczenie, bo jest jawna. Jeśli kolega potrzebuje tego samego środowiska, może użyć tej konfiguracji. Po incydencie możesz odtworzyć środowisko ze źródła.
Terraform operuje na idei stanu docelowego: deklarujesz, czego chcesz, a Terraform ustala, jakie zmiany są potrzebne, aby to osiągnąć.
Typowy cykl wygląda tak:
To „podgląd, potem zastosowanie” to miejsce, w którym Terraform błyszczy dla zespołów: wspiera przegląd kodu, zatwierdzenia i przewidywalne rollouty.
„IaC znaczy pełna automatyzacja.” Nie zawsze. Często warto zachować punkty kontrolne z udziałem ludzi — zwłaszcza przy zmianach produkcyjnych. IaC chodzi o powtarzalność i jasność, nie o wyeliminowanie ludzi z procesu.
„Jedno narzędzie rozwiąże wszystkie problemy infra/dostawy.” Terraform świetnie nadaje się do provisioningu i zmian infra, ale nie zastąpi dobrej architektury, monitoringu czy dyscypliny operacyjnej. Nie zarządza też każdą rzeczą równie dobrze — niektóre zasoby lepiej obsłużą inne systemy — dlatego najlepiej używać go jako części szerszego przepływu.
Zadanie Vagranta jest proste: dać każdemu deweloperowi to samo działające środowisko na żądanie, z jednej pliku konfiguracyjnego.
W centrum stoi Vagrantfile, gdzie opisujesz obraz bazowy (box), CPU/RAM, sieć, współdzielone foldery i jak maszyna ma być skonfigurowana.
Ponieważ to kod, środowisko jest możliwe do przeglądu, wersjonowania i łatwe do udostępnienia. Nowa osoba klonuje repo, uruchamia jedno polecenie i otrzymuje przewidywalne środowisko z właściwą wersją OS, pakietami, usługami i domyślnymi ustawieniami.
Kontenery są świetne do pakowania aplikacji i zależności, ale współdzielą jądro hosta. To oznacza, że nadal możesz napotkać różnice w sieci, zachowaniu systemu plików, usługach w tle czy narzędziach na poziomie OS — zwłaszcza gdy produkcja bardziej przypomina pełną maszynę Linux niż runtime kontenerów.
Vagrant zwykle używa maszyn wirtualnych (przez VirtualBox, VMware, Hyper-V). VM zachowuje się jak prawdziwy komputer z własnym jądrem i systemem init. To lepsze rozwiązanie, gdy musisz testować rzeczy, które kontenery słabo modelują: usługi systemowe, ustawienia jądra, reguły iptables, wielointerfejsową sieć czy problemy typu „to psuje się tylko na Ubuntu 22.04”.
To nie jest konkurs: wiele zespołów używa kontenerów do pakowania aplikacji, a Vagranta do realistycznego, pełnostystemowego developmentu i testowania.
Krótko: Vagrant to mniej „wirtualizacja dla samej wirtualizacji”, a bardziej uczynienie środowiska deweloperskiego wspólnym, zaufanym przepływem pracy.
Terraform i Vagrant rozwiązują różne problemy, ale razem tworzą jasną ścieżkę od „działa na mojej maszynie” do „działa niezawodnie dla wszystkich”. Most to parytet: utrzymywanie spójnych założeń aplikacji, mimo że miejsce uruchomienia się zmienia.
Vagrant to front door. Daje każdemu deweloperowi powtarzalne środowisko lokalne — ten sam OS, te same pakiety, te same wersje usług — więc aplikacja zaczyna od znanej bazy.
Terraform to współdzielony fundament. Definiuje infrastrukturę, na której polegają zespoły: sieci, bazy danych, moc obliczeniową, DNS, load balancery i reguły dostępu. Ta definicja staje się źródłem prawdy dla testów i produkcji.
Połączenie jest proste: Vagrant pomaga budować i weryfikować aplikację w środowisku przypominającym rzeczywistość, a Terraform zapewnia, że rzeczywistość (test/prod) jest provisionowana i zmieniana w sposób spójny i możliwy do przeglądu.
Nie używasz tego samego narzędzia do każdego celu — używasz tej samej umowy.
DATABASE_URL i REDIS_URL.Vagrant egzekwuje ten kontrakt lokalnie. Terraform egzekwuje go w środowiskach współdzielonych. Aplikacja pozostaje taka sama; zmienia się tylko „gdzie”.
Laptop (Vagrant): deweloper uruchamia vagrant up, dostaje VM z runtime aplikacji oraz Postgres i Redis. Iteruje szybko i wyłapuje problemy „działa lokalnie” wcześniej.
Test (Terraform): PR aktualizuje Terraform, aby provisionować testową bazę i instancje aplikacji. Zespół weryfikuje zachowanie przeciwko realnym ograniczeniom infrastruktury.
Produkcja (Terraform): te same wzorce Terraform stosuje się z ustawieniami produkcyjnymi — większa pojemność, surowszy dostęp, wyższa dostępność — bez wymyślania wszystkiego od nowa.
To most: powtarzalna lokalna parytetka napędzająca powtarzalną współdzieloną infrastrukturę, więc dostarczanie staje się kontrolowanym procesem, a nie reinwencją na każdym etapie.
Solidny przepływ Terraform/Vagrant to nie zapamiętywanie komend, lecz uczynienie zmian łatwymi do przeglądu, powtórzenia i wycofania.
Cel: deweloper zaczyna lokalnie, proponuje zmianę infrastruktury razem ze zmianą aplikacji i promuje tę zmianę przez środowiska z minimalnymi niespodziankami.
Wiele zespołów trzyma aplikację i infrastrukturę w tym samym repo, aby historia dostarczania była spójna:
/app — kod aplikacji, testy, artefakty builda/infra/modules — wielokrotnego użytku moduły Terraform (sieć, baza danych, usługa aplikacji)/infra/envs/dev, /infra/envs/test, /infra/envs/prod — cienkie warstwy środowisk/vagrant — Vagrantfile i skrypty provisionujące, aby odzwierciedlić „realne” zależnościWażny wzorzec to „cienkie środowiska, grube moduły”: środowiska wybierają głównie wejścia (rozmiary, liczby, nazwy DNS), podczas gdy współdzielone moduły zawierają faktyczne definicje zasobów.
Proste podejście trunk-based działa dobrze: krótkotrwałe branche feature, scalane przez PR.
W przeglądzie wymagaj dwóch artefaktów:
terraform fmt, validate i generuje terraform plan dla PR.Recenzenci powinni móc odpowiedzieć „co się zmieni?” i „czy to bezpieczne?” bez odtwarzania wszystkiego lokalnie.
Promuj ten sam zestaw modułów z dev → test → prod, utrzymując różnice jawne i małe:
Unikaj kopiowania całych katalogów per środowisko. Lepiej promować przez zmianę zmiennych, nie przepisywanie definicji zasobów.
Gdy zmiana aplikacji wymaga nowej infrastruktury (np. kolejka czy nowa konfiguracja), dostarczaj je w jednym PR, aby były recenzowane jako całość.
Jeśli infrastruktura jest współdzielona między wieloma usługami, traktuj moduły jak produkty: wersjonuj je (tagi/wydania) i dokumentuj wejścia/wyjścia jako kontrakt. Dzięki temu zespoły mogą aktualizować intencjonalnie, zamiast przypadkowo dryfować do „najświeższej” wersji.
Supermoc Terraformu to nie tylko tworzenie infrastruktury, lecz bezpieczna zmiana jej w czasie. Aby to zrobić, Terraform potrzebuje pamięci tego, co zbudował i co myśli, że istnieje.
Stan Terraform to plik (lub dane), który mapuje twoją konfigurację na rzeczywiste zasoby: która instancja bazy należy do którego aws_db_instance, jaki ma identyfikator i jakie ustawienia zostały ostatnio zastosowane.
Bez stanu Terraform musiałby zgadywać, co istnieje, skanując wszystko na nowo — co jest wolne, zawodliwe i czasem niemożliwe. Dzięki stanowi Terraform może obliczyć plan: co zostanie dodane, zmienione lub zniszczone.
Ponieważ stan może zawierać identyfikatory zasobów — a czasem wartości, które wolałbyś nie ujawniać — należy traktować go jak poświadczenie. Kto ma do niego dostęp lub może go modyfikować, może wpływać na to, co Terraform zrobi.
Dryft zdarza się, gdy infrastruktura zmienia się poza Terraformem: edycja w konsoli, szybka poprawka o 2:00 czy proces automatyczny modyfikujący ustawienia.
Dryft sprawia, że przyszłe plany są zaskakujące: Terraform może próbować cofnąć zmianę ręczną lub zawieść, bo założenia przestały odpowiadać rzeczywistości.
Zespoły zwykle trzymają stan zdalnie (a nie na jednym laptopie), aby wszyscy planowali i stosowali zmiany wobec tej samej prawdy. Dobre zdalne rozwiązanie oferuje też:
Bezpieczne dostarczanie jest przeważnie nudne: jeden stan, kontrolowany dostęp i zmiany przechodzące przez przeglądane plany.
Terraform staje się naprawdę potężny, gdy przestajesz kopiować te same bloki między projektami i zaczynasz pakować wspólne wzorce w moduły.
Moduł to wielokrotnego użytku zestaw kodu Terraform, który przyjmuje wejścia (np. CIDR VPC, rozmiar instancji) i zwraca wyjścia (np. identyfikatory subnetów, endpoint bazy). Korzyścią jest mniejsza duplikacja, mniej „śnieżnych płatków” i szybsze dostarczanie, bo zespoły zaczynają od znanego, działającego bloku.
Bez modułów kod infra rozrasta się przez kopiuj/wklej: jedno repo zmienia reguły security group, inne zapomina o szyfrowaniu, trzecie przypina inną wersję providera.
Moduł tworzy jedno miejsce, aby zakodować decyzję i ją udoskonalać. Przeglądy też stają się prostsze: zamiast audytować 200 linii sieci za każdym razem, przeglądasz mały interfejs modułu (wejścia/wyjścia) i tylko kiedy moduł się zmienia, audytujesz jego wnętrze.
Dobre moduły standaryzują kształt rozwiązania, zostawiając miejsce na sensowne różnice.
Przykłady wartę modularizacji:
Unikaj kodowania każdej opcji. Jeśli moduł potrzebuje 40 wejść, prawdopodobnie próbuje obsłużyć zbyt wiele przypadków. Wybierz sensowne domyślny i niewielki zestaw decyzji politycznych, a „escape hatch” niech będzie rzadki i jawny.
Moduły mogą stać się labiryntem, jeśli każdy publikuje lekko inną wersję („vpc-basic”, „vpc-basic2”, „vpc-new”). Rozrost pojawia się, gdy brak właściciela, dyscypliny wersjonowania i wytycznych, kiedy tworzyć nowy moduł zamiast ulepszać istniejący.
Praktyczne zasady:
Dobrze zrobione moduły zamieniają Terraform w współdzielony przepływ pracy: zespoły działają szybciej, bo „właściwy sposób” jest spakowany, odkrywalny i powtarzalny.
Terraform i Vagrant czynią środowiska odtwarzalnymi — ale też sprawiają, że błędy są odtwarzalne. Jeden wyciek tokena w repo może rozprzestrzenić się na laptopy, zadania CI i zmiany w produkcji.
Kilka prostych nawyków zapobiega większości powszechnych błędów.
Traktuj „co budujemy” (konfiguracja) i „jak się uwierzytelniamy” (sekrety) jako oddzielne sprawy.
Definicje infrastruktury, Vagrantfile i wejścia modułów powinny opisywać zasoby i ustawienia — nie hasła, klucze API ani prywatne certyfikaty. Sekrety pobieraj w czasie wykonania z zaufanego magazynu sekretów (dedykowany vault, manager sekretów chmury lub ściśle kontrolowany magazyn sekretów CI). Dzięki temu kod jest przeglądalny, a wartości wrażliwe audytowalne.
Nadaj każdemu aktorowi tylko uprawnienia, których potrzebuje:
plan vs apply).terraform plan, nie musi mieć uprawnień do wykonywania zmian w produkcji. Stosuj separację ról, aby zatwierdzenie i wykonanie nie zawsze przypadały tej samej osobie.Unikaj wbudowywania poświadczeń w kodzie, lokalnych plików dotfile, które się kopiują, czy „zespołowych kluczy”. Wspólne sekrety niweczą odpowiedzialność.
Te zabezpieczenia nie spowalniają dostarczania — zmniejszają zasięg szkód, gdy coś pójdzie nie tak.
To w CI/CD Terraform przestaje być „rzeczą, którą ktoś uruchamia” i staje się przepływem zespołowym: każda zmiana jest widoczna, przeglądana i stosowana tak samo za każdym razem.
Praktyczna podstawa to trzy kroki, podpięte do PR i zatwierdzeń:
terraform fmt -check i terraform validate, by wykryć oczywiste błędy wcześnie.terraform plan i opublikuj wynik do PR (artefakt lub komentarz). Recenzenci powinni móc odpowiedzieć: co się zmieni? gdzie? dlaczego?terraform apply używając tej samej rewizji kodu, która wygenerowała plan.# Example (GitHub Actions-style) outline
# - fmt/validate on PR
# - plan on PR
# - apply on manual approval
Klucz to separacja: PR-y produkują dowody (plany), zatwierdzenia autoryzują zmiany (apply).
Vagrant nie zastępuje CI, ale sprawia, że lokalne testy mogą być zbliżone do CI. Gdy zgłoszenie błędu brzmi „działa na mojej maszynie”, wspólny Vagrantfile pozwala każdemu uruchomić ten sam OS, pakiety i wersje usług, by odtworzyć problem.
To szczególnie przydatne do:
Jeśli zespół ustandaryzuje przepływy dostarczania, narzędzia takie jak Terraform i Vagrant działają najlepiej w parze z konsekwentnym szkieletem aplikacji i powtarzalnymi krokami wydawniczymi.
Koder.ai może tu pomóc jako platforma vibe-coding: zespoły mogą wygenerować działający szkielet web/backend/mobile z poziomu rozmowy, a potem wyeksportować kod źródłowy i wpiąć go w ten sam Git-based workflow opisany powyżej (łącznie z modułami Terraform i bramkami CI plan/apply). To nie zastępstwo Terraform lub Vagrant; to sposób na skrócenie czasu do pierwszego commita przy zachowaniu jawnych praktyk infra i środowisk.
Aby automatyzacja nie stała się przypadkową automatyzacją:
Dzięki tym zabezpieczeniom Terraform i Vagrant wspierają ten sam cel: zmiany, które potrafisz wyjaśnić, powtórzyć i którym ufasz.
Nawet dobre narzędzia mogą stworzyć nowe problemy, gdy są traktowane jako „ustaw i zapomnij”. Terraform i Vagrant działają najlepiej, gdy utrzymasz jasny zakres, zastosujesz kilka zabezpieczeń i oprzesz się pokusie modelowania każdego szczegółu.
Długotrwały dryft: zmiany ręczne „tylko raz” w konsoli chmurowej mogą cicho odróżniać infra od Terraform. Po miesiącach następny apply staje się ryzykowny.
Zbyt skomplikowane moduły: moduły świetnie nadają się do ponownego użycia, ale mogą stać się labiryntem — dziesiątki zmiennych, zagnieżdżone moduły i „magiczne” domyślne, które rozumie tylko jedna osoba. Efekt: wolniejsze dostarczanie.
Wolne lokalne VM: Vagrant boxy mogą rosnąć (duże obrazy, za dużo usług, wolny provisioning). Deweloperzy zaczynają omijać VM, a powtarzalne środowisko staje się opcjonalne — aż coś psuje się w produkcji.
Trzymaj Vagranta, gdy potrzebujesz pełnego środowiska OS, które odpowiada zachowaniom produkcji (usługi systemowe, ustawienia jądra, różnice systemowe) i zespół korzysta z „znanej, działającej” bazy.
Przejdź na kontenery, gdy aplikacja dobrze działa w Dockerze, chcesz szybszego startu i nie potrzebujesz granicy jądra VM. Kontenery często rozwiązują problem "moja VM jest wolna".
Używaj obu, gdy potrzebujesz VM, by emulować hosta (lub uruchamiać zależności), ale samą aplikację trzymasz w kontenerach wewnątrz tej VM. To może zrównoważyć realizm ze szybkością.
Suggested links: /blog/terraform-workflow-checklist, /docs, /pricing
Terraform sprawia, że zmiany w infrastrukturze są jawne, możliwe do przeglądu i powtarzalne. Zamiast polegać na klikaniu w konsoli czy instrukcjach w runbooku, zapisujesz konfigurację w kontroli wersji, używasz terraform plan, aby zobaczyć wpływ zmian, a potem stosujesz je konsekwentnie.
Największą wartość daje tam, gdzie wiele osób musi rozumieć i bezpiecznie zmieniać współdzieloną infrastrukturę w czasie.
Vagrant daje deweloperom znane, działające środowisko na poziomie systemu operacyjnego z jednego Vagrantfile. Skraca to czas wdrożenia nowych osób, eliminuje dryft typu „działa na moim laptopie” i pomaga odtwarzać błędy powiązane z pakietami systemowymi, usługami lub siecią.
Jest szczególnie przydatny, gdy założenia produkcyjne bardziej przypominają VM niż kontener.
Użyj Vagranta do ustandaryzowania środowiska lokalnego (OS, usługi, ustawienia). Użyj Terraformu do ustandaryzowania współdzielonych środowisk (sieci, bazy danych, obliczenia, DNS, uprawnienia).
Łącząc je, definiujesz stabilny „kontrakt” (porty, zmienne środowiskowe jak DATABASE_URL), który pozostaje spójny przy przejściu z laptopa → test → produkcja.
Zacznij od struktury, która oddziela wielokrotne bloki od ustawień środowiskowych:
/infra/modules/infra/envs/dev, /infra/envs/prod)/vagrantDzięki temu promocja między środowiskami to głównie zmiana zmiennych, a nie kopiowanie całych katalogów.
Stan Terraform to sposób, w jaki Terraform pamięta, które zasoby rzeczywiste odpowiadają konfiguracji. Bez stanu Terraform nie potrafi bezpiecznie obliczyć zmian.
Traktuj stan jak poświadczenie:
Dryft pojawia się, gdy infrastruktura zmienia się poza Terraformem (edycje w konsoli, poprawki awaryjne, procesy automatyczne). Powoduje to zaskakujące plany i może sprawić, że Terraform spróbuje cofnąć ręczne zmiany lub operacja zakończy się błędem.
Praktyczne sposoby zmniejszania dryftu:
Używaj modułów, aby standaryzować powtarzalne wzorce (sieć, bazy danych, wdrożenia usług) zamiast kopiować kod.
Dobre moduły mają:
Unikaj modułów z kilkudziesięcioma zmiennymi — zbyt duża złożoność spowolni dostarczanie.
Oddziel konfigurację i sekrety:
Vagrantfileplan, inne dla apply, a w produkcji wymagaj dodatkowych zatwierdzeńPamiętaj, że stan może zawierać wrażliwe identyfikatory — zabezpiecz go odpowiednio.
Minimalna, skalowalna linia CI dla Terraform:
terraform fmt -check i terraform validateterraform plan i opublikuj jego wynik do przegląduterraform apply na tym samym commicie, który wygenerował planDzięki temu przeglądający mogą odpowiedzieć „co się zmieni?” zanim cokolwiek zostanie zastosowane.
Zachowaj Vagranta, gdy potrzebujesz:
Rozważ kontenery, gdy zależy ci na szybszym starcie, a aplikacja nie potrzebuje zachowań na poziomie VM. Wiele zespołów stosuje oba: kontenery dla aplikacji, Vagrant do emulacji hosta produkcyjnego.