Integracja z Terraform

Hashicorp Terraform to narzędzie typu open source IaC (infrastructure-as-Code), które pozwala na automatyzację tworzenia, modyfikowania oraz usuwania infrastruktury w różnych chmurach. Dzięki Terraform'owi możemy zdefiniować naszą infrastrukturę lub środowisko w postaci kodu.

Integracja i możliwości Terraform'a

Terraform to popularne narzędzie do automatyzacji infrastruktury, które pozwala definiować i zarządzać zasobami infrastrukturalnymi w sposób deklaratywny. Integracja Terraforma z VMware Cloud Director (VCD) może dostarczyć wiele korzyści, umożliwiając zarządzanie zasobami w chmurze VCD za pomocą kodu, a także zapewniając elastyczność i powtarzalność operacji infrastrukturalnych.

Obsługiwana jest także usługa Cloud Director Service (CDS).

Oto kilka możliwości integracji Terraforma z VMware Cloud Director:
1. Tworzenie i zarządzanie maszynami wirtualnymi (VMs): Terraform pozwala zdefiniować pliki konfiguracyjne, które opisują, jakie wirtualne maszyny powinny być utworzone, w jakim centrum danych, sieci i z jakimi parametrami (np. CPU, RAM). Dzięki temu możesz w łatwy sposób skalować swoją infrastrukturę w chmurze VCD w zgodzie z potrzebami aplikacji.
2. Tworzenie i zarządzanie sieciami: Terraform umożliwia tworzenie i zarządzanie sieciami w VMware Cloud Director, co obejmuje konfigurowanie reguł firewall, VPN i innych elementów sieciowych.
3. Zarządzanie zasobami VCD:
1. Zarządzanie użytkownikami i uprawnieniami: Terraform może pomóc w automatycznym przypisywaniu uprawnień do różnych zasobów w VMware Cloud Director dla użytkowników i grup.
2. Tworzenie katalogów: Możesz użyć Terraform'a do automatycznego tworzenia katalogów VCD i przypisywania do nich zasobów.
4. Tworzenie i zarządzanie vApps: Terraform pozwala na tworzenie vApp'ów i zarządzanie nimi, co jest przydatne do pakowania i dostarczania aplikacji w chmurze VCD.
5. Kontrola wersji infrastruktury: Dzięki korzystaniu z Terraform'a, można trzymać konfiguracje infrastruktury w repozytorium kodu, co ułatwia śledzenie zmian, dokładne udokumentowanie infrastruktury oraz przywracanie do wcześniejszych wersji w razie potrzeby.
6. Automatyzacja cyklu życia aplikacji: Terraform pozwala na definiowanie kompletnych środowisk w chmurze VCD, od infrastruktury po oprogramowanie. To pozwala na łatwe replikowanie i tworzenie identycznych środowisk testowych, deweloperskich i produkcyjnych.
7. Integracja z innymi narzędziami: Możesz integrować Terraform'a z narzędziami do ciągłej integracji (CI) i dostarczania (CD), takimi jak Jenkins, GitLab CI/CD, czy Travis CI, aby automatyzować procesy dostarczania aplikacji do środowisk VCD.
8. Monitorowanie i raportowanie: Terraform może być używany wraz z innymi narzędziami do monitorowania i zarządzania infrastrukturą, aby zapewnić wydajność i niezawodność środowisk działających w VMware Cloud Director.

Warto zaznaczyć, że integracja Terraforma z VMware Cloud Director wymaga odpowiedniej konfiguracji, dostępu i uwierzytelniania, co zapewnia bezpieczeństwo operacji zarządzania infrastrukturą.

Możliwości połączenia

Wstępna konfiguracja provider'a (dostawcy)

1. Na początek ustalamy wersję i dostawcę chmury. Jak wiemy, Chmura 2.0 działa w oparciu o rozwiązanie VMware Cloud Director (VCD), poniżej znajduje się przykładowy kod ustalenia provider'a (dostawcy) dla Chmury 2.0.

1
2
3
4
5
6
7
8

terraform {
  required_providers {
    vcd = {
      source = "vmware/vcd"
      version = "3.10.0"
    }
  }
}

W powyższym kodzie możemy wyróżnić source = "vmware/vcd", który definiuje dostawcę rozwiązania chmurowego, a także version = "3.10.0", który definiuje ustaloną wersję.

