Getting started with Terraform¶

Այս հոդվածում

• Ինչ է ձեզ անհրաժեշտ Terraform-ով աշխատելու համար
• Քայլ 1. Տեղակայել Terraform
• Քայլ 2. Ստեղծել API key
• Քայլ 3. Պատրաստել կոնֆարկացիան
• Քայլ 4. Ինիցիալիզացնել provider-ը
• Քայլ 5. Վավերացնել կոնֆարկացիան
• Քայլ 6. Պատվիրել սերվերը
• Քայլ 7. Փոփոխել կոնֆարկացիան
• Քայլ 8. Ունչնահատուկ ռեսուրսների ոչնչացում (Destroy)
• Գոյություն ունեցող սերվերների ներդրում (Importing)
• Խնդիրների հնարավորությունների լուծում (Troubleshooting)

Երբ դուք ունեք միայն մեկ սերվեր, այն ձեռքով պատվիրելն ավելի արագ է: Սակայն, երբ դրանք դառնում են տասնհինը, որոնք ստեղծվել են տարբեր ժամանակների վրա տարբեր ադմինիստրատորների կողմից, ոչ ոք չի հիշում, թե ինչու մեկը աշխատում է Ubuntu 20.04-ով, մինչդեռ հարևանը՝ 22.04-ով: Կոնֆարկացիոն ֆայլը պահում է այդ պատմությունը, ինչպես նաև թույլ է տալիս վերականգնել նույն միջավայրը՝ առանց հիշողությունից կլիքերի շղթայական գործողությունները վերարտադրելու:

Մեր provider-ի հետ աշխատանքային գործընթացը հետևյալն է. ֆայլում նշված են նախնական սահմանված (preset) տարբերակը, տեղադիրքը, օպերացիոն համակարգը և տրաֆիկի պլանը, որից հետո terraform apply-ը կատարում է պատվերը և սպասում տեղակայման (deployment) ավտոմատ ավարտին: Կրկնակի գործարկման դեպքում ոչինչ չի կրկնօրինակվում, քանի որ Terraform-ը հիշում է իր ստեղծած ռեսուրսները: terraform plan հրամանը ցույց է տալիս առաջիկա փոփոխությունները՝ առանց դրանցից որևէ մեկը իրականացնելու:

Provider-ը աշխատում է ամբողջ կատալոգի հետ, ներառյալ VPS, VDS, dedicated և GPU սերվերները, հավելավարձը IP հասցեները, SSH բանալիները և DNS գոտիները: Ռեսուրսների և տվյալների աղբյուրների (data sources) ամբողջական ուղեցույցը հասանելի է Terraform Registry հարթակում և hostkey-cloud/terraform-provider-hostkey-com պահոստոցում (repository): Ստորև ներկայացված է հիմնական սցենարը՝ վիրտուալ սերվերի պատվիրումը:

Ինչ է ձեզ անհրաժեշտ Terraform-ով աշխատելու համար¶

• Հաշիվ Invapi կառավարման վահանակում (control panel)՝ հաշվեկշռում առկա միջոցներով, քանի որ սերվերի պատվիրումը վճարովի գործողություն է.
• API key;
• SSH key;
• Terraform 1.0 կամ ավելի նոր տարբերակ:

Քայլ 1. Տեղակայել Terraform¶

Terraform-ը աշխատում է Linux, macOS և Windows համակարգերում: Դուք կարող եք այն տեղակայել երկու եղանակով՝ կա՛մ փաթեթների կառավարիչի (package manager) միջոցով, կա՛մ ձեռքով՝ ներբեռնելով և քվլելով պատրաստի binary ֆայլը:

Windows¶

Ներբեռնեք արխիվը, քվլեք terraform.exe-ն հատուկ թղթապանակում, օրինակ՝ C:\terraform, և այդ թղթապանակը ավելացրեք Path շրջակա միջավայրի փոփոխականում:

Դրանից հետո փակեք և նորից բացեք տերմինալը, քանի որ նոր Path արժեքը չի կիրառվի մինչև այդ պահը: Տեղակայումը ստուգելու համար գրեք.

terraform -v

Linux¶

wget https://releases.hashicorp.com/terraform/1.15.8/terraform_1.15.8_linux_amd64.zip
unzip ./terraform_1.15.8_linux_amd64.zip
sudo mv ./terraform /usr/local/bin
terraform -v

macOS¶

brew install terraform
terraform -v

