Praktinis „Terraform“ vadovas: įvaldykite infrastruktūrą kaip kodą, padidinkite efektyvumą ir sumažinkite išlaidas

# Praktinis „Terraform“ vadovas: įvaldykite infrastruktūrą kaip kodą, padidinkite efektyvumą ir sumažinkite išlaidas „Terraform“ yra populiarus infrastruktūros kaip kodo (IaC) įrankis, leidžiantis valdyti ir automatizuoti debesų infrastruktūrą naudojant deklaratyvius konfigūracijos failus. Pavertus infrastruktūrą kodu, „Terraform“ gali padėti padidinti efektyvumą, sumažinti klaidų skaičių ir geriau valdyti debesų aplinką. Šiame straipsnyje, remiantis diskusijomis X/Twitter, pateikiamas praktinis „Terraform“ vadovas, apimantis geriausią praktiką, patarimus ir įrankių rekomendacijas, padėsiančias efektyviau naudoti „Terraform“ praktikoje. ## „Terraform“ vertė ir pranašumai * **Infrastruktūra kaip kodas (IaC):** Infrastruktūros konfigūracijos apibrėžimas kaip kodas, leidžiantis versijų valdymą, automatizuotą diegimą ir pakartojamumą. * **Kelių platformų palaikymas:** Palaiko įvairius debesų paslaugų teikėjus (AWS, Azure, GCP ir kt.) ir vietines aplinkas. * **Deklaratyvi konfigūracija:** Apibūdina norimą būseną, o „Terraform“ automatiškai atlieka reikiamus veiksmus, kad pasiektų tą būseną. * **Būsenos valdymas:** „Terraform“ seka jūsų infrastruktūros būseną ir atlieka reikiamus pakeitimus, kad konfigūracija būtų nuosekli. * **Moduliškumas:** Infrastruktūros padalijimas į pakartotinai naudojamus modulius, supaprastinantis konfigūraciją ir priežiūrą. ## „FinOps“ ir „Terraform“: sumažinkite išlaidas debesims @@AskYoshik tviterio žinutė pabrėžė „FinOps“ inžinierių svarbą ir tai, kad jų atlyginimai yra didesni nei „DevOps“ inžinierių, nes išlaidų optimizavimas tapo svarbiausiu prioritetu. Štai keletas pagrindinių punktų, kaip „Terraform“ gali atlikti svarbų vaidmenį „FinOps“ srityje: * **Rightsizing (tinkamas išteklių dydžio nustatymas):** Naudokite „Terraform“ automatizuoti AWS EC2 instancijų, Kubernetes klasterių ir kitų debesų išteklių dydžio keitimą, užtikrinant maksimalų išteklių panaudojimą ir išvengiant švaistymo. Pavyzdžiui, galite parašyti „Terraform“ konfigūraciją, kuri automatiškai keičia EC2 instancijų skaičių arba Kubernetes Pod replikų skaičių pagal CPU naudojimą. * **Automatizuotas išteklių išjungimas:** Ne gamybos aplinkoms, tokioms kaip kūrimo ir testavimo aplinkos, ištekliai gali būti automatiškai išjungiami ne darbo valandomis, siekiant sutaupyti išlaidas. „Terraform“ tai gali pasiekti per CloudWatch Event ir Lambda funkcijas. * **Naudokite ekonomiškai efektyvius išteklius:** „Terraform“ gali padėti pasirinkti ekonomiškai efektyviausius išteklių tipus. Pavyzdžiui, galite pasirinkti Spot Instances, kad sumažintumėte EC2 instancijų kainą, arba pasirinkti pigesnį saugojimo lygį. * **Žymų valdymas:** Naudokite „Terraform“ pridėti žymes prie visų išteklių, kad būtų galima geriau analizuoti ir sekti išlaidas. **Praktinis patarimas: „Rightsizing“ naudojant „Terraform“** Štai pavyzdys, kaip naudoti „Terraform“ automatiškai keisti EC2 instancijų skaičių: ```terraform resource "aws_autoscaling_group" "example" { name = "example-asg" max_size = 5 min_size = 1 desired_capacity = 1 health_check_type = "EC2" force_delete = true launch_template { id = aws_launch_template.example.id version = "$Latest" } tag { key = "Name" value = "example-asg" propagate_at_launch = true } ```

