டெர்ராஃபார்ம் ஆபத்துகள்

அறிக்கைகள் மற்றும் வரிசைப்படுத்தல் நுட்பங்கள் மற்றும் பொதுவாக டெர்ராஃபார்மைப் பாதிக்கும் பொதுவான சிக்கல்கள், லூப்கள் தொடர்பானவை உட்பட சில சிக்கல்களை முன்னிலைப்படுத்துவோம்:

• எண்ணிக்கை மற்றும் for_each அளவுருக்கள் வரம்புகளைக் கொண்டுள்ளன;
• பூஜ்ஜிய வேலையில்லா வரிசைப்படுத்தல்களை வரம்பிடவும்;
• ஒரு நல்ல திட்டம் கூட தோல்வியடையும்;
• மறுசீரமைப்பு அதன் ஆபத்துக்களைக் கொண்டிருக்கலாம்;
• ஒத்திவைக்கப்பட்ட ஒத்திசைவு நிலையானது... ஒத்திவைப்புடன்.

எண்ணிக்கை மற்றும் for_each அளவுருக்கள் வரம்புகளைக் கொண்டுள்ளன

இந்த அத்தியாயத்தில் உள்ள எடுத்துக்காட்டுகள் எண்ணிக்கை அளவுரு மற்றும் சுழல்கள் மற்றும் நிபந்தனை தர்க்கத்தில் for_each வெளிப்பாடு ஆகியவற்றை விரிவாகப் பயன்படுத்துகின்றன. அவர்கள் சிறப்பாக செயல்படுகிறார்கள், ஆனால் நீங்கள் அறிந்திருக்க வேண்டிய இரண்டு முக்கியமான வரம்புகள் உள்ளன.

• Count மற்றும் for_each எந்த ஆதார வெளியீட்டு மாறிகளையும் குறிப்பிட முடியாது.
• எண்ணிக்கை மற்றும் 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
}

இந்தக் குறியீடு 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.

எந்தவொரு ஆதாரமும் உருவாக்கப்படும் அல்லது மாற்றியமைக்கப்படுவதற்கு முன், திட்டமிடல் கட்டத்தில் கணக்கிடப்பட வேண்டும் மற்றும் foreach கணக்கிடப்பட வேண்டும் என்று Terraform தேவைப்படுகிறது. இதன் பொருள், எண்ணும் மற்றும் for_each என்பது எழுத்துக்கள், மாறிகள், தரவு மூலங்கள் மற்றும் ஆதாரப் பட்டியல்களைக் குறிக்கலாம் (அவற்றின் நீளத்தை திட்டமிடும் நேரத்தில் தீர்மானிக்கும் வரை), ஆனால் கணக்கிடப்பட்ட வள வெளியீட்டு மாறிகள் அல்ல.

எண்ணிக்கை மற்றும் 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.

