Dzień dobry, mam nadzieje, że macie się dobrze i nie przestajecie się uczyć :)

Dzisiaj zapraszam Was na naukę terraforma, który pozwala tworzyć zasoby w chmurze. Jeśli początek Was przestraszył, nie martwcie się, zaczniemy od banałów.

Co to jest ta chmura?

Chmura

Ta mistyczna chmura to po prostu zasoby (serwery, dyski twarde, wirtualne sieci itd.) które możesz dynamicznie wypożyczać/tworzyć w zależności od potrzeb. W większości przypadków płacisz dokładnie za tyle, ile używasz. Jeśli twoja aplikacja ma ruch zwiększony od 16:00 do 19:00 to na ten czas możesz zarezerwować więcej RAMU czy silniejsze CPU dla twojego serwera (co jest trudne w przypadku zwykłego hostingu).

Najpopularniejszymi rozwiązaniami tego typu są Amazon Web Services (AWS), Microsoft Azure oraz Google Cloud. Dzisiaj będziemy korzystać z AWSa, chociaż HCL - jako język - jest uniwersalnym medium.

Infrastructure as a code

Skoro można tak dynamicznie zmieniać zasoby i stawiać środowiska to pojawia się pytanie jak to zrobić. Kiedyś "goście od serwerów" instalowali systemy operacyjne/narzędzia/interpretery, obecnie przesuwa się tę pracę w stronę zespołu programistycznego. Dzięki temu jest w stanie stworzyć i udostępnić aplikację samodzielnie.

Infrastructure as a code to nazwa podejścia w którym piszemy kod, który po wywołaniu tworzy zasoby w chmurze.

A jeśli kod to w jakim języku? Większość dostawców udostępnia swoje narzędzia (API/CLI/etc.) w Javie, C#, JavaScriptcie, ale nie ma wsparcia dla każdego więc powstał unikalny język do tworzenia zasobów w chmurze, czyli HCL.

HCL

Przedmiotem dzisiejszego wpisu jest HCL, czyli HashiCorp Configuration Language na przykładzie użycia w chmurze AWS. Zapoznamy się z jego strukturą.

HCL

HCL posiada dwie podstawowe struktury danych: argumenty oraz bloki.

Argumenty

Argumenty służą do przypisywania wartości do zmiennej.  Nazwa zmiennej może zawierać liczby, litery oraz znaki specjalne: - oraz _.

name = "solutionchaser"
author_name = "kamila"

Bloki

Bloki tworzą struktury danych za pomocą zagnieżdżonych klamer {}:

resource "typStruktury" "nazwaWłasnaStruktury" {
  zmienna = "Hello World"

  struktura wewnętrzna {
    # ...
  }
  tablica = ["kot", "pies"]
}

Komentarze

Z pewnością zauważyliście komentarz w powyższym przykładzie, więc udokumentujmy to jeszcze raz:

# komentarz jednolinijkowy, ten jedyny słuszny
// komentarz jednolinijkowy, nierekomendowany, stworzony żeby trudniej było utrzymać porządek w kodzie
/* komentarz
wielolinikowy */

Terraform

Najpierw polecam zainstalowanie terraforma na naszym komputerze. Jeśli korzystasz Linuxa to będzie to:

snap install terraform

Komendy na inne systemy operacyjne możesz znaleźć pod tym linkiem. Ogólnie polecam zainstalować również tfenv, jeśli zamierzacie używać terraforma pracując w zespole. Pozwala on zmieniać obecnie używaną wersję terraforma.

Dobrze, już powinna zakończyć się instalacja. Poleceniem terraform --help zweryfikujesz czy działa poprawnie.

Terraform to akurat jedna z najprostszych technologii jakie znam. Musisz znać 4 komendy, żeby zacząć:

• terraform init - inicjalizuje stan (zaraz powrócimy do tego ważnego słowa)
• terraform plan - porównuje obecny stan oraz ten który napisaliśmy przez nasz kod i generuje plan zmian
• terraform apply - tworzyć/usuwa/edytuje zasoby w chmurze i zmienia stan
• terraform destroy - niszczy wszystkie zasoby w chmurze zapisanie w stanie
• terraform fmt - formatuje pliki z rozszerzeniem tf

Zmienne

Są tworzone za pomocą bloku variable w którym pierwszy argument to nazwa zmiennej. Mogą mieć typ, opis oraz wartość (zadeklarowaną lub domyślną).

Standardowa deklaracja:

variable "blog" {
  default = "solutionchaser"
}

Zarówno wartość domyślną jak i brak wartości można nadpisać przy wywołaniu kodu, najczęściej przez plik .tfvars.

variable "blog" {}

variable "blog" {
  type    = string
  default = "solutionchaser"
  description = "This variable describes blog's name"
}

Powyższa deklaracja jest typowa: definiuje typ oraz dodaje opis przydatny przy czytaniu kodu oraz generowaniu dokumentacji. Poniżej mamy przykład zmiennej typu lista:

variable "favourite_food_list" {
  type    = list(string)
  default = ["kefir", "borówki"]
}

HCL korzysta z typów prostych: string, boolean, numer oraz typów złożonych: list, map, set, turple oraz object, których nie będziemy dzisiaj szczegółowo omawiać.

Zmienne lokalne (ang. locals)

Zmienne lokalne również mogą deklarować statyczne wartości, ale najczęściej używa się ich do tworzenia zmiennych z innych zmiennych. Spójrzmy na poniższy przykład:

