ປ່ຽນຈາກ Terraform ເປັນ CloudFormation - ແລະເສຍໃຈມັນ

ການເປັນຕົວແທນພື້ນຖານໂຄງລ່າງເປັນລະຫັດໃນຮູບແບບຂໍ້ຄວາມທີ່ເຮັດຊ້ໍາໄດ້ແມ່ນການປະຕິບັດທີ່ດີທີ່ສຸດທີ່ງ່າຍດາຍສໍາລັບລະບົບທີ່ບໍ່ຈໍາເປັນຕ້ອງມີຫນູ. ການ​ປະ​ຕິ​ບັດ​ນີ້​ມີ​ຊື່ - ພື້ນຖານໂຄງລ່າງເປັນລະຫັດ, ແລະມາຮອດປະຈຸບັນມີສອງເຄື່ອງມືທີ່ນິຍົມເພື່ອປະຕິບັດມັນ, ໂດຍສະເພາະໃນ AWS: Terraform и CloudFormation.

ປຽບທຽບປະສົບການກັບ Terraform ແລະ CloudFormation

ກ່ອນທີ່ຈະມາ Twitch (ລາວ​ແມ່ນ Amazon Jr.) ຂ້ອຍໄດ້ເຮັດວຽກ ໃນການເລີ່ມຕົ້ນຫນຶ່ງ ແລະໃຊ້ Terraform ສໍາລັບສາມປີ. ຢູ່ໃນສະຖານທີ່ໃຫມ່, ຂ້ອຍຍັງໄດ້ໃຊ້ Terraform ດ້ວຍຄວາມສາມາດຂອງຂ້ອຍ, ແລະຫຼັງຈາກນັ້ນບໍລິສັດໄດ້ຊຸກຍູ້ການຫັນປ່ຽນໄປສູ່ທຸກສິ່ງຂອງ Amazon, ລວມທັງ CloudFormation. ຂ້າພະເຈົ້າໄດ້ພັດທະນາການປະຕິບັດທີ່ດີທີ່ສຸດສໍາລັບທັງສອງຢ່າງພາກພຽນ, ແລະໄດ້ນໍາໃຊ້ທັງສອງເຄື່ອງມືໃນຂະບວນການເຮັດວຽກທີ່ສັບສົນຫຼາຍ, ອົງການຈັດຕັ້ງ. ຕໍ່ມາ, ຫຼັງຈາກການຊັ່ງນໍ້າຫນັກຢ່າງລະມັດລະວັງກ່ຽວກັບຜົນສະທ້ອນຂອງການເຄື່ອນຍ້າຍຈາກ Terraform ໄປຫາ CloudFormation, ຂ້ອຍເຊື່ອວ່າ Terraform ແມ່ນອາດຈະເປັນທາງເລືອກທີ່ດີທີ່ສຸດສໍາລັບອົງການ.

Terraform ເປັນຕາຢ້ານ

ຊອບແວເບຕ້າ

Terraform ຍັງບໍ່ທັນໄດ້ອອກເວີຊັ່ນ 1.0 ເທື່ອ, ເຊິ່ງເປັນເຫດຜົນທີ່ດີທີ່ຈະບໍ່ໃຊ້ມັນ. ມັນມີການປ່ຽນແປງຫຼາຍນັບຕັ້ງແຕ່ຂ້າພະເຈົ້າໄດ້ພະຍາຍາມມັນດ້ວຍຕົນເອງ, ແຕ່ກັບຄືນໄປບ່ອນນັ້ນ terraform apply ມັກຈະລົ້ມລົງຫຼັງຈາກການປັບປຸງຫຼາຍໆຄັ້ງຫຼືພຽງແຕ່ຫຼັງຈາກສອງສາມປີຂອງການນໍາໃຊ້. ຂ້າພະເຈົ້າຈະເວົ້າວ່າ "ທຸກສິ່ງທຸກຢ່າງແມ່ນແຕກຕ່າງກັນໃນປັດຈຸບັນ," ແຕ່ ... ນັ້ນແມ່ນສິ່ງທີ່ທຸກຄົນເວົ້າ, ບໍ່ແມ່ນບໍ? ມີການປ່ຽນແປງທີ່ບໍ່ເຫມາະສົມກັບສະບັບທີ່ຜ່ານມາ, ເຖິງແມ່ນວ່າມັນເຫມາະສົມ, ແລະມັນຍັງມີຄວາມຮູ້ສຶກຄືກັບ syntax ແລະ abstractions ຂອງຮ້ານຊັບພະຍາກອນແມ່ນສິ່ງທີ່ພວກເຮົາຕ້ອງການ. ເຄື່ອງມືເບິ່ງຄືວ່າດີຂື້ນແທ້ໆ, ແຕ່ ... :-0

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

