ტერაფორმული ხაფანგები

მოდი ხაზგასმით აღვნიშნოთ რამდენიმე ხარვეზი, მათ შორის მარყუჟებთან დაკავშირებული, თუ განცხადებები და განლაგების ტექნიკა, ასევე უფრო ზოგადი საკითხები, რომლებიც გავლენას ახდენს Terraform-ზე ზოგადად:

• count და for_each პარამეტრებს აქვთ შეზღუდვები;
• ნულოვანი შეფერხების შეზღუდვა;
• კარგი გეგმაც კი შეიძლება ჩავარდეს;
• რეფაქტორირებას შეიძლება ჰქონდეს თავისი ნაკლი;
• გადავადებული თანმიმდევრულობა შეესაბამება... გადავადებას.

რაოდენობას და 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"
}

მოდით შევხედოთ მათ სათითაოდ.

ვინაიდან დათვლის პარამეტრი დაყენებულია სტატიკურ მნიშვნელობაზე, ეს კოდი იმუშავებს უპრობლემოდ: როდესაც აწარმოებთ განაცხადის ბრძანებას, ის შექმნის სამ EC2 სერვერს. რა მოხდება, თუ გინდოდათ ერთი სერვერის განთავსება თითოეულ ხელმისაწვდომობის ზონაში (AZ) თქვენს ამჟამინდელ AWS რეგიონში? თქვენ შეგიძლიათ თქვენი კოდი ატვირთოთ ზონების სია 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 რესურსის count პარამეტრში:

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 მოითხოვს, რომ 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-ზე დაყენებით. ეს შეიძლება გონივრულ კოდს ჰგავს, მაგრამ თქვენ მიიღებთ ამ შეცდომას ტერაფორმული გეგმის გაშვებისას:

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 გეგმავს მომავალში ამ შესაძლებლობის დამატებას, ასე რომ, იმისდა მიხედვით, თუ როდის წაიკითხავთ ამ წიგნს, ის შეიძლება უკვე ხელმისაწვდომი იყოს. დანამდვილებით გასარკვევად, წაიკითხეთ Terraform ცვლილებების ჟურნალი აქ.

ნულოვანი შეფერხების შეზღუდვები

ASG-თან კომბინაციაში create_before_destroy ბლოკის გამოყენება შესანიშნავი გამოსავალია ნულოვანი შეფერხების განლაგების შესაქმნელად, გარდა ერთი სიფრთხილისა: ავტოსკალირების წესები არ არის მხარდაჭერილი. ან უფრო ზუსტად რომ ვთქვათ, ეს აღადგენს ASG ზომას min_size-მდე ყველა განლაგებისას, რაც შეიძლება იყოს პრობლემა, თუ იყენებდით ავტოსკალირების წესებს გაშვებული სერვერების რაოდენობის გასაზრდელად.

მაგალითად, webserver-cluster მოდული შეიცავს წყვილ aws_autoscaling_schedule რესურსს, რომელიც დილის 9 საათზე ზრდის სერვერების რაოდენობას კლასტერში ორიდან ათამდე. თუ თქვენ განათავსებთ, ვთქვათ, დილის 11 საათზე, ახალი ASG ჩაიტვირთება მხოლოდ ორი სერვერით, ვიდრე ათი და ასე დარჩება მეორე დღის დილის 9 საათამდე.

ამ შეზღუდვის თავიდან აცილება შესაძლებელია რამდენიმე გზით.

