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.
Comments