คำอธิบายของโครงสร้างพื้นฐานใน Terraform สำหรับอนาคต อันตอน บาเบนโก (2018)

หลายคนรู้จักและใช้ Terraform ในการทำงานประจำวัน แต่ยังไม่มีแนวทางปฏิบัติที่ดีที่สุดสำหรับ Terraform แต่ละทีมจะต้องคิดค้นแนวทางและวิธีการของตนเอง

โครงสร้างพื้นฐานของคุณเกือบจะเริ่มต้นง่ายๆ เลย: ทรัพยากรไม่กี่อย่าง + นักพัฒนาไม่กี่คน เมื่อเวลาผ่านไปมันก็เติบโตไปในทุกทิศทาง คุณพบวิธีจัดกลุ่มทรัพยากรลงในโมดูล Terraform จัดระเบียบโค้ดลงในโฟลเดอร์ และมีอะไรผิดพลาดอีกหรือไม่ (คำสุดท้ายอันโด่งดัง)

เวลาผ่านไปและคุณรู้สึกว่าโครงสร้างพื้นฐานของคุณคือสัตว์เลี้ยงตัวใหม่ของคุณ แต่ทำไม? คุณกังวลเกี่ยวกับการเปลี่ยนแปลงที่อธิบายไม่ได้ในโครงสร้างพื้นฐาน คุณกลัวที่จะแตะต้องโครงสร้างพื้นฐานและโค้ด - เป็นผลให้คุณชะลอการทำงานใหม่หรือลดคุณภาพ...

หลังจากสามปีของการจัดการคอลเลกชันโมดูลชุมชน Terraform สำหรับ AWS บน Github และการบำรุงรักษา Terraform ในการผลิตในระยะยาว Anton Babenko ก็พร้อมที่จะแบ่งปันประสบการณ์ของเขา: วิธีเขียนโมดูล TF เพื่อไม่ให้เกิดความเสียหายในอนาคต

ในตอนท้ายของการบรรยาย ผู้เข้าร่วมจะคุ้นเคยกับหลักการจัดการทรัพยากรใน Terraform แนวทางปฏิบัติที่ดีที่สุดที่เกี่ยวข้องกับโมดูลใน Terraform และหลักการบูรณาการอย่างต่อเนื่องที่เกี่ยวข้องกับการจัดการโครงสร้างพื้นฐาน

คำออกตัว: ฉันทราบว่ารายงานนี้ลงวันที่เดือนพฤศจิกายน 2018—ผ่านไป 2 ปีแล้ว ไม่รองรับ Terraform เวอร์ชัน 0.11 ที่กล่าวถึงในรายงานอีกต่อไป ในช่วง 2 ปีที่ผ่านมา มีการเปิดตัวผลิตภัณฑ์ใหม่ 2 รายการซึ่งมีนวัตกรรม การปรับปรุง และการเปลี่ยนแปลงมากมาย โปรดใส่ใจกับสิ่งนี้และตรวจสอบเอกสาร

อ้างอิง:

• โมดูลชุมชนภูมิประเทศ + โมดูล Terraform-aws
• antonbabenko/pre-commit-terraform — รหัสการจัดรูปแบบอัตโนมัติและเอกสารประกอบ
• อันตอนบาเบงโก/terrapin - เครื่องกำเนิดโมดูล Terraform (WIP)
• antonbabenko/modules.tf-lambda — ตัวสร้างโค้ด Terraform จากไดอะแกรมภาพ (WIP)
• www.terraform-best-practices.com
• medium.com/@anton.babenko (กระทู้ใหม่อยู่ในเว็บไซต์ส่วนตัวของฉัน www.antonbabenko.com/)
• @antonbabenko - Twitter และกางเกงสแล็กต่างๆ

ฉันชื่อแอนตัน บาเบนโก บางท่านคงใช้โค้ดที่ผมเขียน ตอนนี้ฉันจะพูดเกี่ยวกับเรื่องนี้ด้วยความมั่นใจมากขึ้นกว่าเดิมเพราะฉันสามารถเข้าถึงสถิติได้

ฉันทำงานกับ Terraform และเป็นผู้เข้าร่วมและผู้สนับสนุนโครงการโอเพ่นซอร์สจำนวนมากที่เกี่ยวข้องกับ Terraform และ Amazon มาตั้งแต่ปี 2015

ตั้งแต่นั้นมา ฉันก็เขียนโค้ดมากพอที่จะทำให้มันน่าสนใจ และฉันจะพยายามบอกคุณเกี่ยวกับเรื่องนี้ตอนนี้

ฉันจะพูดถึงความซับซ้อนและข้อมูลเฉพาะของการทำงานกับ Terraform แต่นั่นไม่ใช่ประเด็นของ HighLoad จริงๆ และตอนนี้คุณจะเข้าใจว่าทำไม

เมื่อเวลาผ่านไป ฉันเริ่มเขียนโมดูล Terraform ผู้ใช้เขียนคำถาม ฉันเขียนใหม่ จากนั้นฉันก็เขียนยูทิลิตี้ต่างๆ เพื่อจัดรูปแบบโค้ดโดยใช้ hook ที่คอมมิตล่วงหน้า ฯลฯ

มีโครงการที่น่าสนใจมากมาย ฉันชอบการสร้างโค้ดเพราะฉันชอบให้คอมพิวเตอร์ทำงานให้ฉันและโปรแกรมเมอร์มากขึ้นเรื่อยๆ ดังนั้นฉันจึงกำลังสร้างตัวสร้างโค้ด Terraform จากไดอะแกรมภาพ บางทีบางท่านอาจเคยเห็นมาแล้ว เหล่านี้เป็นกล่องที่สวยงามพร้อมลูกศร และฉันคิดว่าจะดีมากหากคุณสามารถคลิกปุ่ม "ส่งออก" และรับข้อมูลทั้งหมดเป็นโค้ดได้

ฉันมาจากยูเครน ฉันอาศัยอยู่ในนอร์เวย์มาหลายปีแล้ว

นอกจากนี้ ข้อมูลสำหรับรายงานนี้รวบรวมจากผู้ที่รู้จักชื่อของฉันและพบฉันบนโซเชียลเน็ตเวิร์ก ฉันเกือบจะมีชื่อเล่นเดียวกันเสมอ

https://github.com/terraform-aws-modules
https://registry.terraform.io/namespaces/terraform-aws-modules

ดังที่ได้กล่าวไปแล้ว ฉันเป็นผู้ดูแลหลักของโมดูล Terraform AWS ซึ่งเป็นหนึ่งในพื้นที่เก็บข้อมูลที่ใหญ่ที่สุดบน GitHub ที่เราโฮสต์โมดูลสำหรับงานทั่วไปที่สุด: VPC, Autoscaling, RDS

และสิ่งที่คุณได้ยินตอนนี้เป็นพื้นฐานที่สุด หากคุณสงสัยว่าคุณเข้าใจว่า Terraform คืออะไร ก็ควรใช้เวลาอยู่ที่อื่นจะดีกว่า ที่นี่จะมีคำศัพท์ทางเทคนิคมากมาย และฉันไม่ลังเลที่จะประกาศระดับรายงานให้สูงที่สุด ซึ่งหมายความว่าฉันสามารถพูดคุยโดยใช้คำศัพท์ที่เป็นไปได้ทั้งหมดโดยไม่ต้องอธิบายมากนัก

Terraform ปรากฏในปี 2014 เป็นยูทิลิตี้ที่อนุญาตให้คุณเขียน วางแผน และจัดการโครงสร้างพื้นฐานในรูปแบบโค้ด แนวคิดหลักที่นี่คือ "โครงสร้างพื้นฐานเป็นโค้ด"

เอกสารทั้งหมดอย่างที่ผมบอกเขียนไว้แล้ว terraform.io. ฉันหวังว่าคนส่วนใหญ่จะรู้เกี่ยวกับไซต์นี้และได้อ่านเอกสารแล้ว ถ้าเป็นเช่นนั้นคุณก็มาถูกที่แล้ว

