រណ្តៅដីឥដ្ឋ

សូមគូសបញ្ជាក់ពីភាពលំបាកមួយចំនួន រួមទាំងបញ្ហាដែលទាក់ទងនឹងរង្វិលជុំ ប្រសិនបើសេចក្តីថ្លែងការណ៍ និងបច្ចេកទេសនៃការដាក់ពង្រាយ ក៏ដូចជាបញ្ហាទូទៅជាច្រើនទៀតដែលប៉ះពាល់ដល់ Terraform ជាទូទៅ៖

• ការរាប់ និងប៉ារ៉ាម៉ែត្រនីមួយៗមានដែនកំណត់។
• កំណត់សូន្យការដាក់ពង្រាយពេលទំនេរ;
• សូម្បីតែផែនការល្អក៏អាចបរាជ័យដែរ។
• refactoring អាចមានរណ្តៅរបស់វា;
• ការបង្រួបបង្រួមពន្យាពេលគឺស្រប ... ជាមួយការពន្យាពេល។

ប៉ារ៉ាម៉ែត្ររាប់ និងសម្រាប់_នីមួយៗមានដែនកំណត់

ឧទាហរណ៍ក្នុងជំពូកនេះប្រើប្រាស់យ៉ាងទូលំទូលាយនៃប៉ារ៉ាម៉ែត្ររាប់ និងកន្សោម for_each ក្នុងរង្វិលជុំ និងតក្កវិជ្ជាតាមលក្ខខណ្ឌ។ ពួកគេអនុវត្តបានល្អ ប៉ុន្តែពួកគេមានដែនកំណត់សំខាន់ពីរដែលអ្នកត្រូវដឹង។

• រាប់ និង for_each មិនអាចយោងទៅលើអថេរទិន្នផលធនធានណាមួយបានទេ។
• count និង for_each មិនអាចប្រើក្នុងការកំណត់រចនាសម្ព័ន្ធម៉ូឌុលបានទេ។

រាប់ និង for_each មិន​អាច​យោង​អថេរ​ទិន្នផល​ធនធាន​ណាមួយ​បាន​ទេ។

ស្រមៃថាអ្នកត្រូវដាក់ពង្រាយម៉ាស៊ីនមេ EC2 ជាច្រើន ហើយសម្រាប់ហេតុផលមួយចំនួនដែលអ្នកមិនចង់ប្រើ ASG ។ លេខកូដរបស់អ្នកអាចដូចនេះ៖

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

តោះមើលពួកវាម្តងមួយៗ។

ដោយសារប៉ារ៉ាម៉ែត្ររាប់ត្រូវបានកំណត់ជាតម្លៃឋិតិវន្ត កូដនេះនឹងដំណើរការដោយគ្មានបញ្ហា៖ នៅពេលអ្នកដំណើរការពាក្យបញ្ជាអនុវត្ត វានឹងបង្កើតម៉ាស៊ីនមេ EC2 ចំនួនបី។ ប៉ុន្តែចុះយ៉ាងណាបើអ្នកចង់ដាក់ពង្រាយ server មួយនៅក្នុងតំបន់ Availability Zone (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៖

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

ប្រសិនបើអ្នកដំណើរការគម្រោង terraform នៅលើកូដនេះ អ្នកនឹងទទួលបានកំហុសដូចខាងក្រោម៖

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 ត្រូវបានគណនាក្នុងដំណាក់កាលធ្វើផែនការ មុនពេលធនធានណាមួយត្រូវបានបង្កើត ឬកែប្រែ។ នេះមានន័យថា រាប់ និង 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"
}

