Infrastruktura w Kodzie (IaaC) - Digital Ocean, prosty cloud na start - część trzecia.

Witam ponownie w trzeciej już części naszych (moich) zmagań z Terraform. W tym odcinku dodamy obsługę Digatal Ocean i przygotujemy nasz kod do obsługi właśnie tej infrastruktury Cloud. Ktoś pewnie zapyta dlaczego nie AWS - przecież jest bardziej popularny i szerzej wykorzystywany przez organizacje.

Oczywiście zgodze się - lecz hobbistycznie w domowym zaciszu wolę pobawić się inną platformą niż tą którą bawię się w pracy :) Work Life Balance :D :D - gotowi zaczynamy.

... a tak poprzednie dwie części znajdziesz tu:

1. Część pierwsza - Infrastruktura jako kod (IaaC) - cześć 1

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

A teraz część trzecia

Na tym etapie mamy już katalog ./modules i nasz pierwszy moduł w postaci konfiguracji OVH (w katalogu ./modules/myovh) - dzięki temu mam możliwość kontroli moich rekordów w OVH z poziomu terraforma. Jak będę potrzebował dowolnego rekordu na przykład A wystarczy że dodam taki wpis (przykład):

resource "ovh_domain_zone_record" "ID-5251866548-technicznie-nietechnicznie-cloud" {
    fieldtype = "A"
    subdomain = ""
    ttl = "0"
    target = "213.186.33.5"
    zone = "technicznie-nietechnicznie.cloud"
}

I po wydaniu polecenia terraform apply będzie on w mojej konfiguracji już wprowadzony po stronie OVH. Proste czytelne i mamy kontrolę zmian. Widzimy kto co i kiedy dodawał - oczywiście nie w samym terraform ale w naszych "commitach" do repozytorium kodu git.

Okej, teraz dodajmy sobie obsługę DigitalOcean i sprawimy że nasza konfiguracja zacznie żyć. Pojawią się pierwsze usługi, uruchomimy naszą stronę www, postawimy bazę danych i stworzymy aplikację. Ale pomalutku, dodajmy nasz pierwszy koncept czyli byt jakim jest projekt w DigitalOcean.

Obsługa Digital Ocean

Dodajemy wpis w pliku providers.tf w naszym głownym repozytorium z informacja o naszym wymaganym prowiderze:

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

    digitalocean = {
      source = "digitalocean/digitalocean"
      version = "~> 2.0"
    }
  }
  backend "pg" {
    conn_str = "połączenia do bazy danych PostgreSQL"
  }
}

Dokładnie interesuje nas ta nowa sekcja w której wybieramy nazwę dla naszego providera. Dokładnie to słowo przed znaczkiem równości. Nazwa ta jest umowna, gdybym wpisał tu "pomidor" i po tej nazwie się odwoływał wszystko by działało. Najważniejsza jest ta cześć po znaku równości. Czyli nasz source i version. Source znamy już z poprzednich dwóch części i wskazujemy tu naszego dostawcze i providera od tego dostawcy

Version określa wersję naszego provaidera jaką chcemy pobrać. Ten akurat zapis pobierze najnowszą wersje ale nie mniejsza niż 2.0. Możemy tutaj zastosować inne kombinacje.

W tym samym pliku będziemy potrzebować dodać obsługę naszego nowego providera plus deklaracja naszej zmiennej poprzez variable. Oczywiście skąd takie ustawienia można znaleźć w dokumentacji. Zatem dodajemy:

variable "do_token_youtube" {
  description = "Digital Ocean Acces token"
  sensitive = true
}

provider "digitalocean" {
  alias = "youtube-do"
  token = var.do_token_youtube
}

Sekcja variable jest już dla nas znana zawiera deklarację zmiennej plus informacje o tym że wartości w tej zmiennej będą wrażliwe i będa pokazywane za pomocą gwiazdek w outputach terraform.

