Terraform pitfalls

I-highlight natin ang ilang mga pitfalls, kabilang ang mga nauugnay sa mga loop, kung ang mga pahayag at mga diskarte sa pag-deploy, pati na rin ang mga mas pangkalahatang isyu na nakakaapekto sa Terraform sa pangkalahatan:

• ang bilang at para sa_bawat mga parameter ay may mga limitasyon;
• limitahan ang zero downtime deployment;
• kahit na ang isang magandang plano ay maaaring mabigo;
• ang refactoring ay maaaring magkaroon ng mga pitfalls nito;
• pare-pareho ang ipinagpaliban na pagkakaugnay-ugnay... may pagpapaliban.

Ang bilang at para sa_bawat mga parameter ay may mga limitasyon

Malawakang ginagamit ng mga halimbawa sa kabanatang ito ang count parameter at ang for_each expression sa mga loop at conditional logic. Mahusay ang kanilang pagganap, ngunit mayroon silang dalawang mahahalagang limitasyon na kailangan mong malaman.

• Hindi maaaring mag-refer ang Count at for_each sa anumang mga variable na output ng mapagkukunan.
• count and for_each ay hindi magagamit sa configuration ng module.

count at for_each ay hindi maaaring sumangguni sa anumang mga variable na output ng mapagkukunan

Isipin na kailangan mong mag-deploy ng ilang EC2 server at sa ilang kadahilanan ay ayaw mong gumamit ng ASG. Maaaring ganito ang iyong code:

resource "aws_instance" "example_1" {
   count             = 3
   ami                = "ami-0c55b159cbfafe1f0"
   instance_type = "t2.micro"
}

Tingnan natin sila isa-isa.

Dahil ang count parameter ay nakatakda sa isang static na halaga, ang code na ito ay gagana nang walang problema: kapag pinatakbo mo ang apply command, lilikha ito ng tatlong EC2 server. Ngunit paano kung gusto mong mag-deploy ng isang server sa bawat Availability Zone (AZ) sa loob ng iyong kasalukuyang rehiyon ng AWS? Maaari mong i-load ang iyong code ng isang listahan ng mga zone mula sa aws_availability_zones data source at pagkatapos ay i-loop ang bawat isa at lumikha ng isang EC2 server dito gamit ang count parameter at array index access:

resource "aws_instance" "example_2" {
   count                   = length(data.aws_availability_zones.all.names)
   availability_zone   = data.aws_availability_zones.all.names[count.index]
   ami                     = "ami-0c55b159cbfafe1f0"
   instance_type       = "t2.micro"
}

data "aws_availability_zones" "all" {}

Ang code na ito ay gagana rin nang maayos, dahil ang parameter ng bilang ay maaaring sumangguni sa mga mapagkukunan ng data nang walang anumang mga problema. Ngunit ano ang mangyayari kung ang bilang ng mga server na kailangan mong gawin ay depende sa output ng ilang mapagkukunan? Upang ipakita ito, ang pinakamadaling paraan ay ang paggamit ng random_integer na mapagkukunan, na, gaya ng iminumungkahi ng pangalan, ay nagbabalik ng random na integer:

resource "random_integer" "num_instances" {
  min = 1
  max = 3
}

Ang code na ito ay bumubuo ng random na numero sa pagitan ng 1 at 3. Tingnan natin kung ano ang mangyayari kung susubukan nating gamitin ang output ng mapagkukunang ito sa count parameter ng aws_instance na mapagkukunan:

resource "aws_instance" "example_3" {
   count             = random_integer.num_instances.result
   ami                = "ami-0c55b159cbfafe1f0"
   instance_type = "t2.micro"
}

Kung magpapatakbo ka ng terraform plan sa code na ito, makukuha mo ang sumusunod na error:

Error: Invalid count argument

   on main.tf line 30, in resource "aws_instance" "example_3":
   30: count = random_integer.num_instances.result

The "count" value depends on resource attributes that cannot be determined until apply, so Terraform cannot predict how many instances will be created. To work around this, use the -target argument to first apply only the resources that the count depends on.