កូដនេះព្យាយាមប្រើការរាប់នៅក្នុងម៉ូឌុលមួយដើម្បីបង្កើតច្បាប់ចម្លងចំនួនបីនៃធនធាន webserver-cluster ។ ឬ​អ្នក​ប្រហែល​ជា​ចង់​ធ្វើ​ការ​តភ្ជាប់​ម៉ូឌុល​ជា​ជម្រើស​ដោយ​ផ្អែក​លើ​លក្ខខណ្ឌ Boolean មួយ​ចំនួន​ដោយ​កំណត់​ប៉ារ៉ាម៉ែត្រ​រាប់​របស់​វា​ទៅ 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 គ្រោងនឹងបន្ថែមសមត្ថភាពនេះនាពេលអនាគត ដូច្នេះអាស្រ័យលើពេលដែលអ្នកអានសៀវភៅនេះ វាអាចមានរួចហើយ។ ចង់ដឹងច្បាស់ថា សូមអានកំណត់ហេតុផ្លាស់ប្តូរ Terraform នៅទីនេះ.

ដែនកំណត់នៃការដាក់ពង្រាយ Zero Downtime

ការប្រើប្រាស់ប្លុក create_before_destroy រួមផ្សំជាមួយ ASG គឺជាដំណោះស្រាយដ៏ល្អសម្រាប់ការបង្កើតការដាក់ពង្រាយពេលគ្មានពេលសម្រាក លើកលែងតែការព្រមានមួយ៖ ច្បាប់នៃការធ្វើមាត្រដ្ឋានដោយស្វ័យប្រវត្តិមិនត្រូវបានគាំទ្រទេ។ ឬដើម្បីឱ្យច្បាស់លាស់ជាងនេះ វាកំណត់ទំហំ ASG ឡើងវិញទៅទំហំ min_size នៅលើរាល់ការដាក់ពង្រាយ ដែលអាចជាបញ្ហាប្រសិនបើអ្នកកំពុងប្រើច្បាប់ធ្វើមាត្រដ្ឋានដោយស្វ័យប្រវត្តិ ដើម្បីបង្កើនចំនួនម៉ាស៊ីនមេដែលកំពុងដំណើរការ។

ឧទាហរណ៍ ម៉ូឌុល webserver-cluster មានធនធាន aws_autoscaling_schedule មួយគូ ដែលនៅម៉ោង 9 am បង្កើនចំនួន servers ក្នុង cluster ពីពីរទៅដប់។ ប្រសិនបើអ្នកដាក់ពង្រាយនៅម៉ោង 11 ព្រឹក ASG ថ្មីនឹងចាប់ផ្ដើមដោយគ្រាន់តែប្រើម៉ាស៊ីនមេពីរជាជាងដប់ ហើយនៅដដែលរហូតដល់ម៉ោង 9 ព្រឹកនៅថ្ងៃបន្ទាប់។

ដែនកំណត់នេះអាចជៀសបានតាមវិធីជាច្រើន។

• ផ្លាស់ប្តូរប៉ារ៉ាម៉ែត្រនៃការកើតឡើងវិញនៅក្នុង aws_autoscaling_schedule ពី 0 9 * * * ("រត់នៅម៉ោង 9 ព្រឹក") ទៅជាអ្វីមួយដូចជា 0-59 9-17 * * * ("រត់រៀងរាល់នាទីពីម៉ោង 9 ព្រឹកដល់ម៉ោង 5 ល្ងាច")។ ប្រសិនបើ ASG មានម៉ាស៊ីនមេចំនួន XNUMX រួចហើយនោះ ការដំណើរការក្បួនធ្វើមាត្រដ្ឋានដោយស្វ័យប្រវត្តិនេះម្តងទៀតនឹងមិនផ្លាស់ប្តូរអ្វីនោះទេ ដែលជាអ្វីដែលយើងចង់បាន។ ប៉ុន្តែប្រសិនបើ ASG ទើបតែត្រូវបានដាក់ឱ្យប្រើប្រាស់នាពេលថ្មីៗនេះ ច្បាប់នេះនឹងធានាថាក្នុងរយៈពេលអតិបរមាមួយនាទី ចំនួនម៉ាស៊ីនមេរបស់វានឹងឈានដល់ដប់។ នេះមិនមែនជាវិធីសាស្រ្តឆើតឆាយទាំងស្រុងនោះទេ ហើយការលោតដ៏ធំពីម៉ាស៊ីនមេចំនួនដប់ទៅពីរ និងខាងក្រោយក៏អាចបង្កបញ្ហាដល់អ្នកប្រើប្រាស់ផងដែរ។
• បង្កើតស្គ្រីបផ្ទាល់ខ្លួនដែលប្រើ AWS API ដើម្បីកំណត់ចំនួនម៉ាស៊ីនមេសកម្មនៅក្នុង ASG ហៅវាដោយប្រើប្រភពទិន្នន័យខាងក្រៅ (សូមមើល "ប្រភពទិន្នន័យខាងក្រៅ" នៅទំព័រ 249) ហើយកំណត់ប៉ារ៉ាម៉ែត្រដែលចង់បានរបស់ ASG ទៅនឹងតម្លៃដែលត្រឡប់ដោយ ស្គ្រីប។ វិធីនេះ វត្ថុ ASG ថ្មីនីមួយៗនឹងដំណើរការក្នុងកម្រិតដូចគ្នាទៅនឹងកូដ Terraform ដែលមានស្រាប់ ហើយធ្វើឱ្យមានការលំបាកក្នុងការថែរក្សា។