Šis pavyzdys demonstruoja, kaip nustatyti AWS Auto Scaling grupę su CloudWatch Alarms, kurie suaktyvina mastelio keitimą aukštyn ir žemyn, atsižvelgiant į CPU išnaudojimą.

Pagrindiniai komponentai:

• aws_launch_template: Apibrėžia EC2 instancijos šabloną, naudojamą Auto Scaling grupėje.
• aws_autoscaling_group: Valdo EC2 instancijų grupę, automatiškai keičiant mastelį pagal poreikį.
• aws_cloudwatch_metric_alarm: Stebi CPU išnaudojimą ir suaktyvina veiksmus, kai viršijama arba nepasiekiama nustatyta riba.
• aws_autoscaling_policy: Apibrėžia mastelio keitimo veiksmus, kuriuos suaktyvina CloudWatch Alarms.

resource "aws_launch_template" "example" {
  name = "example-launch-template"

  image_id      = "ami-0c55b24aca56cf24f" # Pakeiskite tinkamu AMI
  instance_type = "t2.micro"

  network_interface {
    associate_public_ip_address = true
    subnet_id                   = "subnet-0bb1c79de3EXAMPLE" # Pakeiskite tinkamu subnet ID
  }

  user_data = base64encode(
    """#!/bin/bash
    echo "Hello, World!" > index.html
    nohup python -m SimpleHTTPServer 80 &> /dev/null &"
  )

  tag_specifications {
    resource_type = "instance"

    tags = {
      Name = "example-instance"
    }
  }
}

resource "aws_autoscaling_group" "example" {
  name                      = "example-autoscaling-group"
  max_size                  = 3 # Maksimalus instancijų skaičius
  min_size                  = 1 # Minimalus instancijų skaičius
  desired_capacity          = 1 # Pradinis instancijų skaičius
  health_check_type         = "EC2"
  health_check_grace_period = 300
  launch_template {
    id      = aws_launch_template.example.id
    version = "$Latest"
  }
  vpc_zone_identifier = ["subnet-0bb1c79de3EXAMPLE"] # Pakeiskite tinkamu subnet ID

  tag {
    key                 = "Name"
    value               = "example-instance"
    propagate_at_launch = true
  }

  lifecycle {
    create_before_destroy = true
  }
}

resource "aws_cloudwatch_metric_alarm" "cpu_high" {
  alarm_name          = "example-cpu-high"
  comparison_operator = "GreaterThanThreshold"
  evaluation_periods  = 2
  metric_name         = "CPUUtilization"
  namespace           = "AWS/EC2"
  period              = 60
  statistic           = "Average"
  threshold           = 70
  alarm_description   = "Alarm when server CPU exceeds 70%" # Signalas, kai serverio CPU viršija 70%
  dimensions = {
    AutoScalingGroupName = aws_autoscaling_group.example.name
  }

  alarm_actions = [aws_autoscaling_policy.scale_up.arn]
}

resource "aws_cloudwatch_metric_alarm" "cpu_low" {
  alarm_name          = "example-cpu-low"
  comparison_operator = "LessThanThreshold"
  evaluation_periods  = 2
  metric_name         = "CPUUtilization"
  namespace           = "AWS/EC2"
  period              = 60
  statistic           = "Average"
  threshold           = 30
  alarm_description   = "Alarm when server CPU is below 30%" # Signalas, kai serverio CPU yra žemiau 30%
  dimensions = {
    AutoScalingGroupName = aws_autoscaling_group.example.name
  }

  alarm_actions = [aws_autoscaling_policy.scale_down.arn]
}

resource "aws_autoscaling_policy" "scale_up" {
  name                   = "example-scale-up"
  scaling_adjustment     = 1
  adjustment_type        = "ChangeInCapacity"
  cooldown               = 300
  autoscaling_group_name = aws_autoscaling_group.example.name
}

resource "aws_autoscaling_policy" "scale_down" {
  name                   = "example-scale-down"
  scaling_adjustment     = -1
  adjustment_type        = "ChangeInCapacity"
  cooldown               = 300
  autoscaling_group_name = aws_autoscaling_group.example.name
}

Paaiškinimai:

• aws_launch_template: Apibrėžia EC2 instancijos šabloną. Svarbu pakeisti image_id ir subnet_id tinkamomis reikšmėmis jūsų regione ir VPC. user_data skriptas paleidžia paprastą HTTP serverį instancijoje.
• aws_autoscaling_group: Sukuria Auto Scaling grupę. min_size, max_size ir desired_capacity nustato grupės dydžio ribas. vpc_zone_identifier turi būti pakeistas tinkamu subnet ID.
• aws_cloudwatch_metric_alarm: Sukuria du CloudWatch Alarms: vieną, kuris suaktyvina mastelio keitimą aukštyn, kai CPU išnaudojimas viršija 70%, ir kitą, kuris suaktyvina mastelio keitimą žemyn, kai CPU išnaudojimas yra žemiau 30%.
• aws_autoscaling_policy: Apibrėžia mastelio keitimo veiksmus. scaling_adjustment nustato, kiek instancijų reikia pridėti arba pašalinti.

Pastabos:

• Pakeiskite image_id, subnet_id ir kitas regionui specifines reikšmes tinkamomis reikšmėmis.
• Šis pavyzdys naudoja paprastą HTTP serverį user_data. Realiame scenarijuje naudotumėte sudėtingesnę programą.
• Apsvarstykite galimybę naudoti kitus metrikus ir mastelio keitimo strategijas, kad optimizuotumėte savo Auto Scaling grupę.

Šiame pavyzdyje naudojamas `aws_autoscaling_group` automatinio mastelio keitimo grupės sukūrimui ir `aws_cloudwatch_metric_alarm` CPU naudojimo stebėjimui. Kai CPU naudojimas viršija 70%, `scale_up` strategija padidina vieną EC2 instanciją, o kai CPU naudojimas yra mažesnis nei 30%, `scale_down` strategija sumažina vieną EC2 instanciją. ## Geriausia Terraform praktika @@devops_nk tviterio žinutėje paminėta Terraform katalogo struktūra ir tai, kaip realios komandos valdo debesų infrastruktūrą. Štai keletas geriausių praktikų: * **Katalogo struktūra:** Naudokite aiškią katalogo struktūrą, kad atskirtumėte skirtingų aplinkų (dev, staging, prod) konfigūracijas, kad netyčia nepaveiktumėte gamybos aplinkos. ``` environments/ ├── dev/ │ ├── main.tf │ ├── variables.tf │ ├── outputs.tf │ └── terraform.tfvars ├── staging/ │ ├── main.tf │ ├── variables.tf │ ├── outputs.tf │ └── terraform.tfvars └── prod/ ├── main.tf ├── variables.tf ├── outputs.tf └── terraform.tfvars ``` * **Moduliškumas:** Padalinkite infrastruktūrą į pakartotinai naudojamus modulius, tokius kaip VPC modulis, EC2 modulis, duomenų bazės modulis ir kt. Tai gali supaprastinti konfigūraciją ir pagerinti prižiūrimumą. ```terraform module "vpc" { source = "./modules/vpc" name = "my-vpc" cidr_block = "10.0.0.0/16" } ``` * **Naudokite Variables ir Outputs:** Naudokite `variables.tf` kintamųjų apibrėžimui, o `outputs.tf` svarbių išteklių atributų, tokių kaip IP adresai ir DNS pavadinimai, išvedimui. ```terraform # variables.tf variable "instance_type" { type = string default = "t2.micro" } # outputs.tf output "public_ip" { value = aws_instance.example.public_ip } ``` * **Būsenos valdymas:** Naudokite Terraform nuotolinio būsenos valdymo funkciją, tokią kaip Terraform Cloud, S3 arba Azure Blob Storage, kad užtikrintumėte būsenos nuoseklumą ir saugumą. ```terraform terraform { backend "s3" { bucket = "my-terraform-state-bucket" key = "terraform.tfstate" region = "us-east-1" } } ```* **Versijų valdymas:** Laikykite Terraform kodą Git saugykloje ir naudokite šakų strategiją versijų valdymui. * **CI/CD:** Integruokite Terraform į CI/CD vamzdyną, kad įgyvendintumėte automatizuotą diegimą ir testavimą. Daugelyje „Twitter“ įrašų minimi „GitHub Actions“ ir „Jenkins“, kurie yra populiarūs CI/CD įrankiai, kuriuos galima integruoti su Terraform. Pavyzdžiui, @@Abdulraheem183 projektas yra puikus pavyzdys, kaip naudoti „GitHub Actions“ + „Docker“ + Terraform programai diegti į AWS. * **Kodo peržiūra:** Atlikite kodo peržiūrą, kad užtikrintumėte kodo kokybę ir saugumą. * **Naudokite Terraform CLI įrankius:** `terraform fmt` formatuoja kodą, `terraform validate` patikrina kodą. ## Rekomenduojami Terraform įrankiai * **Terraform Cloud:** Suteikia nuotolinio būsenos valdymo, bendradarbiavimo ir automatizavimo funkcijas. * **Terragrunt:** Apgaubia Terraform, suteikia geresnį DRY (Don't Repeat Yourself) palaikymą ir lengviau valdomą katalogo struktūrą. * **tfsec:** Statinės kodo analizės įrankis, skirtas aptikti saugumo pažeidžiamumus Terraform kode. * **Checkov:** Kitas statinės kodo analizės įrankis, skirtas aptikti saugumo pažeidžiamumus ir neatitikties problemas Terraform kode. * **Kiro.dev + MCP (Managed Cloud Platform):** Kaip minėjo @@RoxsRoss, šie įrankiai gali automatiškai generuoti infrastruktūros architektūros diagramas, o tai labai padeda suprasti ir prižiūrėti sudėtingą infrastruktūrą. Nuorodos: [https://github.com/awslabs/mcp](https://github.com/awslabs/mcp) ir [https://kiro.dev](https://kiro.dev) * **hcpt:** @@nnstt1 paminėjo kuriamą HCP Terraform CLI įrankį, į kurį verta atkreipti dėmesį. ## Terraform apribojimai ir iššūkiai * **Mokymosi kreivė:** Terraform turi tam tikrą mokymosi kreivę, ypač komandoms, neturinčioms IaC patirties. * **Būsenos valdymas:** Terraform būsenos failų valdymas yra labai svarbus, jei būsenos failas sugadintas arba prarastas, tai gali sukelti rimtų problemų. * **Sudėtingumas:** Sudėtingai infrastruktūrai Terraform kodas gali tapti labai sudėtingas ir sunkiai prižiūrimas. @@Achinedu001_ paminėjo, kad įdiegus Terraform, vartotojo sąsaja tapo galvos skausmu, reikėjo dažnai peršokti tarp skirtingų konsolės dalių. Tai pabrėžia gero modulinio dizaino ir aiškios architektūros svarbą. * **Priklausomybių valdymas:** Terraform modulių ir teikėjų priklausomybių valdymas gali būti sudėtingas. ## IšvadaTerraform yra galingas IaC įrankis, galintis padėti jums padidinti efektyvumą, sumažinti išlaidas ir geriau valdyti savo debesies aplinką. Laikydamiesi geriausios praktikos, naudodami tinkamus įrankius ir atkreipdami dėmesį į Terraform apribojimus, galite efektyviau naudoti Terraform ir gauti didelės naudos. Tikiuosi, kad šis praktinis vadovas padės jums geriau įvaldyti Terraform ir pritaikyti jį realiems projektams.