د ټرافورم زیانونه

راځئ چې یو څو نیمګړتیاوې په ګوته کړو، پشمول د لوپونو پورې اړوند، که بیانات او د ځای پرځای کولو تخنیکونه، او همدارنګه نور عمومي مسلې چې په عمومي توګه د ټرافورم اغیزه کوي:

• شمیرنه او د هر پیرامیټر لپاره محدودیتونه لري؛
• د صفر ځنډ وخت محدودول؛
• حتی یو ښه پلان ناکام کیدی شي؛
• ریفاکتور کول کولی شي خپل زیانونه ولري.
• ځنډول شوی همغږي د ځنډ سره مطابقت لري.

شمېرنه او for_each پیرامیټونه محدودیتونه لري

په دې څپرکي کې مثالونه په لوپس او مشروط منطق کې د شمیرنې پیرامیټر او د هر بیان لپاره پراخه کار اخلي. دوی ښه فعالیت کوي، مګر دوی دوه مهم محدودیتونه لري چې تاسو یې باید خبر وي.

• شمېرنه او for_each نشي کولی د سرچینې محصول متغیر ته مراجعه وکړي.
• شمېرنه او for_each د ماډل ترتیب کې نشي کارول کیدی.

شمېرنه او for_each نشي کولی د سرچینې محصول متغیر ته مراجعه وکړي

تصور وکړئ چې تاسو اړتیا لرئ څو EC2 سرورونه ځای په ځای کړئ او د ځینې دلیلونو لپاره تاسو نه غواړئ ASG وکاروئ. ستاسو کوډ کیدای شي داسې وي:

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

راځئ چې دوی یو له بل سره وګورو.

څرنګه چې د شمېرنې پیرامیټر یو جامد ارزښت ته ټاکل شوی، دا کوډ به پرته له کومې ستونزې کار وکړي: کله چې تاسو د پلي کولو کمانډ پرمخ وړئ، دا به درې EC2 سرورونه رامینځته کړي. مګر څه که تاسو غواړئ په خپل اوسني AWS سیمه کې په هر موجودیت زون (AZ) کې یو سرور ځای په ځای کړئ؟ تاسو کولی شئ خپل کوډ د aws_availability_zones ډیټا سرچینې څخه د زونونو لیست پورته کړئ او بیا د هر یو له لارې لوپ کړئ او د شمیرې پیرامیټر او سري شاخص لاسرسي په کارولو سره پدې کې د 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" {}

دا کوډ به هم ښه کار وکړي، ځکه چې د شمېرنې پیرامیټر کولی شي پرته له کومې ستونزې د معلوماتو سرچینې حواله کړي. مګر څه پیښیږي که چیرې د سرورونو شمیر چې تاسو یې رامینځته کولو ته اړتیا لرئ د ځینې سرچینې محصول پورې اړه لري؟ د دې ښودلو لپاره، ترټولو اسانه لار د random_integer سرچینې کارول دي، کوم چې لکه څنګه چې نوم وړاندیز کوي، یو تصادفي عدد بیرته راولي:

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

دا کوډ د 1 او 3 ترمنځ تصادفي شمیره رامینځته کوي. راځئ وګورو چې څه پیښیږي که موږ هڅه وکړو د دې سرچینې محصول د aws_instance سرچینې د شمیرنې پیرامیټر کې وکاروو:

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

که تاسو په دې کوډ کې د ټرافورم پلان پرمخ وړئ، نو تاسو به لاندې تېروتنه ترلاسه کړئ:

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 اړتیا لري چې د پالن جوړونې مرحلې په جریان کې د هرې سرچینې د رامینځته کیدو یا بدلولو دمخه د هرچا لپاره شمیرل او محاسبه شي. دا پدې مانا ده چې شمیره او هر یو کولی شي لغوي، متغیرونو، د معلوماتو سرچینو، او حتی د سرچینو لیستونو ته مراجعه وکړي (تر هغه چې د دوی اوږدوالی د مهال ویش په وخت کې ټاکل کیدی شي)، مګر د محاسبې سرچینې تولید متغیرونو ته نه.