2. Następnie przechodzimy do dokładnej konfiguracji poświadczeń logowania, a także metody autoryzacji. Poniżej znajduje przykład środowiska testowego, które posłuży jako przykład kodu konfiguracji dla poszczególnych autoryzacji.

Na powyższym obrazku możemy wyróżnić elementy takie jak:
- TEST-DOKB2 - to nazwa VDC, w którym będziemy wprowadzać zmiany, dodawać maszyny, sieci i podsieci itp.
- Test-DOKB - to nazwa organizacji, do której przynależy nasze VDC i w którym mogą znajdywać się inne, o ile takie posiadamy.
- chmuratst.netia.pl - to bezpośredni link do chmury, na której znajduje się nasza organizacja i VDC.

Ustalanie podstawowych zmiennych środowiskowych

Dla utrzymania porządku w naszym kodzie warto rozważyć wprowadzenie poszczególnych zmiennych. Dla późniejszej konfiguracji poświadczeń logowania jak i metody autoryzacji będziemy używać poniższych zmiennych.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

variable "vcd_user" {
  type = string
}

variable "vcd_pass" {
  type = string
}

variable "vcd_auth_type" {
  type = string
}

variable "vcd_token" {
  type = string
}

variable "vcd_api_token" {
  type = string
}

variable "vcd_org" {
  type = string
}

variable "vcd_vdc" {
  type = string
}

variable "vcd_url" {
  type = string
}

W powyższym kodzie możemy wyróżnić każdą ze zmiennych środowiskowych: vcd_user, vcd_pass, vcd_auth_type, vcd_token, vcd_api_token, vcd_org, vcd_vdc oraz vcd_url.

Gdzie zmienna vcd_auth_type jest zależna od metody autoryzacji, którą zdecydujemy się wybrać podczas konfiguracji.

Zmienna vcd_token wymagana jest podczas autoryzacji przy pomocy bearer tokena.

Zmienna vcd_api_token wymagana jest podczas autoryzacji przy pomocy tokena API.

Przykładowe podstawowe dane za zmiennymi

Każda z nich została określona poniżej zgodnie z wcześniej założonym przykładem użytego środowiska z pominięciem vcd_auth_type, vcd_token oraz vcd_api_token:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

vcd_user = "uzytkownik@domena.pl"

vcd_pass = "bezpiecznehaslo123"

vcd_auth_type = "wybrana metoda autoryzacji"

vcd_token = "wygenerowany token autoryzacji"

vcd_api_token = "wygenerowany token API"

vcd_org = "Test-DOKB"

vcd_vdc = "TEST-DOKB2"

vcd_url = "https://chmuratst.netia.pl/api"

Połączenie poprzez autoryzujący bearer token

Połączenie to możliwe jest przy zastosowaniu tokena autoryzującego, który zastępuje naszą nazwę użytkownika oraz hasło.

10
11
12
13
14
15
16
17
18
19
20

provider "vcd" {
  user                 = "none"
  password             = "none"
  auth_type            = var.vcd_auth_type
  token                = var.vcd_token
  org                  = var.vcd_org
  vdc                  = var.vcd_vdc
  url                  = var.vcd_url
  max_retry_timeout    = 60
  allow_unverified_ssl = true
}

W powyższym kodzie możemy zauważyć, że w przypadku użycia bearer tokena pola user i password będą ignorowane, ale nie można ich usunąć z kodu.

Oprócz powyższego, w zmiennej vcd_auth_type powinniśmy zdefiniować:

5

vcd_auth_type = "token"

Dodatkowo, należy odpowiednio zdefiniować vcd_token.

7

vcd_token = "wygenerowany token autoryzacji"

Bearer token jest kodowany w Base64, poniżej znajduje się przykładowy token do Chmury 2.0:

1

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Połączenie poprzez autoryzujący token API

Połączenie to możliwe jest przy zastosowaniu tokena autoryzującego API lub pliku z takim tokenem, który zastępuje naszą nazwę użytkownika oraz hasło.

Wraz z wersjami VCD 10.3.1+ możesz połączyć się za pomocą tokena API. Token zostanie utworzony i automatycznie użyty przez providera (dostawcę) Terraform po dostarczeniu tokena API.

10
11
12
13
14
15
16
17
18
19
20

