W tym artykule przyjrzymy się, z czego składa się Terraform, a także stopniowo uruchomimy własną infrastrukturę — przygotujemy trzy maszyny wirtualne do różnych celów: proxy, przechowywania plików i CMS.
O wszystkim szczegółowo i w trzech etapach:
1. Terraform - opis, zalety i komponenty
Terraform to narzędzie IaC (Infrastructure-as-Code) służące do budowania i zarządzania infrastrukturą wirtualną za pomocą kodu.
Zauważyliśmy kilka zalet pracy z narzędziem:
-
Szybkość wdrażania nowych najemców (niestandardowe środowiska wirtualne). Zazwyczaj im więcej jest nowych klientów, tym więcej „kliknięć” musi wykonać personel pomocy technicznej, aby opublikować nowe zasoby. Dzięki Terraform użytkownicy mogą zmieniać ustawienia maszyny wirtualnej (na przykład automatycznie wyłączając system operacyjny i zwiększając partycję dysku wirtualnego) bez konieczności korzystania z pomocy technicznej lub wyłączania samej maszyny.
-
Natychmiastowa weryfikacja planu aktywacyjnego nowy Tennant. Korzystając z opisu kodu infrastruktury, możemy od razu sprawdzić, co i w jakiej kolejności zostanie dodane, a także w jakim stanie końcowym będzie ta czy inna maszyna wirtualna lub sieć wirtualna z połączeniami z maszynami wirtualnymi.
-
Umiejętność opisu najpopularniejszych platform chmurowych. Możesz użyć narzędzia od Amazon i Google Cloud, po platformy prywatne oparte na VMware vCloud Director, oferujące usługi w zakresie rozwiązań IaaS, SaaS i PaaS.
-
Zarządzaj wieloma dostawcami usług w chmurze i dystrybuuj infrastrukturę między sobą, aby poprawić odporność na awarie, korzystając z jednej konfiguracji do tworzenia, diagnozowania i zarządzania zasobami w chmurze.
-
Wygodne zastosowanie przy tworzeniu stanowisk demonstracyjnych do testowania i debugowania oprogramowania. Możesz tworzyć i przenosić stanowiska dla działu testowego, testować oprogramowanie w różnych środowiskach równolegle oraz błyskawicznie zmieniać i usuwać zasoby, tworząc tylko jeden plan budowy zasobów
Terraforma „Terrarium”.
Krótko omówiliśmy zalety narzędzia, teraz podzielmy je na elementy składowe
Dostawcy.
W Terraform prawie każdy rodzaj infrastruktury może być reprezentowany jako zasób. Połączenie zasobów z platformą API zapewniają moduły dostawców, które umożliwiają tworzenie zasobów w ramach konkretnej platformy, np. Azure lub VMware vCloud Director.
W ramach projektu możesz wchodzić w interakcje z różnymi dostawcami na różnych platformach.
Zasoby (opis zasobu).
Opis zasobów pozwala na zarządzanie komponentami platformy, takimi jak maszyny wirtualne czy sieci.
Możesz samodzielnie utworzyć opis zasobu dla dostawcy VMware vCloud Director i użyć tego opisu do utworzenia zasobów u dowolnego dostawcy hostingu korzystającego z vCloud Director. Wystarczy zmienić parametry uwierzytelniania i parametry połączenia sieciowego na wymaganego dostawcę usług hostingowych
Dostawcy.
Komponent ten umożliwia wykonanie operacji wstępnej instalacji i konserwacji systemu operacyjnego po utworzeniu maszyn wirtualnych. Po utworzeniu zasobu maszyny wirtualnej możesz użyć dostawców usług do konfiguracji i nawiązania połączenia przez SSH, aktualizacji systemu operacyjnego oraz pobrania i uruchomienia skryptu.
Zmienne wejściowe i wyjściowe.
Zmienne wejściowe - zmienne wejściowe dla dowolnych typów bloków.
Zmienne wyjściowe pozwalają na zapisanie wartości po utworzeniu zasobów i mogą służyć jako zmienne wejściowe w innych modułach, np. w bloku Provisioners.
Stany.
Pliki stanów przechowują informacje o konfiguracji zasobów platformy dostawcy. Kiedy platforma jest tworzona po raz pierwszy, nie ma informacji o zasobach i przed jakąkolwiek operacją Terraform aktualizuje stan z rzeczywistą infrastrukturą już opisanych zasobów.
Głównym celem stanów jest zapisanie wiązki obiektów już utworzonych zasobów w celu porównania konfiguracji dodanych zasobów i obiektów, aby uniknąć wielokrotnego tworzenia i zmian na platformie.
Domyślnie informacje o stanie przechowywane są w lokalnym pliku terraform.tfstate, jednak w razie potrzeby istnieje możliwość wykorzystania magazynu zdalnego do pracy zespołowej.
Możesz także zaimportować bieżące zasoby platformy do stanu, aby dalej wchodzić w interakcję z innymi zasobami, które z kolei zostały utworzone bez pomocy Terraform.
2. Tworzenie infrastruktury
Komponenty zostały uporządkowane, teraz za pomocą Terraform będziemy stopniowo tworzyć infrastrukturę z trzema maszynami wirtualnymi. Pierwsza z zainstalowanym serwerem proxy nginx, druga z przechowywaniem plików w oparciu o Nextcloud i trzecia z CMS Bitrix.
Na naszym przykładzie napiszemy kod i wykonamy go . Nasi użytkownicy otrzymują konto z uprawnieniami Administratora Organizacji.Jeśli korzystasz z konta z takimi samymi uprawnieniami w innej chmurze VMware, możesz odtworzyć kod z naszych przykładów. Iść!
Na początek utwórzmy katalog dla naszego nowego projektu, w którym będą umieszczone pliki opisujące infrastrukturę.
mkdir project01
Następnie opisujemy elementy infrastruktury. Terraform tworzy relacje i przetwarza pliki na podstawie opisu w plikach. Same pliki można nazwać w zależności od przeznaczenia opisywanych bloków, np. network.tf - opisuje parametry sieciowe dla infrastruktury.
Aby opisać elementy naszej infrastruktury stworzyliśmy następujące pliki:
Lista plików.
main.tf - opis parametrów środowiska wirtualnego - maszyny wirtualne, kontenery wirtualne;
network.tf - opis parametrów sieci wirtualnej oraz reguł NAT i Firewall;
zmienne.tf - lista zmiennych, których używamy;
vcd.tfvars - wartości zmiennych projektu dla modułu VMware vCloud Director.
Język konfiguracji w Terraformie jest deklaratywny i kolejność bloków nie ma znaczenia, z wyjątkiem bloków modułu udostępniania, ponieważ w tym bloku opisujemy polecenia, które należy wykonać podczas przygotowywania infrastruktury i będą one wykonywane w określonej kolejności.
Struktura blokowa.
<BLOCK TYPE> "<BLOCK LABEL>" "<BLOCK LABEL>" {
# Block body
<IDENTIFIER> = <EXPRESSION> # Argument
}
Do opisu bloków używany jest własny język programowania HCL (HashiCorp Configuration Language), istnieje możliwość opisu infrastruktury za pomocą JSON. Możesz dowiedzieć się więcej o składni .
Konfiguracja zmiennych środowiskowych, zmienne.tf i vcd.tfvars
Na początek utwórzmy dwa pliki opisujące listę wszystkich używanych zmiennych i ich wartości dla modułu VMware vCloud Director. Najpierw utwórzmy plik zmienne.tf.
Zawartość pliku zmienne.tf.
variable "vcd_org_user" {
description = "vCD Tenant User"
}
variable "vcd_org_password" {
description = "vCD Tenant Password"
}
variable "vcd_org" {
description = "vCD Tenant Org"
}
variable "vcd_org_vdc" {
description = "vCD Tenant VDC"
}
variable "vcd_org_url" {
description = "vCD Tenant URL"
}
variable "vcd_org_max_retry_timeout" {
default = "60"
}
variable "vcd_org_allow_unverified_ssl" {
default = "true"
}
variable "vcd_org_edge_name" {
description = "vCD edge name"
}
variable "vcd_org_catalog" {
description = "vCD public catalog"
}
variable "vcd_template_os_centos7" {
description = "OS CentOS 7"
default = "CentOS7"
}
variable "vcd_org_ssd_sp" {
description = "Storage Policies"
default = "Gold Storage Policy"
}
variable "vcd_org_hdd_sp" {
description = "Storage Policies"
default = "Bronze Storage Policy"
}
variable "vcd_edge_local_subnet" {
description = "Organization Network Subnet"
}
variable "vcd_edge_external_ip" {
description = "External public IP"
}
variable "vcd_edge_local_ip_nginx" {}
variable "vcd_edge_local_ip_bitrix" {}
variable "vcd_edge_local_ip_nextcloud" {}
variable "vcd_edge_external_network" {}
Wartości zmienne, które otrzymujemy od dostawcy.
-
vcd_org_user — nazwa użytkownika z uprawnieniami Administratora Organizacji,
-
vcd_org_password — hasło użytkownika,
-
vcd_org — nazwa organizacji,
-
vcd_org_vdc — nazwa wirtualnego centrum danych,
-
vcd_org_url – adres URL API,
-
vcd_org_edge_name — nazwa routera wirtualnego,
-
vcd_org_catalog — nazwa katalogu z szablonami maszyn wirtualnych,
-
vcd_edge_external_ip — publiczny adres IP,
-
vcd_edge_external_network — nazwa sieci zewnętrznej,
-
vcd_org_hdd_sp — nazwa polityki przechowywania dysku twardego,
-
vcd_org_ssd_sp — nazwa polityki przechowywania SSD.
I wprowadź nasze zmienne:
-
vcd_edge_local_ip_nginx — adres IP maszyny wirtualnej z NGINX,
-
vcd_edge_local_ip_bitrix - adres IP maszyny wirtualnej z 1C: Bitrix,
-
vcd_edge_local_ip_nextcloud — Adres IP maszyny wirtualnej z Nextcloud.
Za pomocą drugiego pliku tworzymy i określamy zmienne dla modułu VMware vCloud Director w pliku vcd.tfvars: Przypomnijmy, że w naszym przykładzie używamy , jeśli współpracujesz z innym dostawcą, sprawdź u niego wartości.
Zawartość pliku vcd.tfvars.
vcd_org_url = "https://vcloud.mclouds.ru/api"
vcd_org_user = "orgadmin"
vcd_org_password = "*"
vcd = "org"
vcd_org_vdc = "orgvdc"
vcd_org_maxretry_timeout = 60
vcd_org_allow_unverified_ssl = true
vcd_org_catalog = "Templates"
vcd_templateos_centos7 = "CentOS7"
vcd_org_ssd_sp = "Gold Storage Policy"
vcd_org_hdd_sp = "Bronze Storage Policy"
vcd_org_edge_name = "MCLOUDS-EDGE"
vcd_edge_external_ip = "185.17.66.1"
vcd_edge_local_subnet = "192.168.110.0/24"
vcd_edge_local_ip_nginx = "192.168.110.1"
vcd_edge_local_ip_bitrix = "192.168.110.10"
vcd_edge_local_ip_nextcloud = "192.168.110.11"
vcd_edge_external_network = "NET-185-17-66-0"
Konfiguracja sieci, network.tf.
Zmienne środowiskowe są ustawione, teraz skonfigurujemy schemat połączenia maszyny wirtualnej - przypiszemy każdej maszynie wirtualnej prywatny adres IP i użyjemy docelowego NAT do „przekierowania” portów do sieci zewnętrznej. Aby ograniczyć dostęp do portów zarządzania, ustawimy dostęp tylko dla naszego adresu IP.
Schemat sieciowy dla tworzonej platformy Terraform
Tworzymy wirtualną sieć organizacyjną o nazwie net_lan01, bramie domyślnej: 192.168.110.254, a także z przestrzenią adresową: 192.168.110.0/24.
Opisujemy sieć wirtualną.
resource "vcd_network_routed" "net" {
name = "net_lan01"
edge_gateway = var.vcd_org_edge_name
gateway = "192.168.110.254"
dns1 = "1.1.1.1"
dns2 = "8.8.8.8"
static_ip_pool {
start_address = "192.168.110.1"
end_address = "192.168.110.253"
}
}
Stwórzmy reguły zapory sieciowej, które umożliwią maszynom wirtualnym dostęp do Internetu. W ramach tego bloku wszystkie zasoby wirtualne w chmurze będą miały dostęp do Internetu:
Opisujemy zasady dostępu VM do Internetu.
resource "vcd_nsxv_firewall_rule" "fw_internet_access" {
edge_gateway = var.vcdorgedgename
name = "Internet Access"
source {
gateway_interfaces = ["internal"]
}
destination {
gateway_interfaces = ["external"]
}
service {
protocol = "any"
}
depends_on = [vcdnetworkrouted.net]
}
Po ustaleniu zależności, że po przetworzeniu bloku vcdnetworkrouted.net przystępujemy do konfiguracji bloku vcdnsxvfirewallrule, używając zależy od. Używamy tej opcji, ponieważ niektóre zależności mogą zostać rozpoznane pośrednio w konfiguracji.
Następnie utworzymy reguły umożliwiające dostęp do portów z sieci zewnętrznej i wskażemy nasz adres IP do łączenia się przez SSH z serwerami. Dowolny użytkownik Internetu ma dostęp do portów 80 i 443 na serwerze WWW, a użytkownik o adresie IP 90.1.15.1 ma dostęp do portów SSH serwerów wirtualnych.
Zezwól na dostęp do portów z sieci zewnętrznej.
resource "vcd_nsxv_firewall_rule" "fwnatports" {
edge_gateway = var.vcd_org_edge_name
name = "HTTPs Access"
source {
gateway_interfaces = ["external"]
}
destination {
gateway_interfaces = ["internal"]
}
service {
protocol = "tcp"
port = "80"
}
service {
protocol = "tcp"
port = "443"
}
depends_on = [vcd_network_routed.net]
}
resource "vcd_nsxv_firewall_rule" "fw_nat_admin_ports" {
edge_gateway = var.vcd_org_edge_name
name = "Admin Access"
source {
ip_addresses = [ "90.1.15.1" ]
}
destination {
gateway_interfaces = ["internal"]
}
service {
protocol = "tcp"
port = "58301"
}
service {
protocol = "tcp"
port = "58302"
}
service {
protocol = "tcp"
port = "58303"
}
depends_on = [vcd_network_routed.net]
}
Tworzymy reguły Source NAT umożliwiające dostęp do Internetu z lokalnej sieci w chmurze:
Opisujemy zasady źródłowego NAT.
resource "vcd_nsxv_snat" "snat_local" {
edge_gateway = var.vcd_org_edge_name
network_type = "ext"
network_name = var.vcdedgeexternalnetwork
original_address = var.vcd_edge_local_subnet
translated_address = var.vcd_edge_external_ip
depends_on = [vcd_network_routed.net]
}
Aby zakończyć konfigurację bloku sieciowego, dodajemy reguły Destination NAT dotyczące dostępu do usług z sieci zewnętrznej:
Dodawanie reguł docelowego NAT.
resource "vcd_nsxv_dnat" "dnat_tcp_nginx_https" {
edge_gateway = var.vcd_org_edge_name
network_name = var.vcd_edge_external_network
network_type = "ext"
description = "NGINX HTTPs"
original_address = var.vcd_edge_external_ip
original_port = 443
translated_address = var.vcd_edge_local_ip_nginx
translated_port = 443
protocol = "tcp"
depends_on = [vcd_network_routed.net]
}
resource "vcd_nsxv_dnat" "dnat_tcp_nginx_http" {
edge_gateway = var.vcd_org_edge_name
network_name = var.vcd_edge_external_network
network_type = "ext"
description = "NGINX HTTP"
original_address = var.vcd_edge_external_ip
original_port = 80
translated_address = var.vcd_edge_local_ip_nginx
translated_port = 80
protocol = "tcp"
depends_on = [vcd_network_routed.net]
}
Dodaj regułę NAT dla translacji portów do serwera SSH w Nginx.
resource "vcd_nsxv_dnat" "dnat_tcp-nginx_ssh" {
edge_gateway = var.vcd_org_edge_name
network_name = var.vcd_edge_external_network
network_type = "ext"
description = "SSH NGINX"
original_address = var.vcd_edge_external_ip
original_port = 58301
translated_address = var.vcd_edge_local_ip_nginx
translated_port = 22
protocol = "tcp"
depends_on = [vcd_network_routed.net]
}
Dodaj regułę NAT dla translacji portów do serwera SSH za pomocą 1C-Bitrix.
resource "vcd_nsxv_dnat" "dnat_tcp_bitrix_ssh" {
edge_gateway = var.vcd_org_edge_name
network_name = var.vcd_edge_external_network
network_type = "ext"
description = "SSH Bitrix"
original_address = var.vcd_edge_external_ip
original_port = 58302
translated_address = var.vcd_edge_local_ip_bitrix
translated_port = 22
protocol = "tcp"
depends_on = [vcd_network_routed.net]
}
Dodaj regułę NAT dla translacji portów do serwera SSH za pomocą Nextcloud.
resource "vcd_nsxv_dnat" "dnat_tcp_nextcloud_ssh" {
edge_gateway = var.vcd_org_edge_name
network_name = var.vcd_edge_external_network
network_type = "ext"
description = "SSH Nextcloud"
original_address = var.vcd_edge_external_ip
original_port = 58303 translated_address = var.vcd_edge_local_ip_nextcloud
translated_port = 22
protocol = "tcp"
depends_on = [vcd_network_routed.net]
}
Konfiguracja środowiska wirtualnego Main.tf
Zgodnie z planem na początku artykułu utworzymy trzy maszyny wirtualne. Zostaną one przygotowane przy użyciu „Dostosowywania gości”. Ustawimy parametry sieci zgodnie z określonymi przez nas ustawieniami, a hasło użytkownika zostanie wygenerowane automatycznie.
Opiszmy vApp w której będą zlokalizowane maszyny wirtualne oraz ich konfigurację.
Konfiguracja maszyny wirtualnej
Stwórzmy kontener vApp. Abyśmy mogli od razu podłączyć vApp i VM do sieci wirtualnej, dodajemy również parametr zależność_on:
Utwórz kontener
resource "vcd_vapp" "vapp" {
name = "web"
power_on = "true" depends_on = [vcd_network_routed.net]
}
Stwórzmy maszynę wirtualną z opisem
resource "vcd_vapp_vm" "nginx" {
vapp_name = vcd_vapp.vapp.name
name = "nginx"
catalog_name = var.vcd_org_catalog
template_name = var.vcd_template_os_centos7
storage_profile = var.vcd_org_ssd_sp
memory = 8192
cpus = 1
cpu_cores = 1
network {
type = "org"
name = vcd_network_routed.net.name
is_primary = true
adapter_type = "VMXNET3"
ip_allocation_mode = "MANUAL"
ip = var.vcd_edge_local_ip_nginx
}
override_template_disk {
bus_type = "paravirtual"
size_in_mb = "32768"
bus_number = 0
unit_number = 0
storage_profile = var.vcd_org_ssd_sp
}
}
Główne parametry w opisie VM:
-
name — nazwa maszyny wirtualnej,
-
vappname - nazwa vApp, do której chcesz dodać nową maszynę wirtualną,
-
nazwa_katalogu / nazwa_szablonu - nazwa katalogu i nazwa szablonu maszyny wirtualnej,
-
Storageprofile - domyślna polityka przechowywania.
Parametry bloku sieciowego:
-
type — typ podłączonej sieci,
-
nazwa — do której sieci wirtualnej podłączyć maszynę wirtualną,
-
isprimary - podstawowa karta sieciowa,
-
ipallocation_mode — tryb przydzielania adresów MANUAL / DHCP / POOL,
-
ip — adres IP maszyny wirtualnej, podamy go ręcznie.
blok override_template_disk:
-
sizeinmb — rozmiar dysku startowego dla maszyny wirtualnej
-
Storage_profile — zasady przechowywania na dysku
Stwórzmy drugą maszynę wirtualną z opisem magazynu plików Nextcloud
resource "vcd_vapp_vm" "nextcloud" {
vapp_name = vcd_vapp.vapp.name
name = "nextcloud"
catalog_name = var.vcd_org_catalog
template_name = var.vcd_template_os_centos7
storage_profile = var.vcd_org_ssd_sp
memory = 8192
cpus = 1
cpu_cores = 1
network {
type = "org"
name = vcd_network_routed.net.name
is_primary = true
adapter_type = "VMXNET3"
ip_allocation_mode = "MANUAL"
ip = var.vcd_edge_local_ip_nextcloud
}
override_template_disk {
bus_type = "paravirtual"
size_in_mb = "32768"
bus_number = 0
unit_number = 0
storage_profile = var.vcd_org_ssd_sp
}
}
resource "vcd_vm_internal_disk" "disk1" {
vapp_name = vcd_vapp.vapp.name
vm_name = "nextcloud"
bus_type = "paravirtual"
size_in_mb = "102400"
bus_number = 0
unit_number = 1
storage_profile = var.vcd_org_hdd_sp
allow_vm_reboot = true
depends_on = [ vcd_vapp_vm.nextcloud ]
}
W sekcji vcdvminternal_disk opiszemy nowy dysk wirtualny, który jest podłączony do maszyny wirtualnej.
Objaśnienia dotyczące bloku vcdvminternaldisk:
-
typ magistrali - typ kontrolera dysku
-
sizeinmb — rozmiar dysku
-
numer magistrali / numer jednostki - miejsce podłączenia w adapterze
-
Storage_profile — zasady przechowywania na dysku
Opiszmy najnowszą maszynę wirtualną na Bitrixie
resource "vcd_vapp_vm" "bitrix" {
vapp_name = vcd_vapp.vapp.name
name = "bitrix"
catalog_name = var.vcd_org_catalog
template_name = var.vcd_template_os_centos7
storage_profile = var.vcd_org_ssd_sp
memory = 8192
cpus = 1
cpu_cores = 1
network {
type = "org"
name = vcd_network_routed.net.name
is_primary = true
adapter_type = "VMXNET3"
ip_allocation_mode = "MANUAL"
ip = var.vcd_edge_local_ip_bitrix
}
override_template_disk {
bus_type = "paravirtual"
size_in_mb = "81920"
bus_number = 0
unit_number = 0
storage_profile = var.vcd_org_ssd_sp
}
}
Aktualizacja systemu operacyjnego i instalacja dodatkowych skryptów
Sieć jest przygotowana, opisano maszyny wirtualne. Przed zaimportowaniem naszej infrastruktury możemy z wyprzedzeniem przeprowadzić wstępne udostępnianie przy użyciu bloków Provisioner i bez użycia Ansible.
Przyjrzyjmy się, jak zaktualizować system operacyjny i uruchomić skrypt instalacyjny CMS Bitrix za pomocą bloku udostępniania.
Najpierw zainstalujmy pakiety aktualizacji CentOS.
resource "null_resource" "nginx_update_install" {
provisioner "remote-exec" {
connection {
type = "ssh"
user = "root"
password = vcd_vapp_vm.nginx.customization[0].admin_password
host = var.vcd_edge_external_ip
port = "58301"
timeout = "30s"
}
inline = [
"yum -y update && yum -y upgrade",
"yum -y install wget nano epel-release net-tools unzip zip" ]
}
}
}
Oznaczenie komponentów:
-
Provisioner „remote-exec” - podłącz blok zdalnego udostępniania
-
W bloku przyłączeniowym opisujemy typ i parametry połączenia:
-
typ — protokół, w naszym przypadku SSH;
-
użytkownik — nazwa użytkownika;
-
hasło — hasło użytkownika. W naszym przypadku wskazujemy na parametr vcdvappvm.nginx.customization[0].admin_password, który przechowuje wygenerowane hasło dla użytkownika systemu.
-
host — zewnętrzny adres IP do połączenia;
-
port — port do podłączenia, który został wcześniej określony w ustawieniach DNAT;
-
inline - wyświetla listę poleceń, które zostaną wprowadzone. Polecenia zostaną wprowadzone w kolejności wskazanej w tej sekcji.
Jako przykład wykonajmy dodatkowo skrypt instalacyjny 1C-Bitrix. Dane wyjściowe wyniku wykonania skryptu będą dostępne podczas działania planu. Aby zainstalować skrypt, najpierw opisujemy blok:
Opiszmy instalację 1C-Bitrix.
provisioner "file" {
source = "prepare.sh"
destination = "/tmp/prepare.sh"
connection {
type = "ssh"
user = "root"
password = vcd_vapp_vm.nginx.customization[0].admin_password
host = var.vcd_edge_external_ip
port = "58301"
timeout = "30s"
}
}
provisioner "remote-exec" {
inline = [
"chmod +x /tmp/prepare.sh", "./tmp/prepare.sh"
]
}
I od razu opiszemy aktualizację Bitrix.
Przykład udostępniania 1C-Bitrix.
resource "null_resource" "install_update_bitrix" {
provisioner "remote-exec" {
connection {
type = "ssh"
user = "root"
password = vcd_vapp_vm.bitrix.customization[0].admin_password
host = var.vcd_edge_external_ip
port = "58302"
timeout = "60s"
}
inline = [
"yum -y update && yum -y upgrade",
"yum -y install wget nano epel-release net-tools unzip zip",
"wget http://repos.1c-bitrix.ru/yum/bitrix-env.sh -O /tmp/bitrix-env.sh",
"chmod +x /tmp/bitrix-env.sh",
"/tmp/bitrix-env.sh"
]
}
}
Ważny! Skrypt może nie działać, jeśli wcześniej nie wyłączysz SELinuksa! Jeśli potrzebujesz szczegółowego artykułu na temat instalacji i konfiguracji CMS 1C-Bitrix za pomocą bitrix-env.sh, oo możesz .
3. Inicjalizacja infrastruktury
Inicjowanie modułów i wtyczek
Do pracy używamy prostego „zestawu dżentelmena”: laptopa z systemem operacyjnym Windows 10 i zestawu dystrybucyjnego z oficjalnej strony . Rozpakujmy i zainicjujmy za pomocą polecenia: terraform.exe init
Po opisaniu infrastruktury obliczeniowej i sieciowej przystępujemy do planowania testów naszej konfiguracji, podczas których możemy zobaczyć, co powstanie i jak będzie to ze sobą połączone.
-
Wykonaj polecenie
- terraform plan -var-file=vcd.tfvars. -
Otrzymujemy wynik
- Plan: 16 to add, 0 to change, 0 to destroy.Oznacza to, że zgodnie z tym planem utworzonych zostanie 16 zasobów. -
Uruchamiamy plan na polecenie
- terraform.exe apply -var-file=vcd.tfvars.
Zostaną utworzone maszyny wirtualne, a następnie wymienione przez nas pakiety zostaną wykonane w sekcji Provisioner - system operacyjny zostanie zaktualizowany i zainstalowany zostanie CMS Bitrix.
Odbieranie informacji o połączeniu
Po wykonaniu planu chcemy otrzymać dane w formie tekstowej do połączenia z serwerami, w tym celu sformatujemy sekcję wyjściową w następujący sposób:
output "nginxpassword" {
value = vcdvappvm.nginx.customization[0].adminpassword
}
Poniższe dane wyjściowe informują nas o haśle do utworzonej maszyny wirtualnej:
Outputs: nginx_password = F#4u8!!N
Dzięki temu otrzymujemy dostęp do maszyn wirtualnych z zaktualizowanym systemem operacyjnym i preinstalowanymi pakietami do dalszej pracy. Wszystko jest gotowe!
Ale co, jeśli masz już istniejącą infrastrukturę?
3.1. Działający Terraform z istniejącą infrastrukturą
To proste, możesz zaimportować aktualne maszyny wirtualne i ich kontenery vApp za pomocą polecenia import.
Opiszmy zasób vAPP i maszynę wirtualną.
resource "vcd_vapp" "Monitoring" {
name = "Monitoring"
org = "mClouds"
vdc = "mClouds"
}
resource "vcd_vapp_vm" "Zabbix" {
name = "Zabbix"
org = "mClouds"
vdc = "mClouds"
vapp = "Monitoring"
}
Kolejnym krokiem jest zaimportowanie właściwości zasobów vApp w formacie vcdvapp.<vApp> <org>.<orgvdc>.<vApp>, gdzie:
-
vApp - nazwa vApp;
-
org — nazwa organizacji;
-
org_vdc — nazwa wirtualnego centrum danych.
Importowanie właściwości zasobów vAPP
Zaimportujmy właściwości zasobów VM w formacie: vcdvappvm.<VM> <org>.<orgvdc>.<vApp>.<VM>, w którym:
-
VM - nazwa VM;
-
vApp - nazwa vApp;
-
org — nazwa organizacji;
-
orgvdc to nazwa wirtualnego centrum danych.
Import przebiegł pomyślnie
C:UsersMikhailDesktopterraform>terraform import vcd_vapp_vm.Zabbix mClouds.mClouds.Monitoring.Zabbix
vcd_vapp_vm.Zabbix: Importing from ID "mClouds.mClouds.Monitoring.Zabbix"...
vcd_vapp_vm.Zabbix: Import prepared!
Prepared vcd_vapp_vm for import
vcd_vapp_vm.Zabbix: Refreshing state... [id=urn:vcloud:vm:778f4a89-1c8d-45b9-9d94-0472a71c4d1f]
Import successful!
The resources that were imported are shown above. These resources are now in
your Terraform state and will henceforth be managed by Terraform.
Teraz możemy przyjrzeć się nowemu zaimportowanemu zasóbowi:
Zaimportowany zasób
> terraform show
...
# vcd_vapp.Monitoring:
resource "vcd_vapp" "Monitoring" {
guest_properties = {}
href = "https://vcloud.mclouds.ru/api/vApp/vapp-fe5db285-a4af-47c4-93e8-55df92f006ec"
id = "urn:vcloud:vapp:fe5db285-a4af-47c4-93e8-55df92f006ec"
ip = "allocated"
metadata = {}
name = "Monitoring"
org = "mClouds"
status = 4
status_text = "POWERED_ON"
vdc = "mClouds"
}
…
# vcd_vapp_vm.Zabbix:
resource "vcd_vapp_vm" "Zabbix" {
computer_name = "Zabbix"
cpu_cores = 1
cpus = 2
expose_hardware_virtualization = false
guest_properties = {}
hardware_version = "vmx-14"
href = "https://vcloud.mclouds.ru/api/vApp/vm-778f4a89-1c8d-45b9-9d94-0472a71c4d1f"
id = "urn:vcloud:vm:778f4a89-1c8d-45b9-9d94-0472a71c4d1f"
internal_disk = [
{
bus_number = 0
bus_type = "paravirtual"
disk_id = "2000"
iops = 0
size_in_mb = 122880
storage_profile = "Gold Storage Policy"
thin_provisioned = true
unit_number = 0
},
]
memory = 8192
metadata = {}
name = "Zabbix"
org = "mClouds"
os_type = "centos8_64Guest"
storage_profile = "Gold Storage Policy"
vapp_name = "Monitoring"
vdc = "mClouds"
customization {
allow_local_admin_password = true
auto_generate_password = true
change_sid = false
enabled = false
force = false
join_domain = false
join_org_domain = false
must_change_password_on_first_login = false
number_of_auto_logons = 0
}
network {
adapter_type = "VMXNET3"
ip_allocation_mode = "DHCP"
is_primary = true
mac = "00:50:56:07:01:b1"
name = "MCLOUDS-LAN01"
type = "org"
}
}
Teraz jesteśmy zdecydowanie gotowi - zakończyliśmy ostatni punkt (importowanie do istniejącej infrastruktury) i rozważyliśmy wszystkie główne punkty pracy z Terraform.
Narzędzie okazało się bardzo wygodne i pozwala opisać swoją infrastrukturę w formie kodu, zaczynając od maszyn wirtualnych jednego dostawcy chmury, aż po opis zasobów komponentów sieciowych.
Jednocześnie niezależność od otoczenia pozwala na pracę z zasobami lokalnymi, chmurowymi, a nawet zarządzanie platformą. A jeśli nie ma obsługiwanej platformy i chcesz dodać nową, możesz napisać własnego dostawcę i korzystać z niego.
Źródło: www.habr.com