Kinakailangan ng Terraform na kalkulahin ang bilang at para sa_bawat sa panahon ng yugto ng pagpaplano, bago magawa o mabago ang anumang mga mapagkukunan. Nangangahulugan ito na ang count at for_each ay maaaring sumangguni sa mga literal, variable, pinagmumulan ng data, at kahit na mga listahan ng mapagkukunan (hangga't ang haba ng mga ito ay maaaring matukoy sa oras ng pag-iiskedyul), ngunit hindi sa mga nakalkulang variable na output ng mapagkukunan.

count and for_each ay hindi magagamit sa configuration ng module

Sa ibang araw, maaari kang matukso na magdagdag ng parameter ng bilang sa configuration ng iyong module:

module "count_example" {
     source = "../../../../modules/services/webserver-cluster"

     count = 3

     cluster_name = "terraform-up-and-running-example"
     server_port = 8080
     instance_type = "t2.micro"
}

Sinusubukan ng code na ito na gumamit ng count sa loob ng isang module upang lumikha ng tatlong kopya ng mapagkukunan ng webserver-cluster. O baka gusto mong gawing opsyonal ang pagkonekta sa isang module batay sa ilang kundisyon ng Boolean sa pamamagitan ng pagtatakda ng parameter ng bilang nito sa 0. Maaaring mukhang makatwirang code ito, ngunit makukuha mo ang error na ito kapag nagpapatakbo ng terraform plan:

Error: Reserved argument name in module block

   on main.tf line 13, in module "count_example":
   13: count = 3

The name "count" is reserved for use in a future version of Terraform.

Sa kasamaang palad, mula sa Terraform 0.12.6, ang paggamit ng count o for_each sa isang mapagkukunan ng module ay hindi suportado. Ayon sa mga tala sa paglabas ng Terraform 0.12 (http://bit.ly/3257bv4), plano ng HashiCorp na idagdag ang kakayahang ito sa hinaharap, kaya depende sa kung kailan mo binasa ang aklat na ito, maaaring available na ito. Para malaman mo sigurado, basahin ang Terraform changelog dito.

Mga Limitasyon ng Zero Downtime Deployment

Ang paggamit ng create_before_destroy block kasama ng ASG ay isang magandang solusyon para sa paggawa ng mga zero-downtime na deployment, maliban sa isang caveat: hindi sinusuportahan ang mga panuntunan sa autoscaling. O para maging mas tumpak, nire-reset nito ang laki ng ASG pabalik sa min_size sa bawat deployment, na maaaring maging problema kung gumagamit ka ng mga panuntunan sa autoscaling upang madagdagan ang bilang ng mga server na tumatakbo.

Halimbawa, ang webserver-cluster module ay naglalaman ng isang pares ng aws_autoscaling_schedule resources, na sa 9 am ay pinapataas ang bilang ng mga server sa cluster mula dalawa hanggang sampu. Kung magde-deploy ka sa, sabihin nating, 11 a.m., magbo-boot up ang bagong ASG gamit ang dalawang server lang sa halip na sampu at mananatili sa ganoong paraan hanggang 9 a.m. sa susunod na araw.

Ang limitasyong ito ay maaaring iwasan sa maraming paraan.

• Baguhin ang parameter ng pag-ulit sa aws_autoscaling_schedule mula 0 9 * * * (“tumakbo sa 9 am”) sa isang bagay na tulad ng 0-59 9-17 * * * (“tumakbo bawat minuto mula 9 am hanggang 5 pm”). Kung mayroon nang sampung server ang ASG, ang pagpapatakbo muli sa panuntunang ito ng autoscaling ay hindi magbabago ng anuman, na kung ano ang gusto namin. Ngunit kung kamakailan lamang nai-deploy ang ASG, titiyakin ng panuntunang ito na sa maximum na isang minuto ang bilang ng mga server nito ay aabot sa sampu. Ito ay hindi isang ganap na eleganteng diskarte, at ang malalaking pagtalon mula sampu hanggang dalawang server at pabalik ay maaari ding magdulot ng mga problema para sa mga user.
• Gumawa ng custom na script na gumagamit ng AWS API para matukoy ang bilang ng mga aktibong server sa ASG, tawagan ito gamit ang external na data source (tingnan ang "External Data Source" sa page 249), at itakda ang nais na_capacity parameter ng ASG sa value na ibinalik ng ang script. Sa ganitong paraan, ang bawat bagong instance ng ASG ay palaging tatakbo sa parehong kapasidad tulad ng kasalukuyang Terraform code at ginagawang mas mahirap ang pagpapanatili.

Siyempre, perpektong may built-in na suporta ang Terraform para sa mga zero-downtime na deployment, ngunit noong Mayo 2019, walang plano ang HashiCorp team na idagdag ang functionality na ito (mga detalye - dito).

Maaaring hindi matagumpay na maipatupad ang tamang plano

Minsan ang utos ng plano ay gumagawa ng isang perpektong tamang plano sa pag-deploy, ngunit ang utos ng paglalapat ay nagbabalik ng isang error. Subukan, halimbawa, ang pagdaragdag ng mapagkukunan ng aws_iam_user na may parehong pangalan na ginamit mo para sa user ng IAM na ginawa mo sa unang bahagi ng Kabanata 2:

resource "aws_iam_user" "existing_user" {
   # Подставьте сюда имя уже существующего пользователя IAM,
   # чтобы попрактиковаться в использовании команды terraform import
   name = "yevgeniy.brikman"
}

Ngayon, kung patakbuhin mo ang utos ng plano, maglalabas ang Terraform ng isang tila makatwirang plano sa pag-deploy:

Terraform will perform the following actions:

   # aws_iam_user.existing_user will be created
   + resource "aws_iam_user" "existing_user" {
         + arn                  = (known after apply)
         + force_destroy   = false
         + id                    = (known after apply)
         + name               = "yevgeniy.brikman"
         + path                 = "/"
         + unique_id         = (known after apply)
      }

Plan: 1 to add, 0 to change, 0 to destroy.

Kung patakbuhin mo ang apply command makakakuha ka ng sumusunod na error:

Error: Error creating IAM User yevgeniy.brikman: EntityAlreadyExists:
User with name yevgeniy.brikman already exists.

   on main.tf line 10, in resource "aws_iam_user" "existing_user":
   10: resource "aws_iam_user" "existing_user" {

Ang problema, siyempre, ay mayroon nang IAM user na may ganoong pangalan. At ito ay maaaring mangyari hindi lamang sa mga gumagamit ng IAM, ngunit sa halos anumang mapagkukunan. Posibleng may gumawa ng resource na ito nang manu-mano o gumagamit ng command line, ngunit sa alinmang paraan, humahantong sa mga salungatan ang pagtutugma ng mga ID. Mayroong maraming mga pagkakaiba-iba ng error na ito na kadalasang nakakakuha ng mga bagong dating sa Terraform nang biglaan.

Ang pangunahing punto ay ang utos ng plano ng terraform ay isinasaalang-alang lamang ang mga mapagkukunang iyon na tinukoy sa file ng estado ng Terraform. Kung ang mga mapagkukunan ay nilikha sa ibang paraan (halimbawa, nang manu-mano sa pamamagitan ng pag-click sa AWS console), hindi sila mapupunta sa state file at samakatuwid ay hindi isasaalang-alang ng Terraform ang mga ito kapag isinasagawa ang command ng plano. Bilang resulta, ang isang plano na tila tama sa unang tingin ay magiging hindi matagumpay.

May dalawang aral na mapupulot dito.

• Kung nagsimula ka nang magtrabaho sa Terraform, huwag gumamit ng iba pa. Kung ang bahagi ng iyong imprastraktura ay pinamamahalaan gamit ang Terraform, hindi mo na ito maaaring baguhin nang manu-mano. Kung hindi, hindi ka lang nanganganib ng mga kakaibang error sa Terraform, ngunit tinatanggihan mo rin ang marami sa mga benepisyo ng IaC dahil hindi na magiging tumpak na representasyon ng iyong imprastraktura ang code.
• Kung mayroon ka nang ilang imprastraktura, gamitin ang command sa pag-import. Kung sisimulan mong gamitin ang Terraform sa umiiral na imprastraktura, maaari mo itong idagdag sa state file gamit ang terraform import command. Sa ganitong paraan malalaman ng Terraform kung anong imprastraktura ang kailangang pamahalaan. Ang import command ay tumatagal ng dalawang argumento. Ang una ay ang resource address sa iyong mga configuration file. Ang syntax dito ay kapareho ng para sa mga link ng mapagkukunan: _. (tulad ng aws_iam_user.existing_user). Ang pangalawang argumento ay ang ID ng resource na ii-import. Sabihin nating ang resource ID na aws_iam_user ay ang user name (halimbawa, yevgeniy.brikman), at ang resource ID na aws_instance ay ang EC2 server ID (tulad ng i-190e22e5). Kung paano mag-import ng mapagkukunan ay karaniwang ipinahiwatig sa dokumentasyon sa ibaba ng pahina nito.

  Nasa ibaba ang isang import command na nagsi-synchronize sa aws_iam_user na mapagkukunan na idinagdag mo sa iyong configuration ng Terraform kasama ng IAM user sa Kabanata 2 (siyempre, pinapalitan ang iyong pangalan para sa yevgeniy.brikman):

  $ terraform import aws_iam_user.existing_user yevgeniy.brikman

  Tatawagan ng Terraform ang AWS API upang mahanap ang iyong IAM user at gagawa ng state file association sa pagitan nito at ng aws_iam_user.existing_user na mapagkukunan sa iyong Terraform configuration. Mula ngayon, kapag pinatakbo mo ang utos ng plano, malalaman ng Terraform na umiiral na ang user ng IAM at hindi na susubukang gawin itong muli.

  Kapansin-pansin na kung marami ka nang mapagkukunan na gusto mong i-import sa Terraform, maaaring maging abala ang manu-manong pagsulat ng code at pag-import ng bawat isa nang paisa-isa. Kaya sulit na tingnan ang isang tool tulad ng Terraforming (http://terraforming.dtan4.net/), na maaaring awtomatikong mag-import ng code at estado mula sa iyong AWS account.

  Maaaring magkaroon ng mga pitfalls ang refactoring

  Refactoring ay isang karaniwang kasanayan sa programming kung saan binabago mo ang panloob na istraktura ng code habang iniiwan ang panlabas na pag-uugali na hindi nagbabago. Ito ay upang gawing mas malinaw, mas malinis, at mas madaling mapanatili ang code. Ang refactoring ay isang kailangang-kailangan na pamamaraan na dapat gamitin nang regular. Ngunit pagdating sa Terraform o anumang iba pang tool ng IaC, kailangan mong maging lubhang maingat tungkol sa kung ano ang ibig mong sabihin sa "panlabas na pag-uugali" ng isang piraso ng code, kung hindi, magkakaroon ng mga hindi inaasahang problema.

  Halimbawa, ang isang karaniwang uri ng refactoring ay ang pagpapalit ng mga pangalan ng mga variable o function ng mga mas nauunawaan. Maraming IDE ang may built-in na suporta para sa refactoring at maaaring awtomatikong palitan ang pangalan ng mga variable at function sa buong proyekto. Sa pangkalahatang layunin na mga programming language, ito ay isang maliit na pamamaraan na maaaring hindi mo iniisip, ngunit sa Terraform kailangan mong maging lubhang maingat dito, kung hindi, maaari kang makaranas ng mga pagkawala.

  Halimbawa, ang webserver-cluster module ay may input variable cluster_name:

  variable "cluster_name" {
     description = "The name to use for all the cluster resources"
     type          = string
  }

  Isipin na sinimulan mong gamitin ang module na ito para mag-deploy ng microservice na tinatawag na foo. Sa ibang pagkakataon, gusto mong palitan ang pangalan ng iyong serbisyo sa bar. Ang pagbabagong ito ay maaaring mukhang walang halaga, ngunit sa katotohanan maaari itong magdulot ng mga pagkaantala sa serbisyo.

  Ang katotohanan ay ang webserver-cluster module ay gumagamit ng cluster_name variable sa isang bilang ng mga mapagkukunan, kabilang ang parameter ng pangalan ng dalawang pangkat ng seguridad at ang ALB:

  resource "aws_lb" "example" {
     name                    = var.cluster_name
     load_balancer_type = "application"
     subnets = data.aws_subnet_ids.default.ids
     security_groups      = [aws_security_group.alb.id]
  }

  Kung babaguhin mo ang parameter ng pangalan sa isang mapagkukunan, tatanggalin ng Terraform ang lumang bersyon ng mapagkukunang iyon at gagawa ng bago sa lugar nito. Ngunit kung ang mapagkukunang iyon ay isang ALB, sa pagitan ng pagtanggal nito at pag-download ng bagong bersyon, hindi ka magkakaroon ng mekanismo upang i-redirect ang trapiko sa iyong web server. Gayundin, kung ang isang pangkat ng seguridad ay tinanggal, ang iyong mga server ay magsisimulang tanggihan ang anumang trapiko sa network hanggang sa isang bagong pangkat ay nilikha.

  Ang isa pang uri ng refactoring na maaaring interesado ka ay ang pagpapalit ng Terraform ID. Kunin natin ang mapagkukunan ng aws_security_group sa module ng webserver-cluster bilang isang halimbawa:

  resource "aws_security_group" "instance" {
    # (...)
  }

  Ang identifier ng mapagkukunang ito ay tinatawag na instance. Isipin na sa panahon ng refactoring nagpasya kang baguhin ito sa isang mas naiintindihan (sa iyong opinyon) pangalan cluster_instance:

  resource "aws_security_group" "cluster_instance" {
     # (...)
  }

  Ano ang mangyayari sa huli? Tama iyon: isang pagkagambala.

  Iniuugnay ng Terraform ang bawat resource ID sa cloud provider ID. Halimbawa, ang iam_user ay nauugnay sa AWS IAM user ID, at ang aws_instance ay nauugnay sa AWS EC2 server ID. Kung babaguhin mo ang resource ID (sabihin mula instance sa cluster_instance, gaya ng kaso sa aws_security_group), sa Terraform, lalabas ito na parang tinanggal mo ang lumang resource at nagdagdag ng bago. Kung ilalapat mo ang mga pagbabagong ito, tatanggalin ng Terraform ang lumang pangkat ng seguridad at gagawa ng bago, habang ang iyong mga server ay magsisimulang tanggihan ang anumang trapiko sa network.

  Narito ang apat na mahahalagang aral na dapat mong kunin sa talakayang ito.

  • Palaging gamitin ang utos ng plano. Maaari nitong ibunyag ang lahat ng mga sagabal na ito. Suriing mabuti ang output nito at bigyang pansin ang mga sitwasyon kung saan plano ng Terraform na tanggalin ang mga mapagkukunan na malamang na hindi dapat tanggalin.
  • Lumikha bago mo tanggalin. Kung gusto mong palitan ang isang mapagkukunan, pag-isipang mabuti kung kailangan mong gumawa ng kapalit bago tanggalin ang orihinal. Kung oo ang sagot, makakatulong ang create_before_destroy. Ang parehong resulta ay maaaring makamit nang manu-mano sa pamamagitan ng pagsasagawa ng dalawang hakbang: magdagdag muna ng bagong resource sa configuration at patakbuhin ang apply command, at pagkatapos ay alisin ang lumang resource mula sa configuration at gamitin muli ang apply command.
  • Ang pagpapalit ng mga identifier ay nangangailangan ng pagbabago ng estado. Kung gusto mong baguhin ang ID na nauugnay sa isang mapagkukunan (halimbawa, palitan ang pangalan ng aws_security_group mula instance patungong cluster_instance) nang hindi tinatanggal ang mapagkukunan at gumagawa ng bagong bersyon nito, dapat mong i-update ang Terraform state file nang naaayon. Huwag kailanman gawin ito nang manu-mano - sa halip ay gamitin ang terraform state command. Kapag pinapalitan ang pangalan ng mga identifier, dapat mong patakbuhin ang terraform state mv command, na mayroong sumusunod na syntax:

    terraform state mv <ORIGINAL_REFERENCE> <NEW_REFERENCE>

    Ang ORIGINAL_REFERENCE ay isang expression na tumutukoy sa mapagkukunan sa kasalukuyan nitong anyo, at ang NEW_REFERENCE ay kung saan mo gustong ilipat ito. Halimbawa, kapag pinapalitan ang pangalan ng grupong aws_security_group mula instance sa cluster_instance, kailangan mong patakbuhin ang sumusunod na command:

    $ terraform state mv 
       aws_security_group.instance 
       aws_security_group.cluster_instance

    Sinasabi nito sa Terraform na ang estado na dating nauugnay sa aws_security_group.instance ay dapat na ngayong iugnay sa aws_security_group.cluster_instance. Kung pagkatapos palitan ang pangalan at patakbuhin ang command terraform plan na ito ay hindi nagpapakita ng anumang mga pagbabago, pagkatapos ay ginawa mo ang lahat ng tama.

  • Hindi mababago ang ilang setting. Ang mga parameter ng maraming mapagkukunan ay hindi nababago. Kung susubukan mong baguhin ang mga ito, tatanggalin ng Terraform ang lumang mapagkukunan at gagawa ng bago sa lugar nito. Ang bawat pahina ng mapagkukunan ay karaniwang nagsasaad kung ano ang mangyayari kapag binago mo ang isang partikular na setting, kaya siguraduhing suriin ang dokumentasyon. Palaging gamitin ang plan command at isaalang-alang ang paggamit ng create_before_destroy na diskarte.

  Ang ipinagpaliban na pagkakapare-pareho ay pare-pareho... sa pagpapaliban

  Ang ilang mga cloud provider ng API, gaya ng AWS, ay asynchronous at naantala ang pagkakapare-pareho. Nangangahulugan ang asynchrony na ang interface ay makakapagbalik kaagad ng tugon nang hindi naghihintay na makumpleto ang hiniling na pagkilos. Ang pagkaantala ng pagkakapare-pareho ay nangangahulugan na ang mga pagbabago ay maaaring tumagal ng oras upang ipalaganap sa buong system; habang ito ay nangyayari, ang iyong mga tugon ay maaaring hindi pare-pareho at nakadepende sa kung aling data source replica ang tumutugon sa iyong mga tawag sa API.

  Isipin, halimbawa, na gumawa ka ng isang API na tawag sa AWS na humihiling dito na lumikha ng isang EC2 server. Ang API ay magbabalik ng isang "matagumpay" na tugon (201 Ginawa) halos kaagad, nang hindi naghihintay na ang server mismo ay malikha. Kung susubukan mong kumonekta kaagad dito, halos tiyak na mabibigo ito dahil sa puntong iyon ay sinisimulan pa rin ng AWS ang mga mapagkukunan o, bilang kahalili, ang server ay hindi pa nag-boot. Bukod dito, kung gagawa ka ng isa pang tawag upang makakuha ng impormasyon tungkol sa server na ito, maaari kang makatanggap ng error (404 Not Found). Ang bagay ay ang impormasyon tungkol sa EC2 server na ito ay maaari pa ring ipalaganap sa buong AWS bago ito maging available sa lahat ng dako, kailangan mong maghintay ng ilang segundo.

  Sa tuwing gagamit ka ng asynchronous na API na may tamad na pagkakapare-pareho, dapat mong pana-panahong subukang muli ang iyong kahilingan hanggang sa makumpleto ang pagkilos at magpalaganap sa system. Sa kasamaang palad, ang AWS SDK ay hindi nagbibigay ng anumang mahusay na tool para dito, at ang Terraform na proyekto ay dumaranas ng maraming mga bug tulad ng 6813 (https://github.com/hashicorp/terraform/issues/6813):

  $ terraform apply
  aws_subnet.private-persistence.2: InvalidSubnetID.NotFound:
  The subnet ID 'subnet-xxxxxxx' does not exist

  Sa madaling salita, gagawa ka ng resource (tulad ng subnet) at pagkatapos ay subukang kumuha ng ilang impormasyon tungkol dito (tulad ng ID ng bagong likhang subnet), at hindi ito mahanap ng Terraform. Karamihan sa mga bug na ito (kabilang ang 6813) ay naayos na, ngunit paminsan-minsan pa rin ang mga ito, lalo na kapag ang Terraform ay nagdaragdag ng suporta para sa isang bagong uri ng mapagkukunan. Ito ay nakakainis, ngunit sa karamihan ng mga kaso ay hindi nagdudulot ng anumang pinsala. Kapag nagpatakbo ka muli ng terraform apply, lahat ay dapat gumana, dahil sa oras na ito ang impormasyon ay kumalat na sa buong system.

  Ang sipi na ito ay ipinakita mula sa aklat ni Evgeniy Brikman "Terraform: imprastraktura sa antas ng code".

Pinagmulan: www.habr.com