Mga lit-ag sa Terraform

Atong i-highlight ang pipila ka mga lit-ag, lakip ang mga may kalabutan sa mga loop, kung ang mga pahayag ug mga pamaagi sa pag-deploy, ingon man usab sa mas kinatibuk-ang mga isyu nga makaapekto sa Terraform sa kinatibuk-an:

• ang ihap ug alang sa_matag mga parametro adunay mga limitasyon;
• limitahan ang zero downtime deployments;
• bisan ang usa ka maayong plano mahimong mapakyas;
• refactoring mahimong adunay iyang mga lit-ag;
• ang deferred coherence kay consistent... with deferral.

Ang ihap ug alang sa_matag mga parametro adunay mga limitasyon

Ang mga panig-ingnan niini nga kapitulo naghimo sa halapad nga paggamit sa count parameter ug ang for_each nga ekspresyon sa mga loop ug conditional logic. Maayo ang ilang performance, apan aduna silay duha ka importanteng limitasyon nga kinahanglan nimong masayran.

• Ang Count ug for_each dili maka-refer sa bisan unsang resource output variables.
• count ug for_each dili magamit sa module configuration.

count ug for_each dili maka-refer sa bisan unsang resource output variables

Hunahunaa nga kinahanglan nimo nga i-deploy ang daghang mga EC2 server ug sa pipila ka hinungdan dili nimo gusto nga mogamit sa ASG. Ang imong code mahimong sama niini:

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

Atong tan-awon sa usag usa.

Tungod kay ang parameter sa pag-ihap gitakda sa usa ka static nga kantidad, kini nga code molihok nga wala’y mga problema: kung imong gipadagan ang aplikasyon nga mando, maghimo kini tulo nga EC2 server. Apan unsa man kung gusto nimo nga mag-deploy og usa ka server sa matag Availability Zone (AZ) sulod sa imong kasamtangan nga rehiyon sa AWS? Mahimo nimong i-load ang imong code sa usa ka lista sa mga zone gikan sa aws_availability_zones nga tinubdan sa datos ug dayon i-loop ang matag usa ug maghimo og EC2 server niini gamit ang count parameter ug 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" {}

Kini nga kodigo molihok usab nga maayo, tungod kay ang parameter sa pag-ihap mahimong maghisgot sa mga gigikanan sa datos nga wala’y mga problema. Apan unsa ang mahitabo kung ang gidaghanon sa mga server nga kinahanglan nimong buhaton nagdepende sa output sa pipila nga kapanguhaan? Aron ipakita kini, ang pinakasayon ​​nga paagi mao ang paggamit sa random_integer nga kapanguhaan, nga, sumala sa gisugyot sa ngalan, nagbalik sa usa ka random integer:

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

Kini nga code nagmugna og random nga numero tali sa 1 ug 3. Atong tan-awon kon unsay mahitabo kon atong sulayan nga gamiton ang output niini nga kapanguhaan sa count parameter sa aws_instance nga kapanguhaan:

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

Kung nagpadagan ka sa plano sa terraform sa kini nga code, makuha nimo ang mosunod nga sayup:

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.

Ang Terraform nanginahanglan nga ang pag-ihap ug alang sa_matag usa kalkulado sa yugto sa pagplano, sa wala pa mabuhat o usbon ang bisan unsang mga kapanguhaan. Kini nagpasabot nga ang count ug for_each mahimong magtumong sa mga literal, variable, tinubdan sa datos, ug bisan sa mga lista sa kahinguhaan (basta ang ilang gitas-on mahimong matino sa oras sa pag-iskedyul), apan dili sa pag-compute sa mga variable nga output sa kapanguhaan.

count ug for_each dili magamit sa module configuration

Sa umaabot nga adlaw mahimo kang matintal sa pagdugang sa usa ka parameter sa pag-ihap sa imong configuration sa 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"
}

Kini nga kodigo mosulay sa paggamit sa ihap sulod sa usa ka module aron makahimo og tulo ka kopya sa webserver-cluster nga kapanguhaan. O mahimo nimong himoong opsyonal ang pagkonektar sa usa ka module depende sa pipila ka kondisyon sa Boolean pinaagi sa pag-set sa parametro sa pag-ihap niini ngadto sa 0. Mahimo kini nga tan-awon sama sa makatarunganon nga code, apan makuha nimo kini nga sayup kung magpatuman sa plano sa terraform:

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.