ພົບກັບຂາ... ມັນເປັນລູກປືນ

ເທົ່າທີ່ຂ້ອຍຮູ້, ລຶບຊັບພະຍາກອນ ຄົນນອກ CloudFormation stack ຈາກ stack CF ຂອງທ່ານແມ່ນເປັນໄປບໍ່ໄດ້. ດຽວກັນກັບ Terraform. ມັນອະນຸຍາດໃຫ້ທ່ານສາມາດນໍາເຂົ້າຊັບພະຍາກອນທີ່ມີຢູ່ແລ້ວເຂົ້າໄປໃນ stack ຂອງທ່ານ. ຫນ້າທີ່ສາມາດເວົ້າໄດ້ວ່າເປັນທີ່ຫນ້າອັດສະຈັນ, ແຕ່ມີພະລັງງານທີ່ຍິ່ງໃຫຍ່ມາເຖິງຄວາມຮັບຜິດຊອບອັນໃຫຍ່ຫຼວງ. ທ່ານພຽງແຕ່ຕ້ອງການເພີ່ມຊັບພະຍາກອນໃສ່ stack, ແລະໃນຂະນະທີ່ທ່ານກໍາລັງເຮັດວຽກກັບ stack ຂອງທ່ານ, ທ່ານບໍ່ສາມາດລຶບຫຼືປ່ຽນຊັບພະຍາກອນນີ້. ມື້ຫນຶ່ງມັນ backfired. ມື້ຫນຶ່ງໃນ Twitch, ຜູ້ໃດຜູ້ຫນຶ່ງໄດ້ນໍາເຂົ້າກຸ່ມຄວາມປອດໄພ AWS ຂອງຄົນອື່ນໂດຍບັງເອີນເຂົ້າໄປໃນ stack Terraform ຂອງຕົນເອງໃນຂະນະທີ່ບໍ່ເປັນອັນຕະລາຍໃດໆ. ຂ້າພະເຈົ້າໄດ້ເຂົ້າໄປໃນຄໍາສັ່ງຈໍານວນຫນຶ່ງແລະ ... ກຸ່ມຄວາມປອດໄພ (ພ້ອມກັບການຈະລາຈອນຂາເຂົ້າ) ຫາຍໄປ.

Terraform ທີ່ຍິ່ງໃຫຍ່

ການຟື້ນຕົວຈາກລັດທີ່ບໍ່ຄົບຖ້ວນ

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

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

ການປ່ຽນແປງທີ່ຈະແຈ້ງກວ່າຕໍ່ກັບສະຖານະເອກະສານ

“ຕົກລົງ, ໂຫຼດ balancer, ເຈົ້າກຳລັງປ່ຽນ. ແຕ່ແນວໃດ?"

- ວິ​ສະ​ວະ​ກອນ​ກັງ​ວົນ​, ພ້ອມ​ທີ່​ຈະ​ກົດ​ປຸ່ມ "ຍອມ​ຮັບ​"​.

ບາງຄັ້ງຂ້ອຍຈໍາເປັນຕ້ອງເຮັດການຫມູນໃຊ້ບາງຢ່າງກັບຕົວດຸ່ນດ່ຽງການໂຫຼດໃນ CloudFormation stack, ເຊັ່ນການເພີ່ມຈໍານວນພອດຫຼືປ່ຽນກຸ່ມຄວາມປອດໄພ. ClouFormation ສະແດງການປ່ຽນແປງບໍ່ດີ. ຂ້ອຍ, ໃນເຂັມແລະເຂັມ, ກວດເບິ່ງໄຟລ໌ yaml ສອງຄັ້ງເພື່ອໃຫ້ແນ່ໃຈວ່າຂ້ອຍບໍ່ໄດ້ລຶບສິ່ງທີ່ຈໍາເປັນແລະບໍ່ໄດ້ເພີ່ມສິ່ງທີ່ບໍ່ຈໍາເປັນ.

