Terraformi varjuküljed

Toome mõned kibedused, sealhulgas need, mis on seotud tsüklite, if-lausete ja deploy’imise meetoditega, samuti üldiste probleemidega, mis puudutavad Terraformi laiemalt:

• parameetrites count ja for_each on piirangud;
• nullaegade vahedega seotud deploymise piirangud;
• isegi hea plaan võib osutuda ebaõnnestunud;
• refaktoreerimisel võivad olla oma üllatused;
• viivitatud kooskõla on seotud… viivitamisega.

Parameetrid count ja for_each on piirangud

Selle peatüki näidetes kasutatakse parameetrit count ja väljendit for_each aktiivselt tsüklites ja tingimuslikus loogikas. Need toimivad hästi, kuid neil on kaks olulist piirangut, millest tuleb teada.

• count ja for_each ei saa viidata ühele olemasoleva ressursi väljundmuutujale.
• count ja for_each ei saa kasutada mooduli konfiguratsioonis.

count ja for_each ei saa viidata ühele olemasoleva ressursi väljundmuutujale

Kujutage ette, et peate käivitama mitu EC2-serverit, kuid mingil põhjusel ei soovi te kasutada ASG-d. Teie kood võiks olla selline:

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

Vaadakem neid ükshaaval.

Kuna parameetrile count on määratud staatiline väärtus, töötab see kood probleemideta: kui käitate apply käsku, loob see kolm EC2-serverit. Aga kui soovite käivitada ühe serveri igas kättesaadavusala (Availability Zone või AZ) praeguses AWS-i regioonis? Te saate teha nii, et teie kood laadib nimekirja tsoonidest aws_availability_zones andmeallikast ja seejärel läbib need „tsükliliselt“ ning loob igas neist EC2-serveri, kasutades parameetrit count ja juurdepääsu massiivi kaudu indeksi järgi:

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" {}

See kood töötab samuti suurepäraselt, kuna parameeter count võib probleemideta viidata andmeallikatele. Aga mis juhtub, kui serverite arv, mille peate looma, sõltub mõne ressursi väljundist? Selle demonstreerimiseks on lihtsam võtta ressursi random_integer, mis, nagu nimi vihjab, tagastab juhusliku täisarvu:

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

See on kood, mis genereerib juhusliku numbri vahemikus 1 kuni 3. Vaatame, mis juhtub, kui proovime kasutada selle ressursi väljundit result parameetrina aws_instance ressursis:

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

Kui käitada selle koodi terraform plan, tekib järgmine viga:

Error: Invalid count argument

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

"count" väärtus sõltub ressursside atribuutidest, mida ei saa määrata enne rakendamist, seetõttu ei saa Terraform ennustada, kui palju instantsi luuakse. Selle lahendamiseks kasutage -target argumenti, et esmalt rakendada ainult ressursse, millele count toetub.

Terraform nõuab, et count ja for_each arvutatakse planeerimise etapis, enne kui mõnda ressurssi luuakse või muudetakse. See tähendab, et count ja for_each võivad viidata konstanditele, muutujatele, andmeallikatele ja isegi ressursside loenditele (kui nende pikkus on planeerimise ajal määratav), kuid mitte arvutatavatele väljundmuutujatele.

count ja for_each ei saa olla modulite konfiguratsioonis kasutuses

Varem või hiljem võib teil tekkida kiusatus lisada count parameeter mooduli konfiguratsioonidesse:

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

     count = 3

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

See kood proovib kasutada count'i mooduli sees, et luua kolm koopiat webserver-cluster ressursist. Või võib-olla soovite mooduli ühenduse teha valikuliseks mingi boolesekondit toetava väärtuse põhjal, määrates count väärtuseks 0. Selline kood näib täiesti mõistlik, kuid terraform plan'i käitamisel tekib teil selline viga:

Error: Reserved argument name in module block

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