Ikasubo, sa Terraform 0.12.6, ang paggamit sa count o for_each sa usa ka module nga kapanguhaan dili suportado. Sumala sa Terraform 0.12 nga mga nota sa pagpagawas (http://bit.ly/3257bv4), ang HashiCorp nagplano nga idugang kini nga kapabilidad sa umaabot, busa depende kung kanus-a nimo basahon kini nga libro, mahimo’g magamit na kini. Aron mahibal-an nga sigurado, basaha ang Terraform changelog dinhi.

Mga Limitasyon sa Zero Downtime Deployment

Ang paggamit sa create_before_destroy block inubanan sa ASG usa ka maayong solusyon sa pagmugna og zero-downtime deployments, gawas sa usa ka caveat: ang mga lagda sa autoscaling dili suportado. O aron mahimong mas tukma, gi-reset niini ang gidak-on sa ASG balik sa min_size sa matag deployment, nga mahimong problema kung naggamit ka mga lagda sa autoscaling aron madugangan ang gidaghanon sa mga server nga nagdagan.

Pananglitan, ang module sa webserver-cluster naglangkob sa usa ka pares sa aws_autoscaling_schedule nga mga kapanguhaan, nga sa alas-9 sa buntag nagdugang ang gidaghanon sa mga server sa cluster gikan sa duha ngadto sa napulo. Kung mag-deploy ka sa, ingnon ta, 11 a.m., ang bag-ong ASG mag-boot sa duha ra ka server kaysa sa napulo ug magpabilin nga ingon niana hangtod alas 9 sa buntag sa sunod nga adlaw.

Kini nga limitasyon mahimong likayan sa daghang mga paagi.

• Usba ang balik-balik nga parametro sa aws_autoscaling_schedule gikan sa 0 9 * * * (“pagdagan sa alas 9 sa buntag”) ngadto sa 0-59 9-17 * * * (“pagdagan matag minuto gikan sa alas 9 sa buntag hangtod sa alas 5 sa hapon”). Kung ang ASG aduna nay napulo ka mga server, ang pagpadagan niining autoscaling nga lagda pag-usab dili makausab sa bisan unsa, nga mao ang atong gusto. Apan kung bag-o pa lang nga na-deploy ang ASG, kini nga lagda magsiguro nga sa labing taas nga minuto ang gidaghanon sa mga server niini moabot sa napulo. Dili kini usa ka hingpit nga elegante nga pamaagi, ug ang dagkong paglukso gikan sa napulo ngadto sa duha ka mga server ug likod mahimo usab nga hinungdan sa mga problema sa mga tiggamit.
• Paghimo ug custom script nga naggamit sa AWS API aron matino ang gidaghanon sa mga aktibong server sa ASG, tawga kini gamit ang external data source (tan-awa ang "External Data Source" sa pahina 249), ug itakda ang ASG's desired_capacity parameter sa value nga gibalik ni ang script. Niining paagiha, ang matag bag-ong instance sa ASG kanunay nga modagan sa parehas nga kapasidad sa kasamtangan nga Terraform code ug maghimo nga mas lisud ang pagpadayon.

Siyempre, ang Terraform labing maayo nga adunay built-in nga suporta alang sa zero-downtime nga pag-deploy, apan kaniadtong Mayo 2019, ang HashiCorp team wala’y plano nga idugang kini nga pagpaandar (mga detalye - dinhi).

Ang husto nga plano mahimong dili malampuson nga gipatuman

Usahay ang plano nga mando naghimo sa usa ka hingpit nga husto nga plano sa pag-deploy, apan ang pag-apply nga mando nagbalik usa ka sayup. Sulayi, pananglitan, ang pagdugang sa aws_iam_user nga kapanguhaan nga adunay parehas nga ngalan nga imong gigamit alang sa IAM user nga imong gibuhat sa sayo pa sa Kapitulo 2:

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

Karon, kung gipadagan nimo ang mando sa plano, ang Terraform magpagawas usa ka daw makatarunganon nga 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 gipadagan nimo ang apply command makuha nimo ang mosunod nga sayup:

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, mao nga ang usa ka IAM user nga adunay kana nga ngalan naglungtad na. Ug kini mahimong mahitabo dili lamang sa mga tiggamit sa IAM, apan sa halos bisan unsang kapanguhaan. Posible nga adunay naghimo niini nga kapanguhaan nga mano-mano o naggamit sa command line, apan bisan asa nga paagi, ang pagpares sa mga ID mosangpot sa mga panagsumpaki. Adunay daghang mga kabag-ohan sa kini nga sayup nga kanunay makadakop sa mga bag-ong nangabot sa Terraform sa katingala.

Ang yawe nga punto mao nga ang mando sa plano sa terraform nagkonsiderar lamang sa mga kahinguhaan nga gipiho sa file sa estado sa Terraform. Kung ang mga kahinguhaan gihimo sa lain nga paagi (pananglitan, mano-mano pinaagi sa pag-klik sa AWS console), dili kini maabut sa file sa estado ug busa dili kini tagdon sa Terraform kung ipatuman ang mando sa plano. Ingon nga resulta, ang usa ka plano nga daw husto sa unang pagtan-aw mahimong dili molampos.

Adunay duha ka leksyon nga makat-unan gikan niini.

• Kung nagsugod ka na sa pagtrabaho sa Terraform, ayaw gamita ang bisan unsa. Kung ang bahin sa imong imprastraktura gidumala gamit ang Terraform, dili na nimo mabag-o kini sa mano-mano. Kung dili, dili lang nimo peligro ang mga katingad-an nga mga sayup sa Terraform, apan gibalibaran usab nimo ang daghang mga benepisyo sa IaC tungod kay ang code dili na usa ka tukma nga representasyon sa imong imprastraktura.
• Kung aduna ka nay imprastraktura, gamita ang import command. Kung nagsugod ka sa paggamit sa Terraform nga adunay na nga imprastraktura, mahimo nimo kini idugang sa file sa estado gamit ang terraform import command. Niining paagiha mahibal-an sa Terraform kung unsa nga imprastraktura ang kinahanglan madumala. Ang import command nagkinahanglan og duha ka argumento. Ang una mao ang resource address sa imong configuration files. Ang syntax dinhi parehas sa mga link sa kapanguhaan: _. (sama sa aws_iam_user.existing_user). Ang ikaduha nga argumento mao ang ID sa kapanguhaan nga i-import. Ingnon ta nga ang resource ID aws_iam_user mao ang user name (pananglitan, yevgeniy.brikman), ug ang resource ID aws_instance mao ang EC2 server ID (sama sa i-190e22e5). Ang paagi sa pag-import sa usa ka kapanguhaan kasagarang gipakita sa dokumentasyon sa ubos sa panid niini.

  Sa ubos mao ang usa ka import command nga nag-synchronize sa aws_iam_user nga kapanguhaan nga imong gidugang sa imong Terraform configuration uban sa IAM user sa Chapter 2 (ilisan ang imong ngalan sa yevgeniy.brikman, siyempre):

  $ terraform import aws_iam_user.existing_user yevgeniy.brikman

  Tawgon sa Terraform ang AWS API aron pangitaon ang imong IAM user ug maghimo ug state file association tali niini ug sa aws_iam_user.existing_user nga kapanguhaan sa imong Terraform configuration. Sukad karon, kung imong gipadagan ang plano nga mando, mahibal-an sa Terraform nga ang IAM user naglungtad na ug dili na mosulay sa paghimo niini pag-usab.

  Angay nga hinumdoman nga kung daghan ka na nga mga kapanguhaan nga gusto nimong i-import sa Terraform, ang mano-mano nga pagsulat sa code ug ang pag-import sa matag usa sa usa ka higayon mahimong usa ka problema. Busa angayan nga tan-awon ang usa ka himan sama sa Terraforming (http://terraforming.dtan4.net/), nga awtomatik nga maka-import og code ug estado gikan sa imong AWS account.

  Ang refactoring mahimong adunay mga lit-ag

  Refactoring kay kasagarang praktis sa programming diin imong usbon ang internal structure sa code samtang dili mausab ang external behavior. Kini mao ang paghimo sa code nga mas tin-aw, hapsay, ug mas sayon ​​sa pagmentinar. Ang refactoring usa ka kinahanglanon nga teknik nga kinahanglan gamiton kanunay. Apan kung bahin sa Terraform o bisan unsang uban pang tool sa IaC, kinahanglan nimo nga mag-amping pag-ayo kung unsa ang imong gipasabut sa "panggawas nga pamatasan" sa usa ka piraso sa code, kung dili, ang wala damha nga mga problema moabut.

  Pananglitan, ang usa ka kasagarang matang sa refactoring mao ang pag-ilis sa mga ngalan sa mga variable o mga function sa mas masabtan. Daghang mga IDE ang adunay built-in nga suporta alang sa refactoring ug mahimo nga awtomatiko nga ilisan ang ngalan sa mga variable ug function sa tibuuk nga proyekto. Sa kinatibuk-ang katuyoan nga mga pinulongan sa programming, kini usa ka gamay nga pamaagi nga dili nimo mahunahuna, apan sa Terraform kinahanglan nimo nga mag-amping pag-ayo niini, kung dili mahimo nimong masinati ang mga pagkaguba.

  Pananglitan, ang webserver-cluster module adunay input variable cluster_name:

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

  Hunahunaa nga nagsugod ka sa paggamit niini nga module sa pag-deploy og microservice nga gitawag og foo. Sa ulahi, gusto nimong ilisan ang ngalan sa imong serbisyo sa bar. Kini nga pagbag-o mahimo’g ingon gamay ra, apan sa tinuud mahimo’g hinungdan kini nga mga pagkabalda sa serbisyo.

  Ang kamatuoran mao nga ang webserver-cluster module naggamit sa cluster_name variable sa daghang mga kapanguhaan, lakip ang ngalan nga parameter sa duha ka grupo sa seguridad ug 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 imong usbon ang parameter sa ngalan sa usa ka kapanguhaan, ang Terraform magtangtang sa daan nga bersyon sa kana nga kapanguhaan ug maghimo usa ka bag-o sa lugar niini. Apan kung kana nga kapanguhaan usa ka ALB, tali sa pagtangtang niini ug pag-download sa usa ka bag-ong bersyon, wala ka'y ​​mekanismo sa pag-redirect sa trapiko sa imong web server. Ingon usab, kung ang usa ka grupo sa seguridad matangtang, ang imong mga server magsugod sa pagsalikway sa bisan unsang trapiko sa network hangtod nga adunay usa ka bag-ong grupo.

  Ang laing matang sa refactoring nga tingali interesado ka mao ang pagbag-o sa Terraform ID. Atong kuhaon ang aws_security_group nga kapanguhaan sa webserver-cluster module isip usa ka pananglitan:

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

  Ang identifier niini nga kapanguhaan gitawag nga pananglitan. Hunahunaa nga sa panahon sa refactoring nakahukom ka nga usbon kini sa usa ka mas masabtan (sa imong opinyon) nga ngalan cluster_instance:

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

  Unsa ang mahitabo sa katapusan? Husto kana: usa ka pagkabalda.

  Gi-associate sa Terraform ang matag resource ID sa cloud provider ID. Pananglitan, ang iam_user nakig-uban sa AWS IAM user ID, ug ang aws_instance nalambigit sa AWS EC2 server ID. Kung imong usbon ang resource ID (iingon gikan sa instance ngadto sa cluster_instance, sama sa kaso sa aws_security_group), ngadto sa Terraform kini makita nga ingon og imong gitangtang ang daan nga kapanguhaan ug gidugang ang usa ka bag-o. Kung imong i-apply kini nga mga pagbag-o, ang Terraform magtangtang sa daan nga grupo sa seguridad ug maghimo usa ka bag-o, samtang ang imong mga server magsugod sa pagsalikway sa bisan unsang trapiko sa network.

  Ania ang upat ka mahinungdanong mga leksyon nga kinahanglan nimong kuhaon gikan niini nga panaghisgutan.

  • Gamita kanunay ang sugo sa plano. Mahimong ipadayag niini ang tanan nga mga snags. Ribyuha pag-ayo ang output niini ug hatagi'g pagtagad ang mga sitwasyon diin ang Terraform nagplano sa pagtangtang sa mga kapanguhaan nga lagmit dili kinahanglan nga tangtangon.
  • Paghimo sa dili pa nimo tangtangon. Kung gusto nimong ilisan ang usa ka kapanguhaan, hunahunaa pag-ayo kung kinahanglan ba nimo nga maghimo usa ka puli sa dili pa tangtangon ang orihinal. Kung oo ang tubag, makatabang ang create_before_destroy. Ang parehas nga resulta mahimong makab-ot sa mano-mano pinaagi sa paghimo sa duha ka mga lakang: una pagdugang usa ka bag-ong kapanguhaan sa pag-configure ug pagdagan ang pag-apply nga mando, ug dayon kuhaa ang daan nga kapanguhaan gikan sa pagsumpo ug gamita pag-usab ang pag-apply nga mando.
  • Ang pagbag-o sa mga identifier nanginahanglan pagbag-o sa estado. Kung gusto nimong usbon ang ID nga may kalabotan sa usa ka kapanguhaan (pananglitan, ilisan ang ngalan sa aws_security_group gikan sa pananglitan ngadto sa cluster_instance) nga dili tangtangon ang kapanguhaan ug maghimo usa ka bag-ong bersyon niini, kinahanglan nimo nga i-update ang Terraform state file sumala niana. Ayaw gayud pagbuhat niini nga mano-mano - gamita hinuon ang terraform state command. Kung gibag-o ang ngalan sa mga identifier, kinahanglan nimo nga ipadagan ang terraform state mv command, nga adunay mosunod nga syntax:

    terraform state mv <ORIGINAL_REFERENCE> <NEW_REFERENCE>

    Ang ORIGINAL_REFERENCE usa ka ekspresyon nga nagtumong sa kahinguhaan sa karon nga porma, ug ang NEW_REFERENCE kung asa nimo gusto ibalhin kini. Pananglitan, sa pag-usab sa ngalan sa aws_security_group nga grupo gikan sa pananglitan ngadto sa cluster_instance, kinahanglan nimo nga ipadagan ang mosunod nga sugo:

    $ terraform state mv 
       aws_security_group.instance 
       aws_security_group.cluster_instance

    Gisultihan niini ang Terraform nga ang estado nga kaniadto nakig-uban sa aws_security_group.instance kinahanglan na karon nga kauban sa aws_security_group.cluster_instance. Kung pagkahuman sa pagbag-o ug pagpadagan sa kini nga mando nga plano sa terraform wala magpakita bisan unsang mga pagbag-o, nan gibuhat nimo ang tanan sa husto.

  • Ang ubang mga setting dili mausab. Ang mga parameter sa daghang mga kapanguhaan dili mausab. Kung sulayan nimo nga usbon kini, ang Terraform magtangtang sa daan nga kapanguhaan ug maghimo usa ka bag-o sa lugar niini. Ang matag panid sa kapanguhaan kasagarang magpakita kung unsa ang mahitabo kung imong usbon ang usa ka partikular nga setting, busa siguruha nga susihon ang dokumentasyon. Kanunay gamita ang plan command ug ikonsiderar ang paggamit sa create_before_destroy nga estratehiya.

  Ang gidugayon nga pagkamakanunayon mao ang makanunayon... uban sa paglangan

  Ang ubang mga cloud providers' APIs, sama sa AWS, kay asynchronous ug nalangan ang consistency. Ang asynchrony nagpasabot nga ang interface makabalik dayon og tubag nga dili maghulat nga makompleto ang gihangyo nga aksyon. Ang nalangan nga pagkamakanunayon nagpasabut nga ang mga pagbag-o mahimo’g magkinahanglan og panahon aron ipakaylap sa tibuuk nga sistema; samtang kini nahitabo, ang imong mga tubag mahimong dili managsama ug nagdepende kung unsang data source replica ang nagtubag sa imong mga tawag sa API.

  Hunahunaa, pananglitan, nga naghimo ka usa ka tawag sa API sa AWS nga gihangyo kini nga maghimo usa ka EC2 server. Ibalik sa API ang usa ka "malampuson" nga tubag (201 Gibuhat) hapit dayon, nga wala maghulat nga ang server mismo mabuhat. Kung sulayan nimo ang pagkonektar niini dayon, hapit gyud kini mapakyas tungod kay sa kana nga punto ang AWS nag-una pa sa mga kapanguhaan o, sa laing paagi, ang server wala pa mag-boot. Dugang pa, kung maghimo ka og lain nga tawag aron makakuha og kasayuran bahin sa kini nga server, mahimo ka makadawat usa ka sayup (404 Wala Makita). Ang butang mao nga ang kasayuran bahin sa kini nga EC2 server mahimo pa nga ipakaylap sa tibuuk nga AWS sa wala pa kini magamit bisan diin, kinahanglan ka maghulat pipila ka segundo.

  Sa matag higayon nga mogamit ka usa ka asynchronous nga API nga adunay tapulan nga pagkamakanunayon, kinahanglan nimo nga sulayan pag-usab matag karon ug unya ang imong hangyo hangtod nga makompleto ang aksyon ug mokaylap sa sistema. Ikasubo, ang AWS SDK wala maghatag bisan unsang maayong mga himan alang niini, ug ang Terraform nga proyekto kaniadto nag-antos sa daghang mga bug sama sa 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 laing pagkasulti, maghimo ka og kahinguhaan (sama sa subnet) ug dayon mosulay sa pagkuha og pipila ka impormasyon bahin niini (sama sa ID sa bag-ong nabuhat nga subnet), ug dili kini makit-an sa Terraform. Kadaghanan sa kini nga mga bug (lakip ang 6813) naayo na, apan kini nagpadayon sa matag karon ug unya, labi na kung ang Terraform nagdugang suporta alang sa usa ka bag-ong tipo sa kapanguhaan. Makalagot kini, apan sa kadaghanan nga mga kaso dili hinungdan sa bisan unsang kadaot. Kung imong gipadagan ang terraform nga magamit pag-usab, ang tanan kinahanglan nga molihok, tungod kay niining panahona ang kasayuran mikaylap na sa tibuuk nga sistema.

  Kini nga kinutlo gipresentar gikan sa libro ni Evgeniy Brikman "Terraform: imprastraktura sa lebel sa code".

Source: www.habr.com