ProHoster > Blogs > Administrācija > Terraformas kļūmes

Terraformas kļūmes

Terraformas kļūmes
Izcelsim dažas nepilnÄ«bas, tostarp tās, kas saistÄ«tas ar cilpām, if paziņojumiem un izvietoÅ”anas metodēm, kā arÄ« vispārÄ«gākas problēmas, kas ietekmē Terraform kopumā:

  • parametriem skaits un for_each ir ierobežojumi;
  • ierobežot nulles dÄ«kstāves izvietoÅ”anu;
  • pat labs plāns var neizdoties;
  • pārstrukturÄ“Å”anai var bÅ«t savas nepilnÄ«bas;
  • atliktā saskaņotÄ«ba atbilst... ar atlikÅ”anu.

Skaits un for_each parametriem ir ierobežojumi

Å Ä«s nodaļas piemēros plaÅ”i tiek izmantots skaitÄ«Å”anas parametrs un izteiksme for_each cilpās un nosacÄ«juma loÄ£ikā. Tie darbojas labi, taču tiem ir divi svarÄ«gi ierobežojumi, kas jums jāzina.

  • Skaits un for_each nevar atsaukties uz resursa izvades mainÄ«gajiem.
  • count un for_each nevar izmantot moduļa konfigurācijā.

count un for_each nevar atsaukties uz resursa izvades mainīgajiem

Iedomājieties, ka jums ir jāizvieto vairāki EC2 serveri un kādu iemeslu dēļ jÅ«s nevēlaties izmantot ASG. JÅ«su kods varētu bÅ«t Ŕāds:

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

Apskatīsim tos pa vienam.

Tā kā skaitÄ«Å”anas parametrs ir iestatÄ«ts uz statisku vērtÄ«bu, Å”is kods darbosies bez problēmām: palaižot komandu lietot, tas izveidos trÄ«s EC2 serverus. Bet ko darÄ«t, ja vēlaties izvietot vienu serveri katrā pieejamÄ«bas zonā (AZ) paÅ”reizējā AWS reÄ£ionā? Varat likt savam kodam ielādēt zonu sarakstu no datu avota aws_availability_zones un pēc tam veikt katru no tām un izveidot tajā EC2 serveri, izmantojot skaitÄ«Å”anas parametru un masÄ«va indeksa piekļuvi:

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Ä« darbosies labi, jo skaitÄ«Å”anas parametrs bez problēmām var atsaukties uz datu avotiem. Bet kas notiek, ja izveidojamo serveru skaits ir atkarÄ«gs no kāda resursa izvades? Lai to parādÄ«tu, vienkārŔākais veids ir izmantot resursu random_integer, kas, kā norāda nosaukums, 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. Redzēsim, kas notiks, ja mēģināsim izmantot Ŕī resursa izvadi aws_instance resursa skaitÄ«Å”anas parametrā:

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

Ja palaižat terraform plānu ar Ŕo kodu, tiks parādīta Ŕāda kļūda:

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.

Terraform pieprasa, lai plānoÅ”anas fāzē, pirms tiek izveidoti vai pārveidoti resursi, jāaprēķina skaits un katram. Tas nozÄ«mē, ka count un for_each var attiekties uz literāļiem, mainÄ«gajiem, datu avotiem un pat resursu sarakstiem (ja vien to garumu var noteikt plānoÅ”anas laikā), bet ne uz aprēķinātajiem resursu izvades mainÄ«gajiem.

count un for_each nevar izmantot moduļa konfigurācijā

Kādu dienu jums varētu rasties kārdinājums moduļa konfigurācijai pievienot skaitÄ«Å”anas parametru:

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 modulÄ« esoÅ”o skaitu, lai izveidotu trÄ«s tÄ«mekļa servera klastera resursa kopijas. Varat arÄ« iestatÄ«t moduļa pievienoÅ”anu neobligātu atkarÄ«bā no dažiem BÅ«la nosacÄ«jumiem, iestatot tā skaitÄ«Å”anas parametru uz 0. Tas varētu izskatÄ«ties kā saprātÄ«gs kods, taču, izpildot terraformas plānu, tiks parādÄ«ta Ŕī kļūda:

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.