Terraform ແມ່ນມີຄວາມໂປ່ງໃສຫຼາຍໃນເລື່ອງນີ້. ບາງຄັ້ງລາວກໍ່ມີຄວາມໂປ່ງໃສເກີນໄປ (ອ່ານ: ຫນ້າລໍາຄານ). ໂຊກດີ, ສະບັບຫລ້າສຸດປະກອບມີການປັບປຸງການສະແດງການປ່ຽນແປງເພື່ອໃຫ້ທ່ານສາມາດເບິ່ງເຫັນໄດ້ຊັດເຈນວ່າມີການປ່ຽນແປງຫຍັງ.

ຢືດຢຸ່ນ

ຂຽນຊອບແວກັບຫຼັງ.

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

ໂມດູນໃນ git

ການແບ່ງປັນລະຫັດ Terraform ຜ່ານຫຼາຍ stacks ແມ່ນງ່າຍກວ່າການແບ່ງປັນລະຫັດ CloudFormation. ດ້ວຍ Terraform, ທ່ານສາມາດໃສ່ລະຫັດຂອງທ່ານໃນ git repository ແລະເຂົ້າເຖິງມັນໂດຍໃຊ້ການຄວບຄຸມສະບັບ semantic. ທຸກຄົນທີ່ມີການເຂົ້າເຖິງບ່ອນເກັບມ້ຽນນີ້ສາມາດນຳໃຊ້ລະຫັດທີ່ແບ່ງປັນຄືນໃໝ່ໄດ້. ທຽບເທົ່າຂອງ CloudFormation ແມ່ນ S3, ແຕ່ມັນບໍ່ມີຜົນປະໂຫຍດດຽວກັນ, ແລະບໍ່ມີເຫດຜົນທີ່ພວກເຮົາຄວນປະຖິ້ມ git ໃນເງື່ອນໄຂຂອງ S3 ເລີຍ.

ອົງການຈັດຕັ້ງຂະຫຍາຍຕົວແລະຄວາມສາມາດໃນການແບ່ງປັນ stacks ທົ່ວໄປໄດ້ບັນລຸລະດັບທີ່ສໍາຄັນ. Terraform ເຮັດໃຫ້ມັນງ່າຍແລະເປັນທໍາມະຊາດ, ໃນຂະນະທີ່ CloudFormation ຈະເຮັດໃຫ້ເຈົ້າໂດດຜ່ານ hoops ກ່ອນທີ່ທ່ານຈະສາມາດໄດ້ຮັບບາງສິ່ງບາງຢ່າງເຊັ່ນນີ້.

ການດໍາເນີນງານເປັນລະຫັດ

"ຂໍໃຫ້ຂຽນມັນແລະຕົກລົງ."

- ວິສະວະກອນ 3 ປີກ່ອນທີ່ຈະປະດິດລົດຖີບ Terraform.

ໃນເວລາທີ່ມັນມາກັບການພັດທະນາຊອບແວ, Go ຫຼືໂຄງການ Java ບໍ່ແມ່ນພຽງແຕ່ລະຫັດ.

ລະຫັດເປັນລະຫັດ

ນອກຈາກນີ້ຍັງມີໂຄງສ້າງພື້ນຖານທີ່ມັນເຮັດວຽກ.

ພື້ນຖານໂຄງລ່າງເປັນລະຫັດ

ແຕ່ນາງມາຈາກໃສ? ວິທີການຕິດຕາມມັນ? ລະຫັດຂອງເຈົ້າຢູ່ໃສ? ຜູ້ພັດທະນາຕ້ອງການການອະນຸຍາດເຂົ້າເຖິງບໍ?

ການດໍາເນີນງານເປັນລະຫັດ

ການເປັນນັກພັດທະນາຊອບແວບໍ່ພຽງແຕ່ຫມາຍຄວາມວ່າການຂຽນລະຫັດ.