provider "vcd" {
  user                 = "none"
  password             = "none"
  auth_type            = var.vcd_auth_type
  api_token            = var.vcd_api_token
  org                  = var.vcd_org
  vdc                  = var.vcd_vdc
  url                  = var.vcd_url
  max_retry_timeout    = 60
  allow_unverified_ssl = true
}

W powyższym kodzie możemy zauważyć, że w przypadku użycia tokena API pola user i password będą ignorowane, tak samo jak przy użyciu bearer tokena.

Oprócz powyższego, w zmiennej vcd_auth_type powinniśmy zdefiniować:

5

vcd_auth_type = "api_token"

Dodatkowo, należy odpowiednio zdefiniować vcd_api_token.

9

vcd_api_token = "wygenerowany token API"

Autoryzacja poprzez plik z tokenem API

W przypadku zdecydowania się na metodę autoryzacji tokena API istnieje możliwość wprowadzenia takiego tokena jako osobnego pliku.

10
11
12
13
14
15
16
17
18
19
20

provider "vcd" {
  user                 = "none"
  password             = "none"
  auth_type            = var.vcd_auth_type
  api_token            = "token.json"
  org                  = var.vcd_org
  vdc                  = var.vcd_vdc
  url                  = var.vcd_url
  max_retry_timeout    = 60
  allow_unverified_ssl = true
}

W powyższym kodzie możemy zauważyć, że oprócz ignorowanych pól user i password z góry określamy api_token jako osobny plik, np. token.json.

Oprócz powyższego, w zmiennej vcd_auth_type powinniśmy zdefiniować:

5

vcd_auth_type = "api_token_file"

Dodatkowo należy utworzyć plik token.json, w którym umieścimy nasz wygenerowany token API. Plik ten musi być do odczytu i zapisu, w formacie .json:

1

{"refresh_token":"7bRTRHEhGAZHjx57qYmlEwG6O3YDEqV2"}

7bRTRHEhGAZHjx57qYmlEwG6O3YDEqV2 to przykładowy token API.

Połączenie jako System Administrator lub Organization Administrator

Jest to jedna z najbardziej powszechnych opcji połączeń. Połączenie to możliwe jest przy zastosowaniu danych do logowania użytkownika o uprawnieniach System Administrator lub Organization Administrator.

10
11
12
13
14
15
16
17
18
19

provider "vcd" {
  user                 = var.vcd_user
  password             = var.vcd_pass
  auth_type            = var.vcd_auth_type
  org                  = var.vcd_org
  vdc                  = var.vcd_vdc
  url                  = var.vcd_url
  max_retry_timeout    = 60
  allow_unverified_ssl = true
}

W powyższym kodzie możemy zauważyć, że w tym przypadku niezbednym jest użycie zmiennych vcd_user i vcd_password. Zmienne te powinny zostać zdefiniowane odpowiednimi danymi, np.:

1
2
3

vcd_user = "uzytkownik@domena.pl"

vcd_pass = "bezpiecznehaslo123"

Oprócz powyższego, w zmiennej vcd_auth_type powinniśmy zdefiniować:

5

vcd_auth_type = "integrated"

Praktyczne zastosowanie Terraform'a w Chmurze 2.0

Po poprawnej konfiguracji poświadczeń i wyborze odpowiedniego sposobu połączenia przechodzimy do wykonania testu w praktyce.

Zadanie do wykonania

• Posiadamy utworzoną organizację Test-DOKB
  • Posiadamy utworzone VDC TEST-DOKB2
  • Posiadamy utworzony EDGE edge-Test-DOKB
• Utworzymy vApp Terraform-App
  • Utworzymy 3 wirtualne maszyny cvm-01, cvm-02 i cvm-03
    • System: Ubuntu Server 20.04
    • CPU: 9 GHz
    • RAM: 3072 MB
    • Dysk S1: 60 GB
    • Sieć routed_172.16.10.0
  • Podłączymy sieć routed_172.16.10.0 do vApp typem sieci Direct
• Utworzymy Data Center Group terra-group01
• Utworzymy sieć typu Routed routed_172.16.10.0
  • Gateway CIDR: 172.16.10.1/28
  • Statyczna pula adresów IP: 172.16.10.5 - 172.16.10.15
  • Przypiszemy powyższe adresy zakresem POOL do utworzonych maszyn wirtualnych

Struktura kodu

Do wykonania zadania zostały utworzone odpowiednie pliki aby utrzymać porządek i podział w kodzie. W ich skład wchodzą:
- main.tf,
- common.tf,
- app.tf,
- variables.tf,
- terraform.tfvars.

