ടെറാഫോം അപകടങ്ങൾ

ലൂപ്പുകളുമായി ബന്ധപ്പെട്ടവ, ഇഫ് സ്റ്റേറ്റ്‌മെന്റുകളും ഡിപ്ലോയ്‌മെന്റ് ടെക്‌നിക്കുകളും, ടെറാഫോമിനെ പൊതുവായി ബാധിക്കുന്ന കൂടുതൽ പൊതുവായ പ്രശ്‌നങ്ങളും ഉൾപ്പെടെയുള്ള ചില പോരായ്മകൾ നമുക്ക് ഹൈലൈറ്റ് ചെയ്യാം:

• എണ്ണത്തിനും for_each പരാമീറ്ററുകൾക്കും പരിമിതികളുണ്ട്;
• പൂജ്യം പ്രവർത്തനരഹിതമായ വിന്യാസങ്ങൾ പരിമിതപ്പെടുത്തുക;
• ഒരു നല്ല പദ്ധതി പോലും പരാജയപ്പെടാം;
• പുനർനിർമ്മാണത്തിന് അതിന്റെ അപകടങ്ങൾ ഉണ്ടാകാം;
• മാറ്റിവെച്ച യോജിപ്പ് സ്ഥിരതയുള്ളതാണ്... മാറ്റിവയ്ക്കലിനൊപ്പം.

എണ്ണത്തിനും for_each പരാമീറ്ററുകൾക്കും പരിമിതികളുണ്ട്

ഈ അധ്യായത്തിലെ ഉദാഹരണങ്ങൾ ലൂപ്പുകളിലും സോപാധിക ലോജിക്കിലുമുള്ള കൗണ്ട് പാരാമീറ്ററും for_each എക്സ്പ്രഷനും വിപുലമായി ഉപയോഗിക്കുന്നു. അവർ നന്നായി പ്രവർത്തിക്കുന്നു, എന്നാൽ നിങ്ങൾ അറിഞ്ഞിരിക്കേണ്ട രണ്ട് പ്രധാന പരിമിതികളുണ്ട്.

• Count, for_each എന്നിവയ്ക്ക് റിസോഴ്‌സ് ഔട്ട്‌പുട്ട് വേരിയബിളുകളൊന്നും പരാമർശിക്കാൻ കഴിയില്ല.
• മൊഡ്യൂൾ കോൺഫിഗറേഷനിൽ count, 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.