Քայլ 2. Ստեղծել API key¶

Key-ը ստեղծվում է Invapi կառավարման վահանակում: Սեղմեք ձեր օգտանվան վերևի աջ անկյունում և ընտրեք API keys:

Click Add new և լրացրեք ձևաթուղթը:

Restrict a new API key only for the server դաշտը կապում է բանալին մեկ ծառայության հետ, իսկ provider-ը պետք է կարողանա պատվիրել նոր սերվերներ, ուստի արժեքը պետք է լինի Any:

IP ACL դաշտը սահմանափակում է մուտքը նշված հասցեների համար: Այն բարձրացնում է անվտանգությունը, սակայն դինամիկ IP հասցեի դեպքում բանալին դադարում է աշխատել հենց հասցեն փոփոխվելուց հետո, ուստի սկզբնական փուլում թողեք դաշտը դատարկ, իսկ continuous integration-ի համար նշեք ձեր build սերվերների հասցեները:

Click Create: Բանալին ցուցադրվում է միայն մեկ անգամ:

Քայլ 3. Պատրաստել կոնֆարկացիան¶

Ստեղծեք նախագծի թղթապանակ, օրինակ՝ hostkey-terraform: Կոնֆարկացիոն ֆայլերը օգտագործում են .tf ընդլայնումը, և դրանց անունները ցանկացած կարող են լինել, քանի որ Terraform-ը թղթապանակի ներսում գտնվող յուրաքանչյուր .tf ֆայլ միավորում է մեկ միասնական կոնֆարկացիայի մեջ: Մեր օրինակում օգտագործվում է երեք ֆայլ:

main.tf¶

Առաջին բլոկը սահմանում է provider-ը և Terraform-ի պահանջվող տարբերակը:

terraform {
  required_providers {
    hostkey = {
      source  = "hostkey-cloud/hostkey-com"
      version = "~> 0.2"
    }
  }
  required_version = ">= 1.0"
}

provider "hostkey" {}

Հաջորդը կատալոգի ստուգումն է: Այս բլոկները ռեսուրսներ չեն ստեղծում և չեն հաշվարկվում, դրանք միայն API-ից հարցում են անում՝ ստանալու պատվերի համար հասանելի preset-ների և տրաֆիկի պլանների ցանկերը.

data "hostkey_presets" "selected" {
  location = var.location
  name     = var.preset_name
}

data "hostkey_traffic_plans" "for_preset" {
  location    = var.location
  instance_id = data.hostkey_presets.selected.presets[0].id
}

output "catalog_preset" {
  value = data.hostkey_presets.selected.presets
}

output "catalog_traffic_plans" {
  value = data.hostkey_traffic_plans.for_preset.traffic_plans
}

Ստուգումը պետք է կատարվի երկու պատճառով: Provider-ը պահանջում է անունների ճիշտ համընկնում, իսկ կատալոգում կան նմանատիպ տրաֆիկ պլանների անուններ, օրինակ՝ 3 TB / 1 Gbps VM և 3Tb traffic (1Gbps) VM: Բացի այդ, կատալոգի բովանդակությունը կախված է տեղակայումից և փոփոփոխվում է ժամանակի ընթացքում, ուստի այսօր հասանելի preset-ը վաղը կարող է չլինել հասանելի:

Հաջորդը սերվերի նկարագրությունն է.

resource "hostkey_server" "web" {
  preset_name       = var.preset_name
  location_name     = var.location
  traffic_plan_name = var.traffic_plan_name
  deploy_period     = "monthly"

  os_name   = "Ubuntu 22.04"
  root_pass = var.root_pass
  ssh_key   = file(pathexpand(var.ssh_public_key_path))

  power_state = "on"

  cancellation_type   = 1
  cancellation_reason = "terraform"

  tags = {
    env = "demo"
  }

  timeouts {
    create = "90m"
    update = "90m"
    delete = "30m"
  }
}

timeouts բլոկը սահմանում է, թե որքան ժամանակ Terraform-ը պետք է սպասի գործողության ավարտին: Տեղակայումը սովորաբար տևում է մի քանի րոպե, սակայն, եթե սպասումը կտրվում է timeout-ի պատճառով, պատվերը մնում է վճարված, մինչդեռ Terraform-ը կորցնում է դրա վերահսկողությունը:

cancellation_type արգումենտը, սահմանված 1 արժեքով, անմիջապես չեղարկում է ծառայությունը, մինչդեռ 0-ը թողնում է այն աշխատել վճարված ժամանակաշրջանի ավարտին:

