W tym artykule omówimy, z czego składa się Terraform i krok po kroku uruchomimy własną infrastrukturę — przygotujemy trzy VM do różnych celów: proxy, przechowywanie 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) do budowy i zarządzania wirtualną infrastrukturą przy użyciu kodu.
W pracy z narzędziem zauważyliśmy kilka zalet:
Szybkość wdrażania nowych tenantów (wirtualnych środowisk użytkowników). Z reguły im więcej nowych klientów, tym więcej „kliknięć” muszą wykonać pracownicy wsparcia technicznego, aby opublikować nowe zasoby. Dzięki Terraform użytkownicy mogą zmieniać parametry maszyn wirtualnych (na przykład automatycznie wyłączać OS i powiększać partycję wirtualnego dysku) bez udziału wsparcia technicznego i wyłączania samej maszyny.
Natychmiastowe sprawdzenie planu aktywacji nowego tenanta. Dzięki opisowi kodu infrastruktury możemy od razu sprawdzić, co i w jakiej kolejności zostanie dodane, a także w jakim końcowym stanie będzie dana maszyna wirtualna lub wirtualna sieć z połączeniami do maszyn wirtualnych.
Możliwość opisywania większości popularnych platform chmurowych. Możesz korzystać z narzędzia od Amazon i Google Cloud, aż po prywatne platformy oparte na VMware vCloud Director, oferujące usługi w ramach rozwiązań IaaS, SaaS i PaaS.
Zarządzanie wieloma dostawcami chmur i rozdzielanie infrastruktury między nimi w celu zwiększenia odporności na awarie, używając jednej konfiguracji do tworzenia, diagnostyki i zarządzania zasobami chmurowymi.
Wygodne użycie do tworzenia pokazowych środowisk do testowania i debugowania oprogramowania. Możesz tworzyć i udostępniać środowiska dla działu testów, równocześnie testując oprogramowanie w różnych środowiskach, a także natychmiast zmieniać i usuwać zasoby, tworząc tylko jeden plan budowy zasobów.
„Terrarium” Terraform
Krótko omówiliśmy zalety narzędzia, teraz rozłóżmy je na komponenty
Providers (dostawcy).
W Terraformie prawie każdy typ infrastruktury można przedstawić jako zasób. Połączenie między zasobami a platformą API zapewniają moduły providers, które umożliwiają tworzenie zasobów w ramach określonej platformy, na przykład Azure lub VMware vCloud Director.
W ramach projektu możesz współpracować z różnymi dostawcami na różnych platformach.
Resources (opis zasobów).
Opis zasobów pozwala zarządzać komponentami platformy, takimi jak maszyny wirtualne lub sieci.
Możesz samodzielnie stworzyć opis zasobów dla dostawcy VMware vCloud Director i wykorzystać ten opis do tworzenia zasobów u dowolnego dostawcy hostingowego, który korzysta z vCloud Director. Wystarczy, że zamienisz parametry autoryzacji i parametry połączenia sieciowego z odpowiednim dostawcą hostingowym.
Provisioners.
Ta składnik umożliwia wykonywanie operacji wstępnej instalacji i konserwacji systemu operacyjnego po utworzeniu maszyn wirtualnych. Po utworzeniu zasobu maszyny wirtualnej, za pomocą provisioners możesz skonfigurować i połączyć się przez SSH, zaktualizować system operacyjny oraz przesłać i uruchomić skrypt.
Zmienne Input i Output.
Input zmienne — wejściowe zmienne dla wszystkich typów bloków.
Output zmienne pozwalają zachować wartości po utworzeniu zasobów i mogą być używane jako wejściowe zmienne w innych modułach, na przykład w bloku Provisioners.
States (stany).
Pliki states przechowują informacje o konfiguracji zasobów platformy dostawcy. Przy pierwszym utworzeniu platformy nie ma żadnych informacji o zasobach, a przed każdą operacją Terraform aktualizuje stan z rzeczywistą infrastrukturą już opisanych zasobów.
Głównym celem stanów jest zachowanie powiązania obiektów już stworzonych zasobów w celu porównania konfiguracji dodawanych zasobów i obiektów, aby uniknąć ich ponownego tworzenia i zmian w platformie.
Informacje o stanie domyślnie przechowywane są w lokalnym pliku terraform.tfstate, ale w razie potrzeby istnieje możliwość korzystania z zdalnego przechowywania do pracy w zespole.
Możesz również zaimportować bieżące zasoby platformy w stan, aby następnie współdziałać z innymi zasobami, które z kolei zostały stworzone bez pomocy Terraform.
2. Tworzenie infrastruktury
Teraz, gdy rozłożyliśmy komponenty, przy pomocy Terraform krok po kroku stworzymy infrastrukturę z trzema maszynami wirtualnymi. Pierwsza z zainstalowanym serwerem proxy nginx, druga z magazynem plików na bazie Nextcloud, a trzecia z CMS Bitrix.
Będziemy pisać kod i go wykonywać na przykładzie naszego Użytkownicy otrzymują konto z uprawnieniami Administratora Organizacji; jeśli używasz konta z tymi samymi uprawnieniami w innej chmurze VMware, będziesz mógł odtworzyć kod z naszych przykładów. Zaczynamy!
Najpierw stworzymy dla naszego nowego projektu katalog, w którym będą umieszczone pliki z opisem infrastruktury.
mkdir project01
Następnie opiszemy komponenty infrastruktury. Terraform tworzy powiązania i przetwarza pliki na podstawie opisu w tych plikach. Same pliki można nazywać w zależności od docelowego przeznaczenia opisywanych bloków, na przykład network.tf — opisuje parametry sieciowe dla infrastruktury.
Do opisu komponentów naszej infrastruktury stworzyliśmy następujące pliki:
Lista plików.
main.tf — opis parametrów dla środowiska wirtualnego — maszyny wirtualne, kontenery wirtualne;
network.tf — opis parametrów wirtualnej sieci oraz reguł NAT, Firewall;
variables.tf — lista zmiennych, które używamy;
vcd.tfvars — wartości zmiennych projektu dla modułu VMware vCloud Director.
Język konfiguracji w Terraform jest deklaratywny, a kolejność bloków nie ma znaczenia, z wyjątkiem bloków provisioner, ponieważ w tym bloku opisujemy polecenia do wykonania podczas przygotowania infrastruktury i będą one wykonywane w określonej kolejności.
Struktura bloków.
"" "" {
# Block body
= # Argument
}
Do opisu bloków używany jest własny język programowania HCL (HashiCorp Configuration Language), infrastrukturę można opisać również przy użyciu JSON. Więcej na temat składni można .
Konfiguracja zmiennej środowiskowej, variables.tf i vcd.tfvars
Najpierw stworzymy dwa pliki, które opisują listę wszystkich używanych zmiennych i ich wartości dla modułu VMware vCloud Director. Najpierw stworzymy plik variables.tf.
Zawartość pliku variables.tf.
zmienna "vcd_org_user" {
opis = "użytkownik vCD Tenanta"
}
zmienna "vcd_org_password" {
opis = "hasło vCD Tenanta"
}
zmienna "vcd_org" {
opis = "organizacja vCD Tenanta"
}
zmienna "vcd_org_vdc" {
opis = "vDC Tenanta vCD"
}
zmienna "vcd_org_url" {
opis = "URL Tenanta vCD"
}
zmienna "vcd_org_max_retry_timeout" {
domyślnie = "60"
}
zmienna "vcd_org_allow_unverified_ssl" {
domyślnie = "true"
}
zmienna "vcd_org_edge_name" {
opis = "nazwa krawędzi vCD"
}
zmienna "vcd_org_catalog" {
opis = "publiczny katalog vCD"
}
zmienna "vcd_template_os_centos7" {
opis = "OS CentOS 7"
domyślnie = "CentOS7"
}
zmienna "vcd_org_ssd_sp" {
opis = "Polityki przechowywania"
domyślnie = "Polityka przechowywania Gold"
}
zmienna "vcd_org_hdd_sp" {
opis = "Polityki przechowywania"
domyślnie = "Polityka przechowywania Bronze"
}
zmienna "vcd_edge_local_subnet" {
opis = "Podsieć sieci organizacji"
}
zmienna "vcd_edge_external_ip" {
opis = "Zewnętrzny publiczny adres IP"
}
zmienna "vcd_edge_local_ip_nginx" {}
zmienna "vcd_edge_local_ip_bitrix" {}
zmienna "vcd_edge_local_ip_nextcloud" {}
zmienna "vcd_edge_external_network" {}
Wartości zmiennych, 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 — URL API,
vcd_org_edge_name — nazwa wirtualnego routera,
vcd_org_catalog — nazwa katalogu z szablonami maszyn wirtualnych,
vcd_edge_external_ip — publiczny adres IP,
vcd_edge_external_network — nazwa zewnętrznej sieci,
vcd_org_hdd_sp — nazwa polityki przechowywania HDD,
vcd_org_ssd_sp — nazwa polityki przechowywania SSD.
I definiujemy 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.
W drugim pliku tworzymy i podajemy zmienne dla modułu VMware vCloud Director w pliku vcd.tfvars: Przypominamy, że w naszym przykładzie używamy , jeśli pracujesz z innym dostawcą, skonsultuj się o wartości z nim.
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 = "Polityka przechowywania Gold"
vcd_org_hdd_sp = "Polityka przechowywania Bronze"
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 zostały ustawione, teraz skonfigurujemy schemat połączenia wirtualnych maszyn — przypiszemy każdy wirtualnej maszynie prywatny adres IP i za pomocą Destination NAT 'przekierujemy' porty do sieci zewnętrznej. Aby ograniczyć dostęp do portów sterujących, ustalimy dostęp tylko dla naszego adresu IP.
Schemat sieci dla tworzonej platformy Terraform
Tworzymy wirtualną organizacyjną sieć o nazwie net_lan01, z domyślną bramą: 192.168.110.254 oraz z przestrzenią adresową: 192.168.110.0/24.
Opisujemy wirtualną sieć.
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"
}
}
Utworzymy zasady dla zapory, które umożliwią wirtualnym maszynom dostęp do sieci Internet. W ramach tego bloku wszystkie wirtualne zasoby w chmurze będą miały dostęp do sieci Internet:
Opisujemy zasady dostępu VM do internetu.
resource "vcd_nsxv_firewall_rule" "fw_internet_access" {
edge_gateway = var.vcdorgedgename
name = "Dostęp do Internetu"
source {
gateway_interfaces = ["internal"]
}
destination {
gateway_interfaces = ["external"]
}
service {
protocol = "any"
}
depends_on = [vcdnetworkrouted.net]
}
Po ustawieniu zależności, że po przetworzeniu bloku vcdnetworkrouted.net przystępujemy do konfiguracji bloku vcdnsxvfirewallrule, za pomocą dependson. Używamy tej opcji, ponieważ niektóre zależności mogą być rozpoznawane niejawnie w konfiguracji.
Następnie tworzymy zasady zezwalające na dostęp do portów z sieci zewnętrznej i podajemy nasz adres IP do połączeń SSH z serwerami. Każdy użytkownik sieci Internet ma dostęp do portów 80 i 443 na serwerze www, a użytkownik z adresem IP 90.1.15.1 ma dostęp do portów SSH wirtualnych serwerów.
Zezwalamy na dostęp do portów z sieci zewnętrznej.
resource "vcd_nsxv_firewall_rule" "fwnatports" {
edge_gateway = var.vcd_org_edge_name
name = "Dostęp HTTPs"
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 = "Dostęp administracyjny"
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 zasady Source NAT dla dostępu do sieci Internet z chmury lokalnej:
Opisujemy zasady Source 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]
}
I na zakończenie konfiguracji bloku sieciowego dodajemy zasady Destination NAT dla dostępu do usług z sieci zewnętrznej:
Dodajemy zasady Destination 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"
oryginalny_adres = var.vcd_edge_external_ip
oryginalny_port = 443
przetłumaczony_adres = var.vcd_edge_local_ip_nginx
przetłumaczony_port = 443
protokół = "tcp"
depends_on = [vcd_network_routed.net]
}
zasób "vcd_nsxv_dnat" "dnat_tcp_nginx_http" {
edge_gateway = var.vcd_org_edge_name
network_name = var.vcd_edge_external_network
network_type = "ext"
opis = "NGINX HTTP"
oryginalny_adres = var.vcd_edge_external_ip
oryginalny_port = 80
przetłumaczony_adres = var.vcd_edge_local_ip_nginx
przetłumaczony_port = 80
protokół = "tcp"
depends_on = [vcd_network_routed.net]
}
Dodajemy regułę NAT do translacji portów do serwera SSH pod Nginx.
zasób "vcd_nsxv_dnat" "dnat_tcp-nginx_ssh" {
edge_gateway = var.vcd_org_edge_name
network_name = var.vcd_edge_external_network
network_type = "ext"
opis = "SSH NGINX"
oryginalny_adres = var.vcd_edge_external_ip
oryginalny_port = 58301
przetłumaczony_adres = var.vcd_edge_local_ip_nginx
przetłumaczony_port = 22
protokół = "tcp"
depends_on = [vcd_network_routed.net]
}
Dodajemy regułę NAT do translacji portów do serwera SSH z 1C-Bitrix.
zasób "vcd_nsxv_dnat" "dnat_tcp_bitrix_ssh" {
edge_gateway = var.vcd_org_edge_name
network_name = var.vcd_edge_external_network
network_type = "ext"
opis = "SSH Bitrix"
oryginalny_adres = var.vcd_edge_external_ip
oryginalny_port = 58302
przetłumaczony_adres = var.vcd_edge_local_ip_bitrix
przetłumaczony_port = 22
protokół = "tcp"
depends_on = [vcd_network_routed.net]
}
Dodajemy regułę NAT do translacji portów do serwera SSH z Nextcloud.
zasób "vcd_nsxv_dnat" "dnat_tcp_nextcloud_ssh" {
edge_gateway = var.vcd_org_edge_name
network_name = var.vcd_edge_external_network
network_type = "ext"
opis = "SSH Nextcloud"
oryginalny_adres = var.vcd_edge_external_ip
oryginalny_port = 58303 przetłumaczony_adres = var.vcd_edge_local_ip_nextcloud
przetłumaczony_port = 22
protokół = "tcp"
depends_on = [vcd_network_routed.net]
}
Konfiguracja wirtualnego środowiska main.tf
Jak zaplanowaliśmy na początku artykułu, stworzymy trzy maszyny wirtualne. Zostaną one przygotowane z użyciem „Guest Customization”. Parametry sieciowe zostaną zapisane zgodnie z naszymi ustawieniami, a hasło użytkownika będzie generowane automatycznie.
Opiszemy vApp, w którym będą znajdować się maszyny wirtualne oraz ich konfiguracja.
Konfiguracja maszyn wirtualnych
Stworzymy kontener vApp. Abyśmy mogli od razu podłączyć vApp i maszyny wirtualne do wirtualnej sieci, dodajemy także parametr depends_on:
Tworzymy kontener
zasób "vcd_vapp" "vapp" {
nazwa = "web"
włączone = "true" depends_on = [vcd_network_routed.net]
}
Stworzymy maszynę wirtualną z opisem
zasób "vcd_vapp_vm" "nginx" {
nazwa_vapp = vcd_vapp.vapp.name
nazwa = "nginx"
nazwa_katalogu = var.vcd_org_catalog
nazwa_szablonu = var.vcd_template_os_centos7
profil_przechowywania = var.vcd_org_ssd_sp
pamięć = 8192
procesory = 1
rdzenie_cpu = 1
sieć {
typ = "org"
nazwa = vcd_network_routed.net.name
jest_podstawowy = true
typ_adaptera = "VMXNET3"
tryb_przydzielania_ip = "MANUAL"
ip = var.vcd_edge_local_ip_nginx
}
nadpisz_szablon_dysku {
typ_busa = "paravirtual"
rozmiar_w_mb = "32768"
numer_busa = 0
numer_jednostki = 0
profil_przechowywania = var.vcd_org_ssd_sp
}
}
Podstawowe parametry w opisie VM:
nazwa — nazwa maszyny wirtualnej,
nazwa_vapp — nazwa vApp, do którego dodać nową VM,
nazwa_katalogu / nazwa_szablonu — nazwa katalogu i nazwa szablonu maszyny wirtualnej,
profil_przechowywania — domyślna polityka przechowywania.
Parametry bloku sieci:
typ — typ podłączanej sieci,
nazwa — do jakiej wirtualnej sieci podłączyć VM,
jest_podstawowy — podstawowy adapter sieciowy,
tryb_przydzielania_ip — tryb przydzielania adresu MANUAL / DHCP / POOL,
ip — adres IP dla maszyny wirtualnej, podamy ręcznie.
Blok nadpisywania_szablonu_dysku:
rozmiarwmb — rozmiar dysku startowego dla maszyny wirtualnej
profil_przechowywania — polityka przechowywania dla dysku
Stworzymy drugą VM z opisem pamięci masowej Nextcloud
zasób "vcd_vapp_vm" "nextcloud" {
nazwa_vapp = vcd_vapp.vapp.name
nazwa = "nextcloud"
nazwa_katalogu = var.vcd_org_catalog
nazwa_szablonu = var.vcd_template_os_centos7
profil_przechowywania = var.vcd_org_ssd_sp
pamięć = 8192
procesory = 1
rdzenie_cpu = 1
sieć {
typ = "org"
nazwa = vcd_network_routed.net.name
jest_podstawowy = true
typ_adaptera = "VMXNET3"
tryb_przydzielania_ip = "MANUAL"
ip = var.vcd_edge_local_ip_nextcloud
}
nadpisz_szablon_dysku {
typ_busa = "paravirtual"
rozmiar_w_mb = "32768"
numer_busa = 0
numer_jednostki = 0
profil_przechowywania = 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 opisujemy nowy wirtualny dysk, który jest podłączany do wirtualnej maszyny.
Wyjaśnienia dotyczące bloku vcdvminternaldisk:
bustype — typ kontrolera dysku
sizeinmb — rozmiar dysku
busnumber / unitnumber — miejsce podłączenia w adapterze
profil_przechowywania — polityka przechowywania dla dysku
Opisujemy ostatnią VM na Bitrix
resource "vcd_vapp_vm" "bitrix" {
nazwa_vapp = vcd_vapp.vapp.name
name = "bitrix"
nazwa_katalogu = var.vcd_org_catalog
nazwa_szablonu = var.vcd_template_os_centos7
profil_przechowywania = var.vcd_org_ssd_sp
pamięć = 8192
procesory = 1
rdzenie_cpu = 1
sieć {
typ = "org"
nazwa = vcd_network_routed.net.name
jest_podstawowy = true
typ_adaptera = "VMXNET3"
tryb_przydzielania_ip = "MANUAL"
ip = var.vcd_edge_local_ip_bitrix
}
nadpisz_szablon_dysku {
typ_busa = "paravirtual"
size_in_mb = "81920"
numer_busa = 0
numer_jednostki = 0
profil_przechowywania = var.vcd_org_ssd_sp
}
}
Aktualizacja systemu operacyjnego i instalacja dodatkowych skryptów
Sieć jest przygotowana, wirtualne maszyny zostały opisane. Przed importem naszej infrastruktury możemy przeprowadzić początkowe provisionowanie za pomocą bloków provisioners i bez użycia Ansible.
Rozważmy jak zaktualizować system operacyjny i uruchomić skrypt instalacyjny CMS Bitrix za pomocą bloku provisioner.
Najpierw zainstalujemy 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 składników:
provisioner «remote-exec» — łączymy blok zdalnego «provisioningu»
W bloku connection opisujemy typ i parametry połączenia:
type — protokół, w naszym przypadku SSH;
user — nazwa użytkownika;
password — 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 połączenia, który wcześniej wskazaliśmy w ustawieniach DNAT;
inline — wymieniamy listę poleceń, które będą wprowadzane. Polecenia będą wprowadzane po kolei, tak jak jest to wskazane w tej sekcji.
Jako przykład, dodatkowo wykonamy skrypt instalacji 1C-Bitrix. Wynik wykonania skryptu będzie dostępny w czasie realizacji planu. Aby zainstalować skrypt, najpierw opiszemy blok:
Opisujemy 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 opisujemy aktualizację Bitrix.
Przykład provisioningu 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"
]
}
}
Uwaga! Skrypt może nie zadziałać, jeśli wcześniej nie wyłączysz SELinux! Jeśli potrzebujesz szczegółowego artykułu na temat instalacji i konfiguracji CMS 1C-Bitrix za pomocą bitrix-env.sh, możesz .
3. Inicjalizacja infrastruktury
Inicjalizacja modułów i wtyczek
Do pracy używamy prostego „zestawu dżentelmena”: laptopa z systemem Windows 10 oraz dystrybucji z oficjalnej strony . Rozpakujemy i zainicjalizujemy za pomocą polecenia: terraform.exe init
Po opisaniu infrastruktury obliczeniowej i sieciowej, uruchamiamy planowanie, aby sprawdzić naszą konfigurację, gdzie możemy zobaczyć, co zostanie utworzone i jak jest połączone.
Wykonujemy polecenie
- terraform plan -var-file=vcd.tfvars.Otrzymujemy wynik
- Plan: 16 do dodania, 0 do zmiany, 0 do zniszczenia.Oznacza to, że według tego planu zostanie utworzonych 16 zasobów.Uruchamiamy plan za pomocą polecenia
- terraform.exe apply -var-file=vcd.tfvars.
Maszyny wirtualne zostaną utworzone, a następnie wykonane będą wymienione przez nas pakiety w ramach sekcji provisioner — system operacyjny zostanie zaktualizowany i zainstalowane zostanie CMS Bitrix.
Uzyskiwanie danych do połączenia
Po wykonaniu planu chcemy uzyskać dane do połączenia z serwerami w formie tekstowej, w tym celu zorganizujemy sekcję output w następujący sposób:
output "nginxpassword" {
value = vcdvappvm.nginx.customization[0].adminpassword
}
A następnie wynik informuje nas o haśle do utworzonej maszyny wirtualnej:
Outputs: nginx_password = F#4u8!!N
W rezultacie uzyskujemy dostęp do maszyn wirtualnych z zaktualizowanym systemem operacyjnym i wstępnie zainstalowanymi pakietami do naszej dalszej pracy. Wszystko gotowe!
Ale co jeśli masz już istniejącą infrastrukturę?
3.1. Praca Terraform z już istniejącą infrastrukturą
To proste, możesz zaimportować aktualne maszyny wirtualne i ich kontenery vApp za pomocą polecenia import.
Opiszemy zasób vAPP oraz 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"
}
Następny krok to import 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.
Import właściwości zasobu vAPP
Wykonamy import 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 — nazwa wirtualnego centrum danych.
Import udany
C:UsersMikhailDesktopterraform>terraform import vcd_vapp_vm.Zabbix mClouds.mClouds.Monitoring.Zabbix
vcd_vapp_vm.Zabbix: Importowanie z ID "mClouds.mClouds.Monitoring.Zabbix"...
vcd_vapp_vm.Zabbix: Import przygotowany!
Przygotowano vcd_vapp_vm do importu
vcd_vapp_vm.Zabbix: OdsRefreshing state... [id=urn:vcloud:vm:778f4a89-1c8d-45b9-9d94-0472a71c4d1f]
Import zakończony sukcesem!
Zaimportowane zasoby są pokazane powyżej. Te zasoby są teraz w
twoim stanie Terraform i będą od teraz zarządzane przez Terraform.
Teraz możemy zobaczyć nowo zaimportowany zasób:
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 = "przydzielony"
metadata = {}
name = "Monitoring"
org = "mClouds"
status = 4
status_text = "WŁĄCZONY"
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 = [
{
numer_busa = 0
typ_busa = "paravirtual"
disk_id = "2000"
iops = 0
size_in_mb = 122880
storage_profile = "Złota Polityka Przechowywania"
thin_provisioned = true
numer_jednostki = 0
},
]
memory = 8192
metadata = {}
name = "Zabbix"
org = "mClouds"
os_type = "centos8_64Guest"
storage_profile = "Złota Polityka Przechowywania"
vapp_name = "Monitoring"
vdc = "mChmury"
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
}
sieć {
adapter_type = "VMXNET3"
ip_allocation_mode = "DHCP"
is_primary = true
mac = "00:50:56:07:01:b1"
name = "MCLOUDS-LAN01"
type = "org"
}
}
Teraz to na pewno gotowe — skończyliśmy z ostatnim elementem (import do istniejącej infrastruktury) i omówiliśmy wszystkie kluczowe aspekty pracy z Terraform.
Narzędzie okazało się bardzo przydatne i pozwala na opisanie Twojej infrastruktury jako kodu, od maszyn wirtualnych jednego dostawcy chmur do opisywania zasobów komponentów sieciowych.
Jednocześnie niezależność od środowiska umożliwia pracę zarówno z lokalnymi, jak i chmurowymi zasobami, aż po zarządzanie platformą. A w przypadku braku obsługiwanej platformy i chęci dodania nowej, można napisać własnego dostawcę i go używać.
Źródło: habr.com