ഏതെങ്കിലും ഉറവിടങ്ങൾ സൃഷ്‌ടിക്കുകയോ പരിഷ്‌ക്കരിക്കുകയോ ചെയ്യുന്നതിന് മുമ്പ്, ആസൂത്രണ ഘട്ടത്തിൽ ഓരോന്നിനും എണ്ണവും കണക്കുകൂട്ടലും ടെറാഫോമിന് ആവശ്യമാണ്. ഇതിനർത്ഥം, 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 പോലെ, ഒരു മൊഡ്യൂൾ റിസോഴ്‌സിൽ കൗണ്ട് അല്ലെങ്കിൽ for_each ഉപയോഗിക്കുന്നത് പിന്തുണയ്ക്കുന്നില്ല. Terraform 0.12 റിലീസ് കുറിപ്പുകൾ അനുസരിച്ച് (http://bit.ly/3257bv4), HashiCorp ഭാവിയിൽ ഈ കഴിവ് ചേർക്കാൻ പദ്ധതിയിടുന്നു, അതിനാൽ നിങ്ങൾ ഈ പുസ്തകം വായിക്കുമ്പോൾ, അത് ഇതിനകം ലഭ്യമായേക്കാം. ഉറപ്പായും കണ്ടെത്താൻ, Terraform changelog ഇവിടെ വായിക്കുക.

സീറോ ഡൌൺടൈം വിന്യാസങ്ങളുടെ പരിമിതികൾ

ASG-യുമായി സംയോജിപ്പിച്ച് create_before_destroy ബ്ലോക്ക് ഉപയോഗിക്കുന്നത് സീറോ-ഡൗൺടൈം വിന്യാസങ്ങൾ സൃഷ്ടിക്കുന്നതിനുള്ള മികച്ച പരിഹാരമാണ്, ഒരു മുന്നറിയിപ്പ് ഒഴികെ: ഓട്ടോസ്‌കേലിംഗ് നിയമങ്ങൾ പിന്തുണയ്ക്കുന്നില്ല. അല്ലെങ്കിൽ കൂടുതൽ കൃത്യമായി പറഞ്ഞാൽ, ഇത് എല്ലാ വിന്യാസത്തിലും 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-ന്റെ ആവശ്യമുള്ള_കപ്പാസിറ്റി പാരാമീറ്റർ തിരികെ നൽകിയ മൂല്യത്തിലേക്ക് സജ്ജമാക്കുക. തിരക്കഥ. ഈ രീതിയിൽ, ഓരോ പുതിയ ASG ഇൻസ്റ്റൻസും എല്ലായ്‌പ്പോഴും നിലവിലുള്ള ടെറാഫോം കോഡിന്റെ അതേ ശേഷിയിൽ പ്രവർത്തിക്കുകയും പരിപാലിക്കുന്നത് കൂടുതൽ ബുദ്ധിമുട്ടാക്കുകയും ചെയ്യും.

തീർച്ചയായും, സീറോ-ഡൌൺടൈം വിന്യാസങ്ങൾക്ക് ടെറാഫോമിന് ബിൽറ്റ്-ഇൻ പിന്തുണ ഉണ്ടായിരിക്കും, എന്നാൽ 2019 മെയ് വരെ, ഹാഷികോർപ്പ് ടീമിന് ഈ പ്രവർത്തനം ചേർക്കാൻ പദ്ധതിയൊന്നുമില്ല (വിശദാംശങ്ങൾ - ഇവിടെ).

ശരിയായ പദ്ധതി നടപ്പിലാക്കാൻ കഴിയാതെ വന്നേക്കാം

ചിലപ്പോൾ പ്ലാൻ കമാൻഡ് തികച്ചും ശരിയായ വിന്യാസ പദ്ധതി നിർമ്മിക്കുന്നു, എന്നാൽ പ്രയോഗിക്കുക കമാൻഡ് ഒരു പിശക് നൽകുന്നു. ഉദാഹരണത്തിന്, അധ്യായം 2-ൽ നിങ്ങൾ മുമ്പ് സൃഷ്‌ടിച്ച IAM ഉപയോക്താവിനായി ഉപയോഗിച്ച അതേ പേരിൽ aws_iam_user റിസോഴ്‌സ് ചേർക്കാൻ ശ്രമിക്കുക:

resource "aws_iam_user" "existing_user" {
   # Подставьте сюда имя уже существующего пользователя IAM,
   # чтобы попрактиковаться в использовании команды terraform import
   name = "yevgeniy.brikman"
}

ഇപ്പോൾ, നിങ്ങൾ പ്ലാൻ കമാൻഡ് പ്രവർത്തിപ്പിക്കുകയാണെങ്കിൽ, ടെറാഫോം ന്യായമായ ഒരു വിന്യാസ പദ്ധതി പുറപ്പെടുവിക്കും:

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 ഉപയോക്താക്കൾക്ക് മാത്രമല്ല, മിക്കവാറും എല്ലാ ഉറവിടങ്ങൾക്കും സംഭവിക്കാം. ആരെങ്കിലും ഈ റിസോഴ്‌സ് സ്വമേധയാ അല്ലെങ്കിൽ കമാൻഡ് ലൈൻ ഉപയോഗിച്ച് സൃഷ്‌ടിച്ചതാകാം, എന്നാൽ ഒന്നുകിൽ ഐഡികൾ പൊരുത്തപ്പെടുന്നത് വൈരുദ്ധ്യങ്ങളിലേക്ക് നയിക്കുന്നു. ടെറാഫോമിലെ പുതുമുഖങ്ങളെ പലപ്പോഴും ആശ്ചര്യപ്പെടുത്തുന്ന ഈ പിശകിന്റെ നിരവധി വ്യതിയാനങ്ങളുണ്ട്.

ടെറാഫോം സ്‌റ്റേറ്റ് ഫയലിൽ വ്യക്തമാക്കിയിട്ടുള്ള വിഭവങ്ങൾ മാത്രമേ ടെറാഫോം പ്ലാൻ കമാൻഡ് കണക്കിലെടുക്കൂ എന്നതാണ് പ്രധാന കാര്യം. ഉറവിടങ്ങൾ മറ്റേതെങ്കിലും വിധത്തിൽ സൃഷ്ടിക്കപ്പെട്ടാൽ (ഉദാഹരണത്തിന്, AWS കൺസോളിൽ സ്വമേധയാ ക്ലിക്കുചെയ്യുന്നതിലൂടെ), അവ സ്റ്റേറ്റ് ഫയലിൽ അവസാനിക്കില്ല, അതിനാൽ പ്ലാൻ കമാൻഡ് എക്സിക്യൂട്ട് ചെയ്യുമ്പോൾ Terraform അവ കണക്കിലെടുക്കില്ല. തൽഫലമായി, ഒറ്റനോട്ടത്തിൽ ശരിയെന്ന് തോന്നുന്ന ഒരു പ്ലാൻ പരാജയപ്പെടും.

ഇതിൽ നിന്ന് രണ്ട് പാഠങ്ങൾ പഠിക്കാനുണ്ട്.

• നിങ്ങൾ ഇതിനകം ടെറാഫോമിൽ പ്രവർത്തിക്കാൻ തുടങ്ങിയിട്ടുണ്ടെങ്കിൽ, മറ്റൊന്നും ഉപയോഗിക്കരുത്. ടെറാഫോം ഉപയോഗിച്ചാണ് നിങ്ങളുടെ ഇൻഫ്രാസ്ട്രക്ചറിന്റെ ഒരു ഭാഗം കൈകാര്യം ചെയ്യുന്നതെങ്കിൽ, നിങ്ങൾക്ക് അത് സ്വമേധയാ പരിഷ്‌കരിക്കാനാകില്ല. അല്ലാത്തപക്ഷം, നിങ്ങൾ വിചിത്രമായ ടെറാഫോം പിശകുകൾ മാത്രമല്ല, IaC-യുടെ പല ആനുകൂല്യങ്ങളും നിങ്ങൾ നിരാകരിക്കുന്നു, കാരണം കോഡ് നിങ്ങളുടെ ഇൻഫ്രാസ്ട്രക്ചറിന്റെ കൃത്യമായ പ്രതിനിധാനം ആയിരിക്കില്ല.
• നിങ്ങൾക്ക് ഇതിനകം കുറച്ച് ഇൻഫ്രാസ്ട്രക്ചർ ഉണ്ടെങ്കിൽ, ഇറക്കുമതി കമാൻഡ് ഉപയോഗിക്കുക. നിലവിലുള്ള ഇൻഫ്രാസ്ട്രക്ചർ ഉപയോഗിച്ച് നിങ്ങൾ ടെറാഫോം ഉപയോഗിക്കാൻ തുടങ്ങുകയാണെങ്കിൽ, ടെറാഫോം ഇറക്കുമതി കമാൻഡ് ഉപയോഗിച്ച് നിങ്ങൾക്ക് അത് സ്റ്റേറ്റ് ഫയലിലേക്ക് ചേർക്കാവുന്നതാണ്. എന്തെല്ലാം അടിസ്ഥാന സൗകര്യങ്ങൾ കൈകാര്യം ചെയ്യണമെന്ന് ഇതുവഴി ടെറാഫോമിന് അറിയാം. ഇറക്കുമതി കമാൻഡ് രണ്ട് ആർഗ്യുമെന്റുകൾ എടുക്കുന്നു. ആദ്യത്തേത് നിങ്ങളുടെ കോൺഫിഗറേഷൻ ഫയലുകളിലെ ഉറവിട വിലാസമാണ്. ഇവിടെയുള്ള വാക്യഘടന റിസോഴ്സ് ലിങ്കുകൾക്ക് സമാനമാണ്: _. (aws_iam_user.existing_user പോലെ). ഇറക്കുമതി ചെയ്യേണ്ട വിഭവത്തിന്റെ ഐഡിയാണ് രണ്ടാമത്തെ വാദം. റിസോഴ്‌സ് ഐഡി aws_iam_user എന്നത് ഉപയോക്തൃ നാമമാണെന്നും (ഉദാഹരണത്തിന്, yevgeniy.brikman), റിസോഴ്‌സ് ഐഡി aws_instance EC2 സെർവർ ഐഡി (i-190e22e5 പോലെ) ആണെന്നും പറയാം. ഒരു റിസോഴ്‌സ് എങ്ങനെ ഇറക്കുമതി ചെയ്യാം എന്നത് സാധാരണയായി അതിന്റെ പേജിന്റെ ചുവടെയുള്ള ഡോക്യുമെന്റേഷനിൽ സൂചിപ്പിച്ചിരിക്കുന്നു.

  അധ്യായം 2-ലെ IAM ഉപയോക്താവിനൊപ്പം നിങ്ങളുടെ Terraform കോൺഫിഗറേഷനിലേക്ക് നിങ്ങൾ ചേർത്ത aws_iam_user റിസോഴ്‌സിനെ സമന്വയിപ്പിക്കുന്ന ഒരു ഇറക്കുമതി കമാൻഡ് ചുവടെയുണ്ട് (തീർച്ചയായും yevgeniy.brikman എന്നതിന് നിങ്ങളുടെ പേര് മാറ്റിസ്ഥാപിക്കുന്നു):

  $ terraform import aws_iam_user.existing_user yevgeniy.brikman

  നിങ്ങളുടെ IAM ഉപയോക്താവിനെ കണ്ടെത്തുന്നതിനും നിങ്ങളുടെ ടെറാഫോം കോൺഫിഗറേഷനിലെ aws_iam_user.existing_user റിസോഴ്സിനും ഇടയിൽ ഒരു സ്റ്റേറ്റ് ഫയൽ അസോസിയേഷൻ സൃഷ്ടിക്കുന്നതിനും ടെറാഫോം AWS API-യെ വിളിക്കും. ഇപ്പോൾ മുതൽ, നിങ്ങൾ പ്ലാൻ കമാൻഡ് പ്രവർത്തിപ്പിക്കുമ്പോൾ, IAM ഉപയോക്താവ് ഇതിനകം ഉണ്ടെന്നും അത് വീണ്ടും സൃഷ്ടിക്കാൻ ശ്രമിക്കില്ലെന്നും Terraform അറിയും.

  Terraform-ലേക്ക് ഇമ്പോർട്ടുചെയ്യാൻ നിങ്ങൾ ആഗ്രഹിക്കുന്ന ധാരാളം ഉറവിടങ്ങൾ നിങ്ങൾക്ക് ഇതിനകം ഉണ്ടെങ്കിൽ, കോഡ് സ്വമേധയാ എഴുതുകയും ഓരോന്നും ഒരു സമയം ഇറക്കുമതി ചെയ്യുകയും ചെയ്യുന്നത് ഒരു ബുദ്ധിമുട്ടാണ് എന്നത് ശ്രദ്ധിക്കേണ്ടതാണ്. അതിനാൽ, നിങ്ങളുടെ AWS അക്കൗണ്ടിൽ നിന്ന് കോഡും സ്‌റ്റേറ്റും സ്വയമേവ ഇറക്കുമതി ചെയ്യാൻ കഴിയുന്ന Terraforming (http://terraforming.dtan4.net/) പോലുള്ള ഒരു ടൂൾ പരിശോധിക്കുന്നത് മൂല്യവത്താണ്.

  റീഫാക്‌ടറിംഗിന് അതിന്റെ പോരായ്മകൾ ഉണ്ടാകാം

  റീഫാക്ടറിംഗ് പ്രോഗ്രാമിംഗിലെ ഒരു സാധാരണ രീതിയാണ്, അവിടെ നിങ്ങൾ കോഡിന്റെ ആന്തരിക ഘടന മാറ്റുകയും ബാഹ്യ സ്വഭാവം മാറ്റാതിരിക്കുകയും ചെയ്യുന്നു. കോഡ് കൂടുതൽ വ്യക്തവും വൃത്തിയുള്ളതും പരിപാലിക്കാൻ എളുപ്പവുമാക്കുന്നതിനാണ് ഇത്. പതിവായി ഉപയോഗിക്കേണ്ട ഒരു ഒഴിച്ചുകൂടാനാവാത്ത സാങ്കേതികതയാണ് റീഫാക്റ്ററിംഗ്. എന്നാൽ Terraform അല്ലെങ്കിൽ മറ്റേതെങ്കിലും IaC ടൂൾ വരുമ്പോൾ, ഒരു കോഡിന്റെ "ബാഹ്യ സ്വഭാവം" എന്നതുകൊണ്ട് നിങ്ങൾ എന്താണ് ഉദ്ദേശിക്കുന്നതെന്ന് നിങ്ങൾ വളരെ ശ്രദ്ധാലുവായിരിക്കണം, അല്ലാത്തപക്ഷം അപ്രതീക്ഷിത പ്രശ്നങ്ങൾ ഉണ്ടാകാം.

  ഉദാഹരണത്തിന്, വേരിയബിളുകളുടെയോ ഫംഗ്‌ഷനുകളുടെയോ പേരുകൾ കൂടുതൽ മനസ്സിലാക്കാവുന്നവ ഉപയോഗിച്ച് മാറ്റിസ്ഥാപിക്കുക എന്നതാണ് ഒരു സാധാരണ തരം റീഫാക്‌ടറിംഗ്. പല ഐഡിഇകൾക്കും റീഫാക്‌ടറിംഗിനുള്ള ബിൽറ്റ്-ഇൻ പിന്തുണയുണ്ട്, കൂടാതെ പ്രോജക്‌റ്റിലുടനീളം വേരിയബിളുകളുടെയും ഫംഗ്‌ഷനുകളുടെയും പേര് സ്വയമേവ പുനർനാമകരണം ചെയ്യാൻ കഴിയും. പൊതു-ഉദ്ദേശ്യ പ്രോഗ്രാമിംഗ് ഭാഷകളിൽ, ഇത് നിങ്ങൾ ചിന്തിക്കാത്ത ഒരു നിസ്സാരമായ നടപടിക്രമമാണ്, എന്നാൽ ടെറാഫോമിൽ നിങ്ങൾ ഇത് വളരെ ശ്രദ്ധാലുവായിരിക്കണം, അല്ലാത്തപക്ഷം നിങ്ങൾക്ക് തകരാറുകൾ അനുഭവപ്പെട്ടേക്കാം.

  ഉദാഹരണത്തിന്, വെബ്സെർവർ-ക്ലസ്റ്റർ മൊഡ്യൂളിന് ഒരു ഇൻപുട്ട് വേരിയബിൾ cluster_name ഉണ്ട്:

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

  foo എന്ന മൈക്രോസർവീസ് വിന്യസിക്കാൻ നിങ്ങൾ ഈ മൊഡ്യൂൾ ഉപയോഗിക്കാൻ തുടങ്ങിയെന്ന് സങ്കൽപ്പിക്കുക. പിന്നീട്, നിങ്ങളുടെ സേവനം ബാറിലേക്ക് പുനർനാമകരണം ചെയ്യാൻ നിങ്ങൾ ആഗ്രഹിക്കുന്നു. ഈ മാറ്റം നിസ്സാരമെന്ന് തോന്നുമെങ്കിലും വാസ്തവത്തിൽ ഇത് സേവന തടസ്സങ്ങൾക്ക് കാരണമാകും.

  രണ്ട് സെക്യൂരിറ്റി ഗ്രൂപ്പുകളുടെയും ALBയുടെയും നെയിം പാരാമീറ്റർ ഉൾപ്പെടെ നിരവധി ഉറവിടങ്ങളിൽ വെബ്‌സെർവർ-ക്ലസ്റ്റർ മൊഡ്യൂൾ cluster_name വേരിയബിൾ ഉപയോഗിക്കുന്നു എന്നതാണ് വസ്തുത.

  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]
  }

  നിങ്ങൾ ഒരു റിസോഴ്‌സിലെ നെയിം പാരാമീറ്റർ മാറ്റുകയാണെങ്കിൽ, ടെറാഫോം ആ ഉറവിടത്തിന്റെ പഴയ പതിപ്പ് ഇല്ലാതാക്കുകയും അതിന്റെ സ്ഥാനത്ത് പുതിയൊരെണ്ണം സൃഷ്ടിക്കുകയും ചെയ്യും. എന്നാൽ ആ ഉറവിടം ഒരു ALB ആണെങ്കിൽ, അത് ഇല്ലാതാക്കുന്നതിനും ഒരു പുതിയ പതിപ്പ് ഡൗൺലോഡ് ചെയ്യുന്നതിനും ഇടയിൽ, നിങ്ങളുടെ വെബ് സെർവറിലേക്ക് ട്രാഫിക് റീഡയറക്ട് ചെയ്യുന്നതിനുള്ള ഒരു സംവിധാനം നിങ്ങൾക്കുണ്ടാകില്ല. അതുപോലെ, ഒരു സുരക്ഷാ ഗ്രൂപ്പ് ഇല്ലാതാക്കിയാൽ, ഒരു പുതിയ ഗ്രൂപ്പ് സൃഷ്ടിക്കുന്നത് വരെ നിങ്ങളുടെ സെർവറുകൾ ഏതെങ്കിലും നെറ്റ്‌വർക്ക് ട്രാഫിക്കിനെ നിരസിക്കാൻ തുടങ്ങും.

  നിങ്ങൾക്ക് താൽപ്പര്യമുണ്ടായേക്കാവുന്ന മറ്റൊരു തരം റീഫാക്‌ടറിംഗ് ടെറഫോം ഐഡി മാറ്റുകയാണ്. നമുക്ക് വെബ്‌സെർവർ-ക്ലസ്റ്റർ മൊഡ്യൂളിലെ aws_security_group റിസോഴ്‌സ് ഉദാഹരണമായി എടുക്കാം:

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

  ഈ വിഭവത്തിന്റെ ഐഡന്റിഫയറിനെ ഇൻസ്‌റ്റൻസ് എന്ന് വിളിക്കുന്നു. റീഫാക്‌ടറിംഗ് സമയത്ത് നിങ്ങൾ അതിനെ കൂടുതൽ മനസ്സിലാക്കാവുന്ന (നിങ്ങളുടെ അഭിപ്രായത്തിൽ) cluster_instance എന്ന പേരിലേക്ക് മാറ്റാൻ തീരുമാനിച്ചുവെന്ന് സങ്കൽപ്പിക്കുക:

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

  അവസാനം എന്ത് സംഭവിക്കും? അത് ശരിയാണ്: ഒരു തടസ്സം.

  ടെറാഫോം ഓരോ റിസോഴ്സ് ഐഡിയെയും ക്ലൗഡ് പ്രൊവൈഡർ ഐഡിയുമായി ബന്ധപ്പെടുത്തുന്നു. ഉദാഹരണത്തിന്, iam_user AWS IAM ഉപയോക്തൃ ഐഡിയുമായി ബന്ധപ്പെട്ടിരിക്കുന്നു, കൂടാതെ aws_instance AWS EC2 സെർവർ ഐഡിയുമായി ബന്ധപ്പെട്ടിരിക്കുന്നു. നിങ്ങൾ റിസോഴ്സ് ഐഡി (ഉദാഹരണത്തിൽ നിന്ന് cluster_instance ലേക്ക് പറയുക, aws_security_group-ന്റെ കാര്യത്തിലെന്നപോലെ) ടെറാഫോമിലേക്ക് മാറ്റുകയാണെങ്കിൽ, നിങ്ങൾ പഴയ ഉറവിടം ഇല്ലാതാക്കി പുതിയൊരെണ്ണം ചേർത്തതുപോലെ ദൃശ്യമാകും. നിങ്ങൾ ഈ മാറ്റങ്ങൾ പ്രയോഗിക്കുകയാണെങ്കിൽ, നിങ്ങളുടെ സെർവറുകൾ ഏതെങ്കിലും നെറ്റ്‌വർക്ക് ട്രാഫിക്കിനെ നിരസിക്കാൻ തുടങ്ങുമ്പോൾ ടെറാഫോം പഴയ സുരക്ഷാ ഗ്രൂപ്പ് ഇല്ലാതാക്കുകയും പുതിയൊരെണ്ണം സൃഷ്ടിക്കുകയും ചെയ്യും.

  ഈ ചർച്ചയിൽ നിന്ന് നിങ്ങൾ എടുക്കേണ്ട നാല് പ്രധാന പാഠങ്ങൾ ഇതാ.

  • എപ്പോഴും പ്ലാൻ കമാൻഡ് ഉപയോഗിക്കുക. ഇതിന് ഈ കുരുക്കുകളെല്ലാം വെളിപ്പെടുത്താനാകും. അതിന്റെ ഔട്ട്‌പുട്ട് ശ്രദ്ധാപൂർവം അവലോകനം ചെയ്യുക, മിക്കവാറും ഇല്ലാതാക്കാൻ പാടില്ലാത്ത വിഭവങ്ങൾ ഇല്ലാതാക്കാൻ Terraform പദ്ധതിയിടുന്ന സാഹചര്യങ്ങൾ ശ്രദ്ധിക്കുക.
  • ഇല്ലാതാക്കുന്നതിന് മുമ്പ് സൃഷ്ടിക്കുക. നിങ്ങൾക്ക് ഒരു റിസോഴ്‌സ് മാറ്റിസ്ഥാപിക്കണമെങ്കിൽ, ഒറിജിനൽ ഇല്ലാതാക്കുന്നതിന് മുമ്പ് ഒരു പകരം വയ്ക്കേണ്ടതുണ്ടോ എന്ന് ശ്രദ്ധാപൂർവ്വം ചിന്തിക്കുക. ഉത്തരം അതെ എന്നാണെങ്കിൽ, create_before_destroy-ന് സഹായിക്കാനാകും. രണ്ട് ഘട്ടങ്ങൾ ചെയ്യുന്നതിലൂടെ ഒരേ ഫലം സ്വമേധയാ നേടാനാകും: ആദ്യം കോൺഫിഗറേഷനിലേക്ക് ഒരു പുതിയ റിസോഴ്സ് ചേർത്ത് പ്രയോഗിക്കുക കമാൻഡ് പ്രവർത്തിപ്പിക്കുക, തുടർന്ന് കോൺഫിഗറേഷനിൽ നിന്ന് പഴയ റിസോഴ്സ് നീക്കം ചെയ്ത് പ്രയോഗിക്കുക കമാൻഡ് വീണ്ടും ഉപയോഗിക്കുക.
  • ഐഡന്റിഫയറുകൾ മാറ്റുന്നതിന് അവസ്ഥ മാറ്റേണ്ടതുണ്ട്. ഒരു റിസോഴ്‌സുമായി ബന്ധപ്പെട്ട ഐഡി മാറ്റണമെങ്കിൽ (ഉദാഹരണത്തിന്, aws_security_group-നെ ഉദാഹരണത്തിൽ നിന്ന് cluster_instance എന്നതിലേക്ക് പുനർനാമകരണം ചെയ്യുക) റിസോഴ്‌സ് ഇല്ലാതാക്കാതെ അതിന്റെ ഒരു പുതിയ പതിപ്പ് സൃഷ്‌ടിക്കുക, അതിനനുസരിച്ച് നിങ്ങൾ Terraform സ്റ്റേറ്റ് ഫയൽ അപ്‌ഡേറ്റ് ചെയ്യണം. ഇത് ഒരിക്കലും സ്വമേധയാ ചെയ്യരുത് - പകരം ടെറാഫോം സ്റ്റേറ്റ് കമാൻഡ് ഉപയോഗിക്കുക. ഐഡന്റിഫയറുകൾ പുനർനാമകരണം ചെയ്യുമ്പോൾ, നിങ്ങൾ ടെറാഫോം സ്റ്റേറ്റ് 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

    aws_security_group.instance-മായി മുമ്പ് ബന്ധപ്പെടുത്തിയിരുന്ന സംസ്ഥാനം ഇപ്പോൾ aws_security_group.cluster_instance-മായി ബന്ധപ്പെടുത്തണമെന്ന് ഇത് Terraform-നോട് പറയുന്നു. ഈ കമാൻഡ് ടെറാഫോം പ്ലാൻ പുനർനാമകരണം ചെയ്ത് പ്രവർത്തിപ്പിച്ചതിന് ശേഷം മാറ്റങ്ങളൊന്നും കാണിക്കുന്നില്ലെങ്കിൽ, നിങ്ങൾ എല്ലാം ശരിയായി ചെയ്തു.

  • ചില ക്രമീകരണങ്ങൾ മാറ്റാൻ കഴിയില്ല. പല വിഭവങ്ങളുടെയും പാരാമീറ്ററുകൾ മാറ്റാനാവില്ല. നിങ്ങൾ അവ മാറ്റാൻ ശ്രമിക്കുകയാണെങ്കിൽ, ടെറാഫോം പഴയ ഉറവിടം ഇല്ലാതാക്കുകയും അതിന്റെ സ്ഥാനത്ത് പുതിയൊരെണ്ണം സൃഷ്ടിക്കുകയും ചെയ്യും. നിങ്ങൾ ഒരു പ്രത്യേക ക്രമീകരണം മാറ്റുമ്പോൾ എന്താണ് സംഭവിക്കുന്നതെന്ന് ഓരോ റിസോഴ്‌സ് പേജും സാധാരണയായി സൂചിപ്പിക്കും, അതിനാൽ ഡോക്യുമെന്റേഷൻ പരിശോധിക്കുന്നത് ഉറപ്പാക്കുക. എപ്പോഴും പ്ലാൻ കമാൻഡ് ഉപയോഗിക്കുകയും create_before_destroy സ്ട്രാറ്റജി ഉപയോഗിക്കുന്നത് പരിഗണിക്കുകയും ചെയ്യുക.

  മാറ്റിവെച്ച സ്ഥിരത സ്ഥിരതയുള്ളതാണ്... മാറ്റിവയ്ക്കലിനൊപ്പം

  AWS പോലുള്ള ചില ക്ലൗഡ് ദാതാക്കളുടെ API-കൾ അസമന്വിതവും കാലതാമസമുള്ള സ്ഥിരതയുമാണ്. അഭ്യർത്ഥിച്ച പ്രവർത്തനം പൂർത്തിയാകുന്നതുവരെ കാത്തിരിക്കാതെ ഇന്റർഫേസിന് ഉടനടി ഒരു പ്രതികരണം നൽകാമെന്നാണ് അസിൻക്രണി അർത്ഥമാക്കുന്നത്. കാലതാമസമുള്ള സ്ഥിരത അർത്ഥമാക്കുന്നത് മാറ്റങ്ങൾ സിസ്റ്റത്തിലുടനീളം പ്രചരിപ്പിക്കാൻ സമയമെടുത്തേക്കാം എന്നാണ്; ഇത് സംഭവിക്കുമ്പോൾ, നിങ്ങളുടെ പ്രതികരണങ്ങൾ പൊരുത്തമില്ലാത്തതും നിങ്ങളുടെ API കോളുകളോട് ഏത് ഡാറ്റാ ഉറവിട പകർപ്പാണ് പ്രതികരിക്കുന്നത് എന്നതിനെ ആശ്രയിച്ചിരിക്കും.

  ഉദാഹരണത്തിന്, ഒരു EC2 സെർവർ സൃഷ്ടിക്കാൻ നിങ്ങൾ AWS-ലേക്ക് ഒരു API കോൾ ചെയ്യുന്നുവെന്ന് സങ്കൽപ്പിക്കുക. സെർവർ തന്നെ സൃഷ്‌ടിക്കുന്നതുവരെ കാത്തിരിക്കാതെ, എപിഐ ഒരു “വിജയകരമായ” പ്രതികരണം (201 സൃഷ്‌ടിച്ചത്) ഏതാണ്ട് തൽക്ഷണം നൽകും. നിങ്ങൾ ഉടൻ തന്നെ ഇതിലേക്ക് കണക്റ്റുചെയ്യാൻ ശ്രമിക്കുകയാണെങ്കിൽ, അത് മിക്കവാറും പരാജയപ്പെടും, കാരണം ആ സമയത്ത് AWS ഇപ്പോഴും ഉറവിടങ്ങൾ ആരംഭിക്കുന്നു അല്ലെങ്കിൽ, സെർവർ ഇതുവരെ ബൂട്ട് ചെയ്തിട്ടില്ല. മാത്രമല്ല, ഈ സെർവറിനെക്കുറിച്ചുള്ള വിവരങ്ങൾ ലഭിക്കുന്നതിന് നിങ്ങൾ മറ്റൊരു കോൾ ചെയ്യുകയാണെങ്കിൽ, നിങ്ങൾക്ക് ഒരു പിശക് ലഭിച്ചേക്കാം (404 കണ്ടെത്തിയില്ല). ഈ EC2 സെർവറിനെക്കുറിച്ചുള്ള വിവരങ്ങൾ എല്ലായിടത്തും ലഭ്യമാകുന്നതിന് മുമ്പ് AWS-ൽ ഉടനീളം പ്രചരിപ്പിച്ചേക്കാം, നിങ്ങൾ കുറച്ച് നിമിഷങ്ങൾ കാത്തിരിക്കേണ്ടിവരും.

  നിങ്ങൾ അലസമായ സ്ഥിരതയുള്ള ഒരു അസിൻക്രണസ് API ഉപയോഗിക്കുമ്പോഴെല്ലാം, പ്രവർത്തനം പൂർത്തിയാകുന്നതുവരെ നിങ്ങളുടെ അഭ്യർത്ഥന ഇടയ്‌ക്കിടെ വീണ്ടും ശ്രമിക്കേണ്ടതുണ്ട്. നിർഭാഗ്യവശാൽ, AWS SDK ഇതിനുള്ള നല്ല ടൂളുകളൊന്നും നൽകുന്നില്ല, കൂടാതെ ടെറാഫോം പ്രോജക്റ്റ് 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

  മറ്റൊരു വിധത്തിൽ പറഞ്ഞാൽ, നിങ്ങൾ ഒരു റിസോഴ്‌സ് സൃഷ്‌ടിക്കുകയും (ഒരു സബ്‌നെറ്റ് പോലെ) അതിനെക്കുറിച്ചുള്ള ചില വിവരങ്ങൾ (പുതുതായി സൃഷ്‌ടിച്ച സബ്‌നെറ്റിന്റെ ഐഡി പോലെ) നേടാൻ ശ്രമിക്കുകയും ചെയ്യുന്നു, ടെറാഫോമിന് അത് കണ്ടെത്താനായില്ല. ഈ ബഗുകളിൽ ഭൂരിഭാഗവും (6813 ഉൾപ്പെടെ) പരിഹരിച്ചിരിക്കുന്നു, പക്ഷേ അവ കാലാകാലങ്ങളിൽ ക്രോപ്പ് അപ്പ് ചെയ്യുന്നു, പ്രത്യേകിച്ചും ടെറാഫോം ഒരു പുതിയ റിസോഴ്സ് തരത്തിന് പിന്തുണ ചേർക്കുമ്പോൾ. ഇത് അരോചകമാണ്, പക്ഷേ മിക്ക കേസുകളിലും ഒരു ദോഷവും വരുത്തുന്നില്ല. നിങ്ങൾ ടെറാഫോം പ്രയോഗിക്കുമ്പോൾ വീണ്ടും പ്രവർത്തിപ്പിക്കുമ്പോൾ, എല്ലാം പ്രവർത്തിക്കും, കാരണം ഈ സമയം വിവരങ്ങൾ ഇതിനകം തന്നെ സിസ്റ്റത്തിലുടനീളം വ്യാപിച്ചിരിക്കും.

  Evgeniy Brikman എന്ന പുസ്തകത്തിൽ നിന്നാണ് ഈ ഉദ്ധരണി അവതരിപ്പിക്കുന്നത് "ടെറാഫോം: കോഡ് തലത്തിലുള്ള അടിസ്ഥാന സൗകര്യം".

അവലംബം: www.habr.com