Nimi "count" on reserveeritud kasutamiseks tulevikus Terraform'i versioonis.

Kahjuks ei toeta Terraform 0.12.6 seisuga count või for_each kasutamine module ressurssides. Vastavalt Terraform 0.12 väljaannete märkmetele (http:\/\/bit.ly\/3257bv4) plaanib HashiCorp tulevikus sellise võimaluse lisada, seetõttu, sõltuvalt sellest, millal te seda raamatut loete, võib see juba saadaval olla. Et seda kindlasti teada saada, vaadake Terraform'i muudatuste ajalugu siin.

Nulli aegadega juurutamise piirangud

Create_before_destroy ploki kasutamine ASG-ga on suurepärane lahendus nullist seisakutega turutarnete korraldamiseks, välja arvatud üks nüanss: automaatse skaleerimise reeglid ei ole selle puhul toetatud. Või kui olla täpsem, nullib see ASG suuruse tagasi min_size-ks igal tarnel, mis võib muutuda probleemiks, kui olete kasutanud automaatse skaleerimise reegleid serverite arvu suurendamiseks.

Näiteks sisaldab webserver-cluster moodul paari aws_autoscaling_schedule ressursi, mis hommikul kell 9 suurendab klastris serverite arvu kahest kümneni. Kui teete tarnet näiteks kell 11, siis uus ASG rühm ei käivitu kümne, vaid vaid kahe serveriga ja jääb sellesse olekusse kuni järgmise päeva hommikuni kell 9.

Seda piirangut on võimalik ümber mängida mitmel viisil.

• Muuda aws_autoscaling_schedule parameetrit recurrence 0 9 * * * („käivita kell 9 hommikul”) näiteks millegiks selliseks nagu 0-59 9-17 * * * („käivita igal minutil kell 9 hommikul kuni 5 õhtul”). Kui ASG-s on juba kümme serverit, ei muuda selle automaatse skaleerimise reegli uuesti käivitamine midagi, mis ongi vajalik. Kuid kui ASG rühm on hiljuti käivitatud, tagab see reegel, et maksimaalselt minuti jooksul jõuab serverite arv kümnele. See pole just elegantne lähenemine ja suured hüpped kümne serveri ja kahe vahel võivad samuti kasutajatele probleeme tekitada.
• Loo kohandatud skript, mis kasutab AWS API-d aktiivsete serverite arvu määramiseks ASG-s, kutsu see üles välise andmeallika abil (vt jaotist „Väline andmeallikas” lk 249) ja määra ASG rühma desired_capacity parameetriks selle skripti tagastatud väärtus. Seeläbi käivitatakse iga uus ASG instants alati sama mahuga nagu meie Terraformi kood ja keerulisem on selle hooldamine.

Muidugi peaks ideaaljuhul Terraform toetama nullist seisakutega tarnete käivitamist, kuid seisuga mai 2019 ei kavatse HashiCorpi meeskond seda funktsionaalsust lisada (detailid - siin).

Korralik plaan võib osutuda ebaõnnestunuks

Mõnikord, kui käivitate plaani käsu, saadakse täiesti õige juurutusplaan, kuid apply käsk tagastab vea. Proovige näiteks lisada aws_iam_user ressursi sama nimega, mida kasutasite IAM kasutaja jaoks, mille lõite varasemalt peatükis 2:

resource "aws_iam_user" "existing_user" {
   # Sisestage siia juba olemasoleva IAM kasutaja nimi,
   # et harjutada terraform import käsu kasutamist
   name = "yevgeniy.brikman"
}

Nüüd, kui käivitate plaani käsu, väljendab Terraform esmapilgul täiesti mõistlikku juurutusplaani:

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.

Kui käivitate apply käsu, tekib järgmine viga:

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" {

