เทคโนโลยี

Terraform AWS Cloud: การจัดการโครงสร้างพื้นฐานที่ดี



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

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



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



ขอแนะนำ Terraform

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



Terraform เป็นเลเยอร์นามธรรมใช่และ นามธรรมรั่วไหล , ฉันเห็นด้วย. แต่ท้ายที่สุดแล้วเราอยู่ในธุรกิจการแก้ปัญหาและการจัดการนามธรรม สิ่งนี้มีจุดมุ่งหมายเพื่อให้เรามีสติสัมปชัญญะมากขึ้นในการทำงานประจำวัน

เป้าหมาย

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



ตัวอย่างทั้งหมดจะเน้นไปที่ผู้ให้บริการระบบคลาวด์รายเดียว: Amazon Web Services (AWS) นี่เป็นเพียงระบบคลาวด์ที่ฉันมีประสบการณ์มากที่สุด แต่ข้อมูลทั้งหมดควรนำไปใช้กับคลาวด์อื่นด้วย

ฉันจะปิดท้ายด้วยบันทึกบางส่วนที่ฉันหวังว่าฉันจะรู้เมื่อเริ่มต้น: ไวยากรณ์ gotchas นิสัยใจคอและกรณีที่ Terraform ไม่ได้เป็นเครื่องมือที่ฉันเลือก



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

การจัดการโครงสร้างพื้นฐานเป็นเรื่องยาก

มีหลายขั้นตอนที่เกี่ยวข้องในการตั้งค่าสภาพแวดล้อมสำหรับแอปในระบบคลาวด์ เว้นแต่คุณจะจดไว้ทั้งหมดเป็นรายการตรวจสอบโดยละเอียดและติดตามอย่างใกล้ชิด ตลอดเวลา, คุณจะทำผิด; หลังจากนั้นเราก็เป็นมนุษย์ ขั้นตอนเหล่านั้นยากที่จะแบ่งปัน คุณจำเป็นต้องจัดทำเอกสารเกี่ยวกับขั้นตอนด้วยตนเองจำนวนมากและเอกสารอาจล้าสมัยได้อย่างรวดเร็ว ตอนนี้คูณทั้งหมดนั้นด้วยจำนวนสภาพแวดล้อมทั้งหมดสำหรับแอพเดียว: dev , ทดสอบ / qa , เวที และ แยง . คุณต้องคิดถึงความปลอดภัยสำหรับแต่ละคนด้วย



เครื่องมือทุกตัวไม่มี UI ที่ฉันสามารถใช้และลืมเกี่ยวกับความซับซ้อนได้หรือไม่?

พวกเขามี UIs AWS Management Console เป็นตัวอย่างที่สำคัญ แต่เครื่องมือเหล่านั้นทำมากมายภายใต้ประทุน การคลิกเพียงครั้งเดียวบน UI อาจทำให้เกิดการเปลี่ยนแปลงที่ยากจะเข้าใจได้ โดยปกติจะไม่มีวิธียกเลิกสิ่งที่คุณทำใน UI (คำเตือน 'คุณแน่ใจหรือ' ตามปกติมักไม่เพียงพอ) ยิ่งไปกว่านั้นเป็นความคิดที่ดีเสมอที่จะมีดวงตาคู่ที่สองเพื่อตรวจสอบการเปลี่ยนแปลง แต่เมื่อเราใช้ UI เราจะต้องนั่งคุยกับบุคคลนี้ด้วยกันหรือตรวจสอบการเปลี่ยนแปลงของเรา หลังจาก ทำขึ้นซึ่งเป็นการตรวจสอบมากกว่าการทบทวน ผู้ให้บริการคลาวด์แต่ละรายมี UI ของตัวเองซึ่งคุณต้องเชี่ยวชาญ UI ออกแบบมาให้ใช้งานง่าย ( ไม่จำเป็นต้องเรียบง่าย! ) และด้วยเหตุนี้จึงมีแนวโน้มที่จะใช้วิธีการที่หลอกลวงเช่น 'นี่เป็นเพียงการปรับแต่งเล็กน้อย' หรือโปรแกรมแก้ไขด่วนสำหรับการผลิตด่วนที่คุณจะลืมใน 48 ชั่วโมง การคลิกด้วยตนเองดังกล่าวยังทำได้ยากมากที่จะทำให้เป็นอัตโนมัติ

แล้ว CLI Tools ล่ะ?

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



การจัดระเบียบเทียบกับการจัดการการกำหนดค่า

ฉันจะกำหนดประเภทของเครื่องมือและแนวปฏิบัติบางอย่างที่ใช้ในการจัดการโครงสร้างพื้นฐาน สิ่งเหล่านี้คือการจัดเตรียมและการจัดการการกำหนดค่า คุณสามารถคิดคร่าวๆว่าเป็นโมเดลการเขียนโปรแกรมที่เปิดเผยและจำเป็น (คิดว่า Prolog เทียบกับ Python) แต่ละคนมีข้อดีและข้อเสียของตัวเอง แต่ควรรู้จักพวกเขาทั้งหมดและใช้เครื่องมือที่ดีที่สุดสำหรับงานนั้น ๆ นอกจากนี้การเรียบเรียงมักเกี่ยวข้องกับระดับนามธรรมที่สูงกว่าการจัดการการกำหนดค่า

