Цөөн хэдэн бэрхшээлийг онцолж үзье, үүнд гогцоо, if мэдэгдлүүд болон байршуулах арга техник, түүнчлэн Terraform-д ерөнхийдөө нөлөөлдөг ерөнхий асуудлуудтай холбоотой асуудлууд багтана.
- count болон for_each параметрүүд нь хязгаарлалттай;
- тэг сул зогсолтын байршуулалтыг хязгаарлах;
- сайн төлөвлөгөө ч бүтэлгүйтэж болзошгүй;
- refactoring нь алдаатай байж болно;
- хойшлуулсан уялдаа нийцэж байна... хойшлуулах.
Count болон for_each параметрүүдэд хязгаарлалт байдаг
Энэ бүлгийн жишээнүүдэд гогцоон дахь count параметр болон for_each илэрхийлэл болон нөхцөлт логикийг өргөнөөр ашигласан болно. Тэд сайн гүйцэтгэлтэй, гэхдээ тэдгээр нь таны мэдэж байх ёстой хоёр чухал хязгаарлалттай байдаг.
- Count болон for_each нь ямар ч нөөцийн гаралтын хувьсагчийг иш татах боломжгүй.
- count болон for_each-г модулийн тохиргоонд ашиглах боломжгүй.
count болон for_each нь ямар ч нөөцийн гаралтын хувьсагчийг иш татах боломжгүй
Та хэд хэдэн EC2 сервер байрлуулах шаардлагатай байгаа бөгөөд ямар нэг шалтгааны улмаас ASG ашиглахыг хүсэхгүй байна гэж төсөөлөөд үз дээ. Таны код дараах байдалтай байж болно.
resource "aws_instance" "example_1" {
count = 3
ami = "ami-0c55b159cbfafe1f0"
instance_type = "t2.micro"
}
Тэднийг нэг нэгээр нь харцгаая.
Count параметрийг статик утгаар тохируулсан тул энэ код асуудалгүй ажиллах болно: та application командыг ажиллуулахад гурван EC2 сервер үүсгэнэ. Гэхдээ хэрэв та одоогийн AWS бүсийнхээ Хүртээмжийн бүсэд (AZ) нэг сервер байрлуулахыг хүсвэл яах вэ? Та өөрийн кодыг aws_availability_zones өгөгдлийн эх сурвалжаас бүсүүдийн жагсаалтыг ачаалж, дараа нь тус бүрээр дамжуулан count параметр болон массивын индексийн хандалтыг ашиглан EC2 сервер үүсгэж болно:
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" {}Count параметр нь өгөгдлийн эх сурвалжийг ямар ч асуудалгүйгээр лавлах боломжтой тул энэ код бас сайн ажиллах болно. Гэхдээ таны үүсгэх шаардлагатай серверийн тоо зарим нөөцийн гаралтаас шалтгаалвал яах вэ? Үүнийг харуулахын тулд хамгийн хялбар арга бол нэрнээс нь харахад санамсаргүй бүхэл тоог буцаадаг random_integer нөөцийг ашиглах явдал юм:
resource "random_integer" "num_instances" {
min = 1
max = 3
}Энэ код нь 1-ээс 3-ын хооронд санамсаргүй тоог үүсгэдэг. Хэрэв бид aws_instance нөөцийн count параметрт энэ нөөцийн гаралтыг ашиглахыг оролдвол юу болохыг харцгаая:
resource "aws_instance" "example_3" {
count = random_integer.num_instances.result
ami = "ami-0c55b159cbfafe1f0"
instance_type = "t2.micro"
}Хэрэв та энэ код дээр terraform plan ажиллуулбал дараах алдаа гарах болно.
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 нь төлөвлөлтийн үе шатанд аливаа нөөцийг үүсгэх эсвэл өөрчлөхөөс өмнө count болон for_each-ийг тооцоолохыг шаарддаг. Энэ нь count болон for_each нь литерал, хувьсагч, өгөгдлийн эх сурвалж, тэр ч байтугай нөөцийн жагсаалтад (тэдгээрийн уртыг хуваарийн дагуу тодорхойлох боломжтой бол) хамаарах боловч тооцоолсон нөөцийн гаралтын хувьсагчдад хамаарахгүй гэсэн үг юм.
count болон for_each-г модулийн тохиргоонд ашиглах боломжгүй
Хэзээ нэгэн цагт та модулийн тохиргоонд тооны параметр нэмэхийг хүсч магадгүй юм:
module "count_example" {
source = "../../../../modules/services/webserver-cluster"
count = 3
cluster_name = "terraform-up-and-running-example"
server_port = 8080
instance_type = "t2.micro"
}Энэ код нь вэбсервер-кластер нөөцийн гурван хуулбарыг үүсгэхийн тулд модуль доторх тоог ашиглахыг оролддог. Эсвэл та зарим логикийн нөхцөл дээр тулгуурлан модулийг холбохыг хүсвэл түүний count параметрийг 0 болгож тохируулж болно. Энэ нь боломжийн код мэт харагдах боловч 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.Харамсалтай нь, Terraform 0.12.6-аас эхлэн модулийн нөөцөд count эсвэл for_each-г ашиглахыг дэмждэггүй. Terraform 0.12 хувилбарын тэмдэглэлийн дагуу (http://bit.ly/3257bv4) HashiCorp ирээдүйд энэ боломжийг нэмэхээр төлөвлөж байгаа тул та энэ номыг хэзээ уншихаас хамаарч энэ нь аль хэдийн бэлэн болсон байж магадгүй юм. Баттай мэдэхийн тулд, .
Сул зогсолтыг тэглэх хязгаарлалтууд
Create_before_destroy блокийг ASG-тэй хослуулан ашиглах нь нэг анхааруулгыг эс тооцвол тэг зогсолтгүй байршуулалтыг бий болгох гайхалтай шийдэл юм: автомат масштабын дүрмийг дэмждэггүй. Өөрөөр хэлбэл, энэ нь байршуулалт бүр дээр ASG-ийн хэмжээг мин_хэмжээ рүү буцаан тохируулдаг бөгөөд хэрэв та ажиллаж байгаа серверийн тоог нэмэгдүүлэхийн тулд автоматаар масштаблах дүрмийг ашиглаж байсан бол асуудал гарч болзошгүй.
Жишээлбэл, вэбсервер-кластер модуль нь aws_autoscaling_schedule хос нөөцийг агуулдаг бөгөөд өглөөний 9 цагт кластер дахь серверийн тоог хоёроос арав хүртэл нэмэгдүүлдэг. Хэрэв та өглөөний 11 цагт байрлуулбал шинэ ASG нь арав биш хоёр серверээр ачаалагдах бөгөөд маргааш өглөөний 9 цаг хүртэл хэвээр байх болно.
Энэ хязгаарлалтыг хэд хэдэн аргаар тойрч болно.
- aws_autoscaling_schedule дахь давталтын параметрийг 0 9 * * * (“өглөө 9 цагт ажиллуулах”)-аас 0-59 9-17 * * * (“өглөөний 9 цагаас оройн 5 цаг хүртэл минут тутамд ажиллуулах”) болгон өөрчил. Хэрэв ASG аль хэдийн арван сервертэй бол энэ автомат масштабын дүрмийг дахин ажиллуулснаар юу ч өөрчлөгдөхгүй бөгөөд энэ нь бидний хүсч буй зүйл юм. Гэхдээ хэрэв ASG саяхан ашиглалтад орсон бол энэ дүрэм нь хамгийн ихдээ нэг минутын дотор түүний серверийн тоо арав хүрэх болно. Энэ нь тийм ч гоёмсог арга биш бөгөөд араваас хоёр сервер рүү том үсрэлт хийх нь хэрэглэгчдэд асуудал үүсгэж болзошгүй юм.
- ASG дахь идэвхтэй серверүүдийн тоог тодорхойлохын тулд AWS API ашигладаг захиалгат скрипт үүсгэж, гадаад өгөгдлийн эх сурвалжийг ашиглан дуудаж (249-р хуудасны "Гадаад мэдээллийн эх сурвалж" -ыг үзнэ үү), ASG-ийн хүссэн_чадавхийн параметрийг буцаасан утгад тохируулна уу. бичиг үсэг. Ингэснээр шинэ ASG instance бүр нь одоо байгаа Terraform кодтой ижил хүчин чадлаар ажиллах бөгөөд засвар үйлчилгээ хийхэд илүү төвөгтэй болгодог.
Мэдээжийн хэрэг, Terraform нь сул зогсолтгүй байршуулалтыг дэмждэг байх нь зүйтэй боловч 2019 оны XNUMX-р сарын байдлаар HashiCorp баг энэ функцийг нэмэх төлөвлөгөөгүй байсан ().
Зөв төлөвлөгөө амжилтгүй хэрэгжиж магадгүй
Заримдаа төлөвлөгөөний команд нь төгс зөв байршуулах төлөвлөгөө гаргадаг боловч хэрэглэх команд нь алдаа гаргадаг. Жишээлбэл, 2-р бүлэгт өмнө нь үүсгэсэн IAM хэрэглэгчийн хувьд ашигласан ижил нэртэй aws_iam_user нөөцийг нэмж үзээрэй:
resource "aws_iam_user" "existing_user" {
# Подставьте сюда имя уже существующего пользователя IAM,
# чтобы попрактиковаться в использовании команды terraform import
name = "yevgeniy.brikman"
}Одоо, хэрэв та төлөвлөгөөний командыг ажиллуулбал Terraform нь боломжийн мэт санагдах байрлуулах төлөвлөгөөг гаргах болно:
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.Хэрэв та application командыг ажиллуулбал дараах алдаа гарч ирнэ.
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" {Асуудал нь мэдээжийн хэрэг ийм нэртэй IAM хэрэглэгч аль хэдийн байгаа явдал юм. Энэ нь зөвхөн IAM хэрэглэгчдэд төдийгүй бараг бүх нөөцөд тохиолдож болно. Хэн нэгэн энэ нөөцийг гараар эсвэл командын мөрийг ашиглан үүсгэсэн байж магадгүй, гэхдээ аль ч тохиолдолд ID таарах нь зөрчилдөөнд хүргэдэг. Энэ алдааны олон хувилбарууд байдаг бөгөөд энэ нь ихэвчлэн Terraform-д шинээр ирсэн хүмүүсийг гайхшруулдаг.
Гол зүйл бол terraform plan команд нь зөвхөн Terraform төлөвийн файлд заасан нөөцүүдийг харгалзан үздэг. Хэрэв нөөцийг өөр аргаар (жишээлбэл, AWS консол дээр дарж гараар) үүсгэсэн бол тэдгээр нь төрийн файлд үлдэхгүй тул Terraform төлөвлөгөөний командыг гүйцэтгэхдээ тэдгээрийг тооцохгүй. Үүний үр дүнд эхлээд харахад зөв мэт санагдсан төлөвлөгөө бүтэлгүйтэх болно.
Үүнээс суралцах хоёр сургамж бий.
- Хэрэв та Terraform-тэй аль хэдийн ажиллаж эхэлсэн бол өөр зүйл бүү ашигла. Хэрэв таны дэд бүтцийн нэг хэсгийг Terraform ашиглан удирдаж байгаа бол та үүнийг гараар өөрчлөх боломжгүй. Үгүй бол та Terraform-ийн хачирхалтай алдаа гаргах эрсдэлтэй төдийгүй код нь таны дэд бүтцийн үнэн зөв төлөөлөл байхаа больсон тул IaC-ийн олон давуу талыг үгүйсгэх болно.
- Хэрэв танд дэд бүтэц байгаа бол импортын командыг ашиглана уу. Хэрэв та Terraform-г одоо байгаа дэд бүтэцтэй ашиглаж эхэлж байгаа бол terraform import командыг ашиглан төрийн файлд нэмж болно. Ингэснээр Terraform ямар дэд бүтцийг удирдах ёстойг мэдэх болно. Импортын команд нь хоёр аргумент авдаг. Эхнийх нь таны тохиргооны файл дахь нөөцийн хаяг юм. Энд байгаа синтакс нь нөөцийн холбоостой адил байна: _. (aws_iam_user.existing_user гэх мэт). Хоёрдахь аргумент бол импортлох нөөцийн ID юм. Нөөцийн ID aws_iam_user нь хэрэглэгчийн нэр (жишээ нь, yevgeniy.brikman), нөөцийн ID aws_instance нь EC2 серверийн ID (i-190e22e5 гэх мэт) байна гэж үзье. Нөөцийг хэрхэн импортлохыг ихэвчлэн хуудасны доод талд байгаа баримт бичигт заасан байдаг.
Доорх нь таны Terraform тохиргоонд нэмсэн aws_iam_user нөөцийг 2-р бүлэгт IAM хэрэглэгчтэй синхрончлох (мэдээж өөрийн нэрийг yevgeniy.brikman гэж орлуулах) импортын команд юм.
$ terraform import aws_iam_user.existing_user yevgeniy.brikmanTerraform нь таны IAM хэрэглэгчийг олохын тулд AWS API-г дуудаж, Terraform тохиргоон доторх aws_iam_user.existing_user нөөцийн хооронд төлөвийн файлын холбоо үүсгэнэ. Одооноос эхлэн төлөвлөгөөний командыг ажиллуулахад Terraform нь IAM хэрэглэгч аль хэдийн байгаа гэдгийг мэдэж, дахин үүсгэхийг оролдохгүй.
Хэрэв танд Terraform руу оруулахыг хүссэн маш их нөөц байгаа бол кодыг гараар бичиж, тус бүрийг нэг нэгээр нь импортлох нь төвөг учруулдаг гэдгийг тэмдэглэх нь зүйтэй. Тиймээс Terraforming (http://terraforming.dtan4.net/) шиг таны AWS бүртгэлээс код болон төлөвийг автоматаар импортлох боломжтой хэрэгслийг хайж олох нь зүйтэй.
Refactoring нь алдаатай байж болно
Дахин засварлах Энэ нь кодын дотоод бүтцийг өөрчлөхийн зэрэгцээ гадаад үйлдлийг өөрчлөхгүй байх програмчлалын нийтлэг практик юм. Энэ нь кодыг илүү ойлгомжтой, цэвэрхэн, засвар үйлчилгээ хийхэд хялбар болгох зорилготой юм. Рефакторинг нь байнга хэрэглэх зайлшгүй шаардлагатай арга юм. Гэхдээ Terraform эсвэл бусад IaC хэрэгслийн талаар ярихад та кодын "гадаад зан байдал" гэж юу болохыг ойлгоход маш болгоомжтой байх хэрэгтэй, эс тэгвээс гэнэтийн асуудал гарч ирнэ.
Жишээлбэл, рефакторингын нийтлэг төрөл бол хувьсагч эсвэл функцийн нэрийг илүү ойлгомжтой нэрээр солих явдал юм. Олон IDE-д рефакторинг хийх суурилуулсан дэмжлэг байдаг бөгөөд төслийн туршид хувьсагч болон функцүүдийн нэрийг автоматаар өөрчлөх боломжтой. Ерөнхий зориулалтын програмчлалын хэлнүүдийн хувьд энэ нь таны санаанд оромгүй энгийн процедур боловч Terraform дээр та үүнийг маш болгоомжтой хийх хэрэгтэй, эс тэгвээс та тасалдал үүсгэж болзошгүй.
Жишээлбэл, вэбсервер-кластер модуль нь cluster_name гэсэн оролтын хувьсагчтай:
variable "cluster_name" { description = "The name to use for all the cluster resources" type = string }Та энэ модулийг foo нэртэй микро үйлчилгээг ашиглахад ашиглаж эхэлсэн гэж төсөөлөөд үз дээ. Дараа нь та үйлчилгээнийхээ нэрийг bar болгон өөрчлөхийг хүсэж байна. Энэ өөрчлөлт нь өчүүхэн мэт санагдаж болох ч бодит байдал дээр энэ нь үйлчилгээний тасалдал үүсгэж болзошгүй юм.
Баримт нь вэбсервер-кластер модуль нь cluster_name хувьсагчийг хэд хэдэн нөөцөд ашигладаг бөгөөд үүнд хоёр хамгаалалтын бүлгийн нэрийн параметр болон 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] }Хэрэв та нөөц дээрх нэрийн параметрийг өөрчилбөл Terraform тухайн нөөцийн хуучин хувилбарыг устгаж оронд нь шинээр үүсгэнэ. Гэхдээ хэрэв тэр нөөц нь ALB юм бол устгах болон шинэ хувилбарыг татаж авах хооронд таны вэб сервер рүү урсгалыг дахин чиглүүлэх механизм байхгүй болно. Үүний нэгэн адил, хэрэв аюулгүй байдлын бүлгийг устгавал шинэ бүлэг үүсгэх хүртэл таны серверүүд сүлжээний урсгалаас татгалзаж эхэлнэ.
Таны сонирхож болох өөр нэг рефакторинг бол Terraform ID-г өөрчлөх явдал юм. Жишээ болгон вэбсервер-кластер модулийн aws_security_group нөөцийг авч үзье:
resource "aws_security_group" "instance" { # (...) }Энэ нөөцийн танигчийг instance гэж нэрлэдэг. Та дахин засварлах явцад үүнийг илүү ойлгомжтой (таны бодлоор) cluster_instance нэрээр өөрчлөхөөр шийдсэн гэж төсөөлөөд үз дээ:
resource "aws_security_group" "cluster_instance" { # (...) }Эцсийн эцэст юу болох вэ? Энэ нь зөв: тасалдал.
Terraform нөөцийн ID бүрийг үүлэн үйлчилгээ үзүүлэгчийн ID-тай холбодог. Жишээлбэл, iam_user нь AWS IAM хэрэглэгчийн ID-тай, aws_instance нь AWS EC2 серверийн ID-тай холбоотой байдаг. Хэрэв та нөөцийн ID-г (aws_security_group-ийн адил жишээнээс cluster_instance болгон) өөрчилбөл Terraform руу хуучин нөөцийг устгаад шинээр нэмсэн мэт харагдана. Хэрэв та эдгээр өөрчлөлтийг хийвэл Terraform нь хуучин хамгаалалтын бүлгийг устгаж, шинээр үүсгэх бөгөөд таны серверүүд сүлжээний урсгалаас татгалзаж эхэлнэ.
Энэ хэлэлцүүлгээс та авах ёстой дөрвөн гол сургамж энд байна.
- Төлөвлөгөөний командыг үргэлж ашиглаарай. Энэ бүх гажигуудыг илчилж чадна. Гаралтыг сайтар нягталж үзээд Terraform нь устгаж болохгүй нөөцийг устгахаар төлөвлөж байгаа нөхцөл байдалд анхаарлаа хандуулаарай.
- Устгахаасаа өмнө үүсгэ. Хэрэв та нөөцийг солихыг хүсвэл эх хувийг устгахаасаа өмнө орлуулах шаардлагатай эсэхээ сайтар бодож үзээрэй. Хэрэв тийм гэж хариулсан бол устгах_өмнө create_before_destroy туслах болно. Хоёр алхмыг хийснээр ижил үр дүнд гараар хүрч болно: эхлээд тохиргоонд шинэ нөөц нэмж, хэрэглэх командыг ажиллуулж, дараа нь тохиргооноос хуучин нөөцийг устгаж, хэрэглэх командыг дахин ашиглана.
- Тодорхойлогчийг өөрчлөхийн тулд төлөвийг өөрчлөх шаардлагатай. Хэрэв та нөөцтэй холбоотой ID-г өөрчлөхийг хүсвэл (жишээлбэл, aws_security_group-ийн нэрийг жишээнээс cluster_instance болгон өөрчлөх) нөөцийг устгаж, шинэ хувилбар үүсгэхгүйгээр Terraform төлөвийн файлыг зохих ёсоор шинэчлэх ёстой. Үүнийг хэзээ ч гараар бүү хий - оронд нь terraform state командыг ашиглана уу. Тодорхойлогчдын нэрийг өөрчлөхдөө дараах синтакстай terraform state mv командыг ажиллуулах хэрэгтэй.
terraform state mv <ORIGINAL_REFERENCE> <NEW_REFERENCE>ORIGINAL_REFERENCE нь одоогийн хэлбэрээр байгаа нөөцийг илэрхийлдэг илэрхийлэл бөгөөд ШИНЭ_REFERENCE нь таны зөөхийг хүссэн газар юм. Жишээлбэл, aws_security_group бүлгийн нэрийг жишээнээс cluster_instance болгон өөрчлөхдөө дараах тушаалыг ажиллуулах хэрэгтэй:
$ terraform state mv aws_security_group.instance aws_security_group.cluster_instanceЭнэ нь Terraform-д өмнө нь aws_security_group.instance-тэй холбоотой байсан төлөвийг одоо aws_security_group.cluster_instance-тэй холбох ёстой гэж хэлдэг. Хэрэв энэ командыг нэрлэж, ажиллуулсны дараа terraform төлөвлөгөөнд ямар ч өөрчлөлт гарахгүй бол та бүх зүйлийг зөв хийсэн.
- Зарим тохиргоог өөрчлөх боломжгүй. Олон нөөцийн параметрүүд өөрчлөгддөггүй. Хэрэв та тэдгээрийг өөрчлөхийг оролдвол Terraform хуучин нөөцийг устгаад оронд нь шинээр үүсгэнэ. Нөөцийн хуудас бүр нь таныг тодорхой тохиргоог өөрчлөх үед юу болохыг ихэвчлэн зааж өгөх тул баримт бичгийг шалгахаа мартуузай. Төлөвлөгөөний командыг үргэлж ашиглаж, устгахаас өмнө үүсгэх стратегийг ашиглах талаар бодож үзээрэй.
Хойшлогдсон тууштай байдал нь нийцэж байна... хойшлуулах
AWS гэх мэт зарим үүлэн үйлчилгээ үзүүлэгчдийн API-ууд нь асинхрон бөгөөд хойшлогдсон тогтвортой байдалтай байдаг. Асинхрон гэдэг нь интерфэйс нь хүссэн үйлдлийг дуусгахыг хүлээхгүйгээр шууд хариу өгөх боломжтой гэсэн үг юм. Хойшлогдсон тууштай байдал нь өөрчлөлтийг систем даяар тараахад цаг хугацаа шаардагдана гэсэн үг; Энэ нь тохиолдож байх үед таны хариултууд нийцэхгүй байх бөгөөд аль өгөгдлийн эх сурвалжийн хуулбар таны API дуудлагад хариу өгч байгаагаас шалтгаална.
Жишээлбэл, та AWS руу API дуудлага хийж EC2 сервер үүсгэхийг хүссэн гэж төсөөлөөд үз дээ. API нь сервер өөрөө үүсгэгдэхийг хүлээхгүйгээр "амжилттай" хариултыг (201 Үүсгэсэн) бараг тэр даруйд нь буцаана. Хэрэв та үүнтэй шууд холбогдохыг оролдвол энэ нь бүтэлгүйтэх нь дамжиггүй, учир нь тэр үед AWS нөөцийг эхлүүлсэн хэвээр байгаа эсвэл сервер хараахан ачаалагдаагүй байна. Түүнчлэн, хэрэв та энэ серверийн талаар мэдээлэл авахын тулд дахин дуудлага хийвэл алдаа (404 олдсонгүй) гарч болзошгүй. Хамгийн гол нь энэ EC2 серверийн талаарх мэдээлэл хаа сайгүй ашиглах боломжтой болохоос өмнө AWS даяар тархсан хэвээр байгаа тул та хэдэн секунд хүлээх хэрэгтэй болно.
Залхуу нийцтэй асинхрон API ашиглах бүрдээ, үйл ажиллагаа дуусч, системээр дамжих хүртэл та хүсэлтээ үе үе дахин оролдох хэрэгтэй. Харамсалтай нь AWS SDK нь үүнд ямар ч сайн хэрэгслээр хангаагүй бөгөөд Terraform төсөл нь 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Өөрөөр хэлбэл, та нөөц (дэд сүлжээ гэх мэт) үүсгээд дараа нь энэ талаар зарим мэдээлэл авахыг оролдох (шинээр үүсгэсэн дэд сүлжээний ID гэх мэт) бөгөөд Terraform үүнийг олж чадахгүй. Эдгээр алдаануудын ихэнхийг (6813 гэх мэт) зассан ч үе үе гарч ирдэг, ялангуяа Terraform нь шинэ төрлийн нөөцийн дэмжлэгийг нэмсэн үед. Энэ нь ядаргаатай боловч ихэнх тохиолдолд ямар ч хор хөнөөл учруулахгүй. Terraform application-г дахин ажиллуулахад бүх зүйл ажиллах ёстой, учир нь энэ үед мэдээлэл систем даяар тархсан байх болно.
Энэхүү ишлэлийг Евгений Брикманы номноос толилуулж байна .
Эх сурвалж: www.habr.com