นี่คือลักษณะของไฟล์การกำหนดค่า Terraform ปกติ โดยเราจะกำหนดตัวแปรบางตัวก่อน

ในกรณีนี้ เรากำหนด "aws_region"

จากนั้นเราจะอธิบายว่าทรัพยากรใดที่เราต้องการสร้าง

เรารันคำสั่งบางคำสั่ง โดยเฉพาะ “terraform init” เพื่อโหลดการขึ้นต่อกันและผู้ให้บริการ

และเรารันคำสั่ง "terraform Apply" เพื่อตรวจสอบว่าการกำหนดค่าที่ระบุตรงกับทรัพยากรที่เราสร้างขึ้นหรือไม่ เนื่องจากเราไม่เคยสร้างสิ่งใดมาก่อน Terraform จึงแจ้งให้เราสร้างทรัพยากรเหล่านี้

เรายืนยันสิ่งนี้ ดังนั้นเราจึงสร้างถังที่เรียกว่าหอยทากทะเล

นอกจากนี้ยังมียูทิลิตี้ที่คล้ายกันหลายประการ หลายๆ คนที่ใช้ Amazon รู้จัก AWS CloudFormation หรือ Google Cloud Deployment Manager หรือ Azure Resource Manager แต่ละคนมีการดำเนินการบางอย่างของตนเองเพื่อจัดการทรัพยากรภายในผู้ให้บริการคลาวด์สาธารณะแต่ละราย Terraform มีประโยชน์อย่างยิ่งเพราะช่วยให้คุณสามารถจัดการผู้ให้บริการได้มากกว่า 100 ราย (รายละเอียดเพิ่มเติม ที่นี่)

เป้าหมายที่ Terraform ไล่ตามตั้งแต่เริ่มต้น:

• Terraform มอบมุมมองทรัพยากรแบบเดียว
• ให้คุณรองรับแพลตฟอร์มที่ทันสมัยทั้งหมด
• และ Terraform ได้รับการออกแบบตั้งแต่เริ่มต้นให้เป็นยูทิลิตี้ที่ช่วยให้คุณเปลี่ยนโครงสร้างพื้นฐานได้อย่างปลอดภัยและคาดเดาได้

ในปี 2014 คำว่า "คาดเดาได้" ฟังดูแปลกมากในบริบทนี้

Terraform เป็นยูทิลิตี้สากล หากคุณมี API คุณสามารถควบคุมทุกอย่างได้อย่างแน่นอน:

• คุณสามารถใช้ผู้ให้บริการมากกว่า 120 รายเพื่อจัดการทุกสิ่งที่คุณต้องการ
• ตัวอย่างเช่น คุณสามารถใช้ Terraform เพื่ออธิบายการเข้าถึงที่เก็บ GitHub
• คุณสามารถสร้างและปิดข้อบกพร่องใน Jira ได้ด้วย
• คุณสามารถจัดการเมตริก Relic ใหม่ได้
• คุณสามารถสร้างไฟล์ในดรอปบ็อกซ์ได้หากต้องการ

ทั้งหมดนี้ทำได้โดยใช้ผู้ให้บริการ Terraform ซึ่งมี API แบบเปิดที่สามารถอธิบายได้ใน Go

สมมติว่าเราเริ่มใช้ Terraform อ่านเอกสารบนเว็บไซต์ ดูวิดีโอ และเริ่มเขียน main.tf ดังที่ฉันแสดงไว้ในสไลด์ที่แล้ว

และทุกอย่างยอดเยี่ยมมาก คุณมีไฟล์ที่สร้าง VPC

หากคุณต้องการสร้าง VPC คุณจะต้องระบุประมาณ 12 บรรทัดเหล่านี้ อธิบายว่าคุณต้องการสร้างภูมิภาคใด cidr_block ของที่อยู่ IP ใดที่จะใช้ นั่นคือทั้งหมดที่

แน่นอนว่าโครงการก็จะค่อยๆ เติบโต

และคุณจะเพิ่มสิ่งใหม่ๆ มากมายที่นั่น เช่น ทรัพยากร แหล่งข้อมูล คุณจะรวมเข้ากับผู้ให้บริการรายใหม่ จู่ๆ คุณจะต้องใช้ Terraform เพื่อจัดการผู้ใช้ในบัญชี GitHub ของคุณ เป็นต้น คุณอาจต้องการใช้ ผู้ให้บริการ DNS ข้ามทุกสิ่ง Terraform ทำให้สิ่งนี้เป็นเรื่องง่าย

ลองดูตัวอย่างต่อไปนี้

คุณค่อยๆ เพิ่ม internet_gateway เนื่องจากคุณต้องการให้ทรัพยากรจาก VPC ของคุณมีการเข้าถึงอินเทอร์เน็ต นี่เป็นความคิดที่ดี

ผลลัพธ์คือ main.tf นี้:

นี่คือส่วนบนสุดของ main.tf

นี่คือส่วนล่างของ main.tf

จากนั้นคุณเพิ่มเครือข่ายย่อย เมื่อถึงเวลาที่คุณต้องการเพิ่มเกตเวย์ NAT เส้นทาง ตารางเส้นทาง และเครือข่ายย่อยอื่นๆ คุณจะไม่มี 38 บรรทัด แต่จะอยู่ที่ประมาณ 200-300 บรรทัด

นั่นคือไฟล์ main.tf ของคุณค่อยๆ เติบโตขึ้น และบ่อยครั้งที่ผู้คนรวมทุกอย่างไว้ในไฟล์เดียว 10-20 Kb ปรากฏใน main.tf ลองนึกภาพว่า 10-20 Kb เป็นเนื้อหาข้อความ และทุกสิ่งเชื่อมโยงกับทุกสิ่ง สิ่งนี้จะค่อยๆ กลายเป็นเรื่องยากที่จะทำงานด้วย 10-20 Kb เป็นกรณีผู้ใช้ที่ดี บางครั้งก็มากกว่านั้น และผู้คนก็ไม่ได้คิดว่ามันแย่เสมอไป

เช่นเดียวกับการเขียนโปรแกรมทั่วไป เช่น ไม่ใช่โครงสร้างพื้นฐานเป็นโค้ด เราคุ้นเคยกับการใช้คลาส แพ็คเกจ โมดูล และการจัดกลุ่มที่แตกต่างกันมากมาย Terraform ช่วยให้คุณทำสิ่งเดียวกันได้หลายอย่าง

• รหัสกำลังเติบโต
• การพึ่งพาระหว่างทรัพยากรก็เพิ่มขึ้นเช่นกัน

และเรามีความต้องการอย่างมาก เราเข้าใจว่าเราไม่สามารถอยู่แบบนี้ได้อีกต่อไป รหัสของเรามีจำนวนมหาศาล แน่นอนว่า 10-20 Kb นั้นไม่ใหญ่มาก แต่เรากำลังพูดถึงเฉพาะเครือข่ายสแต็กเท่านั้นนั่นคือ คุณเพิ่มทรัพยากรเครือข่ายเท่านั้น เราไม่ได้พูดถึง Application Load Balancer, คลัสเตอร์ ES การปรับใช้งาน, Kubernetes ฯลฯ ซึ่งสามารถรวม 100 Kb เข้าด้วยกันได้อย่างง่ายดาย หากคุณจดทั้งหมดนี้ คุณจะได้เรียนรู้ในไม่ช้าว่า Terraform มีโมดูล Terraform