AWS ບໍ່ແມ່ນອັນດຽວ: ທ່ານອາດຈະໃຊ້ຜູ້ໃຫ້ບໍລິການອື່ນ. SignalFx, PagerDuty ຫຼື Github. ບາງທີເຈົ້າມີເຊີບເວີ Jenkins ພາຍໃນສໍາລັບ CI/CD ຫຼື dashboard Grafana ພາຍໃນສໍາລັບການຕິດຕາມ. Infra as Code ຖືກເລືອກສໍາລັບເຫດຜົນທີ່ແຕກຕ່າງກັນ, ແລະແຕ່ລະຄົນມີຄວາມສໍາຄັນເທົ່າທຽມກັນສໍາລັບທຸກສິ່ງທຸກຢ່າງທີ່ກ່ຽວຂ້ອງກັບຊອບແວ.

ເມື່ອຂ້ອຍເຮັດວຽກຢູ່ Twitch, ພວກເຮົາໄດ້ເລັ່ງການບໍລິການພາຍໃນລະບົບການຝັງຕົວແບບປະສົມຂອງ Amazon ແລະ AWS. ພວກເຮົາ churned ອອກແລະສະຫນັບສະຫນູນ microservices ຫຼາຍ, ເພີ່ມຄ່າໃຊ້ຈ່າຍໃນການດໍາເນີນງານ. ການ​ສົນ​ທະ​ນາ​ໄດ້​ມີ​ບາງ​ຢ່າງ​ເຊັ່ນ​ນີ້​:

• Я: ແມ່ນແລ້ວ, ນັ້ນແມ່ນທ່າທາງຫຼາຍຢ່າງທີ່ຈະ overclock ຫນຶ່ງ microservice. ຂ້ອຍຈະຕ້ອງໃຊ້ຂີ້ເຫຍື້ອນີ້ເພື່ອສ້າງບັນຊີ AWS (ພວກເຮົາໄດ້ໄປ 2 ບັນຊີ ການບໍລິການຈຸລະພາກ), ແລ້ວອັນນີ້ສຳລັບຕັ້ງການແຈ້ງເຕືອນ, ອັນນີ້ສຳລັບບ່ອນເກັບລະຫັດ, ແລະອັນນີ້ສຳລັບລາຍຊື່ອີເມວ, ແລະຫຼັງຈາກນັ້ນອັນນີ້...
• ນຳ: ໃຫ້ຂຽນອັກສອນມັນແລະຕົກລົງ.
• Я: Okay, ແຕ່ script ຕົວຂອງມັນເອງຈະປ່ຽນແປງ. ພວກເຮົາຈະຕ້ອງການວິທີການກວດສອບວ່າທັງຫມົດທີ່ສ້າງໃນ Amazon gizmos ເຫຼົ່ານີ້ແມ່ນເຖິງວັນທີ.
• ນຳ: ສຽງດີ. ແລະພວກເຮົາຈະຂຽນ script ສໍາລັບເລື່ອງນີ້.
• Я: ຍິ່ງໃຫຍ່! ແລະສະຄຣິບອາດຈະຍັງຕ້ອງການກໍານົດພາລາມິເຕີ. ລາວຈະຍອມຮັບພວກເຂົາບໍ?
• ນຳ: ໃຫ້ເຂົາເອົາໄປໃສ!
• Я: ຂະບວນການອາດຈະມີການປ່ຽນແປງ ແລະຄວາມເຂົ້າກັນໄດ້ໃນດ້ານຫຼັງຈະສູນເສຍໄປ. ບາງປະເພດຂອງການຄວບຄຸມສະບັບ semantic ຈະຕ້ອງໄດ້.
• ນຳ: ຄວາມຄິດທີ່ຍິ່ງໃຫຍ່!
• Я: ເຄື່ອງມືສາມາດປ່ຽນແປງໄດ້ດ້ວຍຕົນເອງ, ພາຍໃນການໂຕ້ຕອບຜູ້ໃຊ້. ພວກເຮົາຈະຕ້ອງການວິທີການກວດສອບ ແລະແກ້ໄຂອັນນີ້.

…3 ປີຕໍ່ມາ:

• ນຳ: ແລະພວກເຮົາໄດ້ຮັບ terraform.