Հաշվի պահոցում SSH բանալին ստեղծվում է առանձին.

resource "hostkey_ssh_key" "deploy" {
  name = "tf-deploy"
  key  = file(pathexpand(var.ssh_public_key_path))
}

Սա նույնն է, ինչ hostkey_server-ի ssh_key ատրիբուտը: Սերվերի ատրիբուտը բանալին գրում է մեքենայի վրա օպերացիոն համակարգի տեղակայման ժամանակ, մինչդեռ hostkey_ssh_key ռեսուրսը պահում է բանալին հաշվի մեջ հետագա օգտագործման համար:

Ֆայլն ավարտվում է output բլոկերով: Պատվերից հետո Terraform-ը տպում է սերվերի հասցեն, նրա իդենտիֆիկատորը և հաշիվի համարը, իսկ terraform output main_ipv4 հրամանը ցույց է տալիս հասցեն ցանկացուց հետո, ինչը շատ հարմար է հաջորդ գործողությունների համար:

output "server_id" {
  value = hostkey_server.web.id
}

output "main_ipv4" {
  value = hostkey_server.web.main_ipv4
}

output "invoice" {
  value = hostkey_server.web.invoice
}

variables.tf¶

variable "location" {
  type    = string
  default = "FI"
}

variable "preset_name" {
  type    = string
  default = "vm.v2-pico"
}

variable "traffic_plan_name" {
  type    = string
  default = "3 TB / 1 Gbps VM"
}

variable "root_pass" {
  type      = string
  sensitive = true
}

variable "ssh_public_key_path" {
  type    = string
  default = "~/.ssh/id_ed25519.pub"
}

terraform.tfvars¶

Այս ֆայլը պահում է գաղտնաբառը, ուստի այն չի ներառվում version control-ում.

root_pass = "StrongPass1%"

# Defaults-ը կարող է փոփոխվել այստեղ
# location          = "NL"
# preset_name       = "vm.v3-pico"
# traffic_plan_name = "5 TB / 1 Gbps VM"

Քայլ 4. Ինիցիալիզացնել provider-ը¶

Բանալին փոխանցվում է որպես շրջակա միջավայրի փոփոխական, որպեսզի այն չհայտնվի նախագծի ֆայլերում.

$env:HOSTKEY_API_KEY = "your-key"

Windows-ի command prompt-ում օգտագործեք set HOSTKEY_API_KEY=your-key, իսկ Linux-ում և macOS-ում՝ export HOSTKEY_API_KEY="your-key": Փոփոխականը գործում է միայն տվյալ տերմինալի սեսիայի համար:

Հաջորդիվ պետք է ներբեռնվի provider-ը.

terraform init

Terraform-ը ներբեռնում է provider-ը և ստեղծում .terraform.lock.hcl ֆայլ՝ հստակ տարբերակով: Այս ֆայլը ներառվում է պահոստոցում (repository), քանի որ այն երաշխավորում է, որ նախագծի բոլոր մասնակիցները կունենան նույն տեղակայված տարբերակը:

Քայլ 5. Վավերացնել կոնֆարկացիան¶

Սինտաքսը ստուգվում է առանց API կանչի.

terraform validate

Հաջողված ստուգումը տպում է Success! The configuration is valid.:

Այնուհետև գալիս է plan-ը, որը ցույց է տալիս առաջիկա փոփոխությունները՝ առանց դրանցից որևէ մեկը իրականացնելու.

terraform plan

Summary line. Ակնկալեք Plan: 2 to add, 0 to change, 0 to destroy, այսինքն՝ սերվեր և SSH բանալի:

Resolved identifiers. Provider-ը անունների կողքին լրացնում է preset_id, os_id և traffic_plan_id արժեքները, և եթե անունը չի գտնվում կատալոգում, plan-ը ձախողվում է նախքան որևէ վճարման իրականացումը:

Catalog. Changes to Outputs բաժինը թվարկում է preset-ները և տրաֆիկ պլանները, և կոնֆարկացիայում նշված արժեքները պետք է գրված լինեն հենց այդպես:

Քայլ 6. Պատվիրել սերվերը¶

terraform apply

Terraform-ը ևս մեկ անգամ ցույց է տալիս plan-ը և հարցնում է հաստատում. գրեք yes և սեղմեք Enter:

Նախ ստեղծվում է SSH բանալին, այնուհետև սկսվում է սերվերի պատվիրումը, և Terraform-ը ինքնուրույն հաշվարկում է հերթականությունը՝ հիմնվելով կախվածություններ վրա:

Դրանից հետո հայտնվում են Still creating... տողերը, որոնք թարմացվում են յուրաքանչյուր տասը վայրկյանը մեկ, մինչդեռ provider-ը հարցումներ է ուղարկում API-ին և սպասում տեղակայման ավարտին: Միդերկում սերվերը տեսանելի է կառավարման վահանակում.

Երբ ամեն ինչ պատրաստ է, արժեքները տպվում են: Արժե է ստուգել SSH հասանելիությունը ձեր ստացած հասցեով.

ssh_key ատրիբուտում նշված բանալին արդեն առկա է սերվերի վրա, ուստի գաղտնաբառ չի պահանջվում: Նոր սերվերը կառավարման վահանակում հայտնվում է ձեռքով պատվիրված սերվերների կողքին.

Քայլ 7. Փոփոխել կոնֆարկացիան¶

Փոփոխությունները բաժանվում են երեք կատեգորիայի.

• Safe changes. Թեգերը և էներգետիկ վիճակը (power state) կիրառվում են աշխատող սերվերի վրա, և plan-ը դրանք ցույց է տալիս որպես update in-place:

• Operating system reinstall. os_name, soft_name, root_pass կամ ssh_key փոփոխելը նշանակում է օպերացիոն համակարգի վերատեղակայում նույն սերվերի վրա, ինչը նշանակում է, որ սկավառակի վրա եղած բոլոր տվյալները կկորցվեն:

• A new order. preset_name, location_name, traffic_plan_name կամ deploy_period փոփոխելը նշանակում է, որ նախորդ սերվերը չեղարկվում է և պատվիրվում է նորը, ինչի հետևանքով ձեզնից նորին վճար կպահվի: Plan-ը նման փոփոխությունները նշում է որպես forces replacement:

Քայլ 8. Ունչնահատուկ ռեսուրսների ոչնչացում (Destroy)¶

terraform destroy

terraform destroy-ն հեռացնում է բոլոր այն ռեսուրսները, որոնք ներկայումս գտնվում են տվյալ կոնֆարկացիայի Terraform state-ում: Terraform-ը կցուցադրի հեռացվող ռեսուրսների ցանկը և հարց կտա հաստատման համար: Մուտքագրեք yes և սեղմեք Enter:

Եթե ցանկանում եք հեռացնել միայն մեկ ռեսուրս, կարող եք նշել այն -target պարամետրով: Օրինակ՝

terraform destroy -target=hostkey_server.web

Այստեղ web-ը resource "hostkey_server" "web" բլոկի ռեսուրսի անունն է, այլ ոչ թե սերվերի ID-ն կառավարման վահանակում:

Մեկ այլ տարբերակ՝ ռեսոուրսը հեռացնելն է .tf ֆայլերից և հետո գործարկել՝

terraform apply

Terraform-ը կտեսնի, որ ռեսուրսը այլևս առկա չէ կոնֆարկացիայում, և կհեռացնի այն ենթակառուցվածքից:

Ծառայության չեղարկումը կատարվում է Invapi-ի միջոցով, և չեղարկման մեթոդը որոշվում է cancellation_type պարամետրով. 1-ը չեղարկում է ծառայությունը անմիջապես, իսկ 0-ը՝ վճարված ժամանակաշրջանի ավարտին:

Գոյություն ունեցող սերվերների ներդրում (Importing)¶

Կառավարման վահանակի միջոցով պատվիրված սերվերները կարող են դառնալ Terraform-ի կառավարման ներքև: Իդենտիֆիկատորը վերցվում է սերվերների ցանկի ID սյունակից.

terraform import hostkey_server.web 19463

Ներդրումից հետո state-ը պահում է իրական տվյալները, այսինքն՝ իդենտիֆիկատորը, հասցեն, կարգավիճակը և էներգետիկ վիճակը: Պատվերի ժամանակ ստացված արգումենտները չեն փոխանցվում կառավարման վահանակից, ուստի դրանք պետք է ձեռքով նկարագրվեն կոնֆարկացիայում: Ներդրումից հետո առաջին terraform apply-ը չի հանգեցնում վերատեղակայման:

Խնդիրների հնարավորությունների լուծում (Troubleshooting)¶