Peryglon teras

Gadewch i ni dynnu sylw at rai peryglon, gan gynnwys y rhai sy'n ymwneud â dolenni, os yw datganiadau a thechnegau defnyddio, yn ogystal â materion mwy cyffredinol sy'n effeithio ar Terraform yn gyffredinol:

• mae gan y paramedrau cyfrif a for_each gyfyngiadau;
• cyfyngu sero ar leoliadau amser segur;
• gall hyd yn oed cynllun da fethu;
• gall ailffactorio gael ei beryglon;
• mae cydlyniad gohiriedig yn gyson... â gohirio.

Mae gan y paramedrau cyfrif ac ar gyfer pob un gyfyngiadau

Mae'r enghreifftiau yn y bennod hon yn gwneud defnydd helaeth o'r paramedr cyfrif a'r mynegiad for_each mewn dolenni a rhesymeg amodol. Maent yn perfformio'n dda, ond mae ganddynt ddau gyfyngiad pwysig y mae angen i chi fod yn ymwybodol ohonynt.

• Ni all Count a for_each gyfeirio at unrhyw newidynnau allbwn adnoddau.
• ni ellir defnyddio count a for_each wrth ffurfweddu modiwl.

Ni all count a for_each gyfeirio at unrhyw newidynnau allbwn adnoddau

Dychmygwch fod angen i chi ddefnyddio sawl gweinydd EC2 ac am ryw reswm nad ydych am ddefnyddio ASG. Gallai eich cod fod fel hyn:

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

Gadewch i ni edrych arnynt fesul un.

Gan fod y paramedr cyfrif wedi'i osod i werth statig, bydd y cod hwn yn gweithio heb broblemau: pan fyddwch chi'n rhedeg y gorchymyn cymhwyso, bydd yn creu tri gweinydd EC2. Ond beth os oeddech chi eisiau defnyddio un gweinydd ym mhob Parth Argaeledd (AZ) yn eich rhanbarth AWS presennol? Gallwch gael eich cod i lwytho rhestr o barthau o ffynhonnell ddata aws_availability_zones ac yna dolennu trwy bob un a chreu gweinydd EC2 ynddo gan ddefnyddio'r paramedr cyfrif a mynediad mynegai arae:

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

Bydd y cod hwn hefyd yn gweithio'n iawn, oherwydd gall y paramedr cyfrif gyfeirio at ffynonellau data heb unrhyw broblemau. Ond beth sy'n digwydd os bydd nifer y gweinyddwyr y mae angen i chi eu creu yn dibynnu ar allbwn rhywfaint o adnodd? I ddangos hyn, y ffordd hawsaf yw defnyddio'r adnodd random_integer, sydd, fel y mae'r enw'n awgrymu, yn dychwelyd cyfanrif ar hap:

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

Mae'r cod hwn yn cynhyrchu haprif rhwng 1 a 3. Gawn ni weld beth sy'n digwydd os ydyn ni'n ceisio defnyddio allbwn yr adnodd hwn ym mharamedr cyfrif yr adnodd aws_instance:

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

Os ydych chi'n rhedeg cynllun terraform ar y cod hwn, fe gewch y gwall canlynol:

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.

Mae Terraform yn ei gwneud yn ofynnol i gyfrif ac ar gyfer pob un gael ei gyfrifo yn ystod y cyfnod cynllunio, cyn i unrhyw adnoddau gael eu creu neu eu haddasu. Mae hyn yn golygu y gall cyfrif a for_each gyfeirio at lythrennau, newidynnau, ffynonellau data, a hyd yn oed restrau adnoddau (cyn belled ag y gellir pennu eu hyd ar amser amserlennu), ond nid at newidynnau allbwn adnoddau cyfrifiadurol.

ni ellir defnyddio count a for_each wrth ffurfweddu modiwl

Rhyw ddydd efallai y cewch eich temtio i ychwanegu paramedr cyfrif at ffurfweddiad eich modiwl:

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

     count = 3

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

