top of page

Śledź nasze wpisy w social media

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

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:



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.

104 wyświetlenia0 komentarzy

Ostatnie posty

Zobacz wszystkie

Комментарии


Ś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