የቴራፎርም ወጥመዶች

ከ loops ጋር የተያያዙትን፣ መግለጫዎችን እና የማሰማራት ቴክኒኮችን እንዲሁም በአጠቃላይ Terraformን የሚነኩ አጠቃላይ ጉዳዮችን ጨምሮ ጥቂት ወጥመዶችን እናሳይ።

• ቆጠራው እና ለ_እያንዳንዱ ግቤቶች ገደቦች አሏቸው;
• ዜሮ የእረፍት ጊዜ ማሰማራቶችን ይገድቡ;
• ጥሩ እቅድ እንኳን ሊሳካ ይችላል;
• refactoring የራሱ ወጥመዶች ሊኖረው ይችላል;
• የዘገየ ትስስር ወጥነት ያለው ነው... ከማዘግየት ጋር።

ቆጠራው እና ለእያንዳንዱ_መመዘኛዎች ገደቦች አሏቸው

በዚህ ምዕራፍ ውስጥ ያሉት ምሳሌዎች የቁጥር መለኪያውን እና የእያንዳንዱን አገላለጽ በ loops እና ሁኔታዊ አመክንዮዎች በስፋት ይጠቀማሉ። እነሱ ጥሩ አፈፃፀም አላቸው ፣ ግን ማወቅ ያለብዎት ሁለት አስፈላጊ ገደቦች አሏቸው።

• ቆጠራ እና ለ_እያንዳንዱ ማንኛውንም የንብረት ውፅዓት ተለዋዋጮችን መጥቀስ አይችልም።
• ቆጠራ እና ለ_እያንዳንዱ በሞጁል ውቅር ውስጥ መጠቀም አይቻልም።

ቆጠራ እና ለ_እያንዳንዱ ማንኛውንም የንብረት ውፅዓት ተለዋዋጮችን መጥቀስ አይችልም።

ብዙ EC2 አገልጋዮችን ማሰማራት እንዳለቦት እና በሆነ ምክንያት ASG መጠቀም እንደማይፈልጉ አስቡት። የእርስዎ ኮድ እንደዚህ ሊሆን ይችላል፡-

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

እስቲ አንድ በአንድ እንያቸው።

የቁጥር መለኪያው ወደ የማይንቀሳቀስ እሴት የተቀናበረ በመሆኑ ይህ ኮድ ያለምንም ችግር ይሰራል፡ የአፕሊኬሽን ትዕዛዙን ሲያሄዱ ሶስት የEC2 አገልጋዮችን ይፈጥራል። ግን አሁን ባለህበት የAWS ክልል ውስጥ በእያንዳንዱ የተገኝነት ዞን (AZ) አንድ አገልጋይ ማሰማራት ብትፈልግስ? ኮድዎን ከአውስ_availability_ዞኖች የውሂብ ምንጭ የዞኖች ዝርዝር እንዲጭን ማድረግ እና እያንዳንዱን መዞር እና የቁጥር መለኪያ እና የድርድር መረጃ ጠቋሚ መዳረሻን በመጠቀም የ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 መካከል ያለ የዘፈቀደ ቁጥር ያመነጫል። የዚህን ሃብት ውፅዓት በአውስ_ኢንስታንስ ሪሶርስ ቆጠራ መለኪያ ለመጠቀም ከሞከርን ምን እንደሚሆን እንይ፡-

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 ማንኛውም ግብዓት ከመፈጠሩ ወይም ከመቀየሩ በፊት በእቅድ ደረጃው ውስጥ እንዲቆጠር እና ለእያንዳንዱ_እያንዳንዱ እንዲሰላ ይፈልጋል። ይህ ማለት ቆጠራ እና ለ_እያንዳንዱ ቃል በቃል፣ ተለዋዋጮች፣ የውሂብ ምንጮች እና ሌላው ቀርቶ የንብረት ዝርዝሮችን ሊያመለክት ይችላል (ርዝመታቸው በጊዜ መርሐግብር ላይ እስካልተወሰነ ድረስ)፣ ነገር ግን የተሰላ የሀብት ውፅዓት ተለዋዋጮችን አይደለም።

