Terraform

01Գաղափարը՝ infrastructure as code

Infrastructure as code նշանակում է, որ քո սերվերները, ցանցերը և DNS-ը սահմանված են տեքստային ֆայլերում, պահվում են Git-ում և փոխվում են pull request-ներով, ինչպես հավելվածի կոդը։ Terraform-ը օգտագործում է դեկլարատիվ լեզու՝ HCL. նկարագրում ես ցանկալի վերջնական վիճակը (այս չափի մեկ սերվեր, մեկ DNS գրառում, որը նայում է դրան), ոչ թե այնտեղ հասնելու քայլերը։ Քայլերը Terraform-ն ինքն է հաշվարկում։ Օգուտները շոշափելի են։ Staging միջավայրը կարող է production-ի ճշգրիտ պատճենը լինել։ Թիմի նոր անդամը կարդում է կոդը՝ ենթակառուցվածքը հասկանալու համար։ Փոփոխությունները վերանայվում են մինչև տեղի ունենալը, իսկ Git-ի պատմությունը ցույց է տալիս, թե ով ինչ է փոխել և ինչու։ Աղետից վերականգնումը արագանում է, որովհետև ենթակառուցվածքը կարող ես վերստեղծել կոդից, թեև տվյալները դեռ պետք է գան backup-ներից։

• Դեկլարատիվ՝ նկարագրիր ինչը, ոչ թե ինչպեսը։
• Տարբերակավորված և վերանայվող, ինչպես հավելվածի կոդը։
• Terraform-ը ստեղծում է ենթակառուցվածքը, իսկ Ansible-ի նման գործիքները կարգավորում են այն, ինչ աշխատում է սերվերների ներսում։

02Provider-ներ և ռեսուրսներ

Terraform-ն ինքնին ոչինչ չգիտի AWS-ի կամ DigitalOcean-ի մասին։ Provider-ները plugin-ներ են, որոնք քո կոդը թարգմանում են մեկ պլատֆորմի API կանչերի. կան provider-ներ AWS-ի, Google Cloud-ի, Azure-ի, DigitalOcean-ի, Hetzner-ի, Cloudflare-ի, GitHub-ի, Kubernetes-ի և հարյուրավոր այլ պլատֆորմների համար։ Հայտարարում ես, թե որ provider-ներն են պետք, և ամրագրում դրանց տարբերակները, հետո terraform init-ը ներբեռնում է դրանք և ճշգրիտ տարբերակները գրանցում lock ֆայլում, որը commit ես անում։ Resource բլոկը նկարագրում է կառավարվող մեկ օբյեկտ՝ սերվեր, bucket, DNS գրառում։ Data բլոկը կարդում է արդեն գոյություն ունեցող ինչ-որ բան՝ առանց այն կառավարելու։ Variable-ները կոդը դարձնում են վերաօգտագործելի, output-ները բացահայտում են օգտակար արժեքներ, օրինակ՝ IP հասցեն, իսկ credentials-ը գալիս են environment variable-ներից, ոչ թե կոդից։

1terraform {
2  required_version = ">= 1.10"
3  required_providers {
4    digitalocean = { source = "digitalocean/digitalocean", version = "~> 2.0" }
5    cloudflare   = { source = "cloudflare/cloudflare", version = "~> 5.0" }
6  }
7}
8 
9# tokens come from DIGITALOCEAN_TOKEN and CLOUDFLARE_API_TOKEN env vars
10provider "digitalocean" {}
11provider "cloudflare" {}
12 
13variable "ssh_key_fingerprint" { type = string }
14variable "cloudflare_zone_id" { type = string }

03Օրինակ՝ սերվեր և դրա DNS գրառումը

Ահա իրական ենթակառուցվածքի ամբողջական, փոքր կտոր՝ Ubuntu սերվեր և DNS գրառում, որը hostname-ը ուղղում է դրան։ Ուշադրություն դարձրու DNS գրառման ներսում digitalocean_droplet.web.ipv4_address հղմանը։ Terraform-ը կարդում է այս հղումները՝ կախվածությունների գրաֆ կառուցելու համար, ուստի գիտի, որ սերվերը պետք է գոյություն ունենա, նախքան գրառումը ստեղծելը, և կարող է անկախ ռեսուրսները ստեղծել զուգահեռ։ Եթե հետո փոխես սերվերի չափը, plan-ը ցույց կտա in-place թարմացում, իսկ եթե փոխես image-ը, ցույց կտա, որ սերվերը պետք է ջնջվի ու վերստեղծվի. հենց այդպիսի անակնկալներ բացահայտելու համար է plan-ը։ Output-ը apply-ից հետո տպում է նոր IP-ն։