โมดูล Terraform คือการกำหนดค่า Terraform ในตัวเองที่ได้รับการจัดการเป็นกลุ่ม นั่นคือทั้งหมดที่คุณต้องรู้เกี่ยวกับโมดูล Terraform พวกเขาไม่ฉลาดเลย พวกเขาไม่อนุญาตให้คุณทำการเชื่อมต่อที่ซับซ้อนโดยขึ้นอยู่กับบางสิ่งบางอย่าง ทั้งหมดนี้ตกอยู่บนไหล่ของนักพัฒนา นั่นคือนี่เป็นเพียงการกำหนดค่า Terraform บางประเภทที่คุณเขียนไว้แล้ว และคุณสามารถเรียกมันว่าเป็นกลุ่มได้

ดังนั้นเราจึงพยายามทำความเข้าใจว่าเราจะเพิ่มประสิทธิภาพโค้ดขนาด 10-20-30 Kb ของเราได้อย่างไร เราค่อยๆ ตระหนักว่าเราจำเป็นต้องใช้บางโมดูล

โมดูลประเภทแรกที่คุณพบคือโมดูลทรัพยากร พวกเขาไม่เข้าใจว่าโครงสร้างพื้นฐานของคุณเกี่ยวกับอะไร ธุรกิจของคุณเกี่ยวกับอะไร ที่ไหนและเงื่อนไขเป็นอย่างไร เหล่านี้เป็นโมดูลที่ฉันร่วมกับชุมชนโอเพ่นซอร์สดูแล และเราหยิบยกมาเป็นองค์ประกอบเริ่มต้นสำหรับโครงสร้างพื้นฐานของคุณ

ตัวอย่างของโมดูลทรัพยากร

เมื่อเราเรียกโมดูลทรัพยากร เราจะระบุว่าเราควรโหลดเนื้อหาจากเส้นทางใด

เราระบุเวอร์ชันที่เราต้องการดาวน์โหลด

เราผ่านการโต้แย้งมากมายที่นั่น นั่นคือทั้งหมดที่ นั่นคือทั้งหมดที่เราต้องรู้เมื่อใช้โมดูลนี้

หลายคนคิดว่าหากใช้เวอร์ชันล่าสุดทุกอย่างจะมีเสถียรภาพ แต่ไม่มี. โครงสร้างพื้นฐานต้องมีเวอร์ชัน เราต้องตอบอย่างชัดเจนว่าเวอร์ชันใดหรือส่วนประกอบนั้นถูกปรับใช้กับเวอร์ชันใด

นี่คือโค้ดที่อยู่ภายในโมดูลนี้ โมดูลกลุ่มความปลอดภัย ที่นี่เลื่อนไปที่บรรทัดที่ 640 การสร้างทรัพยากรกลุ่มความปลอดภัยใน Amazon ในทุกการกำหนดค่าที่เป็นไปได้ถือเป็นงานที่ไม่สำคัญอย่างยิ่ง การสร้างกลุ่มความปลอดภัยและบอกว่าต้องผ่านกฎเกณฑ์ใดนั้นไม่เพียงพอ มันจะง่ายมาก Amazon มีข้อจำกัดที่แตกต่างกันนับล้าน เช่น ถ้าคุณใช้ ตำแหน่งข้อมูล VPC, รายการคำนำหน้า, API ต่างๆ และพยายามรวมทั้งหมดนี้เข้ากับสิ่งอื่นใด Terraform ไม่อนุญาตให้คุณทำเช่นนี้ และ Amazon API ก็ไม่อนุญาตเช่นกัน ดังนั้นเราจึงจำเป็นต้องซ่อนตรรกะที่น่ากลัวทั้งหมดนี้ในโมดูลและให้รหัสผู้ใช้ที่มีลักษณะเช่นนี้

ผู้ใช้ไม่จำเป็นต้องรู้ว่ามันทำอย่างไรภายใน

โมดูลประเภทที่สองซึ่งประกอบด้วยโมดูลทรัพยากร ได้แก้ไขปัญหาที่เกี่ยวข้องกับธุรกิจของคุณแล้ว บ่อยครั้งนี่คือสถานที่ที่เป็นส่วนขยายสำหรับ Terraform และตั้งค่าที่เข้มงวดสำหรับแท็ก ตามมาตรฐานของบริษัท คุณยังสามารถเพิ่มฟังก์ชันการทำงานที่นั่นซึ่ง Terraform ไม่อนุญาตให้คุณใช้งานในปัจจุบัน นี่คือตอนนี้ ตอนนี้เวอร์ชัน 0.11 ซึ่งกำลังจะหมดยุคไปแล้ว แต่ถึงกระนั้น ตัวประมวลผลล่วงหน้า, jsonnet, เครื่องตัดคุกกี้ และสิ่งอื่น ๆ อีกมากมายยังเป็นกลไกเสริมที่ต้องใช้สำหรับงานเต็มรูปแบบ

ต่อไปฉันจะแสดงตัวอย่างบางส่วนเกี่ยวกับเรื่องนี้

โมดูลโครงสร้างพื้นฐานถูกเรียกในลักษณะเดียวกันทุกประการ

มีการระบุแหล่งที่มาของการดาวน์โหลดเนื้อหา

ค่าจำนวนมากถูกส่งผ่านและส่งผ่านไปยังโมดูลนี้

ถัดไป ภายในโมดูลนี้ โมดูลทรัพยากรจำนวนมากจะถูกเรียกใช้เพื่อสร้าง VPC หรือ Application Load Balancer หรือเพื่อสร้างกลุ่มความปลอดภัยหรือสำหรับคลัสเตอร์ Elastic Container Service

โมดูลมีสองประเภท นี่เป็นสิ่งสำคัญที่ต้องทำความเข้าใจเนื่องจากข้อมูลส่วนใหญ่ที่ฉันจัดกลุ่มไว้ในรายงานนี้ไม่ได้เขียนไว้ในเอกสารประกอบ

และเอกสารประกอบใน Terraform ในตอนนี้ค่อนข้างมีปัญหา เพราะมันบอกว่ามีคุณสมบัติเหล่านี้ คุณก็สามารถนำไปใช้ได้ แต่เธอไม่ได้บอกว่าจะใช้ฟีเจอร์เหล่านี้อย่างไร ทำไมจึงควรใช้ฟีเจอร์เหล่านี้ดีกว่า ดังนั้นผู้คนจำนวนมากจึงเขียนสิ่งที่พวกเขาไม่สามารถอยู่ด้วยได้

มาดูวิธีเขียนโมดูลเหล่านี้กันต่อไป จากนั้นเรามาดูวิธีการโทรหาพวกเขาและวิธีทำงานกับโค้ด

รีจิสทรี Terraform - https://registry.terraform.io/

เคล็ดลับ #0 คืออย่าเขียนโมดูลทรัพยากร โมดูลเหล่านี้ส่วนใหญ่เขียนไว้สำหรับคุณแล้ว อย่างที่ฉันบอกไป มันเป็นโอเพ่นซอร์ส ไม่มีตรรกะทางธุรกิจของคุณ ไม่มีค่าฮาร์ดโค้ดสำหรับที่อยู่ IP รหัสผ่าน ฯลฯ โมดูลนี้มีความยืดหยุ่นมาก และน่าจะเขียนไปแล้ว มีโมดูลมากมายสำหรับทรัพยากรจาก Amazon ประมาณ 650 และส่วนมากจะมีคุณภาพดี

ในตัวอย่างนี้ มีคนเข้ามาหาคุณแล้วพูดว่า “ฉันต้องการจัดการฐานข้อมูลได้ สร้างโมดูลเพื่อให้ฉันสามารถสร้างฐานข้อมูลได้" บุคคลนั้นไม่ทราบรายละเอียดการใช้งานของ Amazon หรือ Terraform เขาพูดง่ายๆ ว่า: "ฉันต้องการจัดการ MSSQL" นั่นคือเราหมายความว่ามันจะเรียกโมดูลของเรา ส่งประเภทเครื่องยนต์ไปที่นั่น และระบุเขตเวลา