main.tf

Główny plik, w którym znajduje się konfiguracja połączenia Terraform'a z Chmurą 2.0.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

terraform {
  required_providers {
    vcd = {
      source = "vmware/vcd"
      version = "3.10.0"
    }
  }
}

provider "vcd" {
  user                 = var.vcd_user
  password             = var.vcd_pass
  auth_type            = var.vcd_auth_type
  org                  = var.vcd_org
  vdc                  = var.vcd_vdc
  url                  = var.vcd_url
  max_retry_timeout    = 60
  allow_unverified_ssl = true
}

W powyższym kodzie możemy zauważyć, że wybrana została metoda połączenia jako System Administrator.

common.tf

Drugi plik, w którym znajduje się konfiguracja terra-group01, routed_172.16.10.0.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

data "vcd_org_vdc" "new-vcd-org-vdc" {
  name = var.vcd_vdc
}

resource "vcd_vdc_group" "new-vdc-group" {
  org                   = var.vcd_org
  name                  = var.vcd_new-vdc-group-name
  starting_vdc_id       = data.vcd_org_vdc.new-vcd-org-vdc.id
  participating_vdc_ids = [var.vcd_participating_vdc_ids]
  dfw_enabled           = true
  default_policy_status = true
}

resource "vcd_nsxt_edgegateway" "current-nsxt-edgegateway" {
  org      = var.vcd_org
  name     = var.vcd_current-nsxt-edgegateway-name
  external_network_id = var.vcd_external_network_id
}

resource "vcd_network_routed_v2" "edge01_routed01" {
  edge_gateway_id = resource.vcd_nsxt_edgegateway.current-nsxt-edgegateway.id
  name            = var.vcd_edge01_routed01-name
  gateway         = var.vcd_edge01_routed01-gateway
  prefix_length   = var.vcd_edge01_routed01-prefix

  static_ip_pool {
    start_address = var.vcd_edge01_routed01-start_address
    end_address   = var.vcd_edge01_routed01-end_address
  }
}

W powyższym kodzie określone są między innymi:
- zainicjowanie utworzonego wcześniej EDGE, którego nie chcemy modyfikować,
- utworzenie nowej grupy VDC o nazwie terra-group01,
- utworzenie nowej sieci typu routed o nazwie routed_172.16.0.0.

app.tf

Trzeci plik, w którym znajduje się konfiguracja Terraform-App, cmv-01, cvm-02, cvm-03.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

resource "vcd_vapp" "dev_vapp" {
  name = var.vcd_dev_vapp-name
}

resource "vcd_vapp_org_network" "dev_vapp_org_net_edge01_routed01" {
  vapp_name        = vcd_vapp.dev_vapp.name
  org_network_name = resource.vcd_network_routed_v2.edge01_routed01.name
}

resource "vcd_vapp_vm" "vapp_cvm_dev" {
  count            = var.vcd_vapp_cvm_dev-count
  vapp_name        = vcd_vapp.dev_vapp.name
  name             = "cvm-0${count.index + 1}"
  computer_name    = "cvm-0${count.index + 1}"
  description      = "Compute Virtual Machine ${count.index + 1}"
  memory           = var.vcd_vapp_cvm_dev-memory
  cpus             = var.vcd_vapp_cvm_dev-cpus
  cpu_cores        = 1
  os_type          = var.vcd_vapp_cvm_dev-os_type
  hardware_version = var.vcd_vapp_cvm_dev-hardware_version
  vapp_template_id = var.vcd_vapp_template_id
  vm_name_in_template = var.vcd_vm_name_in_template

  override_template_disk {
  bus_type        = "paravirtual"
  size_in_mb      = var.vcd_vapp_cvm_dev-disk
  bus_number      = 0
  unit_number     = 0
  iops            = 0
  storage_profile = "*"
  }

  network {
  type               = "org"
  name               = resource.vcd_network_routed_v2.edge01_routed01.name
  ip_allocation_mode = "POOL"
  }
}

W powyższym kodzie określone są między innymi:
- utworzenie nowego vApp o nazwie Terraform-App,
- utworzenie nowych maszyn wirtualnych w utworzonym vApp'ie o nazwach cmv-01, cvm-02, cvm-03 o określonych zasobach,
- połączenie vApp'a i maszyn wirtualnych z wcześniej utworzoną siecią.

