టెర్రాఫార్మ్ ఆపదలు

లూప్‌లకు సంబంధించిన వాటితో సహా కొన్ని ఆపదలను హైలైట్ చేద్దాం, అయితే స్టేట్‌మెంట్‌లు మరియు డిప్లాయ్‌మెంట్ టెక్నిక్‌లు, అలాగే సాధారణంగా Terraformని ప్రభావితం చేసే మరిన్ని సాధారణ సమస్యలు:

• కౌంట్ మరియు for_each పారామితులు పరిమితులను కలిగి ఉంటాయి;
• సున్నా డౌన్‌టైమ్ విస్తరణలను పరిమితం చేయండి;
• మంచి ప్రణాళిక కూడా విఫలమవుతుంది;
• రీఫ్యాక్టరింగ్ దాని ఆపదలను కలిగి ఉంటుంది;
• వాయిదా వేసిన పొందిక స్థిరంగా ఉంటుంది... వాయిదాతో.

కౌంట్ మరియు for_each పారామీటర్‌లకు పరిమితులు ఉన్నాయి

ఈ అధ్యాయంలోని ఉదాహరణలు లూప్‌లు మరియు షరతులతో కూడిన తర్కంలో కౌంట్ పారామీటర్ మరియు for_each వ్యక్తీకరణను విస్తృతంగా ఉపయోగించుకుంటాయి. వారు బాగా పని చేస్తారు, కానీ మీరు తెలుసుకోవలసిన రెండు ముఖ్యమైన పరిమితులు ఉన్నాయి.

• కౌంట్ మరియు for_each ఏ రిసోర్స్ అవుట్‌పుట్ వేరియబుల్స్‌ను సూచించలేవు.
• కౌంట్ మరియు 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" {}

ఈ కోడ్ కూడా బాగా పని చేస్తుంది, ఎందుకంటే కౌంట్ పరామితి ఎటువంటి సమస్యలు లేకుండా డేటా మూలాలను సూచించగలదు. మీరు సృష్టించాల్సిన సర్వర్‌ల సంఖ్య కొన్ని వనరుల అవుట్‌పుట్‌పై ఆధారపడి ఉంటే ఏమి జరుగుతుంది? దీనిని ప్రదర్శించడానికి, ర్యాండమ్_పూర్ణాంక వనరును ఉపయోగించడం సులభమయిన మార్గం, ఇది పేరు సూచించినట్లుగా, యాదృచ్ఛిక పూర్ణాంకాన్ని అందిస్తుంది:

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.

టెర్రాఫార్మ్‌కు ఏదైనా వనరులు సృష్టించబడటానికి లేదా సవరించబడటానికి ముందు, ప్రణాళికా దశలో గణన మరియు for_each అవసరం. దీనర్థం, కౌంట్ మరియు 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.

దురదృష్టవశాత్తూ, 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 వినియోగదారులకు మాత్రమే కాకుండా, దాదాపు ఏ వనరుకైనా జరగవచ్చు. ఎవరైనా ఈ వనరును మాన్యువల్‌గా లేదా కమాండ్ లైన్ ఉపయోగించి సృష్టించి ఉండవచ్చు, కానీ ఏ విధంగా అయినా, IDలను సరిపోల్చడం వైరుధ్యాలకు దారి తీస్తుంది. ఈ లోపం యొక్క అనేక వైవిధ్యాలు ఉన్నాయి, ఇవి తరచుగా టెర్రాఫార్మ్‌కు కొత్తవారిని ఆశ్చర్యానికి గురిచేస్తాయి.

ప్రధాన విషయం ఏమిటంటే టెరాఫార్మ్ ప్లాన్ కమాండ్ టెర్రాఫార్మ్ స్టేట్ ఫైల్‌లో పేర్కొన్న వనరులను మాత్రమే పరిగణనలోకి తీసుకుంటుంది. వనరులు వేరే విధంగా సృష్టించబడితే (ఉదాహరణకు, AWS కన్సోల్‌లో మాన్యువల్‌గా క్లిక్ చేయడం ద్వారా), అవి స్టేట్ ఫైల్‌లో ముగియవు మరియు ప్లాన్ కమాండ్‌ను అమలు చేస్తున్నప్పుడు Terraform వాటిని పరిగణనలోకి తీసుకోదు. ఫలితంగా, మొదటి చూపులో సరైనది అనిపించే ప్రణాళిక విజయవంతం కాదు.

ఇందులో రెండు పాఠాలు నేర్చుకోవాలి.