Diemžēl no Terraform 0.12.6 moduļa resursā netiek atbalstÄ«ta count vai for_each izmantoÅ”ana. Saskaņā ar Terraform 0.12 izlaiÅ”anas piezÄ«mēm (http://bit.ly/3257bv4), HashiCorp plāno pievienot Å”o iespēju nākotnē, tāpēc atkarÄ«bā no Ŕīs grāmatas lasÄ«Å”anas brīža tā jau var bÅ«t pieejama. Lai to noteikti uzzinātu, lasiet Terraform izmaiņu žurnālu Å”eit.

Nulles dīkstāves izvietoŔanas ierobežojumi

Bloka create_before_destroy izmantoÅ”ana kopā ar ASG ir lielisks risinājums, lai izveidotu nulles dÄ«kstāves izvietojumus, izņemot vienu brÄ«dinājumu: automātiskās mērogoÅ”anas noteikumi netiek atbalstÄ«ti. PrecÄ«zāk sakot, tas atiestata ASG izmēru atpakaļ uz min_size katrā izvietoÅ”anas reizē, kas varētu bÅ«t problēma, ja izmantojat automātiskās mērogoÅ”anas noteikumus, lai palielinātu strādājoÅ”o serveru skaitu.

Piemēram, tīmekļa servera klastera modulis satur aws_autoscaling_schedule resursu pāri, kas pulksten 9 palielina klastera serveru skaitu no diviem līdz desmit. Ja izvietosit, piemēram, pulksten 11:9, jaunais ASG tiks palaists tikai ar diviem serveriem, nevis desmit, un paliks tāds līdz nākamās dienas pulksten XNUMX:XNUMX.

Šo ierobežojumu var apiet vairākos veidos.

  • Mainiet atkārtoÅ”anās parametru aws_autoscaling_schedule no 0 9 * * * (ā€œpalaist plkst. 9:0ā€) uz 59-9 17-9 * * * (ā€œpalaist katru minÅ«ti no 5:XNUMX lÄ«dz XNUMX:XNUMXā€). Ja ASG jau ir desmit serveri, Ŕī automātiskās mērogoÅ”anas kārtula atkārtota izpilde neko nemainÄ«s, un tas ir tas, ko mēs vēlamies. Bet, ja ASG ir tikai nesen izvietots, Å”is noteikums nodroÅ”inās, ka maksimāli minÅ«tes laikā tā serveru skaits sasniegs desmit. Tā nav gluži eleganta pieeja, un arÄ« lieli lēcieni no desmit uz diviem serveriem un atpakaļ var radÄ«t problēmas lietotājiem.
  • Izveidojiet pielāgotu skriptu, kas izmanto AWS API, lai noteiktu ASG aktÄ«vo serveru skaitu, izsauciet to, izmantojot ārēju datu avotu (sk. "Ārējais datu avots" 249. lpp.), un iestatiet ASG parametru wish_capacity uz vērtÄ«bu, ko atgriež scenārijs. Tādā veidā katra jauna ASG instance vienmēr darbosies ar tādu paÅ”u jaudu kā esoÅ”ajam Terraform kodam un apgrÅ«tina tā uzturÄ“Å”anu.

Protams, ideālā gadÄ«jumā Terraform bÅ«tu iebÅ«vēts atbalsts izvietoÅ”anai bez dÄ«kstāves, taču 2019. gada maijā HashiCorp komanda neplānoja pievienot Å”o funkcionalitāti (sÄ«kāka informācija - Å”eit).

Pareizais plāns var tikt nesekmīgi īstenots

Dažreiz plāna komanda izveido pilnÄ«gi pareizu izvietoÅ”anas plānu, bet komanda App atgriež kļūdu. Mēģiniet, piemēram, pievienot aws_iam_user resursu ar tādu paÅ”u nosaukumu, ko izmantojāt IAM lietotājam, kuru izveidojāt iepriekÅ” 2. nodaļā:

resource "aws_iam_user" "existing_user" {
   # ŠŸŠ¾Š“стŠ°Š²ŃŒŃ‚Šµ сюŠ“Š° ŠøŠ¼Ń уŠ¶Šµ сущŠµŃŃ‚Š²ŃƒŃŽŃ‰ŠµŠ³Š¾ ŠæŠ¾Š»ŃŒŠ·Š¾Š²Š°Ń‚ŠµŠ»Ń IAM,
   # чтŠ¾Š±Ń‹ ŠæŠ¾ŠæрŠ°ŠŗтŠøŠŗŠ¾Š²Š°Ń‚ŃŒŃŃ Š² ŠøсŠæŠ¾Š»ŃŒŠ·Š¾Š²Š°Š½ŠøŠø ŠŗŠ¾Š¼Š°Š½Š“ы terraform import
   name = "yevgeniy.brikman"
}

Tagad, ja palaižat plānu komandu, Terraform izvadīs Ŕķietami saprātīgu izvietoŔanas plānu:

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.

Ja palaižat komandu lietot, tiks parādÄ«ts Ŕāds kļūdas ziņojums:

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 IAM lietotājiem, bet gandrÄ«z jebkuram resursam. Iespējams, kāds Å”o resursu ir izveidojis manuāli vai izmantojot komandrindu, taču jebkurā gadÄ«jumā ID atbilstÄ«bas rezultātā rodas konflikti. Å ai kļūdai ir daudz variāciju, kas bieži vien pārsteidz Terraform jaunpienācējus.

Galvenais ir tas, ka komanda terraform plan ņem vērā tikai tos resursus, kas norādÄ«ti Terraform stāvokļa failā. Ja resursi tiek izveidoti kādā citā veidā (piemēram, manuāli, noklikŔķinot AWS konsolē), tie nenonāks stāvokļa failā un tāpēc Terraform tos neņems vērā, izpildot plan komandu. Rezultātā plāns, kas pirmajā mirklÄ« Ŕķiet pareizs, izrādÄ«sies neveiksmÄ«gs.

No tā ir jāmācās divas mācības.

  • Ja jau esat sācis strādāt ar Terraform, nelietojiet neko citu. Ja daļa no jÅ«su infrastruktÅ«ras tiek pārvaldÄ«ta, izmantojot Terraform, jÅ«s vairs nevarat to manuāli modificēt. Pretējā gadÄ«jumā jÅ«s ne tikai riskējat ar dÄ«vainām Terraform kļūdām, bet arÄ« noliedzat daudzas IaC priekÅ”rocÄ«bas, jo kods vairs nebÅ«s precÄ«zs jÅ«su infrastruktÅ«ras attēlojums.
  • Ja jums jau ir kāda infrastruktÅ«ra, izmantojiet importÄ“Å”anas komandu. Ja sākat lietot Terraform ar esoÅ”o infrastruktÅ«ru, varat to pievienot stāvokļa failam, izmantojot terraform importÄ“Å”anas komandu. Tādā veidā Terraform zinās, kāda infrastruktÅ«ra ir jāpārvalda. ImportÄ“Å”anas komandai ir divi argumenti. Pirmā ir resursa adrese jÅ«su konfigurācijas failos. Sintakse Å”eit ir tāda pati kā resursu saitēm: _. (piemēram, aws_iam_user.existing_user). Otrais arguments ir importējamā resursa ID. Pieņemsim, ka resursa ID aws_iam_user ir lietotājvārds (piemēram, yevgeniy.brikman), bet resursa ID aws_instance ir EC2 servera ID (piemēram, i-190e22e5). Kā importēt resursu, parasti ir norādÄ«ts dokumentācijā tā lapas apakŔā.

    Zemāk ir importÄ“Å”anas komanda, kas sinhronizē aws_iam_user resursu, ko pievienojāt savai Terraform konfigurācijai kopā ar IAM lietotāju 2. nodaļā (protams, aizstājot savu vārdu ar yevgeniy.brikman):

    $ terraform import aws_iam_user.existing_user yevgeniy.brikman

    Terraform izsauks AWS API, lai atrastu jūsu IAM lietotāju un izveidotu stāvokļa faila saistību starp to un aws_iam_user.existing_user resursu jūsu Terraform konfigurācijā. Turpmāk, palaižot plānu komandu, Terraform zinās, ka IAM lietotājs jau pastāv, un nemēģinās to izveidot vēlreiz.

    Ir vērts atzÄ«mēt, ka, ja jums jau ir daudz resursu, ko vēlaties importēt programmā Terraform, manuāla koda rakstÄ«Å”ana un katra importÄ“Å”ana pa vienam var radÄ«t grÅ«tÄ«bas. Tāpēc ir vērts izpētÄ«t tādu rÄ«ku kā Terraforming (http://terraforming.dtan4.net/), kas var automātiski importēt kodu un stāvokli no jÅ«su AWS konta.

    PārveidoŔanai var būt savas nepilnības

    Refaktorings ir plaÅ”i izplatÄ«ta programmÄ“Å”anas prakse, kurā jÅ«s maināt koda iekŔējo struktÅ«ru, vienlaikus atstājot nemainÄ«gu ārējo uzvedÄ«bu. Tas ir paredzēts, lai padarÄ«tu kodu skaidrāku, glÄ«tāku un vieglāk uzturējamu. Refaktorings ir neaizstājams paņēmiens, kas jāizmanto regulāri. Bet, kad runa ir par Terraform vai jebkuru citu IaC rÄ«ku, jums ir jābÅ«t ļoti uzmanÄ«giem attiecÄ«bā uz to, ko jÅ«s domājat ar koda daļas ā€œÄrējo uzvedÄ«buā€, pretējā gadÄ«jumā radÄ«sies negaidÄ«tas problēmas.

    Piemēram, izplatÄ«ts pārstrukturÄ“Å”anas veids ir mainÄ«go vai funkciju nosaukumu aizstāŔana ar saprotamākiem. Daudzām IDE ir iebÅ«vēts pārstrukturÄ“Å”anas atbalsts, un tās var automātiski pārdēvēt mainÄ«gos un funkcijas visā projektā. Universālajās programmÄ“Å”anas valodās Ŕī ir triviāla procedÅ«ra, par kuru jÅ«s, iespējams, nedomājat, taču Terraform ar to ir jābÅ«t Ä«paÅ”i uzmanÄ«gam, pretējā gadÄ«jumā var rasties pārtraukumi.

    Piemēram, tīmekļa servera klastera modulim ir ievades mainīgais cluster_name:

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

    Iedomājieties, ka sākāt izmantot Å”o moduli, lai izvietotu mikropakalpojumu ar nosaukumu foo. Vēlāk vēlaties pārdēvēt pakalpojumu par bāru. Å Ä«s izmaiņas var Ŕķist triviālas, taču patiesÄ«bā tās var izraisÄ«t pakalpojuma traucējumus.

    Fakts ir tāds, ka tīmekļa servera klastera modulis izmanto mainīgo cluster_name vairākos resursos, tostarp divu droŔības grupu nosaukuma parametru un 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]
}

    Ja maināt resursa nosaukuma parametru, Terraform izdzēsÄ«s Ŕī resursa veco versiju un tā vietā izveidos jaunu. Bet, ja Å”is resurss ir ALB, no tā dzÄ“Å”anas lÄ«dz jaunas versijas lejupielādei jums nebÅ«s mehānisma, lai novirzÄ«tu trafiku uz jÅ«su tÄ«mekļa serveri. Tāpat, ja droŔības grupa tiek dzēsta, jÅ«su serveri sāks noraidÄ«t jebkādu tÄ«kla trafiku, lÄ«dz tiks izveidota jauna grupa.

    Vēl viens pārstrukturÄ“Å”anas veids, kas jÅ«s varētu interesēt, ir Terraform ID maiņa. Kā piemēru ņemsim aws_security_group resursu tÄ«mekļa servera klastera modulÄ«:

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

    Å Ä« resursa identifikatoru sauc par instance. Iedomājieties, ka pārstrukturÄ“Å”anas laikā jÅ«s nolēmāt to mainÄ«t uz saprotamāku (jÅ«suprāt) nosaukumu cluster_instance:

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

    Kas notiks beigās? TieÅ”i tā: traucējumi.

    Terraform saista katru resursa ID ar mākoņa nodroÅ”inātāja ID. Piemēram, iam_user ir saistÄ«ts ar AWS IAM lietotāja ID, un aws_instance ir saistÄ«ts ar AWS EC2 servera ID. Ja maināt resursa ID (piemēram, no instances uz cluster_instance, kā tas ir gadÄ«jumā ar aws_security_group), uz Terraform, tas parādÄ«sies tā, it kā bÅ«tu izdzēsts vecais resurss un pievienots jauns. Ja lietosit Ŕīs izmaiņas, Terraform izdzēsÄ«s veco droŔības grupu un izveidos jaunu, savukārt jÅ«su serveri sāks noraidÄ«t jebkādu tÄ«kla trafiku.

    Å eit ir četras galvenās atziņas, kuras jums vajadzētu ņemt no Ŕīs diskusijas.

    • Vienmēr izmantojiet plānu komandu. Tas var atklāt visas Ŕīs nepilnÄ«bas. RÅ«pÄ«gi pārskatiet tā rezultātus un pievērsiet uzmanÄ«bu situācijām, kad Terraform plāno dzēst resursus, kurus, visticamāk, nevajadzētu dzēst.
    • Izveidojiet pirms dzÄ“Å”anas. Ja vēlaties aizstāt resursu, pirms oriÄ£ināla dzÄ“Å”anas rÅ«pÄ«gi pārdomājiet, vai jums ir jāizveido aizstājējs. Ja atbilde ir apstiprinoÅ”a, var palÄ«dzēt Create_before_destroy. To paÅ”u rezultātu var sasniegt manuāli, veicot divas darbÄ«bas: vispirms pievienojiet konfigurācijai jaunu resursu un palaidiet komandu lietot, un pēc tam noņemiet veco resursu no konfigurācijas un vēlreiz izmantojiet lietotnes komandu.
    • Lai mainÄ«tu identifikatorus, ir jāmaina statuss. Ja vēlaties mainÄ«t ar resursu saistÄ«to ID (piemēram, pārdēvēt aws_security_group no instances uz cluster_instance), neizdzÄ“Å”ot resursu un neizveidojot jaunu tā versiju, ir attiecÄ«gi jāatjaunina Terraform stāvokļa fails. Nekad nedariet to manuāli ā€” tā vietā izmantojiet komandu terraform state. Pārdēvējot identifikatorus, palaidiet komandu terraform state mv, kurai ir Ŕāda sintakse: 
      terraform state mv <ORIGINAL_REFERENCE> <NEW_REFERENCE>

      ORIGINAL_REFERENCE ir izteiksme, kas attiecas uz resursu tā paÅ”reizējā formā, un NEW_REFERENCE ir vieta, kur vēlaties to pārvietot. Piemēram, pārdēvējot grupu aws_security_group no instances uz cluster_instance, ir jāizpilda Ŕāda komanda:

      $ terraform state mv 
   aws_security_group.instance 
   aws_security_group.cluster_instance

      Tas norāda Terraform, ka stāvoklis, kas iepriekÅ” bija saistÄ«ts ar aws_security_group.instance, tagad ir jāsaista ar aws_security_group.cluster_instance. Ja pēc Ŕīs komandas pārdēvÄ“Å”anas un palaiÅ”anas terraform plāns neuzrāda nekādas izmaiņas, tad jÅ«s visu izdarÄ«jāt pareizi.

    • Dažus iestatÄ«jumus nevar mainÄ«t. Daudzu resursu parametri ir nemaināmi. Ja mēģināsit tos mainÄ«t, Terraform izdzēsÄ«s veco resursu un tā vietā izveidos jaunu. Katrā resursa lapā parasti ir norādÄ«ts, kas notiek, mainot konkrētu iestatÄ«jumu, tāpēc noteikti pārbaudiet dokumentāciju. Vienmēr izmantojiet komandu plan un apsveriet iespēju izmantot stratēģiju create_before_destroy.

    Atliktā konsekvence atbilst... ar atlikŔanu

    Dažu mākoņpakalpojumu sniedzēju API, piemēram, AWS, ir asinhronas un tām ir aizkavēta konsekvence. Asinhronija nozÄ«mē, ka saskarne var nekavējoties atgriezt atbildi, negaidot pieprasÄ«tās darbÄ«bas pabeigÅ”anu. Aizkavēta konsekvence nozÄ«mē, ka var paiet laiks, lai izmaiņas izplatÄ«tos visā sistēmā; kamēr tas notiek, jÅ«su atbildes var bÅ«t nekonsekventas un atkarÄ«gas no tā, kura datu avota replika reaģē uz jÅ«su API izsaukumiem.

    Iedomājieties, piemēram, ka veicat API zvanu uz AWS, lÅ«dzot izveidot EC2 serveri. API gandrÄ«z uzreiz sniegs ā€œveiksmÄ«guā€ atbildi (izveidots 201), negaidot, kamēr tiks izveidots pats serveris. Ja mēģināsit izveidot savienojumu ar to uzreiz, tas gandrÄ«z noteikti neizdosies, jo tajā brÄ«dÄ« AWS joprojām inicializē resursus vai, alternatÄ«vi, serveris vēl nav palaists. Turklāt, ja veicat citu zvanu, lai iegÅ«tu informāciju par Å”o serveri, var tikt parādÄ«ts kļūdas ziņojums (404 Nav atrasts). Lieta tāda, ka informācija par Å”o EC2 serveri joprojām var tikt izplatÄ«ta visā AWS, pirms tā kļūst pieejama visur, jums bÅ«s jāgaida dažas sekundes.

    Ikreiz, kad izmantojat asinhronu API ar slinku konsekvenci, jums periodiski jāmēģina atkārtoti iesniegt pieprasÄ«jumu, lÄ«dz darbÄ«ba ir pabeigta un tiek izplatÄ«ta sistēmā. Diemžēl AWS SDK Å”im nolÅ«kam nesniedz nekādus labus rÄ«kus, un Terraform projekts agrāk cieta 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:
The subnet ID 'subnet-xxxxxxx' does not exist

    Citiem vārdiem sakot, jÅ«s izveidojat resursu (piemēram, apakÅ”tÄ«klu) un pēc tam mēģināt iegÅ«t informāciju par to (piemēram, jaunizveidotā apakÅ”tÄ«kla ID), un Terraform nevar to atrast. Lielākā daļa no Ŕīm kļūdām (tostarp 6813) ir novērstas, taču tās joprojām ik pa laikam parādās, it Ä«paÅ”i, ja Terraform pievieno atbalstu jaunam resursa veidam. Tas ir kaitinoÅ”i, bet vairumā gadÄ«jumu nerada nekādu kaitējumu. Atkārtoti palaižot terraform application, visam vajadzētu darboties, jo Å”ajā laikā informācija jau bÅ«s izplatÄ«jusies visā sistēmā.

    Šis fragments ir no Jevgeņija Brikmana grāmatas "Terraforma: infrastruktūra koda līmenī".

Avots: www.habr.com

Pievieno komentāru