ສົມບັດສິນຂອງເລື່ອງແມ່ນ: ເຖິງແມ່ນວ່າທ່ານ head over heels ໃນທຸກ Amazon, ທ່ານຍັງໃຊ້ບາງສິ່ງບາງຢ່າງທີ່ບໍ່ໄດ້ມາຈາກ AWS, ແລະການບໍລິການເຫຼົ່ານີ້ມີສະຖານະທີ່ໃຊ້ພາສາການຕັ້ງຄ່າເພື່ອຮັກສາສະຖານະນັ້ນຢູ່ໃນ sync.

CloudFormation lambda vs git modules terraform

lambda ແມ່ນການແກ້ໄຂຂອງ CloudFormation ຕໍ່ບັນຫາຕາມເຫດຜົນແບບກຳນົດເອງ. ດ້ວຍ lambda ທ່ານສາມາດເຮັດໄດ້ ສ້າງມະຫາພາກ ຫຼື ຊັບພະຍາກອນຜູ້ໃຊ້. ວິທີການນີ້ແນະນໍາຄວາມສັບສົນເພີ່ມເຕີມທີ່ບໍ່ມີຢູ່ໃນສະບັບ semantic ຂອງ Terraform ຂອງໂມດູນ git. ສໍາລັບຂ້ອຍ, ບັນຫາທີ່ກົດດັນທີ່ສຸດແມ່ນການຄຸ້ມຄອງການອະນຸຍາດສໍາລັບ lambdas ຜູ້ໃຊ້ທັງຫມົດເຫຼົ່ານີ້ (ແລະເຫຼົ່ານີ້ແມ່ນບັນຊີ AWS ຫຼາຍສິບບັນຊີ). ບັນຫາທີ່ສໍາຄັນອີກອັນຫນຶ່ງແມ່ນບັນຫາ "ແມ່ນຫຍັງມາກ່ອນ, ໄກ່ຫຼືໄຂ່?": ມັນກ່ຽວຂ້ອງກັບລະຫັດ lambda. ຫນ້າທີ່ນີ້ເອງແມ່ນໂຄງສ້າງພື້ນຖານແລະລະຫັດ, ແລະມັນເອງຕ້ອງການການຕິດຕາມແລະການປັບປຸງ. ເລັບສຸດທ້າຍໃນ coffin ແມ່ນຄວາມຫຍຸ້ງຍາກໃນການປັບປຸງການປ່ຽນແປງລະຫັດ lambda semantically; ພວກເຮົາຍັງຕ້ອງເຮັດໃຫ້ແນ່ໃຈວ່າການປະຕິບັດ stack ໂດຍບໍ່ມີຄໍາສັ່ງໂດຍກົງບໍ່ໄດ້ປ່ຽນແປງລະຫວ່າງການແລ່ນ.

ຂ້າພະເຈົ້າຈື່ໄດ້ວ່າຄັ້ງຫນຶ່ງຂ້າພະເຈົ້າຕ້ອງການສ້າງການນໍາໃຊ້ canary ສໍາລັບສະພາບແວດລ້ອມ Elastic Beanstalk ທີ່ມີການດຸ່ນດ່ຽງການໂຫຼດຄລາສສິກ. ສິ່ງທີ່ງ່າຍທີ່ສຸດທີ່ຈະເຮັດແມ່ນເພື່ອເຮັດໃຫ້ການນໍາໃຊ້ຄັ້ງທີສອງສໍາລັບ EB ຖັດຈາກສະພາບແວດລ້ອມການຜະລິດ, ດໍາເນີນການຕື່ມອີກຫນຶ່ງຂັ້ນຕອນ: ການລວມເອົາກຸ່ມການນໍາໃຊ້ canary ຂະຫນາດອັດຕະໂນມັດກັບການນໍາໃຊ້ LB ເຂົ້າໄປໃນສະພາບແວດລ້ອມການຜະລິດ. ແລະນັບຕັ້ງແຕ່ Terraform ໃຊ້ ASG beantalk ເປັນການສະຫລຸບ, ນີ້ຈະຮຽກຮ້ອງໃຫ້ມີ 4 ເສັ້ນເພີ່ມເຕີມຂອງລະຫັດໃນ Terraform. ເມື່ອຂ້ອຍຖາມວ່າມີການແກ້ໄຂທຽບເທົ່າໃນ CloudFormation, ພວກເຂົາຊີ້ຂ້ອຍໄປຫາບ່ອນເກັບມ້ຽນ git ທັງຫມົດທີ່ມີທໍ່ສົ່ງແລະທຸກສິ່ງທຸກຢ່າງ, ທັງຫມົດເພື່ອຜົນປະໂຫຍດຂອງລະຫັດ 4 ແຖວທີ່ບໍ່ດີຂອງ Terraform ສາມາດເຮັດໄດ້.