Mae'r cod hwn yn ceisio defnyddio cyfrif o fewn modiwl i greu tri chopi o'r adnodd gwe-weinydd-clwstwr. Neu efallai y byddwch am wneud cysylltu modiwl yn ddewisol yn seiliedig ar gyflwr Boole trwy osod ei baramedr cyfrif i 0. Gallai hwn edrych fel cod rhesymol, ond fe gewch y gwall hwn wrth redeg cynllun 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.

Yn anffodus, o Terraform 0.12.6, ni chefnogir defnyddio cyfrif neu for_each mewn adnodd modiwl. Yn ôl nodiadau rhyddhau Terraform 0.12 (http://bit.ly/3257bv4), mae HashiCorp yn bwriadu ychwanegu'r gallu hwn yn y dyfodol, felly yn dibynnu ar bryd y darllenwch y llyfr hwn, efallai y bydd ar gael eisoes. I ddarganfod yn sicr, darllenwch log newid Terraform yma.

Cyfyngiadau ar Leoliadau Amser Segur

Mae defnyddio'r bloc create_before_destroy ar y cyd ag ASG yn ateb gwych ar gyfer creu gosodiadau dim-amser segur, ac eithrio un cafeat: ni chefnogir rheolau graddio awtomatig. Neu i fod yn fwy manwl gywir, mae hyn yn ailosod maint ASG yn ôl i min_size ar bob gosodiad, a allai fod yn broblem os oeddech chi'n defnyddio rheolau graddio awtomatig i gynyddu nifer y gweinyddwyr sy'n rhedeg.

Er enghraifft, mae'r modiwl gwe-weinydd-clwstwr yn cynnwys pâr o adnoddau aws_autoscaling_schedule, sydd am 9 am yn cynyddu nifer y gweinyddwyr yn y clwstwr o ddau i ddeg. Os byddwch yn defnyddio am, dyweder, 11 a.m., bydd yr ASG newydd yn cychwyn gyda dim ond dau weinydd yn hytrach na deg ac yn aros felly tan 9 a.m. y diwrnod wedyn.

Gellir osgoi'r cyfyngiad hwn mewn sawl ffordd.

• Newidiwch y paramedr ailadrodd yn aws_autoscaling_schedule o 0 9 * * * (“rhedeg am 9 y bore”) i rywbeth fel 0-59 9-17 * * (“redwch bob munud o 9 am i 5 pm”). Os oes gan ASG ddeg gweinydd yn barod, ni fydd rhedeg y rheol awtoscaling hon eto yn newid unrhyw beth, sef yr hyn yr ydym ei eisiau. Ond os mai dim ond yn ddiweddar y mae'r ASG wedi'i ddefnyddio, bydd y rheol hon yn sicrhau y bydd nifer ei weinyddion yn cyrraedd deg mewn munud ar y mwyaf. Nid yw hon yn ddull cwbl gain, a gall neidiau mawr o ddeg i ddau weinydd ac yn ôl hefyd achosi problemau i ddefnyddwyr.
• Creu sgript bwrpasol sy'n defnyddio'r API AWS i bennu nifer y gweinyddion gweithredol yn yr ASG, ei alw gan ddefnyddio ffynhonnell ddata allanol (gweler "Ffynhonnell Data Allanol" ar dudalen 249), a gosod paramedr_capacity dymunol yr ASG i'r gwerth a ddychwelwyd gan y sgript. Fel hyn, bydd pob enghraifft ASG newydd bob amser yn rhedeg ar yr un capasiti â'r cod Terraform presennol ac yn ei gwneud yn anos i'w gynnal.

Wrth gwrs, yn ddelfrydol byddai gan Terraform gefnogaeth adeiledig ar gyfer lleoliadau dim-amser segur, ond ym mis Mai 2019, nid oedd gan dîm HashiCorp unrhyw gynlluniau i ychwanegu'r swyddogaeth hon (manylion - yma).

Efallai y bydd y cynllun cywir yn cael ei roi ar waith yn aflwyddiannus

Weithiau mae'r gorchymyn cynllun yn cynhyrchu cynllun lleoli hollol gywir, ond mae'r gorchymyn cymhwyso yn dychwelyd gwall. Ceisiwch, er enghraifft, ychwanegu'r adnodd aws_iam_user gyda'r un enw a ddefnyddiwyd gennych ar gyfer y defnyddiwr IAM a grëwyd gennych yn gynharach ym Mhennod 2:

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

Nawr, os ydych chi'n rhedeg gorchymyn y cynllun, bydd Terraform yn cynhyrchu cynllun defnyddio sy'n ymddangos yn rhesymol:

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.

Os ydych chi'n rhedeg y gorchymyn cymhwyso fe gewch y gwall canlynol:

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

Y broblem, wrth gwrs, yw bod defnyddiwr IAM gyda'r enw hwnnw eisoes yn bodoli. A gall hyn ddigwydd nid yn unig i ddefnyddwyr IAM, ond i bron unrhyw adnodd. Mae'n bosibl bod rhywun wedi creu'r adnodd hwn â llaw neu gan ddefnyddio'r llinell orchymyn, ond y naill ffordd neu'r llall, mae cyfateb IDs yn arwain at wrthdaro. Mae yna lawer o amrywiadau o'r gwall hwn sy'n aml yn synnu newydd-ddyfodiaid i Terraform.

Y pwynt allweddol yw bod y gorchymyn cynllun terraform ond yn ystyried yr adnoddau hynny a nodir yn ffeil cyflwr Terraform. Os crëir adnoddau mewn rhyw ffordd arall (er enghraifft, â llaw trwy glicio yn y consol AWS), ni fyddant yn y pen draw yn y ffeil wladwriaeth ac felly ni fydd Terraform yn eu hystyried wrth weithredu'r gorchymyn cynllun. O ganlyniad, bydd cynllun sy'n ymddangos yn gywir ar yr olwg gyntaf yn aflwyddiannus.

Mae dwy wers i’w dysgu o hyn.

• Os ydych chi eisoes wedi dechrau gweithio gyda Terraform, peidiwch â defnyddio unrhyw beth arall. Os yw rhan o'ch seilwaith yn cael ei reoli gan ddefnyddio Terraform, ni allwch ei addasu â llaw mwyach. Fel arall, rydych nid yn unig yn peryglu gwallau Terraform rhyfedd, ond rydych hefyd yn negyddu llawer o fanteision IaC gan na fydd y cod yn gynrychiolaeth gywir o'ch seilwaith mwyach.
• Os oes gennych chi rywfaint o seilwaith eisoes, defnyddiwch y gorchymyn mewnforio. Os ydych chi'n dechrau defnyddio Terraform gyda'r seilwaith presennol, gallwch ei ychwanegu at ffeil y wladwriaeth gan ddefnyddio'r gorchymyn mewnforio terraform. Fel hyn bydd Terraform yn gwybod pa seilwaith sydd angen ei reoli. Mae'r gorchymyn mewnforio yn cymryd dwy ddadl. Y cyntaf yw'r cyfeiriad adnodd yn eich ffeiliau ffurfweddu. Mae'r gystrawen yma yr un peth ag ar gyfer dolenni adnoddau: _. (fel aws_iam_user.existing_user). Yr ail ddadl yw ID yr adnodd i'w fewnforio. Dywedwch mai'r ID adnodd aws_iam_user yw'r enw defnyddiwr (er enghraifft, yevgeniy.brikman), a'r ID adnodd aws_instance yw ID gweinydd EC2 (fel i-190e22e5). Mae sut i fewnforio adnodd fel arfer yn cael ei nodi yn y ddogfennaeth ar waelod ei dudalen.

  Isod mae gorchymyn mewnforio sy'n cydamseru'r adnodd aws_iam_user a ychwanegwyd gennych at eich ffurfwedd Terraform ynghyd â'r defnyddiwr IAM ym Mhennod 2 (gan amnewid eich enw am yevgeniy.brikman, wrth gwrs):

  $ terraform import aws_iam_user.existing_user yevgeniy.brikman

  Bydd Terraform yn galw'r API AWS i ddod o hyd i'ch defnyddiwr IAM a chreu cysylltiad ffeil cyflwr rhyngddo a'r adnodd aws_iam_user.existing_user yn eich cyfluniad Terraform. O hyn ymlaen, pan fyddwch chi'n rhedeg y gorchymyn cynllun, bydd Terraform yn gwybod bod y defnyddiwr IAM eisoes yn bodoli ac ni fydd yn ceisio ei greu eto.

  Mae'n werth nodi, os oes gennych lawer o adnoddau eisoes yr ydych am eu mewnforio i Terraform, gall ysgrifennu'r cod â llaw a mewnforio pob un ar y tro fod yn drafferth. Felly mae'n werth edrych i mewn i offeryn fel Terraforming (http://terraforming.dtan4.net/), a all fewnforio cod a chyflwr yn awtomatig o'ch cyfrif AWS.

  Gall ad-ffactorio gael ei beryglon

  Ailffactorio yn arfer cyffredin mewn rhaglennu lle rydych yn newid strwythur mewnol y cod tra'n gadael yr ymddygiad allanol heb ei newid. Mae hyn er mwyn gwneud y cod yn gliriach, yn daclus ac yn haws i'w gynnal. Mae ailffactorio yn dechneg anhepgor y dylid ei defnyddio'n rheolaidd. Ond o ran Terraform neu unrhyw offeryn IaC arall, mae'n rhaid i chi fod yn hynod ofalus ynghylch yr hyn a olygwch wrth “ymddygiad allanol” darn o god, fel arall bydd problemau annisgwyl yn codi.

  Er enghraifft, math cyffredin o ailffactorio yw disodli enwau newidynnau neu ffwythiannau gyda rhai mwy dealladwy. Mae gan lawer o DRhA gefnogaeth fewnol ar gyfer ailffactorio a gallant ailenwi newidynnau a swyddogaethau yn awtomatig trwy gydol y prosiect. Mewn ieithoedd rhaglennu pwrpas cyffredinol, mae hon yn weithdrefn ddibwys efallai na fyddwch chi'n meddwl amdani, ond yn Terraform mae'n rhaid i chi fod yn hynod ofalus gyda hyn, neu fe allech chi brofi toriadau.

  Er enghraifft, mae gan y modiwl gwe-gweinydd-clwstwr enw newidyn mewnbwn clwstwr_enw:

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

  Dychmygwch eich bod wedi dechrau defnyddio'r modiwl hwn i ddefnyddio microwasanaeth o'r enw foo. Yn ddiweddarach, rydych chi am ailenwi'ch gwasanaeth yn far. Gall y newid hwn ymddangos yn ddibwys, ond mewn gwirionedd gall achosi aflonyddwch i wasanaethau.

  Y ffaith yw bod y modiwl gwe-weinydd-clwstwr yn defnyddio'r newidyn clwstwr_name mewn nifer o adnoddau, gan gynnwys paramedr enw dau grŵp diogelwch a'r 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]
  }

  Os byddwch yn newid y paramedr enw ar adnodd, bydd Terraform yn dileu'r hen fersiwn o'r adnodd hwnnw ac yn creu un newydd yn ei le. Ond os yw'r adnodd hwnnw yn ALB, rhwng ei ddileu a lawrlwytho fersiwn newydd, ni fydd gennych fecanwaith i ailgyfeirio traffig i'ch gweinydd gwe. Yn yr un modd, os caiff grŵp diogelwch ei ddileu, bydd eich gweinyddwyr yn dechrau gwrthod unrhyw draffig rhwydwaith nes bod grŵp newydd yn cael ei greu.

  Math arall o ailffactorio y gallai fod gennych ddiddordeb ynddo yw newid yr ID Terraform. Gadewch i ni gymryd yr adnodd aws_security_group yn y modiwl webserver-cluster fel enghraifft:

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

  Gelwir dynodwr yr adnodd hwn yn enghraifft. Dychmygwch eich bod wedi penderfynu ei newid i enw mwy dealladwy (yn eich barn chi) cluster_instance:

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

  Beth fydd yn digwydd yn y diwedd? Mae hynny'n iawn: amhariad.

  Mae Terraform yn cysylltu pob ID adnodd ag ID darparwr y cwmwl. Er enghraifft, mae iam_user yn gysylltiedig ag ID defnyddiwr AWS IAM, ac mae aws_instance yn gysylltiedig ag ID gweinydd AWS EC2. Os byddwch yn newid ID yr adnodd (dyweder o enghraifft i cluster_instance, fel sy'n wir am aws_security_group), i Terraform bydd yn ymddangos fel pe baech wedi dileu'r hen adnodd ac ychwanegu un newydd. Os byddwch chi'n cymhwyso'r newidiadau hyn, bydd Terraform yn dileu'r hen grŵp diogelwch ac yn creu un newydd, tra bod eich gweinyddwyr yn dechrau gwrthod unrhyw draffig rhwydwaith.

  Dyma bedair gwers allweddol y dylech eu cymryd o'r drafodaeth hon.

  • Defnyddiwch y gorchymyn cynllun bob amser. Gall ddatgelu'r holl rwystrau hyn. Adolygwch ei allbwn yn ofalus a rhowch sylw i sefyllfaoedd lle mae Terraform yn bwriadu dileu adnoddau sydd fwyaf tebygol o beidio â chael eu dileu.
  • Creu cyn i chi ddileu. Os ydych am adnewyddu adnodd, meddyliwch yn ofalus a oes angen i chi greu un arall cyn dileu'r gwreiddiol. Os mai 'ydw' yw'r ateb, gall create_before_destroy helpu. Gellir cyflawni'r un canlyniad â llaw trwy berfformio dau gam: yn gyntaf ychwanegwch adnodd newydd i'r ffurfweddiad a rhedeg y gorchymyn cymhwyso, ac yna tynnwch yr hen adnodd o'r ffurfweddiad a defnyddiwch y gorchymyn cymhwyso eto.
  • Mae newid dynodwyr yn gofyn am newid cyflwr. Os ydych chi am newid yr ID sy'n gysylltiedig ag adnodd (er enghraifft, ailenwi aws_security_group o enghraifft i cluster_instance) heb ddileu'r adnodd a chreu fersiwn newydd ohono, rhaid i chi ddiweddaru ffeil cyflwr Terraform yn unol â hynny. Peidiwch byth â gwneud hyn â llaw - defnyddiwch y gorchymyn cyflwr terraform yn lle hynny. Wrth ailenwi dynodwyr, dylech redeg y gorchymyn terraform state mv, sydd â'r gystrawen ganlynol:

    terraform state mv <ORIGINAL_REFERENCE> <NEW_REFERENCE>

    Mae ORIGINAL_REFERENCE yn fynegiad sy'n cyfeirio at yr adnodd yn ei ffurf bresennol, a NEW_REFERENCE yw lle rydych chi am ei symud. Er enghraifft, wrth ailenwi'r grŵp aws_security_group o enghraifft i clwstwr_instance, mae angen i chi redeg y gorchymyn canlynol:

    $ terraform state mv 
       aws_security_group.instance 
       aws_security_group.cluster_instance

    Mae hyn yn dweud wrth Terraform y dylai'r cyflwr a oedd yn gysylltiedig yn flaenorol ag aws_security_group.instance bellach fod yn gysylltiedig ag aws_security_group.cluster_instance. Ar ôl ailenwi a rhedeg y cynllun terraform gorchymyn hwn nad yw'n dangos unrhyw newidiadau, yna gwnaethoch bopeth yn gywir.

  • Ni ellir newid rhai gosodiadau. Mae paramedrau llawer o adnoddau yn ddigyfnewid. Os ceisiwch eu newid, bydd Terraform yn dileu'r hen adnodd ac yn creu un newydd yn ei le. Bydd pob tudalen adnoddau fel arfer yn nodi beth sy'n digwydd pan fyddwch chi'n newid gosodiad penodol, felly gwnewch yn siŵr eich bod yn gwirio'r ddogfennaeth. Defnyddiwch y gorchymyn cynllun bob amser ac ystyriwch ddefnyddio'r strategaeth create_before_destroy.

  Mae cysondeb gohiriedig yn gyson... gyda gohirio

  Mae APIs rhai darparwyr cwmwl, fel AWS, yn anghydamserol ac wedi gohirio cysondeb. Mae Asynchrony yn golygu y gall y rhyngwyneb ddychwelyd ymateb ar unwaith heb aros i'r camau y gofynnwyd amdanynt gael eu cwblhau. Mae oedi o ran cysondeb yn golygu y gall newidiadau gymryd amser i ledaenu drwy'r system gyfan; tra bod hyn yn digwydd, gall eich ymatebion fod yn anghyson ac yn dibynnu ar ba replica o ffynhonnell ddata sy'n ymateb i'ch galwadau API.

  Dychmygwch, er enghraifft, eich bod yn gwneud galwad API i AWS yn gofyn iddo greu gweinydd EC2. Bydd yr API yn dychwelyd ymateb “llwyddiannus” (201 Created) bron yn syth, heb aros i’r gweinydd ei hun gael ei greu. Os ceisiwch gysylltu ag ef ar unwaith, bydd bron yn sicr yn methu oherwydd ar y pwynt hwnnw mae AWS yn dal i gychwyn adnoddau neu, fel arall, nid yw'r gweinydd wedi cychwyn eto. Ar ben hynny, os gwnewch alwad arall i gael gwybodaeth am y gweinydd hwn, efallai y byddwch yn derbyn gwall (404 Heb ei Ddarganfod). Y peth yw y gall y wybodaeth am y gweinydd EC2 hwn barhau i gael ei lluosogi trwy gydol AWS cyn iddo ddod ar gael ym mhobman, bydd yn rhaid i chi aros ychydig eiliadau.

  Pryd bynnag y byddwch yn defnyddio API asyncronaidd gyda chysondeb diog, rhaid i chi ail-geisio'ch cais o bryd i'w gilydd nes bod y weithred wedi'i chwblhau a'i lledaenu trwy'r system. Yn anffodus, nid yw'r AWS SDK yn darparu unrhyw offer da ar gyfer hyn, ac roedd y prosiect Terraform yn arfer dioddef o lawer o fygiau fel 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

  Mewn geiriau eraill, rydych chi'n creu adnodd (fel is-rwydwaith) ac yna'n ceisio cael rhywfaint o wybodaeth amdano (fel ID yr is-rwydwaith newydd), ac ni all Terraform ddod o hyd iddo. Mae'r rhan fwyaf o'r bygiau hyn (gan gynnwys 6813) wedi'u trwsio, ond maent yn dal i godi o bryd i'w gilydd, yn enwedig pan fydd Terraform yn ychwanegu cefnogaeth ar gyfer math newydd o adnodd. Mae hyn yn blino, ond yn y rhan fwyaf o achosion nid yw'n achosi unrhyw niwed. Pan fyddwch chi'n rhedeg terraform gwnewch gais eto, dylai popeth weithio, oherwydd erbyn hyn bydd y wybodaeth eisoes wedi lledaenu trwy'r system gyfan.

  Cyflwynir y dyfyniad hwn o'r llyfr gan Evgeniy Brikman "Terraform: seilwaith ar lefel y cod".

Ffynhonnell: hab.com