ຂຸມ Terraform

ຂໍໃຫ້ຍົກໃຫ້ເຫັນບາງຂຸມ, ລວມທັງສິ່ງທີ່ກ່ຽວຂ້ອງກັບ loops, ຖ້າຄໍາຖະແຫຼງແລະເຕັກນິກການນໍາໄປໃຊ້, ເຊັ່ນດຽວກັນກັບບັນຫາທົ່ວໄປຫຼາຍທີ່ມີຜົນກະທົບ Terraform ໂດຍທົ່ວໄປ:

• count ແລະ for_each ຕົວກໍານົດການມີຂໍ້ຈໍາກັດ;
• ຈໍາ​ກັດ​ສູນ​ການ​ປະ​ຕິ​ບັດ​ການ downtime​;
• ເຖິງແມ່ນວ່າແຜນການທີ່ດີກໍ່ບໍ່ສາມາດລົ້ມເຫລວ;
• refactoring ສາມາດມີ pitfalls ຂອງຕົນ;
• ການເລື່ອນເວລາສອດຄ່ອງແມ່ນສອດຄ່ອງ ... ກັບການເລື່ອນເວລາ.

ຕົວກໍານົດການນັບ ແລະ for_each ມີຂໍ້ຈໍາກັດ

ຕົວຢ່າງໃນບົດນີ້ເຮັດໃຫ້ການນໍາໃຊ້ຢ່າງກວ້າງຂວາງຂອງພາລາມິເຕີການນັບແລະການສະແດງອອກ for_each ໃນ loops ແລະເຫດຜົນຕາມເງື່ອນໄຂ. ພວກເຂົາປະຕິບັດໄດ້ດີ, ແຕ່ພວກເຂົາມີຂໍ້ຈໍາກັດທີ່ສໍາຄັນສອງຢ່າງທີ່ເຈົ້າຕ້ອງລະວັງ.

• Count ແລະ for_each ບໍ່ສາມາດອ້າງອີງຕົວແປຜົນຜະລິດຊັບພະຍາກອນໃດໆ.
• count ແລະ for_each ບໍ່ສາມາດໃຊ້ໃນການຕັ້ງຄ່າໂມດູນໄດ້.

count ແລະ for_each ບໍ່ສາມາດອ້າງອີງຕົວແປຜົນຜະລິດຊັບພະຍາກອນໃດໆ

ຈິນຕະນາການວ່າທ່ານຈໍາເປັນຕ້ອງໃຊ້ເຄື່ອງແມ່ຂ່າຍ EC2 ຫຼາຍອັນແລະສໍາລັບບາງເຫດຜົນທີ່ທ່ານບໍ່ຕ້ອງການໃຊ້ ASG. ລະຫັດຂອງທ່ານສາມາດເປັນແບບນີ້:

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

ໃຫ້ເຮົາເບິ່ງພວກເຂົາເທື່ອລະອັນ.