ມັນກວດພົບການລອຍລົມໄດ້ດີກວ່າ

ໃຫ້ແນ່ໃຈວ່າຄວາມເປັນຈິງກົງກັບຄວາມຄາດຫວັງ.

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

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

CDK ແລະອະນາຄົດຂອງ CloudFormation

CloudFormation ມີຄວາມຫຍຸ້ງຍາກໃນການຈັດການໃນລະດັບຂະຫນາດໃຫຍ່, ຂ້າມໂຄງສ້າງພື້ນຖານ. ຄວາມຫຍຸ້ງຍາກເຫຼົ່ານີ້ຈໍານວນຫຼາຍໄດ້ຮັບການຍອມຮັບແລະເຄື່ອງມືຕ້ອງການສິ່ງຕ່າງໆເຊັ່ນ aws-cdk, ກອບການກໍານົດໂຄງສ້າງພື້ນຖານຂອງຄລາວໃນລະຫັດແລະແລ່ນມັນຜ່ານ AWS CloudFormation. ມັນຈະເປັນຫນ້າສົນໃຈທີ່ຈະເບິ່ງວ່າອະນາຄົດຈະເປັນແນວໃດສໍາລັບ aws-cdk, ແຕ່ມັນຈະມີຄວາມຫຍຸ້ງຍາກໃນການແຂ່ງຂັນກັບຄວາມເຂັ້ມແຂງອື່ນໆຂອງ Terraform; ເພື່ອເຮັດໃຫ້ CloudFormation ທັນສະໄໝ, ການປ່ຽນແປງທົ່ວໂລກຈະຕ້ອງມີ.

ດັ່ງນັ້ນ Terraform ບໍ່ຜິດຫວັງ

ນີ້ແມ່ນ "ໂຄງສ້າງພື້ນຖານເປັນລະຫັດ", ແລະບໍ່ແມ່ນ "ຂໍ້ຄວາມ".

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

ຄວາມຈິງຂອງການພັດທະນາຊອບແວທີ່ດີຍັງໃຊ້ກັບ Terraform.

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

ລະຫັດບໍ່ສາມາດຖືກບັນທຶກໄວ້ໄດ້ແນວໃດ?

ຂ້າພະເຈົ້າໄດ້ເຫັນ stacks Terraform ຂະຫນາດໃຫຍ່ທີ່ບໍ່ມີເອກະສານຢ່າງແທ້ຈິງ. ທ່ານສາມາດຂຽນລະຫັດໃນຫນ້າເວັບໄດ້ແນວໃດ - ໂດຍບໍ່ມີເອກະສານຢ່າງແທ້ຈິງ? ເພີ່ມເອກະສານທີ່ອະທິບາຍຂອງທ່ານ ລະຫັດ Terraform (ເນັ້ນໃສ່ຄໍາວ່າ "ລະຫັດ"), ເປັນຫຍັງພາກນີ້ມີຄວາມສໍາຄັນຫຼາຍ, ແລະສິ່ງທີ່ທ່ານເຮັດ.

ພວກເຮົາສາມາດນຳໃຊ້ການບໍລິການທີ່ເຄີຍເປັນໜ້າຫຼັກໜຶ່ງອັນໃຫຍ່ໄດ້ແນວໃດ?