และบุคคลไม่ควรรู้ว่าเราจะสร้างทรัพยากรที่แตกต่างกันสองรายการภายในโมดูลนี้: หนึ่งสำหรับ MSSQL ที่สองสำหรับทุกสิ่งเพียงเพราะใน Terraform 0.11 คุณไม่สามารถระบุค่าโซนเวลาเป็นตัวเลือกได้

และเมื่อออกจากโมดูลนี้บุคคลจะสามารถรับที่อยู่ได้อย่างง่ายดาย เขาจะไม่ทราบว่าเรากำลังสร้างทั้งหมดนี้จากฐานข้อมูลใดจากแหล่งข้อมูลใดเป็นการภายใน นี่เป็นองค์ประกอบที่สำคัญมากของการปกปิด และสิ่งนี้ไม่เพียงแต่ใช้กับโมดูลที่เปิดเผยต่อสาธารณะในโอเพ่นซอร์สเท่านั้น แต่ยังรวมถึงโมดูลที่คุณจะเขียนในโครงการและทีมของคุณด้วย

นี่เป็นอาร์กิวเมนต์ที่สอง ซึ่งค่อนข้างสำคัญหากคุณใช้ Terraform มาระยะหนึ่งแล้ว คุณมีพื้นที่เก็บข้อมูลสำหรับวางโมดูล Terraform ทั้งหมดสำหรับบริษัทของคุณ และเป็นเรื่องปกติที่เมื่อเวลาผ่านไปโครงการนี้จะขยายเป็นขนาดหนึ่งหรือสองเมกะไบต์ นี่เป็นเรื่องปกติ

แต่ปัญหาคือ Terraform เรียกโมดูลเหล่านี้อย่างไร ตัวอย่างเช่น หากคุณเรียกใช้โมดูลเพื่อสร้างผู้ใช้แต่ละราย Terraform จะโหลดพื้นที่เก็บข้อมูลทั้งหมดก่อน จากนั้นจึงนำทางไปยังโฟลเดอร์ที่มีโมดูลนั้นอยู่ วิธีนี้คุณจะดาวน์โหลดครั้งละหนึ่งเมกะไบต์ หากคุณจัดการผู้ใช้ 100 หรือ 200 ราย คุณจะดาวน์โหลดได้ 100 หรือ 200 เมกะไบต์ จากนั้นไปที่โฟลเดอร์นั้น โดยธรรมชาติแล้วคุณคงไม่อยากดาวน์โหลดอะไรมากมายทุกครั้งที่คุณกด "Terraform init"

https://github.com/mbtproject/mbt

มีวิธีแก้ไขปัญหานี้สองวิธี ประการแรกคือการใช้เส้นทางสัมพัทธ์ วิธีนี้คุณจะระบุในโค้ดว่าโฟลเดอร์อยู่ในเครื่อง (./) และก่อนที่คุณจะเปิดตัวสิ่งใด คุณจะต้องสร้างโคลน Git ของที่เก็บนี้ในเครื่อง ด้วยวิธีนี้คุณจะทำเพียงครั้งเดียว

แน่นอนว่ามีข้อเสียมากมาย ตัวอย่างเช่น คุณไม่สามารถใช้การกำหนดเวอร์ชันได้ และบางครั้งก็เป็นเรื่องยากที่จะอยู่ด้วย

วิธีแก้ปัญหาที่สอง หากคุณมีโมดูลย่อยจำนวนมากและคุณมีไปป์ไลน์ที่กำหนดไว้แล้ว ก็มีโปรเจ็กต์ MBT ซึ่งช่วยให้คุณรวบรวมแพ็คเกจต่างๆ มากมายจาก Monorepository และอัปโหลดไปยัง S3 นี่เป็นวิธีที่ดีมาก ดังนั้น ไฟล์ iam-user-1.0.0.zip จะมีน้ำหนักเพียง 1 Kb เนื่องจากโค้ดสำหรับสร้างทรัพยากรนี้มีขนาดเล็กมาก และมันจะทำงานเร็วขึ้นมาก

เรามาพูดถึงสิ่งที่ไม่สามารถใช้ในโมดูลได้

เหตุใดจึงมีความชั่วร้ายในโมดูล? สิ่งที่แย่ที่สุดคือการถือว่าผู้ใช้ สมมติว่าผู้ใช้เป็นตัวเลือกการตรวจสอบสิทธิ์ของผู้ให้บริการที่บุคคลอื่นสามารถใช้ได้ ตัวอย่างเช่น เราทุกคนจะซึมซับบทบาทนี้ ซึ่งหมายความว่า Terraform จะเข้ามารับหน้าที่นี้ จากนั้นจึงจะดำเนินการอื่นๆ ด้วยบทบาทนี้

และความชั่วร้ายก็คือถ้า Vasya ชอบเชื่อมต่อกับ Amazon ด้วยวิธีเดียว เช่น ใช้ตัวแปรสภาพแวดล้อมเริ่มต้น และ Petya ชอบใช้คีย์ที่แชร์ของเขาซึ่งเขามีอยู่ในที่ลับ คุณจะไม่สามารถระบุทั้งสองอย่างในนั้นได้ เทอร์ราฟอร์ม และเพื่อไม่ให้พวกเขาประสบความทุกข์ทรมาน ไม่จำเป็นต้องระบุบล็อกนี้ในโมดูล สิ่งนี้จะต้องระบุในระดับที่สูงขึ้น นั่นคือเรามีโมดูลทรัพยากร โมดูลโครงสร้างพื้นฐาน และองค์ประกอบอยู่ด้านบน และควรระบุสิ่งนี้ไว้ที่ใดที่หนึ่งที่สูงกว่า

ความชั่วร้ายประการที่สองคือผู้จัดเตรียม ความชั่วร้ายที่นี่ไม่ใช่เรื่องเล็กน้อย เพราะถ้าคุณเขียนโค้ดและมันได้ผลสำหรับคุณ คุณอาจคิดว่าถ้ามันได้ผล แล้วทำไมต้องเปลี่ยนมัน

ความชั่วร้ายก็คือคุณไม่สามารถควบคุมได้เสมอไปว่าจะเปิดตัวตัวจัดเตรียมนี้เมื่อใดในตอนแรก และประการที่สอง คุณไม่ได้ควบคุมความหมายของ aws ec2 เช่น เรากำลังพูดถึง Linux หรือ Windows อยู่ในขณะนี้ ดังนั้นคุณจึงไม่สามารถเขียนสิ่งที่จะทำงานเหมือนกันบนระบบปฏิบัติการที่แตกต่างกันหรือในกรณีผู้ใช้ที่แตกต่างกันได้

ตัวอย่างที่พบบ่อยที่สุด ซึ่งระบุไว้ในเอกสารอย่างเป็นทางการก็คือ หากคุณเขียน aws_instance และระบุอาร์กิวเมนต์จำนวนมาก ก็ไม่มีอะไรผิดปกติหากคุณระบุตัวจัดเตรียม “local-exec” ที่นั่น และเรียกใช้ ansible- หนังสือเล่น

ในความเป็นจริงใช่ไม่มีอะไรผิดปกติกับสิ่งนั้น แต่ในไม่ช้า คุณจะรู้ว่าไม่มีสิ่งนี้ใน local-exec เช่น ใน launch_configuration

และเมื่อคุณใช้ launch_configuration และคุณต้องการสร้างกลุ่มการปรับขนาดอัตโนมัติจากอินสแตนซ์เดียว ดังนั้นใน launch_configuration จะไม่มีแนวคิดเรื่อง “ตัวจัดสรร” มีแนวคิดเรื่อง “ข้อมูลผู้ใช้”

ดังนั้นวิธีแก้ปัญหาที่เป็นสากลมากขึ้นคือการใช้ข้อมูลผู้ใช้ และจะเปิดตัวบนอินสแตนซ์เอง เมื่อเปิดใช้งานอินสแตนซ์ หรือในข้อมูลผู้ใช้เดียวกัน เมื่อกลุ่มการปรับขนาดอัตโนมัติใช้ launch_configuration นี้