Orchestration

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



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

การจัดการการตั้งค่า

ด้านเสริมของแนวทางปฏิบัติเหล่านี้คือแนวทางการจัดการการกำหนดค่า ในกระบวนทัศน์นี้คุณระบุขั้นตอนที่แน่นอนที่เครื่องมือต้องทำเพื่อให้ได้คอนฟิกูเรชันที่ต้องการ ขั้นตอนอาจมีขนาดเล็กและรองรับระบบปฏิบัติการหลายระบบ แต่คุณต้องคิดถึงลำดับการดำเนินการอย่างจริงจัง พวกเขาไม่ตระหนักถึงสถานะปัจจุบันและสภาพแวดล้อม (เว้นแต่คุณจะตั้งโปรแกรมด้วยสิ่งนั้น) และด้วยเหตุนี้จะดำเนินการตามขั้นตอนที่คุณให้ไว้อย่างสุ่มสี่สุ่มห้า ซึ่งอาจนำไปสู่ปัญหาที่เรียกว่า การกำหนดค่าดริฟท์ โดยที่ทรัพยากรของคุณจะค่อยๆซิงโครไนซ์กับสิ่งที่ตั้งใจจะแสดงในตอนแรกโดยเฉพาะอย่างยิ่งหากคุณทำการเปลี่ยนแปลงด้วยตนเอง พวกเขายอดเยี่ยมในการจัดการและจัดเตรียมบริการในแต่ละอินสแตนซ์ ตัวอย่างของเครื่องมือที่มีความโดดเด่นในขั้นตอนการทำงานนี้ ได้แก่ Chef, Puppet, Ansible และ Salt

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

Meme of the IT Crowd รายการทีวีที่มีสโลแกนโดดเด่น: คุณลองปิดและเปิดใหม่อีกครั้งหรือไม่?

คุณควรตรวจสอบและแก้ไขปัญหาแทน ในรหัส แล้วปรับใช้

Ansible (และเครื่องมือ CM อื่น ๆ ) สามารถใช้เพื่อจัดการโครงสร้างพื้นฐานของ AWS ได้ แต่จะเกี่ยวข้องกับการทำงานจำนวนมากและมีโอกาสเกิดข้อผิดพลาดได้ง่ายขึ้นโดยเฉพาะเมื่อโครงสร้างพื้นฐานมีการเปลี่ยนแปลงบ่อยครั้งและมีความซับซ้อนเพิ่มขึ้น

กองทุนรวมอสังหาริมทรัพย์เพื่อการเฉพาะบุคคล

สิ่งสำคัญอย่างหนึ่งที่ต้องจำไว้คือแนวทางการจัดการและการกำหนดค่าไม่ขัดแย้งกัน เข้ากันได้ เป็นเรื่องที่ดีอย่างยิ่งที่จะมีกลุ่มของอินสแตนซ์ EC2 (VPS) ในกลุ่ม AutoScaling ที่จัดการโดย Terraform แต่เรียกใช้ AWS Application Image (AMI) ซึ่งเป็นภาพรวมของดิสก์ที่จัดเตรียมด้วยขั้นตอนที่จำเป็นเช่น Ansible . Terraform ยังมีแนวคิดเรื่อง“ ผู้ให้บริการ” ที่ช่วยให้คุณสามารถเรียกใช้เครื่องมือจัดเตรียมภายนอกได้เมื่อเครื่องบูทขึ้น

เอกสาร Terraform ช่วยอธิบายสิ่งนี้เพิ่มเติมและช่วยคุณวาง Terraform ในระบบนิเวศทั้งหมด

Terraform คืออะไร?

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

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

โครงสร้างพื้นฐานเป็นรหัส

Terraform เป็นแพลตฟอร์มที่ไม่เชื่อเรื่องพระเจ้า คุณสามารถใช้เพื่อจัดการเซิร์ฟเวอร์ Bare Metal หรือเซิร์ฟเวอร์ระบบคลาวด์เช่น AWS, Google Cloud Platform, OpenStack และ Azure ใน Terraform lingo สิ่งเหล่านี้เรียกว่า ผู้ให้บริการ คุณสามารถรับความรู้สึกของมาตราส่วนได้โดยการอ่าน รายชื่อผู้ให้บริการที่รองรับทั้งหมด . สามารถใช้ผู้ให้บริการหลายรายในเวลาเดียวกันได้ตัวอย่างเช่นเมื่อผู้ให้บริการ A กำหนดค่า VM ให้คุณ แต่ผู้ให้บริการ B กำหนดค่าและมอบหมายระเบียน DNS

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

