Izcelsim dažus zemÅ«dens akmeÅus, tostarp tos, kas saistÄ«ti ar cikliem, if izteikumiem un izvietoÅ”anas metodÄm, kÄ arÄ« ar vispÄrÄ«gÄkÄm problÄmÄm, kas attiecas uz Terraform kopumÄ:
- count un for_each parametriem ir ierobežojumi;
- bezizsistÄÅ”anas izvietojumu ierobežojumi;
- pat labam plÄnam var nebÅ«t izdoÅ”anÄs;
- refaktoriÅÅ” var nest savus slÄptos pÄrsteigumus;
- atliekamÄ saskaÅotÄ«ba atbilst⦠atliekamÄ«bai.
Count un for_each parametriem ir ierobežojumi
Å Ä«s nodaļas piemÄros count parametru un for_each izteiksmi aktÄ«vi izmanto ciklos un nosacÄ«jumu loÄ£ikÄ. Tie darbojas labi, taÄu tiem ir divi svarÄ«gi ierobežojumi, par kuriem jÄzina.
- count un for_each nevar atsaukties uz nevienu resursa izejas mainīgo.
- count un for_each nevar izmantot moduļa konfigurÄcijÄ.
Count un for_each nevar atsaukties uz nevienu resursa izejas mainīgo
IedomÄjieties, ka nepiecieÅ”ams izvietot vairÄkus EC2 serverus un jums kÄdÄ iemesla dÄļ nevajag izmantot ASG. JÅ«su kods varÄtu izskatÄ«ties Å”Ädi:
resource "aws_instance" "example_1" {
count = 3
ami = "ami-0c55b159cbfafe1f0"
instance_type = "t2.micro"
}
Apskatīsim tos secīgi.
KÄ count parametrs ir pieŔķirts statisks vÄrtÄ«bas, Å”is kods darbosies bez problÄmÄm: kad jÅ«s izpildÄ«sit komandu apply, tas izveidos trÄ«s EC2 serverus. Bet, ja jÅ«s vÄlÄtos izvietot pa vienam serverim katrÄ pieejamÄ«bas zonÄ (Availability Zone vai AZ) esoÅ”ajÄ AWS reÄ£ionÄ? JÅ«s varat padarÄ«t tÄ, lai jÅ«su kods ielÄdÄtu zonu sarakstu no aws_availability_zones datu avota un pÄc tam "cikliskÄ" veidÄ izietu cauri katrai un izveidotu tajÄ EC2 serveri, izmantojot count parametru un piekļuvi masÄ«vam pÄc indeksa:
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" {}Å is kods arÄ« strÄdÄs lieliski, jo count parametrs var bez problÄmÄm atsaukties uz datu avotiem. Bet kas notiks, ja serveru skaits, kas jums jÄrada, ir atkarÄ«gs no kÄda resursa izejas? Lai to parÄdÄ«tu, visvieglÄk ir Åemt resursu random_integer, kas, kÄ var nojaust no nosaukuma, atgriež nejauÅ”u veselu skaitli:
resource "random_integer" "num_instances" {
min = 1
max = 3
}Å is kods Ä£enerÄ nejauÅ”u skaitli no 1 lÄ«dz 3. ApskatÄ«sim, kas notiks, ja mÄs mÄÄ£inÄsim izmantot resursa rezultÄta output atgriezenisko vÄrtÄ«bu parametrÄ count resursÄ aws_instance:
resource "aws_instance" "example_3" {
count = random_integer.num_instances.result
ami = "ami-0c55b159cbfafe1f0"
instance_type = "t2.micro"
}Ja izpildīsiet Ŕo kodu ar komandu terraform plan, iegūsiet sekojoŔo kļūdu:
Kļūda: nederīgs count arguments
failÄ main.tf rindÄ 30, resursÄ "aws_instance" "example_3":
30: count = random_integer.num_instances.result
"count" vÄrtÄ«ba ir atkarÄ«ga no resursu atribÅ«tiem, kurus nevar noteikt lÄ«dz pielietoÅ”anai, tÄpÄc Terraform nevar prognozÄt, cik instance tiks izveidotas. Lai to apietu, izmantojiet -target argumentu, lai vispirms pielietotu tikai resursus, no kuriem count ir atkarÄ«gs.Terraform prasa, lai count un for_each tiktu aprÄÄ·inÄti plÄnoÅ”anas posmÄ, pirms tiek izveidoti vai mainÄ«ti jebkuri resursi. Tas nozÄ«mÄ, ka count un for_each var atsaukties uz literÄliem, mainÄ«gajiem, datu avotiem un pat resursu sarakstiem (ja to garumu var noteikt plÄnoÅ”anas laikÄ), bet ne uz aprÄÄ·inÄtÄm resursu izvades mainÄ«gajÄm vÄrtÄ«bÄm.
count un for_each nevar izmantot moduļa konfigurÄcijÄ
VisticamÄk, kÄdu dienu jums bÅ«s kÄrdinÄjums pievienot count parametru moduļa konfigurÄcijai:
module "count_example" {
source = "..\/..\/..\/..\/modules\/services\/webserver-cluster"
count = 3
cluster_name = "terraform-up-and-running-example"
server_port = 8080
instance_type = "t2.micro"
}Å is kods mÄÄ£ina izmantot count moduļa iekÅ”ienÄ, lai izveidotu trÄ«s kopijas resursam webserver-cluster. Vai varbÅ«t jÅ«s vÄlÄtos padarÄ«t moduļa piesaisti opciju atkarÄ«bÄ no kÄda loÄ£iskÄ nosacÄ«juma, pieŔķirot tÄ parametram count vÄrtÄ«bu 0. Å Äds kods izskatÄs diezgan saprÄtÄ«gi, tomÄr, izpildot terraform plan, jÅ«s saÅemsiet Å”Ädu kļūdu:
Kļūda: rezervÄts argumenta nosaukums moduļa blokÄ
failÄ main.tf rindÄ 13, modulÄ« "count_example":
13: count = 3
Nosaukums "count" ir rezervÄts turpmÄkajai Terraform versijai.DiemžÄl, kad tika laists klajÄ Terraform 0.12.6, count vai for_each izmantoÅ”ana moduļa resursÄ netika atbalstÄ«ta. SaskaÅÄ ar Terraform 0.12 izlaiduma piezÄ«mÄm (http:\/\/bit.ly\/3257bv4) uzÅÄmums HashiCorp plÄno pievienot Å”o iespÄju nÄkotnÄ, tÄpÄc, atkarÄ«bÄ no tÄ, kad lasÄt Å”o grÄmatu, tÄ jau var bÅ«t pieejama. Lai uzzinÄtu noteikti, .
Ierobežojumi izvietojumiem ar nulles dÄ«kstÄves laiku
IzmantoÅ”ana ar create_before_destroy bloku kopÄ ar ASG ir lielisks risinÄjums nevainojamu ievieÅ”anu nodroÅ”inÄÅ”anai, izÅemot vienu niansi: automÄtiskÄs skalÄÅ”anas noteikumi Å”ajÄ gadÄ«jumÄ netiek atbalstÄ«ti. PrecÄ«zÄk sakot, tas katru reizi ievieÅ”ot atjauno ASG izmÄru uz min_size, kas var radÄ«t problÄmas, ja esat izmantojis automÄtiskÄs skalÄÅ”anas noteikumus serveru skaita palielinÄÅ”anai.
PiemÄram, webserver-cluster modulis satur pÄris resursu aws_autoscaling_schedule, kas 9:00 palielina serveru skaitu klasterÄ« no diviem lÄ«dz desmit. Ja ievieÅ”at Å”os mainÄ«jumus, pieÅemsim, 11:00, jaunÄ ASG grupa netiks palaista ar desmit, bet tikai ar diviem serveriem un paliks Å”ajÄ stÄvoklÄ« lÄ«dz nÄkamÄs dienas 9:00.
Å o ierobežojumu var apiet vairÄkiem veidiem.
- MainÄ«t aws_autoscaling_schedule parametra recurrence no 0 9 * * * ("palaist 9:00") uz kaut ko lÄ«dzÄ«gu 0-59 9-17 * * * ("palaist katru minÅ«ti no 9:00 lÄ«dz 17:00"). Ja ASG jau ir desmit serveri, atkÄrtota Ŕī automÄtiskÄs skalÄÅ”anas noteikuma izpilde neko nemainÄ«s, kas mums ir nepiecieÅ”ams. Bet, ja ASG grupa ir nesen ieviesta, Å”is noteikums nodroÅ”inÄs, ka maksimÄli pÄc minÅ«tes tÄs serveru skaits sasniegs desmit. Tas nav gluži elegants risinÄjums, un lielas pÄrmaiÅas no desmit lÄ«dz diviem serveriem un atpakaļ var radÄ«t problÄmas lietotÄjiem.
- Izveidotu pielÄgotu skriptu, kas izmanto AWS API, lai noteiktu aktÄ«vo serveru skaitu ASG, un izsauktu to, izmantojot ÄrÄju datu avotu (skat. punktu āÄrÄjais datu avotsā lappusÄ 249), un pieŔķirtu ASG grupas desired_capacity parametram vÄrtÄ«bu, ko atgriež Å”is skripts. TÄdÄjÄdi katrs jaunais ASG instances vienmÄr sÄksies ar to paÅ”u jaudu kÄ iepriekÅ”ÄjÄ Terraform kods un sarežģīs tÄ apkalpoÅ”anu.
Protams, ideÄlÄ gadÄ«jumÄ Terraform bÅ«tu jÄatbalsta nevainojamu ievieÅ”anu atbalsts, bet 2019. gada maijÄ HashiCorp komanda neplÄnoja Ŕīs funkcionalitÄtes pievienoÅ”anu ().
Pareizs plÄns var tikt neveiksmÄ«gi Ä«stenots
Dažreiz, izpildot komandu plan, tiek iegÅ«ts pilnÄ«gi korekts izvietoÅ”anas plÄns, taÄu komanda apply atgriež kļūdu. PiemÄram, mÄÄ£iniet pievienot resursu aws_iam_user ar to paÅ”u vÄrdu, ko izmantojÄt IAM lietotÄjam, ko izveidojÄt iepriekÅ” 2. nodaļÄ:
resource "aws_iam_user" "existing_user" {
# Ievadiet Å”eit esoÅ”a IAM lietotÄja vÄrdu,
# lai praktizÄtos komandas terraform import izmantoÅ”anÄ
name = "yevgeniy.brikman"
}Tagad, ja izpildÄ«siet komandu plan, Terraform izvadÄ«s pirmajÄ acu uzmetienÄ pilnÄ«gi saprÄtÄ«gu izvietoÅ”anas plÄnu:
Terraform veiks Å”Ädas darbÄ«bas:
# aws_iam_user.existing_user tiks izveidots
+ resource "aws_iam_user" "existing_user" {
+ arn = (zinÄms pÄc apply)
+ force_destroy = false
+ id = (zinÄms pÄc apply)
+ name = "yevgeniy.brikman"
+ path = "\/"
+ unique_id = (zinÄms pÄc apply)
}
PlÄns: 1 pievienot, 0 mainÄ«t, 0 iznÄ«cinÄt.Ja izpildÄ«siet komandu apply, tiks saÅemta Å”Äda kļūda:
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" {ProblÄma, protams, ir tÄ, ka IAM lietotÄjs ar Å”Ädu vÄrdu jau pastÄv. Un tas var notikt ne tikai ar IAM lietotÄjiem, bet arÄ« ar gandrÄ«z jebkuru resursu. IespÄjams, kÄds Å”o resursu izveidojis manuÄli vai izmantojot komandrindas rÄ«ku, bet, kÄ lai arÄ« tas bÅ«tu, identifikatoru sakritÄ«ba noved pie konfliktiem. Å ai kļūdai ir daudz variÄciju, kas bieži pÄrsteidz iesÄcÄjus Terraform.
Galvenais ir tas, ka komanda terraform plan Åem vÄrÄ tikai tos resursus, kas norÄdÄ«ti Terraform stÄvokļa failÄ. Ja resursi ir izveidoti kÄdÄ citÄ veidÄ (piemÄram, manuÄli, noklikŔķinot uz pogas AWS konsolÄ), tie netiks iekļauti stÄvokļa failÄ un, tÄdÄjÄdi, Terraform tos neÅem vÄrÄ, izpildot komandu plan. RezultÄtÄ, Ŕķietami korekts plÄns izrÄdÄ«sies neizdevÄ«gs.
No tÄ var izdarÄ«t divus secinÄjumus.
- Ja jau sÄkat strÄdÄt ar Terraform, nelietojiet neko citu. Ja daļa no jÅ«su infrastruktÅ«ras tiek pÄrvaldÄ«ta, izmantojot Terraform, vairs nedrÄ«kst to mainÄ«t manuÄli. PretÄjÄ gadÄ«jumÄ jÅ«s ne tikai riskÄjat iegÅ«t dÄ«vainas Terraform kļūdas, bet arÄ« iznÄ«cinÄt daudzus IaC ieguvumus, jo kods vairs nebÅ«s precÄ«zs jÅ«su infrastruktÅ«ras atspoguļojums.
- Ja jums jau ir kÄda infrastruktÅ«ra, izmantojiet komandu import. Ja jÅ«s sÄkat izmantot Terraform ar jau esoÅ”u infrastruktÅ«ru, to var pievienot stÄvokļa failam, izmantojot komandu terraform import. Tad Terraform zinÄs, ar kuru infrastruktÅ«ru ir jÄstrÄdÄ. Komanda import pieÅem divus argumentus. Pirmais ir resursa adrese jÅ«su konfigurÄcijas failos. Å eit ir tÄds pats sintaksis kÄ resursu atsaucÄs: _. (piemÄram, aws_iam_user.existing_user). Otrais arguments ir resursa identifikators, kuru nepiecieÅ”ams importÄt. PiemÄram, aws_iam_user resursa ID ir lietotÄjvÄrds (piemÄram, yevgeniy.brikman), bet aws_instance resursa ID bÅ«s EC2 servera identifikators (piemÄram, i-190e22e5). Tas, kÄ importÄt resursu, parasti ir norÄdÄ«ts dokumentÄcijÄ tÄ lapas apakÅ”Ä.
ZemÄk ir norÄdÄ«ta import komanda, kas ļauj sinhronizÄt aws_iam_user resursu, ko jÅ«s pievienojÄt savai Terraform konfigurÄcijai kopÄ ar IAM lietotÄju 2. nodaÄ¼Ä (protams, vietÄ yevgeniy.brikman jÄievieto jÅ«su vÄrds):
$ terraform import aws_iam_user.existing_user yevgeniy.brikmanTerraform sazinÄs ar AWS API, lai atrastu jÅ«su IAM lietotÄju un izveidotu stÄvokļa failÄ savienojumu starp to un resursu aws_iam_user.existing_user jÅ«su Terraform konfigurÄcijÄ. No Ŕī brīža, izpildot plÄna komandu, Terraform zinÄs, ka IAM lietotÄjs jau eksistÄ un necentÄ«sies to izveidot vÄlreiz.
JÄatzÄ«mÄ, ka, ja jums jau ir daudz resursu, kurus vÄlaties importÄt Terraform, manuÄla koda rakstīŔana un katra no tiem importÄÅ”ana pa vienam var izrÄdÄ«ties sarežģīta nodarbe. TÄpÄc vÄrts pievÄrst uzmanÄ«bu tÄdÄm rÄ«kam kÄ Terraforming (http://terraforming.dtan4.net/), kas var automÄtiski importÄt kodu un stÄvokli no AWS konta.
Refaktoringam var bÅ«t savi slÄpti ŔķÄrŔļi
Refaktoring ā izplatÄ«ta prakse programmÄÅ”anÄ, kad jÅ«s mainÄt koda iekÅ”Äjo struktÅ«ru, atstÄjot ÄrÄjo uzvedÄ«bu nemainÄ«gu. Tas ir nepiecieÅ”ams, lai padarÄ«tu kodu skaidrÄku, sakoptÄku un vieglÄk apkalpojamu. Refaktoring ir neatÅemama metode, kuru jÄpiemÄro regulÄri. Bet, runÄjot par Terraform vai jebkuru citu IaC rÄ«ku, ir ÄrkÄrtÄ«gi uzmanÄ«gi jÄizturas pret to, ko saprot ar "ÄrÄjo uzvedÄ«bu" koda fragmentÄ, citÄdi var rasties neparedzÄtas problÄmas.
PiemÄram, viena no izplatÄ«tÄkajÄm refaktorÄÅ”anas metodÄm ir mainÄ«t mainÄ«go vai funkciju nosaukumus uz saprotamÄkiem. DaudzÄm IDE ir iebÅ«vÄta atbalsta funkcija refaktorÄÅ”anai, kas var automÄtiski pÄrdÄvÄt mainÄ«gos un funkcijas visÄ projektÄ. VispÄrÄjas lietoÅ”anas programmÄÅ”anas valodÄs tas ir trivials process, par kuru var neuztraukties, taÄu Terraform gadÄ«jumÄ jÄbÅ«t ļoti uzmanÄ«giem, citÄdi var rasties darbÄ«bas traucÄjumi.
PiemÄram, modulis webserver-cluster satur ieejas mainÄ«go cluster_name:
variable "cluster_name" { description = "VÄrds, ko izmantot visÄm klastera resursiem" type = string }IedomÄjieties, ka jÅ«s sÄkat izmantot Å”o moduli, lai izvietotu mikservices ar nosaukumu foo. VÄlÄk jums radÄs vÄlme pÄrdÄvÄt savu pakalpojumu par bar. Å Ä« izmaiÅa var Ŕķist triviala, taÄu realitÄtÄ tÄ var izraisÄ«t darbÄ«bas traucÄjumus.
ProblÄma ir tÄda, ka modulis webserver-cluster izmanto mainÄ«go cluster_name daudzos resursos, tostarp divu droŔības grupu un ALB nosaukuma parametrÄ:
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] }Ja tiek mainÄ«ts nosaukuma parametrs kÄdÄ no resursiem, Terraform izdzÄsÄ«s esoÅ”o Ŕī resursa versiju un izveidos jaunu. TaÄu, ja Å”Äds resurss ir ALB, tad periodÄ starp tÄ izdzÄÅ”anu un jaunÄs versijas ielÄdi jums nebÅ«s mehÄnisma, kÄ novirzÄ«t trafiku uz jÅ«su tÄ«mekļa serveri. TieÅ”i tÄpat, ja tiek izdzÄsta droŔības grupa, jÅ«su serveri sÄks noraidÄ«t jebkuru tÄ«kla trafiku, lÄ«dz tiks izveidota jauna grupa.
VÄl viena refaktorÄÅ”anas metode, kas jÅ«s varÄtu interesÄt, ir Terraform identifikatora maiÅa. Å emsim piemÄru ar resursu aws_security_group modulÄ« webserver-cluster:
resource "aws_security_group" "instance" { # (...) }Å Ä« resursa identifikators tiek saukts par instance. IedomÄjieties, ka refaktorÄÅ”anas procesa laikÄ jÅ«s nolemjat mainÄ«t to uz saprotamÄku (jÅ«suprÄt) nosaukumu cluster_instance:
resource "aws_security_group" "cluster_instance" { # (...) }Kas notiks pÄc tam? Pareizi: darbÄ«bas traucÄjumi.
Terraform saista katra resursa ID ar mÄkoÅa pakalpojumu sniedzÄja identifikatoru. PiemÄram, iam_user tiek piesaistÄ«ts IAM lietotÄja ID AWS, bet aws_instance ā AWS EC2 servera ID. Ja mainÄt resursa identifikatoru (piemÄram, no instance uz cluster_instance, kÄ tas ir aws_security_group gadÄ«jumÄ), Terraform to uztvers tÄ, it kÄ jÅ«s bÅ«tu izdzÄsis veco resursus un pievienojis jaunu. Ja Ŕīs izmaiÅas tiek piemÄrotas, Terraform izdzÄsÄ«s veco droŔības grupu un izveidos citu, savukÄrt jÅ«su serveri sÄkums noraidÄ«t jebkuru tÄ«kla trafiku.
Å eit ir Äetri galvenie mÄcÄ«bu punkti, ko jÅ«s vajadzÄtu iegÅ«t no Ŕīs diskusijas.
- VienmÄr izmantojiet plan komandu. TÄs palÄ«dzÄ«ba var atklÄt visas Ŕīs problÄmas. RÅ«pÄ«gi pÄrskatiet tÄs rezultÄtus un pievÄrsiet uzmanÄ«bu situÄcijÄm, kad Terraform plÄno izdzÄst resursus, kuri, visticamÄk, nebÅ«tu jÄiznÄ«cina.
- Izveidojiet, pirms izdzÄÅ”at. Ja vÄlaties nomainÄ«t resursu, rÅ«pÄ«gi padomÄjiet, vai nepiecieÅ”ams izveidot aizvietojumu pirms oriÄ£inÄla izdzÄÅ”anas. Ja atbilde ir pozitÄ«va, Å”ajÄ var palÄ«dzÄt create_before_destroy. To paÅ”u rezultÄtu var sasniegt manuÄli, veicot divus soļus: vispirms pievienojiet konfigurÄcijai jauno resursu un palaidiet apply komandu, pÄc tam izdzÄsiet konfigurÄcijÄ veco resursu un vÄlreiz izmantojiet apply komandu.
- Identifikatoru maiÅa prasa stÄvokļa izmaiÅas. Ja vÄlaties mainÄ«t identifikatoru, kas saistÄ«ts ar resursu (piemÄram, pÄrdÄvÄjot aws_security_group no instance uz cluster_instance), izvairoties no resursa dzÄÅ”anas un jauna izveides, jums ir nepiecieÅ”ams atbilstoÅ”i atjauninÄt Terraform stÄvokļa failu. Nekad to nedariet manuÄli ā izmantojiet Å”im mÄrÄ·im terraform state komandu. Veicot identifikatoru pÄrdÄvÄÅ”anu, jÄizpilda terraform state mv komanda ar sekojoÅ”u sintaksi:
terraform state mvORIGINAL_REFERENCE ir izteiksme, kas atsaucas uz resursu tÄ paÅ”reizÄjÄ formÄ, bet NEW_REFERENCE ā vieta, uz kuru vÄlaties to pÄrvietot. PiemÄram, pÄrdÄvÄjot aws_security_group grupu no instance uz cluster_instance, jÄveic Å”Äda komanda:
$ terraform state mv aws_security_group.instance aws_security_group.cluster_instanceTÄdÄjÄdi jÅ«s informÄsiet Terraform, ka stÄvoklis, kas iepriekÅ” attiecÄs uz aws_security_group.instance, tagad jÄsaista ar aws_security_group.cluster_instance. Ja pÄc pÄrdÄvÄÅ”anas un Ŕīs komandas terraform plan palaiÅ”anas netiks rÄdÄ«tas nekÄdas izmaiÅas, tas nozÄ«mÄ, ka viss ir izdarÄ«ts pareizi.
- Dažus parametrus nav iespÄjams mainÄ«t. Daudzi resursu parametri ir nemainÄ«gi. Ja mÄÄ£inÄsiet tos mainÄ«t, Terraform izdzÄsÄ«s veco resursu un izveidos jaunu. Parasti katra resursa lapÄ tiek norÄdÄ«ts, kas notiek, mainot Å”o vai citu parametru, tÄpÄc neaizmirstiet salÄ«dzinÄt ar dokumentÄciju. VienmÄr izmantojiet komandu plan un izvÄrtÄjiet izveidot pirms iznÄ«cinÄÅ”anas stratÄÄ£iju.
AtliktÄ konsekvence saskaÅojas⦠ar atlikÅ”anu
Dažu mÄkoÅu pakalpojumu sniedzÄju, piemÄram, AWS, API ir asinkroni un tiem ir atliktÄ konsekvence. AsinkronitÄte nozÄ«mÄ, ka saskarne var nekavÄjoties atgriezt atbildi, negaidot pieprasÄ«tÄ darbÄ«ba. AtliktÄ konsekvence nozÄ«mÄ, ka izmaiÅu izplatīŔanai visÄ sistÄmÄ var bÅ«t nepiecieÅ”ams laiks; kamÄr tas notiek, jÅ«su atbildes var bÅ«t nesaskaÅotas un atkarÄ«gas no tÄ, kurÅ” datu avota replikats atbild uz jÅ«su API pieprasÄ«jumiem.
IedomÄjieties, piemÄram, ka veicat API pieprasÄ«jumu uz AWS, lÅ«dzot izveidot EC2 serveri. API gandrÄ«z nekavÄjoties atgriezÄ«s āveiksmÄ«guā atbildi (201 Created), negaidot paÅ”a servera izveidi. Ja jÅ«s uzreiz mÄÄ£inÄsiet tam pievienoties, droÅ”i vien nekas nesanÄks, jo Å”ajÄ brÄ«dÄ« AWS vÄl joprojÄm inicializÄ resursus vai arÄ« servers vÄl nav lejupielÄdÄjies. TurklÄt, ja jÅ«s veiksiet vÄl vienu pieprasÄ«jumu, lai iegÅ«tu informÄciju par Å”o serveri, var tikt saÅemta kļūda (404 Not Found). ProblÄma ir tÄda, ka informÄcija par Å”o EC2 serveri vÄl var izplatÄ«ties visÄ AWS, lai tÄs kļūtu pieejamas visur, nepiecieÅ”ams pagaidÄ«t dažas sekundes.
Ikreiz, kad izmantojat asinkrono API ar atlikto konsekvenci, jums periodiski jÄatkÄrto sava pieprasÄ«juma, lÄ«dz darbÄ«ba ir pabeigta un izplatÄ«ta visÄ sistÄmÄ. DiemžÄl AWS SDK Å”im nolÅ«kam nenodroÅ”ina labus rÄ«kus, un Terraform projekts iepriekÅ” cieÅ” no daudzÄm kļūdÄm, piemÄram, 6813 (https://github.com/hashicorp/terraform/issues/6813):
$ terraform apply aws_subnet.private-persistence.2: InvalidSubnetID.NotFound: Subnet ID 'subnet-xxxxxxx' nepastÄvCitiem vÄrdiem sakot, jÅ«s izveidojat resursu (piemÄram, apakÅ”netu), un tad mÄÄ£inÄt iegÅ«t informÄciju par to (piemÄram, nesen izveidotÄ apakÅ”neta ID), bet Terraform to nevar atrast. LielÄko daļu Å”Ädu kļūdu (ieskaitot 6813) jau ir izlaboti, taÄu laiku pa laikam tÄs joprojÄm parÄdÄs, it Ä«paÅ”i, kad Terraform pievieno atbalstu jaunu resursu tipiem. Tas ir kaitinoÅ”i, bet lielÄkajÄ daÄ¼Ä gadÄ«jumu tas nerada nekÄdas sekas. AtkÄrtoti izpildot terraform apply, viss vajadzÄtu nostrÄdÄt, jo lÄ«dz tam laikam informÄcija jau bÅ«s izplatÄ«jusies pa sistÄmu.
Å is fragments ir Åemts no JevgÄnija BrikmaÅa grÄmatas .
Avots: habr.com