شمېرنه او 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"
}

دا کوډ هڅه کوي د ماډل دننه شمیره وکاروي ترڅو د ویب سرور - کلستر سرچینې درې کاپي رامینځته کړي. یا تاسو ممکن د یو ماډل سره وصل کول اختیاري کړئ چې د ځینې بولین حالت پورې اړه لري د هغې د شمیرنې پیرامیټر 0 ته په ترتیب کولو سره. دا ممکن د مناسب کوډ په څیر ښکاري ، مګر تاسو به دا تېروتنه ترلاسه کړئ کله چې د ټرافارم پلان اجرا کول:

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 په څیر، د ماډل سرچینې کې د شمېرنې یا for_each کارول نه ملاتړ کیږي. د Terraform 0.12 ریلیز یادښتونو (http://bit.ly/3257bv4) له مخې، HashiCorp پالن لري چې دا وړتیا په راتلونکي کې اضافه کړي، نو پدې پورې اړه لري چې تاسو دا کتاب لوستلو په وخت کې، دا ممکن دمخه شتون ولري. د ډاډ ترلاسه کولو لپاره، دلته د Terraform changelog ولولئ.

د صفر ښکته وخت ګمارلو محدودیتونه

د ASG سره په ترکیب کې د create_before_destroy بلاک کارول د صفر-Downtime ګمارنې رامینځته کولو لپاره عالي حل دی ، پرته له یو خبرداری: د اتوماتیک کولو مقررات نه ملاتړ کیږي. یا د ډیر دقیق کیدو لپاره ، دا د ASG اندازه بیرته په هره ګمارنه کې min_size ته بیا تنظیموي ، کوم چې ستونزه کیدی شي که تاسو د چلولو سرورونو شمیر زیاتولو لپاره د اتوماتیک کولو قواعد وکاروئ.

د مثال په توګه، د ویبسرور-کلستر ماډل یو جوړه 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 مطلوب_capacity پیرامیټر د بیرته راستنیدو ارزښت ته تنظیم کړئ. سکریپټ په دې توګه، د ASG هر نوی مثال به تل په ورته ظرفیت کې د موجوده Terraform کوډ په څیر پرمخ ځي او ساتل یې ستونزمن کوي.

البته، Terraform به په مثالي توګه د صفر-Downtime ګمارنې لپاره جوړ شوی ملاتړ ولري، مګر د می 2019 پورې، د HashiCorp ټیم د دې فعالیت اضافه کولو لپاره هیڅ پالن نه درلود (تفصیلات - دلته).

سم پلان ممکن په ناکامۍ سره پلي شي

ځینې ​​​​وختونه د پلان کمانډ په سمه توګه د ځای پرځای کولو پلان تولیدوي، مګر د پلي کولو کمانډ یوه تېروتنه راګرځوي. هڅه وکړئ، د مثال په توګه، د ورته نوم سره aws_iam_user سرچینې اضافه کړئ چې تاسو د IAM کارونکي لپاره کارولی و چې تاسو مخکې په 2 فصل کې رامینځته کړی:

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.

که تاسو د پلي کولو کمانډ پرمخ وړئ نو تاسو به لاندې تېروتنه ترلاسه کړئ:

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 کاروونکو ته پیښ کیدی شي ، مګر نږدې هرې سرچینې ته. دا ممکنه ده چې یو څوک دا سرچینه په لاسي ډول رامینځته کړي یا د کمانډ لاین په کارولو سره ، مګر په هرصورت ، د IDs سره سمون د شخړو لامل کیږي. د دې تېروتنې ډیری توپیرونه شتون لري چې ډیری وختونه په حیرانتیا سره Terraform ته نوي راغلي.

کلیدي ټکی دا دی چې د ټرافورم پلان کمانډ یوازې هغه سرچینې په پام کې نیسي چې د ټیرفارم ریاست فایل کې مشخص شوي. که سرچینې په کوم بل ډول رامینځته شي (د مثال په توګه ، په لاسي ډول د AWS کنسول کې کلیک کولو سره) ، دوی به په دولتي فایل کې پای ته ونه رسیږي او له همدې امله د پلان قوماندې اجرا کولو پرمهال ټیرافارم به دوی په پام کې ونه نیسي. د پایلې په توګه، یو پلان چې په لومړي نظر کې سم ښکاري به ناکامه وي.

له دې څخه د زده کړې دوه درسونه دي.

• که تاسو دمخه د Terraform سره کار پیل کړی وي ، نو بل څه مه کاروئ. که ستاسو د زیربنا یوه برخه د Terraform په کارولو سره اداره کیږي، تاسو نور نشئ کولی دا په لاسي ډول ترمیم کړئ. که نه نو، تاسو نه یوازې د عجیب Terraform غلطیو خطر لرئ، مګر تاسو د IaC ډیری ګټې هم ردوي ځکه چې کوډ به نور ستاسو د زیربنا سمه نمایش نه وي.
• که تاسو دمخه یو څه زیربنا لرئ، د وارداتو کمانډ وکاروئ. که تاسو د موجوده زیربنا سره د Terraform کارولو پیل کوئ ، تاسو کولی شئ دا د ټیرافارم وارداتو کمانډ په کارولو سره په دولتي فایل کې اضافه کړئ. په دې توګه Terraform به پوه شي چې کوم زیربنا اداره کولو ته اړتیا لري. د وارداتو قومانده دوه دلیلونه اخلي. لومړی ستاسو د تشکیلاتو فایلونو کې د سرچینې پته ده. دلته ترکیب د سرچینو لینکونو لپاره ورته دی: _. (لکه aws_iam_user.existing_user). دوهم دلیل د سرچینې ID دی چې باید وارد شي. راځئ چې ووایو د سرچینې ID aws_iam_user د کارونکي نوم دی (د مثال په توګه ، yevgeniy.brikman) ، او د سرچینې ID aws_instance د EC2 سرور ID دی (لکه i-190e22e5). د سرچینې واردولو څرنګوالی معمولا د دې پاڼې په پای کې په اسنادو کې ښودل کیږي.

  لاندې د وارداتو کمانډ دی چې د aws_iam_user سرچینې سره همغږي کوي چې تاسو په 2 فصل کې د IAM کارونکي سره په خپل Terraform ترتیب کې اضافه کړې (البته د yevgeniy.brikman لپاره ستاسو نوم ځای په ځای کول):

  $ terraform import aws_iam_user.existing_user yevgeniy.brikman

  Terraform به ستاسو د IAM کارونکي موندلو لپاره AWS API ته زنګ ووهي او ستاسو د Terraform ترتیب کې د دې او aws_iam_user.existing_user سرچینې ترمنځ د دولتي فایل اتحادیه رامینځته کړي. له اوس څخه، کله چې تاسو د پلان کمانډ پرمخ وړئ، Terraform به پوه شي چې د IAM کاروونکي لا دمخه شتون لري او بیا به یې د جوړولو هڅه ونه کړي.

  دا د یادونې وړ ده چې که تاسو دمخه ډیری سرچینې لرئ چې تاسو غواړئ په ټیرفارم کې وارد کړئ ، په لاسي ډول کوډ لیکل او په یو وخت کې د هر یو واردول ممکن یوه ستونزه وي. نو دا د یوې وسیلې په لټه کې دي لکه Terraforming (http://terraforming.dtan4.net/)، کوم چې کولی شي په اتوماتيک ډول ستاسو د AWS حساب څخه کوډ او حالت وارد کړي.

  Refactoring کولی شي خپل زیانونه ولري

  ریفکټور کول په برنامه کولو کې یو عام عمل دی چیرې چې تاسو د کوډ داخلي جوړښت بدل کړئ پداسې حال کې چې بهرني چلند بدلیږي. دا د دې لپاره دی چې کوډ روښانه، پاک، او د ساتلو لپاره اسانه کړي. Refactoring یو اړین تخنیک دی چې باید په منظمه توګه وکارول شي. مګر کله چې دا د Terraform یا کوم بل IaC وسیلې ته راځي ، تاسو باید د دې په اړه خورا محتاط اوسئ چې تاسو د کوډ یوې برخې "بهرني چلند" څخه څه معنی لرئ ، که نه نو غیر متوقع ستونزې به رامینځته شي.

  د مثال په توګه، د بیاکتنې یو عام ډول د متغیرونو یا افعالونو نومونه د ډیر پوهیدو وړ نومونو سره بدلول دي. ډیری IDEs د ریفکتور کولو لپاره جوړ شوي ملاتړ لري او کولی شي په اوتومات ډول د پروژې په اوږدو کې متغیرونه او افعال بدل کړي. د عمومي هدف پروګرام کولو ژبو کې، دا یو کوچنی طرزالعمل دی چې تاسو یې فکر نه کوئ، مګر په ټیرفارم کې تاسو باید د دې سره خورا محتاط اوسئ، که نه نو تاسو ممکن د بندیدو تجربه وکړئ.

  د مثال په توګه، د ویبسرور-کلستر ماډل د ان پټ متغیر کلستر_نوم لري:

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

  تصور وکړئ چې تاسو د دې ماډل کارول پیل کړي ترڅو د فوو په نوم مایکرو خدمت ځای په ځای کړي. وروسته، تاسو غواړئ خپل خدمت بار ته بدل کړئ. دا بدلون ممکن لږ ښکاري، مګر په حقیقت کې دا کولی شي د خدماتو خنډ رامنځته کړي.

  حقیقت دا دی چې د ویبسرور-کلستر ماډل په یو شمیر سرچینو کې د کلستر_نیم متغیر کاروي، په شمول د دوو امنیتي ډلو نوم پیرامیټر او 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 ته بدل کړئ:

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

  په پای کې به څه کیږي؟ دا سمه ده: یو خنډ.

  Terraform د هرې سرچینې ID د کلاوډ چمتو کونکي ID سره شریکوي. د مثال په توګه، iam_user د AWS IAM کارن ID سره تړاو لري، او aws_instance د AWS EC2 سرور ID سره تړاو لري. که تاسو د سرچینې ID بدل کړئ (د مثال څخه کلستر_instance ته ووایاست ، لکه څنګه چې د aws_security_group سره قضیه ده) ، Terraform ته به داسې ښکاري چې تاسو پخوانۍ سرچینه حذف کړې او نوې یې اضافه کړې. که تاسو دا بدلونونه پلي کړئ، Terraform به پخوانی امنیتي ګروپ حذف کړي او یو نوی رامینځته کړي، پداسې حال کې چې ستاسو سرورونه د شبکې ټرافيک رد کول پیل کوي.

  دلته څلور کلیدي درسونه دي چې تاسو باید له دې بحث څخه لیرې شئ.

  • تل د پلان کمانډ وکاروئ. دا کولی شي دا ټولې نښې ښکاره کړي. د دې محصول په دقت سره بیاکتنه وکړئ او هغه حالتونو ته پاملرنه وکړئ چیرې چې Terraform پلان لري هغه سرچینې حذف کړي چې ډیری احتمال یې باید حذف نشي.
  • مخکې له دې چې تاسو حذف کړئ جوړ کړئ. که تاسو غواړئ یوه سرچینه بدله کړئ، په دقت سره فکر وکړئ چې ایا تاسو د اصلي حذف کولو دمخه بدیل رامینځته کولو ته اړتیا لرئ. که ځواب هو وي، create_before_destroy مرسته کولی شي. ورته پایله په لاسي ډول د دوه مرحلو په ترسره کولو سره ترلاسه کیدی شي: لومړی په ترتیب کې نوې سرچینه اضافه کړئ او د پلي کولو کمانډ چل کړئ ، او بیا له ترتیب څخه زړې سرچینې لرې کړئ او بیا د پلي کولو کمانډ وکاروئ.
  • د پیژندونکو بدلول د حالت بدلولو ته اړتیا لري. که تاسو غواړئ د سرچینې سره تړلې ID بدل کړئ (د مثال په توګه aws_security_group له مثال څخه کلسټر_instance ته بدل کړئ) پرته له دې چې سرچینې حذف کړئ او د هغې نوې نسخه رامینځته کړئ ، تاسو باید د هغې مطابق د Terraform حالت فایل تازه کړئ. هیڅکله دا په لاسي ډول مه کوئ - پرځای یې د ټریفارم ریاست کمانډ وکاروئ. کله چې د پیژندونکو نوم بدل کړئ، تاسو باید د terraform state mv کمانډ چل کړئ، کوم چې لاندې ترکیب لري:

    terraform state mv <ORIGINAL_REFERENCE> <NEW_REFERENCE>

    ORIGINAL_REFERENCE یو بیان دی چې سرچینې ته په خپل اوسني شکل کې اشاره کوي، او NEW_REFERENCE هغه ځای دی چې تاسو یې غواړئ حرکت وکړئ. د مثال په توګه، کله چې د aws_security_group ګروپ د مثال څخه کلستر_instance ته بدل کړئ، تاسو اړتیا لرئ لاندې کمانډ چل کړئ:

    $ terraform state mv 
       aws_security_group.instance 
       aws_security_group.cluster_instance

    دا Terraform ته وايي چې هغه دولت چې پخوا د aws_security_group.instance سره تړلی و اوس باید د aws_security_group.cluster_instance سره وصل شي. که د دې کمانډ نوم بدلولو او چلولو وروسته د ټرافورم پلان هیڅ بدلون ونه ښیې ، نو تاسو هرڅه سم ترسره کړي.

  • ځینې ​​ترتیبات نشي بدلیدلی. د ډیری سرچینو پیرامیټونه د بدلون وړ ندي. که تاسو د دوی د بدلولو هڅه وکړئ، Terraform به زاړه سرچینې حذف کړي او د هغې په ځای کې به یو نوی رامینځته کړي. د هرې سرچینې پا pageه به معمولا په ګوته کړي چې څه پیښیږي کله چې تاسو یو ځانګړي ترتیب بدل کړئ ، نو ډاډه اوسئ چې اسناد چیک کړئ. تل د پلان کمانډ وکاروئ او د create_before_destroy ستراتیژۍ په کارولو غور وکړئ.

  ځنډول شوي دوام د ځنډ سره مطابقت لري ...

  د ځینې کلاوډ چمتو کونکو APIs، لکه AWS، غیر متناسب دي او دوام یې ځنډولی دی. د اسینکروني معنی دا ده چې انٹرفیس کولی شي سمدلاسه ځواب بیرته راستانه کړي پرته لدې چې غوښتل شوي عمل بشپړیدو ته انتظار وکړي. د ځنډ دوام پدې معنی دی چې بدلونونه ممکن په ټول سیسټم کې د خپریدو لپاره وخت ونیسي. پداسې حال کې چې دا پیښیږي، ستاسو ځوابونه ممکن متضاد وي او پدې پورې اړه ولري چې د کومې ډاټا سرچینې نقل ستاسو د 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 د نوي سرچینې ډول لپاره مالتړ زیاتوي. دا ځورونکی دی، مګر په ډیری قضیو کې هیڅ زیان نه رسوي. کله چې تاسو د ټیرفارم اپلیکیشن بیا پیل کړئ، هرڅه باید کار وکړي، ځکه چې پدې وخت کې به معلومات په ټول سیسټم کې خپاره شوي وي.

  دا اقتباس د Evgeniy Brikman لخوا د کتاب څخه وړاندې شوی "ټرافارم: د کوډ په کچه زیربنا".

سرچینه: www.habr.com