ส่วนประกอบสำคัญของการตั้งค่า Terraform

  1. Terraform binary นั้นเองที่คุณมี ติดตั้ง
  2. ไฟล์ซอร์สโค้ดเช่นการกำหนดค่าของคุณ
  3. สถานะ (ทั้งในพื้นที่หรือระยะไกล) ที่แสดงถึงทรัพยากรที่ Terraform จัดการ (เพิ่มเติมในภายหลัง)

การเขียนการกำหนดค่า Terraform

คุณเขียนโค้ดการกำหนดค่า Terraform ใน *.tf ไฟล์โดยใช้ ภาษา HCL . มีตัวเลือกในการใช้รูปแบบ JSON (*.tf.json) แต่กำหนดเป้าหมายไปที่เครื่องจักรและการสร้างอัตโนมัติมากกว่ามนุษย์ ฉันแนะนำให้คุณติด HCL ฉันจะไม่เจาะลึกเกี่ยวกับไวยากรณ์ของภาษา HCL เอกสารอย่างเป็นทางการ ทำงานได้อย่างยอดเยี่ยมในการอธิบายวิธีการเขียน HCL และวิธีใช้ตัวแปรและการแก้ไข ฉันจะพูดถึงเฉพาะขั้นต่ำที่จำเป็นในการทำความเข้าใจตัวอย่างเท่านั้น

ภายในไฟล์ Terraform ส่วนใหญ่คุณกำลังจัดการกับไฟล์ ทรัพยากร และ แหล่งข้อมูล . ทรัพยากรแสดงถึงส่วนประกอบของโครงสร้างพื้นฐานของคุณเช่นอินสแตนซ์ AWS EC2 อินสแตนซ์ RDS ระเบียน DNS ของ Route53 หรือกฎในกลุ่มความปลอดภัย ช่วยให้คุณสามารถจัดเตรียมและเปลี่ยนแปลงได้ภายในสถาปัตยกรรมระบบคลาวด์

สมมติว่าคุณได้ตั้งค่า Terraform แล้วหากคุณออก terraform apply โค้ดด้านล่างจะสร้างอินสแตนซ์ EC2 ที่ทำงานได้อย่างสมบูรณ์ (แสดงเฉพาะคุณสมบัติบางอย่างเท่านั้น):