ជាការពិតណាស់ Terraform នឹងមានការគាំទ្រដែលភ្ជាប់មកជាមួយសម្រាប់ការដាក់ពង្រាយពេលគ្មានពេលសម្រាក ប៉ុន្តែគិតត្រឹមខែឧសភា ឆ្នាំ 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 ប៉ុណ្ណោះទេ ប៉ុន្តែចំពោះធនធានស្ទើរតែទាំងអស់។ វាអាចទៅរួចដែលថានរណាម្នាក់បានបង្កើតធនធាននេះដោយដៃ ឬប្រើបន្ទាត់ពាក្យបញ្ជា ប៉ុន្តែតាមវិធីណាក៏ដោយ លេខសម្គាល់ដែលត្រូវគ្នានាំឱ្យមានការប៉ះទង្គិច។ មានការប្រែប្រួលជាច្រើននៃកំហុសនេះ ដែលជារឿយៗចាប់អ្នកចំណូលថ្មីមក Terraform ដោយការភ្ញាក់ផ្អើល។

ចំណុចសំខាន់គឺថាពាក្យបញ្ជាផែនការ terraform គិតតែក្នុងគណនីធនធានទាំងនោះដែលត្រូវបានបញ្ជាក់នៅក្នុងឯកសាររដ្ឋ Terraform ។ ប្រសិនបើធនធានត្រូវបានបង្កើតតាមរបៀបផ្សេងទៀត (ឧទាហរណ៍ ដោយដៃដោយចុចក្នុងកុងសូល AWS) នោះពួកគេនឹងមិនបញ្ចប់នៅក្នុងឯកសាររដ្ឋទេ ដូច្នេះហើយ Terraform នឹងមិនយកពួកវាទៅក្នុងគណនីនៅពេលប្រតិបត្តិពាក្យបញ្ជាផែនការនោះទេ។ ជាលទ្ធផល ផែនការដែលហាក់ដូចជាត្រឹមត្រូវនៅ glance ដំបូងនឹងប្រែទៅជាមិនជោគជ័យ។

មានមេរៀនពីរដែលត្រូវរៀនពីរឿងនេះ។