1resource "digitalocean_droplet" "web" {
2  name     = "web-1"
3  image    = "ubuntu-24-04-x64"
4  region   = "fra1"
5  size     = "s-1vcpu-2gb"
6  ssh_keys = [var.ssh_key_fingerprint]
7}
8 
9resource "cloudflare_dns_record" "app" {
10  zone_id = var.cloudflare_zone_id
11  name    = "app.example.com"
12  type    = "A"
13  content = digitalocean_droplet.web.ipv4_address
14  ttl     = 1
15  proxied = true
16}
17 
18output "server_ip" { value = digitalocean_droplet.web.ipv4_address }

04Plan և apply

Ամենօրյա workflow-ն ունի ֆիքսված ռիթմ։ terraform init-ը պատրաստում է աշխատանքային թղթապանակը և ներբեռնում provider-ները։ terraform fmt-ը և validate-ը բռնում են ոճի ու շարահյուսության խնդիրները։ terraform plan-ը համեմատում է երեք բան՝ քո կոդը, state ֆայլը և իրական ռեսուրսները, հետո տպում է յուրաքանչյուր գործողություն նշանով՝ պլյուս՝ ստեղծման, տիլդա՝ in-place թարմացման, մինուս՝ ջնջման և մինուս-պլյուս՝ փոխարինման համար։ Plan-ը ուշադիր կարդա, հատկապես ցանկացած destroy։ Plan-ը ֆայլում պահելը և հենց այդ ֆայլը կիրառելը երաշխավորում է, որ աշխատում է հենց այն, ինչ վերանայել ես։ Թիմում CI-ը plan է աշխատեցնում յուրաքանչյուր pull request-ի վրա և արդյունքը հրապարակում review-ի համար, իսկ apply-ը աշխատում է merge-ից հետո՝ CI-ից, ոչ թե ինչ-որ մեկի լափթոփից։ Թանկարժեք ռեսուրսների, օրինակ՝ բազաների վրա օգտագործիր prevent_destroy։

1terraform init
2terraform fmt -check
3terraform validate
4terraform plan -out=tfplan
5terraform apply tfplan
6 
7# inspect and troubleshoot
8terraform state list
9terraform output server_ip

05State, remote state և locking

Terraform-ը պահում է state ֆայլ՝ քարտեզ քո կոդի յուրաքանչյուր ռեսուրսից դեպի իրական օբյեկտը, որը կառավարում է, իր ID-ով ու ատրիբուտներով։ Առանց state-ի Terraform-ը չի կարող իմանալ, որ քո կոդի web-ը provider-ի մոտ 12345 սերվերն է։ Լռելյայն state-ը լոկալ ֆայլ է, որը կոտրվում է, հենց որ երկու մարդ կամ CI job է ներգրավվում։ Պահիր այն հեռակա՝ S3 bucket-ում կամ համատեղելի պահոցում, Terraform Cloud-ում կամ այլ backend-ում, versioning-ը միացված, որպեսզի կարողանաս վերականգնել վատ գրառումը։ Locking-ը թույլ չի տալիս երկու apply միաժամանակ աշխատել և վնասել state-ը։ S3 backend-ն այժմ աջակցում է native locking use_lockfile-ով. հին DynamoDB աղյուսակի մեթոդը deprecated է։ State-ը կարող է secret-ներ պարունակել, օրինակ՝ բազայի գաղտնաբառեր, ուստի գաղտնագրիր այն և սահմանափակիր մուտքը։

1terraform {
2  backend "s3" {
3    bucket       = "example-terraform-state"
4    key          = "prod/terraform.tfstate"
5    region       = "eu-central-1"
6    encrypt      = true
7    use_lockfile = true
8  }
9}

06Module-ներ, drift և գործիքների լանդշաֆտը

Module-ը Terraform կոդի թղթապանակ է input-ներով ու output-ներով, ինչպես ֆունկցիան։ Գրիր web-server module մեկ անգամ և կանչիր այն staging-ի ու production-ի համար տարբեր չափերով։ Module-ները պահիր փոքր և կենտրոնացված, ընդհանուրների տարբերակները ամրագրիր, իսկ միջավայրերը պահիր առանձին state ֆայլերում, որպեսզի staging-ում սխալը չկարողանա դիպչել production-ին։ Drift-ը այն է, երբ իրականությունն այլևս չի համապատասխանում կոդին, սովորաբար որովհետև ինչ-որ մեկը կոնսոլում ինչ-որ բան ձեռքով է փոխել։ terraform plan-ը բացահայտում է այն. հետո կա՛մ թարմացնում ես կոդը՝ համապատասխանեցնելու համար, կա՛մ apply ես անում՝ հայտարարված վիճակը վերականգնելու համար։ Ինչ վերաբերում է գործիքներին. HashiCorp-ը 2023-ին Terraform-ը տեղափոխեց Business Source License-ի և այժմ IBM-ի մաս է։ OpenTofu-ն open-source fork-ն է, մեծապես համատեղելի, լրացուցիչ հնարավորություններով, օրինակ՝ ներկառուցված state encryption-ով։ Pulumi-ն HCL-ի փոխարեն օգտագործում է TypeScript, Python կամ Go։