Probleem on loomulikult see, et IAM kasutaja sama nimega juba eksisteerib. Ja see võib juhtuda mitte ainult IAM kasutajatega, vaid ka peaaegu iga ressursiga. Võib-olla on keegi loonud selle ressursi käsitsi või käsureal, kuid igal juhul toovad ID-de kokkulangemised kaasa konflikte. Sellel veal on mitu varianti, mis sageli üllatavad Terraformi algajaid.

Oluline punkt on see, et terraform plan käsk arvestab ainult neid ressursse, mis on ära toodud Terraformi oleku failis. Kui ressursid on loodud mõne muude meetoditega (näiteks käsitsi, klikkides AWS konsoolil), ei jõua need oleku faili ja seega ei arvestata Terraformi poolt plaani käsu täitmisel. Lõppkokkuvõttes osutub näiliselt korrektne plaan ebaõnnestunuks.

Sellest võib tuletada kaks õpetust.

• Kui olete juba Terraformiga töötamise alustanud, ärge kasutage midagi muud. Kui osa teie infrastruktuurist juhitakse Terraformi abil, ei tohi seda käsitsi muuta. Vastasel juhul mitte ainult ei riski te kummaliste Terraformi vigade saamisega, vaid ka kaotate paljusid IaC eeliseid, kuna kood ei kajasta enam täpselt teie infrastruktuuri.
• Kui teil on juba olemas mingi infrastruktuur, kasutage käsku import. Kui hakkate Terraformi kasutama juba olemasoleva infrastruktuuriga, saab selle lisada olekufaili käsuga terraform import. Nii oskab Terraform teads, millise infrastruktuuriga tuleb hallata. Käsk import võtab vastu kaks argumenti. Esimene on ressursi aadress teie konfiguratsioonifailides. Siin kehtib sama süntaks, mis ressursside linkide puhul: _. (nagu aws_iam_user.existing_user). Teine argument on identifikaator ressursile, mille soovite importida. Näiteks on ressursi aws_iam_user ID kasutajanimi (nt yevgeniy.brikman) ja ressursi aws_instance ID EC2 serveri identifikaator (nt i-190e22e5). Kuidas ressurssi importida, on tavaliselt toodud hõive dokumentatsioonis lehe allosas.

  Allpool on toodud käsk import, mis võimaldab sünkroonida ressursi aws_iam_user, mille olete lisanud oma Terraformi konfiguratsiooni koos IAM kasutajaga peatükis 2 (loomulikult tuleks yevgeniy.brikman asemele kirjutada teie nimi):

  $ terraform import aws_iam_user.existing_user yevgeniy.brikman

  Terraform pöördub AWS API poole, et leida teie IAM kasutaja ja luua olekufailis link ressursi aws_iam_user.existing_user ja teie Terraformi konfiguratsiooni vahel. Sellest hetkest alates, kui käivitate käsu plan, teab Terraform, et IAM kasutaja juba eksisteerib, ja ei püüa seda veel kord luua.

  Tasub märkida, et kui teil on juba palju ressursse, mida soovite Terraformi importida, võib igaühe käsitsi kodeerimine ja järjestikune importimine osutuda vaevarikkaks. Seetõttu tasub tähelepanu pöörata sellisele tööriistale nagu Terraforming (http://terraforming.dtan4.net/), mis suudab automaatselt importida AWS kontolt koodi ja oleku.

  Refaktooringul võivad olla oma lõksud

  Refaktooring on laialdaselt levinud praktika programmeerimises, kus muudetakse koodi sisemist struktuuri, jättes välise käitumise muutumatuks. See on vajalik, et muuta kood arusaadavamaks, puhtamaks ja lihtsamaks hooldada. Refaktooring on ülioluline meetod, mida tuleks regulaarselt rakendada. Kuid kui jutt on Terraformist või mõnest muust IaC vahendist, tuleb olla äärmiselt ettevaatlik selles, mida mõistetakse "välise käitumise" all, muidu tekivad ettearvamatud probleemid.

  Näiteks on levinud refaktoreerimise tüüp muutmine muutuja või funktsiooni nimedele selgemateks. Paljud IDE-d pakuvad sisseehitatud refaktoreerimise tuge ja võivad automaatselt ümber nimetada muutujaid ja funktsioone kogu projekti ulatuses. Üldiseks otstarbeks programmeerimiskeeltes on see triviaalne protseduur, millest ei pea eriti mõtlema, kuid Terraformis tuleb olla äärmiselt ettevaatlik, vastasel juhul võib tekkida häireid töös.

  Näiteks on webserver-cluster modulil sisenemisvariable cluster_name:

  variable "cluster_name" {
     description = "Nimi, mida kasutada kõigi klastrite ressursside jaoks"
     type          = string
  }

  Kujutage ette, et hakkasite kasutama seda moodulit mikroteenuse juurutamiseks nimega foo. Hiljem soovisite oma teenuse nime muuta bar-iks. See muudatus võib tunduda triviaalne, kuid tegelikult võivad selle tõttu tekkida häired.

  Asi on selles, et webserver-cluster moodul kasutab muutuja cluster_name mitmesugustes ressurssides, sealhulgas kahes turvagruppide ja ALB nimede parameetris:

  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]
  }

  Kui muudad mõnes ressursis parameetrit name, siis Terraform kustutab selle ressursi vana versiooni ja loob uue. Kuid kui selliseks ressursiks on ALB, siis ajavahemikul, mil see kustutatakse ja uus versioon laaditakse, ei ole sul mehhanismi, et suunata liiklust oma veebiserverisse. Samamoodi, kui kustutatakse turvagrupp, hakkavad sinu serverid igasugust võrgu liiklust tagasi lükkama, kuni kuvatakse uus grupp.

  Teine refaktoreerimise tüüp, mis võiks sind huvitada, on Terraformi identifikaatori muutmine. Võtame näiteks aws_security_group ressursi webserver-cluster moodulis:

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

  Selle ressursi identifikaator on instance. Kujutage ette, et otsustate refaktoreerimise käigus selle muuta mõistetavamaks (sinu arvates) nimeks cluster_instance:

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

  Mis lõpuks juhtuma hakkab? Õige: häired töös.

  Terraform seobade iga iga ressurssi ID pilti pilti pilbiga. Näiteks on iam_user seotud IAM-kasutaja ID-ga AWS-is ja aws_instance on seotud AWS EC2 serveri ID-ga. Kui muudad ressurssi ID-d (ütleme, et instance'ilt cluster_instance'ile, nagu aws_security_group puhul), näeb Terraform seda nagu vana ressursi eemaldamist ja uue lisamist. Kui need muudatused rakendada, eemaldab Terraform vana turbarühma ja loob teise, samas kui teie serverid hakkavad blokeerima igasugust võrguliiklust.

  Siin on neli peamist õppetundi, mille peaksite sellest arutelust välja tõmbama.

  • Kasutage alati käsku plan. Sellega saab tuvastada kõik need probleemid. Vaadake hoolikalt selle väljundit ja pöörake tähelepanu olukordadele, kus Terraform plaanib eemaldada ressursse, mida tõenäoliselt ei tasu eemaldada.
  • Looge enne kustutamist. Kui soovite ressurssi asendada, mõelge põhjalikult, kas uue loomine tuleks teha enne originaali kustutamist. Kui vastus on jaatav, aitab teid create_before_destroy. Sama tulemuse saavutamiseks saate manuaalselt järgida kahte sammu: esmalt lisage konfiguratsiooni uus ressurss ja käivitage käsk apply, seejärel eemaldage konfiguratsioonist vana ressurss ja kasutage käsku apply veel kord.
  • ID-de muutmine nõuab oleku muutmist. Kui soovite muuta ressursiga seotud ID-d (näiteks ümber nimetada aws_security_group instance'ilt cluster_instance'ile), vältides samas ressursi eemaldamist ja uue versiooni loomist, tuleb vastavalt uuendada Terraformi olekufaili. Ärge tehke seda kunagi käsitsi – kasutage selle asemel käsku terraform state. ID-de ümbernimetamisel tuleb kasutada käsku terraform state mv, millel on järgmine süntaks:

    terraform state mv

    ORIGINAL_REFERENCE on väljund, mis viitab ressurssile selle praeguses vormis, ja NEW_REFERENCE on koht, kuhu soovite selle liigutada. Näiteks aws_security_group grupi ümbernimetamiseks instance'ilt cluster_instance'ile tuleb käivitada järgmine käsk:

    $ terraform state mv 
       aws_security_group.instance 
       aws_security_group.cluster_instance

    Nii teavitada Terraform'i, et olek, mis varem kuulus aws_security_group.instance'ile, peab nüüd olema seotud aws_security_group.cluster_instance'iga. Kui pärast ümbernimetamist ja selle käsu `terraform plan` käivitamist ei näita mingeid muudatusi, siis olete kõik õigesti teinud.

  • Mõningaid parameetreid ei saa muuta. Paljude ressursside parameetrid on muutumatud. Kui proovite neid muuta, kustutab Terraform vana ressursi ja loob selle asemel uue. Iga ressursi lehelt on tavaliselt kirjas, mis juhtub, kui muudate mõnda parameetrit, seega ärge unustage dokumentatsiooniga tutvuda. Kasutage alati käsku `plan` ja kaalutage `create_before_destroy` strateegia rakendamise otstarbekust.

  Viivitatud kooskõla kooskõlastub... viivitamisega

  Mõnede pilveteenuste pakkujate, nagu AWS, API-d on asünkroonsed ja neil on viivitatud kooskõla. Asünkroonsus tähendab, et liidest saab kohe vastuse, ootamata nõutud tegevuse lõpuleviimist. Viivitatud kooskõla tähendab, et muudatuste levimiseks kogu süsteemis võib kuluda aega; kuni see toimub, võivad teie vastused olla kooskõlastamata ja sõltuda sellest, milline andmeallika koopia vastab teie API-päringutele.

  Kujutage ette, et teete näiteks API-päringu AWS-ile, paludes luua EC2 server. API tagastab "eduka" vastuse (201 Created) peaaegu kohe, ootamata serveri loomist. Kui proovite sellele kohe juurdepääsu saada, ei õnnestu see tõenäoliselt, kuna AWS on endiselt ressursse initsialiseerimas või server ei ole veel käivitatud. Veelgi enam, kui teete veel ühe päringu, et saada teavet selle serveri kohta, võib tulla viga (404 Not Found). Asi on selles, et teave selle EC2 serveri kohta võib endiselt AWS-is levida ning selle kättesaadavaks tegemiseks võib kuluda mitu sekundit.

  Iga kord, kui kasutate asünkroonset API-d viivitatud kooskõlaga, peate perioodiliselt oma päringut kordama, kuni tegevus on lõpule viidud ja levinud kogu süsteemis. Kahjuks ei paku AWS SDK selleks mingeid häid tööriistu ning Terraformi projekt on varem kannatanud palju selliste vigade all nagu 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

  Teisisõnu loote ressursi (nt alamvõrgu) ja proovite seejärel saada teavet sellest (nt just loodud alamvõrgu ID), kuid Terraform ei suuda neid leida. Enamik selliseid vigu (sealhulgas 6813) on juba parandatud, kuid need võivad aeg-ajalt ikka ilmneda, eriti siis, kui Terraform lisab toele uue ressursitüübi. See on tü annoying, kuid enamasti ei too see kaasa mingeid tõsiseid tagajärgi. Uue terraform apply käitamisel peaks kõik toimima, kuna sel hetkel on teave juba süsteemis hajutatud.

  See lõik on pärit Jevgeni Brikmani raamatust «Terraform: infrastruktuur koodi tasandil».

Allikas: habr.com