• შეცვალეთ განმეორების პარამეტრი aws_autoscaling_schedule-ში 0 9 * * * („დილის 9 საათზე სირბილი“) დაახლოებით 0-59 9-17 * * * („ირბინეთ ყოველ წუთს დილის 9 საათიდან საღამოს 5 საათამდე“). თუ ASG-ს უკვე აქვს ათი სერვერი, ამ ავტოსკალირების წესის ხელახლა გაშვება არაფერს შეცვლის, რაც ჩვენ გვინდა. მაგრამ თუ ASG ახლახან განლაგდა, ეს წესი უზრუნველყოფს, რომ მაქსიმუმ ერთ წუთში მისი სერვერების რაოდენობა ათს მიაღწევს. ეს არ არის მთლიანად ელეგანტური მიდგომა და დიდმა გადახტომებმა ათიდან ორ სერვერზე და უკან ასევე შეიძლება გამოიწვიოს პრობლემები მომხმარებლებისთვის.
• შექმენით მორგებული სკრიპტი, რომელიც იყენებს AWS API-ს ASG-ში აქტიური სერვერების რაოდენობის დასადგენად, დარეკეთ მას მონაცემთა გარე წყაროს გამოყენებით (იხილეთ „გარე მონაცემთა წყარო“ 249 გვერდზე) და დააყენეთ ASG-ის სასურველი_ტევადობის პარამეტრი დაბრუნებულ მნიშვნელობაზე სცენარი. ამ გზით, ყოველი ახალი ASG ინსტანცია ყოველთვის იმუშავებს იმავე სიმძლავრით, როგორც არსებული Terraform კოდი და ართულებს მის შენარჩუნებას.

რა თქმა უნდა, Terraform-ს იდეალურად ექნებოდა ჩაშენებული მხარდაჭერა ნულოვანი შეფერხების განლაგებისთვის, მაგრამ 2019 წლის მაისის მდგომარეობით, HashiCorp-ის გუნდს არ ჰქონდა გეგმები ამ ფუნქციის დამატებას (დეტალები - აქ).

სწორი გეგმა შეიძლება წარუმატებლად განხორციელდეს

ზოგჯერ გეგმის ბრძანება აწარმოებს იდეალურად სწორ განლაგების გეგმას, მაგრამ განაცხადის ბრძანება აბრუნებს შეცდომას. სცადეთ, მაგალითად, დაამატოთ aws_iam_user რესურსი იმავე სახელით, რომელსაც იყენებდით მე-2 თავში ადრე შექმნილი 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.