ቆጠራ እና ለ_እያንዳንዱ በሞጁል ውቅር ውስጥ መጠቀም አይቻልም

አንድ ቀን ወደ ሞጁል ውቅርዎ የቁጥር መለኪያ ለመጨመር ሊፈተኑ ይችላሉ፡

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 ጀምሮ፣ በሞጁል ውስጥ ያለውን ቆጠራ ወይም ለእያንዳንዱ_እያንዳንዱን መጠቀም አይደገፍም። በቴራፎርም 0.12 የመልቀቂያ ማስታወሻዎች (http://bit.ly/3257bv4) መሠረት HashiCorp ይህንን ችሎታ ወደፊት ለመጨመር አቅዷል፣ ስለዚህ ይህን መጽሐፍ በሚያነቡበት ጊዜ ላይ በመመስረት፣ አስቀድሞ ሊገኝ ይችላል። በእርግጠኝነት ለማወቅ፣ የ Terraform changelog እዚህ ያንብቡ.

የዜሮ የእረፍት ጊዜ ማሰማራት ገደቦች

Create_before_destroy ብሎክን ከ ASG ጋር በማጣመር መጠቀም ዜሮ-ጊዜ ማሰማራቶችን ለመፍጠር ጥሩ መፍትሄ ነው፣ከአንድ ማስጠንቀቂያ በስተቀር፣የራስ-አመጣጥ ህጎች አይደገፉም። ወይም የበለጠ ትክክለኛ ለመሆን፣ ይህ በእያንዳንዱ ማሰማራቱ ላይ የ ASG መጠኑን ወደ min_size ይመልሰዋል፣ ይህም የሚሄዱትን የአገልጋዮች ብዛት ለመጨመር አውቶማቲክ ህጎችን እየተጠቀሙ ከሆነ ችግር ሊሆን ይችላል።

ለምሳሌ የዌብሰርቨር-ክላስተር ሞጁል ጥንድ aws_autoscaling_schedule መርጃዎችን ይዟል፣ይህም 9 am ላይ በክላስተር ውስጥ ያሉትን የአገልጋዮች ብዛት ከሁለት ወደ አስር ይጨምራል። ከጠዋቱ 11፡9 ላይ ካሰማራክ አዲሱ ASG ከአስር ይልቅ በሁለት አገልጋዮች ብቻ ይነሳና በሚቀጥለው ቀን እስከ XNUMX፡XNUMX ድረስ ይቆያል።

ይህ ገደብ በተለያዩ መንገዶች ሊታለፍ ይችላል።

• የድግግሞሹን ልኬት በ aws_autoscaling_schedule ከ 0 9 * * * ("በ9 am መሮጥ") ወደ እንደ 0-59 9-17 * * * ("በየደቂቃው ከጠዋቱ 9 am እስከ 5 pm ሩጡ") ይለውጡ። ASG ቀድሞውኑ አስር ሰርቨሮች ካሉት፣ ይህንን የራስ-ስኬል ህግን እንደገና ማስኬድ ምንም ነገር አይለውጥም፣ ይህም እኛ የምንፈልገው ነው። ነገር ግን ASG በቅርቡ ስራ ላይ ከዋለ፣ ይህ ህግ በከፍተኛ ደቂቃ ውስጥ የአገልጋዮቹ ቁጥር አስር መድረሱን ያረጋግጣል። ይህ ሙሉ ለሙሉ የሚያምር አካሄድ አይደለም፣ እና ከአስር ወደ ሁለት ሰርቨሮች እና ጀርባ ትልቅ ዝላይ በተጠቃሚዎች ላይ ችግር ይፈጥራል።
• በ ASG ውስጥ ያሉትን የነቁ አገልጋዮች ብዛት ለማወቅ የAWS APIን የሚጠቀም ብጁ ስክሪፕት ይፍጠሩ፣ የውጪ የውሂብ ምንጭ በመጠቀም ይደውሉ ("የውጭ የውሂብ ምንጭ" በገጽ 249 ይመልከቱ) እና የ ASG የሚፈልገውን_አቅም መለኪያ ወደ ተመለሰው እሴት ያዘጋጁ። ጽሁፉ. በዚህ መንገድ፣ እያንዳንዱ አዲስ ASG ምሳሌ ሁልጊዜ ካለው የቴራፎርም ኮድ ጋር በተመሳሳይ አቅም ይሰራል እና ለማቆየት የበለጠ አስቸጋሪ ያደርገዋል።

በእርግጥ ቴራፎርም ለዜሮ ጊዜ ማሽቆልቆል አብሮ የተሰራ ድጋፍ ይኖረዋል፣ ነገር ግን ከሜይ 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 ተጠቃሚዎች ላይ ብቻ ሳይሆን ለማንኛውም ምንጭ ማለት ይቻላል ሊከሰት ይችላል. አንድ ሰው ይህን ሃብት የፈጠረው ወይም የትእዛዝ መስመሩን በመጠቀም ሊሆን ይችላል፣ ነገር ግን በማንኛውም መንገድ፣ መታወቂያዎች መመሳሰል ወደ ግጭት ያመራል። ብዙ ጊዜ ወደ ቴራፎርም መጤዎችን የሚይዘው የዚህ ስህተት ብዙ ልዩነቶች አሉ።

ዋናው ነጥብ የቴራፎርም እቅድ ትዕዛዝ በ Terraform State ፋይል ውስጥ የተገለጹትን ሀብቶች ብቻ ግምት ውስጥ ያስገባል. ሃብቶች በሌላ መንገድ ከተፈጠሩ (ለምሳሌ, በእጅ በ AWS ኮንሶል ውስጥ ጠቅ በማድረግ), በስቴቱ ፋይል ውስጥ አይጠናቀቁም እና ስለዚህ Terraform የእቅዱን ትዕዛዝ ሲፈጽም ግምት ውስጥ አያስገባም. በውጤቱም, በአንደኛው እይታ ትክክል የሚመስለው እቅድ ወደ ስኬት ይቀየራል.

ከዚህ የምንማራቸው ሁለት ትምህርቶች አሉ።

• ከቴራፎርም ጋር መስራት ከጀመርክ ሌላ ምንም ነገር አትጠቀም። የመሠረተ ልማትዎ ክፍል ቴራፎርምን በመጠቀም የሚተዳደር ከሆነ፣ ከአሁን በኋላ በእጅ መቀየር አይችሉም። ያለበለዚያ፣ እርስዎ ለሚገርሙ የቴራፎርም ስህተቶች ብቻ ሳይሆን ኮዱ የመሠረተ ልማትዎን ትክክለኛ ውክልና ስለማይሆን ብዙ የIaC ጥቅሞችን ይክዳሉ።
• አንዳንድ መሠረተ ልማቶች ካሉዎት የማስመጣት ትዕዛዙን ይጠቀሙ። ቴራፎርምን ከነባር መሠረተ ልማት ጋር መጠቀም ከጀመርክ የቴራፎርም አስመጪ ትዕዛዙን በመጠቀም ወደ ግዛቱ ፋይል ማከል ትችላለህ። በዚህ መንገድ ቴራፎርም ምን ዓይነት መሠረተ ልማት መምራት እንዳለበት ያውቃል። የማስመጣት ትእዛዝ ሁለት ነጋሪ እሴቶችን ይወስዳል። የመጀመሪያው በእርስዎ የማዋቀር ፋይሎች ውስጥ ያለው የመረጃ ምንጭ አድራሻ ነው። እዚህ ያለው አገባብ ከንብረት ማያያዣዎች ጋር ተመሳሳይ ነው፡_ . (እንደ aws_iam_user.existing_user)። ሁለተኛው መከራከሪያ ወደ አገር ውስጥ የሚገባውን ሀብት መታወቂያ ነው. የመርጃ መታወቂያ aws_iam_user የተጠቃሚ ስም ነው እንበል (ለምሳሌ yevgeniy.brikman) እና የንብረት መታወቂያ aws_intance የEC2 አገልጋይ መታወቂያ ነው (እንደ i-190e22e5)። ሀብትን እንዴት ማስመጣት እንደሚቻል ብዙውን ጊዜ በገጹ ታችኛው ክፍል ላይ ባለው ሰነድ ውስጥ ይገለጻል።

  በምዕራፍ 2 ከIAM ተጠቃሚ ጋር ወደ Terraform ውቅረትህ ያከሉትን የaws_iam_user ግብዓት የሚያመሳስለው የማስመጣት ትእዛዝ ከዚህ በታች አለ (ስምህን በ yevgeniy.brikman በመተካት እርግጥ ነው)፡-

  $ terraform import aws_iam_user.existing_user yevgeniy.brikman

  Terraform የእርስዎን IAM ተጠቃሚ ለማግኘት ወደ AWS ኤፒአይ ይደውላል እና በእሱ እና በ aws_iam_user.existing_user መርጃ መካከል በ Terraform ውቅረትዎ መካከል የግዛት ፋይል ግንኙነት ይፈጥራል። ከአሁን ጀምሮ፣ የእቅድ ትዕዛዙን ሲያሄዱ ቴራፎርም የIAM ተጠቃሚ አስቀድሞ እንዳለ ያውቃል እና እንደገና ለመፍጠር አይሞክርም።

  ወደ ቴራፎርም ለማስመጣት የምትፈልጋቸው ብዙ ሀብቶች ካሉህ ኮዱን በእጅ በመጻፍ እያንዳንዱን በአንድ ጊዜ ማስመጣት ችግር ሊሆን እንደሚችል ልብ ሊባል ይገባል። ስለዚህ እንደ ቴራፎርሚንግ (http://terraforming.dtan4.net/) ያለ መሳሪያ መፈለግ ተገቢ ነው፣ እሱም በራስ ሰር ኮድ አስመጣ እና ከAWS መለያህ ላይ ማስቀመጥ ይችላል።

  እንደገና መፈጠር የራሱ ችግሮች ሊኖሩት ይችላል።

  እንደገና መፈጠር ውጫዊ ባህሪ ሳይለወጥ ሲቀር የኮዱን ውስጣዊ መዋቅር የሚቀይሩበት ፕሮግራም ውስጥ የተለመደ ተግባር ነው። ይህ ኮዱን የበለጠ ግልጽ፣ ንፁህ እና ቀላል ለማድረግ ነው። ማደስ የማይፈለግ ዘዴ ሲሆን በመደበኛነት ጥቅም ላይ መዋል አለበት. ነገር ግን ወደ ቴራፎርም ወይም ሌላ የIaC መሳሪያ ሲመጣ የአንድ ቁራሽ ኮድ "ውጫዊ ባህሪ" ሲሉ ምን ለማለት እንደፈለጉ በጣም መጠንቀቅ አለብዎት, አለበለዚያ ያልተጠበቁ ችግሮች ይከሰታሉ.

  ለምሳሌ፣ የተለመደ የመልሶ ማቋቋም አይነት የተለዋዋጮችን ወይም የተግባሮችን ስም በበለጠ ለመረዳት በሚያስችል መተካት ነው። ብዙ አይዲኢዎች ለማደስ አብሮ የተሰራ ድጋፍ አላቸው እና በፕሮጀክቱ ውስጥ ተለዋዋጮችን እና ተግባራትን በራስ ሰር እንደገና መሰየም ይችላሉ። በአጠቃላይ ዓላማ የፕሮግራም አወጣጥ ቋንቋዎች፣ ይህ እርስዎ ሊያስቡበት የማይችሉት ተራ ሂደት ነው፣ ነገር ግን በቴራፎርም ውስጥ በዚህ ላይ ከፍተኛ ጥንቃቄ ማድረግ አለብዎት፣ ካልሆነ ግን መቋረጥ ሊያጋጥምዎት ይችላል።

  ለምሳሌ፣ የዌብሰርቨር-ክላስተር ሞጁል የግቤት ተለዋዋጭ የክላስተር_ስም አለው፡-

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

  foo የሚባል ማይክሮ ሰርቪስ ለማሰማራት ይህን ሞጁል መጠቀም እንደጀመርክ አድርገህ አስብ። በኋላ፣ የእርስዎን አገልግሎት ወደ አሞሌ እንደገና መሰየም ይፈልጋሉ። ይህ ለውጥ ቀላል ሊመስል ይችላል፣ ግን እንደ እውነቱ ከሆነ የአገልግሎት መስተጓጎል ሊያስከትል ይችላል።

  እውነታው ግን የዌብሰርቨር-ክላስተር ሞጁል የክላስተር_ስም ተለዋዋጭ በበርካታ ሃብቶች ውስጥ ይጠቀማል፣የሁለት የደህንነት ቡድኖች የስም መለኪያ እና 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 ከሆነ፣ እሱን በመሰረዝ እና አዲስ ስሪት በማውረድ መካከል፣ ትራፊክን ወደ የድር አገልጋይዎ ለማዞር የሚያስችል ዘዴ አይኖርዎትም። እንደዚሁም የደህንነት ቡድን ከተሰረዘ የእርስዎ አገልጋዮች አዲስ ቡድን እስኪፈጠር ድረስ ማንኛውንም የአውታረ መረብ ትራፊክ አለመቀበል ይጀምራሉ።

  ሊፈልጉት የሚችሉት ሌላ የማሻሻያ አይነት የቴራፎርም መታወቂያ መቀየር ነው። በዌብሰርቨር-ክላስተር ሞጁል ውስጥ ያለውን የአውስ_ደህንነት_ቡድን ሃብት እንደ ምሳሌ እንውሰድ፡-

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

  የዚህ ሀብት መለያ ምሳሌ ይባላል። እንደገና በማዘጋጀት ጊዜ ይበልጥ ለመረዳት ወደሚቻል (በእርስዎ አስተያየት) የክላስተር_ምሳሌ ስም ለመቀየር እንደወሰኑ አስቡት፡-

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

  በመጨረሻ ምን ይሆናል? ልክ ነው፡ መቋረጥ።

  Terraform እያንዳንዱን የንብረት መታወቂያ ከደመና አቅራቢ መታወቂያ ጋር ያዛምዳል። ለምሳሌ፣ iam_user ከAWS IAM ተጠቃሚ መታወቂያ ጋር የተቆራኘ ነው፣ እና aws_intance ከ AWS EC2 አገልጋይ መታወቂያ ጋር የተቆራኘ ነው። የንብረት መታወቂያውን ከቀየሩት (ከአብነት ወደ ክላስተር_ኢስታንስ ይናገሩ፣ እንደ aws_security_group) ወደ Terraform የድሮውን ሃብት ሰርዘህ አዲስ እንደጨመርክ ሆኖ ይታያል። እነዚህን ለውጦች ከተተገበሩ ቴራፎርም የድሮውን የደህንነት ቡድን ይሰርዛል እና አዲስ ይፈጥራል, የእርስዎ አገልጋዮች ማንኛውንም የአውታረ መረብ ትራፊክ ውድቅ ማድረግ ይጀምራሉ.

  ከዚህ ውይይት ሊወስዷቸው የሚገቡ አራት ቁልፍ ትምህርቶች እዚህ አሉ።

  • ሁልጊዜ የእቅድ ትዕዛዙን ይጠቀሙ. እነዚህን ሁሉ እንቅፋቶች ሊገልጥ ይችላል. ውጤቱን በጥንቃቄ ይገምግሙ እና ቴራፎርም መሰረዝ የማይገባቸውን ሀብቶች ለመሰረዝ ያቀደባቸውን ሁኔታዎች ትኩረት ይስጡ።
  • ከመሰረዝዎ በፊት ይፍጠሩ. ሀብትን ለመተካት ከፈለጉ ዋናውን ከመሰረዝዎ በፊት ምትክ መፍጠር ያስፈልግዎት እንደሆነ በጥንቃቄ ያስቡበት። መልሱ አዎ ከሆነ፣ ከመፍረስ_በፊት_ፍጠር_ይረዳናል። ሁለት እርምጃዎችን በመፈጸም ተመሳሳይ ውጤት በእጅ ማግኘት ይቻላል፡ በመጀመሪያ ወደ ውቅሩ አዲስ ምንጭ ይጨምሩ እና የአፕሊኬሽን ትዕዛዙን ያሂዱ እና ከዚያ የድሮውን ሃብት ከውቅሩ ያስወግዱ እና የአፕሊኬሽን ትዕዛዙን እንደገና ይጠቀሙ።
  • መለያዎችን መቀየር ሁኔታን መለወጥ ያስፈልገዋል። ከንብረት ጋር የተያያዘውን መታወቂያ መቀየር ከፈለጉ (ለምሳሌ፦ aws_security_groupን ከአብነት ወደ ክላስተር_ኢንስታንስ ይሰይሙ) ንብረቱን ሳይሰርዙ እና አዲስ ቅጂውን ሳይፈጥሩ የTerraform state ፋይልን በዚሁ መሰረት ማዘመን አለብዎት። ይህንን በጭራሽ በእጅ አያድርጉ - በምትኩ የቴራፎርም ግዛት ትዕዛዝን ይጠቀሙ። መለያዎችን በሚቀይሩበት ጊዜ፣ የሚከተለውን አገባብ የያዘውን የቴራፎርም ስቴት mv ትዕዛዝ ማስኬድ አለቦት።

    terraform state mv <ORIGINAL_REFERENCE> <NEW_REFERENCE>

    ORIGINAL_REFERENCE ንብረቱን አሁን ባለው መልኩ የሚያመለክት አገላለጽ ነው፣ እና NEW_REFERENCE ሊያንቀሳቅሱት የሚፈልጉት ቦታ ነው። ለምሳሌ የአውስ_ደህንነት_ግሩፕ ቡድንን ከአብነት ወደ ክላስተር_ኢስታንስ ስትሰይም የሚከተለውን ትዕዛዝ ማስኬድ አለብህ።

    $ terraform state mv 
       aws_security_group.instance 
       aws_security_group.cluster_instance

    ይህ ለቴራፎርም ከዚህ ቀደም ከአውስ_ደህንነት_ቡድን.ኢንስታንስ ጋር የተቆራኘው ግዛት አሁን ከaws_security_group.cluster_intance ጋር መያያዝ እንዳለበት ይነግረዋል። ይህንን የትዕዛዝ ስም ከቀየሩ እና ካስኬዱ በኋላ ቴራፎርም እቅድ ምንም ለውጦችን ካላሳየ ሁሉንም ነገር በትክክል አከናውነዋል።

  • አንዳንድ ቅንብሮች ሊለወጡ አይችሉም። የብዙ ሀብቶች መለኪያዎች የማይለወጡ ናቸው። እነሱን ለመቀየር ከሞከሩ ቴራፎርም የድሮውን ሃብት ይሰርዛል እና በእሱ ቦታ አዲስ ይፈጥራል። እያንዳንዱ የመረጃ ምንጭ አብዛኛውን ጊዜ አንድን መቼት ሲቀይሩ ምን እንደሚፈጠር ይጠቁማል፣ ስለዚህ ሰነዶቹን ማረጋገጥዎን ያረጋግጡ። ሁልጊዜ የፕላን ትዕዛዙን ይጠቀሙ እና የcreat_before_destroy ስትራቴጂ ለመጠቀም ያስቡበት።

  የዘገየ ወጥነት ወጥነት ያለው ነው... ከማዘግየት ጋር

  እንደ AWS ያሉ አንዳንድ የደመና አቅራቢዎች ኤፒአይዎች ያልተመሳሰሉ እና ወጥነት ዘግይተዋል። Asynchrony ማለት በይነገጹ የተጠየቀው እርምጃ እስኪጠናቀቅ ድረስ ሳይጠብቅ ወዲያውኑ ምላሽ ሊመልስ ይችላል። የዘገየ ወጥነት ማለት ለውጦቹ በስርአቱ ውስጥ ለመስፋፋት ጊዜ ሊወስዱ ይችላሉ፤ ይህ በሚሆንበት ጊዜ የእርስዎ ምላሾች ወጥነት የሌላቸው እና በየትኛው የውሂብ ምንጭ ቅጂ ለኤፒአይ ጥሪዎችዎ ምላሽ እየሰጠ እንደሆነ ላይ የተመረኮዙ ሊሆኑ ይችላሉ።

  አስቡት፣ ለምሳሌ፣ የኤ.ፒ.አይ.ኤ2 አገልጋይ እንዲፈጥር በመጠየቅ ወደ AWS ይደውሉ። ኤፒአይ አገልጋዩ ራሱ እስኪፈጠር ድረስ ሳይጠብቅ ወዲያውኑ “የተሳካ” ምላሽ (201 የተፈጠረው) ይመልሳል። ከእሱ ጋር ወዲያውኑ ለመገናኘት ከሞከሩ በእርግጠኝነት አይሳካም ምክንያቱም በዚያ ጊዜ AWS አሁንም ሀብቶችን እያስጀመረ ነው ወይም እንደ አማራጭ አገልጋዩ ገና አልተጫነም። በተጨማሪም ስለዚህ አገልጋይ መረጃ ለማግኘት ሌላ ጥሪ ካደረጉ ስህተት ሊደርስዎት ይችላል (404 አልተገኘም)። ነገሩ ይህ የEC2 አገልጋይ መረጃ በሁሉም ቦታ ከመገኘቱ በፊት አሁንም በመላው AWS ሊሰራጭ ይችላል፣ ጥቂት ሰከንዶች መጠበቅ አለብዎት።

  ያልተመሳሰለ ኤፒአይ ከሰነፍ ወጥነት ጋር በተጠቀምክ ቁጥር ድርጊቱ እስኪጠናቀቅ እና በስርዓቱ ውስጥ እስኪሰራጭ ድረስ በየጊዜው ጥያቄህን እንደገና መሞከር አለብህ። እንደ አለመታደል ሆኖ፣ AWS ኤስዲኬ ለዚህ ምንም አይነት ጥሩ መሳሪያ አይሰጥም፣ እና የቴራፎርም ፕሮጀክት እንደ 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 ን ጨምሮ) ተስተካክለዋል፣ ነገር ግን አሁንም ከጊዜ ወደ ጊዜ ይበቅላሉ፣ በተለይም Terraform ለአዲሱ የንብረት አይነት ድጋፍን ሲጨምር። ይህ የሚያበሳጭ ነው, ነገር ግን በአብዛኛዎቹ ሁኔታዎች ምንም ጉዳት አያስከትልም. ቴራፎርምን እንደገና ሲያካሂዱ ሁሉም ነገር መስራት አለበት ምክንያቱም በዚህ ጊዜ መረጃው በስርዓቱ ውስጥ ይሰራጫል.

  ይህ ቅንጭብ ከመጽሐፉ Evgeniy Brikman ቀርቧል "ቴራፎርም: መሠረተ ልማት በኮድ ደረጃ".

ምንጭ: hab.com