Zmieńmy naszą konfigurację na moduł. Infrastruktura jako kod (IaaC) - cześć 2

W poprzedniej części - Infrastruktura jako kod (IaaC) - cześć 1 zaczeliśmy zabawę z IaC czyli z naszą infrastrukturą w kodzie i dodalismy obsługę naszego OVH w terreform. Spróbuje moją obecna konfigurację przerobic na moduł, dzięki któremu będę mógł lepiej zarządzać moją infrastrukturą i połączyć OVH i Digital Ocean. Na początek przybliżymy sobie kilka pojęć:

- Artykuł możesz przeczytać lub posłuchać - materiał dostępny na youtube.

Co tu się odterraformowało...

Na początek by móc dodać moduły do mojej konfiguracji i go obsłużyć, muszę usunąć obecny stan konfiguracji. Dlaczego muszę to zrobić - już wyjaśniam.

Gdybym pozostawił stan terraforma i obecna konfigurację przeniósł do modułu czyli do podkatalogu modules i do mojego podkatalogów (./modules/myovh) - to terreform tą zmianę wykryłby jako nowe rekordy które, chcę dodać - a mi zależy na tym by one zostały wciągnięte bez zmiany mojego stanu w OVH. Nie chcę robić żadnej modyfikacji. Co zatem powinienem zrobić? Może przykład lepiej to zademonstruje:

Mój obecny stan z poprzedniego materiału wywołujemy go po przez polecenie terraform state list - jest to polecenie które pokaże Ci aktualny stan w backendzie - czytaj w pliku ze stanem. Backendów możemy mieć kilka rodzaji, ja osobiście mam w bazie danych postgreSQL.

terraform state list

Polecenie terraform plan, mówi mi że wszystko jest okej i mój stan trzymany w backend zgadza się z tym w plikach konfiguracyjnych, a zatem nie dokonuje żadnej modyfikacji czy zmiany na plus lub minus. W samym terraform mamy zmiany rozróżniane jako:

• dodanie - jest to zawsze nowy zasób

• zmiana - jest to zmiana aktualnego zasobu

• usuwanie - jest to usunięcie zasobu - nie będzie on już istniał

Jednak gdy przeniosę moja konfiguracje (plik .auto.ftvars i providers) terraforma do głównego folderu repo a folder ovh przerobie na moduł by tylko zawierał konfigurację OVH + skrypty do importu mój stan się zmieni.

Co dokładnie przeniosłem i gdzie:

• Do głownego katalogu tylko pliki providers i .auto.tfvars

• resztę tak jak była pozostawiam w katalogu ovh (którego zmienią nazwę na myovh - by uniknąć tego by moduł nazywał sie tak samo jak provider czyli ovh),

• a i usunę katalog .terraform ponieważ nie będzie mi on już potrzebny. Jego lokalizacja się zmieni po przez wydanie polecenia terraform init.

terraform init

Wydanie teraz polecenia terraform init w głownym katalogu repozytorium jest potrzebne w celu zainicjalizowania naszego terraforma oraz pobrania odpowiednich modułów i providerów do naszej konfiguracji. Inicjalizuje się tez nasz backend - widzimy więc że jest to dość ważne polecenie i zalecam wydanie jego chociaż raz na samym początku pracy z naszym repo oraz zawsze gdy dokonamy modyfikacji naszego providera, backendu i modułu.

Katalog .terraform też ten jest uwzględniony w .gitignore zatem nie ma go w repo więc jest tylko plikiem tymczasowym dla mnie.

Teraz moje ułożenie plików i katalogów przedstawia się w następujący sposób.

Jeszcze na tym etapie nie mamy naszego modułu, ale z racji tego że zmieniliśmy ścieżkę naszej konfiguracji i teraz nie mamy informacji o naszych plikach z konfiguracją. Nasz terraform plan sugeruje że chcemy lub zamierzamy usunąć wszystkie nasze rekordy. Jeżeli wydałbym terraform apply to usunąłbym moje rekordy z konfiguracja mojej zony w OVH. Terraform nie rozumie że chcem przerobic moje zabrane informacje na moduł - muszę mu o tym powiedzieć.

Spróbujmy teraz to naprawić

Przygotujmy zatem nasz moduł. Przyjmuje się że moduły, które chcę stworzyć i używać w moim terraformie umieszczamy w katalogu modules. Czyli nasza ścieżka będzie wyglądać teraz tak:

./modules/myovh

Używanie modułu w terraform też jest proste. Tworzę plik main.tf w którym dam informacje o tym że chcę użyć tego modułu. Czyli zaciagne informacje o moich dodatkowych plikach konfiguracyjnych mojej infrastruktury. Dodanie później kolejnego modułu na przykład z inną konfiguracja jest analogiczne, modyfikujemy tylko wartość source i nazwę dla naszego modułu.

module "myovh" {
    source = "./modules/myovh"
}

Jeszcze raz wydaję polecenie terraform init i przeanalizujmy błąd który mi się pokaże.

By zrozumieć ten błąd należy pamiętać że, terraform używa modułu i ściąga do niego providera na bazie tego co opiszesz w pliku provider w module - tak moduły są niezależne i muszą mieć podanego providera. Choć dobrze on tu podpowiada jak widać na zrzucie ekranu wyżej to nie szuka go w ścieżce dostępnych providerów ovh/ovh tylko hashicorp/ovh i takiego providera po prostu nie ma. Nie pozostaje nam nic innego jak wskazać mu tego providera. Dodajemy informacje w pliku provider z poziomu katalogu modułu (w jego katalogu) - czyli ./modules/myovh

terraform {
  required_providers {
    ovh = {
      source = "ovh/ovh"
    }
  }
}

Taka ciekawostka jeszcze taka - że informacje o samym provider możemy przekazać przez moduł w jego inicjalizacja w naszym pliku main.tf ale o tym w innym materiale.

Teraz dzięki tym informacja polecenie terraform init wykona się bez problemu.

Nasz moduł już funkcjonuje i działa o czym zaraz się przekonany wydając polecenie terraform plan. Dzieje się tak dlatego że nasze rekordy mają inną konfigurację w stanie a widać to dobrze na tych dwóch zrzutach ekranu poniżej.

Widzimy że w naszym stanie nasze rekordy (zasoby), wpisy maja inna nazwę poczatkową -

• ovh_domin_zone_rekord.... - w stanie w naszym backend

• a te z modułu module.myovh.ovh_domain_zone_record...

Mała różnica a jaka znacząca. I dlatego terraform plan chce byśmy 23 zasoby dodali i 23 usunęli. Można powiedzieć wszystko się zgadza ale nie do końca. Będzie to zmiana i nasze zony będą miały już inne ID. Plus takie majstrowanie mogłoby zaburzyć dobre rozpoznawanie naszego DNS przez inne DNS. I spowodować chwilowy down time naszych stron czy serwisów działających na konfigurowanej strefie DNS. Plus zależy nam na imporcie a nie usuwaniu i tworzeniu nowych rekordów. Dlatego musimy to naprawić.

Usuwamy zatem nasz stan by nasza operacja usuwania zniknęła. I pozostanie nam tylko raz jeszcze zaimportować aktualny stan naszej zony do stanu poprzez nasz skrypt co robiliśmy w poprzednim materiale z mała delikatną zminą

Jedyne co pewne w IT to zmiana

terraform state rm $(terraform state list)

Wydanie tego polecenia usunie nasze rekordy ze stanu z naszego backendu i będziemy mogli zaimportować nasz stan z naszego modułu i podmapować istniejącą konfigurację z naszej strefy DNS w OVH.

Tak jak wspomniałem musimy lekko zmodyfikować nasz skrypt do importu istniejącej konfiguracji z OVH i przetłumaczyć go na terraforma.

Drobne modyfikacje tylko w naszych plikach *.sh tak by kontekst w skryptach się zmienił i dalej dobrze importował nasz stan.

Wywołanie teraz naszego skryptu bedzie w postaci ./modules/<nazwa_modułu_katalogu>/00_generate_tf.sh

Uruchamiamy nasz skrypt i po zakończeniu jego działania wydajemy polecenie terraform plan. Ukazuje nam się informacja że nie ma zmian w naszej infrastrukturze. Jest to dla nas dobra informacja. Mamy konfigurację z OVH w pliku terraform i jest ona dobrze zaimportowana.

Tak teraz przedstawia się wygląd mojej struktury katalogów i plików w repozytorium.

Zakończenie

W tym wpisie to wszystko - w następnym materiale dodamy sobie jeszcze coś z digitalocean i tchneimy bardziej namacalne życie w moja konfigurację. Daj znać co myslisz o wpisie. Pozdrawiam do usłyszenia.