თუ თქვენ გაუშვით განაცხადის ბრძანება, მიიღებთ შემდეგ შეცდომას:

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 State ფაილში. თუ რესურსები იქმნება სხვა გზით (მაგალითად, ხელით 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). როგორ ხდება რესურსის იმპორტი, როგორც წესი, მითითებულია დოკუმენტაციაში მისი გვერდის ბოლოში.

  ქვემოთ მოცემულია იმპორტის ბრძანება, რომელიც სინქრონიზებს aws_iam_user რესურსს, რომელიც დაამატეთ თქვენს Terraform-ის კონფიგურაციაში IAM მომხმარებელთან ერთად მე-2 თავში (რა თქმა უნდა, თქვენი სახელის ჩანაცვლება yevgeniy.brikman-ით):

  $ terraform import aws_iam_user.existing_user yevgeniy.brikman

  Terraform დაურეკავს AWS API-ს თქვენი IAM მომხმარებლის მოსაძებნად და შექმნას სახელმწიფო ფაილის ასოციაცია მასსა და aws_iam_user.existing_user რესურსს შორის თქვენს Terraform-ის კონფიგურაციაში. ამიერიდან, როცა გეგმის ბრძანებას გაუშვით, Terraform გაიგებს, რომ IAM მომხმარებელი უკვე არსებობს და აღარ შეეცდება მის შექმნას.

  აღსანიშნავია, რომ თუ თქვენ უკვე გაქვთ უამრავი რესურსი, რომლის იმპორტი გსურთ Terraform-ში, კოდის ხელით დაწერა და თითოეულის იმპორტი ერთდროულად შეიძლება იყოს რთული. ასე რომ, ღირს ისეთი ინსტრუმენტის ძიება, როგორიცაა Terraforming (http://terraforming.dtan4.net/), რომელსაც შეუძლია ავტომატურად შემოიტანოს კოდი და მდგომარეობა თქვენი AWS ანგარიშიდან.

  რეფაქტორირებას შეიძლება ჰქონდეს თავისი ნაკლი

  რეფაქტორირება არის ჩვეულებრივი პრაქტიკა პროგრამირებაში, როდესაც თქვენ ცვლით კოდის შიდა სტრუქტურას, ხოლო გარე ქცევა უცვლელი რჩება. ეს არის იმისათვის, რომ კოდი უფრო მკაფიო, დახვეწილი და ადვილად შესანახი გახდეს. რეფაქტორირება შეუცვლელი ტექნიკაა, რომელიც რეგულარულად უნდა იქნას გამოყენებული. მაგრამ როდესაც საქმე ეხება Terraform-ს ან IaC-ის ნებისმიერ სხვა ინსტრუმენტს, ძალიან ფრთხილად უნდა იყოთ, თუ რას გულისხმობთ კოდის ნაწილის „გარე ქცევაში“, წინააღმდეგ შემთხვევაში წარმოიქმნება მოულოდნელი პრობლემები.

  მაგალითად, რეფაქტორირების ჩვეულებრივი ტიპია ცვლადების ან ფუნქციების სახელების ჩანაცვლება უფრო გასაგები სახელებით. ბევრ IDE-ს აქვს ჩაშენებული მხარდაჭერა რეფაქტორაციისთვის და შეუძლია ავტომატურად გადარქმევა ცვლადები და ფუნქციები მთელი პროექტის განმავლობაში. ზოგადი დანიშნულების პროგრამირების ენებში, ეს არის ტრივიალური პროცედურა, რომელზეც შეიძლება არ იფიქროთ, მაგრამ Terraform-ში ძალიან ფრთხილად უნდა იყოთ ამასთან დაკავშირებით, წინააღმდეგ შემთხვევაში შეიძლება შეგეშალოთ.

  მაგალითად, webserver-cluster მოდულს აქვს შეყვანის ცვლადი cluster_name:

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

  წარმოიდგინეთ, რომ თქვენ დაიწყეთ ამ მოდულის გამოყენება მიკროსერვისის გამოსაყენებლად, სახელწოდებით foo. მოგვიანებით, გსურთ თქვენი სერვისის გადარქმევა ბარად. ეს ცვლილება შეიძლება ტრივიალური ჩანდეს, მაგრამ სინამდვილეში შეიძლება გამოიწვიოს სერვისის შეფერხება.

  ფაქტია, რომ webserver-cluster მოდული იყენებს 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" {
    # (...)
  }

  ამ რესურსის იდენტიფიკატორს ეწოდება ინსტანცია. წარმოიდგინეთ, რომ რეფაქტორირების დროს გადაწყვიტეთ მისი შეცვლა უფრო გასაგები (თქვენი აზრით) სახელით cluster_instance:

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

  რა მოხდება ბოლოს? მართალია: შეფერხება.

  Terraform აკავშირებს თითოეული რესურსის ID-ს ღრუბლის პროვაიდერის ID-თან. მაგალითად, iam_user ასოცირდება AWS IAM მომხმარებლის ID-თან, ხოლო aws_instance ასოცირდება AWS EC2 სერვერის ID-თან. თუ თქვენ შეცვლით რესურსის ID-ს (ვთქვათ, მაგალითად, cluster_instance-ზე, როგორც ეს ხდება aws_security_group-ზე), Terraform-ზე გამოჩნდება, თითქოს წაშალეთ ძველი რესურსი და დაამატეთ ახალი. თუ ამ ცვლილებებს გამოიყენებთ, Terraform წაშლის უსაფრთხოების ძველ ჯგუფს და შექმნის ახალს, ხოლო თქვენი სერვერები დაიწყებენ ნებისმიერი ქსელის ტრაფიკის უარყოფას.

  აქ არის ოთხი ძირითადი გაკვეთილი, რომელიც უნდა ამოიღოთ ამ დისკუსიიდან.

  • ყოველთვის გამოიყენეთ გეგმის ბრძანება. მას შეუძლია გამოავლინოს ყველა ეს ნაკლი. ყურადღებით გადახედეთ მის შედეგებს და ყურადღება მიაქციეთ სიტუაციებს, როდესაც Terraform გეგმავს წაშალოს რესურსები, რომლებიც, სავარაუდოდ, არ უნდა წაიშალოს.
  • შექმენით წაშლამდე. თუ გსურთ შეცვალოთ რესურსი, კარგად დაფიქრდით, გჭირდებათ თუ არა ჩანაცვლების შექმნა ორიგინალის წაშლამდე. თუ პასუხი დადებითია, create_before_destroy დაგეხმარებათ. იგივე შედეგის მიღწევა შესაძლებელია ხელით ორი ნაბიჯის შესრულებით: ჯერ დაამატეთ ახალი რესურსი კონფიგურაციაში და გაუშვით განაცხადის ბრძანება, შემდეგ ამოიღეთ ძველი რესურსი კონფიგურაციიდან და კვლავ გამოიყენეთ განაცხადის ბრძანება.
  • იდენტიფიკატორების შეცვლა მოითხოვს მდგომარეობის შეცვლას. თუ გსურთ რესურსთან ასოცირებული ID-ის შეცვლა (მაგალითად, გადარქმევა aws_security_group მაგალითიდან cluster_instance-ზე) რესურსის წაშლისა და მისი ახალი ვერსიის შექმნის გარეშე, თქვენ უნდა განაახლოთ 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.

  გადავადებული თანმიმდევრულობა შეესაბამება... გადავადებას

  ღრუბლოვანი პროვაიდერების ზოგიერთი API, როგორიცაა AWS, ასინქრონულია და აქვს დაგვიანებული თანმიმდევრულობა. ასინქრონულობა ნიშნავს, რომ ინტერფეისს შეუძლია დაუყოვნებლივ დააბრუნოს პასუხი მოთხოვნილი მოქმედების დასრულებამდე მოლოდინის გარეშე. დაგვიანებული თანმიმდევრულობა ნიშნავს, რომ ცვლილებების გავრცელებას შეიძლება დრო დასჭირდეს მთელ სისტემაში; სანამ ეს ხდება, თქვენი პასუხები შეიძლება იყოს არათანმიმდევრული და დამოკიდებულია იმაზე, თუ რომელი მონაცემთა წყაროს რეპლიკა პასუხობს თქვენს API ზარებს.

  წარმოიდგინეთ, მაგალითად, რომ თქვენ ურეკავთ API AWS-ს და სთხოვთ მას შექმნას EC2 სერვერი. API დააბრუნებს "წარმატებულ" პასუხს (201 შექმნილია) თითქმის მყისიერად, თავად სერვერის შექმნის მოლოდინის გარეშე. თუ თქვენ ცდილობთ მასთან დაკავშირებას, ის თითქმის ვერ მოხერხდება, რადგან ამ დროს AWS ჯერ კიდევ ახდენს რესურსების ინიციალიზაციას, ან, სხვაგვარად, სერვერი ჯერ არ არის ჩატვირთული. უფრო მეტიც, თუ სხვა ზარს განახორციელებთ ამ სერვერის შესახებ ინფორმაციის მისაღებად, შეიძლება მიიღოთ შეცდომა (404 Not Found). საქმე იმაშია, რომ ინფორმაცია ამ 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, ყველაფერი უნდა იმუშაოს, რადგან ამ დროისთვის ინფორმაცია უკვე გავრცელდება მთელ სისტემაში.

  ეს ნაწყვეტი წარმოდგენილია ევგენი ბრიკმანის წიგნიდან "Terraform: ინფრასტრუქტურა კოდის დონეზე".

წყარო: www.habr.com