துரதிர்ஷ்டவசமாக, டெர்ராஃபார்ம் 0.12.6 இன் படி, தொகுதி வளத்தில் எண்ணிக்கை அல்லது for_each ஐப் பயன்படுத்துவது ஆதரிக்கப்படவில்லை. Terraform 0.12 வெளியீட்டுக் குறிப்புகளின்படி (http://bit.ly/3257bv4), HashiCorp எதிர்காலத்தில் இந்தத் திறனைச் சேர்க்கத் திட்டமிட்டுள்ளது, எனவே நீங்கள் இந்தப் புத்தகத்தைப் படிக்கும் போது, ​​அது ஏற்கனவே கிடைக்கக்கூடும். உறுதியாக அறிய, Terraform சேஞ்ச்லாக்கை இங்கே படிக்கவும்.

ஜீரோ டவுன்டைம் வரிசைப்படுத்தல்களின் வரம்புகள்

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 ஒரு நியாயமான வரிசைப்படுத்தல் திட்டத்தை வெளியிடும்:

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 அவற்றை கணக்கில் எடுத்துக்கொள்ளாது. இதன் விளைவாக, முதல் பார்வையில் சரியானதாகத் தோன்றும் ஒரு திட்டம் தோல்வியடையும்.

இதிலிருந்து கற்றுக் கொள்ள வேண்டிய பாடங்கள் இரண்டு உள்ளன.

• நீங்கள் ஏற்கனவே Terraform உடன் பணிபுரிய ஆரம்பித்திருந்தால், வேறு எதையும் பயன்படுத்த வேண்டாம். உங்கள் உள்கட்டமைப்பின் ஒரு பகுதி 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 API ஐ அழைக்கும் மற்றும் அதற்கும் உங்கள் Terraform உள்ளமைவில் உள்ள aws_iam_user.existing_user ஆதாரத்திற்கும் இடையே ஒரு மாநில கோப்பு தொடர்பை உருவாக்கும். இனிமேல், நீங்கள் திட்ட கட்டளையை இயக்கும் போது, ​​IAM பயனர் ஏற்கனவே இருப்பதை டெர்ராஃபார்ம் அறியும், மேலும் அதை மீண்டும் உருவாக்க முயற்சிக்க மாட்டீர்கள்.

  நீங்கள் ஏற்கனவே டெர்ராஃபார்மில் இறக்குமதி செய்ய விரும்பும் ஏராளமான ஆதாரங்கள் உங்களிடம் இருந்தால், குறியீட்டை கைமுறையாக எழுதி, ஒவ்வொன்றையும் ஒரே நேரத்தில் இறக்குமதி செய்வது ஒரு தொந்தரவாக இருக்கும் என்பது குறிப்பிடத்தக்கது. எனவே டெர்ராஃபார்மிங் (http://terraforming.dtan4.net/) போன்ற ஒரு கருவியைப் பார்ப்பது மதிப்புக்குரியது, இது உங்கள் AWS கணக்கிலிருந்து தானாகவே குறியீடு மற்றும் நிலையை இறக்குமதி செய்யலாம்.

  மறுசீரமைப்பு அதன் ஆபத்துக்களைக் கொண்டிருக்கலாம்

  மறுசீரமைப்பு நிரலாக்கத்தில் ஒரு பொதுவான நடைமுறையாகும், இதில் வெளிப்புற நடத்தை மாறாமல் இருக்கும் போது குறியீட்டின் உள் கட்டமைப்பை மாற்றுவீர்கள். இது குறியீட்டை தெளிவாகவும், சுத்தமாகவும், எளிதாகவும் பராமரிக்க வேண்டும். மறுசீரமைப்பு என்பது ஒரு தவிர்க்க முடியாத நுட்பமாகும், இது தொடர்ந்து பயன்படுத்தப்பட வேண்டும். ஆனால் Terraform அல்லது வேறு ஏதேனும் IaC கருவிக்கு வரும்போது, ​​குறியீட்டின் ஒரு பகுதியின் "வெளிப்புற நடத்தை" என்பதன் மூலம் நீங்கள் எதைக் குறிப்பிடுகிறீர்கள் என்பதில் மிகவும் கவனமாக இருக்க வேண்டும், இல்லையெனில் எதிர்பாராத சிக்கல்கள் எழும்.

  எடுத்துக்காட்டாக, ஒரு பொதுவான வகை மறுசீரமைப்பு என்பது மாறிகள் அல்லது செயல்பாடுகளின் பெயர்களை மிகவும் புரிந்துகொள்ளக்கூடியவற்றுடன் மாற்றுவதாகும். பல IDEகள் மறுசீரமைப்பிற்கான உள்ளமைக்கப்பட்ட ஆதரவைக் கொண்டுள்ளன, மேலும் திட்டம் முழுவதும் மாறிகள் மற்றும் செயல்பாடுகளை தானாக மறுபெயரிடலாம். பொது-நோக்க நிரலாக்க மொழிகளில், இது நீங்கள் சிந்திக்காத ஒரு அற்பமான செயல்முறையாகும், ஆனால் டெர்ராஃபார்மில் நீங்கள் மிகவும் கவனமாக இருக்க வேண்டும், இல்லையெனில் நீங்கள் செயலிழப்புகளை சந்திக்க நேரிடும்.

  எடுத்துக்காட்டாக, webserver-cluster module ஆனது உள்ளீடு மாறி 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 ஆக இருந்தால், அதை நீக்குவதற்கும் புதிய பதிப்பைப் பதிவிறக்குவதற்கும் இடையில், உங்கள் வலை சேவையகத்திற்கு ட்ராஃபிக்கைத் திருப்பிவிடுவதற்கான வழிமுறை உங்களிடம் இருக்காது. அதேபோல, ஒரு பாதுகாப்புக் குழு நீக்கப்பட்டால், புதிய குழு உருவாக்கப்படும் வரை உங்கள் சர்வர்கள் எந்த நெட்வொர்க் டிராஃபிக்கை நிராகரிக்கத் தொடங்கும்.

  டெர்ராஃபார்ம் ஐடியை மாற்றுவது உங்களுக்கு ஆர்வமாக இருக்கும் மற்றொரு வகை மறுசீரமைப்பு. webserver-cluster தொகுதியில் உள்ள 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 ஐ instance என்பதிலிருந்து cluster_instance என மறுபெயரிடவும்) ஆதாரத்தை நீக்கி அதன் புதிய பதிப்பை உருவாக்காமல், அதற்கேற்ப Terraform நிலை கோப்பை புதுப்பிக்க வேண்டும். இதை ஒருபோதும் கைமுறையாக செய்ய வேண்டாம் - அதற்கு பதிலாக டெராஃபார்ம் மாநில கட்டளையைப் பயன்படுத்தவும். அடையாளங்காட்டிகளை மறுபெயரிடும்போது, ​​​​நீங்கள் டெராஃபார்ம் ஸ்டேட் எம்வி கட்டளையை இயக்க வேண்டும், அதில் பின்வரும் தொடரியல் உள்ளது:

    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 உடன் இணைக்கப்பட வேண்டும் என்று டெர்ராஃபார்மிடம் இது கூறுகிறது. இந்த கட்டளையை மறுபெயரிட்டு இயக்கிய பிறகு டெராஃபார்ம் திட்டம் எந்த மாற்றத்தையும் காட்டவில்லை என்றால், நீங்கள் எல்லாவற்றையும் சரியாகச் செய்தீர்கள்.

  • சில அமைப்புகளை மாற்ற முடியாது. பல வளங்களின் அளவுருக்கள் மாற்ற முடியாதவை. நீங்கள் அவற்றை மாற்ற முயற்சித்தால், டெர்ராஃபார்ம் பழைய ஆதாரத்தை நீக்கி, அதன் இடத்தில் புதிய ஒன்றை உருவாக்கும். ஒவ்வொரு ஆதாரப் பக்கமும் ஒரு குறிப்பிட்ட அமைப்பை மாற்றும்போது என்ன நடக்கும் என்பதைக் குறிக்கும், எனவே ஆவணங்களைச் சரிபார்க்கவும். எப்போதும் திட்ட கட்டளையைப் பயன்படுத்தவும் மற்றும் create_before_destroy உத்தியைப் பயன்படுத்தவும்.

  ஒத்திவைக்கப்பட்ட நிலைத்தன்மை சீரானது... ஒத்திவைப்புடன்

  AWS போன்ற சில கிளவுட் வழங்குநர்களின் APIகள் ஒத்திசைவற்றவை மற்றும் தாமதமான நிலைத்தன்மையைக் கொண்டுள்ளன. ஒத்திசைவு என்பது, கோரப்பட்ட செயல் முடிவடையும் வரை காத்திருக்காமல், இடைமுகம் உடனடியாக ஒரு பதிலை அளிக்கும். தாமதமான நிலைத்தன்மை என்பது கணினி முழுவதும் பரவுவதற்கு மாற்றங்கள் நேரத்தை எடுத்துக்கொள்ளலாம்; இது நிகழும் போது, ​​உங்கள் பதில்கள் சீரற்றதாக இருக்கலாம் மற்றும் உங்கள் 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

  வேறு வார்த்தைகளில் கூறுவதானால், நீங்கள் ஒரு ஆதாரத்தை (சப்நெட் போன்றது) உருவாக்கி, அதைப் பற்றிய சில தகவல்களைப் பெற முயற்சிக்கிறீர்கள் (புதிதாக உருவாக்கப்பட்ட சப்நெட்டின் ஐடி போன்றவை), மற்றும் Terraform அதைக் கண்டுபிடிக்க முடியவில்லை. இந்த பிழைகளில் பெரும்பாலானவை (6813 உட்பட) சரி செய்யப்பட்டுள்ளன, ஆனால் அவை அவ்வப்போது வளரும், குறிப்பாக டெர்ராஃபார்ம் புதிய ஆதார வகைக்கான ஆதரவைச் சேர்க்கும் போது. இது எரிச்சலூட்டும், ஆனால் பெரும்பாலான சந்தர்ப்பங்களில் எந்தத் தீங்கும் ஏற்படாது. நீங்கள் டெராஃபார்மை மீண்டும் இயக்கும்போது, ​​​​எல்லாம் வேலை செய்ய வேண்டும், ஏனெனில் இந்த நேரத்தில் தகவல் ஏற்கனவே கணினி முழுவதும் பரவியிருக்கும்.

  இந்த பகுதி Evgeniy Brikman புத்தகத்தில் இருந்து வழங்கப்படுகிறது "டெர்ராஃபார்ம்: குறியீடு மட்டத்தில் உள்கட்டமைப்பு".

ஆதாரம்: www.habr.com