resource 'aws_instance' 'bastion' { ami = 'ami-db1688a2' # Amazon Linux 2 LTS Candidate AMI 2017.12.0 (HVM), SSD Volume Type - ami-db1688a2 instance_type = 't2.nano' key_name = '${var.key_name}' subnet_id = '${module.network.public_subnets[0]}' vpc_security_group_ids = ['${aws_security_group.bastion.id}'] monitoring = 'false' associate_public_ip_address = 'true' disable_api_termination = 'true' tags = { Name = '${var.project_tag}-bastion-${var.env}' Env = '${var.env}' ApplicationID = '${var.api_app_tag}' ApplicationRole = 'Bastion Host' Project = '${var.project_tag}' } }

ในทางกลับกันมีแหล่งข้อมูลที่ให้คุณอ่านข้อมูลเกี่ยวกับส่วนประกอบที่กำหนดโดยไม่ต้องเปลี่ยนแปลง คุณต้องการรับ AWS ID (ARN) ของใบรับรองที่ออกโดย ACM หรือไม่ คุณใช้แหล่งข้อมูล ความแตกต่างคือแหล่งข้อมูลขึ้นต้นด้วย data_ เมื่ออ้างถึงในไฟล์คอนฟิกูเรชัน

data 'aws_acm_certificate' 'ssl_cert' { domain = '*.example.com' statuses = ['ISSUED'] }

ข้างต้นอ้างถึงใบรับรอง ACM SSL ที่ออกซึ่งสามารถใช้ร่วมกับ AWS ALB ได้ ก่อนที่คุณจะทำทั้งหมดนั้นคุณต้องตั้งค่าสภาพแวดล้อมของคุณ

โครงสร้างโฟลเดอร์

สภาพแวดล้อม Terraform (และสถานะ) ถูกคั่นด้วยไดเร็กทอรี Terraform โหลดทั้งหมด *.tf ไฟล์ในไดเร็กทอรีลงในเนมสเปซเดียวดังนั้นลำดับจึงไม่สำคัญ ฉันขอแนะนำโครงสร้างไดเร็กทอรีต่อไปนี้:

/terraform/ |---> default_variables.tf (1) /stage/ (2) |---> terraform.tfvars (3) |---> default_variables.tf (4) |---> terraform.tf (5) |---> env_variables.tf (6) /prod/ //
  1. default_variables.tf - กำหนดตัวแปรระดับบนสุดทั้งหมดและเลือกค่าเริ่มต้น สามารถใช้ซ้ำได้ในแต่ละสภาพแวดล้อม (ไดเรกทอรีที่ซ้อนกัน) ด้วย symlinks
  2. /stage/ - ไดเร็กทอรีที่มีการกำหนดค่าสำหรับสภาพแวดล้อมที่แยกจากกันทั้งหมด (ที่นี่ชื่อ stage แต่อาจเป็นอะไรก็ได้) การเปลี่ยนแปลงใด ๆ ที่เกิดขึ้นภายในโฟลเดอร์นี้จะไม่ขึ้นอยู่กับสภาพแวดล้อมอื่น ๆ (env - เช่น prod) ซึ่งเป็นสิ่งที่คุณต้องการเพื่อหลีกเลี่ยงความยุ่งเหยิงในสภาพแวดล้อมการผลิตด้วยการเปลี่ยนแปลงที่ทำกับ stage!
  3. terraform.tfvars - กำหนดค่าตัวแปร .tfvars ไฟล์คล้ายกับ .env ไฟล์ที่มี key=val คู่สำหรับตัวแปรที่กำหนด ตัวอย่างเช่นระบุ AWS profile, AWS key_name และ AWS key_path ที่ฉันใช้ สามารถละเว้นได้ใน Git
  4. default_variables.tf - นี่คือ symlink ไปยังไฟล์ (2) ซึ่งช่วยให้เราแบ่งปันตัวแปรที่ไม่ขึ้นกับ env โดยไม่ต้องทำซ้ำตัวเอง
  5. terraform.tf - นี่คือการกำหนดค่าหลักของแต่ละ env; มันถือ terraform {} บล็อกซึ่งกำหนดค่าส่วนหลัง ฉันยังกำหนดค่า ผู้ให้บริการ ที่นี่.
  6. env_variables.tf - ไฟล์นี้มีตัวแปรเฉพาะ env ฉันแท็กทรัพยากรทั้งหมดด้วย Env= ใน AWS ดังนั้นไฟล์นี้มักกำหนดตัวแปรเพียงตัวเดียว: env

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

การกำหนดค่าส่วนหลัง

ฉันได้กล่าวถึงสถานะ Terraform แล้ว นี่เป็นส่วนสำคัญของเวิร์กโฟลว์ Terraform คุณอาจสงสัยว่าจำเป็นต้องมีรัฐหรือไม่ ไม่สามารถ Terraform เพียงแค่ค้นหา AWS API ตลอดเวลาเพื่อรับสถานะที่แท้จริงของโครงสร้างพื้นฐาน ถ้าคุณคิดเกี่ยวกับเรื่องนี้ Terraform จำเป็นต้องคงไว้ซึ่งการจับคู่ระหว่างสิ่งที่จัดการในไฟล์การกำหนดค่าที่เปิดเผยและสิ่งที่ไฟล์เหล่านั้นสอดคล้องกับจริง (ในสภาพแวดล้อมของผู้ให้บริการระบบคลาวด์) โปรดทราบว่าในขณะที่เขียนไฟล์การกำหนดค่า Terraform คุณไม่ต้องสนใจ ID ของเช่นอินสแตนซ์ EC2 แต่ละรายการหรือ ARN ที่จะสร้างขึ้นสำหรับกลุ่มความปลอดภัยที่คุณเผยแพร่ อย่างไรก็ตามภายใน Terraform จำเป็นต้องทราบว่าบล็อกทรัพยากรที่กำหนดแสดงถึงทรัพยากรที่เป็นรูปธรรมที่มี ID / ARN สิ่งนี้จำเป็นในการตรวจจับการเปลี่ยนแปลง ยิ่งไปกว่านั้นรัฐยังใช้เพื่อติดตามการอ้างอิงระหว่างทรัพยากร (ซึ่งเป็นสิ่งที่คุณไม่จำเป็นต้องนึกถึง!) ใช้เพื่อสร้างกราฟที่สามารถขนานและดำเนินการได้ (โดยปกติ) เช่นเคยฉันขอแนะนำให้คุณอ่านเอกสารที่ยอดเยี่ยมบน สถานะ Terraform และวัตถุประสงค์ .

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

โดยค่าเริ่มต้น Terraform จะจัดเก็บสถานะในไฟล์บนดิสก์ซึ่งอยู่ในไดเร็กทอรีการทำงานปัจจุบัน (ของแต่ละ env) เป็น terraform.tfstate ไฟล์. ไม่เป็นไรหากคุณรู้ว่าคุณจะเป็นนักพัฒนาเพียงคนเดียวในงานนี้หรือแค่เรียนรู้และทดลองใช้ Terraform ในทางเทคนิคคุณสามารถทำให้มันทำงานเป็นทีมได้เนื่องจากคุณสามารถกำหนดสถานะให้กับที่เก็บ VCS ได้ แต่คุณจะต้องตรวจสอบให้แน่ใจว่าทุกคนทำงานในสถานะเวอร์ชันล่าสุดอยู่เสมอและไม่มีใครทำการเปลี่ยนแปลงในเวลาเดียวกัน! นี่เป็นอาการปวดหัวที่สำคัญโดยทั่วไปฉันไม่แนะนำอย่างยิ่ง นอกจากนี้หากมีคนเข้าร่วมการดำเนินการแบบ single-dev ของคุณคุณจะต้องกำหนดค่าสถานที่อื่นสำหรับรัฐ

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

ขออภัยมีปัญหาไก่และไข่: ต้องสร้างถัง S3 และตาราง DynamoDB ด้วยตนเอง Terraform ไม่สามารถสร้างได้โดยอัตโนมัติเนื่องจากยังไม่มีสถานะ! มีวิธีแก้ปัญหาบางอย่างเช่น https://github.com/gruntwork-io/terragrunt โดยอัตโนมัติโดยใช้ AWS CLI แต่ฉันไม่ต้องการเบี่ยงเบนไปจากหัวข้อหลักของบล็อกโพสต์นี้

สิ่งสำคัญที่ควรทราบเกี่ยวกับการกำหนดค่าแบ็กเอนด์ S3 และ DynamoDB ได้แก่

  1. เปิดใช้งานการกำหนดเวอร์ชันบนที่เก็บข้อมูล S3 เพื่อให้ปลอดภัยจากข้อผิดพลาดของมนุษย์และ กฎหมายของ Murphy .
  2. ตาราง DynamoDB มีขีด จำกัด อัตราสำหรับการอ่านและเขียน (เรียกว่าความจุ) หากคุณทำการเปลี่ยนแปลงหลายอย่างกับสถานะรีโมตตรวจสอบให้แน่ใจว่าได้เปิดใช้งาน DynamoDB AutoScaling สำหรับตารางนั้นหรือกำหนดค่าขีด จำกัด R / W ที่สูงเพียงพอ มิฉะนั้น Terraform จะได้รับข้อผิดพลาด HTTP 400 จาก AWS API เมื่อดำเนินการโทรจำนวนมาก

เพื่อสรุปผลทั้งหมดการกำหนดค่าส่วนหลังต่อไปนี้สามารถวางไว้ใน terraform.tf เพื่อกำหนดค่าสถานะระยะไกลบน S3 และ DynamoDB

terraform { # Sometimes you may want to require a certain version of Terraform required_version = '>= 0.11.7' # Stores remote state, required for distributed teams # Bucket & dynamoDB table have to be created manually if they do not exist # See: https://github.com/hashicorp/terraform/issues/12780 backend 's3' { bucket = 'my-company-terraform-state' key = 'app-name/stage' region = 'eu-west-1' # 5/5 R/W Capacity might not be enough for heavy, burst work (resulting in 400s). Consider enabling Auto Scaling on the table. # See: http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.ProvisionedThroughput.html dynamodb_table = 'terraform-state-lock-table' } }

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

ผู้ให้บริการ

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

provider 'aws' { profile = '${var.profile}' region = '${var.region}' version = '~> 1.23.0' }

ตัวแปรสำหรับ profile และ region จะถูกเก็บไว้ใน terraform.tfvars ซึ่งอาจถูกละเว้น profile ตัวแปรหมายถึงโปรไฟล์ที่มีชื่อที่มีข้อมูลรับรองความปลอดภัยสำหรับ AWS cloud โดยใช้มาตรฐาน ไฟล์หนังสือรับรอง . โปรดทราบว่าฉันกำลังตั้งค่าบางอย่าง ข้อ จำกัด ของเวอร์ชัน . คุณไม่ต้องการให้ Terraform อัปเกรดปลั๊กอินผู้ให้บริการของคุณโดยที่คุณไม่รู้เรื่องการเริ่มต้นแบ็คเอนด์ทุกครั้ง โดยเฉพาะอย่างยิ่งมีเวอร์ชัน 2.x ของผู้ให้บริการ AWS ที่ ต้องอัพเกรดอย่างระมัดระวัง .

ทำ discord bot ยังไงคะ

การเริ่มต้นแบ็คเอนด์

การกำหนดค่าส่วนหลังแต่ละรายการต้องมีขั้นตอนการเตรียมใช้งานที่จุดเริ่มต้นและ ทุกครั้งที่มีการเปลี่ยนแปลงเกิดขึ้น . การเริ่มต้นยังกำหนดค่าโมดูล Terraform (เพิ่มเติมในภายหลัง) ดังนั้นเมื่อคุณเพิ่มสิ่งเหล่านี้คุณต้องเรียกใช้ขั้นตอนเริ่มต้นใหม่เช่นกัน การดำเนินการนี้ปลอดภัยในการเรียกใช้หลายครั้ง โปรดทราบว่าในระหว่างการกำหนดค่าเริ่มต้นของแบ็คเอนด์ Terraform ไม่สามารถอ่านตัวแปรทั้งหมดเพื่อกำหนดค่าสถานะและไม่ควรเป็นเพราะเหตุผลด้านความปลอดภัย (เช่นคีย์ลับ) เพื่อเอาชนะสิ่งนี้และในกรณีของเราให้ใช้โปรไฟล์ AWS ที่แตกต่างจากค่าเริ่มต้นคุณสามารถใช้ -backend-config ตัวเลือกพร้อมยอมรับ k=v คู่ของตัวแปร สิ่งนี้เรียกว่าการกำหนดค่าบางส่วน .

terraform init -backend-config=profile=

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

เวิร์กโฟลว์

ขั้นตอนการทำงานทั่วไปเมื่อทำงานกับโค้ด Terraform มีดังนี้:

  1. เขียนการกำหนดค่าสำหรับโครงสร้างพื้นฐานของคุณ
  2. ดูว่าจะมีการเปลี่ยนแปลงอะไรบ้าง (terraform plan)
  3. เรียกใช้งาน ที่แน่นอน การเปลี่ยนแปลงที่คุณเห็นในขั้นตอนที่ 2 (terraform apply)
  4. ก๊อต 1

แผน Terraform

Terraform plan คำสั่งจะแสดงรายการการเปลี่ยนแปลงที่จะทำกับโครงสร้างพื้นฐานของคุณเมื่อออก apply คำสั่ง ปลอดภัยที่จะออก plan หลาย ๆ ครั้งเพราะมันไม่ได้เปลี่ยนแปลงอะไรเลย

วิธีอ่านแผน

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

  1. ในกรณีของทรัพยากร ID อาจมีลักษณะดังนี้ . —e.g., aws_ecs_service.this
  2. ในกรณีของทรัพยากรภายในโมดูลเรามีชื่อโมดูลเพิ่มเติม: module... - เช่น, module.my_service_ecs_service_task.aws_ecs_service.this
  3. แหล่งข้อมูล (ภายในและภายนอกโมดูล): (module.).data.. - เช่น., module.my_service_ecs_service_task.data.aws_ecs_task_definition.this

ประเภททรัพยากรเป็นประเภทเฉพาะสำหรับผู้ให้บริการที่กำหนดและมักจะมีชื่อ (aws_…) รายการทรัพยากรที่มีอยู่ทั้งหมดสำหรับ AWS มีอยู่ใน เอกสาร .

มีการดำเนินการห้าอย่างที่แผนจะแสดงสำหรับทรัพยากรที่กำหนด:

  1. [+] เพิ่ม - ทรัพยากรใหม่จะถูกสร้างขึ้น
  2. [-] ทำลาย - ทรัพยากรจะถูกทำลายอย่างสมบูรณ์
  3. [~] แก้ไขในสถานที่ - ทรัพยากรจะถูกแก้ไขและจะมีการเปลี่ยนแปลงพารามิเตอร์อย่างน้อยหนึ่งรายการ โดยทั่วไปปลอดภัย Terraform จะแสดงให้คุณเห็นว่าจะแก้ไขพารามิเตอร์ใดและอย่างไร (ถ้าเป็นไปได้)
  4. [- / +] - ทรัพยากรจะถูกลบออก แล้วสร้างขึ้นใหม่ ด้วยพารามิเตอร์ใหม่ สิ่งนี้จะเกิดขึ้นหากมีการเปลี่ยนแปลงพารามิเตอร์ที่ไม่สามารถเปลี่ยนแทนได้ Terraform จะแสดงให้คุณเห็นว่าการเปลี่ยนแปลงใดที่บังคับให้เกิดการพักผ่อนหย่อนใจของทรัพยากรโดยมีความคิดเห็นต่อไปนี้เป็นสีแดง: (forces new resource) สิ่งนี้อาจเป็นอันตรายได้เนื่องจากมีช่วงเวลาหนึ่งที่ทรัพยากรจะไม่มีอยู่เลย นอกจากนี้ยังสามารถทำลายการอ้างอิงที่เชื่อมต่ออื่น ๆ ฉันขอแนะนำให้แก้ไขการเปลี่ยนแปลงดังกล่าวเว้นแต่คุณจะทราบว่าผลที่ตามมาจะเป็นอย่างไรหรือไม่สนใจเกี่ยวกับการหยุดทำงาน
  5. [<=] - จะอ่านแหล่งข้อมูล นี่เป็นการดำเนินการแบบอ่านอย่างเดียว

Terraform AWS - ตัวอย่าง

ด้านบนเป็นแผนตัวอย่าง การเปลี่ยนแปลงที่ฉันทำคือ:

  • เปลี่ยน instance_type ของป้อมปราการแรก
  • เพิ่มตัวอย่างป้อมปราการที่สอง
  • เปลี่ยนชื่อของกลุ่มความปลอดภัย

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

โดยปกติคำสั่ง Terraform จะยอมรับพารามิเตอร์เพิ่มเติม พารามิเตอร์ที่สำคัญที่สุดของคำสั่งแผนคือ -out ตัวเลือกซึ่งจะบันทึกแผนของคุณบนดิสก์ แผนที่บันทึกไว้นี้สามารถดำเนินการได้ (ตรงตามที่บันทึกไว้) โดยใช้คำสั่ง สิ่งนี้สำคัญมากเนื่องจากไม่เช่นนั้นอาจมีการเปลี่ยนแปลงเกิดขึ้นได้เช่นเพื่อนร่วมงานระหว่างคุณออก plan และการออก apply. ตัวอย่าง:

  1. ปัญหา plan และตรวจสอบว่าดูดี
  2. มีคนเปลี่ยนสถานะโดยที่คุณไม่รู้จัก
  3. ปัญหา apply และโอ๊ะโอมันทำอย่างอื่นนอกเหนือจากที่วางแผนไว้!

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

อีกทางเลือกหนึ่งที่มีประโยชน์คือ -destroy ซึ่งจะแสดงแผนการที่จะส่งผลให้คุณทำลายทรัพยากรทั้งหมดที่ Terraform จัดการ คุณยังสามารถกำหนดเป้าหมายทรัพยากรเฉพาะสำหรับการทำลายได้ด้วย -target ตัวเลือก

ใช้ Terraform

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

การนำเข้าทรัพยากร

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

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

โมดูล

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

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

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

ความแตกต่างระหว่างการออกแบบและเทคนิคคืออะไร?

โมดูลภายในและระยะไกล

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

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

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

module 'my-module' { source = ' [email protected] :your-company/terraform-modules.git//modules/my-module?ref=v1.1.0' ... }

ที่นี่ฉันกำลังอ้างถึงโมดูลของฉัน v1.1.0 (เส้นทางเฉพาะ) ซึ่งฉันสามารถทดสอบได้โดยอิสระจากโมดูลเดียวกันเวอร์ชันอื่น ๆ ในสภาพแวดล้อมที่แตกต่างกัน

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

การใช้โมดูล

โมดูลสามารถอ้างอิงได้อย่างง่ายดายในสภาพแวดล้อม Terraform โดยการกำหนดบล็อกโมดูลพิเศษ นี่คือตัวอย่างของบล็อกดังกล่าวสำหรับโมดูล ECS สมมุติ:

module 'my_service_ecs_cluster' { source = '../modules/ecs_cluster' cluster_name = 'my-ecs-service-${var.env}' repository_names = [ 'my-ecs-service-${var.env}/api', 'my-ecs-service-${var.env}/nginx', 'my-ecs-service-${var.env}/docs', ] service_name = 'my-ecs-service-${var.env}' ecs_instance_type = 't2.nano' min_size = '1' max_size = '1' use_autoscaling = false alb_target_group_arn = '${module.my_alb.target_group_arn}' subnets = '${local.my_private_subnets}' security_groups = '${aws_security_group.my_ecs.id}' key_name = '${var.key_name}' env_tag = '${var.env}' project_tag = '${var.project_tag}' application_tag = '${var.api_app_tag}' asg_tag = '${var.api_app_tag}-asg' }

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

Modules Registry

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

ก่อนหน้านี้คุณต้องเขียนโมดูลของคุณเองตั้งแต่เริ่มต้น (และเรียนรู้จากความผิดพลาดของคุณ) หรือใช้โมดูลที่เผยแพร่บน GitHub และที่อื่น ๆ โดยไม่มีการรับประกันใด ๆ เกี่ยวกับพฤติกรรมของพวกเขา (นอกเหนือจากการอ่านโค้ด!)

การแบ่งปันข้อมูลระหว่างสภาพแวดล้อม

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

สมมติว่า env global แบ่งปันข้อมูลกับ stage. เพื่อให้ได้ผลคุณสามารถกำหนดเอาต์พุต ในระดับหลักของสิ่งแวดล้อม ดังนี้:

output 'vpc_id' { value = '${module.network.vpc_id}' }

จากนั้นใน stage คุณกำหนดแหล่งข้อมูลที่ชี้ไปยังสถานะระยะไกลของ global:

data 'terraform_remote_state' 'global' { backend = 's3' config { bucket = 'my-app-terraform-state' key = 'terraform/global' region = '${var.region}' dynamodb_table = 'terraform-state-lock-table' profile = '${var.profile}' } }

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

vpc_id = '${data.terraform_remote_state.global.vpc_id}'

คำเตือน

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

จะรายงานปัญหาและตรวจสอบการเปลี่ยนแปลงได้ที่ไหน

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

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

ไม่สามารถโกงทางออกจาก Cloud Knowledge ได้

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

ต้องการทรัพยากรที่แยกจากกันที่มีการเชื่อมโยงอย่างชัดเจน

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

ตัวอย่างแนวทางปฏิบัติที่ดีพร้อมแหล่งข้อมูลที่เชื่อมโยงอย่างชัดเจน:

resource 'aws_security_group' 'my_sg' { name = '${var.app_tag}-my-sg' ... } resource 'aws_security_group_rule' 'rule_one' { security_group_id = '${aws_security_group.my_sg.id}' ... } resource 'aws_security_group_rule' 'rule_two' { security_group_id = '${aws_security_group.my_sg.id}' ... }

Terraform plan ตรวจไม่พบปัญหาและความขัดแย้งเสมอไป

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

Quirks ไวยากรณ์

นอกจากนี้ยังมีนิสัยแปลก ๆ ที่เกี่ยวข้องกับวิธีการออกแบบ HCLv1 (ภาษาไวยากรณ์ที่ Terraform ใช้) มันมีสองสาม นิสัยใจคอที่น่าหงุดหงิด . มีงานระหว่างทำ เพื่อจัดเตรียมโปรแกรมแยกวิเคราะห์เวอร์ชันที่ปรับปรุงแล้วสำหรับ HCLv2 วิธีที่ดีที่สุดในการอ่านข้อ จำกัด ในปัจจุบันและแผนการที่จะเอาชนะพวกเขาคือ ชุดบล็อกที่ยอดเยี่ยมนี้ . ในระหว่างนี้ มีวิธีแก้ปัญหา สำหรับคนส่วนใหญ่ ประเด็น . พวกเขาไม่สวยและจะล้มเหลวเมื่อ v0.12 ออกมา แต่เดี๋ยวก่อนมันคืออะไร

เมื่อการอัปเดตสถานะล้มเหลว

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

ปัญหาอื่นอาจเกิดขึ้นเมื่อการล็อกสถานะ (ดั้งเดิมของการซิงโครไนซ์ที่ป้องกันไม่ให้ผู้ใช้หลายคนอัปเดตสถานะเดียวกัน) ไม่สามารถลบ Terraform ได้ ซึ่งเกี่ยวข้องกับการเรียกใช้ terraform force-unlock ด้วยรหัสล็อคเพื่อลบออกด้วยตนเอง

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

เว็บแอพไปยังแอพมือถือ

ไม่ใช่ทุกสิ่งที่สนุกที่จะจัดการผ่าน Terraform

มีบางกรณีที่ Terraform ไม่ใช่เครื่องมือที่ฉันเลือก ตัวอย่างเช่นการกำหนดค่าโครงการ AWS CodePipeline และ CodeBuild (เทียบเท่า AWS ของไปป์ไลน์ CI / CD) จะยุ่งยากเมื่อทำผ่าน Terraform คุณต้องกำหนดแต่ละขั้นตอนผ่านบล็อกการกำหนดค่าที่ละเอียดมากและสิ่งต่างๆเช่น“ เข้าสู่ระบบผ่าน GitHub” นั้นซับซ้อนกว่าการใช้ UI มาก แน่นอนว่ายังคงเป็นไปได้หากคุณต้องการให้เข้ารหัส ฉันคิดว่ามันเป็นตัวเลือกที่ดีสำหรับโมดูลที่มีการเขียนอย่างดี!

สิ่งเดียวกันสำหรับการจัดการปลายทาง AWS API Gateway ในกรณีนี้การใช้ไฟล์ เฟรมเวิร์กไร้เซิร์ฟเวอร์โดยเฉพาะ น่าจะเป็นตัวเลือกที่ดีกว่า

เมื่อกำหนดค่าทรัพยากร AWS ด้วย Terraform คุณจะพบว่าตัวเองกำลังเขียนนโยบายจำนวนมาก นโยบายที่มักจะสร้างขึ้นโดยอัตโนมัติสำหรับคุณ (เมื่อใช้ UI) สำหรับสิ่งนั้นฉันขอแนะนำ AWS Visual Editor จากนั้นคัดลอก JSON ของนโยบายที่เป็นผลลัพธ์ไปยัง Terraform

สรุป

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

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

ฉันขอแนะนำส่วนขยายสำหรับการสนับสนุน Terraform ในโปรแกรมแก้ไขโค้ดต่างๆ สำหรับ Visual Studio Code มีหนึ่ง ด้วยการเน้นไวยากรณ์การจัดรูปแบบการตรวจสอบความถูกต้องและการสนับสนุนการทับถม

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

ที่เกี่ยวข้อง: Terraform เทียบกับ CloudFormation: The Definitive Guide

ทำความเข้าใจพื้นฐาน

Terraform ใช้ทำอะไร?

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

เหตุใดฉันจึงควรใช้ Terraform

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

AWS คืออะไร

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

ฉันจำเป็นต้องรู้ AWS หรือแพลตฟอร์มอื่น ๆ เพื่อใช้ Terraform หรือไม่

ใช่อย่างน้อยคุณต้องมีความเข้าใจพื้นฐานเกี่ยวกับสิ่งที่แพลตฟอร์มนั้น ๆ นำเสนอและวิธีที่ส่วนประกอบต่างๆโต้ตอบกันเพื่อสร้างการตั้งค่าการทำงาน

ฉันสามารถดูการเปลี่ยนแปลงก่อนที่จะดำเนินการกับ Terraform ได้หรือไม่

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

ระเบียบวิธี TAM: คำอธิบายและตัวอย่างการวิเคราะห์ตลาดรวมแอดเดรส

กระบวนการทางการเงิน

ระเบียบวิธี TAM: คำอธิบายและตัวอย่างการวิเคราะห์ตลาดรวมแอดเดรส
การสอนชุดสปริง: การประมวลผลชุดงานทำได้ง่ายด้วยสปริง

การสอนชุดสปริง: การประมวลผลชุดงานทำได้ง่ายด้วยสปริง

แบ็คเอนด์