1module "web_staging" {
2  source = "./modules/web-server"
3  name   = "web-staging"
4  size   = "s-1vcpu-1gb"
5}
6 
7module "web_prod" {
8  source = "./modules/web-server"
9  name   = "web-prod"
10  size   = "s-2vcpu-4gb"
11}

07Ինչպես է իրականում աշխատում plan-ը․ գրաֆը, անհայտները և փոխարինման հերթականությունը

Terraform-ը քո կոնֆիգուրացիան վերածում է կախվածությունների գրաֆի։ Յուրաքանչյուր resource, data source, variable և output գագաթ է, իսկ յուրաքանչյուր հղում ստեղծում է կող։ Plan-ի ժամանակ այն provider-ից թարմացնում է յուրաքանչյուր կառավարվող resource, համեմատում է թարմացված state-ը կոնֆիգուրացիայի հետ և provider-ին հարցնում, թե ինչ գործողություն է պետք։ Այն արժեքները, որոնք գոյություն ունեն միայն ստեղծումից հետո, օրինակ՝ նոր սերվերի IP-ն, երևում են որպես known after apply և հոսում են առաջ որպես անհայտներ, այդ պատճառով որոշ plan-եր ցույց են տալիս փոփոխությունների շղթա։ Terraform-ը գրաֆով անցնում է զուգահեռ՝ լռելյայն միաժամանակ տասը գործողություն, որը կարգավորվում է -parallelism-ով։ Երբ արգումենտը հնարավոր չէ թարմացնել տեղում, provider-ը այն նշում է որպես forcing replacement, և լռելյայն Terraform-ը նախ ոչնչացնում է հին օբյեկտը, հետո ստեղծում նորը։ create_before_destroy-ը շրջում է հերթականությունը՝ downtime-ից խուսափելու համար, եթե միայն անունները չեն բախվում։ depends_on-ն օգտագործիր միայն թաքնված կախվածությունների համար, որոնք ոչ մի հղում չի արտահայտում։

1resource "aws_launch_template" "web" {
2  name_prefix   = "web-"            # unique names allow create-before-destroy
3  image_id      = var.ami_id
4  instance_type = "t4g.small"
5 
6  lifecycle {
7    create_before_destroy = true
8    ignore_changes        = [tags["LastScannedAt"]]   # set by another tool
9  }
10}

08count-ն ընդդեմ for_each-ի և refactoring՝ առանց ոչնչացնելու

count-ը ստեղծում է instance-ների ցուցակ, որոնց դիմում են index-ով՝ server[0], server[1], server[2]։ Հեռացրու մուտքային ցուցակի միջին տարրը, և բոլոր հաջորդ index-ները կտեղաշարժվեն, ուստի Terraform-ը կպլանավորի ոչնչացնել և վերստեղծել սերվերներ, որոնք իրականում չեն փոխվել։ for_each-ը ստեղծում է map, որին դիմում են key-ով՝ server["api"], server["worker"], ուստի մեկ key-ի հեռացումն ազդում է միայն այդ instance-ի վրա․ նախընտրիր այն, երբ տարրերն ունեն բնական ինքնություն։ Resource-ի անվանափոխումը կամ module-ի մեջ տեղափոխելը նույնպես փոխում է դրա հասցեն, և առանց օգնության Terraform-ը կոչնչացներ հին հասցեն և կստեղծեր նորը։ moved block-ը անվանափոխումը հայտարարում է կոդում, ուստի plan-ը ցույց է տալիս տեղափոխություն՝ առանց փոփոխությունների, և թիմակիցներն ու CI-ը դա ավտոմատ վերցնում են, ինչը terraform state mv-ն չի կարող անել։ Resource-ը կառավարելը դադարեցնելու համար՝ առանց այն ոչնչացնելու, օգտագործիր removed block՝ lifecycle destroy = false-ով։ Գոյություն ունեցող resource-ը «որդեգրելու» համար օգտագործիր import block։