To co nowe to wartość alias oraz token. Zacznijmy od tokena - to po prostu zmienna z wartością tokena do naszego konta w DigitalOcean, którego możemy utworzyć w DigitalOcean w tym miejscu:

Po utworzeniu go dodajemy wartość naszego tokena do pliku .auto.tfvars z naszymi kluczami do OVH przy wartości do_token_youtube = " " - tak jak przedstawiłem to poniżej. Plik jest uwzględniony w .gitignore wiec nie znajdzie się w naszym repozytorium podczas commitowania zmian.

# OVH
ovh_endpoint           = "ovh-eu"
ovh_application_key    = ""
ovh_application_secret = ""
ovh_consumer_key       = ""

# DigitalOcean
do_token_youtube = ""

Wróćmy do aliasa. Alias to jak nazwa wskazuje dodatkowy łącznika do wykorzystania ponownie tego samego providera i możliwość nadpisywania zmiennych w providerze w danym module. Terraform nie pozwala wielokrotnie deklarować tego samego providera nawet pod inna nazwą i daje za to mechanizm aliasów. Zatem naszym nadpisywany elementem w przypadku digitalocean będzie to token, a w przypadku ovh byłoby to odpowiednio endpoint, application_key, application_secret i consumer_key. Wykorzystanie takiego provideram bedzie w pliku main.tf jako deklaracja naszego nowego modułu:

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

module "digitalocean-youtube" {
  source = "./modules/digitalocean/youtube-do"
  providers = {
    digitalocean = digitalocean.youtube-do
  }
}

Source - wskazujemy ścieżkę do konfiguracji naszego modułu względem naszego pliku main.tf z folderu z naszym repozytorium git.

Providers - to nic innego jak lista zdefiniowanych naszych providerów połączonych przez alias

Do kompletu potrzebujemy folderu tak jak zadeklarowaliśmy to w sekcji source dla modułu digitalocean-youtube.

W tym katalogu tworzymy dwa pliki project.tf i provider.tf. Plik z provider.tf będzie zawierał informację z jakiego providera ma korzystać. Wiem troche to takie masło maślane ale tak działa terraform i jego moduły. Po prostu moduł nie wie z jakiego modułu korzysta nasz cały projekt i musimy mu to powiedzieć. A żeby nie deklarować w różnych katalogach zmiennych nasz moduł łączymy z aliasem naszego providera i zmienne są przekazywane przez te alias

terraform {
  required_providers {
    digitalocean = {
      source  = "digitalocean/digitalocean"
      version = "~> 2.0"
    }
  }
}

Plik z project.tf to już konfiguracja naszych zasobów po stronie digitalocean. Tym pierwszym zasobem będzie skonfigurowanie naszego projektu w digitalocean.

resource "digitalocean_project" "youtube-project" {
  name = "YoutubeProject"
  description = "Project for YouTube Channel"
  purpose = "Learning"
  environment = "development"
}

Taki wpis w pliku tworzy nam nowy zasób, który utworzy nam w digital ocean byt zwany projektem o parametrach opisanych w pliku terraform.

Jestesmy juz gotowi na uruchomienie i wydanie polecenia terraform init, który to zaciągnie nam wszystkie brakujące moduły i providerów do naszej konfiguracji.

Zielony komunikat "Terraform has been successfully initialized!" informacje nas że wszystko jest okej z nasz inicjalizacją.

Wydanie polecenia terraform plan pokazuje nam że polecenie terraform apply doda nasz projekt do digitalocean.

Akceptujemy naszą zmianę i po chwili widzimy jak wszystko mamy już zaimplementowane przez naszego terraforma

Zmiana została dodan. Możemy to zweryfikować wzrokowo w naszym Digital Ocean przechodząc na nasze konto i sprawdzając czy nasz projekt widnieje na liście projektów

To wszystko w tym wpisie. A konfiguracja dalsza naszych aplikacji, maszyn wirtualnych i firewall to już inna do której zajrzymy w kolejnym moim wpisie. Pozdrawiam.