• మీరు ఇప్పటికే టెర్రాఫార్మ్‌తో పని చేయడం ప్రారంభించినట్లయితే, మరేదైనా ఉపయోగించవద్దు. మీ ఇన్‌ఫ్రాస్ట్రక్చర్‌లో కొంత భాగాన్ని Terraform ఉపయోగించి నిర్వహించినట్లయితే, మీరు ఇకపై దానిని మాన్యువల్‌గా సవరించలేరు. లేకపోతే, మీరు విచిత్రమైన టెర్రాఫార్మ్ ఎర్రర్‌లను మాత్రమే కాకుండా, IaC యొక్క అనేక ప్రయోజనాలను కూడా మీరు తిరస్కరించారు, ఎందుకంటే కోడ్ ఇకపై మీ మౌలిక సదుపాయాల యొక్క ఖచ్చితమైన ప్రాతినిధ్యంగా ఉండదు.
• మీకు ఇప్పటికే కొన్ని మౌలిక సదుపాయాలు ఉంటే, దిగుమతి ఆదేశాన్ని ఉపయోగించండి. మీరు ఇప్పటికే ఉన్న ఇన్‌ఫ్రాస్ట్రక్చర్‌తో టెర్రాఫార్మ్‌ని ఉపయోగించడం ప్రారంభించినట్లయితే, టెరాఫార్మ్ దిగుమతి ఆదేశాన్ని ఉపయోగించి మీరు దానిని స్టేట్ ఫైల్‌కు జోడించవచ్చు. ఈ విధంగా టెర్రాఫార్మ్ ఎలాంటి మౌలిక సదుపాయాలను నిర్వహించాలో తెలుసుకుంటుంది. దిగుమతి ఆదేశం రెండు వాదనలను తీసుకుంటుంది. మొదటిది మీ కాన్ఫిగరేషన్ ఫైల్‌లలోని వనరు చిరునామా. ఇక్కడ సింటాక్స్ రిసోర్స్ లింక్‌ల మాదిరిగానే ఉంటుంది: _. (aws_iam_user.existing_user లాగా). రెండవ వాదన దిగుమతి చేయవలసిన వనరు యొక్క ID. వనరు ID aws_iam_user అనేది వినియోగదారు పేరు (ఉదాహరణకు, yevgeniy.brikman), మరియు వనరు ID aws_instance అనేది EC2 సర్వర్ ID (i-190e22e5 వంటిది) అని చెప్పండి. వనరును ఎలా దిగుమతి చేయాలో సాధారణంగా దాని పేజీ దిగువన ఉన్న డాక్యుమెంటేషన్‌లో సూచించబడుతుంది.

  చాప్టర్ 2లోని IAM యూజర్‌తో పాటు మీరు మీ టెర్రాఫార్మ్ కాన్ఫిగరేషన్‌కు జోడించిన aws_iam_user వనరును సమకాలీకరించే దిగుమతి కమాండ్ క్రింద ఉంది (వాస్తవానికి, yevgeniy.brikman కోసం మీ పేరును భర్తీ చేస్తుంది):

  $ terraform import aws_iam_user.existing_user yevgeniy.brikman

  Terraform మీ IAM వినియోగదారుని కనుగొనడానికి AWS APIకి కాల్ చేస్తుంది మరియు మీ Terraform కాన్ఫిగరేషన్‌లోని aws_iam_user.existing_user వనరుకి మధ్య స్టేట్ ఫైల్ అనుబంధాన్ని సృష్టిస్తుంది. ఇప్పటి నుండి, మీరు ప్లాన్ కమాండ్‌ను అమలు చేసినప్పుడు, IAM వినియోగదారు ఇప్పటికే ఉన్నారని మరియు దానిని మళ్లీ సృష్టించడానికి ప్రయత్నించరని Terraform తెలుసుకుంటుంది.

  మీరు ఇప్పటికే టెర్రాఫార్మ్‌లోకి దిగుమతి చేసుకోవాలనుకునే చాలా వనరులు మీ వద్ద ఉంటే, మాన్యువల్‌గా కోడ్‌ను వ్రాయడం మరియు ఒక్కొక్కటిగా దిగుమతి చేసుకోవడం ఇబ్బందిగా ఉంటుందని గమనించాలి. కాబట్టి మీ AWS ఖాతా నుండి స్వయంచాలకంగా కోడ్ మరియు స్థితిని దిగుమతి చేసుకోగల Terraforming (http://terraforming.dtan4.net/) వంటి సాధనాన్ని పరిశీలించడం విలువైనదే.

  రీఫ్యాక్టరింగ్ దాని ఆపదలను కలిగి ఉంటుంది

  రీఫ్యాక్టరింగ్ ప్రోగ్రామింగ్‌లో మీరు బాహ్య ప్రవర్తనను మార్చకుండానే కోడ్ యొక్క అంతర్గత నిర్మాణాన్ని మార్చే సాధారణ పద్ధతి. ఇది కోడ్‌ను స్పష్టంగా, చక్కగా మరియు సులభంగా నిర్వహించేలా చేయడం. రీఫ్యాక్టరింగ్ అనేది ఒక అనివార్యమైన సాంకేతికత, దీనిని క్రమం తప్పకుండా ఉపయోగించాలి. కానీ Terraform లేదా మరేదైనా IaC సాధనం విషయానికి వస్తే, మీరు కోడ్ ముక్క యొక్క "బాహ్య ప్రవర్తన" అంటే ఏమిటో చాలా జాగ్రత్తగా ఉండాలి, లేకుంటే ఊహించని సమస్యలు తలెత్తుతాయి.

  ఉదాహరణకు, ఒక సాధారణ రకం రీఫ్యాక్టరింగ్ అనేది వేరియబుల్స్ లేదా ఫంక్షన్‌ల పేర్లను మరింత అర్థమయ్యే వాటితో భర్తీ చేయడం. అనేక IDEలు రీఫ్యాక్టరింగ్ కోసం అంతర్నిర్మిత మద్దతును కలిగి ఉన్నాయి మరియు ప్రాజెక్ట్ అంతటా వేరియబుల్స్ మరియు ఫంక్షన్‌లను స్వయంచాలకంగా పేరు మార్చవచ్చు. సాధారణ-ప్రయోజన ప్రోగ్రామింగ్ భాషలలో, ఇది మీరు ఆలోచించని పనికిమాలిన ప్రక్రియ, కానీ టెర్రాఫార్మ్‌లో మీరు దీనితో చాలా జాగ్రత్తగా ఉండాలి, లేకుంటే మీరు అంతరాయాలను అనుభవించవచ్చు.

  ఉదాహరణకు, వెబ్‌సర్వర్-క్లస్టర్ మాడ్యూల్ ఇన్‌పుట్ వేరియబుల్ 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]
  }

  మీరు రిసోర్స్‌లో పేరు పరామితిని మార్చినట్లయితే, Terraform ఆ వనరు యొక్క పాత సంస్కరణను తొలగిస్తుంది మరియు దాని స్థానంలో కొత్తదాన్ని సృష్టిస్తుంది. కానీ ఆ వనరు ALB అయితే, దాన్ని తొలగించడం మరియు కొత్త వెర్షన్‌ని డౌన్‌లోడ్ చేయడం మధ్య, మీ వెబ్ సర్వర్‌కి ట్రాఫిక్‌ను దారి మళ్లించే మెకానిజం మీకు ఉండదు. అలాగే, ఒక భద్రతా సమూహం తొలగించబడినట్లయితే, కొత్త సమూహం సృష్టించబడే వరకు మీ సర్వర్‌లు ఏదైనా నెట్‌వర్క్ ట్రాఫిక్‌ని తిరస్కరించడం ప్రారంభిస్తాయి.

  టెర్రాఫార్మ్ 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 ఎక్కువగా తొలగించకూడని వనరులను తొలగించాలని ప్లాన్ చేస్తున్న పరిస్థితులపై శ్రద్ధ వహించండి.
  • మీరు తొలగించే ముందు సృష్టించండి. మీరు రిసోర్స్‌ని రీప్లేస్ చేయాలనుకుంటే, ఒరిజినల్‌ని తొలగించే ముందు రీప్లేస్‌మెంట్‌ని సృష్టించాలా వద్దా అనే దాని గురించి జాగ్రత్తగా ఆలోచించండి. సమాధానం అవును అయితే, create_before_destroy సహాయం చేస్తుంది. అదే ఫలితాన్ని రెండు దశలను చేయడం ద్వారా మానవీయంగా సాధించవచ్చు: మొదట కాన్ఫిగరేషన్‌కు కొత్త వనరును జోడించి, వర్తించు ఆదేశాన్ని అమలు చేయండి, ఆపై కాన్ఫిగరేషన్ నుండి పాత వనరును తీసివేసి, మళ్లీ వర్తించు ఆదేశాన్ని ఉపయోగించండి.
  • ఐడెంటిఫైయర్‌లను మార్చడానికి స్థితిని మార్చడం అవసరం. మీరు రిసోర్స్‌తో అనుబంధించబడిన IDని మార్చాలనుకుంటే (ఉదాహరణకు, aws_security_group పేరును instance నుండి 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 కాల్ చేసినట్లు ఊహించుకోండి. 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తో సహా) పరిష్కరించబడ్డాయి, అయితే అవి ఇప్పటికీ ఎప్పటికప్పుడు క్రాప్ అవుతూ ఉంటాయి, ప్రత్యేకించి టెర్రాఫార్మ్ కొత్త రిసోర్స్ రకానికి మద్దతును జోడించినప్పుడు. ఇది బాధించేది, కానీ చాలా సందర్భాలలో ఎటువంటి హాని కలిగించదు. మీరు టెర్రాఫార్మ్ దరఖాస్తును మళ్లీ అమలు చేసినప్పుడు, ప్రతిదీ పని చేయాలి, ఎందుకంటే ఈ సమయానికి సమాచారం ఇప్పటికే సిస్టమ్ అంతటా వ్యాపించి ఉంటుంది.

  ఈ సారాంశం Evgeniy Brikman పుస్తకం నుండి అందించబడింది "టెర్రాఫార్మ్: కోడ్ స్థాయిలో మౌలిక సదుపాయాలు".

మూలం: www.habr.com