ເນື່ອງຈາກພາລາມິເຕີການນັບຖືກຕັ້ງເປັນຄ່າຄົງທີ່, ລະຫັດນີ້ຈະເຮັດວຽກໂດຍບໍ່ມີບັນຫາ: ເມື່ອທ່ານດໍາເນີນການຄໍາສັ່ງສະຫມັກ, ມັນຈະສ້າງສາມເຄື່ອງແມ່ຂ່າຍ EC2. ແຕ່ຈະເປັນແນວໃດຖ້າທ່ານຕ້ອງການໃຊ້ເຄື່ອງແມ່ຂ່າຍຫນຶ່ງໃນແຕ່ລະເຂດ Availability (AZ) ພາຍໃນພາກພື້ນ AWS ໃນປະຈຸບັນຂອງທ່ານ? ທ່ານສາມາດໃຫ້ລະຫັດຂອງທ່ານໂຫຼດບັນຊີລາຍຊື່ຂອງເຂດຈາກແຫຼ່ງຂໍ້ມູນ aws_availability_zones ແລະຫຼັງຈາກນັ້ນ loop ຜ່ານແຕ່ລະອັນແລະສ້າງເຄື່ອງແມ່ຂ່າຍ EC2 ໃນມັນໂດຍໃຊ້ຕົວກໍານົດການນັບແລະການເຂົ້າເຖິງດັດສະນີ array:

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, ການນໍາໃຊ້ການນັບຫຼື for_each ໃນຊັບພະຍາກອນຂອງໂມດູນແມ່ນບໍ່ສະຫນັບສະຫນູນ. ອີງຕາມບັນທຶກການປ່ອຍ Terraform 0.12 (http://bit.ly/3257bv4), HashiCorp ວາງແຜນທີ່ຈະເພີ່ມຄວາມສາມາດນີ້ໃນອະນາຄົດ, ດັ່ງນັ້ນຂຶ້ນຢູ່ກັບເວລາທີ່ທ່ານອ່ານຫນັງສືເຫຼັ້ມນີ້, ມັນອາດຈະມີຢູ່ແລ້ວ. ເພື່ອຊອກຫາແນ່ນອນ, ອ່ານການປ່ຽນແປງ Terraform ທີ່ນີ້.

ຂໍ້ຈໍາກັດຂອງ Zero Downtime Deployments

ການໃຊ້ block create_before_destroy ປະສົມປະສານກັບ ASG ເປັນການແກ້ໄຂທີ່ດີສໍາລັບການສ້າງການໃຊ້ງານສູນການຢຸດເຮັດວຽກ, ຍົກເວັ້ນຄໍາເຕືອນຫນຶ່ງ: ກົດລະບຽບການປັບຂະຫນາດອັດຕະໂນມັດບໍ່ໄດ້ຮັບການສະຫນັບສະຫນູນ. ຫຼືເພື່ອໃຫ້ມີຄວາມຊັດເຈນຫຼາຍຂຶ້ນ, ນີ້ຈະປັບຂະຫນາດ ASG ກັບຄືນໄປບ່ອນ min_size ໃນທຸກໆການນໍາໃຊ້, ເຊິ່ງອາດຈະເປັນບັນຫາຖ້າທ່ານໃຊ້ກົດລະບຽບການປັບຂະຫນາດອັດຕະໂນມັດເພື່ອເພີ່ມຈໍານວນເຄື່ອງແມ່ຂ່າຍທີ່ເຮັດວຽກ.

ຕົວຢ່າງ, ໂມດູນ webserver-cluster ມີຄູ່ຂອງຊັບພະຍາກອນ aw_autoscaling_schedule, ເຊິ່ງໃນເວລາ 9 ໂມງເຊົ້າຈະເພີ່ມຈໍານວນເຄື່ອງແມ່ຂ່າຍໃນ cluster ຈາກສອງຫາສິບ. ຖ້າທ່ານປະຕິບັດໃນເວລາ, ເວົ້າວ່າ, 11 ໂມງເຊົ້າ, ASG ໃຫມ່ຈະບູດດ້ວຍພຽງແຕ່ສອງເຄື່ອງແມ່ຂ່າຍແທນທີ່ຈະເປັນສິບແລະຍັງຄົງເປັນແບບນັ້ນຈົນກ່ວາ 9 ໂມງເຊົ້າຂອງມື້ຕໍ່ມາ.

ຂໍ້ ຈຳ ກັດນີ້ສາມາດຫລີກລ້ຽງໄດ້ໃນຫຼາຍວິທີ.

• ປ່ຽນພາລາມິເຕີການເກີດຂຶ້ນຊ້ຳໃນ aws_autoscaling_schedule ຈາກ 0 9 * * * (“ແລ່ນເວລາ 9 ໂມງເຊົ້າ”) ມາເປັນ 0-59 9-17 * * * (“ແລ່ນທຸກໆນາທີຈາກ 9 ໂມງເຊົ້າຫາ 5 ໂມງແລງ”). ຖ້າ ASG ມີສິບເຊີບເວີແລ້ວ, ການໃຊ້ກົດລະບຽບການປັບຂະຫນາດອັດຕະໂນມັດນີ້ອີກເທື່ອຫນຶ່ງຈະບໍ່ປ່ຽນແປງຫຍັງ, ເຊິ່ງເປັນສິ່ງທີ່ພວກເຮົາຕ້ອງການ. ແຕ່ຖ້າ 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, ແຕ່ກັບເກືອບທຸກຊັບພະຍາກອນ. ມັນເປັນໄປໄດ້ວ່າຜູ້ໃດຜູ້ຫນຶ່ງສ້າງຊັບພະຍາກອນນີ້ດ້ວຍຕົນເອງຫຼືໃຊ້ເສັ້ນຄໍາສັ່ງ, ແຕ່ໃນທາງໃດກໍ່ຕາມ, ການຈັບຄູ່ IDs ນໍາໄປສູ່ການຂັດແຍ້ງ. ມີຫຼາຍການປ່ຽນແປງຂອງຄວາມຜິດພາດນີ້ທີ່ມັກຈະຈັບຜູ້ມາໃຫມ່ກັບ Terraform ໂດຍແປກໃຈ.

ຈຸດສໍາຄັນແມ່ນວ່າຄໍາສັ່ງແຜນການ terraform ພຽງແຕ່ໃຊ້ເວລາເຂົ້າໄປໃນບັນຊີຊັບພະຍາກອນເຫຼົ່ານັ້ນທີ່ຖືກກໍານົດໄວ້ໃນໄຟລ໌ລັດ Terraform. ຖ້າຊັບພະຍາກອນຖືກສ້າງຂື້ນໃນທາງອື່ນ (ຕົວຢ່າງ, ດ້ວຍຕົນເອງໂດຍການຄລິກໃສ່ console AWS), ພວກມັນຈະບໍ່ສິ້ນສຸດໃນໄຟລ໌ຂອງລັດແລະດັ່ງນັ້ນ Terraform ຈະບໍ່ເອົາພວກມັນເຂົ້າໃນບັນຊີໃນເວລາທີ່ປະຕິບັດຄໍາສັ່ງແຜນການ. ດັ່ງນັ້ນ, ແຜນການທີ່ເບິ່ງຄືວ່າຖືກຕ້ອງຢູ່ glance ທໍາອິດຈະກາຍເປັນບໍ່ສໍາເລັດ.

ມີສອງບົດຮຽນທີ່ຈະຮຽນຮູ້ຈາກນີ້.

• ຖ້າທ່ານໄດ້ເລີ່ມເຮັດວຽກກັບ Terraform ແລ້ວ, ຢ່າໃຊ້ອັນອື່ນ. ຖ້າສ່ວນຫນຶ່ງຂອງໂຄງສ້າງພື້ນຖານຂອງທ່ານຖືກຈັດການໂດຍໃຊ້ Terraform, ທ່ານບໍ່ສາມາດດັດແປງມັນດ້ວຍຕົນເອງໄດ້. ຖ້າບໍ່ດັ່ງນັ້ນ, ທ່ານບໍ່ພຽງແຕ່ມີຄວາມສ່ຽງຕໍ່ຄວາມຜິດພາດ Terraform ທີ່ແປກປະຫຼາດ, ແຕ່ທ່ານຍັງປະຕິເສດຜົນປະໂຫຍດຫຼາຍຢ່າງຂອງ IaC ເພາະວ່າລະຫັດຈະບໍ່ເປັນຕົວແທນທີ່ຖືກຕ້ອງຂອງໂຄງສ້າງພື້ນຖານຂອງທ່ານ.
• ຖ້າທ່ານມີໂຄງສ້າງພື້ນຖານບາງຢ່າງແລ້ວ, ໃຫ້ໃຊ້ຄໍາສັ່ງນໍາເຂົ້າ. ຖ້າທ່ານກໍາລັງເລີ່ມໃຊ້ Terraform ກັບໂຄງສ້າງພື້ນຖານທີ່ມີຢູ່, ທ່ານສາມາດເພີ່ມມັນໃສ່ໄຟລ໌ຂອງລັດໂດຍໃຊ້ຄໍາສັ່ງນໍາເຂົ້າ terraform. ວິທີນີ້ Terraform ຈະຮູ້ວ່າໂຄງສ້າງພື້ນຖານອັນໃດທີ່ຕ້ອງໄດ້ຮັບການຄຸ້ມຄອງ. ຄໍາສັ່ງນໍາເຂົ້າໃຊ້ເວລາສອງການໂຕ້ຖຽງ. ທໍາອິດແມ່ນທີ່ຢູ່ຊັບພະຍາກອນໃນໄຟລ໌ການຕັ້ງຄ່າຂອງທ່ານ. syntax ຢູ່ທີ່ນີ້ແມ່ນຄືກັນກັບການເຊື່ອມຕໍ່ຊັບພະຍາກອນ: _. (ເຊັ່ນ: aws_iam_user.existing_user). ການໂຕ້ຖຽງທີສອງແມ່ນ ID ຂອງຊັບພະຍາກອນທີ່ຈະນໍາເຂົ້າ. ສົມມຸດວ່າ ID ຊັບພະຍາກອນ aws_iam_user ແມ່ນຊື່ຜູ້ໃຊ້ (ຕົວຢ່າງ, yevgeniy.brikman), ແລະ ID ຊັບພະຍາກອນ aws_instance ແມ່ນ ID ເຊີບເວີ EC2 (ເຊັ່ນ: i-190e22e5). ວິທີການນໍາເຂົ້າຊັບພະຍາກອນແມ່ນມັກຈະສະແດງຢູ່ໃນເອກະສານຢູ່ດ້ານລຸ່ມຂອງຫນ້າຂອງມັນ.

  ຂ້າງລຸ່ມນີ້ແມ່ນຄໍາສັ່ງນໍາເຂົ້າທີ່ synchronizes ຊັບພະຍາກອນ 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 ສາມາດມີ pitfalls ຂອງຕົນ

  ປະຕິສັງຂອນ ເປັນການປະຕິບັດທົ່ວໄປໃນການຂຽນໂປຼແກຼມທີ່ທ່ານປ່ຽນໂຄງສ້າງພາຍໃນຂອງລະຫັດໃນຂະນະທີ່ເຮັດໃຫ້ພຶດຕິກໍາພາຍນອກບໍ່ປ່ຽນແປງ. ນີ້ແມ່ນເພື່ອເຮັດໃຫ້ລະຫັດຊັດເຈນ, ສະອາດ, ແລະງ່າຍຕໍ່ການຮັກສາ. Refactoring ເປັນເຕັກນິກທີ່ຂາດບໍ່ໄດ້ທີ່ຄວນຈະຖືກນໍາໃຊ້ເປັນປະຈໍາ. ແຕ່ເມື່ອມັນມາກັບ Terraform ຫຼືເຄື່ອງມື IaC ອື່ນໆ, ທ່ານຕ້ອງລະມັດລະວັງທີ່ສຸດກ່ຽວກັບສິ່ງທີ່ທ່ານຫມາຍເຖິງ "ພຶດຕິກໍາພາຍນອກ" ຂອງລະຫັດ, ຖ້າບໍ່ດັ່ງນັ້ນບັນຫາທີ່ບໍ່ຄາດຄິດຈະເກີດຂື້ນ.

  ຕົວຢ່າງ, ປະເພດທົ່ວໄປຂອງ refactoring ແມ່ນການປ່ຽນຊື່ຂອງຕົວແປຫຼືຫນ້າທີ່ທີ່ມີຄວາມເຂົ້າໃຈຫຼາຍ. IDEs ຫຼາຍຄົນມີຕົວຊ່ວຍໃນຕົວສໍາລັບການ refactoring ແລະສາມາດປ່ຽນຊື່ຕົວແປແລະຫນ້າທີ່ອັດຕະໂນມັດໃນທົ່ວໂຄງການ. ໃນພາສາການຂຽນໂປລແກລມທີ່ມີຈຸດປະສົງທົ່ວໄປ, ນີ້ແມ່ນຂັ້ນຕອນເລັກນ້ອຍທີ່ເຈົ້າອາດຈະບໍ່ຄິດກ່ຽວກັບ, ແຕ່ໃນ Terraform ທ່ານຕ້ອງລະມັດລະວັງທີ່ສຸດກັບເລື່ອງນີ້, ຖ້າບໍ່ດັ່ງນັ້ນທ່ານອາດຈະປະສົບກັບບັນຫາ.

  ຕົວຢ່າງ, webserver-cluster module ມີ input variable cluster_name:

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

  ຈິນຕະນາການວ່າທ່ານເລີ່ມໃຊ້ໂມດູນນີ້ເພື່ອນຳໃຊ້ບໍລິການຈຸລະພາກທີ່ເອີ້ນວ່າ foo. ຕໍ່ມາ, ທ່ານຕ້ອງການປ່ຽນຊື່ບໍລິການຂອງທ່ານເປັນແຖບ. ການປ່ຽນແປງນີ້ອາດເບິ່ງຄືວ່າເປັນເລື່ອງເລັກນ້ອຍ, ແຕ່ໃນຄວາມເປັນຈິງແລ້ວ ມັນສາມາດເຮັດໃຫ້ເກີດການຂັດຂວາງການບໍລິການ.

  ຄວາມຈິງແມ່ນວ່າ webserver-cluster module ໃຊ້ຕົວແປ 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, ລະຫວ່າງການລຶບມັນແລະການດາວໂຫລດເວີຊັນໃຫມ່, ທ່ານຈະບໍ່ມີກົນໄກທີ່ຈະປ່ຽນເສັ້ນທາງໄປຫາເຄື່ອງແມ່ຂ່າຍເວັບຂອງທ່ານ. ເຊັ່ນດຽວກັນ, ຖ້າກຸ່ມຄວາມປອດໄພຖືກລຶບ, ເຄື່ອງແມ່ຂ່າຍຂອງທ່ານຈະເລີ່ມປະຕິເສດການຈາລະຈອນເຄືອຂ່າຍໃດໆຈົນກ່ວາກຸ່ມໃຫມ່ຖືກສ້າງຂື້ນ.

  ປະເພດຂອງການ refactoring ອື່ນທີ່ທ່ານອາດຈະສົນໃຈແມ່ນການປ່ຽນແປງ Terraform ID. ໃຫ້ເອົາຊັບພະຍາກອນ aws_security_group ໃນໂມດູນ webserver-cluster ເປັນຕົວຢ່າງ:

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

  ຕົວລະບຸຂອງຊັບພະຍາກອນນີ້ເອີ້ນວ່າ instance. ຈິນຕະນາການວ່າໃນລະຫວ່າງການ refactoring ທ່ານໄດ້ຕັດສິນໃຈທີ່ຈະປ່ຽນເປັນຊື່ທີ່ເຂົ້າໃຈໄດ້ຫຼາຍຂຶ້ນ (ໃນຄວາມຄິດເຫັນຂອງທ່ານ) cluster_instance:

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

  ຈະເກີດຫຍັງຂຶ້ນໃນທີ່ສຸດ? ມັນຖືກຕ້ອງ: ການຂັດຂວາງ.

  Terraform ເຊື່ອມໂຍງແຕ່ລະ ID ຊັບພະຍາກອນກັບ ID ຜູ້ໃຫ້ບໍລິການຄລາວ. ຕົວຢ່າງ, iam_user ແມ່ນເຊື່ອມໂຍງກັບ ID ຜູ້ໃຊ້ AWS IAM, ແລະ aws_instance ແມ່ນກ່ຽວຂ້ອງກັບ ID ເຊີບເວີ AWS EC2. ຖ້າທ່ານປ່ຽນ ID ຊັບພະຍາກອນ (ເວົ້າຈາກ instance ເປັນ cluster_instance, ເຊັ່ນດຽວກັບ aws_security_group), ກັບ Terraform ມັນຈະປາກົດຄືກັບວ່າທ່ານໄດ້ລຶບຊັບພະຍາກອນເກົ່າອອກ ແລະເພີ່ມອັນໃໝ່. ຖ້າທ່ານນໍາໃຊ້ການປ່ຽນແປງເຫຼົ່ານີ້, Terraform ຈະລຶບກຸ່ມຄວາມປອດໄພເກົ່າແລະສ້າງໃຫມ່, ໃນຂະນະທີ່ເຄື່ອງແມ່ຂ່າຍຂອງທ່ານເລີ່ມປະຕິເສດການຈະລາຈອນເຄືອຂ່າຍໃດໆ.

  ນີ້ແມ່ນສີ່ບົດຮຽນທີ່ສໍາຄັນທີ່ທ່ານຄວນຖອດຖອນອອກຈາກການສົນທະນານີ້.

  • ໃຊ້ຄຳສັ່ງແຜນສະເໝີ. ມັນສາມາດເປີດເຜີຍ snags ທັງຫມົດເຫຼົ່ານີ້. ທົບທວນຜົນຜະລິດຂອງມັນຢ່າງລະມັດລະວັງແລະເອົາໃຈໃສ່ກັບສະຖານະການທີ່ Terraform ວາງແຜນທີ່ຈະລຶບຊັບພະຍາກອນທີ່ອາດຈະບໍ່ຖືກລຶບຖິ້ມ.
  • ສ້າງກ່ອນທີ່ທ່ານຈະລຶບ. ຖ້າທ່ານຕ້ອງການທົດແທນຊັບພະຍາກອນ, ໃຫ້ຄິດຢ່າງລະອຽດກ່ຽວກັບວ່າທ່ານຕ້ອງການສ້າງການທົດແທນກ່ອນທີ່ຈະລຶບຕົ້ນສະບັບ. ຖ້າຄໍາຕອບແມ່ນແມ່ນ, create_before_destroy ສາມາດຊ່ວຍໄດ້. ຜົນໄດ້ຮັບດຽວກັນສາມາດບັນລຸໄດ້ດ້ວຍຕົນເອງໂດຍການປະຕິບັດສອງຂັ້ນຕອນ: ທໍາອິດເພີ່ມຊັບພະຍາກອນໃຫມ່ໃນການຕັ້ງຄ່າແລະດໍາເນີນການຄໍາສັ່ງສະຫມັກ, ແລະຫຼັງຈາກນັ້ນເອົາຊັບພະຍາກອນເກົ່າອອກຈາກການຕັ້ງຄ່າແລະນໍາໃຊ້ຄໍາສັ່ງນໍາໃຊ້ອີກເທື່ອຫນຶ່ງ.
  • ການປ່ຽນແປງຕົວລະບຸຕ້ອງການປ່ຽນສະຖານະ. ຖ້າທ່ານຕ້ອງການປ່ຽນ ID ທີ່ກ່ຽວຂ້ອງກັບຊັບພະຍາກອນ (ຕົວຢ່າງ, ປ່ຽນຊື່ aws_security_group ຈາກ instance ເປັນ cluster_instance) ໂດຍບໍ່ມີການລຶບຊັບພະຍາກອນແລະສ້າງເວີຊັນໃຫມ່ຂອງມັນ, ທ່ານຕ້ອງປັບປຸງໄຟລ໌ລັດ Terraform ຕາມຄວາມເຫມາະສົມ. ຢ່າເຮັດສິ່ງນີ້ດ້ວຍຕົນເອງ - ໃຊ້ຄໍາສັ່ງຂອງລັດ terraform ແທນ. ເມື່ອປ່ຽນຊື່ຕົວລະບຸ, ທ່ານຄວນແລ່ນຄໍາສັ່ງ mv state terraform, ເຊິ່ງມີ syntax ຕໍ່ໄປນີ້:

    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 ຫມາຍຄວາມວ່າການໂຕ້ຕອບສາມາດສົ່ງຄືນການຕອບໂຕ້ໄດ້ທັນທີໂດຍບໍ່ຕ້ອງລໍຖ້າການປະຕິບັດທີ່ຮ້ອງຂໍໃຫ້ສໍາເລັດ. ຄວາມສອດຄ່ອງທີ່ຊັກຊ້າຫມາຍຄວາມວ່າການປ່ຽນແປງອາດຈະໃຊ້ເວລາເພື່ອແຜ່ຂະຫຍາຍໃນທົ່ວລະບົບ; ໃນຂະນະທີ່ມັນເກີດຂຶ້ນ, ຄໍາຕອບຂອງທ່ານອາດຈະບໍ່ສອດຄ່ອງແລະຂຶ້ນກັບວ່າແຫຼ່ງຂໍ້ມູນ replica ແມ່ນຕອບສະຫນອງຕໍ່ການໂທ API ຂອງທ່ານ.

  ຕົວຢ່າງ, ຈິນຕະນາການວ່າເຈົ້າໂທຫາ API ກັບ AWS ຂໍໃຫ້ມັນສ້າງເຄື່ອງແມ່ຂ່າຍ EC2. API ຈະສົ່ງຄືນການຕອບສະຫນອງ "ປະສົບຜົນສໍາເລັດ" (201 ສ້າງ) ເກືອບທັນທີ, ໂດຍບໍ່ຕ້ອງລໍຖ້າເຄື່ອງແມ່ຂ່າຍຂອງຕົວມັນເອງຖືກສ້າງ. ຖ້າທ່ານພະຍາຍາມເຊື່ອມຕໍ່ມັນທັນທີ, ມັນເກືອບແນ່ນອນຈະລົ້ມເຫລວເພາະວ່າໃນຈຸດນັ້ນ AWS ຍັງກໍາລັງເລີ່ມຕົ້ນຊັບພະຍາກອນຫຼື, ໃນທາງກົງກັນຂ້າມ, ເຄື່ອງແມ່ຂ່າຍຍັງບໍ່ໄດ້ booted. ຍິ່ງໄປກວ່ານັ້ນ, ຖ້າທ່ານໂທຫາອື່ນເພື່ອຮັບເອົາຂໍ້ມູນກ່ຽວກັບເຄື່ອງແມ່ຂ່າຍນີ້, ທ່ານອາດຈະໄດ້ຮັບຂໍ້ຜິດພາດ (404 ບໍ່ພົບ). ສິ່ງແມ່ນວ່າຂໍ້ມູນກ່ຽວກັບເຄື່ອງແມ່ຂ່າຍ EC2 ນີ້ອາດຈະຍັງຖືກເຜີຍແຜ່ໃນທົ່ວ AWS ກ່ອນທີ່ມັນຈະມີຢູ່ທົ່ວທຸກແຫ່ງ, ທ່ານຈະຕ້ອງລໍຖ້າສອງສາມວິນາທີ.

  ເມື່ອໃດກໍ່ຕາມທີ່ທ່ານໃຊ້ API asynchronous ທີ່ມີຄວາມສອດຄ່ອງຂີ້ກຽດ, ທ່ານຕ້ອງລອງຄືນຄໍາຮ້ອງຂໍຂອງທ່ານເປັນໄລຍະຈົນກ່ວາການປະຕິບັດສໍາເລັດແລະແຜ່ຂະຫຍາຍຜ່ານລະບົບ. ແຕ່ຫນ້າເສຍດາຍ, 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) ໄດ້ຖືກແກ້ໄຂແລ້ວ, ແຕ່ພວກເຂົາຍັງປູກພືດເປັນແຕ່ລະໄລຍະ, ໂດຍສະເພາະໃນເວລາທີ່ Terraform ເພີ່ມການສະຫນັບສະຫນູນສໍາລັບປະເພດຊັບພະຍາກອນໃຫມ່. ນີ້ແມ່ນຫນ້າລໍາຄານ, ແຕ່ໃນກໍລະນີຫຼາຍທີ່ສຸດບໍ່ໄດ້ເຮັດໃຫ້ເກີດອັນຕະລາຍໃດໆ. ເມື່ອທ່ານໃຊ້ terraform ອີກເທື່ອຫນຶ່ງ, ທຸກສິ່ງທຸກຢ່າງຄວນຈະເຮັດວຽກ, ເພາະວ່າເວລານີ້ຂໍ້ມູນຈະແຜ່ລາມໄປທົ່ວລະບົບ.

  excerpt ນີ້ໄດ້ຖືກນໍາສະເຫນີຈາກຫນັງສືໂດຍ Evgeniy Brikman "Terraform: ໂຄງສ້າງພື້ນຖານໃນລະດັບລະຫັດ".

ແຫຼ່ງຂໍ້ມູນ: www.habr.com