top of page

Śledź nasze wpisy w social media

  • Instagram
  • Facebook
  • Twitter
  • LinkedIn
  • YouTube
  • Zdjęcie autoraPiotr Kośka

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

Zaktualizowano: 17 gru 2022

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.




313 wyświetleń0 komentarzy

Ostatnie posty

Zobacz wszystkie

Comments


Śledź nasze wpisy w social media

  • Instagram
  • Facebook
  • Twitter
  • LinkedIn
  • YouTube

Poznaj terraform jedno z najepszych narzedzi do zarządzania infrastrukturą w kodzie (IaC) - w kursie tym przeprowadzam Cię przez proces instalacji i konfiguracji tego narzędzia.

bottom of page