• ប្រសិនបើអ្នកបានចាប់ផ្តើមធ្វើការជាមួយ Terraform រួចហើយ សូមកុំប្រើអ្វីផ្សេង។ ប្រសិនបើផ្នែកនៃហេដ្ឋារចនាសម្ព័ន្ធរបស់អ្នកត្រូវបានគ្រប់គ្រងដោយប្រើ Terraform នោះ អ្នកមិនអាចកែប្រែវាដោយដៃបានទៀតទេ។ បើមិនដូច្នោះទេ អ្នកមិនត្រឹមតែប្រថុយនឹងកំហុស Terraform ដ៏ចំលែកប៉ុណ្ណោះទេ ប៉ុន្តែអ្នកក៏បដិសេធអត្ថប្រយោជន៍ជាច្រើនរបស់ IaC ផងដែរ ចាប់តាំងពីលេខកូដនឹងលែងជាតំណាងត្រឹមត្រូវនៃហេដ្ឋារចនាសម្ព័ន្ធរបស់អ្នកទៀតហើយ។
• ប្រសិនបើអ្នកមានហេដ្ឋារចនាសម្ព័ន្ធមួយចំនួនរួចហើយ សូមប្រើពាក្យបញ្ជានាំចូល។ ប្រសិនបើអ្នកកំពុងចាប់ផ្តើមប្រើ Terraform ជាមួយនឹងហេដ្ឋារចនាសម្ព័ន្ធដែលមានស្រាប់ អ្នកអាចបន្ថែមវាទៅក្នុងឯកសាររដ្ឋដោយប្រើពាក្យបញ្ជានាំចូល terraform ។ វិធីនេះ Terraform នឹងដឹងថាហេដ្ឋារចនាសម្ព័ន្ធអ្វីខ្លះដែលត្រូវគ្រប់គ្រង។ ពាក្យបញ្ជានាំចូលយកអាគុយម៉ង់ពីរ។ ទីមួយគឺជាអាសយដ្ឋានធនធាននៅក្នុងឯកសារកំណត់រចនាសម្ព័ន្ធរបស់អ្នក។ វាក្យសម្ព័ន្ធនៅទីនេះគឺដូចគ្នាទៅនឹងតំណភ្ជាប់ធនធាន៖ _. (ដូចជា aws_iam_user.existing_user)។ អាគុយម៉ង់ទីពីរគឺលេខសម្គាល់នៃធនធានដែលត្រូវនាំចូល។ ចូរនិយាយថាលេខសម្គាល់ធនធាន aws_iam_user គឺជាឈ្មោះអ្នកប្រើប្រាស់ (ឧទាហរណ៍ yevgeniy.brikman) ហើយលេខសម្គាល់ធនធាន aws_instance គឺជាលេខសម្គាល់ម៉ាស៊ីនមេ EC2 (ដូចជា i-190e22e5) ។ របៀបនាំចូលធនធានជាធម្មតាត្រូវបានចង្អុលបង្ហាញនៅក្នុងឯកសារនៅផ្នែកខាងក្រោមនៃទំព័ររបស់វា។

  ខាងក្រោមនេះគឺជាពាក្យបញ្ជានាំចូលដែលធ្វើសមកាលកម្មធនធាន aws_iam_user ដែលអ្នកបានបន្ថែមទៅការកំណត់រចនាសម្ព័ន្ធ Terraform របស់អ្នកជាមួយនឹងអ្នកប្រើប្រាស់ IAM នៅក្នុងជំពូកទី 2 (ការជំនួសឈ្មោះរបស់អ្នកសម្រាប់ yevgeniy.brikman ពិតណាស់)៖

  $ terraform import aws_iam_user.existing_user yevgeniy.brikman

  Terraform នឹងហៅទៅ API AWS ដើម្បីស្វែងរកអ្នកប្រើប្រាស់ IAM របស់អ្នក និងបង្កើតការភ្ជាប់ឯកសាររដ្ឋរវាងវា និងធនធាន aws_iam_user.existing_user នៅក្នុងការកំណត់រចនាសម្ព័ន្ធ Terraform របស់អ្នក។ ចាប់ពីពេលនេះតទៅ នៅពេលអ្នកដំណើរការពាក្យបញ្ជាផែនការ Terraform នឹងដឹងថាអ្នកប្រើប្រាស់ IAM មានរួចហើយ ហើយនឹងមិនព្យាយាមបង្កើតវាម្តងទៀតទេ។

  គួរកត់សម្គាល់ថា ប្រសិនបើអ្នកមានធនធានជាច្រើនដែលអ្នកចង់នាំចូលទៅក្នុង Terraform រួចហើយ ការសរសេរកូដដោយដៃ និងនាំចូលម្តងមួយៗអាចមានបញ្ហា។ ដូច្នេះវាមានតម្លៃក្នុងការរកមើលឧបករណ៍ដូចជា Terraforming (http://terraforming.dtan4.net/) ដែលអាចនាំចូលកូដ និងស្ថានភាពដោយស្វ័យប្រវត្តិពីគណនី AWS របស់អ្នក។

  ការកែច្នៃឡើងវិញអាចមានគុណវិបត្តិរបស់វា។

  ការកែច្នៃឡើងវិញ គឺជាការអនុវត្តទូទៅក្នុងការសរសេរកម្មវិធី ដែលអ្នកផ្លាស់ប្តូររចនាសម្ព័ន្ធខាងក្នុងនៃកូដ ខណៈពេលដែលទុកឱ្យអាកប្បកិរិយាខាងក្រៅមិនផ្លាស់ប្តូរ។ នេះគឺដើម្បីធ្វើឱ្យកូដកាន់តែច្បាស់ ស្អាតជាងមុន និងងាយស្រួលក្នុងការថែទាំ។ Refactoring គឺជាបច្ចេកទេសដែលមិនអាចខ្វះបាន ដែលគួរប្រើជាប្រចាំ។ ប៉ុន្តែនៅពេលនិយាយអំពី Terraform ឬឧបករណ៍ IaC ផ្សេងទៀត អ្នកត្រូវតែមានការប្រុងប្រយ័ត្នបំផុតអំពីអ្វីដែលអ្នកចង់សំដៅលើ "អាកប្បកិរិយាខាងក្រៅ" នៃកូដមួយ បើមិនដូច្នោះទេ បញ្ហាដែលមិននឹកស្មានដល់នឹងកើតឡើង។

  ឧទាហរណ៍ ប្រភេទទូទៅនៃ refactoring គឺជំនួសឈ្មោះនៃអថេរ ឬមុខងារជាមួយនឹងអ្វីដែលអាចយល់បាន។ IDEs ជាច្រើនមានការគាំទ្រដែលភ្ជាប់មកជាមួយសម្រាប់ការ refactoring និងអាចប្តូរឈ្មោះអថេរ និងមុខងារដោយស្វ័យប្រវត្តិទូទាំងគម្រោង។ នៅក្នុងភាសាសរសេរកម្មវិធីដែលមានគោលបំណងទូទៅ នេះគឺជានីតិវិធីដ៏កម្រមួយ ដែលអ្នកប្រហែលជាមិនគិតដល់ ប៉ុន្តែនៅក្នុង Terraform អ្នកត្រូវតែប្រុងប្រយ័ត្នបំផុតជាមួយនឹងបញ្ហានេះ បើមិនដូច្នេះទេ អ្នកអាចជួបប្រទះនឹងការដាច់ភ្លើង។

  ឧទាហរណ៍ ម៉ូឌុល webserver-cluster មាន input variable 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 ។ តោះយកធនធាន aws_security_group នៅក្នុងម៉ូឌុល webserver-cluster ជាឧទាហរណ៍៖

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

  ឧបករណ៍កំណត់អត្តសញ្ញាណនៃធនធាននេះត្រូវបានគេហៅថា instance ។ ស្រមៃថាក្នុងអំឡុងពេល refactor អ្នកសម្រេចចិត្តផ្លាស់ប្តូរវាទៅជាឈ្មោះ cluster_instance ដែលអាចយល់បានកាន់តែច្រើន (តាមគំនិតរបស់អ្នក)៖

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

  តើនឹងមានអ្វីកើតឡើងនៅទីបញ្ចប់? នោះជាការត្រឹមត្រូវ៖ ការរំខានមួយ។

  Terraform ភ្ជាប់លេខសម្គាល់ធនធាននីមួយៗជាមួយលេខសម្គាល់អ្នកផ្តល់សេវាពពក។ ឧទាហរណ៍ iam_user ត្រូវបានភ្ជាប់ជាមួយលេខសម្គាល់អ្នកប្រើប្រាស់ AWS IAM ហើយ aws_instance ត្រូវបានភ្ជាប់ជាមួយលេខសម្គាល់ម៉ាស៊ីនមេ AWS EC2 ។ ប្រសិនបើអ្នកផ្លាស់ប្តូរលេខសម្គាល់ធនធាន (និយាយថាពី instance ទៅ cluster_instance ដូចករណី aws_security_group) ទៅ Terraform វានឹងបង្ហាញឡើងដូចជាប្រសិនបើអ្នកបានលុបធនធានចាស់ ហើយបន្ថែមថ្មីមួយ។ ប្រសិនបើអ្នកអនុវត្តការផ្លាស់ប្ដូរទាំងនេះ Terraform នឹងលុបក្រុមសុវត្ថិភាពចាស់ ហើយបង្កើតថ្មីមួយ ខណៈពេលដែលម៉ាស៊ីនមេរបស់អ្នកចាប់ផ្តើមបដិសេធចរាចរណ៍បណ្តាញណាមួយ។

  នេះគឺជាមេរៀនសំខាន់ៗចំនួនបួនដែលអ្នកគួរដកចេញពីការពិភាក្សានេះ។

  • ប្រើពាក្យបញ្ជាផែនការជានិច្ច។ វា​អាច​លាតត្រដាង​នូវ​ស្នាម​ទាំងអស់នេះ​។ ពិនិត្យមើលលទ្ធផលរបស់វាដោយប្រុងប្រយ័ត្ន និងយកចិត្តទុកដាក់លើស្ថានភាពដែល Terraform គ្រោងនឹងលុបធនធានដែលទំនងជាមិនគួរត្រូវបានលុប។
  • បង្កើតមុនពេលអ្នកលុប។ ប្រសិនបើអ្នកចង់ជំនួសធនធាន សូមគិតដោយប្រុងប្រយ័ត្នថាតើអ្នកត្រូវការបង្កើតការជំនួសមុននឹងលុបដើម។ ប្រសិនបើចម្លើយគឺបាទ, create_before_destroy អាចជួយបាន។ លទ្ធផលដូចគ្នាអាចត្រូវបានសម្រេចដោយដៃដោយអនុវត្តពីរជំហាន៖ ដំបូងបន្ថែមធនធានថ្មីទៅក្នុងការកំណត់រចនាសម្ព័ន្ធ ហើយដំណើរការពាក្យបញ្ជាអនុវត្ត ហើយបន្ទាប់មកយកធនធានចាស់ចេញពីការកំណត់ ហើយប្រើពាក្យបញ្ជាអនុវត្តម្តងទៀត។
  • ការផ្លាស់ប្តូរអត្តសញ្ញាណតម្រូវឱ្យផ្លាស់ប្តូរស្ថានភាព។ ប្រសិនបើអ្នកចង់ផ្លាស់ប្តូរលេខសម្គាល់ដែលភ្ជាប់ជាមួយធនធាន (ឧទាហរណ៍ ប្តូរឈ្មោះ aws_security_group ពី instance ទៅ cluster_instance) ដោយមិនចាំបាច់លុបធនធាន និងបង្កើតកំណែថ្មីរបស់វា អ្នកត្រូវតែធ្វើបច្ចុប្បន្នភាពឯកសាររដ្ឋ Terraform ទៅតាមនោះ។ កុំធ្វើវាដោយដៃ - ប្រើពាក្យបញ្ជារដ្ឋ terraform ជំនួសវិញ។ នៅពេលប្តូរឈ្មោះឧបករណ៍សម្គាល់ អ្នកគួរតែដំណើរការពាក្យបញ្ជា terraform state mv ដែលមានវាក្យសម្ព័ន្ធដូចខាងក្រោម៖

    terraform state mv <ORIGINAL_REFERENCE> <NEW_REFERENCE>

    ORIGINAL_REFERENCE គឺជាកន្សោមដែលសំដៅទៅលើធនធានក្នុងទម្រង់បច្ចុប្បន្នរបស់វា ហើយ NEW_REFERENCE គឺជាកន្លែងដែលអ្នកចង់ផ្លាស់ទីវា។ ឧទាហរណ៍ នៅពេលប្តូរឈ្មោះក្រុម aws_security_group ពី instance ទៅ 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 នឹងលុបធនធានចាស់ ហើយបង្កើតថ្មីមួយនៅកន្លែងរបស់វា។ ទំព័រធនធាននីមួយៗជាធម្មតានឹងបង្ហាញពីអ្វីដែលកើតឡើងនៅពេលអ្នកផ្លាស់ប្តូរការកំណត់ជាក់លាក់ណាមួយ ដូច្នេះត្រូវប្រាកដថាពិនិត្យមើលឯកសារ។ ប្រើពាក្យបញ្ជាផែនការជានិច្ច ហើយពិចារណាប្រើយុទ្ធសាស្ត្រ create_before_destroy ។

  ភាពជាប់លាប់ពន្យារគឺស្រប... ជាមួយការពន្យាពេល

  APIs របស់អ្នកផ្តល់សេវាពពកមួយចំនួនដូចជា AWS មានលក្ខណៈអសមកាល និងមានការពន្យារពេល។ Asynchrony មានន័យថា ចំណុចប្រទាក់អាចត្រឡប់ការឆ្លើយតបភ្លាមៗដោយមិនរង់ចាំសកម្មភាពដែលបានស្នើសុំដើម្បីបញ្ចប់។ ភាពជាប់លាប់ដែលពន្យារពេលមានន័យថាការផ្លាស់ប្តូរអាចត្រូវការពេលវេលាដើម្បីផ្សព្វផ្សាយពេញប្រព័ន្ធ។ ខណៈពេលដែលវាកំពុងកើតឡើង ការឆ្លើយតបរបស់អ្នកអាចមានភាពមិនស៊ីសង្វាក់គ្នា និងអាស្រ័យលើប្រភពទិន្នន័យចម្លងណាមួយដែលកំពុងឆ្លើយតបទៅនឹងការហៅ API របស់អ្នក។

  ជាឧទាហរណ៍ សូមស្រមៃថាអ្នកធ្វើការហៅ API ទៅ AWS ដោយសុំឱ្យវាបង្កើតម៉ាស៊ីនមេ EC2។ API នឹងត្រឡប់ការឆ្លើយតប "ជោគជ័យ" (201 Created) ស្ទើរតែភ្លាមៗ ដោយមិនរង់ចាំឱ្យម៉ាស៊ីនមេខ្លួនឯងត្រូវបានបង្កើត។ ប្រសិនបើអ្នកព្យាយាមភ្ជាប់ទៅវាភ្លាមៗ វាស្ទើរតែប្រាកដជានឹងបរាជ័យ ដោយសារតែនៅពេលនោះ 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

  ម្យ៉ាងវិញទៀត អ្នកបង្កើតធនធាន (ដូចជាបណ្តាញរង) ហើយបន្ទាប់មកព្យាយាមយកព័ត៌មានមួយចំនួនអំពីវា (ដូចជាលេខសម្គាល់នៃបណ្តាញរងដែលបានបង្កើតថ្មី) ហើយ Terraform មិនអាចស្វែងរកវាបានទេ។ ភាគច្រើននៃកំហុសទាំងនេះ (រួមទាំង 6813) ត្រូវបានជួសជុល ប៉ុន្តែពួកគេនៅតែច្រឹបឡើងពីពេលមួយទៅពេលមួយ ជាពិសេសនៅពេលដែល Terraform បន្ថែមការគាំទ្រសម្រាប់ប្រភេទធនធានថ្មី។ នេះគឺជាការរំខាន ប៉ុន្តែក្នុងករណីភាគច្រើនមិនបង្កគ្រោះថ្នាក់អ្វីឡើយ។ នៅពេលដែលអ្នកដំណើរការ terraform ម្តងទៀត អ្វីគ្រប់យ៉ាងគួរតែដំណើរការ ព្រោះនៅពេលនេះព័ត៌មាននឹងរីករាលដាលពេញប្រព័ន្ធហើយ។

  ការដកស្រង់នេះត្រូវបានបង្ហាញចេញពីសៀវភៅដោយ Evgeniy Brikman "Terraform: ហេដ្ឋារចនាសម្ព័ន្ធនៅកម្រិតកូដ".

ប្រភព: www.habr.com