Bezpieczny rurociąg dostarczania Terraform – najlepsze praktyki. Część 1/2
Choć wciąż bardzo młody (wersja 0.12), Terraform stał się już wiodącym rozwiązaniem w obszarze Infrastruktura jako Kod. Zupełnie nowe narzędzie w powstającym obszarze, działające w nowym modelu programowania – rodzi to wiele pytań i wątpliwości, szczególnie przy obsłudze niezbędnej biznesowo infrastruktury chmurowej.
W GFT stoimy przed wyzwaniami związanymi z dostarczaniem wdrożeń Terraform na dużą skalę: oprócz wszystkich głównych dostawców usług w chmurze, wspieramy duże organizacje w ściśle regulowanym środowisku usług finansowych, z wieloma zespołami pracującymi w środowiskach w wielu regionach na całym świecie. Automatyzacja dostarczania Terraform przy jednoczesnym zapewnieniu odpowiedniego bezpieczeństwa i łagodzeniu typowych ryzyk i błędów to jeden z głównych tematów w naszych zespołach DevOps.
Dlaczego potrzebny jest bezpieczny rurociąg Terraform?
Celem jest stworzenie procesu, który umożliwi użytkownikowi wprowadzanie zmian w środowisku chmury bez konieczności posiadania wyraźnych uprawnień do ręcznych działań. Proces jest następujący:
- Zmiana jest sprawdzana i łączona z żądaniem ściągnięcia po sprawdzeniu przez wymaganych recenzentów. Nie ma innej możliwości wprowadzenia zmiany.
- Zmiana jest wdrażana w środowisku testowym. Wcześniej plan Terraform jest sprawdzany ręcznie i zatwierdzany.
- Zmiana musi zostać przetestowana/zatwierdzona w środowisku testowym.
- Plan Terraform został zatwierdzony dla środowiska tymczasowego. Zmiana jest dokładnie taka sama jak w środowisku testowym (np. ta sama rewizja).
- Zmiany Terraform są stosowane do przemieszczania przy użyciu wyznaczonego konta systemowego Terraform. Nie ma innego sposobu wykorzystania tego konta Terraform, jak na tym etapie procesu.
- Wykonaj tę samą procedurę, aby promować zmiany ze środowiska tymczasowego do środowiska produkcyjnego.
Wymagania niefunkcjonalne
Środowiska
- Środowiska (dev/uat/stage/prod) mają zapewniony odpowiedni poziom separacji:
- W tych środowiskach Terraform używa różnych kont systemowych. Każde konto systemowe Terraform ma uprawnienia tylko do swojego własnego środowiska.
- Łączność sieciowa jest ograniczona między zasobami w różnych środowiskach.
- (Opcjonalnie) Tylko wyznaczony agent lub zestaw agentów skonfigurowany w specjalnej sieci wirtualnej może modyfikować infrastrukturę (tj. uruchamiać Terraform) i uzyskiwać dostęp do wrażliwych zasobów (np. zaplecza Terraform, magazynów kluczy itp.). Nie jest możliwe wydanie np. prod przy użyciu agenta kompilacji innego niż prod.
- Istnieje sposób, aby upewnić się, że konfiguracja Terraform jest jak najbardziej podobna w różnych środowiskach. (tzn. nie mogę zapomnieć o całym module w PROD w porównaniu do UAT)
- Backend Terraform w wyższych środowiskach (np. UAT) nie jest dostępny z komputerów lokalnych (sieć + ograniczenia RBAC). Dostęp do niego można uzyskać tylko z komputerów budujących i opcjonalnie z wyznaczonych hostów bastionowych.
Konta systemowe dla Terraform
- Jeśli to możliwe, Terraform działa przy użyciu konta systemowego, a nie konta użytkownika.
- Różne konta systemowe służą do:
- Terraform (użytkownik systemu modyfikujący infrastrukturę),
- Kubernetes (użytkownik systemu, za pomocą którego Kubernetes tworzy wymagane zasoby, np. moduły równoważenia obciążenia lub pobiera obrazy dockerów z repozytorium),
- Komponenty aplikacji w czasie wykonywania (w porównaniu z czasem kompilacji lub wydaniem).
- Konta systemowe, które mają zezwolenie na zmiany Terraform, mogą być używane tylko w wyznaczonych potokach CD. Czyli nie ma możliwości, żebym mógł bez specjalnego zezwolenia używać np. produkcyjnego konta systemu Terraform w nowo utworzonym rurociągu.
- (Opcjonalnie) Dostęp do konta w systemie Terraform jest przyznawany „w samą porę” dla danej wersji. Alternatywnie konto systemowe otrzymuje uprawnienia tylko na czas wdrożenia.
- Konta systemowe w wyższych środowiskach mają uprawnienia ograniczone tylko do tych, które są wymagane do wykonywania działań.
- Ogranicz uprawnienia tylko do używanych typów zasobów.
- Usuń uprawnienia do usuwania krytycznych zasobów (np. baz danych, pamięci masowej), aby uniknąć automatycznego ponownego utworzenia tych zasobów i utraty danych. W takich sytuacjach należy udzielić specjalnych zezwoleń „w samą porę”.
Proces
- Zmiana na wyższe środowisko (np. STAGE) może zostać wdrożona tylko wtedy, gdy została wcześniej przetestowana w niższym środowisku. Istnieje metoda gwarantująca, że jest to dokładnie ta sama wersja Gita, która została przetestowana. Zmiana może zostać wprowadzona jedynie poprzez pull request z wymaganym procesem przeglądu.
- Opcja zastosowania zmian Terraform może być dozwolona jedynie po ręcznym sprawdzeniu i zatwierdzeniu planu Terraform w każdym środowisku.
Wdrażanie bezpiecznego potoku Terraform
WSKAZÓWKA: zapoznaj się z tą zewnętrzną dokumentacją, aby rozpocząć konfigurowanie Terraform w potokach CI/CD:
Backendy Terraforma
Posiadanie wspólnego backendu Terraform jest pierwszym krokiem do zbudowania potoku. Backend Terraform to kluczowy komponent obsługujący przechowywanie, zarządzanie i blokowanie stanu współdzielonego, aby zapobiec modyfikowaniu infrastruktury przez wiele procesów Terraform.
Trochę wstępnej dokumentacji:
- Konfiguracja zaplecza Terraform
- lista dostawców backendu
- AWS-a 3
- Przechowywanie w chmurze GCP
- Konto magazynu Azure
- Zdalny backend dla Terraform Cloud/Enterprise
Upewnij się, że infrastruktura zaplecza ma wystarczającą ochronę. Pliki stanu będą zawierać wszystkie wrażliwe informacje przechodzące przez Terraform (klucze, sekrety, wygenerowane hasła itp.).
- Najprawdopodobniej będzie to konto AWS S3+DynamoDB, Google Cloud Storage lub Azure Storage.
- Oddzielna infrastruktura (sieć + RBAC) backendu produkcyjnego i nieprodukcyjnego.
- Zaplanuj wyłączenie dostępu do plików stanu (dostęp do sieci i kontrola dostępu RBAC) spoza wyznaczonej sieci (np. puli agentów wdrażania).
- Nie przechowuj infrastruktury backendowej Terraform w środowisku wykonawczym. Użyj osobnego konta/projektu/subskrypcji itp.
- Włącz opcje wersjonowania obiektów/usuwania nietrwałego w backendach Terraform, aby uniknąć utraty zmian i plików stanu oraz aby zachować historię stanu Terraform.
W niektórych szczególnych przypadkach wymagany będzie ręczny dostęp do plików stanu Terraform. Rzeczy takie jak refaktoryzacja, wprowadzanie zmian lub naprawianie defektów będą wymagały wykonywania operacji stanu Terraform przez personel operacyjny. Na takie okazje zaplanuj nadzwyczajny kontrolowany dostęp do stanu Terraform za pomocą hosta bastionowego, VPN itp.
W przypadku korzystania z Terraform Cloud/Enterprise ze zdalnym backendem narzędzie będzie obsługiwać wymagania dotyczące przechowywania stanu.
Podziel na wiele projektów
Oczywiście Terraform pozwala na podzielenie konstrukcji na moduły. Warto jednak rozważyć podzielenie całej infrastruktury na osobne projekty. „Projekt Terraform” w tym opisie to pojedynczy element infrastruktury, który można wprowadzić w wielu środowiskach, zwykle za pomocą jednego rurociągu.
Projekty Terraform będą zazwyczaj pasować do wzorców architektury chmury, takich jak współdzielone środowisko VPC , strefa docelowa ( Azure i AWS ), topologia sieci typu hub-and-szprychy. Wzorców jest wiele w AWS Well-Architected Framework, Azure Cloud Adoption Framework, Architecture Center czy Google Cloud Solutions.
Oto kilka próbek:
- Terraform Bootstrap
Jest to potrzebne, gdy zdalne pliki stanu Terraform są przechowywane w chmurze. Będzie to prosty projekt, który stworzy infrastrukturę wymaganą dla backendów innych projektów. Ogólnie rzecz biorąc, należy unikać projektów bezpaństwowych. Ale to będzie jeden z nich (stary problem kury i jajka). - Landing Zone
Posiadaj oddzielny projekt (lub projekty) do skonfigurowania obecności w chmurze – sieć lub połączenie VPN. Budowa strefy lądowania to osobny temat. Zobacz na przykład https://www.tranquilitybase.io/ - Współdzielona infrastruktura kompilacji
Fragment infrastruktury firmy, zwykle globalnej, który obsługuje operacje w czasie kompilacji. Na przykład:- Twórz pule agentów
- rejestr kontenerów (lub rejestry)
- podstawowe magazyny kluczy przechowujące certyfikaty firmy
- globalne konfiguracje DNS itp.
- Infrastruktura środowiska uruchomieniowego hosta
Zwykle środowiska wykonawcze mają pewne wymagania wstępne i elementy infrastruktury, które mogą być współdzielone między środowiskami prod i nieprodukcyjnymi, takie jak hosty bastionowe, DNS, magazyny kluczy. Jest to również dobre miejsce na skonfigurowanie pul agentów wdrażania oddzielnych dla środowisk produkcyjnych i innych niż produkcyjne (może nie być konieczne oddzielne pul dla dev1, dev2, uat1, uat2 itp.). - Środowiska uruchomieniowe
Jest to oczywiście infrastruktura pod aplikacje i usługi obsługujące biznes. Upewnij się, że istnieje środowisko do testowania skryptów Terraform, niekoniecznie takie samo, w jakim testowana jest aplikacja, aby uniknąć zakłócania pracy zespołu ds. kontroli jakości podczas stosowania potencjalnie niedoskonałych konfiguracji Terraform. Co więcej, bądź przygotowany na podzielenie środowisk wykonawczych pomiędzy zespoły, usługi i działy. Może się okazać, że nie będzie możliwe utworzenie jednego projektu obejmującego całe środowisko „produkcyjne firmy”.
Przyjrzyjmy się teraz ogólnym sytuacjom, w których warto podzielić swoją infrastrukturę na projekty.
- Używaj różnych kont systemowych dla różnych poziomów bezpieczeństwa.
Przygotuj oddzielny projekt, jeśli chcesz użyć innego konta systemowego Terraform dla elementów infrastruktury. W przeciwnym razie będziesz musiał nadać bardzo szerokie uprawnienia pojedynczemu kontu systemowemu. Przykłady:- elementów infrastruktury w ramach wielu projektów lub jednostek organizacyjnych,
- infrastruktura czasu kompilacji a infrastruktura czasu wykonania,
- oddzielne systemy,
- współdzielona infrastruktura vs pojedynczy system/usługa,
- obsługujących różne regiony.
- Mieć inny zestaw środowisk
Kiedy stwierdzisz, że dla jednego elementu infrastruktury potrzebujesz tylko „prod” i „non-prod”, a dla drugiej części będziesz mieć „dev”, „uat”, „stage” lub „prod ”, to jest to znak, że te elementy infrastruktury powinny być rozdzielone. - Twórz warstwy i nakładki
Jeśli konfiguracja Terraform w jednym projekcie stanie się zbyt duża, obsługa jej może stać się trudna. Konstruowanie planów Terraform będzie wolniejsze, a refaktoryzacja może być bardzo ryzykowna. Dobrym pomysłem może być podzielenie całej infrastruktury na warstwy. Nakładki mogą początkowo wyglądać jak moduły opcjonalne wymagane tylko w niektórych środowiskach. Oto kilka teoretycznych przykładów:- Współdzielona warstwa sieciowa – sieci wirtualne, firewalle, VPN,
- Infrastruktura podstawowa – obliczeniowa, magazynowa, Kubernetes,
- Warstwa aplikacji – usługi przesyłania wiadomości, bazy danych, magazyny kluczy, agregacja logów,
- Nakładka monitorująca – niestandardowe metryki, kontrole kondycji, reguły alertów.
- Obsługuj różne działy/systemy
Fragmenty infrastruktury, które mają różne źródła zmian lub obsługują różne obszary biznesowe lub działy, zwykle mają różne poziomy bezpieczeństwa – w takich przypadkach kontrola dostępu może być traktowana oddzielnie za pomocą różnych potoków Terraform, cyklów wydawniczych itp. Staraj się unikać ogromnych konfiguracje monolityczne.
WSKAZÓWKA: Gdy zasoby wielu projektów muszą ze sobą współdziałać i na sobie polegać, możesz użyć źródeł danych Terraform , aby „dotrzeć” do zasobów z różnych projektów. Terraform pozwala na posiadanie wielu dostawców tego samego typu, którzy na przykład mają dostęp do różnych projektów/kont/subskrypcji. Przykład: użyj oddzielnego dostawcy i źródła danych, aby „znaleźć” globalną podsieć bramy VPN firmy w celu skonfigurowania łączności sieciowej dla środowiska wykonawczego.
Oto przykład podziału infrastruktury na projekty Terraform:
Obsługuj środowiska oddzielnie
Przygotuj się do obsługi wielu środowisk już pierwszego dnia. Później będzie to bardzo skomplikowana zmiana i może wymagać intensywnej refaktoryzacji.
- Upewnij się, że każde środowisko każdego projektu ma swój własny plik stanu. Nie przechowuj wielu środowisk (dev/stage/prod) w jednym pliku stanu Terraform.
- Używaj różnych kont systemowych Terraform dla środowisk. Upewnij się już na początku, że konta systemowe mają ograniczone uprawnienia i nie mogą uzyskać wzajemnego dostępu do infrastruktury.
- Blokuj dostęp np. do pliku stanu tymczasowego na wczesnym etapie. Zmusi Cię to do szybkiego zastanowienia się nad zbudowaniem zautomatyzowanego i bezpiecznego rurociągu.
- Przygotuj wcześniej pule agentów nieprodukcyjnych i prod wdrożeniowych. Blokuj dostęp sieciowy do magazynu, magazynów kluczy, API Kubernetes itp. z określonych sieci wirtualnych pul agentów wdrożeniowych.
Należy pamiętać, że Terraform nie pozwala na używanie zmiennych w sekcjach dostawcy i backendu. Proste podejście z wieloma plikami „.tfvars” może na dłuższą metę stanowić wyzwanie.
Oto kilka opcji obsługi środowisk:
- Użyj Terraform Workspaces i opcji terraform init –backend-config, aby przełączać backendy i środowiska. Można tego używać z lub bez Terraform Cloud/Enterprise,
- Użyj układu modułów i katalogów (np. podejście oparte na module głównym Terraform) , które pozwala na obsługę wielu środowisk poprzez wykorzystanie struktury modułowej.
Budując wiele środowisk, upewnij się, że prawidłowo radzisz sobie z różnicami. Różne środowiska będą miały różne poziomy cenowe, rozmiary maszyn wirtualnych, a nawet niektóre zasoby będą całkowicie wyłączone (ochrona WAF, DDoS).
- Użyj parametrów i „flag funkcji”, aby włączyć/wyłączyć opcjonalne funkcje w połączeniu z konstrukcją „liczba” i „dla każdego” w Terraform,
- Jeśli używasz ustawień domyślnych, upewnij się, że domyślne jest ustawienie produkcyjne i zastąpisz ustawienia środowiska innego niż produkcyjne,
- Możesz łatwo wskazać różnice w poszczególnych środowiskach i wiesz, jak funkcje zmieniają się w różnych środowiskach,
- Posiadaj jawne środowisko przypominające produkty do testowania z ustawieniami produkcyjnymi 1:1. Przygotuj wyraźny test w procedurze wydawania.
WSKAZÓWKA: Na etapie kompilacji potoku zawsze uruchamiaj „terraform valid” dla wszystkich środowisk. Upewnij się, że ten krok nie powiedzie się, jeśli zapomnisz ustawić właściwość. Upewnij się, że nie da się zapomnieć o całym module w Twoim środowisku.
Organizuj w moduły
Modularyzacja Terraform to szeroki temat, którego głównym celem jest zbudowanie katalogu sprawdzonych, utrzymywanych i nadających się do ponownego wykorzystania elementów infrastruktury. Oprócz globalnego, publicznego rejestru Terraform, firmy budują własne biblioteki modułów. Można to zrobić za pomocą Terraform Cloud/Enterprise lub za pomocą repozytoriów Git.
Niemniej jednak, nawet jeśli fragment projektu Terraform nie wygląda na moduł współdzielony, warto zawrzeć go w podmodule. Istnieją główne korzyści:
- dekompozycja kodu dużej infrastruktury,
- skupienie się na pojedynczej odpowiedzialności za moduł,
- poprawa czytelności kodu,
- podążając tym samym
- śledzenie zależności (zmiennych i wyników) pomiędzy logicznymi elementami infrastruktury.
Podobnie jak w przypadku każdego innego języka programowania, modularyzacja przynosi wartość nawet jeśli moduły stanowią integralną część pojedynczego repozytorium i są używane tylko raz.
Zbuduj rurociąg terraformowy za pomocą CI/CD
Terraform Cloud/Terraform Enterprise to sprawdzone rozwiązanie, które uwzględnia niektóre aspekty wdrażania bezpiecznego potoku Terraform, takie jak:
- Zdalny backend
- Rejestr modułów
- Przegląd i zatwierdzenie planu terenu
- Zdalne wykonanie Terraformu
- Bezpieczna obsługa poświadczeń kont systemowych
Ponieważ można go używać za pośrednictwem interfejsu użytkownika oraz interfejsów API i CLI, można go używać razem z narzędziem CI/CD, jednak Terraform Cloud/Enterprise sam w sobie nie jest narzędziem CI/CD. Będzie to w dużej mierze zależeć od dostępnego narzędzia. Każde narzędzie CI/CD będzie miało inne funkcje i podejścia, mniej lub bardziej specyficzne dla terenu.
Istnieją dwie ogólne opcje:
- Użyj wbudowanego mechanizmu narzędzia CD do kontroli wydania
- Wbudowana wersja pakietu
- Zabezpieczone artefakty potoku/kompilacji
- Zwolnij rurociągi w ramach procesu promocji środowiska
- Ręczne kontrole i zatwierdzenia przez osoby uprawnione
- Plany wydań, plany wycofania
- Obsługa kont systemowych i sekretów
- Postępuj zgodnie z podejściem GitOps
- Polegaj na repozytoriach, gałęziach i tagach Git, aby kontrolować proces
- Polegaj na kontroli dostępu Git, uprawnieniach i egzekwowaniu żądań ściągnięcia
- Użyj webhooków Git
- Posiadaj oddzielne repozytorium „kodu” i repozytorium „dostawy” do kontroli GitOps
Oto kilka ogólnych kroków wdrażania bezpiecznego potoku Terraform:
- Chroń gałąź „master”
Skonfiguruj swojego Gita w taki sposób, aby „push” do gałęzi „master” był zabroniony i dozwolony tylko za pomocą żądania ściągnięcia (lub żądania połączenia). Ustaw wymagane kroki (np. „kompilacja” Terraform musi przejść) i wymaganą liczbę osób zatwierdzających z listy.
Zapytaj: Czy mogę wprowadzić dowolną zmianę w gałęzi, która jest źródłem wydania? - Zbuduj wieloetapowy potok
Jeśli to możliwe, zbuduj potok, który będzie wizualizował, że określona wersja konfiguracji Terraform jest promowana z jednego środowiska do drugiego.
Zapytaj: Czy mogę wprowadzić coś do produkcji bez testowania w fazie testowej? Czy mogę wdrożyć coś z dowolnej gałęzi innej niż „master”? - Polegaj na wersjach, a nie na gałęziach
Budując potok, pamiętaj o promowaniu niezmiennej migawki konfiguracji Terraform. Unikaj używania do tego gałęzi. Zamiast tego promuj artefakt kompilacji lub tag Git.
Zapytaj: Czy jestem w 100% pewien, że wdrażam dokładnie tę samą wersję, którą testowałem wcześniej? - Wykonaj krok „kompilacji” Terraforma
Nie jest oczywiste, że kod Terraform można zbudować. Jednak przynajmniej sprawdzenie Terraforma pod kątem konfiguracji wszystkich środowisk i uruchomienie planu na wyznaczonym środowisku pozwoli wyłapać oczywiste błędy. Akcję sprawdzania poprawności Terraform można wykonać bez łączenia się ze zdalnym backendem. Warto to zrobić zarówno na gałęzi master, jak i na żądanie ściągnięcia. Może to również pozwolić na ustawienie unikalnego numeru wersji lub znacznika w wersji gałęzi głównej.
Zapytaj: Jak mogę się upewnić, że kod Terraform ma przynajmniej poprawną składnię i pełną konfigurację? - Wykonaj etap ręcznego zatwierdzania planu Terraform.
Będzie to jeden z najtrudniejszych wymagań do wdrożenia w przypadku większości narzędzi. Zacznij stąd. Ma to na celu zapewnienie, że plan zostanie sprawdzony i zatwierdzony przez osobę, a dokładnie ten plan zostanie zastosowany.
Zapytaj: Jak mogę sprawdzić, co zmieni się w każdym środowisku? - Upewnij się, że w każdym środowisku istnieje tylko jeden oczekujący plan.
Kiedy plan oczekuje na zatwierdzenie i zastosowano inny plan, pierwszy plan nie jest już prawdziwy. Zapobiegaj współbieżnym planom oczekującym na jednym środowisku.
Zapytaj: Jak mogę się upewnić, że między etapami „planowania” i „zastosowania” nie zostaną zastosowane żadne inne zmiany? - Chroń dostęp do oddzielnych kont systemowych dla każdego środowiska.
Należy przygotować wiele kont systemowych dla różnych środowisk. Celem potoku jest zapewnienie bezpiecznego dostępu do konta systemowego (tj. dane uwierzytelniające/klucze są ukryte/tajne, przeznaczone tylko do zapisu i nie są logowane w konsoli). Tylko zatwierdzony potok powinien mieć możliwość korzystania z tego konta systemowego.
Zapytaj: Czy mogę używać produkcyjnego konta systemu Terraform w procesie nieprodukcyjnym lub na etapie nieprodukcyjnym? - Chroń dostęp do oddzielnych pul agentów dla każdego środowiska.
Pule agentów dla wdrożeń innych niż produkcyjne i prod powinny być oddzielne. Dostęp sieciowy do usług takich jak interfejs API Kubernetes, magazyny kluczy, poufny magazyn itp. powinien być ograniczony, łącznie z agentami kompilacji wdrożenia. Jednak agenci kompilacji nieprodukcyjni nie mogą mieć dostępu do produkcyjnego środowiska wykonawczego. Tylko zatwierdzone potoki powinny móc działać w puli agentów wdrażania produkcyjnego.
Pytanie: Czy możliwe jest uruchomienie dowolnego potoku w pulach agentów wdrażania produkcyjnego? - Przygotuj plan wycofywania
zmian Wycofywanie zmian zwykle oznacza uruchomienie wersji poprzedniej wersji konfiguracji Terraform.
Zapytaj: Jak uruchomić poprzednią wersję? - Kontroluj uprawnienia użytkowników do środowisk
Upewnij się, że tylko określone osoby mogą wdrażać zmiany w określonych środowiskach. Wprowadź kontrolę czterech oczu (zatwierdzenie przez co najmniej 2 osoby) w przypadku wydań produkcyjnych. Zachowaj kontrolę nad inicjowaniem wydania i zatwierdzaniem planu Terraform.
Zapytaj: Czy mogę zatwierdzić plan Terraform w wersji produkcyjnej, jeśli nie mam pozwolenia? - Miej kontrolę dostępu do Terraform na czas.
Wprowadź kontrole do procesu, aby mieć pewność, że produkcyjne konto systemu Terraform będzie dostępne tylko w czasie planowanej wersji. Alternatywnie można mu przyznać uprawnienia RBAC na poziomie produkcyjnym tylko na czas wydania. Ma to na celu zapewnienie, że odpowiedni personel będzie miał dostęp zarówno do rurociągu CI/CD, jak i do dostawcy chmury podczas wydania. To kolejna metoda sprawdzania na cztery oczy. Pomyśl o uwierzytelnianiu wieloskładnikowym dla CI/CD.
Zapytaj: Czy mogę wykonać wydanie produkcyjne, mając dostęp tylko do potoku CI/CD? - Przeprowadzanie testów w ramach potoku
Jak każde inne oprogramowanie, infrastruktura wirtualna może i powinna być testowana. Poniżej znajduje się sekcja Ciągła zgodność z niektórymi wytycznymi dotyczącymi testowania. Upewnij się, że po wdrożeniu przynajmniej w środowiskach prod-like i prod jest krok w celu sprawdzenia zgodności, zasad bezpieczeństwa i przeprowadzenia kilku testów, nawet testów dymnych. Celem jest uzyskanie szybkiej informacji zwrotnej.
Zapytaj: Czy od razu dowiem się, czy zmieniona infrastruktura nie jest zgodna z wymaganiami i zasadami niefunkcjonalnymi?
Przykładowy potok wydawniczy z wykorzystaniem Azure DevOps:
- Wersja kodu jest przechowywana jako artefakt i promowana ze środowiska do środowiska
- Wszystkie etapy „Planuj” i „Zastosuj” są kontrolowane na podstawie zatwierdzeń przed i po etapie.
- Narzędzie utrzymuje poświadczenia systemowe dla poszczególnych środowisk i dostęp do agentów wdrożeniowych.
Przykładowy proces GitOps
- Istnieje repozytorium (lub repozytoria) „dostawcze” służące do kontrolowania faktycznego wdrażania w środowiskach,
- Repozytorium „dostawy” będzie importować moduły z repozytoriów „kodu” lub rejestru modułów,
- Procedura wydania rozpoczyna się od pull requestu ze zmianą w danym repozytorium,
- Zautomatyzowane narzędzie przygotuje Terraform Plan,
- Zatwierdzenie planu jest realizowane jako zatwierdzenie żądania ściągnięcia, połączenie spowoduje faktyczne wydanie.
Rzeczywisty proces dostarczania rurociągu będzie w dużej mierze zależał od wybranych narzędzi. Potraktuj powyższe wytyczne jako listę kontrolną dla swojego procesu. W części 2 tego przewodnika przyjrzymy się ciągłemu zapewnianiu zgodności i testowaniu kodu infrastruktury.