1resource "digitalocean_droplet" "app" {
2  for_each = { api = "s-2vcpu-4gb", worker = "s-1vcpu-2gb" }
3  name     = "app-${each.key}"
4  size     = each.value
5  image    = "ubuntu-24-04-x64"
6  region   = "fra1"
7}
8 
9moved {
10  from = digitalocean_droplet.web
11  to   = digitalocean_droplet.app["api"]
12}
13 
14import {
15  to = cloudflare_dns_record.legacy
16  id = "zone_id/record_id"
17}

09Գաղտնիքներ․ sensitive, ephemeral և write-only արժեքներ

Variable-ը կամ output-ը sensitive = true նշելը միայն թաքցնում է այն plan-ի արդյունքում և log-երում․ արժեքը միևնույն է գրվում է state ֆայլում բաց տեքստով։ Այդ պատճառով state-ը պետք է գաղտնագրված լինի, և հասանելիությունը՝ վերահսկվի։ Նոր տարբերակները ավելի հեռուն են գնում։ Terraform 1.10-ը ավելացրեց ephemeral input variable-ներ, output-ներ և ephemeral resource-ներ՝ արժեքներ, որոնք գոյություն ունեն գործարկման ընթացքում, բայց երբեք չեն գրվում plan կամ state ֆայլերում, օրինակ՝ secret manager-ից վերցված գաղտնաբառը։ Terraform 1.11-ը ավելացրեց write-only արգումենտներ՝ _wo վերջածանցով, որոնք թույլ են տալիս կառավարվող resource-ներին ընդունել այդ ephemeral արժեքները․ provider-ը գաղտնիքն ուղարկում է API-ին, բայց երբեք չի պահում։ Քանի որ Terraform-ը չի տեսնում պահված արժեքը, այն rotation անելու համար մեծացնում ես ուղեկից version արգումենտը։ Ավելի պարզ տարբերակ, որտեղ պլատֆորմն աջակցում է, ծառայությանը թույլ տալն է ինքը գեներացնի և կառավարի գաղտնիքը, ինչպես RDS-ը կարող է manage_master_user_password-ով, այնպես որ Terraform-ը այն երբեք չի տեսնում։

1ephemeral "random_password" "db" {
2  length = 32
3}
4 
5resource "aws_db_instance" "main" {
6  identifier          = "app-prod"
7  engine              = "postgres"
8  instance_class      = "db.t4g.medium"
9  allocated_storage   = 50
10  username            = "app"
11  password_wo         = ephemeral.random_password.db.result
12  password_wo_version = 1          # bump to rotate
13}

10Պաշտպանիչ ցանկապատեր․ validation, check-եր, թեստեր և policy as code

Terraform-ն ունի ներկառուցված ստուգումների մի քանի շերտ։ Variable-ի validation block-երը մերժում են սխալ մուտքը դեռ plan-ից առաջ, օրինակ՝ անհայտ միջավայրի անուն կամ instance-ի չափ, որը թույլատրված ցուցակում չէ։ Resource-ի lifecycle-ի ներսում precondition-ները և postcondition-ները ձևակերպում են ենթադրություններ, որոնք պետք է ճիշտ լինեն, օրինակ՝ որ ընտրված image-ը ճիշտ ճարտարապետության համար է։ Check block-երը գործարկում են assertion-ներ apply-ից հետո, օրինակ՝ HTTP request նոր endpoint-ին, և հաղորդում են warning-ներ՝ առանց արգելափակելու։ terraform test հրամանը, .tftest.hcl-ով ավարտվող ֆայլերով, plan կամ apply է անում թեստային մուտքերով և ստուգում արդյունքները․ այսպես են module-ների հեղինակները բռնում regression-ները։ Terraform-ից դուրս tflint-ը գտնում է provider-ին հատուկ սխալներ, Checkov-ի կամ Trivy-ի նման scanner-ները նշում են անապահով կարգավորումներ, օրինակ՝ բաց security group-եր, իսկ policy engine-ները, ինչպիսիք են OPA-ն Conftest-ի հետ կամ Sentinel-ը HCP Terraform-ում, apply-ից առաջ plan-ի վրա կիրառում են կազմակերպության կանոնները։

1variable "environment" {
2  type = string
3  validation {
4    condition     = contains(["staging", "prod"], var.environment)
5    error_message = "environment must be staging or prod."
6  }
7}
8 
9check "site_up" {
10  data "http" "health" { url = "https://app.example.com/healthz" }
11  assert {
12    condition     = data.http.health.status_code == 200
13    error_message = "Health check did not return 200."
14  }
15}