variables.tf

Czwarty plik, w którym znajduje się konfiguracja zmiennych środowiskowych.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95

variable "vcd_user" {
  type = string
}

variable "vcd_pass" {
  type = string
}

variable "vcd_auth_type" {
  type = string
}

variable "vcd_org" {
  type = string
}

variable "vcd_vdc" {
  type = string
}

variable "vcd_url" {
  type = string
}

variable "vcd_external_network_id" {
  type = string
}

variable "vcd_vapp_template_id" {
  type = string
}

variable "vcd_vm_name_in_template" {
  type = string
}

variable "vcd_participating_vdc_ids" {
  type = string
}

variable "vcd_new-vdc-group-name" {
  type = string
}

variable "vcd_current-nsxt-edgegateway-name" {
  type = string
}

variable "vcd_edge01_routed01-name" {
  type = string
}

variable "vcd_edge01_routed01-gateway" {
  type = string
}

variable "vcd_edge01_routed01-prefix" {
  type = number
}

variable "vcd_edge01_routed01-start_address" {
  type = string
}

variable "vcd_edge01_routed01-end_address" {
  type = string
}

variable "vcd_dev_vapp-name" {
  type = string
}

variable "vcd_vapp_cvm_dev-count" {
  type = number
}

variable "vcd_vapp_cvm_dev-os_type" {
  type = string
}

variable "vcd_vapp_cvm_dev-hardware_version" {
  type = string
}

variable "vcd_vapp_cvm_dev-memory" {
  type = number
}

variable "vcd_vapp_cvm_dev-cpus" {
  type = number
}

variable "vcd_vapp_cvm_dev-disk" {
  type = string
}

W powyższym kodzie określone są wszystkie zmienne użyte w poprzednich plikach, pod którymi kryją się dane wrażliwe. Plik ten został rozszerzony o niezbędne zmienne, które są wykorzystywane do realizacji zadania.

terraform.tfvars

Piąty plik, w którym znajdują się dane wrażliwe poszczególnych zmiennych na podstawie danych z poniższego środowiska, a także danych z Chmury 2.0.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

vcd_user = "uzytkownik@domena.pl"

vcd_pass = "bezpiecznehaslo123"

vcd_auth_type = "integrated"

vcd_org = "Test-DOKB"

vcd_vdc = "TEST-DOKB2"

vcd_url = "https://chmuratst.netia.pl/api"

vcd_external_network_id = "urn:vcloud:network:6e1a7943-4391-466c-a5f8-2ccf245b07fb"

vcd_vapp_template_id = "Template TSTVC3"

vcd_vm_name_in_template = "Ubuntu-20.04.3-x86"

vcd_participating_vdc_ids = "urn:vcloud:vdc:03e2c662-746e-404d-9e54-673c1f6121f4"

vcd_new-vdc-group-name = "terra-group01"

vcd_current-nsxt-edgegateway-name = "edge-Test-DOKB"

vcd_edge01_routed01-name = "routed_172.16.10.0"

vcd_edge01_routed01-gateway = "172.16.10.1"

vcd_edge01_routed01-prefix = 28

vcd_edge01_routed01-start_address = "172.16.10.5"

vcd_edge01_routed01-end_address = "172.16.10.15"

vcd_dev_vapp-name = "Terraform-App"

vcd_vapp_cvm_dev-count = 3

vcd_vapp_cvm_dev-os_type = "ubuntu64Guest"

vcd_vapp_cvm_dev-hardware_version = "vmx-19"

vcd_vapp_cvm_dev-memory = 3072

vcd_vapp_cvm_dev-cpus = 3

vcd_vapp_cvm_dev-disk = "61440"

W powyższym kodzie ostatniego pliku z całego zadania określone są wszystkie dane wrażliwe, które nie powinny trafić do każdego użytkownika, dlatego powyższe dane powinny być traktowane jako przykład.

Repozytorium na Github

Bezpośredni link do repozytorium na Github z opisem i przykładowym kodem:
github/criston37/terraform-vmware-cloud-director

Polecenia i inicjacja kodu

1. Inicjację i rozpoczęcie pracy Terraform'a rozpoczynamy w Terminalu, po wcześniejszym napisaniu pełnego kodu naszego środowiska.

Inicjacje przeprowadzamy za pomocą komendy:

terraform init

2. Na potrzeby wykonania zadania na Chmurze 2.0 musimy na początek zimportować EDGE, którego nie chcemy w żaden sposób zmodyfikować.