ຂ້ອຍໄດ້ເຫັນ stacks Terraform ສະລັບສັບຊ້ອນຫຼາຍທີ່ນໍາສະເຫນີເປັນໂມດູນດຽວ. ເປັນຫຍັງພວກເຮົາຈຶ່ງບໍ່ນຳໃຊ້ຊອບແວແບບນີ້? ເປັນ​ຫຍັງ​ພວກ​ເຮົາ​ຈຶ່ງ​ແບ່ງ​ໜ້າ​ທີ່​ໃຫຍ່​ອອກ​ເປັນ​ໜ້າ​ທີ່​ນ້ອຍ? ຄໍາຕອບດຽວກັນໃຊ້ກັບ Terraform. ຖ້າໂມດູນຂອງເຈົ້າໃຫຍ່ເກີນໄປ, ເຈົ້າຕ້ອງແຍກມັນອອກເປັນໂມດູນນ້ອຍໆ.

ບໍລິສັດຂອງເຈົ້າບໍ່ໄດ້ໃຊ້ຫ້ອງສະໝຸດບໍ?

ຂ້າພະເຈົ້າໄດ້ເຫັນວິທີການວິສະວະກອນ, ປັ່ນໂຄງການໃຫມ່ໂດຍໃຊ້ Terraform, stupidly copy-pased chunks huge ຈາກໂຄງການອື່ນໆເຂົ້າໄປໃນຂອງຕົນເອງ, ແລະຫຼັງຈາກນັ້ນ tinkered ກັບເຂົາເຈົ້າຈົນກ່ວາມັນເລີ່ມຕົ້ນເຮັດວຽກ. ເຈົ້າຈະເຮັດວຽກແບບນີ້ກັບລະຫັດ "combat" ໃນບໍລິສັດຂອງເຈົ້າບໍ? ພວກເຮົາບໍ່ພຽງແຕ່ໃຊ້ຫ້ອງສະຫມຸດ. ແມ່ນແລ້ວ, ບໍ່ແມ່ນທຸກຢ່າງຕ້ອງເປັນຫ້ອງສະໝຸດ, ແຕ່ພວກເຮົາຢູ່ໃສທີ່ບໍ່ມີຫ້ອງສະຫມຸດຮ່ວມກັນໃນຫຼັກການ?!

ເຈົ້າບໍ່ໄດ້ໃຊ້ PEP8 ຫຼື gofmt ບໍ?

ພາສາສ່ວນໃຫຍ່ມີຮູບແບບມາດຕະຖານທີ່ຍອມຮັບ. ໃນ Python ນີ້ແມ່ນ PEP8. ໃນ Go - gofmt . Terraform ມີ​ຂອງ​ຕົນ​ເອງ​: terraform fmt. ມ່ວນມັນເພື່ອສຸຂະພາບຂອງທ່ານ!

ເຈົ້າຈະໃຊ້ React ໂດຍບໍ່ຮູ້ JavaScript ບໍ?

ໂມດູນ Terraform ສາມາດເຮັດໃຫ້ບາງສ່ວນຂອງໂຄງສ້າງພື້ນຖານທີ່ສັບສົນທີ່ທ່ານສ້າງ, ແຕ່ນີ້ບໍ່ໄດ້ຫມາຍຄວາມວ່າທ່ານບໍ່ສາມາດ tinker ກັບມັນທັງຫມົດ. ຕ້ອງການໃຊ້ Terraform ຢ່າງຖືກຕ້ອງໂດຍບໍ່ເຂົ້າໃຈຊັບພະຍາກອນບໍ? ເຈົ້າຖືກ doomed: ເວລາຈະຜ່ານໄປ, ແລະເຈົ້າຈະບໍ່ເປັນເຈົ້າການ Terraform.

ທ່ານກໍາລັງຂຽນລະຫັດດ້ວຍ singletons ຫຼືການສັກຢາທີ່ຂຶ້ນກັບ?

ການສັກຢາການເພິ່ງພາອາໄສແມ່ນການປະຕິບັດທີ່ດີທີ່ສຸດທີ່ໄດ້ຮັບການຍອມຮັບສໍາລັບການພັດທະນາຊອບແວແລະເປັນທີ່ນິຍົມຫຼາຍກວ່າ singletons. ມັນມີປະໂຫຍດແນວໃດໃນ Terraform? ຂ້ອຍໄດ້ເຫັນໂມດູນ Terraform ທີ່ຂຶ້ນກັບລັດຫ່າງໄກສອກຫຼີກ. ແທນທີ່ຈະຂຽນໂມດູນທີ່ດຶງຂໍ້ມູນລັດຫ່າງໄກສອກຫຼີກ, ຂຽນໂມດູນທີ່ໃຊ້ພາລາມິເຕີ. ແລະຫຼັງຈາກນັ້ນຜ່ານຕົວກໍານົດການເຫຼົ່ານີ້ໄປຫາໂມດູນ.

