การแสดงโครงสร้างพื้นฐานเป็นโค้ดในรูปแบบข้อความที่ทำซ้ำได้เป็นแนวทางปฏิบัติที่ดีที่สุดสำหรับระบบที่ไม่จำเป็นต้องเล่นซอกับเมาส์ การปฏิบัตินี้มีชื่อ - และจนถึงตอนนี้มีเครื่องมือยอดนิยมสองอย่างที่ใช้งาน โดยเฉพาะใน AWS: и .
เปรียบเทียบประสบการณ์กับ Terraform และ CloudFormation
ก่อนจะมา. (Aka ) ฉันทำงาน และใช้ Terraform เป็นเวลาสามปี ที่แห่งใหม่ ฉันยังใช้ Terraform อย่างเต็มกำลัง จากนั้นบริษัทก็ผลักดันการเปลี่ยนแปลงไปสู่ทุกสิ่งแบบ Amazon รวมถึง CloudFormation ฉันได้พัฒนาแนวทางปฏิบัติที่ดีที่สุดสำหรับทั้งสองอย่างขยันขันแข็ง และใช้เครื่องมือทั้งสองในขั้นตอนการทำงานที่ซับซ้อนมากทั่วทั้งองค์กร ต่อมา หลังจากที่พิจารณาอย่างรอบคอบถึงผลกระทบของการย้ายจาก Terraform ไปยัง CloudFormation ฉันจึงเชื่อว่า Terraform น่าจะเป็นตัวเลือกที่ดีที่สุดสำหรับองค์กร
เทอร์ราฟอร์ม น่ากลัว
ซอฟต์แวร์เบต้า
Terraform ยังไม่ได้เปิดตัวเวอร์ชัน 1.0 ซึ่งเป็นเหตุผลที่ดีที่จะไม่ใช้มัน มันเปลี่ยนไปมากตั้งแต่ฉันได้ลองด้วยตัวเองครั้งแรก แต่ในตอนนั้น terraform apply มักจะพังหลังจากการอัปเดตหลายครั้งหรือเพียงหลังจากใช้งานไปสองสามปี ฉันจะบอกว่า "ตอนนี้ทุกอย่างแตกต่างออกไป" แต่... นั่นคือสิ่งที่ทุกคนดูเหมือนจะพูดใช่ไหม? มีการเปลี่ยนแปลงที่เข้ากันไม่ได้กับเวอร์ชันก่อนหน้า แม้ว่าจะมีความเหมาะสม และยังรู้สึกเหมือนว่าไวยากรณ์และนามธรรมของที่เก็บทรัพยากรคือสิ่งที่เราต้องการในตอนนี้ ดูเหมือนว่าเครื่องดนตรีจะดีขึ้นจริงๆ แต่... :-0
ในทางกลับกัน AWS ทำงานได้ดีในการรักษาความเข้ากันได้แบบย้อนหลัง อาจเป็นเพราะบริการของพวกเขามักจะได้รับการทดสอบอย่างละเอียดภายในองค์กร และเมื่อเปลี่ยนชื่อแล้วเท่านั้นที่จะถูกเผยแพร่ ดังนั้น “พวกเขาพยายามอย่างหนัก” จึงเป็นการพูดที่น้อยเกินไป การรักษาความเข้ากันได้แบบย้อนหลังกับ API สำหรับระบบที่หลากหลายและซับซ้อนเช่นเดียวกับ AWS เป็นเรื่องยากอย่างไม่น่าเชื่อ ใครก็ตามที่ต้องดูแลรักษา API สาธารณะที่ใช้กันอย่างแพร่หลายควรเข้าใจว่าการดำเนินการดังกล่าวเป็นเวลาหลายปีนั้นยากเพียงใด แต่พฤติกรรมของ CloudFormation ในความทรงจำของฉัน ไม่เคยเปลี่ยนแปลงตลอดหลายปีที่ผ่านมา
เจอขา...มันคือกระสุน
เท่าที่ฉันรู้ ให้ลบทรัพยากรออก คนนอก ไม่สามารถสร้างสแต็ก CloudFormation จากสแต็ก CF ของคุณได้ เช่นเดียวกับ Terraform ช่วยให้คุณสามารถนำเข้าทรัพยากรที่มีอยู่ลงในสแต็กของคุณได้ ฟังก์ชั่นอาจกล่าวได้ว่าน่าทึ่ง แต่พลังที่ยิ่งใหญ่มาพร้อมกับความรับผิดชอบที่ยิ่งใหญ่ คุณเพียงแค่ต้องเพิ่มทรัพยากรลงในสแต็ก และในขณะที่คุณกำลังทำงานกับสแต็ก คุณจะไม่สามารถลบหรือเปลี่ยนแปลงทรัพยากรนี้ได้ วันหนึ่งมันก็ย้อนกลับมา วันหนึ่งบน Twitch มีคนนำเข้ากลุ่มความปลอดภัย AWS ของบุคคลอื่นไปยังสแต็ก Terraform ของตนเองโดยไม่ได้ตั้งใจ โดยไม่ก่อให้เกิดความเสียหายใดๆ ฉันป้อนคำสั่งหลายคำสั่งและ... กลุ่มความปลอดภัย (พร้อมกับทราฟฟิกขาเข้า) หายไป
เทอร์ราฟอร์ม เกรท
การกู้คืนจากสถานะที่ไม่สมบูรณ์
บางครั้ง CloudFormation อาจไม่สามารถเปลี่ยนจากสถานะหนึ่งไปอีกสถานะหนึ่งได้อย่างสมบูรณ์ ขณะเดียวกันเขาก็จะพยายามกลับไปสู่เรื่องก่อนหน้า น่าเสียดายที่สิ่งนี้ไม่สามารถทำได้เสมอไป การแก้ไขข้อบกพร่องสิ่งที่เกิดขึ้นในภายหลังอาจดูน่ากลัว - คุณไม่มีทางรู้ได้เลยว่า CloudFormation จะพอใจกับการถูกแฮ็กหรือไม่ - แม้จะเพียงเพื่อแก้ไขก็ตาม ไม่ว่าจะสามารถกลับไปสู่สภาวะก่อนหน้าได้หรือไม่ก็ตาม เขาไม่รู้วิธีตัดสินใจจริงๆ และโดยปริยาย เขาจะต้องค้างอยู่หลายชั่วโมงเพื่อรอปาฏิหาริย์
ในทางกลับกัน Terraform มีแนวโน้มที่จะฟื้นตัวจากการเปลี่ยนแปลงที่ล้มเหลวได้อย่างสวยงามกว่ามาก และมีเครื่องมือแก้ไขข้อบกพร่องขั้นสูง
การเปลี่ยนแปลงสถานะเอกสารที่ชัดเจนยิ่งขึ้น
“เอาล่ะ โหลดบาลานเซอร์ คุณกำลังเปลี่ยนแปลง แต่ยังไง?”
—วิศวกรวิตกกังวลพร้อมที่จะกดปุ่ม "ยอมรับ"
บางครั้งฉันจำเป็นต้องดำเนินการบางอย่างกับโหลดบาลานเซอร์ในสแต็ก CloudFormation เช่น การเพิ่มหมายเลขพอร์ตหรือการเปลี่ยนกลุ่มความปลอดภัย ClouFormation แสดงการเปลี่ยนแปลงได้ไม่ดี ฉันใช้หมุดและเข็มตรวจสอบไฟล์ yaml อีกครั้งสิบครั้งเพื่อให้แน่ใจว่าฉันไม่ได้ลบสิ่งที่จำเป็นและไม่ได้เพิ่มสิ่งที่ไม่จำเป็น
Terraform มีความโปร่งใสมากกว่ามากในเรื่องนี้ บางครั้งเขาก็โปร่งใสเกินไป (อ่าน: น่ารำคาญ) โชคดีที่เวอร์ชันล่าสุดมีการแสดงการเปลี่ยนแปลงที่ได้รับการปรับปรุงเพื่อให้คุณเห็นได้อย่างชัดเจนว่ามีอะไรเปลี่ยนแปลงบ้าง
มีความยืดหยุ่น
เขียนซอฟต์แวร์ไปข้างหลัง
พูดตรงๆ ลักษณะที่สำคัญที่สุดของซอฟต์แวร์ที่มีอายุยืนยาวคือความสามารถในการปรับตัวให้เข้ากับการเปลี่ยนแปลง เขียนซอฟต์แวร์ใด ๆ ย้อนหลัง บ่อยครั้งที่ฉันทำผิดพลาดโดยใช้บริการ "เรียบง่าย" จากนั้นเริ่มอัดทุกอย่างลงใน CloudFormation หรือ Terraform Stack เดียว และแน่นอนว่าหลายเดือนต่อมามีการเปิดเผยว่าฉันเข้าใจผิดทุกอย่าง และการบริการก็ไม่ง่ายเลยจริงๆ! และตอนนี้ฉันต้องแบ่งสแต็กขนาดใหญ่ออกเป็นส่วนประกอบเล็กๆ เมื่อคุณทำงานกับ CloudFormation สามารถทำได้โดยการสร้างสแต็กที่มีอยู่ใหม่ก่อนเท่านั้น และฉันจะไม่ทำเช่นนี้กับฐานข้อมูลของฉัน ในทางกลับกัน Terraform ทำให้สามารถแยกปึกและแยกมันออกเป็นส่วนย่อยๆ ที่เข้าใจได้มากขึ้น
โมดูลในคอมไพล์
การแชร์โค้ด Terraform ในหลายสแต็กนั้นง่ายกว่าการแชร์โค้ด CloudFormation มาก ด้วย Terraform คุณสามารถใส่โค้ดของคุณในพื้นที่เก็บข้อมูล git และเข้าถึงได้โดยใช้การควบคุมเวอร์ชันเชิงความหมาย ทุกคนที่มีสิทธิ์เข้าถึงพื้นที่เก็บข้อมูลนี้สามารถนำโค้ดที่แชร์มาใช้ซ้ำได้ CloudFormation มีคุณสมบัติเทียบเท่ากับ S3 แต่ไม่มีข้อดีเหมือนกัน และไม่มีเหตุผลว่าทำไมเราจึงควรละทิ้ง Git หันไปใช้ S3 เลย
องค์กรเติบโตขึ้นและความสามารถในการแบ่งปันสแต็คทั่วไปถึงระดับวิกฤติ Terraform ทำให้ทั้งหมดนี้เป็นเรื่องง่ายและเป็นธรรมชาติ ในขณะที่ CloudFormation จะทำให้คุณกระโดดข้ามห่วงก่อนที่คุณจะได้งานแบบนี้
การดำเนินการเป็นรหัส
“มาเขียนสคริปต์กันเถอะและโอเค”
—วิศวกร 3 ปีก่อนที่จะประดิษฐ์จักรยาน Terraform
เมื่อพูดถึงการพัฒนาซอฟต์แวร์ Go หรือโปรแกรม Java ไม่ใช่แค่โค้ดเท่านั้น
รหัสเป็นรหัส
นอกจากนี้ยังมีโครงสร้างพื้นฐานที่ใช้ทำงานอีกด้วย
โครงสร้างพื้นฐานเป็นรหัส
แต่เธอมาจากไหน? จะติดตามได้อย่างไร? รหัสของคุณอยู่ที่ไหน? นักพัฒนาจำเป็นต้องได้รับอนุญาตในการเข้าถึงหรือไม่?
การดำเนินงานเป็นรหัส
การเป็นนักพัฒนาซอฟต์แวร์ไม่ได้หมายถึงแค่การเขียนโค้ดเท่านั้น
AWS ไม่ใช่เพียงแห่งเดียว: คุณอาจใช้ผู้ให้บริการรายอื่น SignalFx, PagerDuty หรือ Github บางทีคุณอาจมีเซิร์ฟเวอร์ Jenkins ภายในสำหรับ CI/CD หรือแดชบอร์ด Grafana ภายในสำหรับการตรวจสอบ Infra as Code ถูกเลือกด้วยเหตุผลที่แตกต่างกัน และแต่ละเหตุผลก็มีความสำคัญเท่าเทียมกันสำหรับทุกสิ่งที่เกี่ยวข้องกับซอฟต์แวร์
ตอนที่ฉันทำงานที่ Twitch เราได้เร่งบริการต่างๆ ภายในระบบ Embedded และระบบ AWS แบบผสมของ Amazon เราเลิกใช้และสนับสนุนไมโครเซอร์วิสจำนวนมาก ซึ่งทำให้ต้นทุนการดำเนินงานเพิ่มขึ้น การอภิปรายดำเนินไปในลักษณะนี้:
- Я: ให้ตายเถอะ นั่นเป็นท่าทางมากมายในการโอเวอร์คล็อกไมโครเซอร์วิสหนึ่งรายการ ฉันจะต้องใช้ขยะนี้เพื่อสร้างบัญชี AWS (เราไปที่ 2 บัญชี ไมโครเซอร์วิส) จากนั้นอันนี้สำหรับการตั้งค่าการแจ้งเตือน อันนี้สำหรับที่เก็บโค้ด และอันนี้สำหรับรายการอีเมล และอันนี้...
- ตะกั่ว: มาเขียนสคริปต์กันเถอะ
- Я: โอเค แต่บทจะเปลี่ยนเอง เราจะต้องมีวิธีตรวจสอบว่า Gizmos ของ Amazon ในตัวทั้งหมดนี้ทันสมัยหรือไม่
- ตะกั่ว: ฟังดูเข้าท่า. และเราจะเขียนสคริปต์สำหรับสิ่งนี้
- Я: ยอดเยี่ยม! และสคริปต์อาจยังต้องตั้งค่าพารามิเตอร์ เขาจะยอมรับพวกเขาไหม?
- ตะกั่ว: ให้เขาพาไปทุกที่!
- Я: กระบวนการอาจมีการเปลี่ยนแปลงและความเข้ากันได้แบบย้อนหลังจะหายไป จำเป็นต้องมีการควบคุมเวอร์ชันเชิงความหมายบางประเภท
- ตะกั่ว: ความคิดที่ดี!
- Я: สามารถเปลี่ยนเครื่องมือได้ด้วยตนเองภายในอินเทอร์เฟซผู้ใช้ เราจะต้องมีวิธีตรวจสอบและแก้ไขปัญหานี้
…3 ปีต่อมา:
- ตะกั่ว: และเราก็มีเทอร์ราฟอร์ม
คุณธรรมของเรื่องคือ: แม้ว่าคุณจะก็ตาม เหนือหัวในทุกสิ่งในอเมซอนคุณยังคงใช้สิ่งที่ไม่ได้มาจาก AWS และบริการเหล่านี้มีสถานะที่ใช้ภาษาการกำหนดค่าเพื่อให้สถานะนั้นซิงค์กัน
CloudFormation แลมบ์ดากับโมดูล git terraform
lambda เป็นโซลูชันของ CloudFormation สำหรับปัญหาตรรกะแบบกำหนดเอง ด้วยแลมบ์ดาคุณก็ทำได้ หรือ . วิธีการนี้ทำให้เกิดความซับซ้อนเพิ่มเติมที่ไม่มีอยู่ในการกำหนดเวอร์ชันเชิงความหมายของโมดูล git ของ Terraform สำหรับฉัน ปัญหาเร่งด่วนที่สุดคือการจัดการสิทธิ์สำหรับแลมบ์ดาผู้ใช้เหล่านี้ทั้งหมด (และนี่คือบัญชี AWS หลายสิบบัญชี) ปัญหาสำคัญอีกประการหนึ่งคือปัญหา "อะไรเกิดก่อน ไก่หรือไข่" ซึ่งเกี่ยวข้องกับรหัสแลมบ์ดา ฟังก์ชันนี้เองเป็นโครงสร้างพื้นฐานและโค้ด และตัวมันเองจำเป็นต้องมีการตรวจสอบและอัปเดต ตะปูสุดท้ายในโลงศพคือความยากลำบากในการอัปเดตการเปลี่ยนแปลงโค้ดแลมบ์ดาเชิงความหมาย เรายังต้องตรวจสอบให้แน่ใจด้วยว่าการกระทำของสแต็กโดยไม่มีคำสั่งโดยตรงจะไม่เปลี่ยนแปลงระหว่างการรัน
ฉันจำได้ว่าครั้งหนึ่งฉันต้องการสร้างการปรับใช้คานารีสำหรับสภาพแวดล้อม Elastic Beanstalk ด้วยโหลดบาลานเซอร์แบบคลาสสิก สิ่งที่ง่ายที่สุดที่ต้องทำคือทำการปรับใช้ครั้งที่สองสำหรับ EB ถัดจากสภาพแวดล้อมการใช้งานจริง ซึ่งเป็นการก้าวไปอีกขั้น: การรวมกลุ่มการปรับใช้ canary ที่ปรับขนาดอัตโนมัติเข้ากับ LB การปรับใช้ในสภาพแวดล้อมการใช้งานจริง และเนื่องจาก Terraform ใช้ ซึ่งจะต้องมีโค้ดเพิ่มเติม 4 บรรทัดใน Terraform เมื่อฉันถามว่ามีวิธีแก้ไขปัญหาที่เทียบเคียงได้ใน CloudFormation หรือไม่ พวกเขาชี้ให้ฉันไปที่พื้นที่เก็บข้อมูล git ทั้งหมดที่มีไปป์ไลน์การปรับใช้และทุกอย่าง ทั้งหมดนี้เพื่อประโยชน์ของสิ่งที่โค้ด Terraform 4 บรรทัดที่ไม่ดีสามารถทำได้
ตรวจจับการดริฟท์ได้ดีขึ้น
ตรวจสอบให้แน่ใจว่าความเป็นจริงตรงกับความคาดหวัง
เป็นการดำเนินการที่มีประสิทธิภาพมากในฐานะคุณลักษณะโค้ดเนื่องจากช่วยให้มั่นใจได้ว่าความเป็นจริงจะตรงกับความคาดหวัง ใช้ได้กับทั้ง CloudFormation และ Terraform แต่เมื่อปริมาณการผลิตเพิ่มขึ้น การค้นหาการเบี่ยงเบนใน CloudFormation ก็ทำให้เกิดการตรวจจับที่ผิดพลาดมากขึ้นเรื่อยๆ
ด้วย Terraform คุณจะมี hooks วงจรชีวิตขั้นสูงสำหรับการตรวจจับการดริฟท์ ตัวอย่างเช่น คุณป้อนคำสั่ง โดยตรงในข้อกำหนดงาน ECS หากคุณต้องการละเว้นการเปลี่ยนแปลงข้อกำหนดของงานเฉพาะโดยไม่ละเว้นการเปลี่ยนแปลงในการปรับใช้ ECS ทั้งหมดของคุณ
CDK และอนาคตของ CloudFormation
CloudFormation จัดการได้ยากในสเกลโครงสร้างพื้นฐานขนาดใหญ่ข้ามระบบ ปัญหาหลายประการเหล่านี้ได้รับการยอมรับ และเครื่องมือก็ต้องการสิ่งต่างๆ เหล่านี้ ซึ่งเป็นเฟรมเวิร์กสำหรับกำหนดโครงสร้างพื้นฐานระบบคลาวด์ในโค้ดและเรียกใช้ผ่าน AWS CloudFormation มันน่าสนใจที่จะเห็นว่า aws-cdk ในอนาคตจะเป็นอย่างไร แต่จะมีช่วงเวลาที่ยากลำบากในการแข่งขันกับจุดแข็งอื่นๆ ของ Terraform เพื่อให้ CloudFormation อัปเดตอยู่เสมอ จำเป็นต้องมีการเปลี่ยนแปลงทั่วโลก
เพื่อให้ Terraform ไม่ทำให้ผิดหวัง
นี่คือ "โครงสร้างพื้นฐานที่เป็นรหัส" และไม่ใช่ "เป็นข้อความ"
ความประทับใจแรกของฉันต่อ Terraform ค่อนข้างแย่ ฉันคิดว่าฉันไม่เข้าใจวิธีการ วิศวกรเกือบทั้งหมดรับรู้โดยไม่ได้ตั้งใจว่าเป็นรูปแบบข้อความที่ต้องแปลงเป็นโครงสร้างพื้นฐานที่ต้องการ อย่าทำเช่นนี้
ความจริงของการพัฒนาซอฟต์แวร์ที่ดียังนำไปใช้กับ Terraform ได้ด้วย
ฉันได้เห็นแนวทางปฏิบัติมากมายที่นำมาใช้เพื่อสร้างโค้ดที่ดีซึ่งถูกละเลยใน Terraform คุณศึกษามาหลายปีเพื่อเป็นโปรแกรมเมอร์ที่ดี อย่าละทิ้งประสบการณ์นี้เพียงเพราะคุณกำลังทำงานกับ Terraform ความจริงของการพัฒนาซอฟต์แวร์ที่ดีนั้นใช้ได้กับ Terraform
รหัสไม่สามารถจัดทำเป็นเอกสารได้อย่างไร?
ฉันเคยเห็น Terraform stack ขนาดใหญ่โดยไม่มีเอกสารประกอบเลย คุณจะเขียนโค้ดในหน้าต่างๆ ได้อย่างไร - โดยไม่มีเอกสารประกอบเลย? เพิ่มเอกสารที่อธิบายของคุณ รหัส Terraform (เน้นคำว่า “โค้ด” ที่นี่) เหตุใดส่วนนี้จึงสำคัญ และสิ่งที่คุณทำ
เราจะปรับใช้บริการที่ครั้งหนึ่งเคยเป็นฟังก์ชัน main() ขนาดใหญ่ฟังก์ชันหนึ่งได้อย่างไร
ฉันเคยเห็นสแต็ค Terraform ที่ซับซ้อนมากที่นำเสนอเป็นโมดูลเดียว ทำไมเราไม่ปรับใช้ซอฟต์แวร์ด้วยวิธีนี้? เหตุใดเราจึงแบ่งฟังก์ชันขนาดใหญ่ออกเป็นฟังก์ชันที่เล็กลง? คำตอบเดียวกันนี้ใช้กับ Terraform หากโมดูลของคุณใหญ่เกินไป คุณจะต้องแยกย่อยออกเป็นโมดูลที่เล็กลง
บริษัทของคุณไม่ได้ใช้ห้องสมุดใช่หรือไม่?
ฉันเคยเห็นวิศวกรที่ปั่นโปรเจ็กต์ใหม่โดยใช้ Terraform คัดลอกและวางชิ้นใหญ่จากโปรเจ็กต์อื่นลงในโปรเจ็กต์ของพวกเขาเองอย่างโง่เขลา จากนั้นจึงปรับแต่งมันจนกว่ามันจะเริ่มทำงาน คุณจะทำงานแบบนี้โดยใช้รหัส "การต่อสู้" ในบริษัทของคุณหรือไม่? เราไม่เพียงแค่ใช้ห้องสมุดเท่านั้น ใช่, แต่หลักการแล้วเราจะไม่มีไลบรารี่ที่แชร์ได้อย่างไร!
คุณไม่ได้ใช้ PEP8 หรือ gofmt ใช่ไหม?
ภาษาส่วนใหญ่มีรูปแบบการจัดรูปแบบที่เป็นมาตรฐานและเป็นที่ยอมรับ ใน Python นี่คือ PEP8 อินโก - gofmt. Terraform มีของตัวเอง: terraform fmt. สนุกกับมันเพื่อสุขภาพของคุณ!
คุณจะใช้ React โดยไม่รู้ JavaScript หรือไม่?
โมดูล Terraform ช่วยลดความซับซ้อนของโครงสร้างพื้นฐานที่ซับซ้อนบางส่วนที่คุณสร้างขึ้น แต่ไม่ได้หมายความว่าคุณไม่สามารถแก้ไขได้เลย ต้องการใช้ Terraform อย่างถูกต้องโดยไม่เข้าใจทรัพยากรหรือไม่ คุณถึงวาระแล้ว เวลาจะผ่านไป และคุณจะไม่มีทางเชี่ยวชาญ Terraform ได้
คุณกำลังเขียนโค้ดด้วยซิงเกิลตันหรือการฉีดพึ่งพาหรือไม่?
การพึ่งพาการฉีดเป็นแนวทางปฏิบัติที่ดีที่สุดที่ได้รับการยอมรับสำหรับการพัฒนาซอฟต์แวร์และเป็นที่ต้องการมากกว่าซิงเกิลตัน สิ่งนี้มีประโยชน์อย่างไรใน Terraform? ฉันเคยเห็นโมดูล Terraform ที่ขึ้นอยู่กับสถานะระยะไกล แทนที่จะเขียนโมดูลที่ดึงข้อมูลสถานะระยะไกล ให้เขียนโมดูลที่รับพารามิเตอร์ จากนั้นส่งพารามิเตอร์เหล่านี้ไปยังโมดูล
ห้องสมุดของคุณทำได้ดีสิบประการหรือมีสิ่งที่ยอดเยี่ยมอย่างหนึ่งหรือไม่?
ห้องสมุดที่ทำงานได้ดีที่สุดคือห้องสมุดที่เน้นไปที่งานเดียวที่ทำได้ดีมาก แทนที่จะเขียนโมดูล Terraform ขนาดใหญ่ที่พยายามทำทุกอย่างในคราวเดียว ให้สร้างส่วนต่างๆ ของโมดูลที่ทำสิ่งเดียวได้ดี จากนั้นจึงรวมเข้าด้วยกันตามต้องการ
คุณจะทำการเปลี่ยนแปลงไลบรารี่ที่ไม่มีความเข้ากันได้แบบย้อนหลังได้อย่างไร
โมดูล Terraform ทั่วไป เช่นเดียวกับไลบรารีทั่วไป จำเป็นต้องสื่อสารการเปลี่ยนแปลงไปยังผู้ใช้โดยไม่ต้องเข้ากันได้แบบย้อนหลัง มันน่ารำคาญเมื่อการเปลี่ยนแปลงเหล่านี้เกิดขึ้นในไลบรารี และก็น่ารำคาญพอๆ กันเมื่อทำการเปลี่ยนแปลงที่เข้ากันไม่ได้ในโมดูล Terraform ขอแนะนำให้ใช้แท็ก git และ semver เมื่อใช้โมดูล Terraform
บริการการผลิตของคุณทำงานบนแล็ปท็อปหรือในศูนย์ข้อมูลหรือไม่?
Hashicorp มีเครื่องมือเช่น เพื่อรัน Terraform ของคุณ บริการแบบรวมศูนย์เหล่านี้ทำให้ง่ายต่อการจัดการ ตรวจสอบ และอนุมัติการเปลี่ยนแปลงพื้นผิว
คุณไม่เขียนแบบทดสอบเหรอ?
วิศวกรรับรู้ว่าจำเป็นต้องทดสอบโค้ด แต่พวกเขาก็มักจะลืมการทดสอบเมื่อทำงานกับ Terraform สำหรับโครงสร้างพื้นฐาน นี่เต็มไปด้วยช่วงเวลาที่เลวร้าย คำแนะนำของฉันคือการ "ทดสอบ" หรือ "สร้างตัวอย่าง" สแต็กโดยใช้โมดูลที่สามารถปรับใช้อย่างถูกต้องสำหรับการทดสอบระหว่าง CI/CD
Terraform และไมโครเซอร์วิส
ชีวิตและความตายของบริษัทไมโครเซอร์วิสนั้นขึ้นอยู่กับความเร็ว นวัตกรรม และการหยุดชะงักของเวิร์กสแต็กไมโครเซอร์วิสใหม่
ด้านลบที่พบบ่อยที่สุดที่เกี่ยวข้องกับสถาปัตยกรรมไมโครเซอร์วิส ซึ่งไม่สามารถกำจัดได้นั้นเกี่ยวข้องกับงาน ไม่ใช่โค้ด หากคุณคิดว่า Terraform เป็นเพียงวิธีหนึ่งในการทำให้เฉพาะโครงสร้างพื้นฐานของสถาปัตยกรรมไมโครเซอร์วิสเป็นแบบอัตโนมัติ คุณก็กำลังพลาดประโยชน์ที่แท้จริงของระบบ ตอนนี้ก็แล้ว .
ที่มา: will.com