variable "blog" {
  default = "solutionchaser"
}

locals {
  blog   = var.blog #w starszych wersjach terraforma to będzie "${var.blog}"
  domain = "${var.blog}.com"
  author = "Kamila Brylewska"
}

Dostawcy (ang. Providers)

Jak mówiłam wcześniej istnieje wielu dostawców chmury (Amazon, Microsoft etc.) i każdy ma swoje zasoby, strukturę i możliwości dlatego zwykle terraformowanie zaczynamy od zadeklarowania dostawcy.

Musimy także określić wersję sterownika, który zostanie pobrany na nasz komputer i będzie służył do komunikacji z chmurą.

Poniżej mamy przykład deklaracji Amazon Web Services jako dostawcy.

terraform {
  required_providers {
    aws = "~> 1.0"
  }
}

Zasoby (ang. Resources)

Zasoby to ładna nazwa na poszczególne usługi oferowane w chmurze takie jak - jeśli wybaczycie powtórzenia - wirtualna prywatna sieć, wirtualny dysk czy wirtualny serwer.

resource "aws_instance" "NazwaZasobuNpMojSerwerInternetowy" {
  ami           = "ciągZnaków"
  instance_type = "t2.micro" # wartości które możesz tutaj wpisać są       zdefiniowane w dokumentacji AWS
}

Dane wyjściowe (ang. output)

Terraform po stworzeniu zasobu w chmurze zwróci nam szczegóły utworzonego komponentu np.: identyfikator. Możemy go wypisać w konsoli lub użyć do stworzenia innego zasobu.

Dane (ang. Data)

Jeśli potrzebujemy informacji z chmury, na przykład identyfikatora czy nazwy jakiegoś zasobu, możemy je pobrać przy pomocy data i wykorzystać pobrane dane do stworzenia nowego elementu naszej infrastruktury.

Inne

Terraform oferuje także wbudowane funkcje oraz możliwość tworzenia/korzystania z gotowych modułów, ale opisanie tego nie jest sednem dzisiejszego wpisu.

Stwórzmy coś!

Skoro już mniej więcej wiesz co jest co, to na sucho wytłumaczę jak tworzy się zasoby w chmurze.

1. Napiszmy kod

Code as infrastructure zakłada obecność kodu, więc napiszemy kod, który utworzy wirtualny dysk dla nas. Ten dysk jest o tym fajny, że płacimy tylko za GB które zajęliśmy i za transfer danych. W Amazonie ten zasób nazywa się wiaderkiem s3 i - z pełną świadomościa jak zabawnie to brzmi - zamierzam go tak nazywać.

Mamy projekt, tworzymy folder terraform i plik s3.tf.

// plik s3.tf
terraform {
  required_providers {
    aws = "~> 1.0"
  }
}

resource "aws_s3_bucket" "MojeWiadro" {
  bucket = "moje-wiadro-solution-chaser" #unikalny identyfikator w chmurze. Jeśli go nie podasz to AWS wygeneruje nieczytelny ciąg znaków

  tags = { #tagi pomagają kategoryzować i grupować zasoby w chmurze
    Author      = "Kamila"
    Environment = "prod"
  }
}

Teraz zainicjujemy lokalny stan wykonując w folderze terraform komendę:

terraform init

Po skończeniu inicjalizacji zauważycie, że powstał folder .terraform w którym znajduje się plik z sterownikami oraz plik terraform.tfstate.

Plik tfstate jest jedynym źródłem prawdy o zbudowanej przez nas infrastrukturze. W chwili obecnej mamy go w lokalnie, ale najczęściej korzystamy z pliku w chmurze, co nazywa się backendem.

Jeśli chcemy zobaczyć jakie zmiany zostaną wprowadzone to możemy wpisać:

terraform plan

Wykonanie tej komendy pokaże nam ile zasobów zostanie stworzonych, zmienionych i usuniętych oraz dokładne zmiany.

Dobrze, to utwórzmy wirtualny dysk:

terraform apply

To jest moment w którym zostają utworzone zasoby w chmurze, aktualizuje się stan i zaczynamy ponosić koszta.

Dlatego, szczególnie w przypadku droższych zasobów, powinniście teraz wykonać:

terraform destroy

Komenda ta usunie zasoby z chmury, zaktualizuje stan oraz zakończy naukę na dzień dzisiejszy. Samą historię jak skorzystać z tego wirtualnego dysku zostawiam na inny dzień :)

Podsumowanie

Ostatnio spędzam w chmurach... znaczy w chmurze mnóstwo czasu i świetnie się bawię. To magia, że jako developer mogę utworzyć sobie środowisko swoich marzeń w kilkanaście sekund i równie szybko je usunąć.

Bardzo przepraszam za uogólnienia i zapraszam do komentowania. To niestety ułamek wiedzy z terraforma, który jest potrzebny do stworzenia infrastruktury aplikacji internetowej, nie mówiąc o doświadczeniu serwerowo-sieciowym czy projektowaniu. Niemniej jednak to dobry początek!

Mam nadzieje, że się podobało i bardzo dziękuję za uwagę. Ostatnio dostaję od Was sporo fajnego feedbacku i chciałam bardzo podziękować. Prowadzenie bloga to sama przyjemność, ale posiadanie czytelników dodaje temu uroku.

Powodzenia!