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

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

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

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

په دې فصل کې مثالونه د شمېرنې پیرامیټر او د 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"
}

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

ځکه چې د شمېرنې پیرامیټر جامد ارزښت ته ټاکل شوی، دا کوډ به پرته له کومې ستونزې کار وکړي: کله چې تاسو د تطبیق قومانده پرمخ وړئ، نو دا به درې 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
}

دا کوډ د ۱ او ۳ ترمنځ یو تصادفي شمیره رامینځته کوي. راځئ وګورو چې څه پیښیږي که چیرې موږ هڅه وکړو چې د دې سرچینې پایله د 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.

ټیرافارم اړتیا لري چې 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"
}

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

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 پلان لري چې دا ځانګړتیا په راتلونکي کې اضافه کړي، نو د دې پورې اړه لري چې تاسو کله دا لولئ، دا ممکن دمخه شتون ولري. د ډاډ لپاره موندلو لپاره، د ټیرفارم چینج لاګ دلته ولولئ.

د صفر-بند وخت ځای پر ځای کولو محدودیتونه

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

د مثال په توګه، د ویب سرور-کلستر ماډل د aws_autoscaling_schedule سرچینو یوه جوړه لري چې په کلستر کې د سرورونو شمیر د سهار په 9:00 بجو له دوو څخه لسو ته لوړوي. که تاسو په 11:00 بجو ځای پر ځای کړئ، نو نوی ASG به د لسو پرځای یوازې دوه سرورونو سره بوټ شي، او د بلې ورځې تر 9:00 بجو پورې به پدې حالت کې پاتې شي.

دا محدودیت په څو لارو لرې کیدی شي.

• په aws_autoscaling_schedule کې د تکرار پیرامیټر له 0 9 * * * ("په 9 سهار چلول") څخه 0-59 9-17 * * * ("په هره دقیقه کې د 9 سهار څخه تر 5 ماښام پورې چلول") ته بدل کړئ. که چیرې ASG دمخه لس سرورونه ولري، نو د دې اتوماتیک کولو قاعدې بیا چلول به هیڅ شی بدل نه کړي، کوم چې موږ یې غواړو. په هرصورت، که چیرې ASG نوی ځای پر ځای شوی وي، دا قاعده تضمینوي چې دا به په اعظمي توګه په یوه دقیقه کې لسو سرورونو ته ورسیږي. دا په سمه توګه یو ښکلی چلند نه دی، او له لسو څخه تر دوو سرورونو او بیرته لوی کودونه هم د کاروونکو لپاره ستونزې رامینځته کولی شي.
• یو دودیز سکریپټ جوړ کړئ چې د AWS API څخه کار اخلي ترڅو په ASG کې د فعال سرورونو شمیر وټاکي، د بهرني ډیټا سرچینې په کارولو سره یې زنګ ووهئ (په 249 مخ کې "بهرني ډیټا سرچینه" وګورئ)، او د ASG مطلوب_ظرفیت پیرامیټر د دې سکریپټ لخوا بیرته راستانه شوي ارزښت ته تنظیم کړئ. دا ډاډ ورکوي چې هر نوی ASG مثال تل د زاړه Terraform کوډ په څیر ورته ظرفیت سره پیل کیږي، چې ساتل یې ډیر ستونزمن کوي.

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

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

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

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.

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

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 نوي راغلي کسان له پامه غورځوي.

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

له دې څخه دوه درسونه زده کېدای شي.

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

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

  $ terraform import aws_iam_user.existing_user yevgeniy.brikman

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

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

  ریفیکٹرینګ کولی شي خپل زیانونه ولري

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

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

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

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

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

  خبره دا ده چې د ویب سرور-کلستر ماډل په یو شمیر سرچینو کې د کلستر_نوم متغیر کاروي، په شمول د دوو امنیتي ډلو د نوم پیرامیټر او 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 پیژندونکي بدلول دي. راځئ چې د مثال په توګه د ویب سرور-کلستر ماډل کې د aws_security_group سرچینې واخلو:

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

  د دې سرچینې پیژندونکی د مثال په نوم یادیږي. تصور وکړئ چې د بیا رغونې په جریان کې، تاسو پریکړه کوئ چې دا ډیر تشریحي (ستاسو په نظر) نوم cluster_instance ته بدل کړئ:

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

  په پای کې به څه پیښ شي؟ سمه ده: د خدماتو مداخله.

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

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

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

    terraform state mv <ORIGINAL_REFERENCE> <NEW_REFERENCE>

    ORIGINAL_REFERENCE یوه څرګندونه ده چې سرچینې ته په خپل اوسني حالت کې اشاره کوي، او NEW_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 Plan د نوم بدلولو او د دې قوماندې چلولو وروسته هیڅ بدلون ونه ښیې، تاسو هرڅه په سمه توګه ترسره کړي دي.

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

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

  د ځینو کلاوډ چمتو کونکو APIs، لکه AWS، غیر متمرکز دي او ځنډیدلي ثبات لري. غیر متمرکز پدې معنی دی چې انٹرفیس کولی شي سمدلاسه ځواب بیرته راولي، پرته له دې چې غوښتل شوي عمل بشپړیدو ته انتظار وکړي. ځنډیدلي ثبات پدې معنی دی چې بدلونونه ممکن په ټول سیسټم کې د خپریدو لپاره وخت ونیسي؛ پداسې حال کې چې دا پیښیږي، ستاسو ځوابونه ممکن متضاد وي او پدې پورې اړه لري چې د معلوماتو سرچینې کوم نقل ستاسو د API زنګونو ته ځواب ورکوي.

  د مثال په توګه، تصور وکړئ چې تاسو AWS ته د EC2 سرور جوړولو لپاره API زنګ وهئ. 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 apply بیا چلول باید کار وکړي، ځکه چې معلومات به تر هغه وخته په ټول سیسټم کې خپاره شوي وي.

  دا اقتباس د ایوګیني بریکمن له کتاب څخه دی. ټیرفارم: د کوډ په کچه زیربنا.

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