หากคุณยังคงต้องการเรียกใช้ Provisioner เนื่องจากเป็นส่วนประกอบที่ติดกาว เมื่อมีการสร้างทรัพยากรหนึ่งรายการ ในขณะนั้นคุณจะต้องเรียกใช้ Provisioner ซึ่งเป็นคำสั่งของคุณ มีสถานการณ์เช่นนี้มากมาย

และทรัพยากรที่ถูกต้องที่สุดสำหรับสิ่งนี้เรียกว่า null_resource Null_resource เป็นทรัพยากรจำลองที่ไม่เคยสร้างขึ้นจริง มันไม่ได้แตะต้องอะไรเลย ไม่มี API ไม่มีการปรับขนาดอัตโนมัติ แต่ช่วยให้คุณควบคุมได้ว่าจะรันคำสั่งเมื่อใด ในกรณีนี้ คำสั่งจะถูกรันระหว่างการสร้าง

ลิงค์ http://bit.ly/common-traits-in-terraform-modules

มีสัญญาณหลายอย่าง ฉันจะไม่ลงลึกถึงหมายสำคัญทั้งหมดอย่างละเอียด มีบทความเกี่ยวกับเรื่องนี้ แต่ถ้าคุณเคยทำงานกับ Terraform หรือใช้โมดูลของผู้อื่น คุณมักจะสังเกตเห็นว่าโมดูลจำนวนมาก เช่นเดียวกับโค้ดส่วนใหญ่ในโอเพ่นซอร์ส ถูกเขียนโดยผู้คนตามความต้องการของตนเอง ชายคนหนึ่งเขียนมันและแก้ไขปัญหาของเขา ฉันติดมันไว้ใน GitHub ปล่อยให้มันใช้งานได้ มันจะใช้งานได้ แต่ถ้าไม่มีเอกสารและตัวอย่างอยู่ที่นั่นก็จะไม่มีใครใช้มัน และหากไม่มีฟังก์ชันที่ช่วยให้คุณแก้ปัญหาได้มากกว่างานเฉพาะเล็กน้อยก็จะไม่มีใครใช้มันเช่นกัน มีหลายวิธีในการสูญเสียผู้ใช้

หากคุณต้องการเขียนอะไรเพื่อให้ผู้คนได้ใช้ฉันแนะนำให้ทำตามป้ายเหล่านี้

พวกเขาจะ:

• เอกสารและตัวอย่าง
• ฟังก์ชั่นครบครัน
• ค่าเริ่มต้นที่สมเหตุสมผล
• รหัสสะอาด
• การทดสอบ

การทดสอบเป็นสถานการณ์ที่แตกต่างออกไปเนื่องจากเขียนค่อนข้างยาก ฉันเชื่อมากขึ้นในเอกสารและตัวอย่าง

ดังนั้นเราจึงดูวิธีการเขียนโมดูล มีสองข้อโต้แย้ง สิ่งแรกที่สำคัญที่สุดคืออย่าเขียนถ้าทำได้ เพราะมีคนจำนวนหนึ่งทำงานเหล่านี้ก่อนคุณแล้ว และประการที่สอง หากคุณยังตัดสินใจอยู่ ให้พยายามอย่าใช้ผู้ให้บริการในโมดูลและผู้จัดเตรียม

นี่คือส่วนสีเทาของเอกสาร ตอนนี้คุณอาจกำลังคิดว่า: “มีบางอย่างไม่ชัดเจน ไม่มั่นใจ” แต่เราจะได้เห็นในอีกหกเดือน

ตอนนี้เรามาพูดถึงวิธีการเรียกโมดูลเหล่านี้กันดีกว่า

เราเข้าใจดีว่าโค้ดของเราเติบโตขึ้นเมื่อเวลาผ่านไป เราไม่มีไฟล์เดียวอีกต่อไป เรามี 20 ไฟล์แล้ว ทั้งหมดรวมอยู่ในโฟลเดอร์เดียว หรืออาจจะเป็นห้าโฟลเดอร์ บางทีเราอาจเริ่มแยกย่อยตามภูมิภาคหรือองค์ประกอบบางส่วน ถ้าอย่างนั้นเราก็เข้าใจว่าตอนนี้เรามีพื้นฐานของการซิงโครไนซ์และการเรียบเรียงแล้ว นั่นคือเราต้องเข้าใจว่าเราควรทำอย่างไรหากเราเปลี่ยนทรัพยากรเครือข่าย สิ่งที่เราควรทำกับทรัพยากรที่เหลือ จะทำให้การพึ่งพาเหล่านี้เกิดขึ้นได้อย่างไร เป็นต้น

มีสองสุดขั้ว สุดขั้วแรกคือทั้งหมดในที่เดียว เรามีไฟล์หลักหนึ่งไฟล์ ในขณะนี้ นี่คือแนวทางปฏิบัติที่ดีที่สุดอย่างเป็นทางการบนเว็บไซต์ Terraform

แต่ตอนนี้มันถูกเขียนว่าเลิกใช้แล้วและถูกลบออก เมื่อเวลาผ่านไป ชุมชน Terraform ตระหนักว่านี่ยังห่างไกลจากแนวปฏิบัติที่ดีที่สุด เนื่องจากผู้คนเริ่มใช้โปรเจ็กต์ในรูปแบบที่แตกต่างกัน และมีปัญหาอยู่ ตัวอย่างเช่น เมื่อเราแสดงรายการการขึ้นต่อกันทั้งหมดไว้ในที่เดียว มีบางสถานการณ์เมื่อเราคลิก "แผน Terraform" และจนกว่า Terraform จะอัปเดตสถานะของทรัพยากรทั้งหมด เวลาก็ผ่านไปได้มาก

เวลาส่วนใหญ่คือ 5 นาที สำหรับบางคนนี่เป็นเวลามาก ฉันเคยเห็นกรณีที่ใช้เวลา 15 นาที AWS API ใช้เวลา 15 นาทีในการพยายามค้นหาว่าเกิดอะไรขึ้นกับสถานะของทรัพยากรแต่ละรายการ นี่เป็นพื้นที่ขนาดใหญ่มาก

และแน่นอนว่าปัญหาที่เกี่ยวข้องจะปรากฏขึ้นเมื่อคุณต้องการเปลี่ยนแปลงบางสิ่งในที่เดียว จากนั้นคุณรอ 15 นาที และจะทำให้คุณเห็นการเปลี่ยนแปลงบางอย่าง คุณทะเลาะวิวาทกันเขียนว่า "ใช่" และมีบางอย่างผิดพลาด นี่เป็นตัวอย่างที่แท้จริงมาก Terraform ไม่ได้พยายามปกป้องคุณจากปัญหา นั่นคือเขียนสิ่งที่คุณต้องการ จะมีปัญหา - ปัญหาของคุณ ในขณะที่ Terraform 0.11 ไม่ได้พยายามช่วยคุณแต่อย่างใด มีสถานที่ที่น่าสนใจบางแห่งใน 0.12 ที่ให้คุณพูดว่า: “วาสยา คุณต้องการสิ่งนี้จริงๆ คุณสัมผัสได้ไหม?”

วิธีที่สองคือการลดพื้นที่นี้ กล่าวคือ การโทรจากที่หนึ่งสามารถเชื่อมต่อจากที่อื่นได้น้อยลง

ปัญหาเดียวคือคุณต้องเขียนโค้ดเพิ่มเติม เช่น คุณต้องอธิบายตัวแปรในไฟล์จำนวนมากและอัปเดตสิ่งนี้ บางคนไม่ชอบมัน นี่เป็นเรื่องปกติสำหรับฉัน และบางคนก็คิดว่า “ทำไมเขียนเรื่องนี้ต่างกัน ฉันจะรวมไว้ในที่เดียว” สิ่งนี้เป็นไปได้ แต่นี่คือสุดโต่งประการที่สอง

