วิธีการ ไอเอซี (โครงสร้างพื้นฐานเป็นโค้ด) ไม่เพียงแต่ประกอบด้วยโค้ดที่จัดเก็บไว้ในพื้นที่เก็บข้อมูลเท่านั้น แต่ยังรวมถึงบุคคลและกระบวนการที่ล้อมรอบโค้ดนี้ด้วย เป็นไปได้หรือไม่ที่จะนำแนวทางต่างๆ มาใช้ตั้งแต่การพัฒนาซอฟต์แวร์ไปจนถึงการจัดการโครงสร้างพื้นฐานและคำอธิบาย? เป็นความคิดที่ดีที่จะจำแนวคิดนี้ไว้ในขณะที่คุณอ่านบทความ
นี่คือบันทึกของฉัน บน .
สไลด์และวิดีโอ
- ดรายรัน 2019-04-24
โครงสร้างพื้นฐานเป็นประวัติการทุบตี
สมมติว่าคุณมาที่โปรเจ็กต์ใหม่ แล้วพวกเขาก็บอกคุณว่า: “เราทำได้แล้ว โครงสร้างพื้นฐานเป็นรหัส". ในความเป็นจริงปรากฎว่า โครงสร้างพื้นฐานเป็นประวัติการทุบตี หรือตัวอย่างเช่น เอกสารประกอบเป็นประวัติทุบตี. นี่เป็นสถานการณ์จริงมาก ตัวอย่างเช่น Denis Lysenko อธิบายกรณีที่คล้ายกันในสุนทรพจน์ เขาบอกว่าพวกเขามีโครงสร้างพื้นฐานที่สอดคล้องกันสำหรับโครงการจากประวัติทุบตีได้อย่างไร
ด้วยความปรารถนาบางอย่างเราก็พูดอย่างนั้นได้ โครงสร้างพื้นฐานเป็นประวัติการทุบตี นี่เป็นเหมือนรหัส:
- การทำซ้ำ: คุณสามารถใช้ bash history รันคำสั่งจากที่นั่น และคุณอาจได้รับการกำหนดค่าการทำงานเป็นเอาต์พุต
- การกำหนดเวอร์ชัน: คุณรู้ว่าใครเข้ามาและทำอะไร อีกครั้ง ไม่ใช่ความจริงที่ว่าสิ่งนี้จะนำคุณไปสู่การกำหนดค่าการทำงานที่ทางออก
- история: เรื่องใครทำอะไร มีเพียงคุณเท่านั้นที่ไม่สามารถใช้งานได้หากคุณสูญเสียเซิร์ฟเวอร์
จะทำอย่างไร?
โครงสร้างพื้นฐานเป็นรหัส
แม้กระทั่งกรณีที่แปลกประหลาดเช่นนี้ โครงสร้างพื้นฐานเป็นประวัติการทุบตี คุณสามารถดึงมันด้วยหูได้ โครงสร้างพื้นฐานเป็นรหัสแต่เมื่อเราต้องการทำสิ่งที่ซับซ้อนกว่าเซิร์ฟเวอร์ LAMP รุ่นเก่าที่ดี เราจะได้ข้อสรุปว่าโค้ดนี้จำเป็นต้องได้รับการแก้ไข เปลี่ยนแปลง ปรับปรุง ต่อไปเราอยากจะพิจารณาความคล้ายคลึงระหว่าง โครงสร้างพื้นฐานเป็นรหัส และการพัฒนาซอฟต์แวร์
แห้ง
ในโครงการพัฒนาระบบจัดเก็บข้อมูลมีงานย่อย : เรากำลังเปิดตัวรุ่นใหม่ - ต้องมีการเปิดตัวเพื่อการทดสอบเพิ่มเติม งานนั้นง่ายมาก:
- เข้าสู่ระบบที่นี่ผ่าน ssh และดำเนินการคำสั่ง
- คัดลอกไฟล์ที่นั่น
- แก้ไขการกำหนดค่าที่นี่
- เริ่มบริการที่นั่น
- ...
- กำไร!
สำหรับตรรกะที่อธิบายไว้ bash นั้นมากเกินพอ โดยเฉพาะอย่างยิ่งในช่วงแรกของโปรเจ็กต์ ซึ่งเป็นตอนที่มันเพิ่งเริ่มต้น นี้ แต่เมื่อเวลาผ่านไป มีการร้องขอให้ปรับใช้สิ่งที่คล้ายกัน แต่แตกต่างกันเล็กน้อย สิ่งแรกที่นึกถึงคือการคัดลอกและวาง และตอนนี้เรามีสคริปต์สองตัวที่คล้ายกันมากซึ่งทำสิ่งเดียวกันเกือบหมด เมื่อเวลาผ่านไป จำนวนสคริปต์เพิ่มขึ้น และเราต้องเผชิญกับความจริงที่ว่ามีตรรกะทางธุรกิจบางอย่างสำหรับการปรับใช้การติดตั้งที่จำเป็นต้องซิงโครไนซ์ระหว่างสคริปต์ต่างๆ ซึ่งค่อนข้างซับซ้อน
ปรากฎว่ามีวิธีปฏิบัติเช่น DRY (อย่าทำซ้ำตัวเอง) แนวคิดคือการนำโค้ดที่มีอยู่กลับมาใช้ใหม่ ฟังดูง่าย แต่เราไม่ได้มาถึงจุดนี้ทันที ในกรณีของเรา มันเป็นแนวคิดซ้ำซาก: แยกการกำหนดค่าออกจากสคริปต์ เหล่านั้น. ตรรกะทางธุรกิจของวิธีการปรับใช้การติดตั้งแยกกัน การกำหนดค่าแยกกัน
ของแข็งสำหรับ CFM
เมื่อเวลาผ่านไปโครงการก็เติบโตขึ้นและ คือการเกิดขึ้นของ Ansible เหตุผลหลักที่ทำให้เกิดสิ่งนี้คือทีมงานมีความเชี่ยวชาญ และการทุบตีนั้นไม่ได้ออกแบบมาเพื่อตรรกะที่ซับซ้อน Ansible เริ่มมีตรรกะที่ซับซ้อนด้วย เพื่อป้องกันไม่ให้ตรรกะที่ซับซ้อนกลายเป็นความสับสนวุ่นวาย มีหลักการในการจัดระเบียบโค้ดในการพัฒนาซอฟต์แวร์ แข็ง ตัวอย่างเช่น Grigory Petrov ในรายงาน "เหตุใดผู้เชี่ยวชาญด้านไอทีจึงต้องการแบรนด์ส่วนบุคคล" ทำให้เกิดคำถามว่าบุคคลได้รับการออกแบบในลักษณะที่ง่ายกว่าสำหรับเขาที่จะทำงานร่วมกับหน่วยงานทางสังคมบางแห่งในการพัฒนาซอฟต์แวร์เหล่านี้ เป็นวัตถุ หากเรารวมแนวคิดทั้งสองนี้เข้าด้วยกันและพัฒนาต่อไปเราจะสังเกตได้ว่าเราก็สามารถนำมาใช้ได้เช่นกัน แข็ง เพื่อให้ง่ายต่อการรักษาและแก้ไขตรรกะนี้ในอนาคต
หลักการความรับผิดชอบเดียว
แต่ละชั้นเรียนจะดำเนินการเพียงงานเดียวเท่านั้น
ไม่จำเป็นต้องผสมโค้ดและสร้างสัตว์ประหลาดสปาเก็ตตี้ศักดิ์สิทธิ์เสาหิน โครงสร้างพื้นฐานควรประกอบด้วยอิฐธรรมดา ปรากฎว่าหากคุณแบ่ง Playbook ของ Ansible ออกเป็นชิ้นเล็กๆ อ่านบทบาท Ansible ก็จะรักษาได้ง่ายขึ้น
หลักการเปิดปิด
หลักการเปิด/ปิด
- เปิดเพื่อขยาย: หมายความว่าพฤติกรรมของเอนทิตีสามารถขยายได้โดยการสร้างประเภทเอนทิตีใหม่
- ปิดเพื่อเปลี่ยนแปลง: อันเป็นผลมาจากการขยายลักษณะการทำงานของเอนทิตี ไม่ควรทำการเปลี่ยนแปลงกับโค้ดที่ใช้เอนทิตีเหล่านั้น
ในตอนแรก เราได้ปรับใช้โครงสร้างพื้นฐานการทดสอบบนเครื่องเสมือน แต่เนื่องจากตรรกะทางธุรกิจของการปรับใช้นั้นแยกออกจากการใช้งาน เราจึงเพิ่มการเปิดตัวไปยัง Baremetall โดยไม่มีปัญหาใดๆ
หลักการทดแทนลิสคอฟ
หลักการทดแทนของบาร์บารา ลิสคอฟ อ็อบเจ็กต์ในโปรแกรมจะต้องสามารถแทนที่ด้วยอินสแตนซ์ของชนิดย่อยได้โดยไม่ต้องเปลี่ยนการดำเนินการที่ถูกต้องของโปรแกรม
หากมองให้กว้างขึ้น ก็ไม่ใช่คุณลักษณะของโครงการใดโครงการหนึ่งที่สามารถนำไปใช้ที่นั่นได้ แข็งโดยทั่วไปจะเกี่ยวกับ CFM ตัวอย่างเช่นในโปรเจ็กต์อื่นจำเป็นต้องปรับใช้แอปพลิเคชัน Java ชนิดบรรจุกล่องที่ด้านบนของ Java, แอปพลิเคชันเซิร์ฟเวอร์, ฐานข้อมูล, ระบบปฏิบัติการ ฯลฯ ฉันจะพิจารณาหลักการเพิ่มเติมโดยใช้ตัวอย่างนี้ แข็ง
ในกรณีของเรา มีข้อตกลงภายในทีมโครงสร้างพื้นฐานว่าหากเราติดตั้งบทบาท imbjava หรือ oraclejava เราก็จะมีไฟล์ปฏิบัติการไบนารี java ได้ ซึ่งมีความจำเป็นเพราะว่า บทบาทต้นทางขึ้นอยู่กับลักษณะการทำงานนี้ โดยคาดหวัง java ในเวลาเดียวกัน สิ่งนี้ช่วยให้เราสามารถแทนที่การใช้งานจาวา/เวอร์ชันหนึ่งด้วยอีกเวอร์ชันหนึ่งได้โดยไม่ต้องเปลี่ยนตรรกะการปรับใช้แอปพลิเคชัน
ปัญหาอยู่ที่ว่าเป็นไปไม่ได้ที่จะนำไปใช้ใน Ansible ซึ่งเป็นผลมาจากข้อตกลงบางอย่างปรากฏภายในทีม
หลักการแยกส่วนต่อประสาน
หลักการแยกอินเทอร์เฟซ: “อินเทอร์เฟซเฉพาะไคลเอนต์จำนวนมากดีกว่าอินเทอร์เฟซทั่วไปเพียงอินเทอร์เฟซเดียว
ในตอนแรก เราพยายามที่จะรวมความแปรปรวนทั้งหมดของการปรับใช้แอปพลิเคชันไว้ใน Playbook Ansible เดียว แต่เป็นการยากที่จะรองรับ และแนวทางเมื่อเราระบุอินเทอร์เฟซภายนอก (ไคลเอนต์คาดว่าพอร์ต 443) จากนั้นจึงสามารถประกอบโครงสร้างพื้นฐานจากแต่ละบุคคลได้ อิฐสำหรับการใช้งานเฉพาะ
หลักการผกผันการพึ่งพา
หลักการผกผันการพึ่งพา โมดูลในระดับที่สูงกว่าไม่ควรขึ้นอยู่กับโมดูลในระดับที่ต่ำกว่า โมดูลทั้งสองประเภทต้องขึ้นอยู่กับนามธรรม นามธรรมไม่ควรขึ้นอยู่กับรายละเอียด รายละเอียดจะต้องขึ้นอยู่กับนามธรรม
ตัวอย่างนี้จะขึ้นอยู่กับการต่อต้านรูปแบบ
- ลูกค้ารายหนึ่งมีคลาวด์ส่วนตัว
- เราสั่งซื้อเครื่องเสมือนภายในระบบคลาวด์
- แต่เนื่องจากธรรมชาติของระบบคลาวด์ การใช้งานแอปพลิเคชันจึงเชื่อมโยงกับไฮเปอร์ไวเซอร์ที่ VM เปิดอยู่
เหล่านั้น. ตรรกะการปรับใช้แอปพลิเคชันระดับสูงไหลไปตามการขึ้นต่อกันของไฮเปอร์ไวเซอร์ระดับล่าง และนี่ทำให้เกิดปัญหาเมื่อนำตรรกะนี้กลับมาใช้ใหม่ อย่าทำเช่นนี้
ปฏิสัมพันธ์
โครงสร้างพื้นฐานที่เป็นโค้ดไม่เพียงแต่เกี่ยวกับโค้ดเท่านั้น แต่ยังเกี่ยวกับความสัมพันธ์ระหว่างโค้ดกับผู้คน เกี่ยวกับการโต้ตอบระหว่างนักพัฒนาโครงสร้างพื้นฐานอีกด้วย
ปัจจัยรถบัส
สมมติว่าคุณมี Vasya ในโครงการของคุณ Vasya รู้ทุกอย่างเกี่ยวกับโครงสร้างพื้นฐานของคุณ จะเกิดอะไรขึ้นหากจู่ๆ Vasya หายไป? นี่เป็นสถานการณ์จริงมาก เพราะเขาอาจถูกรถบัสชนได้ บางครั้งมันก็เกิดขึ้น หากสิ่งนี้เกิดขึ้นและไม่มีการแจกจ่ายความรู้เกี่ยวกับโค้ด โครงสร้าง วิธีการทำงาน ลักษณะที่ปรากฏและรหัสผ่านให้กับทีม คุณอาจเผชิญกับสถานการณ์ที่ไม่พึงประสงค์หลายประการ เพื่อลดความเสี่ยงเหล่านี้และกระจายความรู้ภายในทีม คุณสามารถใช้แนวทางต่างๆ ได้
จับคู่ Devopsing
มันไม่เหมือน ว่าผู้ดูแลระบบดื่มเบียร์ เปลี่ยนรหัสผ่าน และการเขียนโปรแกรมคู่แบบอะนาล็อก เหล่านั้น. วิศวกรสองคนนั่งที่คอมพิวเตอร์เครื่องเดียว คีย์บอร์ดหนึ่งเครื่อง และเริ่มตั้งค่าโครงสร้างพื้นฐานร่วมกัน เช่น การตั้งค่าเซิร์ฟเวอร์ เขียนบทบาท Ansible ฯลฯ มันฟังดูดี แต่มันก็ไม่ได้ผลสำหรับเรา แต่กรณีพิเศษของการปฏิบัตินี้ได้ผล มีพนักงานใหม่เข้ามา ที่ปรึกษาจะปฏิบัติงานจริงร่วมกับเขา ทำงานและถ่ายทอดความรู้
กรณีพิเศษอีกกรณีหนึ่งคือการเรียกเหตุการณ์ ระหว่างเกิดปัญหา กลุ่มผู้ปฏิบัติหน้าที่และผู้ที่เกี่ยวข้องมารวมตัวกัน ผู้นำคนหนึ่งได้รับการแต่งตั้งซึ่งแบ่งปันหน้าจอของเขาและแสดงความคิดเห็นเกี่ยวกับความคิด ผู้เข้าร่วมคนอื่นๆ ติดตามความคิดของผู้นำ สอดแนมกลเม็ดจากคอนโซล ตรวจสอบว่าพวกเขาไม่ได้พลาดบรรทัดในบันทึก และเรียนรู้สิ่งใหม่ๆ เกี่ยวกับระบบ วิธีการนี้ใช้ได้ผลบ่อยกว่านั้น
การตรวจสอบโค้ด
โดยส่วนตัวแล้ว การเผยแพร่ความรู้เกี่ยวกับโครงสร้างพื้นฐานและวิธีการทำงานโดยใช้การตรวจสอบโค้ดจะมีประสิทธิภาพมากกว่า:
- โครงสร้างพื้นฐานอธิบายด้วยโค้ดในพื้นที่เก็บข้อมูล
- การเปลี่ยนแปลงเกิดขึ้นในสาขาที่แยกจากกัน
- ในระหว่างการร้องขอการรวม คุณสามารถดูส่วนต่างของการเปลี่ยนแปลงในโครงสร้างพื้นฐานได้
ไฮไลท์ที่นี่คือการคัดเลือกผู้วิจารณ์ทีละคนตามกำหนดเวลาคือ มีความเป็นไปได้ในระดับหนึ่งที่คุณจะปีนเข้าสู่โครงสร้างพื้นฐานชิ้นใหม่
รหัสสไตล์
เมื่อเวลาผ่านไป การทะเลาะวิวาทเริ่มปรากฏขึ้นระหว่างการรีวิว เพราะ... ผู้วิจารณ์มีสไตล์เป็นของตัวเอง และการหมุนเวียนของผู้วิจารณ์ก็ซ้อนกันด้วยสไตล์ที่แตกต่างกัน: 2 ช่องว่างหรือ 4, CamelCase หรือ Snake_case ไม่สามารถดำเนินการนี้ได้ในทันที
- แนวคิดแรกคือการแนะนำให้ใช้ linter เพราะทุกคนเป็นวิศวกร ทุกคนฉลาด แต่ตัวแก้ไข OS ต่างกันไม่สะดวก
- สิ่งนี้พัฒนาเป็นบอทที่เขียนให้หย่อนสำหรับแต่ละคอมมิตที่มีปัญหาและแนบเอาต์พุต linter แต่ในกรณีส่วนใหญ่ มีสิ่งสำคัญกว่าที่ต้องทำและโค้ดยังคงไม่ได้รับการแก้ไข
อาจารย์สร้างสีเขียว
เวลาผ่านไป และเราได้ข้อสรุปว่าการคอมมิตที่ไม่ผ่านการทดสอบบางอย่างไม่สามารถอนุญาตให้เข้าสู่มาสเตอร์ได้ เอาล่ะ! เราคิดค้น Green Build Master ซึ่งได้รับการฝึกฝนในการพัฒนาซอฟต์แวร์มาเป็นเวลานาน:
- กำลังดำเนินการพัฒนาในสาขาที่แยกจากกัน
- การทดสอบกำลังทำงานอยู่ในหัวข้อนี้
- หากการทดสอบล้มเหลว โค้ดจะไม่ทำให้เป็นต้นแบบ
การตัดสินใจครั้งนี้เป็นเรื่องที่เจ็บปวดมาก เพราะ... ก่อให้เกิดความขัดแย้งมากมาย แต่ก็คุ้มค่า เพราะ... บทวิจารณ์เริ่มได้รับการร้องขอให้รวมกิจการโดยไม่มีรูปแบบที่แตกต่างกัน และเมื่อเวลาผ่านไป จำนวนส่วนที่เป็นปัญหาก็เริ่มลดลง
การทดสอบ IaC
นอกเหนือจากการตรวจสอบสไตล์แล้ว คุณยังสามารถใช้สิ่งอื่นๆ ได้ เช่น เพื่อตรวจสอบว่าโครงสร้างพื้นฐานของคุณสามารถปรับใช้ได้จริงหรือไม่ หรือตรวจสอบว่าการเปลี่ยนแปลงโครงสร้างพื้นฐานจะไม่ทำให้สูญเสียเงิน เหตุใดสิ่งนี้จึงจำเป็น? คำถามนี้ซับซ้อนและเป็นเชิงปรัชญา ควรตอบด้วยเรื่องราวที่ว่า Powershell มีตัวปรับขนาดอัตโนมัติที่ไม่ได้ตรวจสอบเงื่อนไขขอบเขต => มีการสร้าง VM มากกว่าที่จำเป็น => ลูกค้าใช้จ่ายเงินมากกว่าที่วางแผนไว้ สิ่งนี้ไม่น่าพอใจนัก แต่ก็ค่อนข้างเป็นไปได้ที่จะตรวจพบข้อผิดพลาดนี้ในระยะก่อนหน้านี้
อาจมีคนถามว่าเหตุใดจึงต้องสร้างโครงสร้างพื้นฐานที่ซับซ้อนให้ซับซ้อนยิ่งขึ้น การทดสอบโครงสร้างพื้นฐาน เช่นเดียวกับโค้ด ไม่ได้เกี่ยวกับการทำให้เข้าใจง่าย แต่เกี่ยวกับการรู้ว่าโครงสร้างพื้นฐานของคุณควรทำงานอย่างไร
ปิรามิดทดสอบ IaC
การทดสอบ IaC: การวิเคราะห์แบบคงที่
หากคุณปรับใช้โครงสร้างพื้นฐานทั้งหมดพร้อมกันและตรวจสอบว่าใช้งานได้ คุณอาจพบว่าใช้เวลานานและใช้เวลานานมาก ดังนั้นพื้นฐานจึงต้องเป็นสิ่งที่ทำงานเร็ว มีมาก และครอบคลุมถึงจุดดั้งเดิมมากมาย
ทุบตีเป็นเรื่องยุ่งยาก
ลองดูตัวอย่างเล็กน้อย เลือกไฟล์ทั้งหมดในไดเร็กทอรีปัจจุบันและคัดลอกไปยังตำแหน่งอื่น สิ่งแรกที่นึกถึง:
for i in * ; do
cp $i /some/path/$i.bak
doneเกิดอะไรขึ้นถ้ามีช่องว่างในชื่อไฟล์? โอเค เราฉลาด เรารู้วิธีใช้เครื่องหมายคำพูด:
for i in * ; do cp "$i" "/some/path/$i.bak" ; doneทำได้ดี? เลขที่! จะเกิดอะไรขึ้นถ้าไม่มีอะไรในไดเร็กทอรีเช่น การกลมจะไม่ทำงาน
find . -type f -exec mv -v {} dst/{}.bak ;ตอนนี้ทำได้ดีแล้ว? ไม่... ลืมสิ่งที่สามารถอยู่ในชื่อไฟล์ได้ n.
touch x
mv x "$(printf "foonbar")"
find . -type f -print0 | xargs -0 mv -t /path/to/target-dirเครื่องมือวิเคราะห์แบบคงที่
ปัญหาจากขั้นตอนที่แล้วสามารถจับได้เมื่อเราลืมคำพูดเพราะมีวิธีแก้ไขมากมายในธรรมชาติ โดยทั่วไปมีจำนวนมากและเป็นไปได้มากว่าคุณจะพบ linter สำหรับสแต็กของคุณภายใต้ IDE ของคุณ
ภาษา
เครื่องมือ
ทุบตี
ทับทิม
หลาม
เบิ้ล
การทดสอบ IaC: การทดสอบหน่วย
ดังที่เราเห็นจากตัวอย่างที่แล้ว linters ไม่ได้มีอำนาจทุกอย่างและไม่สามารถชี้ให้เห็นปัญหาทั้งหมดได้ นอกจากนี้ โดยการเปรียบเทียบกับการทดสอบในการพัฒนาซอฟต์แวร์ เราสามารถจำการทดสอบหน่วยได้ สิ่งที่เข้ามาในใจทันทีคือ , , , . แต่จะทำอย่างไรกับ ansible, เชฟ, saltstack และคนอื่น ๆ ที่คล้ายกัน?
ในตอนแรกเราพูดถึง แข็ง และโครงสร้างพื้นฐานของเราควรประกอบด้วยอิฐขนาดเล็ก เวลาของพวกเขามาถึงแล้ว
- โครงสร้างพื้นฐานแบ่งออกเป็นอิฐขนาดเล็ก เช่น บทบาท Ansible
- มีการปรับใช้สภาพแวดล้อมบางประเภท ไม่ว่าจะเป็นนักเทียบท่าหรือ VM
- เราใช้บทบาท Ansible ของเรากับสภาพแวดล้อมการทดสอบนี้
- เราตรวจสอบว่าทุกอย่างทำงานได้ตามที่เราคาดหวัง (เราทำการทดสอบ)
- เราตัดสินใจว่าโอเคหรือไม่โอเค
การทดสอบ IaC: เครื่องมือทดสอบหน่วย
คำถาม การทดสอบ CFM คืออะไร? คุณสามารถเรียกใช้สคริปต์หรือใช้โซลูชันสำเร็จรูปสำหรับสิ่งนี้:
CFM
เครื่องมือ
เบิ้ล
พ่อครัว
พ่อครัว
กองเกลือ
ตัวอย่างสำหรับ testinfra การตรวจสอบผู้ใช้นั้น test1, test2 มีอยู่และอยู่ในกลุ่ม sshusers:
def test_default_users(host):
users = ['test1', 'test2' ]
for login in users:
assert host.user(login).exists
assert 'sshusers' in host.user(login).groupsจะเลือกอะไรดี? คำถามนี้ซับซ้อนและคลุมเครือ นี่คือตัวอย่างการเปลี่ยนแปลงในโครงการบน GitHub สำหรับปี 2018-2019:
กรอบการทดสอบ IaC
คำถามเกิดขึ้น: จะรวบรวมทั้งหมดและเปิดใช้งานได้อย่างไร? สามารถ หากมีวิศวกรเพียงพอ หรือคุณสามารถใช้วิธีแก้ปัญหาสำเร็จรูปได้แม้ว่าจะมีไม่มากนัก:
CFM
เครื่องมือ
เบิ้ล
พ่อครัว
terraform
ตัวอย่างการเปลี่ยนแปลงในโครงการบน GitHub สำหรับปี 2018-2019:
โมเลกุลเทียบกับ ครัวทดสอบ
ในตอนแรกเรา :
- สร้าง VM แบบขนาน
- ใช้บทบาท Ansible
- ดำเนินการตรวจสอบ
สำหรับบทบาท 25-35 บทบาทใช้เวลา 40-70 นาที ซึ่งถือว่านานมาก
ขั้นตอนต่อไปคือการเปลี่ยนไปใช้เจนกินส์/นักเทียบท่า/แอนซิเบิล/โมเลกุล ตามหลักสรีรวิทยาทุกอย่างก็เหมือนกัน
- หนังสือเล่นผ้าสำลี
- เรียงตามบทบาท.
- เปิดตัวคอนเทนเนอร์
- ใช้บทบาท Ansible
- เรียกใช้ testinfra
- ตรวจสอบความไร้สมรรถภาพ
การ Lining สำหรับ 40 บทบาทและการทดสอบสำหรับโหลเริ่มใช้เวลาประมาณ 15 นาที
สิ่งที่จะเลือกขึ้นอยู่กับหลายปัจจัย เช่น stack ที่ใช้ ความชำนาญในทีม เป็นต้น ที่นี่ทุกคนตัดสินใจด้วยตนเองว่าจะปิดคำถามการทดสอบหน่วยอย่างไร
การทดสอบ IaC: การทดสอบการรวมระบบ
ขั้นตอนต่อไปในปิระมิดการทดสอบโครงสร้างพื้นฐานคือการทดสอบบูรณาการ คล้ายกับการทดสอบหน่วย:
- โครงสร้างพื้นฐานแบ่งออกเป็นอิฐขนาดเล็ก เช่น บทบาท Ansible
- มีการปรับใช้สภาพแวดล้อมบางประเภท ไม่ว่าจะเป็นนักเทียบท่าหรือ VM
- สำหรับสภาพแวดล้อมการทดสอบนี้ จำนวนมาก บทบาทที่เข้าใจได้
- เราตรวจสอบว่าทุกอย่างทำงานได้ตามที่เราคาดหวัง (เราทำการทดสอบ)
- เราตัดสินใจว่าโอเคหรือไม่โอเค
โดยทั่วไปแล้ว เราไม่ได้ตรวจสอบประสิทธิภาพขององค์ประกอบแต่ละส่วนของระบบเหมือนกับในการทดสอบหน่วย แต่เราตรวจสอบว่าเซิร์ฟเวอร์ได้รับการกำหนดค่าโดยรวมอย่างไร
การทดสอบ IaC: การทดสอบตั้งแต่ต้นจนจบ
ที่ด้านบนสุดของปิรามิด เราได้รับการต้อนรับด้วยการทดสอบแบบ End to End เหล่านั้น. เราไม่ตรวจสอบประสิทธิภาพของเซิร์ฟเวอร์ที่แยกจากกัน สคริปต์ที่แยกจากกัน หรืออิฐที่แยกจากกันของโครงสร้างพื้นฐานของเรา เราตรวจสอบว่าเซิร์ฟเวอร์จำนวนมากเชื่อมต่อเข้าด้วยกัน โครงสร้างพื้นฐานของเราทำงานตามที่เราคาดหวัง น่าเสียดายที่ฉันไม่เคยเห็นโซลูชันแบบบรรจุกล่องสำเร็จรูปมาก่อน อาจเป็นเพราะ... โครงสร้างพื้นฐานมักจะมีเอกลักษณ์เฉพาะตัวและยากต่อการสร้างเทมเพลตและสร้างเฟรมเวิร์กสำหรับการทดสอบ ด้วยเหตุนี้ ทุกคนจึงสร้างโซลูชันของตนเองขึ้นมา มีความต้องการแต่ไม่มีคำตอบ ดังนั้นฉันจะบอกคุณว่ามีอะไรบ้างเพื่อผลักดันคนอื่นให้คิดหรือขยี้จมูกในความจริงที่ว่าทุกสิ่งถูกประดิษฐ์ขึ้นต่อหน้าเรามานานแล้ว
โครงการที่มีประวัติศาสตร์อันยาวนาน มันถูกใช้ในองค์กรขนาดใหญ่ และอาจเป็นไปได้ว่าพวกคุณแต่ละคนอาจก้าวข้ามเส้นทางนี้ทางอ้อมไปด้วย แอปพลิเคชันรองรับฐานข้อมูล การบูรณาการ ฯลฯ มากมาย การรู้ว่าโครงสร้างพื้นฐานอาจมีลักษณะเป็นอย่างไรคือไฟล์นักเทียบท่าจำนวนมาก และการรู้ว่าการทดสอบใดที่จะรันในสภาพแวดล้อมใดคือเจนกินส์
โครงการนี้ใช้ได้ผลมาเป็นเวลานานจนกระทั่งอยู่ในกรอบการทำงาน เรายังไม่ได้พยายามถ่ายโอนสิ่งนี้ไปยัง Openshift คอนเทนเนอร์ยังคงเหมือนเดิม แต่สภาพแวดล้อมการเปิดตัวมีการเปลี่ยนแปลง (สวัสดี DRY อีกครั้ง)
แนวคิดการวิจัยดำเนินต่อไป และใน openshift พวกเขาพบสิ่งที่เรียกว่า APB (Ansible Playbook Bundle) ซึ่งช่วยให้คุณรวบรวมความรู้เกี่ยวกับวิธีการปรับใช้โครงสร้างพื้นฐานลงในคอนเทนเนอร์ เหล่านั้น. มีจุดความรู้ที่สามารถทำซ้ำและทดสอบได้เกี่ยวกับวิธีการปรับใช้โครงสร้างพื้นฐาน
ทั้งหมดนี้ฟังดูดีจนกระทั่งเราพบกับโครงสร้างพื้นฐานที่แตกต่างกัน: เราต้องการ Windows สำหรับการทดสอบ เป็นผลให้ความรู้เกี่ยวกับอะไร ที่ไหน วิธีการปรับใช้ และการทดสอบอยู่ในเจนกินส์
สรุป
โครงสร้างพื้นฐานตามรหัสที่เป็นอยู่
- รหัสในพื้นที่เก็บข้อมูล
- ปฏิสัมพันธ์ของมนุษย์
- การทดสอบโครงสร้างพื้นฐาน
การเชื่อมโยง
- ดรายรัน 2019-04-24
- &
ที่มา: will.com