ดูเหมือนว่านักพัฒนา Terraform จะเสนอแนวทางปฏิบัติที่ดีที่สุดที่สะดวกสำหรับการทำงานกับโครงสร้างพื้นฐาน AWS มีเพียงความแตกต่างกันนิดหน่อย เมื่อเวลาผ่านไป จำนวนสภาพแวดล้อมจะเพิ่มขึ้น โดยแต่ละสภาพแวดล้อมมีคุณสมบัติของตัวเอง สำเนาของสแต็กแอปพลิเคชันเกือบปรากฏขึ้นในภูมิภาคใกล้เคียง และโค้ด Terraform จะต้องได้รับการคัดลอกและแก้ไขอย่างระมัดระวังตามข้อกำหนดใหม่ หรือทำให้เป็นเกล็ดหิมะ
ฉันพูดถึงรูปแบบใน Terraform เพื่อต่อสู้กับความสับสนวุ่นวายและกิจวัตรแบบแมนนวลในโครงการขนาดใหญ่และยาว
วิดีโอ:
ฉันอายุ 40 ฉันทำงานด้านไอทีมา 20 ปีแล้ว ฉันทำงานให้กับ Ixtens มาเป็นเวลา 12 ปีแล้ว เรามีส่วนร่วมในการพัฒนาที่ขับเคลื่อนด้วยอีคอมเมิร์ซ และฉันก็ฝึกฝน DevOps มาเป็นเวลา 5 ปีแล้ว
เรื่องราวของฉันจะเกี่ยวกับประสบการณ์ของฉันในโครงการในบริษัทที่ฉันจะไม่เอ่ยชื่อโดยซ่อนอยู่เบื้องหลังข้อตกลงไม่เปิดเผยข้อมูล
มีการระบุตัวเลขบนสไลด์เพื่อให้เข้าใจถึงขนาดของโครงการ และทุกสิ่งที่ฉันจะพูดต่อไปเกี่ยวข้องกับอเมซอน
ฉันเข้าร่วมโครงการนี้เมื่อ 4 ปีที่แล้ว และการปรับโครงสร้างโครงสร้างพื้นฐานดำเนินไปอย่างเต็มที่เนื่องจากโครงการเติบโตขึ้น และลวดลายที่ใช้ก็ไม่เหมาะสมอีกต่อไป และด้วยการเติบโตตามแผนทั้งหมดของโครงการ จึงจำเป็นต้องคิดสิ่งใหม่ขึ้นมา
ขอบคุณ Matvey ที่เล่าให้เราฟังเมื่อวานนี้ว่าเกิดอะไรขึ้นที่ Dodo Pizza นี่คือสิ่งที่เกิดขึ้นที่นี่เมื่อ 4 ปีที่แล้ว
นักพัฒนาเข้ามาและเริ่มสร้างโค้ดโครงสร้างพื้นฐาน
เหตุผลที่ชัดเจนที่สุดว่าทำไมจึงต้องทำเช่นนี้คือเวลาในการออกสู่ตลาด จำเป็นต้องตรวจสอบให้แน่ใจว่าทีม DevOps ไม่ใช่ปัญหาคอขวดระหว่างการเปิดตัว และเหนือสิ่งอื่นใด Terraform และ Puppet ถูกใช้ในระดับแรกสุด
Terraform เป็นโครงการโอเพ่นซอร์สจาก HashiCorp และสำหรับผู้ที่ไม่รู้ด้วยซ้ำว่านี่คืออะไร สไลด์ถัดไป
โครงสร้างพื้นฐานเป็นรหัสหมายความว่าเราสามารถอธิบายโครงสร้างพื้นฐานของเราและขอให้โรบ็อตบางตัวเพื่อให้แน่ใจว่าเราได้รับทรัพยากรที่เราอธิบายไว้
ตัวอย่างเช่น เราต้องการเครื่องเสมือน เราจะอธิบายและเพิ่มพารามิเตอร์ที่จำเป็นหลายประการ
หลังจากนี้ เราจะกำหนดค่าการเข้าถึง Amazon ในคอนโซล และเราจะขอแผน Terraform แผน Terraform จะพูดว่า: "เอาล่ะ เราสามารถทำสิ่งเหล่านี้เพื่อทรัพยากรของคุณได้" และจะมีการเพิ่มทรัพยากรอย่างน้อยหนึ่งรายการ และคาดว่าจะไม่มีการเปลี่ยนแปลง
เมื่อคุณพอใจกับทุกสิ่งแล้ว คุณสามารถขอให้ Terraform สมัครได้ และ Terraform จะสร้างอินสแตนซ์ให้คุณ และคุณจะได้รับเครื่องเสมือนในระบบคลาวด์ของคุณ
นอกจากนี้โครงการของเรากำลังพัฒนา เรากำลังเพิ่มการเปลี่ยนแปลงบางอย่างที่นั่น เราขอกรณีเพิ่มเติมเราเพิ่ม 53 รายการ
และเราทำซ้ำ กรุณาวางแผน เราเห็นว่ามีแผนการเปลี่ยนแปลงอะไรบ้าง เราสมัคร. และนี่คือวิธีที่โครงสร้างพื้นฐานของเราเติบโตขึ้น
Terraform ใช้สิ่งที่เรียกว่าไฟล์สถานะ นั่นคือ การเปลี่ยนแปลงทั้งหมดที่ไปที่ Amazon จะถูกบันทึกไว้ในไฟล์ซึ่งมีทรัพยากรที่เกี่ยวข้องซึ่งสร้างขึ้นใน Amazon สำหรับแต่ละทรัพยากรที่คุณอธิบายไว้ ดังนั้น เมื่อคำอธิบายของทรัพยากรเปลี่ยนแปลง Terraform จะรู้แน่ชัดว่าต้องเปลี่ยนแปลงอะไรใน Amazon
ไฟล์สถานะเหล่านี้เดิมทีเป็นเพียงไฟล์เท่านั้น และเราเก็บไว้ใน Git ซึ่งไม่สะดวกอย่างยิ่ง มีคนลืมทำการเปลี่ยนแปลงอยู่เสมอและเกิดความขัดแย้งมากมาย
ตอนนี้คุณสามารถใช้แบ็กเอนด์ได้ เช่น Terraform ระบุไว้ในที่เก็บข้อมูลและคีย์ใดที่ควรบันทึกไฟล์สถานะ และ Terraform เองก็จะดูแลการรับไฟล์สถานะนี้ ทำสิ่งมหัศจรรย์ทั้งหมด และนำผลลัพธ์สุดท้ายกลับมา
โครงสร้างพื้นฐานของเรากำลังเติบโต นี่คือรหัสของเรา และตอนนี้เราไม่เพียงแค่ต้องการสร้างเครื่องเสมือนเท่านั้น แต่เราต้องการมีสภาพแวดล้อมการทดสอบด้วย
Terraform ช่วยให้คุณสร้างสิ่งต่าง ๆ เช่นโมดูลนั่นคืออธิบายสิ่งเดียวกันในบางโฟลเดอร์
และตัวอย่างเช่น ในการทดสอบ ให้เรียกโมดูลนี้และรับสิ่งเดียวกันกับที่เราเรียกใช้งาน Terraform ในโมดูลนั้นเอง ในการทดสอบจะมีโค้ดนี้
สำหรับการใช้งานจริง เราสามารถส่งการเปลี่ยนแปลงบางอย่างไปที่นั่นได้ เนื่องจากในการทดสอบเราไม่จำเป็นต้องมีอินสแตนซ์ขนาดใหญ่ ในการใช้งานจริง อินสแตนซ์ขนาดใหญ่ก็มีประโยชน์
แล้วผมจะกลับเข้าสู่โครงการอีกครั้ง เป็นงานที่ยาก โครงสร้างพื้นฐานที่วางแผนไว้มีขนาดใหญ่มาก และจำเป็นต้องวางโค้ดทั้งหมดเพื่อความสะดวกสำหรับทุกคน: ทั้งสำหรับผู้ที่ดำเนินการบำรุงรักษาโค้ดนี้และสำหรับผู้ที่ทำการเปลี่ยนแปลง และมีการวางแผนว่านักพัฒนาทุกคนสามารถไปแก้ไขโครงสร้างพื้นฐานตามที่จำเป็นสำหรับแพลตฟอร์มของเขาได้
นี่คือแผนผังไดเร็กทอรีที่ HashiCorp แนะนำหากคุณมีโปรเจ็กต์ขนาดใหญ่ และควรแบ่งโครงสร้างพื้นฐานทั้งหมดออกเป็นส่วนเล็กๆ และอธิบายแต่ละส่วนในโฟลเดอร์แยกกัน
การมีคลังทรัพยากรที่กว้างขวาง คุณจึงสามารถเรียกใช้สิ่งเดียวกันได้ในการทดสอบและในการใช้งานจริง
ในกรณีของเรา สิ่งนี้ไม่เหมาะสมเลย เนื่องจากสแต็กการทดสอบสำหรับนักพัฒนาหรือสำหรับการทดสอบจะต้องได้รับง่ายกว่านี้ แต่ฉันไม่ต้องการผ่านโฟลเดอร์ต่างๆ และนำไปใช้ในลำดับที่ต้องการ และกังวลว่าฐานข้อมูลจะเพิ่มขึ้น และอินสแตนซ์ที่ใช้ฐานข้อมูลนี้จะเพิ่มขึ้น ดังนั้นการทดสอบทั้งหมดจึงเริ่มต้นจากโฟลเดอร์เดียว มีการเรียกโมดูลเดียวกันที่นั่น แต่ทุกอย่างเสร็จสิ้นในการรันครั้งเดียว
Terraform ดูแลการพึ่งพาทั้งหมด และจะสร้างทรัพยากรตามลำดับเสมอเพื่อให้คุณสามารถรับที่อยู่ IP ได้ เช่น จากอินสแตนซ์ที่สร้างขึ้นใหม่ และรับที่อยู่ IP นี้ในบันทึก Route53
นอกจากนี้แพลตฟอร์มยังมีขนาดใหญ่มาก และการเปิดตัว test stack แม้ว่าจะเป็นเวลาหนึ่งชั่วโมง แม้ว่าจะเป็นเวลา 8 ชั่วโมงก็ตาม ถือเป็นการดำเนินการที่ค่อนข้างแพง
และเราทำเรื่องนี้โดยอัตโนมัติ และงานของเจนกินส์ทำให้เราสามารถรันสแต็กได้ ในนั้นจำเป็นต้องเปิดคำขอดึงพร้อมกับการเปลี่ยนแปลงที่นักพัฒนาต้องการทดสอบ ระบุตัวเลือก ส่วนประกอบ และมิติที่จำเป็นทั้งหมด หากเขาต้องการทดสอบประสิทธิภาพ เขาก็สามารถรับอินสแตนซ์เพิ่มเติมได้ หากเขาเพียงต้องตรวจสอบว่ามีแบบฟอร์มใดเปิดอยู่ เขาก็สามารถเริ่มต้นที่ค่าแรงขั้นต่ำได้ และยังระบุว่าจำเป็นต้องมีคลัสเตอร์หรือไม่ เป็นต้น
จากนั้นเจนกินส์ก็พุชเชลล์สคริปต์ ซึ่งแก้ไขโค้ดในโฟลเดอร์ Terraform เล็กน้อย ฉันลบไฟล์ที่ไม่จำเป็นออกและเพิ่มไฟล์ที่จำเป็น จากนั้นเมื่อใช้ Terraform หนึ่งครั้ง สแต็กก็จะถูกยกขึ้น
แล้วก็มีขั้นตอนอื่นที่ฉันไม่อยากทำ
เนื่องจากความจริงที่ว่าสำหรับการทดสอบเราต้องการตัวเลือกมากกว่าในการใช้งานจริงเล็กน้อย เราจึงต้องทำสำเนาของโมดูลเพื่อที่ในสำเนาเหล่านี้เราจะสามารถเพิ่มคุณสมบัติเหล่านั้นที่จำเป็นสำหรับการทดสอบเท่านั้น
และมันเกิดขึ้นว่าในการทดสอบ ฉันต้องการทดสอบการเปลี่ยนแปลงเหล่านั้นที่จะนำไปสู่การใช้งานจริงในที่สุด แต่ในความเป็นจริง มีการทดสอบสิ่งหนึ่ง และใช้สิ่งที่แตกต่างออกไปเล็กน้อยในการผลิต และมีการแตกหักเล็กน้อยในรูปแบบที่ทีมปฏิบัติการใช้การเปลี่ยนแปลงทั้งหมดในการผลิต และบางครั้งปรากฎว่าการเปลี่ยนแปลงที่ควรจะเริ่มจากการทดสอบไปสู่การใช้งานจริงยังคงอยู่ในเวอร์ชันอื่น
นอกจากนี้มีปัญหาดังกล่าวด้วยการเพิ่มบริการใหม่ซึ่งแตกต่างจากบริการที่มีอยู่แล้วเล็กน้อย และแทนที่จะแก้ไขโมดูลที่มีอยู่ เราต้องทำสำเนาและเพิ่มการเปลี่ยนแปลงที่จำเป็น
โดยพื้นฐานแล้ว Terraform ไม่ใช่ภาษาจริง นี่คือการประกาศ หากเราต้องประกาศสิ่งใด เราก็ประกาศสิ่งนั้น และมันใช้งานได้ทั้งหมด
เมื่อถึงจุดหนึ่ง เมื่อมีการพูดคุยถึงคำขอดึงของฉัน เพื่อนร่วมงานคนหนึ่งของฉันบอกว่าไม่จำเป็นต้องสร้างเกล็ดหิมะ ฉันสงสัยว่าเขาหมายถึงอะไร มีข้อเท็จจริงทางวิทยาศาสตร์ว่าไม่มีเกล็ดหิมะสองอันที่เหมือนกันในโลก พวกมันต่างกันเล็กน้อย และทันทีที่ฉันได้ยินสิ่งนี้ ฉันก็รู้สึกถึงน้ำหนักทั้งหมดของโค้ด Terraform ทันที เนื่องจากเมื่อจำเป็นต้องย้ายจากเวอร์ชันหนึ่งไปอีกเวอร์ชันหนึ่ง Terraform จึงจำเป็นต้องเปลี่ยนแปลงห่วงโซ่การหยุด กล่าวคือ โค้ดไม่สามารถทำงานร่วมกับเวอร์ชันถัดไปได้อีกต่อไป และเราต้องส่งคำขอดึงซึ่งครอบคลุมเกือบครึ่งหนึ่งของไฟล์ในโครงสร้างพื้นฐาน เพื่อนำโครงสร้างพื้นฐานไปสู่ Terraform เวอร์ชันถัดไป
และหลังจากที่เกล็ดหิมะปรากฏขึ้น รหัส Terraform ทั้งหมดที่เราได้ทำก็กลายเป็นกองหิมะก้อนใหญ่
สำหรับนักพัฒนาภายนอกที่อยู่นอกการดำเนินการ สิ่งนี้ไม่สำคัญสำหรับเขามากนัก เนื่องจากเขาได้ส่งคำขอดึง ทรัพยากรของเขาจึงเริ่มต้นขึ้น และนั่นคือทั้งหมด ไม่ใช่ความกังวลของเขาอีกต่อไป และทีมงาน DevOps ที่ทำให้แน่ใจว่าทุกอย่างเรียบร้อยดี จำเป็นต้องทำการเปลี่ยนแปลงทั้งหมดนี้ และค่าใช้จ่ายของการเปลี่ยนแปลงเหล่านี้ก็เพิ่มขึ้นอย่างมากเมื่อมีเกล็ดหิมะเพิ่มเติมแต่ละครั้ง
มีเรื่องราวเกี่ยวกับการที่นักเรียนในการสัมมนาวาดรูปวงกลมที่สมบูรณ์แบบสองวงด้วยชอล์กบนกระดานดำ และครูก็แปลกใจที่เขาวาดได้ลื่นไหลโดยไม่ต้องใช้เข็มทิศ นักเรียนตอบว่า: “ง่ายมาก ฉันใช้เวลาสองปีในกองทัพในการกลึงเครื่องบดเนื้อ”
และตลอดสี่ปีที่ฉันได้มีส่วนร่วมในโปรเจ็กต์นี้ ฉันได้ทำ Terraform มาประมาณสองปีแล้ว และแน่นอนว่า ฉันมีเคล็ดลับ คำแนะนำบางประการเกี่ยวกับวิธีลดความซับซ้อนของโค้ด Terraform ทำงานร่วมกับโค้ดได้เหมือนกับภาษาการเขียนโปรแกรม และลดภาระของนักพัฒนาที่ต้องอัปเดตโค้ดนี้ให้ทันสมัยอยู่เสมอ
สิ่งแรกที่ฉันต้องการเริ่มต้นคือ Symlinks Terraform มีโค้ดที่ซ้ำกันมากมาย ตัวอย่างเช่น การโทรหาผู้ให้บริการในเกือบทุกจุดที่เราสร้างโครงสร้างพื้นฐานจะเหมือนกัน และมีเหตุผลที่จะวางไว้ในโฟลเดอร์แยกต่างหาก และทุกที่ที่ผู้ให้บริการจำเป็นต้องสร้าง Symlinks ไปยังไฟล์นี้
ตัวอย่างเช่น ในการผลิต คุณใช้บทบาทสมมติ ซึ่งช่วยให้คุณได้รับสิทธิ์การเข้าถึงบัญชี Amazon ภายนอกบางบัญชี และเมื่อเปลี่ยนแปลงไฟล์หนึ่งไฟล์ ไฟล์ที่เหลือทั้งหมดในแผนผังทรัพยากรจะมีสิทธิ์ที่จำเป็นเพื่อให้ Terraform รู้ว่า Amazon เซ็กเมนต์ใดที่จะเข้าถึง
Symlinks ล้มเหลวที่ไหน อย่างที่ฉันบอกไป Terraform มีไฟล์สถานะ และพวกเขาก็เจ๋งมาก แต่ประเด็นก็คือ Terraform เริ่มต้นแบ็กเอนด์ตั้งแต่แรก และเขาไม่สามารถใช้ตัวแปรใด ๆ ในพารามิเตอร์เหล่านี้ได้ จะต้องเขียนเป็นข้อความเสมอ
และด้วยเหตุนี้ เมื่อมีคนสร้างทรัพยากรใหม่ เขาจะคัดลอกโค้ดบางส่วนจากโฟลเดอร์อื่น และเขาอาจทำผิดพลาดกับกุญแจหรือถังน้ำ ตัวอย่างเช่น เขาสร้างสิ่งแซนด์บ็อกซ์จากแซนด์บ็อกซ์ จากนั้นจึงสร้างมันขึ้นมาในการใช้งานจริง และอาจกลายเป็นว่าถังที่ใช้งานจริงจะถูกใช้จากแซนด์บ็อกซ์ แน่นอนว่าพวกเขาจะพบมันอย่างรวดเร็ว จะสามารถแก้ไขได้ด้วยวิธีใดวิธีหนึ่ง แต่ก็เป็นการเสียเวลาและทรัพยากรบางส่วน
เราจะทำอย่างไรต่อไป? ก่อนที่จะทำงานกับ Terraform คุณต้องเริ่มต้นใช้งานก่อน เมื่อเริ่มต้น Terraform จะดาวน์โหลดปลั๊กอินทั้งหมด เมื่อถึงจุดหนึ่งพวกเขาก็แยกจากสถาปัตยกรรมใหญ่โตไปเป็นสถาปัตยกรรมไมโครเซอร์วิสที่มากขึ้น และคุณจำเป็นต้องทำ Terraform init เสมอเพื่อที่จะดึงโมดูลทั้งหมด ปลั๊กอินทั้งหมดขึ้นมา
และคุณสามารถใช้เชลล์สคริปต์ ซึ่งประการแรกสามารถรับตัวแปรทั้งหมดได้ เชลล์สคริปต์ไม่ได้ถูกจำกัดแต่อย่างใด และประการที่สองเส้นทาง หากเราใช้เส้นทางที่อยู่ในพื้นที่เก็บข้อมูลเป็นคีย์ไปยังไฟล์สถานะเสมอ ดังนั้นข้อผิดพลาดที่นี่จะถูกกำจัด
ฉันจะรับข้อมูลได้ที่ไหน? ไฟล์ JSON. Terraform ช่วยให้คุณเขียนโครงสร้างพื้นฐานได้ไม่เพียงแต่ใน hcl (ภาษาการกำหนดค่า HashiCorp) แต่ยังเขียนใน JSON ด้วย
JSON นั้นอ่านง่ายจากเชลล์สคริปต์ ดังนั้นคุณสามารถวางไฟล์การกำหนดค่าพร้อมกับที่ฝากข้อมูลไว้ในที่ใดที่หนึ่งได้ และใช้บัคเก็ตนี้ทั้งในโค้ด Terraform และในเชลล์สคริปต์เพื่อการเริ่มต้น
เหตุใดการมีถังสำหรับ Terraform จึงเป็นเรื่องสำคัญ เพราะมีสิ่งเช่นไฟล์สถานะระยะไกล นั่นคือเมื่อฉันเพิ่มทรัพยากรเพื่อบอก Amazon: “โปรดเพิ่มอินสแตนซ์” ฉันจำเป็นต้องระบุพารามิเตอร์ที่จำเป็นจำนวนมาก
และตัวระบุเหล่านี้จะถูกจัดเก็บไว้ในโฟลเดอร์อื่น และฉันสามารถไปพูดว่า: "Terraform โปรดเรียกใช้ไฟล์สถานะของทรัพยากรนั้นและขอตัวระบุเหล่านี้มาให้ฉัน" และด้วยเหตุนี้การรวมกันบางอย่างจึงปรากฏขึ้นระหว่างภูมิภาคหรือสภาพแวดล้อมที่แตกต่างกัน
ไม่สามารถใช้ไฟล์สถานะระยะไกลได้เสมอไป ตัวอย่างเช่น คุณสร้าง VPC ด้วยมือ และโค้ด Terraform ที่สร้าง VPC จะสร้าง VPC ที่แตกต่างกันซึ่งจะใช้เวลานานมากและคุณจะต้องปรับอันหนึ่งไปเป็นอีกอันหนึ่ง เพื่อให้คุณสามารถใช้เคล็ดลับต่อไปนี้
นั่นคือสร้างโมดูลที่ดูเหมือนว่าจะสร้าง VPC และให้ตัวระบุแก่คุณ แต่ในความเป็นจริงแล้วมีเพียงไฟล์ที่มีค่าฮาร์ดโค้ดที่สามารถใช้เพื่อสร้างอินสแตนซ์เดียวกันได้
ไม่จำเป็นต้องบันทึกไฟล์สถานะในระบบคลาวด์เสมอไป ตัวอย่างเช่น เมื่อทดสอบโมดูล คุณสามารถใช้การเริ่มต้นแบ็กเอนด์ โดยที่ไฟล์จะถูกบันทึกลงในดิสก์ในขณะที่ทำการทดสอบ
ตอนนี้เล็กน้อยเกี่ยวกับการทดสอบ คุณสามารถทดสอบอะไรใน Terraform ได้บ้าง? อาจจะเป็นไปได้มากมาย แต่ผมจะพูดถึง 4 สิ่งนี้
HashiCorp มีความเข้าใจเกี่ยวกับวิธีการจัดรูปแบบโค้ด Terraform และ Terraform fmt ช่วยให้คุณสามารถจัดรูปแบบโค้ดที่คุณแก้ไขตามความเชื่อนี้ ดังนั้น การทดสอบจะต้องตรวจสอบว่าการจัดรูปแบบสอดคล้องกับสิ่งที่ HashiCorp มอบให้หรือไม่ ดังนั้นจึงไม่จำเป็นต้องเปลี่ยนตำแหน่งของวงเล็บเหลี่ยม ฯลฯ
อันถัดไปคือการตรวจสอบ Terraform มันไม่ได้ทำอะไรมากไปกว่าการตรวจสอบไวยากรณ์ - อนึ่งไม่ว่าจะจับคู่วงเล็บทั้งหมดหรือไม่ มีอะไรสำคัญที่นี่? โครงสร้างพื้นฐานของเรากว้างขวางมาก มีพ่อที่แตกต่างกันมากมายอยู่ในนั้น และในแต่ละอันคุณต้องรัน Terraform validate
ดังนั้น เพื่อเร่งการทดสอบ เราจึงเรียกใช้กระบวนการต่างๆ แบบขนานโดยใช้แบบขนาน
Parallel เป็นสิ่งที่เจ๋งมาก ใช้มันสิ
แต่ทุกครั้งที่ Terraform เริ่มต้น มันจะไปที่ HashiCorp และถามว่า “ปลั๊กอินเวอร์ชันล่าสุดคืออะไร? และปลั๊กอินที่ฉันมีในแคช – มันเป็นอันที่ถูกต้องหรือผิด?” และสิ่งนี้ก็ช้าลงทุกย่างก้าว
หากคุณบอก Terraform ว่าปลั๊กอินอยู่ที่ไหน Terraform จะพูดว่า: "เอาล่ะ นี่อาจเป็นสิ่งล่าสุดที่มีอยู่ ฉันจะไม่ไปไหน ฉันจะเริ่มตรวจสอบโค้ด Terraform ของคุณทันที”
เพื่อเติมโฟลเดอร์ด้วยปลั๊กอินที่จำเป็น เรามีโค้ด Terraform ง่ายๆ ที่ต้องเริ่มต้นใช้งาน แน่นอนว่าคุณต้องระบุผู้ให้บริการทั้งหมดที่มีส่วนร่วมในโค้ดของคุณ ไม่เช่นนั้น Terraform จะพูดว่า: "ฉันไม่รู้จักผู้ให้บริการรายใดรายหนึ่งเนื่องจากไม่ได้อยู่ในแคช"
ถัดไปคือแผน Terraform อย่างที่ฉันบอกไปแล้วว่าการพัฒนานั้นเป็นวัฏจักร เราทำการเปลี่ยนแปลงรหัส จากนั้นคุณจะต้องค้นหาว่ามีการเปลี่ยนแปลงใดบ้างที่วางแผนไว้สำหรับโครงสร้างพื้นฐาน
และเมื่อโครงสร้างพื้นฐานมีขนาดใหญ่มาก คุณสามารถเปลี่ยนหนึ่งโมดูล แก้ไขสภาพแวดล้อมการทดสอบบางส่วนหรือบางภูมิภาคเฉพาะ และทำลายบางส่วนที่อยู่ใกล้เคียงได้ ดังนั้นจึงควรจัดทำแผน Terraform สำหรับโครงสร้างพื้นฐานทั้งหมดและแสดงให้เห็นว่ามีการวางแผนการเปลี่ยนแปลงใดบ้าง
คุณสามารถทำได้อย่างชาญฉลาด ตัวอย่างเช่น เราเขียนสคริปต์ Python ที่แก้ไขการขึ้นต่อกัน และขึ้นอยู่กับสิ่งที่เปลี่ยนแปลง: โมดูล Terraform หรือเพียงส่วนประกอบเฉพาะ โมดูลจะวางแผนสำหรับโฟลเดอร์ที่ต้องพึ่งพาทั้งหมด
จะต้องจัดทำแผน Terraform เมื่อมีการร้องขอ อย่างน้อยนั่นคือสิ่งที่เราทำ
แน่นอนว่า การทดสอบทุกๆ การเปลี่ยนแปลง ทุกๆ Commit ถือเป็นเรื่องดี แต่แผนงานค่อนข้างจะมีราคาแพง และในคำขอดึงเราพูดว่า “โปรดบอกแผนให้ฉันด้วย” หุ่นยนต์เริ่มทำงาน และส่งความคิดเห็นหรือแนบแผนทั้งหมดที่คาดหวังจากการเปลี่ยนแปลงของคุณ
แผนเป็นสิ่งที่ค่อนข้างแพง ต้องใช้เวลาเนื่องจาก Terraform ไปที่ Amazon แล้วถามว่า “ยังมีอินสแตนซ์นี้อยู่หรือไม่ การปรับขนาดอัตโนมัตินี้มีพารามิเตอร์เหมือนกันทุกประการหรือไม่” และเพื่อเร่งความเร็วนี้ คุณสามารถใช้พารามิเตอร์ เช่น Refresh=false ซึ่งหมายความว่า Terraform จะดาวน์โหลดสถานะจาก S3 และจะเชื่อว่ารัฐจะตรงกับสิ่งที่อยู่ในอเมซอนทุกประการ
แผน Terraform ดังกล่าวดำเนินไปเร็วกว่ามาก แต่สถานะจะต้องสอดคล้องกับโครงสร้างพื้นฐานของคุณ เช่น บางแห่ง บางครั้งการรีเฟรช Terraform จะต้องเริ่มต้นขึ้น การรีเฟรช Terraform ทำสิ่งนั้นทุกประการ: สถานะตรงกับสิ่งที่อยู่ในโครงสร้างพื้นฐานจริง
และเราต้องพูดถึงเรื่องความปลอดภัย นี่คือจุดที่เราต้องเริ่มต้น เมื่อคุณเรียกใช้ Terraform และ Terraform ทำงานบนโครงสร้างพื้นฐานของคุณ จะมีช่องโหว่อยู่ นั่นคือคุณกำลังรันโค้ดเป็นหลัก และหากคำขอดึงข้อมูลมีโค้ดที่เป็นอันตรายบางประเภท ก็สามารถดำเนินการได้บนโครงสร้างพื้นฐานที่มีสิทธิ์เข้าถึงมากเกินไป ดังนั้นควรระวังเมื่อคุณใช้แผน Terraform
สิ่งต่อไปที่ฉันอยากจะพูดถึงคือการทดสอบข้อมูลผู้ใช้
ข้อมูลผู้ใช้คืออะไร? ใน Amazon เมื่อเราสร้างอินสแตนซ์ เราสามารถส่งจดหมายบางตัวพร้อมกับอินสแตนซ์ได้ - ข้อมูลเมตา เมื่ออินสแตนซ์เริ่มทำงาน โดยปกติแล้ว Cloud Init จะปรากฏบนอินสแตนซ์เหล่านี้เสมอ Cloud init อ่านจดหมายฉบับนี้และพูดว่า: “ตกลง วันนี้ฉันเป็นผู้จัดสรรภาระงาน” และตามพันธสัญญาเหล่านี้พระองค์ทรงกระทำการบางอย่าง
แต่น่าเสียดายที่เมื่อเราใช้แผน Terraform และ Terraform ข้อมูลผู้ใช้จะดูเหมือนตัวเลขประเภทนี้ นั่นคือเขาเพียงส่งแฮชให้คุณ และสิ่งที่คุณดูได้ในแผนคือจะมีการเปลี่ยนแปลงใดๆ หรือแฮชจะยังคงเหมือนเดิมหรือไม่
และถ้าคุณไม่ใส่ใจกับสิ่งนี้ ไฟล์ข้อความที่เสียหายบางไฟล์อาจไปอยู่ที่ Amazon บนโครงสร้างพื้นฐานจริง
อีกทางหนึ่ง เมื่อดำเนินการ คุณสามารถระบุไม่ใช่โครงสร้างพื้นฐานทั้งหมด แต่ระบุเฉพาะเทมเพลตเท่านั้น และในโค้ดพูดว่า: “โปรดแสดงเทมเพลตนี้บนหน้าจอของฉัน” และด้วยเหตุนี้ คุณสามารถพิมพ์ออกมาว่าข้อมูลของคุณจะมีลักษณะอย่างไรบน Amazon
อีกทางเลือกหนึ่งคือการใช้โมดูลเพื่อสร้างข้อมูลผู้ใช้ คุณจะใช้โมดูลนี้ คุณได้รับไฟล์บนดิสก์ เปรียบเทียบกับอันอ้างอิง ดังนั้น หากมีผู้ชายตัดสินใจแก้ไขข้อมูลผู้ใช้เพียงเล็กน้อย การทดสอบของคุณจะบอกว่า: "ตกลง มีการเปลี่ยนแปลงบางอย่างที่นี่และที่นั่น ซึ่งเป็นเรื่องปกติ"
สิ่งต่อไปที่ฉันอยากจะพูดถึงคือการใช้ Automate Terraform
แน่นอนว่ามันค่อนข้างน่ากลัวที่จะใช้ Terraform ในโหมดอัตโนมัติ เพราะใครจะรู้ว่ามีการเปลี่ยนแปลงอะไรบ้างและจะทำลายโครงสร้างพื้นฐานของการดำรงชีวิตได้ขนาดไหน
สำหรับสภาพแวดล้อมการทดสอบ นี่เป็นเรื่องปกติ นั่นคืองานที่สร้างสภาพแวดล้อมการทดสอบคือสิ่งที่นักพัฒนาทุกคนต้องการ และสำนวนเช่น "ทุกอย่างได้ผลสำหรับฉัน" ไม่ใช่มีมตลก แต่เป็นข้อพิสูจน์ว่าบุคคลนั้นสับสน ยกสแต็ก และทำการทดสอบบางอย่างกับสแต็กนี้ และเขาทำให้แน่ใจว่าทุกอย่างเรียบร้อยดีที่นั่น และพูดว่า: "เอาล่ะ รหัสที่ฉันปล่อยได้รับการทดสอบแล้ว"
ในการผลิต แซนด์บ็อกซ์ และสภาพแวดล้อมอื่นๆ ที่มีความสำคัญทางธุรกิจมากกว่า คุณสามารถใช้ทรัพยากรบางส่วนได้อย่างปลอดภัย เนื่องจากไม่ส่งผลให้ใครเสียชีวิต สิ่งเหล่านี้ได้แก่: กลุ่มปรับขนาดอัตโนมัติ กลุ่มความปลอดภัย บทบาท เส้นทาง 53 และรายการอาจมีขนาดค่อนข้างใหญ่ แต่คอยติดตามสิ่งที่เกิดขึ้น อ่านรายงานแอปพลิเคชันอัตโนมัติ
ในกรณีที่เป็นอันตรายหรือน่ากลัวที่จะนำไปใช้ เช่น หากสิ่งเหล่านี้เป็นทรัพยากรถาวรจากฐานข้อมูล ก็จะได้รับรายงานว่ามีการเปลี่ยนแปลงที่ยังไม่ได้นำไปใช้ในโครงสร้างพื้นฐานบางส่วน และวิศวกรภายใต้การดูแลจะเริ่มงานเพื่อสมัครหรือดำเนินการจากคอนโซลของเขา
Amazon มีสิ่งเช่น ยุติการป้องกัน และสามารถป้องกันในบางกรณีจากการเปลี่ยนแปลงที่ไม่จำเป็นสำหรับคุณ นั่นคือ Terraform ไปที่ Amazon แล้วพูดว่า: "ฉันต้องฆ่าอินสแตนซ์นี้เพื่อสร้างอินสแตนซ์ใหม่" และอเมซอนพูดว่า: “ขออภัย ไม่ใช่วันนี้ เรามีการป้องกันยุติ"
และไอซิ่งบนเค้กคือการเพิ่มประสิทธิภาพโค้ด เมื่อเราทำงานกับโค้ด Terraform เราต้องส่งพารามิเตอร์จำนวนมากไปยังโมดูล นี่คือพารามิเตอร์ที่จำเป็นในการสร้างทรัพยากรบางประเภท และโค้ดจะเปลี่ยนเป็นรายการพารามิเตอร์จำนวนมากที่ต้องส่งผ่านจากโมดูลหนึ่งไปอีกโมดูล จากโมดูลหนึ่งไปอีกโมดูลหนึ่ง โดยเฉพาะอย่างยิ่งหากโมดูลซ้อนกัน
และอ่านยากมาก เป็นการยากมากที่จะทบทวนเรื่องนี้ และบ่อยครั้งที่ปรากฎว่าพารามิเตอร์บางตัวได้รับการตรวจสอบและไม่ได้เป็นสิ่งที่จำเป็นอย่างแน่นอน และนี่ต้องเสียเวลาและเงินในการแก้ไขในภายหลัง
ดังนั้นฉันขอแนะนำให้คุณใช้สิ่งนี้เป็นพารามิเตอร์ที่ซับซ้อนซึ่งรวมถึงแผนผังค่าบางอย่าง นั่นคือคุณต้องมีโฟลเดอร์บางประเภทที่คุณมีค่าทั้งหมดที่คุณต้องการมีในบางสภาพแวดล้อม
และโดยการเรียกโมดูลนี้ คุณจะได้รับแผนผังที่สร้างขึ้นในโมดูลทั่วไปโมดูลเดียว นั่นคือในโมดูลทั่วไปที่ทำงานเหมือนกันสำหรับโครงสร้างพื้นฐานทั้งหมด
ในโมดูลนี้ คุณสามารถคำนวณบางอย่างได้โดยใช้ฟีเจอร์ล่าสุดใน Terraform เช่นเดียวกับคนในพื้นที่ จากนั้นด้วยเอาต์พุตเดียว ให้ระบุพารามิเตอร์ที่ซับซ้อนซึ่งอาจรวมถึงแฮชของอาร์เรย์ ฯลฯ
นี่คือจุดสิ้นสุดของสิ่งที่ดีที่สุดที่ฉันพบ และฉันอยากจะเล่าเรื่องเกี่ยวกับโคลัมบัส เมื่อเขาหาเงินสำหรับการเดินทางไปค้นพบอินเดีย (อย่างที่เขาคิดในตอนนั้น) ไม่มีใครเชื่อเขาและพวกเขาก็คิดว่ามันเป็นไปไม่ได้ แล้วเขาก็พูดว่า: “อย่าให้ไข่ตกนะ” นายธนาคารทุกคน ซึ่งร่ำรวยมากและน่าจะฉลาด พยายามวางไข่ด้วยวิธีใดวิธีหนึ่ง และมันก็ตกลงมาเรื่อยๆ จากนั้นโคลัมบัสก็หยิบไข่ขึ้นมากดเล็กน้อย เปลือกยับยู่ยี่และไข่ยังคงนิ่งอยู่ พวกเขาพูดว่า "โอ้ ง่ายเกินไป!" และโคลัมบัสตอบว่า “ใช่ มันง่ายเกินไป และเมื่อฉันเปิดอินเดีย ทุกคนจะใช้เส้นทางการค้านี้”
และสิ่งที่ฉันเพิ่งบอกคุณไปอาจเป็นเรื่องที่ค่อนข้างเรียบง่ายและไม่สำคัญ และเมื่อคุณเรียนรู้เกี่ยวกับสิ่งเหล่านี้และเริ่มใช้มัน มันก็จะเป็นไปตามลำดับของสิ่งต่างๆ ดังนั้นจงใช้ประโยชน์ และหากสิ่งเหล่านี้เป็นเรื่องปกติสำหรับคุณ อย่างน้อยคุณก็รู้วิธีวางไข่เพื่อไม่ให้ตก
เพื่อสรุปผล:
- พยายามหลีกเลี่ยงเกล็ดหิมะ และยิ่งมีเกล็ดหิมะน้อยลง คุณก็ยิ่งต้องใช้ทรัพยากรน้อยลงเพื่อทำการเปลี่ยนแปลงทั่วทั้งโครงสร้างพื้นฐานขนาดใหญ่ของคุณ
- การเปลี่ยนแปลงอย่างต่อเนื่อง นั่นคือเมื่อมีการเปลี่ยนแปลงโค้ด คุณจะต้องทำให้โครงสร้างพื้นฐานของคุณสอดคล้องกับการเปลี่ยนแปลงเหล่านี้โดยเร็วที่สุด ไม่ควรจะมีสถานการณ์ที่ใครบางคนมาดู Elasticsearch ในอีกสองหรือสามเดือนต่อมา จัดทำแผน Terraform และมีการเปลี่ยนแปลงมากมายที่เขาไม่คาดคิด และต้องใช้เวลามากในการจัดทุกอย่างให้เรียบร้อย
- การทดสอบและระบบอัตโนมัติ ยิ่งโค้ดของคุณครอบคลุมการทดสอบและฟีเจอร์ต่างๆ มากเท่าใด คุณก็ยิ่งมั่นใจว่าคุณทำทุกอย่างถูกต้องมากขึ้นเท่านั้น และการจัดส่งอัตโนมัติจะช่วยเพิ่มความมั่นใจให้คุณหลายเท่า
- รหัสสำหรับสภาพแวดล้อมการทดสอบและการใช้งานจริงควรเกือบจะเหมือนกัน ในทางปฏิบัติแล้ว เนื่องจากการผลิตยังคงแตกต่างกันเล็กน้อยและยังคงมีความแตกต่างบางอย่างที่นอกเหนือไปจากสภาพแวดล้อมการทดสอบ แต่ถึงกระนั้นบวกหรือลบก็สามารถมั่นใจได้
- และหากคุณมีโค้ด Terraform จำนวนมากและใช้เวลานานมากในการอัปเดตโค้ดนี้ให้ทันสมัยอยู่เสมอ ก็ไม่สายเกินไปที่จะปรับโครงสร้างใหม่และทำให้โค้ดอยู่ในสภาพดี
- โครงสร้างพื้นฐานที่ไม่เปลี่ยนรูป AMI ส่งมอบตามกำหนดเวลา
- โครงสร้างสำหรับเส้นทาง 53 เมื่อคุณมีรายการจำนวนมากและคุณต้องการให้รายการเหล่านั้นอยู่ในลำดับที่สอดคล้องกัน
- ต่อสู้กับขีดจำกัดอัตรา API นี่คือตอนที่ Amazon พูดว่า “แค่นั้นแหละ ฉันไม่สามารถยอมรับคำขอใดๆ ได้อีก โปรดรอสักครู่” และครึ่งหนึ่งของสำนักงานกำลังรอจนกว่าจะสามารถเปิดตัวโครงสร้างพื้นฐานได้
- สปอตอินสแตนซ์ Amazon ไม่ใช่งานราคาถูกและสปอตช่วยให้คุณประหยัดเงินได้มาก และที่นั่นคุณสามารถบอกเล่ารายงานทั้งหมดเกี่ยวกับเรื่องนี้ได้
- บทบาทความปลอดภัยและ IAM
- การค้นหาทรัพยากรที่สูญหาย เมื่อคุณมีอินสแตนซ์ที่ไม่ทราบที่มาใน Amazone พวกเขาจะกินเงิน แม้ว่าอินสแตนซ์จะมีราคา 100-150 เหรียญสหรัฐฯ ต่อเดือน แต่ก็มากกว่า 1 เหรียญสหรัฐฯ ต่อปี การค้นหาทรัพยากรดังกล่าวเป็นธุรกิจที่ทำกำไร
- และกรณีที่สงวนไว้
นั่นคือทั้งหมดสำหรับฉัน Terraform เจ๋งมาก คุณใช้มันสิ ขอบคุณ!
คำถาม
ขอบคุณสำหรับรายงาน! ไฟล์สถานะของคุณอยู่ใน S3 แต่คุณจะแก้ไขปัญหาที่หลายๆ คนสามารถนำไฟล์สถานะนี้ไปและพยายามขยายได้อย่างไร
ก่อนอื่นเราไม่รีบร้อน ประการที่สอง มีการตั้งค่าสถานะซึ่งเรารายงานว่าเรากำลังดำเนินการกับโค้ดบางส่วน นั่นคือแม้ว่าโครงสร้างพื้นฐานจะมีขนาดใหญ่มาก แต่ก็ไม่ได้หมายความว่ามีคนใช้บางสิ่งบางอย่างอยู่ตลอดเวลา และเมื่อมีเฟสที่ใช้งานอยู่ นี่เป็นปัญหา เราจัดเก็บไฟล์สถานะไว้ใน Git นี่เป็นสิ่งสำคัญ ไม่เช่นนั้นจะมีคนสร้างไฟล์สถานะ และเราต้องรวบรวมมันเข้าด้วยกันด้วยตนเองเพื่อให้ทุกอย่างดำเนินต่อไปได้ ตอนนี้ไม่มีปัญหาดังกล่าวแล้ว โดยทั่วไปแล้ว Terraform สามารถแก้ไขปัญหานี้ได้ และหากมีสิ่งใดเปลี่ยนแปลงอยู่ตลอดเวลา คุณสามารถใช้ล็อคซึ่งป้องกันสิ่งที่คุณพูดได้
คุณใช้โอเพ่นซอร์สหรือองค์กรหรือไม่?
ไม่มีองค์กร นั่นคือทุกสิ่งที่คุณสามารถดาวน์โหลดได้ฟรี
ฉันชื่อสตานิสลาฟ ฉันต้องการเพิ่มเล็กน้อย คุณได้พูดคุยเกี่ยวกับคุณสมบัติของ Amazon ที่ช่วยให้คุณสร้างอินสแตนซ์ที่ไม่สามารถทำได้ สิ่งนี้มีอยู่ใน Terraform เช่นกัน ในบล็อก Life Second คุณสามารถระบุการห้ามการเปลี่ยนแปลงหรือการห้ามการทำลายได้
เวลามีจำกัด จุดดี.
ฉันอยากจะถามสองสิ่งเช่นกัน ประการแรก คุณพูดคุยเกี่ยวกับการทดสอบ คุณใช้เครื่องมือทดสอบหรือไม่? ฉันได้ยินเกี่ยวกับปลั๊กอิน Test Kitchen บางทีอาจมีอะไรมากกว่านี้ และผมอยากจะถามเกี่ยวกับค่านิยมท้องถิ่นด้วย พวกมันแตกต่างโดยพื้นฐานจากตัวแปรอินพุตอย่างไร และเหตุใดฉันจึงไม่สามารถกำหนดพารามิเตอร์บางอย่างผ่านค่าท้องถิ่นเท่านั้น ฉันพยายามคิดออกหัวข้อนี้ แต่อย่างใดฉันก็ไม่เข้าใจตัวเอง
คุยรายละเอียดนอกห้องนี้ได้ เครื่องมือทดสอบของเราสร้างขึ้นเองทั้งหมด ไม่มีอะไรให้ทดสอบ โดยทั่วไป มีตัวเลือกต่างๆ เมื่อการทดสอบอัตโนมัติรับโครงสร้างพื้นฐานที่ไหนสักแห่ง ตรวจสอบว่าใช้ได้ จากนั้นทำลายทุกอย่างด้วยรายงานว่าโครงสร้างพื้นฐานของคุณยังอยู่ในสภาพดี เราไม่มีสิ่งนี้เนื่องจากมีการรันสแต็กการทดสอบทุกวัน และนั่นก็เพียงพอแล้ว และถ้ามีอะไรเริ่มพังมันก็จะเริ่มพังโดยที่เราไม่ต้องไปตรวจสอบที่อื่น
ส่วนเรื่องค่านิยมท้องถิ่นก็มาพูดคุยกันนอกห้องกันต่อ
สวัสดี! ขอบคุณสำหรับรายงาน! ข้อมูลมาก คุณบอกว่าคุณมีโค้ดประเภทเดียวกันจำนวนมากเพื่ออธิบายโครงสร้างพื้นฐาน คุณเคยพิจารณาที่จะสร้างรหัสนี้หรือไม่?
เป็นคำถามที่ดีมาก ขอบคุณ! ประเด็นก็คือเมื่อเราใช้โครงสร้างพื้นฐานเป็นโค้ด เราจะถือว่าเราดูโค้ดและเข้าใจว่าโครงสร้างพื้นฐานใดอยู่เบื้องหลังโค้ดนั้น หากมีการสร้างโค้ด เราต้องจินตนาการว่าโค้ดใดจะถูกสร้างขึ้นเพื่อทำความเข้าใจว่าจะมีโครงสร้างพื้นฐานประเภทใด ไม่ว่าเราจะสร้างโค้ด คอมมิตมัน และโดยพื้นฐานแล้วสิ่งเดียวกันก็เกิดขึ้น เราก็เลยเดินตามทางที่เราเขียนไว้ เราเข้าใจแล้ว เครื่องกำเนิดไฟฟ้าพลัสปรากฏขึ้นช้ากว่าเล็กน้อยเมื่อเราเริ่มสร้างมัน และมันก็สายเกินไปที่จะเปลี่ยนแปลงแล้ว
คุณเคยได้ยินอะไรเกี่ยวกับ jsonnet บ้างไหม?
เลขที่
ดูนี่เป็นสิ่งที่เจ๋งมาก ฉันเห็นกรณีเฉพาะที่คุณสามารถนำไปใช้และสร้างโครงสร้างข้อมูลได้
เครื่องปั่นไฟจะดีเมื่อคุณมี อย่างเช่นในเรื่องตลกเกี่ยวกับเครื่องโกนหนวด นั่นคือครั้งแรกที่ใบหน้าแตกต่าง แต่ทุกคนก็มีใบหน้าที่เหมือนกัน เครื่องกำเนิดไฟฟ้าทำงานได้ดีมาก แต่น่าเสียดายที่ใบหน้าของเราแตกต่างกันเล็กน้อย นี่เป็นปัญหา
แค่ดู. ขอบคุณ!
ฉันชื่อ Maxim ฉันมาจาก Sberbank คุณได้พูดคุยเล็กน้อยเกี่ยวกับวิธีที่คุณพยายามทำให้ Terraform เทียบเท่ากับภาษาการเขียนโปรแกรม การใช้ Ansible ไม่ง่ายกว่าเหรอ?
สิ่งเหล่านี้แตกต่างกันมาก คุณสามารถสร้างทรัพยากรใน Ansible และ Puppet ก็สามารถสร้างทรัพยากรใน Amazon ได้ แต่เทอร์ราฟอร์มนั้นเฉียบแหลมยิ่งขึ้น
มีแค่อเมซอนเหรอ?
ไม่ใช่ว่าเรามีแต่อเมซอนเท่านั้น เราเกือบจะมีเพียงอเมซอนเท่านั้น แต่คุณสมบัติที่สำคัญคือ Terraform จดจำได้ ใน Ansible ถ้าคุณพูดว่า: "Give me 5 instance" มันก็จะเพิ่มขึ้น จากนั้นคุณจะพูดว่า: "และตอนนี้ฉันต้องการ 3 อัน" และ Terraform จะพูดว่า: "เอาล่ะ ฉันจะฆ่า 2 ตัว" และ Ansible จะพูดว่า: "เอาล่ะ นี่คือ 3 อันสำหรับคุณ" รวม 8.
สวัสดี! ขอบคุณสำหรับรายงานของคุณ! เป็นเรื่องที่น่าสนใจมากที่ได้ยินเกี่ยวกับ Terraform ฉันอยากจะแสดงความคิดเห็นเล็กๆ น้อยๆ ทันทีเกี่ยวกับความจริงที่ว่า Terraform ยังไม่มีเวอร์ชันที่เสถียร ดังนั้นให้ปฏิบัติต่อ Terraform ด้วยความระมัดระวังอย่างยิ่ง
ช้อนที่ดีสำหรับมื้อเย็น นั่นคือหากคุณต้องการวิธีแก้ปัญหา บางครั้งคุณก็เลื่อนสิ่งที่ไม่เสถียรออกไป ฯลฯ แต่มันก็ได้ผลและช่วยเราได้
คำถามคือสิ่งนี้ คุณใช้แบ็กเอนด์ระยะไกล คุณใช้ S 3 ทำไมคุณไม่ใช้แบ็กเอนด์อย่างเป็นทางการล่ะ
เป็นทางการ?
เทอร์ราฟอร์มคลาวด์
เขาปรากฏตัวเมื่อไหร่?
ประมาณ 4 เดือนที่แล้ว.
ถ้ามันปรากฏเมื่อ 4 ปีที่แล้ว ฉันคงจะตอบคำถามของคุณไปแล้ว
มีฟังก์ชันและล็อคในตัวอยู่แล้ว และคุณสามารถจัดเก็บไฟล์สถานะได้ ให้มันลอง. แต่ฉันยังไม่ได้ทดสอบมันเช่นกัน
เรากำลังเดินทางด้วยรถไฟขบวนใหญ่ที่วิ่งด้วยความเร็วสูง และคุณไม่สามารถเอารถสองสามคันไปทิ้งได้
คุณพูดคุยเกี่ยวกับเกล็ดหิมะ ทำไมคุณไม่ใช้สาขา? ทำไมมันไม่ได้ผลแบบนั้น?
แนวทางของเราคือโครงสร้างพื้นฐานทั้งหมดอยู่ในที่เก็บข้อมูลเดียว Terraform, Puppet และสคริปต์ทั้งหมดที่เกี่ยวข้องกับสิ่งนี้ ทั้งหมดนี้รวมอยู่ในที่เก็บข้อมูลเดียว วิธีนี้ทำให้เรามั่นใจได้ว่าจะมีการทดสอบการเปลี่ยนแปลงที่เพิ่มขึ้นทีละรายการ หากเป็นกลุ่มสาขา โครงการดังกล่าวแทบจะรักษาไม่ได้เลย หกเดือนผ่านไป และความแตกต่างกันมากจนเป็นเพียงการลงโทษบางอย่าง นี่คือสิ่งที่ฉันต้องการหลีกหนีก่อนการปรับโครงสร้างใหม่
แล้วมันไม่ทำงานเหรอ?
สิ่งนี้ไม่ทำงานเลย
ในสาขาฉันตัดสไลด์โฟลเดอร์ออก นั่นคือ หากคุณทำกับแต่ละสแต็กการทดสอบ เช่น ทีม A มีโฟลเดอร์ของตัวเอง ทีม B มีโฟลเดอร์ของตัวเอง วิธีนี้ก็จะใช้งานไม่ได้เช่นกัน เราสร้างโค้ดสภาพแวดล้อมการทดสอบแบบรวมที่ยืดหยุ่นพอที่จะเหมาะกับทุกคน นั่นคือเราให้บริการหนึ่งรหัส
สวัสดี! ฉันชื่อยูร่า! ขอบคุณสำหรับรายงาน! คำถามเกี่ยวกับโมดูล คุณบอกว่าคุณกำลังใช้โมดูล คุณจะแก้ไขปัญหาได้อย่างไรหากมีการเปลี่ยนแปลงในโมดูลหนึ่งที่ไม่เข้ากันกับการเปลี่ยนแปลงของบุคคลอื่น คุณกำลังกำหนดเวอร์ชันของโมดูลหรือพยายามนำ wunderwaffle เพื่อตอบสนองความต้องการสองประการหรือไม่?
นี่เป็นปัญหากองหิมะครั้งใหญ่ นี่คือสิ่งที่เราต้องทนทุกข์ทรมานเมื่อการเปลี่ยนแปลงที่ไม่เป็นอันตรายอาจทำให้โครงสร้างพื้นฐานบางส่วนเสียหายได้ และสิ่งนี้จะสังเกตเห็นได้ชัดเจนหลังจากผ่านไประยะหนึ่งเท่านั้น
คือมันยังไม่ได้รับการแก้ไขใช่ไหม?
คุณสร้างโมดูลสากล หลีกเลี่ยงเกล็ดหิมะ และทุกอย่างจะได้ผล ครึ่งหลังของรายงานเป็นเรื่องเกี่ยวกับวิธีหลีกเลี่ยงปัญหานี้
สวัสดี! ขอบคุณสำหรับรายงาน! ผมอยากจะชี้แจง. เบื้องหลังมีกองใหญ่ที่ผมมา การกระจายหุ่นและบทบาทผสมผสานกันอย่างไร
ข้อมูลผู้ใช้
นั่นคือคุณแค่คายไฟล์ออกมาแล้วรันมันใช่ไหม?
ข้อมูลผู้ใช้เป็นบันทึกย่อ กล่าวคือ เมื่อเราสร้างโคลนของรูปภาพ Daemon จะปรากฏขึ้นที่นั่น และพยายามค้นหาว่าเขาเป็นใคร อ่านบันทึกย่อว่าเขาเป็นโหลดบาลานเซอร์
นั่นคือนี่เป็นกระบวนการแยกประเภทที่มอบให้หรือไม่?
เราไม่ได้ประดิษฐ์มันขึ้นมา เราใช้มัน.
สวัสดี! ฉันมีคำถามเกี่ยวกับ User-data คุณบอกว่ามีปัญหาที่นั่นมีคนส่งของไปผิดที่ มีวิธีใดบ้างในการจัดเก็บข้อมูลผู้ใช้ใน Git เดียวกัน เพื่อให้ชัดเจนว่าข้อมูลผู้ใช้หมายถึงอะไร
เราสร้างข้อมูลผู้ใช้จากเทมเพลต นั่นคือมีการใช้ตัวแปรจำนวนหนึ่งที่นั่น และ Terraform ก็สร้างผลลัพธ์สุดท้าย ดังนั้นคุณไม่สามารถดูเทมเพลตและพูดว่าจะเกิดอะไรขึ้นเพราะปัญหาทั้งหมดเกี่ยวข้องกับความจริงที่ว่านักพัฒนาคิดว่าเขาส่งสตริงในตัวแปรนี้ แต่มีการใช้อาร์เรย์ที่นั่น และเขา - แบมกับฉัน - พอประมาณพอประมาณบรรทัดถัดไปและทุกอย่างก็พัง หากนี่เป็นทรัพยากรใหม่และมีคนหยิบขึ้นมาและเห็นว่ามีบางอย่างใช้งานไม่ได้ แสดงว่าได้รับการแก้ไขอย่างรวดเร็ว และหากมีการอัปเดตกลุ่มการปรับขนาดอัตโนมัตินี้ เมื่อถึงจุดหนึ่ง อินสแตนซ์ในกลุ่มการปรับขนาดอัตโนมัติจะเริ่มถูกแทนที่ และปัง มีบางอย่างใช้งานไม่ได้ มันเจ็บ.
ปรากฎว่าทางออกเดียวคือการทดสอบ?
ใช่ คุณพบปัญหา คุณเพิ่มขั้นตอนการทดสอบที่นั่น นั่นคือสามารถทดสอบเอาต์พุตได้เช่นกัน อาจจะไม่สะดวกนัก แต่คุณสามารถทำเครื่องหมายได้ - ตรวจสอบว่าได้ตอกย้ำข้อมูลผู้ใช้ไว้ที่นี่
ฉันชื่อติมูร์ เป็นเรื่องดีมากที่มีรายงานเกี่ยวกับวิธีการจัดระเบียบ Terraform อย่างเหมาะสม
ฉันยังไม่ได้เริ่มเลย
ฉันคิดว่าบางทีในการประชุมครั้งต่อไปอาจมี ฉันมีคำถามง่ายๆ เหตุใดคุณจึงฮาร์ดโค้ดค่าในโมดูลแยกต่างหากแทนที่จะใช้ tfvars เช่น เหตุใดโมดูลที่มีค่าจึงดีกว่า tfvars
นั่นคือ ฉันควรเขียนที่นี่ (สไลด์: Production/environment/settings.tf): domain =ตัวแปร, โดเมน vpcnetwork, ตัวแปร vpcnetwork และ stvars – ฉันจะได้สิ่งเดียวกันหรือไม่
นั่นคือสิ่งที่เราทำ เราอ้างถึงโมดูลแหล่งการตั้งค่าเป็นต้น
โดยพื้นฐานแล้วนี่คือ tfvars Tfvars สะดวกมากในสภาพแวดล้อมการทดสอบ ฉันมี tfvars สำหรับอินสแตนซ์ขนาดใหญ่สำหรับอินสแตนซ์ขนาดเล็ก และฉันก็โยนไฟล์หนึ่งไฟล์ลงในโฟลเดอร์ และฉันได้สิ่งที่ฉันต้องการ เมื่อเรากำลังตัดโครงสร้างพื้นฐาน เราต้องการให้สามารถดูและเข้าใจทุกอย่างได้ทันที ปรากฎว่าคุณต้องดูที่นี่ แล้วก็ดู tfvars
เป็นไปได้ไหมที่จะมีทุกอย่างในที่เดียว?
ใช่ tfvars คือเมื่อคุณมีรหัสเดียว และมีการใช้ในสถานที่ต่าง ๆ หลายแห่งโดยมีความแตกต่างกัน จากนั้นคุณจะโยน tfvars และรับความแตกต่างของคุณ และเราเป็นโครงสร้างพื้นฐานที่เป็นโค้ดในรูปแบบที่บริสุทธิ์ที่สุด ฉันดูแล้วเข้าใจ
สวัสดี! คุณเคยพบกับสถานการณ์ที่ผู้ให้บริการคลาวด์รบกวนสิ่งที่คุณสร้าง Terraform หรือไม่? สมมติว่าเราแก้ไขข้อมูลเมตา มีคีย์ ssh และ Google ก็ใส่ข้อมูลเมตาและคีย์ของมันไว้ที่นั่นอยู่เสมอ และ Terraform เขียนเสมอว่ามันมีการเปลี่ยนแปลง หลังจากการวิ่งแต่ละครั้งแม้ว่าจะไม่มีอะไรเปลี่ยนแปลง แต่เขามักจะบอกว่าเขาจะอัปเดตฟิลด์นี้ทันที
ด้วยกุญแจ แต่ใช่ ส่วนหนึ่งของโครงสร้างพื้นฐานได้รับผลกระทบจากสิ่งนี้ เช่น Terraform ไม่สามารถเปลี่ยนแปลงอะไรได้ เราไม่สามารถเปลี่ยนแปลงอะไรด้วยมือของเราได้เช่นกัน เราจะอยู่กับมันในตอนนี้
คือเคยเจอแบบนี้แต่ไม่ได้คิดอะไร เขาจะทำยังไง และทำเอง?
น่าเสียดายใช่
สวัสดี! ฉันชื่อสตาร์คอฟ สตานิสลาฟ จดหมาย. รุ กรุ๊ป. คุณจะแก้ไขปัญหาการสร้างแท็กบน... และส่งผ่านเข้าไปข้างในได้อย่างไร? ตามที่ผมเข้าใจแล้ว โดย User - data เพื่อระบุชื่อโฮสต์ ให้ตั้งค่า Puppet ไว้หรือไม่? และส่วนที่สองของคำถาม คุณจะแก้ไขปัญหานี้ใน SG ได้อย่างไร เช่น เมื่อคุณสร้าง SG อินสแตนซ์ประเภทเดียวกันหลายร้อยรายการ ชื่อที่ถูกต้องสำหรับอินสแตนซ์เหล่านั้นคืออะไร
กรณีเหล่านั้นที่สำคัญมากสำหรับเรา เราตั้งชื่อให้สวยงาม สิ่งที่ไม่จำเป็นมีหมายเหตุว่านี่คือกลุ่มปรับขนาดอัตโนมัติ และตามทฤษฎีแล้ว คุณสามารถตอกย้ำมันและหาอันใหม่ได้
ส่วนปัญหาเรื่องแท็กนั้นไม่มีปัญหาดังกล่าว แต่มีงานดังกล่าวอยู่ และเราใช้แท็กอย่างหนัก เนื่องจากโครงสร้างพื้นฐานมีขนาดใหญ่และมีราคาแพง และเราต้องดูว่าเงินไปอยู่ที่ไหน ดังนั้นแท็กจึงช่วยให้เราแยกย่อยได้ว่าอะไรไปอยู่ที่ไหน และด้วยเหตุนี้จึงมีการค้นหาบางสิ่งที่หมายถึงการใช้เงินจำนวนมากที่นี่
มีคำถามเกี่ยวกับอะไรอีก?
เมื่อ SG สร้างอินสแตนซ์หลายร้อยรายการ จำเป็นต้องแยกแยะหรือไม่
ไม่ อย่า ในแต่ละกรณีจะมีเจ้าหน้าที่รายงานว่าฉันมีปัญหา หากตัวแทนรายงาน ตัวแทนก็จะรู้เกี่ยวกับเขาและอย่างน้อยก็มีที่อยู่ IP ของเขาอยู่ คุณสามารถหนีไปได้แล้ว ประการที่สอง เราใช้ Consul for Discovery โดยที่ Kubernetes ไม่ใช่ และกงสุลยังแสดงที่อยู่ IP ของอินสแตนซ์ด้วย
นั่นคือคุณมุ่งความสนใจไปที่ IP โดยเฉพาะ ไม่ใช่ชื่อโฮสต์ใช่หรือไม่
เป็นไปไม่ได้ที่จะนำทางด้วยชื่อโฮสต์นั่นคือ มีจำนวนมาก มีตัวระบุอินสแตนซ์ - AE ฯลฯ คุณสามารถค้นหาได้จากที่ไหนสักแห่งคุณสามารถโยนมันลงในการค้นหาได้
สวัสดี! ฉันรู้ว่า Terraform เป็นสิ่งที่ดี ซึ่งออกแบบมาเพื่อกลุ่มเมฆโดยเฉพาะ
ไม่เพียงแค่.
นี่เป็นคำถามที่ฉันสนใจอย่างแน่นอน หากคุณตัดสินใจที่จะย้ายไปยัง Bare Metal จำนวนมากพร้อมกับอินสแตนซ์ทั้งหมดของคุณ? จะมีปัญหาอะไรมั้ย? หรือจะยังต้องใช้ผลิตภัณฑ์อื่น เช่น Ansible แบบเดียวกับที่กล่าวมานี้หรือเปล่า?
Ansible เป็นเพียงเล็กน้อยเกี่ยวกับสิ่งอื่น นั่นคือ Ansible ใช้งานได้แล้วเมื่ออินสแตนซ์เริ่มทำงาน และ Terraform ทำงานได้ก่อนที่อินสแตนซ์จะเริ่มต้น เปลี่ยนเป็น Bare Metal - ไม่
ยังไม่ใช่ตอนนี้ แต่ธุรกิจจะมาและพูดว่า: "มาเลย"
เปลี่ยนไปใช้คลาวด์อื่น – ใช่ แต่มีเคล็ดลับที่แตกต่างออกไปเล็กน้อยที่นี่ คุณต้องเขียนโค้ด Terraform ในลักษณะที่คุณสามารถสลับไปใช้คลาวด์อื่นได้โดยใช้ความพยายามน้อยลง
ในตอนแรก งานถูกกำหนดไว้ว่าโครงสร้างพื้นฐานทั้งหมดของเราไม่เชื่อเรื่องพระเจ้า กล่าวคือ คลาวด์ใดๆ ก็ตามควรจะเหมาะสม แต่เมื่อถึงจุดหนึ่ง ธุรกิจก็ล้มเลิกและพูดว่า: “เอาล่ะ ในอีก N ปีข้างหน้า เราจะไม่ไปไหน เราสามารถใช้บริการได้ จากอเมซอน”
Terraform ช่วยให้คุณสร้างงาน Front-End, กำหนดค่า PagerDuty, เอกสารข้อมูล ฯลฯ ซึ่งมีขั้นตอนมากมาย เขาสามารถควบคุมโลกทั้งใบได้จริง
ขอบคุณสำหรับรายงาน! ฉันใช้ Terraform มาเป็นเวลา 4 ปีแล้ว ในขั้นตอนของการเปลี่ยนไปใช้ Terraform ไปสู่โครงสร้างพื้นฐานไปจนถึงคำอธิบายที่ประกาศอย่างราบรื่น เราต้องเผชิญกับสถานการณ์ที่มีคนกำลังทำอะไรบางอย่างด้วยมือ และคุณกำลังพยายามวางแผน และฉันได้รับข้อผิดพลาดบางอย่างที่นั่น คุณจะจัดการกับปัญหาดังกล่าวอย่างไร? คุณจะค้นหาทรัพยากรที่สูญหายที่ระบุไว้ได้อย่างไร?
ด้วยมือและตาเป็นหลัก หากเราเห็นสิ่งแปลก ๆ ในรายงาน เราก็วิเคราะห์สิ่งที่เกิดขึ้นที่นั่น หรือเราแค่ฆ่ากัน โดยทั่วไปแล้ว คำขอดึงเป็นเรื่องปกติ
หากมีข้อผิดพลาดคุณจะย้อนกลับหรือไม่? คุณได้ลองทำสิ่งนี้แล้วหรือยัง?
ไม่ นี่คือการตัดสินใจของบุคคลในขณะที่เขาเห็นปัญหา
ที่มา: will.com