ใครมีชีวิตทั้งหมดนี้ในที่เดียว? หนึ่ง สอง สามคน นั่นคือมีคนใช้อยู่

และใครเป็นคนเรียกส่วนประกอบเฉพาะหนึ่งชิ้น หนึ่งบล็อกหรือหนึ่งโมดูลโครงสร้างพื้นฐาน? ห้าถึงเจ็ดคน ที่นี่หนาว.

คำตอบที่พบบ่อยที่สุดคือตรงกลาง หากโครงการมีขนาดใหญ่ คุณมักจะเจอสถานการณ์ที่ไม่มีวิธีแก้ปัญหาที่เหมาะสมและทุกอย่างไม่ได้ผล ดังนั้นคุณจึงจบลงด้วยการผสมผสาน ไม่มีอะไรผิดปกติในเรื่องนี้ ตราบใดที่คุณเข้าใจว่าทั้งสองมีข้อดี

หากมีบางอย่างเปลี่ยนแปลงใน VPC แบบสแต็กและคุณต้องการนำการเปลี่ยนแปลงเหล่านี้ไปใช้กับ EC2 กล่าวคือ คุณต้องการอัปเดตกลุ่มการปรับขนาดอัตโนมัติเนื่องจากคุณมีเครือข่ายย่อยใหม่ ฉันจะเรียกการจัดการการพึ่งพาประเภทนี้ มีวิธีแก้ไขบางประการ: ใครใช้อะไร?

ฉันสามารถแนะนำวิธีแก้ปัญหาได้ คุณสามารถใช้ Terraform เพื่อทำเวทย์มนตร์ หรือคุณสามารถใช้ makefile เพื่อใช้ Terraform ก็ได้ และดูว่ามีอะไรเปลี่ยนแปลงไปบ้างหรือไม่ คุณสามารถเปิดใช้งานได้ที่นี่

คุณชอบการตัดสินใจครั้งนี้อย่างไร? มีใครเชื่อว่านี่เป็นวิธีแก้ปัญหาที่ยอดเยี่ยมหรือไม่? ฉันเห็นรอยยิ้ม เห็นได้ชัดว่ามีความสงสัยพุ่งเข้ามา

แน่นอนอย่าลองทำที่บ้าน Terraform ไม่เคยถูกออกแบบให้รันจาก Terraform

ในรายงานฉบับหนึ่ง พวกเขาบอกฉันว่า “ไม่ นี่ใช้ไม่ได้” ประเด็นก็คือมันไม่ควรทำงาน แม้ว่ามันจะดูน่าประทับใจมากเมื่อคุณสามารถเปิด Terraform จาก Terraform และ Terraform ได้ แต่คุณไม่ควรทำเช่นนั้น Terraform ควรเริ่มต้นอย่างง่ายดายเสมอ

https://github.com/gruntwork-io/terragrunt/

หากคุณต้องการการจัดการการโทรเมื่อมีการเปลี่ยนแปลงบางอย่างในที่เดียว Terragrunt

Terragrunt เป็นโปรแกรมอรรถประโยชน์ซึ่งเป็นส่วนเสริมของ Terraform ที่ช่วยให้คุณสามารถประสานงานและจัดการการเรียกไปยังโมดูลโครงสร้างพื้นฐานได้

ไฟล์การกำหนดค่า Terraform ทั่วไปจะมีลักษณะเช่นนี้

คุณระบุโมดูลเฉพาะที่คุณต้องการโทร

โมดูลมีการพึ่งพาอะไรบ้าง?

และโมดูลนี้ยอมรับข้อโต้แย้งใดบ้าง นั่นคือทั้งหมดที่ต้องรู้เกี่ยวกับ Terragrunt

มีเอกสารประกอบอยู่ที่นั่นและมีดาว 1 ดวงบน GitHub แต่ในกรณีส่วนใหญ่นี่คือสิ่งที่คุณต้องรู้ และนี่เป็นเรื่องง่ายมากที่จะนำไปใช้ในบริษัทที่เพิ่งเริ่มทำงานกับ Terraform

ดังนั้นการเรียบเรียงก็คือ Terragrunt มีตัวเลือกอื่น ๆ

ตอนนี้เรามาพูดถึงวิธีการทำงานกับโค้ดกัน

หากคุณต้องการเพิ่มคุณสมบัติใหม่ให้กับโค้ดของคุณ ในกรณีส่วนใหญ่ การดำเนินการนี้เป็นเรื่องง่าย คุณกำลังเขียนแหล่งข้อมูลใหม่ ทุกอย่างเรียบง่าย

หากคุณมีทรัพยากรบางอย่างที่คุณสร้างไว้ล่วงหน้า เช่น คุณได้เรียนรู้เกี่ยวกับ Terraform หลังจากที่คุณเปิดบัญชี AWS และต้องการใช้ทรัพยากรที่คุณมีอยู่แล้ว ก็เหมาะสมที่จะขยายโมดูลของคุณในลักษณะนี้ เพื่อ รองรับการใช้ทรัพยากรที่มีอยู่

และสนับสนุนการสร้างทรัพยากรใหม่โดยใช้ทรัพยากรบล็อก

ในเอาต์พุตเราจะส่งคืนรหัสเอาต์พุตเสมอขึ้นอยู่กับว่าใช้อะไร

ปัญหาที่สำคัญมากประการที่สองใน Terraform 0.11 คือการทำงานกับรายการ

ปัญหาคือถ้าเรามีรายชื่อผู้ใช้ดังกล่าว

และเมื่อเราสร้างผู้ใช้เหล่านี้โดยใช้ทรัพยากรแบบบล็อก ทุกอย่างจะเป็นไปด้วยดี เราทำรายการทั้งหมดโดยสร้างไฟล์สำหรับแต่ละรายการ ทุกอย่างปกติดี. ตัวอย่างเช่นควรลบผู้ใช้ 3 ที่อยู่ตรงกลางออกจากที่นี่ จากนั้นทรัพยากรทั้งหมดที่สร้างขึ้นหลังจากนั้นจะถูกสร้างขึ้นใหม่เนื่องจากดัชนีจะเปลี่ยนไป

การทำงานกับรายการในสภาพแวดล้อมแบบมีสถานะ สภาพแวดล้อมแบบมีสถานะคืออะไร? นี่คือสถานการณ์ที่มีการสร้างค่าใหม่เมื่อมีการสร้างทรัพยากรนี้ ตัวอย่างเช่น AWS Access Key หรือ AWS Secret Key เช่น เมื่อเราสร้างผู้ใช้ เราจะได้รับ Access หรือ Secret Key ใหม่ และทุกครั้งที่เราลบผู้ใช้ ผู้ใช้รายนี้จะมีรหัสใหม่ แต่นี่ไม่ใช่ฮวงจุ้ยเพราะ user จะไม่อยากเป็นเพื่อนกับเราถ้าเราสร้าง user ใหม่ให้เขาทุกครั้งที่มีคนออกจากทีม

นี่คือวิธีแก้ปัญหา นี่คือโค้ดที่เขียนด้วย Jsonnet Jsonnet เป็นภาษาเทมเพลตจาก Google

คำสั่งนี้อนุญาตให้คุณยอมรับเทมเพลตนี้ และเมื่อเอาต์พุตจะส่งคืนไฟล์ json ที่สร้างขึ้นตามเทมเพลตของคุณ

เทมเพลตมีลักษณะเช่นนี้

Terraform ช่วยให้คุณทำงานกับทั้ง HCL และ Json ในลักษณะเดียวกัน ดังนั้นหากคุณมีความสามารถในการสร้าง Json คุณก็ส่งมันไปไว้ใน Terraform ได้ ไฟล์ที่มีนามสกุล .tf.json จะถูกดาวน์โหลดไฟล์สำเร็จ