Import edge-Test-DOKB przeprowadzamy za pomocą polecenia:

terraform import vcd_nsxt_edgegateway.current-nsxt-edgegateway Test-DOKB.TEST-DOKB2.edge-Test-DOKB

3. Następnym krokiem będzie wykonanie i sprawdzenie planu inicjacji całego tworzonego środowiska.

W tym celu należy użyć polecenia:

terraform plan

4. Ostatnim krokiem będzie zatwierdzenie zaplanowanego wcześniej środowiska i jego budowa na Chmurze 2.0.

Polecenie zatwierdzające wcześniej zrobiony plan to:

terraform apply

Budowa środowiska na Chmurze 2.0

Perspektywa tworzenia całego środowiska ze strony Chmury 2.0 po użyciu polecenia terraform apply i zatwierdzeniu go poleceniem yes.

Jak możemy zauważyć, całe środowisko tworzone jest w czasie rzeczywistym po zastosowaniu polecenia terraform apply.

Podsumowanie, zalety i wady

Zalety używania Terraform'a w środowiskach VMware Cloud Director

1. IaC (Infrastructure as Code):
   • Zaleta: Terraform umożliwia definiowanie infrastruktury w kodzie, co ułatwia zarządzanie infrastrukturą jako kodem (IaC). Możesz tworzyć, zmieniać i usuwać zasoby infrastrukturalne w sposób deklaratywny.
2. Automatyzacja:
   • Zaleta: Terraform pozwala na automatyzację tworzenia i zarządzania zasobami w VCD, co może przyspieszyć proces wdrażania i zapewnić spójność środowiska.
3. Kontrola wersji:
   • Zaleta: Terraform integruje się z systemami kontroli wersji, co umożliwia śledzenie zmian w infrastrukturze i cofanie do wcześniejszych wersji w razie potrzeby.
4. Wsparcie dla wielu dostawców:
   • Zaleta: Terraform obsługuje wiele dostawców chmur i platform, w tym VCD, co pozwala na zarządzanie infrastrukturą wielu dostawców za pomocą jednego narzędzia.
5. Modułowość:
   • Zaleta: Terraform pozwala na tworzenie modułów, które można wielokrotnie używać w różnych projektach, co zwiększa ponowne wykorzystanie kodu i upraszcza zarządzanie infrastrukturą.

Wady używania Terraform'a w środowiskach VMware Cloud Director

1. Skomplikowana konfiguracja:
   • Wada: Konfiguracja Terraform'a do pracy z VCD może być skomplikowana, a dostosowanie dostawcy VCD i uwzględnienie szczegółów konkretnego środowiska może wymagać zaawansowanej wiedzy.
2. Złożone zależności:
   • Wada: W niektórych scenariuszach tworzenia infrastruktury w VCD mogą występować złożone zależności między zasobami, co może stanowić wyzwanie przy definiowaniu odpowiedniej kolejności tworzenia i usuwania zasobów.
3. Ryzyko nadpisania istniejących zasobów:
   • Wada: Terraform, gdy źle skonfigurowany lub użyty nieostrożnie, może próbować nadpisać istniejące zasoby w VCD. Dlatego istnieje ryzyko utraty danych lub konfiguracji.
4. Brak wsparcia ze strony dostawcy VCD:
   • Wada: Terraform to narzędzie spoza ekosystemu VMware, więc dostawca VCD nie zapewnia oficjalnego wsparcia technicznego dla problemów związanych z Terraform'em.
5. Złożoność rozwiązań wieloskryptowych:
   • Wada: W środowiskach, gdzie infrastruktura jest zarządzana za pomocą wielu narzędzi lub skryptów, dodanie Terraform'a jako kolejnego narzędzia może zwiększyć złożoność środowiska.

Podsumowując, Terraform może być potężnym narzędziem do zarządzania infrastrukturą w środowiskach VMware Cloud Director, ale jego skomplikowana konfiguracja i potrzeba ostrożności w celu uniknięcia przypadkowego nadpisywania istniejących zasobów stanowią wyzwanie.

Przydatne linki

Terraform - Mainpage
Terraform VMware Cloud Director - Registry
Terraform VMware Cloud Director - Github
Terraform VMware Cloud Director - Exmaples
VMware Cloud Director - Mainpage
VMware Cloud Director - Documentation