Terraform visvie triki

Terraform visvie triki
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, izlasiet Terraform izmaiņu žurnālu Å”eit.

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 (sÄ«kāka informācija — Å”eit).

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.brikman

    Terraform 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 mv

      ORIGINAL_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_instance

      Tā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āv

    Citiem 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 Ā«Terraform: infrastruktÅ«ra kā kodsĀ».

Avots: habr.com

Iegādājieties uzticamu tÄ«mekļa hostingu ar DDoS aizsardzÄ«bu, VPS VDS serveriem šŸ”„ Iegādājieties uzticamu tÄ«mekļa hostingu ar DDoS aizsardzÄ«bu, VPS VDS serveriem | ProHoster