จากนั้นเราก็ทำงานกับมันตามปกติ: terraform init, terramorm Apply และเราสร้างผู้ใช้สองคน

ตอนนี้เราไม่กลัวถ้ามีใครออกจากทีม เราจะแก้ไขไฟล์ json Vasya Pupkin จากไป Petya Pyatochkin ยังคงอยู่ Petya Pyatochkin จะไม่ได้รับรหัสใหม่

การรวม Terraform เข้ากับเครื่องมืออื่นๆ ไม่ใช่หน้าที่ของ Terraform จริงๆ Terraform ถูกสร้างขึ้นเพื่อเป็นแพลตฟอร์มสำหรับการสร้างทรัพยากรก็แค่นั้นแหละ และทุกสิ่งที่จะเกิดขึ้นในภายหลังไม่ใช่ความกังวลของ Terraform และไม่จำเป็นต้องสานมันในนั้น มี Ansible ซึ่งทำทุกอย่างที่คุณต้องการ

แต่สถานการณ์เกิดขึ้นเมื่อเราต้องการขยาย Terraform และเรียกใช้คำสั่งหลังจากบางสิ่งเสร็จสิ้น

วิธีแรก. เราสร้างผลลัพธ์ที่เราเขียนคำสั่งนี้

จากนั้นเราเรียกคำสั่งนี้จากเอาต์พุตของเชลล์ Terraform และระบุค่าที่เราต้องการ ดังนั้นคำสั่งจะถูกดำเนินการด้วยค่าที่ทดแทนทั้งหมด มันสะดวกสบายมาก

วิธีที่สอง. นี่คือการใช้ null_resource ขึ้นอยู่กับการเปลี่ยนแปลงในโครงสร้างพื้นฐานของเรา เราสามารถเรียก local-exe เดียวกันได้ทันทีที่ ID ของทรัพยากรบางอย่างเปลี่ยนแปลง

แน่นอนว่าทั้งหมดนี้ราบรื่นบนกระดาษ เพราะ Amazon ก็เหมือนกับผู้ให้บริการสาธารณะรายอื่นๆ ที่มี Edge Case ของตัวเองมากมาย

กรณี Edge ที่พบบ่อยที่สุดคือเมื่อคุณเปิดบัญชี AWS สิ่งสำคัญคือภูมิภาคที่คุณใช้ คุณลักษณะนี้เปิดใช้งานอยู่ที่นั่นหรือไม่ บางทีคุณอาจเปิดหลังเดือนธันวาคม 2013 บางทีคุณอาจใช้ค่าเริ่มต้นใน VPC เป็นต้น มีข้อจำกัดมากมาย และอเมซอนก็กระจายพวกมันไปทั่วเอกสาร

มีบางสิ่งที่ฉันแนะนำให้หลีกเลี่ยง

ในการเริ่มต้น ให้หลีกเลี่ยงการโต้แย้งที่ไม่เป็นความลับทั้งหมดภายในแผน Terraform หรือ Terraform CLI ทั้งหมดนี้สามารถใส่ลงในไฟล์ tfvars หรือในตัวแปรสภาพแวดล้อม

แต่คุณไม่จำเป็นต้องจำคำสั่งเวทย์มนตร์ทั้งหมดนี้ แผน Terraform – หลากหลายและไปกันเลย ตัวแปรแรกคือ var ตัวแปรที่สองคือ var ตัวแปรที่สาม ที่สี่ หลักการที่สำคัญที่สุดของโครงสร้างพื้นฐานในฐานะโค้ดที่ฉันใช้บ่อยที่สุดคือเพียงแค่ดูโค้ด ฉันควรมีความเข้าใจที่ชัดเจนเกี่ยวกับสิ่งที่ถูกนำไปใช้งาน ในสถานะใด และด้วยค่าใด ดังนั้นฉันจึงไม่ต้องอ่านเอกสารประกอบหรือถาม Vasya ว่าเขาใช้พารามิเตอร์อะไรในการสร้างคลัสเตอร์ของเรา ฉันแค่ต้องเปิดไฟล์ที่มีนามสกุล tfvars ซึ่งมักจะตรงกับสภาพแวดล้อม และดูทุกอย่างในนั้น

นอกจากนี้ อย่าใช้อาร์กิวเมนต์เป้าหมายเพื่อลดขอบเขต ด้วยเหตุนี้ การใช้โมดูลโครงสร้างพื้นฐานขนาดเล็กจึงง่ายกว่ามาก

นอกจากนี้ยังไม่จำเป็นต้องจำกัดและเพิ่มความเท่าเทียมอีกด้วย หากฉันมีทรัพยากร 150 รายการและต้องการเพิ่มการทำงานคู่ขนานของ Amazon จากค่าเริ่มต้น 10 เป็น 100 ก็มีแนวโน้มว่าจะมีข้อผิดพลาดเกิดขึ้น หรือมันอาจจะไปได้ดีในตอนนี้ แต่เมื่อ Amazon บอกว่าคุณโทรมากเกินไป คุณจะประสบปัญหา

Terraform จะพยายามรีสตาร์ทปัญหาเหล่านี้ส่วนใหญ่ แต่คุณจะไม่ประสบผลสำเร็จเลย Parallelism=1 เป็นสิ่งสำคัญหากคุณพบข้อบกพร่องบางอย่างภายใน AWS API หรือภายในผู้ให้บริการ Terraform จากนั้นคุณต้องระบุ: ความขนาน=1 และรอจนกว่า Terraform จะเสร็จสิ้นการโทรหนึ่งครั้ง จากนั้นการโทรครั้งที่สอง และครั้งที่สาม เขาจะปล่อยมันทีละคน

ผู้คนมักถามฉันว่า “ทำไมฉันถึงคิดว่าพื้นที่ทำงานของ Terraform นั้นชั่วร้าย” ฉันเชื่อว่าหลักการของโครงสร้างพื้นฐานในฐานะโค้ดคือการดูว่าโครงสร้างพื้นฐานใดถูกสร้างขึ้นและมีคุณค่าอะไรบ้าง

ผู้ใช้ไม่ได้สร้างพื้นที่ทำงาน นี่ไม่ได้หมายความว่าผู้ใช้เขียนในประเด็น GitHub ว่าเราไม่สามารถอยู่ได้หากไม่มีพื้นที่ทำงาน Terraform ไม่นะ แบบนี้ Terraform Enterprise เป็นโซลูชันเชิงพาณิชย์ Terraform จาก HashiCorp ตัดสินใจว่าเราต้องการพื้นที่ทำงาน ดังนั้นเราจึงจัดเก็บมันทิ้งไป ฉันคิดว่ามันง่ายกว่ามากที่จะใส่ไว้ในโฟลเดอร์แยกต่างหาก จากนั้นจะมีไฟล์เพิ่มอีกนิดหน่อยแต่จะชัดเจนยิ่งขึ้น

วิธีการทำงานกับรหัส? ที่จริงแล้ว การทำงานกับรายการเป็นเพียงความเจ็บปวดเท่านั้น และใช้ Terraform ได้ง่ายขึ้น นี่ไม่ใช่สิ่งที่จะทำทุกสิ่งที่ดีสำหรับคุณ ไม่จำเป็นต้องผลักทุกสิ่งที่เขียนไว้ในเอกสารที่นั่น

หัวข้อของรายงานเขียนว่า "เพื่ออนาคต" ฉันจะพูดถึงเรื่องนี้สั้น ๆ ในอนาคต นั่นหมายความว่า 0.12 จะเปิดตัวเร็วๆ นี้