ຫ້ອງສະຫມຸດຂອງເຈົ້າເຮັດສິບສິ່ງໄດ້ດີຫຼືສິ່ງຫນຶ່ງທີ່ຍິ່ງໃຫຍ່ບໍ?

ຫ້ອງສະຫມຸດທີ່ເຮັດວຽກດີທີ່ສຸດແມ່ນຜູ້ທີ່ສຸມໃສ່ວຽກງານຫນຶ່ງທີ່ພວກເຂົາເຮັດໄດ້ດີຫຼາຍ. ແທນທີ່ຈະຂຽນໂມດູນ Terraform ຂະຫນາດໃຫຍ່ທີ່ພະຍາຍາມເຮັດທຸກຢ່າງໃນເວລາດຽວກັນ, ສ້າງພາກສ່ວນຂອງພວກເຂົາທີ່ເຮັດສິ່ງຫນຶ່ງໄດ້ດີ. ແລະຫຼັງຈາກນັ້ນສົມທົບພວກມັນຕາມຄວາມຕ້ອງການ.

ເຈົ້າປ່ຽນແປງຫ້ອງສະໝຸດແນວໃດໂດຍບໍ່ເຂົ້າກັນໄດ້ກັບຫຼັງ?

ໂມດູນ Terraform ທົ່ວໄປ, ຄືກັບຫ້ອງສະຫມຸດປົກກະຕິ, ຕ້ອງການຕິດຕໍ່ສື່ສານການປ່ຽນແປງກັບຜູ້ໃຊ້ໂດຍທີ່ບໍ່ເຂົ້າກັນໄດ້. ມັນເປັນເລື່ອງທີ່ຫນ້າຮໍາຄານໃນເວລາທີ່ການປ່ຽນແປງເຫຼົ່ານີ້ເກີດຂື້ນໃນຫ້ອງສະຫມຸດ, ແລະມັນເປັນເລື່ອງທີ່ຫນ້າລໍາຄານໃນເວລາທີ່ການປ່ຽນແປງທີ່ບໍ່ເຂົ້າກັນໄດ້ກັບຫລັງແມ່ນເຮັດຢູ່ໃນໂມດູນ Terraform. ມັນແນະນໍາໃຫ້ໃຊ້ git tags ແລະ semver ເມື່ອໃຊ້ໂມດູນ Terraform.

ບໍລິການການຜະລິດຂອງເຈົ້າເຮັດວຽກຢູ່ໃນແລັບທັອບຂອງເຈົ້າຫຼືຢູ່ໃນສູນຂໍ້ມູນບໍ?

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

ເຈົ້າບໍ່ຂຽນແບບທົດສອບບໍ?

ວິສະວະກອນຮັບຮູ້ວ່າລະຫັດຕ້ອງໄດ້ຮັບການທົດສອບ, ແຕ່ພວກເຂົາເອງມັກຈະລືມກ່ຽວກັບການທົດສອບເມື່ອເຮັດວຽກກັບ Terraform. ສໍາລັບໂຄງສ້າງພື້ນຖານ, ນີ້ແມ່ນ fraught ກັບຊ່ວງເວລາ treacherous. ຄໍາແນະນໍາຂອງຂ້ອຍແມ່ນເພື່ອ "ທົດສອບ" ຫຼື "ສ້າງຕົວຢ່າງ" stacks ໂດຍໃຊ້ໂມດູນທີ່ສາມາດຖືກນໍາໃຊ້ຢ່າງຖືກຕ້ອງສໍາລັບການທົດສອບໃນລະຫວ່າງ CI / CD.

Terraform ແລະ microservices

ຊີວິດແລະຄວາມຕາຍຂອງບໍລິສັດບໍລິການຈຸລະພາກແມ່ນຂຶ້ນກັບຄວາມໄວ, ນະວັດຕະກໍາ, ແລະການຂັດຂວາງການເຮັດວຽກຂອງ microservice ໃຫມ່.

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

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