0.12 เป็นของใหม่มากมาย หากคุณมาจากการเขียนโปรแกรมปกติ คุณจะพลาดบล็อกไดนามิก ลูป การดำเนินการเปรียบเทียบที่ถูกต้องและแบบมีเงื่อนไขทุกประเภท โดยที่ด้านซ้ายและด้านขวาไม่ได้คำนวณพร้อมกัน แต่ขึ้นอยู่กับสถานการณ์ คุณพลาดมันไปมาก ดังนั้น 0.12 จะช่วยแก้ปัญหาให้กับคุณ

แต่! หากคุณเขียนน้อยลงและง่ายขึ้นโดยใช้โมดูลสำเร็จรูปและโซลูชันของบุคคลที่สาม คุณจะไม่ต้องรอและหวังว่า 0.12 จะมาแก้ไขทุกอย่างให้คุณ

ขอบคุณสำหรับรายงาน! คุณพูดถึงโครงสร้างพื้นฐานเป็นโค้ดและพูดได้คำเดียวเกี่ยวกับการทดสอบ จำเป็นต้องมีการทดสอบในโมดูลหรือไม่? นี่เป็นความรับผิดชอบของใคร? ฉันจำเป็นต้องเขียนเองหรือเป็นความรับผิดชอบของโมดูล?

ปีหน้าจะเต็มไปด้วยรายงานที่เราตัดสินใจทดสอบทุกอย่างแล้ว สิ่งที่ต้องทดสอบคือคำถามที่ใหญ่ที่สุด มีการขึ้นต่อกันมากมาย และข้อจำกัดมากมายจากผู้ให้บริการหลายราย เมื่อคุณและฉันกำลังคุยกันและคุณพูดว่า: “ฉันต้องการการทดสอบ” ฉันจึงถามว่า: “คุณจะทดสอบอะไร?” คุณบอกว่าคุณจะทดสอบในภูมิภาคของคุณ แล้วฉันก็บอกว่าสิ่งนี้ใช้ไม่ได้ในภูมิภาคของฉัน นั่นคือเราจะไม่สามารถตกลงเรื่องนี้ได้ ไม่ต้องพูดถึงว่ามีปัญหาทางเทคนิคมากมาย นั่นคือจะเขียนแบบทดสอบเหล่านี้อย่างไรให้เพียงพอ

ฉันกำลังค้นคว้าหัวข้อนี้อย่างแข็งขัน เช่น วิธีสร้างการทดสอบโดยอัตโนมัติตามโครงสร้างพื้นฐานที่คุณเขียน นั่นคือถ้าคุณเขียนโค้ดนี้ ฉันก็ต้องรันมัน โดยอิงจากสิ่งนี้ ฉันสามารถสร้างการทดสอบได้

เทอราเทส เป็นหนึ่งในไลบรารี่ที่ถูกพูดถึงบ่อยที่สุดที่ให้คุณเขียนการทดสอบการรวมสำหรับ Terraform นี่คือหนึ่งในยูทิลิตี้ ฉันชอบประเภท DSL เช่น rspec

แอนตัน ขอบคุณสำหรับรายงาน! ฉันชื่อวาเลรี ให้ฉันถามคำถามเชิงปรัชญาเล็กน้อย มีการจัดเตรียมแบบมีเงื่อนไข มีการปรับใช้ การจัดเตรียมสร้างโครงสร้างพื้นฐานของฉัน ในการปรับใช้ เราจะเติมสิ่งที่มีประโยชน์ เช่น เซิร์ฟเวอร์ แอปพลิเคชัน ฯลฯ และในหัวของฉัน Terraform มีไว้สำหรับการจัดเตรียมมากกว่า และ Ansible มีไว้สำหรับการปรับใช้งานมากกว่า เนื่องจาก Ansible มีไว้สำหรับโครงสร้างพื้นฐานทางกายภาพเช่นกัน อนุญาตให้คุณติดตั้ง nginx, Postgres แต่ในขณะเดียวกัน ดูเหมือนว่า Ansible จะอนุญาตการจัดเตรียม เช่น ทรัพยากรของ Amazon หรือ Google แต่ Terraform ยังอนุญาตให้คุณปรับใช้ซอฟต์แวร์บางตัวโดยใช้โมดูลของมัน จากมุมมองของคุณ มีเส้นขอบบางประเภทที่อยู่ระหว่าง Terraform และ Ansible หรือไม่ จะใช้ที่ไหนและอันไหนดีกว่ากัน? หรือตัวอย่างเช่น คุณคิดว่า Ansible เป็นขยะอยู่แล้ว คุณควรลองใช้ Terraform สำหรับทุกสิ่งหรือไม่

เป็นคำถามที่ดี วาเลรี ฉันเชื่อว่า Terraform ไม่มีการเปลี่ยนแปลงในแง่ของวัตถุประสงค์ตั้งแต่ปี 2014 มันถูกสร้างขึ้นเพื่อโครงสร้างพื้นฐานและตายเพื่อโครงสร้างพื้นฐาน เรายังคงมีและจะมีความต้องการการจัดการการกำหนดค่า Ansible ความท้าทายคือมีข้อมูลผู้ใช้อยู่ภายใน launch_configuration แล้วคุณก็ดึง Ansible เป็นต้น นี่คือความแตกต่างมาตรฐานที่ฉันชอบที่สุด

หากเรากำลังพูดถึงโครงสร้างพื้นฐานที่สวยงาม ก็ยังมีสาธารณูปโภคอย่าง Packer ที่รวบรวมภาพนี้ จากนั้น Terraform จะใช้แหล่งข้อมูลเพื่อค้นหาอิมเมจนี้และอัปเดต launch_configuration นั่นคือด้วยวิธีนี้ไปป์ไลน์คือเราดึง Tracker ก่อนแล้วจึงดึง Terraform และหากบิลด์เกิดขึ้น การเปลี่ยนแปลงใหม่ก็จะเกิดขึ้น

สวัสดี! ขอบคุณสำหรับรายงาน! ฉันชื่อ Misha บริษัท RBS คุณสามารถโทรหา Ansible ผ่านทางผู้จัดสรรเมื่อสร้างทรัพยากร Ansible ยังมีหัวข้อที่เรียกว่าสินค้าคงคลังแบบไดนามิก และก่อนอื่นคุณสามารถเรียก Terraform แล้วเรียก Ansible ซึ่งจะนำทรัพยากรจากรัฐมาดำเนินการ มีอะไรดีกว่า?

ผู้คนใช้ทั้งสองอย่างเพื่อความสำเร็จที่เท่าเทียมกัน สำหรับฉันแล้วดูเหมือนว่าพื้นที่โฆษณาแบบไดนามิกใน Ansible นั้นสะดวกหากเราไม่ได้พูดถึงกลุ่มการปรับขนาดอัตโนมัติ เนื่องจากในกลุ่มการปรับขนาดอัตโนมัติ เรามีชุดเครื่องมือของเราเองอยู่แล้ว ซึ่งเรียกว่า launch_configuration ใน launch_configuration เราบันทึกทุกอย่างที่ต้องเปิดใช้งานเมื่อเราสร้างทรัพยากรใหม่ ดังนั้น สำหรับ Amazon การใช้สินค้าคงคลังแบบไดนามิกและการอ่านไฟล์ Terraform ts ในความคิดของฉันถือว่าเกินความจำเป็น และหากคุณใช้เครื่องมืออื่นที่ไม่มีแนวคิดเรื่อง "กลุ่มการปรับขนาดอัตโนมัติ" เช่น คุณใช้ DigitalOcean หรือผู้ให้บริการรายอื่นที่ไม่มีกลุ่มการปรับขนาดอัตโนมัติ คุณจะต้องดึง API ด้วยตนเอง ค้นหาที่อยู่ IP สร้าง ไฟล์สินค้าคงคลังแบบไดนามิก และ Ansible จะเดินผ่านมันไปแล้ว นั่นคือสำหรับ Amazon จะมี launch_configuration และสำหรับสิ่งอื่นๆ จะมีสินค้าคงคลังแบบไดนามิก

ที่มา: will.com