บันทึก. แปล: หลังจากการตีพิมพ์ครั้งล่าสุด เกี่ยวกับวิธีการดึงและดันใน GitOps เราเห็นความสนใจในโมเดลนี้โดยทั่วไป แต่มีสิ่งพิมพ์ภาษารัสเซียน้อยมากในหัวข้อนี้ (ไม่มีในHabréเลย) ดังนั้นเราจึงยินดีที่จะนำเสนอการแปลบทความอื่นให้คุณทราบ - แม้ว่าจะเกือบหนึ่งปีที่แล้วก็ตาม! — จาก Weaveworks หัวหน้าผู้ก่อตั้งคำว่า “GitOps” ข้อความอธิบายสาระสำคัญของแนวทางและความแตกต่างที่สำคัญจากแนวทางที่มีอยู่
ปีที่แล้วเราเผยแพร่ . ย้อนกลับไปตอนนั้น เราได้แชร์วิธีที่ทีม Weaveworks เปิดตัว SaaS โดยอิงจาก Kubernetes ทั้งหมด และพัฒนาชุดแนวทางปฏิบัติที่ดีที่สุดที่กำหนดไว้สำหรับการปรับใช้ จัดการ และติดตามในสภาพแวดล้อมแบบคลาวด์เนทิฟ
บทความนี้ได้รับความนิยม คนอื่นๆ เริ่มพูดคุยเกี่ยวกับ GitOps และเริ่มเผยแพร่เครื่องมือใหม่สำหรับ , , , , และอื่น ๆ ปรากฏบนเว็บไซต์ของเรา สิ่งตีพิมพ์และกรณีการใช้งาน GitOps แต่บางคนยังคงมีคำถาม โมเดลแตกต่างจากแบบดั้งเดิมอย่างไร? และการส่งมอบอย่างต่อเนื่อง ()? จำเป็นต้องใช้ Kubernetes หรือไม่?
ในไม่ช้าเราก็ตระหนักว่าจำเป็นต้องมีคำอธิบายใหม่ โดยเสนอ:
- ตัวอย่างและเรื่องราวมากมาย
- คำจำกัดความเฉพาะของ GitOps
- เปรียบเทียบกับการจัดส่งต่อเนื่องแบบเดิมๆ
ในบทความนี้เราได้พยายามครอบคลุมหัวข้อเหล่านี้ทั้งหมด โดยให้ข้อมูลเบื้องต้นที่อัปเดตเกี่ยวกับ GitOps และนักพัฒนาและมุมมองของ CI/CD เรามุ่งเน้นไปที่ Kubernetes เป็นหลัก แม้ว่าโมเดลจะสามารถสรุปได้ก็ตาม
พบกับ GitOps
ลองนึกภาพอลิซ เธอดำเนินกิจการ Family Insurance ซึ่งให้บริการประกันสุขภาพ รถยนต์ บ้าน และการเดินทางแก่ผู้ที่มีงานยุ่งเกินกว่าจะเข้าใจรายละเอียดสัญญาด้วยตนเอง ธุรกิจของเธอเริ่มต้นจากโครงการรองเมื่ออลิซทำงานที่ธนาคารในตำแหน่งนักวิทยาศาสตร์ข้อมูล วันหนึ่งเธอตระหนักว่าเธอสามารถใช้อัลกอริธึมคอมพิวเตอร์ขั้นสูงเพื่อวิเคราะห์ข้อมูลและกำหนดแพ็คเกจประกันภัยได้อย่างมีประสิทธิภาพมากขึ้น นักลงทุนสนับสนุนโครงการนี้ และตอนนี้บริษัทของเธอมีรายได้มากกว่า 20 ล้านเหรียญต่อปีและกำลังเติบโตอย่างรวดเร็ว ปัจจุบันมีพนักงาน 180 คนในตำแหน่งต่างๆ รวมถึงทีมงานเทคโนโลยีที่พัฒนา ดูแลรักษาเว็บไซต์ ฐานข้อมูล และวิเคราะห์ฐานลูกค้า ทีมงานจำนวน 60 คน นำโดย Bob ผู้อำนวยการด้านเทคนิคของบริษัท
ทีมของ Bob ปรับใช้ระบบการผลิตในระบบคลาวด์ แอปพลิเคชันหลักทำงานบน GKE โดยใช้ประโยชน์จาก Kubernetes บน Google Cloud นอกจากนี้พวกเขายังใช้เครื่องมือข้อมูลและการวิเคราะห์ต่างๆ ในการทำงานอีกด้วย
Family Insurance ไม่ได้ตั้งใจจะใช้ตู้คอนเทนเนอร์ แต่สนใจในความกระตือรือร้นของ Docker ไม่นานบริษัทก็ค้นพบว่า GKE ช่วยให้ปรับใช้คลัสเตอร์เพื่อทดสอบฟีเจอร์ใหม่ๆ ได้อย่างง่ายดาย มีการเพิ่ม Jenkins สำหรับ CI และ Quay เพื่อจัดระเบียบรีจิสทรีคอนเทนเนอร์ โดยมีการเขียนสคริปต์สำหรับ Jenkins ที่พุชคอนเทนเนอร์และการกำหนดค่าใหม่ไปยัง GKE
เวลาผ่านไปแล้ว อลิซและบ็อบรู้สึกผิดหวังกับประสิทธิภาพของแนวทางที่พวกเขาเลือกและผลกระทบต่อธุรกิจ การเปิดตัวคอนเทนเนอร์ไม่ได้ปรับปรุงประสิทธิภาพการผลิตเท่าที่ทีมงานหวังไว้ บางครั้งการปรับใช้อาจขัดข้อง และไม่ชัดเจนว่าการเปลี่ยนแปลงโค้ดเป็นสาเหตุหรือไม่ การติดตามการเปลี่ยนแปลงการกำหนดค่าก็กลายเป็นเรื่องยากเช่นกัน บ่อยครั้งที่จำเป็นต้องสร้างคลัสเตอร์ใหม่และย้ายแอปพลิเคชันไปที่คลัสเตอร์ เนื่องจากนี่เป็นวิธีที่ง่ายที่สุดในการกำจัดความยุ่งเหยิงที่ระบบเกิดขึ้น อลิซกลัวว่าสถานการณ์จะแย่ลงเมื่อแอปพลิเคชันพัฒนาขึ้น (นอกจากนี้ กำลังสร้างโปรเจ็กต์ใหม่ที่ใช้การเรียนรู้ของเครื่อง) Bob ทำงานอัตโนมัติเป็นส่วนใหญ่และไม่เข้าใจว่าทำไมไปป์ไลน์ถึงยังไม่เสถียร ปรับขนาดได้ไม่ดี และต้องมีการแทรกแซงด้วยตนเองเป็นระยะๆ
จากนั้นพวกเขาก็ได้เรียนรู้เกี่ยวกับ GitOps การตัดสินใจครั้งนี้กลายเป็นสิ่งที่พวกเขาต้องการเพื่อก้าวไปข้างหน้าอย่างมั่นใจ
Alice และ Bob เคยได้ยินเกี่ยวกับ Git, DevOps และโครงสร้างพื้นฐานเป็นเวิร์กโฟลว์โค้ดมาหลายปีแล้ว สิ่งที่เป็นเอกลักษณ์เกี่ยวกับ GitOps คือนำชุดแนวทางปฏิบัติที่ดีที่สุด ทั้งเชิงสรุปและเชิงบรรทัดฐาน มาใช้เพื่อนำแนวคิดเหล่านี้ไปปฏิบัติในบริบทของ Kubernetes ธีมนี้ รวมถึงใน .
Family Insurance ตัดสินใจนำ GitOps ไปใช้ ขณะนี้บริษัทมีรูปแบบการทำงานอัตโนมัติที่เข้ากันได้กับ Kubernetes และผสมผสานกัน ความเร็ว ด้วย ความมั่นคงเพราะพวกเขา:
- พบว่าผลงานของทีมเพิ่มขึ้นสองเท่าโดยไม่มีใครคลั่งไคล้
- หยุดให้บริการสคริปต์แล้ว แต่ขณะนี้พวกเขาสามารถมุ่งเน้นไปที่คุณสมบัติใหม่ๆ และปรับปรุงวิธีการทางวิศวกรรมได้ เช่น การแนะนำการเปิดตัว Canary และปรับปรุงการทดสอบ
- เราได้ปรับปรุงกระบวนการปรับใช้เพื่อที่จะไม่ค่อยพัง
- ได้รับโอกาสในการกู้คืนการปรับใช้หลังจากความล้มเหลวบางส่วนโดยไม่มีการแทรกแซงด้วยตนเอง
- ซื้อมาใช้แล้วоมั่นใจในระบบการจัดส่งมากขึ้น อลิซและบ็อบค้นพบว่าพวกเขาสามารถแบ่งทีมออกเป็นทีมไมโครเซอร์วิสที่ทำงานคู่ขนานได้
- สามารถทำการเปลี่ยนแปลงโครงการได้ 30-50 รายการทุกวันผ่านความพยายามของแต่ละกลุ่มและลองใช้เทคนิคใหม่ ๆ
- มันง่ายที่จะดึงดูดนักพัฒนารายใหม่เข้าสู่โปรเจ็กต์ซึ่งมีโอกาสเปิดตัวการอัปเดตสู่การผลิตโดยใช้คำขอดึงภายในไม่กี่ชั่วโมง
- ผ่านการตรวจสอบภายในกรอบ SOC2 ได้อย่างง่ายดาย (เพื่อการปฏิบัติตามข้อกำหนดของผู้ให้บริการด้านการจัดการข้อมูลที่ปลอดภัย อ่านเพิ่มเติม เช่น - ประมาณ แปล.).
เกิดอะไรขึ้น?
GitOps มีสองสิ่ง:
- โมเดลการดำเนินงานสำหรับ Kubernetes และ Cloud Native โดยให้ชุดแนวทางปฏิบัติที่ดีที่สุดสำหรับการปรับใช้ จัดการ และติดตามคลัสเตอร์และแอปพลิเคชันแบบคอนเทนเนอร์ นิยามที่หรูหราในรูปแบบ จาก :
- เส้นทางสู่การสร้างสภาพแวดล้อมการจัดการแอปพลิเคชันที่เน้นนักพัฒนาเป็นศูนย์กลาง เราใช้เวิร์กโฟลว์ Git กับทั้งการดำเนินงานและการพัฒนา โปรดทราบว่านี่ไม่ใช่แค่เกี่ยวกับการพุช Git เท่านั้น แต่ยังเกี่ยวกับการจัดระเบียบชุดเครื่องมือ CI/CD และ UI/UX ทั้งหมด
คำไม่กี่คำเกี่ยวกับ Git
หากคุณไม่คุ้นเคยกับระบบควบคุมเวอร์ชันและเวิร์กโฟลว์ที่ใช้ Git เราขอแนะนำให้เรียนรู้เกี่ยวกับระบบเหล่านี้ การทำงานกับสาขาและการร้องขอการดึงอาจดูเหมือนเป็นมนต์ดำในตอนแรก แต่ผลประโยชน์ก็คุ้มค่ากับความพยายาม ที่นี่ เริ่ม.
Kubernetes ทำงานอย่างไร
ในเรื่องราวของเรา Alice และ Bob หันมาใช้ GitOps หลังจากทำงานร่วมกับ Kubernetes มาได้ระยะหนึ่งแล้ว แท้จริงแล้ว GitOps มีความเกี่ยวข้องอย่างใกล้ชิดกับ Kubernetes ซึ่งเป็นโมเดลการดำเนินงานสำหรับโครงสร้างพื้นฐานและแอปพลิเคชันบน Kubernetes
Kubernetes ให้อะไรแก่ผู้ใช้?
นี่คือคุณสมบัติหลักบางประการ:
- ในโมเดล Kubernetes ทุกอย่างสามารถอธิบายได้ในรูปแบบการประกาศ
- เซิร์ฟเวอร์ Kubernetes API จะใช้การประกาศนี้เป็นอินพุต จากนั้นจะพยายามนำคลัสเตอร์เข้าสู่สถานะที่อธิบายไว้ในการประกาศอย่างต่อเนื่อง
- การประกาศนั้นเพียงพอที่จะอธิบายและจัดการปริมาณงานที่หลากหลาย—“แอปพลิเคชัน”
- เป็นผลให้การเปลี่ยนแปลงแอปพลิเคชันและคลัสเตอร์เกิดขึ้นเนื่องจาก:
- การเปลี่ยนแปลงในอิมเมจคอนเทนเนอร์
- การเปลี่ยนแปลงข้อกำหนดที่ประกาศ
- ข้อผิดพลาดในสภาพแวดล้อม - ตัวอย่างเช่น คอนเทนเนอร์ล่ม
ความสามารถในการบรรจบกันที่ยอดเยี่ยมของ Kubernetes
เมื่อผู้ดูแลระบบทำการเปลี่ยนแปลงการกำหนดค่า ผู้ดำเนินการ Kubernetes จะนำไปใช้กับคลัสเตอร์ตราบเท่าที่สถานะเป็น จะไม่เข้าใกล้การกำหนดค่าใหม่. โมเดลนี้ใช้ได้กับทรัพยากร Kubernetes ใดๆ และสามารถขยายได้ด้วย Custom Resource Definitions (CRD) ดังนั้น การใช้งาน Kubernetes จึงมีคุณสมบัติที่ยอดเยี่ยมดังต่อไปนี้:
- อัตโนมัติ: การอัปเดต Kubernetes เป็นกลไกในการทำให้กระบวนการนำการเปลี่ยนแปลงไปใช้โดยอัตโนมัติอย่างสวยงามและทันท่วงที
- การบรรจบกัน: Kubernetes จะพยายามอัปเดตต่อไปจนกว่าจะสำเร็จ
- ความเป็นเอกภาพ: การใช้การลู่เข้าซ้ำๆ ทำให้เกิดผลลัพธ์เดียวกัน
- ความมุ่งมั่น: เมื่อทรัพยากรเพียงพอ สถานะของคลัสเตอร์ที่อัปเดตจะขึ้นอยู่กับสถานะที่ต้องการเท่านั้น
GitOps ทำงานอย่างไร
เราได้เรียนรู้เกี่ยวกับ Kubernetes มากพอที่จะอธิบายวิธีการทำงานของ GitOps
กลับมาที่ทีมไมโครเซอร์วิสของ Family Insurance กัน ปกติพวกเขาต้องทำอะไร? ดูรายการด้านล่าง (หากมีรายการใดที่ดูแปลกหรือไม่คุ้นเคยกรุณาระงับการวิพากษ์วิจารณ์และอยู่กับเรา) นี่เป็นเพียงตัวอย่างของเวิร์กโฟลว์ที่ใช้ Jenkins มีกระบวนการอื่นๆ มากมายเมื่อทำงานกับเครื่องมืออื่นๆ
สิ่งสำคัญคือเราจะเห็นว่าการอัปเดตแต่ละครั้งจะจบลงด้วยการเปลี่ยนแปลงไฟล์การกำหนดค่าและที่เก็บ Git การเปลี่ยนแปลง Git เหล่านี้ทำให้ "ตัวดำเนินการ GitOps" อัปเดตคลัสเตอร์:
1.ขั้นตอนการทำงาน: "Jenkins build - สาขาหลัก'
รายการงาน:
- Jenkins ผลักดันภาพที่แท็กไปที่ Quay;
- Jenkins พุชแผนภูมิการกำหนดค่าและ Helm ไปยังบัคเก็ตพื้นที่จัดเก็บข้อมูลหลัก
- ฟังก์ชันคลาวด์จะคัดลอกการกำหนดค่าและแผนภูมิจากที่เก็บข้อมูลหลักไปยังที่เก็บ Git หลัก
- ตัวดำเนินการ GitOps อัปเดตคลัสเตอร์
2. รุ่นเจนกินส์ - รุ่นหรือสาขาโปรแกรมแก้ไขด่วน:
- Jenkins ผลักภาพที่ไม่ติดแท็กไปที่ Quay;
- Jenkins พุชแผนภูมิการกำหนดค่าและ Helm ไปยังที่เก็บข้อมูลชั่วคราว
- ฟังก์ชันคลาวด์จะคัดลอกการกำหนดค่าและแผนภูมิจากที่เก็บข้อมูลชั่วคราวไปยังพื้นที่เก็บข้อมูล Git แบบชั่วคราว
- ตัวดำเนินการ GitOps อัปเดตคลัสเตอร์
3. Jenkins สร้าง - พัฒนาหรือนำเสนอสาขา:
- Jenkins ผลักภาพที่ไม่ติดแท็กไปที่ Quay;
- Jenkins ผลักดันแผนภูมิการกำหนดค่าและ Helm ลงในที่เก็บข้อมูลการพัฒนา
- ฟังก์ชันคลาวด์จะคัดลอกการกำหนดค่าและแผนภูมิจากที่เก็บข้อมูลการพัฒนาไปยังพื้นที่เก็บข้อมูล Git ที่กำลังพัฒนา
- ตัวดำเนินการ GitOps อัปเดตคลัสเตอร์
4. การเพิ่มลูกค้าใหม่:
- ผู้จัดการหรือผู้ดูแลระบบ (LCM/ops) เรียก Gradle เพื่อปรับใช้และกำหนดค่า Network Load Balancer (NLB) ในขั้นต้น
- LCM/ops คอมมิตการกำหนดค่าใหม่เพื่อเตรียมการปรับใช้สำหรับการอัพเดต
- ตัวดำเนินการ GitOps อัปเดตคลัสเตอร์
คำอธิบายโดยย่อของ GitOps
- อธิบายสถานะที่ต้องการของทั้งระบบโดยใช้ข้อกำหนดเฉพาะสำหรับแต่ละสภาพแวดล้อม (ในเรื่องราวของเรา ทีมงานของ Bob ได้กำหนดการกำหนดค่าระบบทั้งหมดใน Git)
- พื้นที่เก็บข้อมูล Git เป็นแหล่งข้อมูลเดียวเกี่ยวกับสถานะที่ต้องการของทั้งระบบ
- การเปลี่ยนแปลงสถานะที่ต้องการทั้งหมดทำได้ผ่านการคอมมิตใน Git
- พารามิเตอร์คลัสเตอร์ที่ต้องการทั้งหมดสามารถสังเกตได้ในคลัสเตอร์ด้วยเช่นกัน ด้วยวิธีนี้เราสามารถระบุได้ว่าสิ่งเหล่านั้นเกิดขึ้นพร้อมกันหรือไม่ (มาบรรจบกัน ลู่) หรือแตกต่าง (แตกต่าง แตกต่าง) สภาวะที่ต้องการและสังเกตได้
- หากสถานะที่ต้องการและที่สังเกตได้แตกต่างกัน ดังนั้น:
- มีกลไกการบรรจบกันที่จะซิงโครไนซ์เป้าหมายและสถานะที่สังเกตได้โดยอัตโนมัติไม่ช้าก็เร็ว ภายในคลัสเตอร์ Kubernetes ทำสิ่งนี้
- กระบวนการเริ่มต้นทันทีด้วยการแจ้งเตือน "การเปลี่ยนแปลงที่กระทำ"
- หลังจากช่วงระยะเวลาที่กำหนดได้ จะสามารถส่งการแจ้งเตือน "แตกต่าง" ได้หากสถานะแตกต่างกัน
- ด้วยวิธีนี้ การคอมมิตทั้งหมดใน Git จะทำให้เกิดการอัปเดตที่ตรวจสอบได้และเป็นแบบ idempotent ไปยังคลัสเตอร์
- การย้อนกลับคือการบรรจบกันสู่สถานะที่ต้องการก่อนหน้านี้
- การบรรจบกันถือเป็นที่สิ้นสุด การเกิดขึ้นของมันถูกระบุโดย:
- ไม่มีการแจ้งเตือนความแตกต่างในช่วงระยะเวลาหนึ่ง
- การแจ้งเตือน "แบบหลอมรวม" (เช่น webhook, เหตุการณ์การเขียนกลับ Git)
ความแตกต่างคืออะไร?
มาทำซ้ำอีกครั้ง: คุณสมบัติคลัสเตอร์ที่ต้องการทั้งหมดจะต้องสังเกตได้ในตัวคลัสเตอร์เอง.
ตัวอย่างของความแตกต่าง:
- การเปลี่ยนแปลงในไฟล์การกำหนดค่าเนื่องจากการรวมสาขาใน Git
- การเปลี่ยนแปลงในไฟล์การกำหนดค่าเนื่องจากการคอมมิต Git ที่ทำโดยไคลเอนต์ GUI
- การเปลี่ยนแปลงหลายครั้งในสถานะที่ต้องการเนื่องจาก PR ใน Git ตามด้วยการสร้างอิมเมจคอนเทนเนอร์และการเปลี่ยนแปลงการกำหนดค่า
- การเปลี่ยนแปลงสถานะของคลัสเตอร์เนื่องจากข้อผิดพลาด ความขัดแย้งของทรัพยากรที่ส่งผลให้เกิด "พฤติกรรมที่ไม่ดี" หรือเพียงแค่เบี่ยงเบนแบบสุ่มจากสถานะดั้งเดิม
กลไกของการบรรจบกันคืออะไร?
ตัวอย่างบางส่วน:
- สำหรับคอนเทนเนอร์และคลัสเตอร์ Kubernetes จะจัดเตรียมกลไกการบรรจบกัน
- กลไกเดียวกันนี้สามารถใช้เพื่อจัดการแอปพลิเคชันและการออกแบบที่ใช้ Kubernetes (เช่น Istio และ Kubeflow)
- กลไกในการจัดการการโต้ตอบในการปฏิบัติงานระหว่าง Kubernetes ที่เก็บรูปภาพ และ Git มีให้ ซึ่งเป็นส่วนหนึ่ง .
- สำหรับเครื่องพื้นฐาน กลไกการลู่เข้าจะต้องเป็นแบบประกาศและเป็นอิสระ จากประสบการณ์ของเราเองเราสามารถพูดได้ว่า ใกล้เคียงกับคำจำกัดความนี้มากที่สุด แต่ยังต้องมีการควบคุมโดยมนุษย์ ในแง่นี้ GitOps ได้ขยายประเพณีของโครงสร้างพื้นฐานให้เป็นโค้ด
GitOps ผสมผสาน Git เข้ากับกลไกการบรรจบกันที่ยอดเยี่ยมของ Kubernetes เพื่อสร้างแบบจำลองสำหรับการใช้ประโยชน์
GitOps ช่วยให้เราพูดได้ว่า: เฉพาะระบบที่สามารถอธิบายและสังเกตได้เท่านั้นที่สามารถเป็นอัตโนมัติและควบคุมได้.
GitOps มีไว้สำหรับสแต็กเนทิฟบนคลาวด์ทั้งหมด (เช่น Terraform เป็นต้น)
GitOps ไม่ใช่แค่ Kubernetes เราต้องการให้ระบบทั้งหมดได้รับการขับเคลื่อนอย่างเปิดเผยและใช้การลู่เข้า โดยรวมทั้งระบบ เราหมายถึงชุดของสภาพแวดล้อมที่ทำงานร่วมกับ Kubernetes - ตัวอย่างเช่น “คลัสเตอร์ dev 1”, “การผลิต” ฯลฯ แต่ละสภาพแวดล้อมประกอบด้วยเครื่อง คลัสเตอร์ แอปพลิเคชัน รวมถึงอินเทอร์เฟซสำหรับบริการภายนอกที่ให้ข้อมูล การตรวจสอบ และอื่น ๆ
สังเกตว่า Terraform มีความสำคัญเพียงใดต่อปัญหาการบูตเครื่องในกรณีนี้ ต้องติดตั้ง Kubernetes ที่ไหนสักแห่ง และการใช้ Terraform หมายความว่าเราสามารถใช้เวิร์กโฟลว์ GitOps เดียวกันเพื่อสร้างเลเยอร์การควบคุมที่รองรับ Kubernetes และแอปพลิเคชันต่างๆ นี่เป็นแนวทางปฏิบัติที่ดีที่สุดที่มีประโยชน์
มีการมุ่งเน้นอย่างมากในการใช้แนวคิด GitOps กับเลเยอร์บน Kubernetes ในขณะนี้ มีโซลูชันประเภท GitOps สำหรับ Istio, Helm, Ksonnet, OpenFaaS และ Kubeflow รวมถึงตัวอย่างสำหรับ Pulumi ซึ่งสร้างเลเยอร์สำหรับการพัฒนาแอปพลิเคชันสำหรับคลาวด์เนทีฟ
Kubernetes CI/CD: การเปรียบเทียบ GitOps กับแนวทางอื่นๆ
ตามที่ระบุไว้ GitOps มีสองสิ่ง:
- รูปแบบการดำเนินงานสำหรับ Kubernetes และ Cloud Native ที่อธิบายไว้ข้างต้น
- เส้นทางสู่สภาพแวดล้อมการจัดการแอปพลิเคชันที่เน้นนักพัฒนาเป็นศูนย์กลาง
สำหรับหลายๆ คน GitOps นั้นเป็นเวิร์กโฟลว์ที่อิงจาก Git Pushes เป็นหลัก เราก็ชอบเขาเหมือนกัน แต่นั่นไม่ใช่ทั้งหมด ตอนนี้เรามาดูไปป์ไลน์ CI/CD กันดีกว่า
GitOps เปิดใช้งานการปรับใช้อย่างต่อเนื่อง (CD) สำหรับ Kubernetes
GitOps นำเสนอกลไกการปรับใช้งานอย่างต่อเนื่องซึ่งช่วยลดความจำเป็นในการแยก “ระบบการจัดการการปรับใช้งาน” Kubernetes ทำทุกอย่างเพื่อคุณ
- การอัปเดตแอปพลิเคชันจำเป็นต้องอัปเดตใน Git นี่คือการอัปเดตธุรกรรมไปยังสถานะที่ต้องการ จากนั้น "การปรับใช้" จะเสร็จสิ้นภายในคลัสเตอร์โดย Kubernetes เองตามคำอธิบายที่อัปเดต
- เนื่องจากลักษณะการทำงานของ Kubernetes การอัปเดตเหล่านี้จึงมาบรรจบกัน นี่เป็นกลไกสำหรับการปรับใช้อย่างต่อเนื่องซึ่งการอัปเดตทั้งหมดเป็นแบบอะตอมมิก
- หมายเหตุ: เสนอตัวดำเนินการ GitOps ที่รวม Git และ Kubernetes และอนุญาตให้ดำเนินการซีดีโดยปรับสถานะคลัสเตอร์ที่ต้องการและปัจจุบัน
ไม่มี kubectl และสคริปต์
คุณควรหลีกเลี่ยงการใช้ Kubectl เพื่ออัปเดตคลัสเตอร์ และโดยเฉพาะอย่างยิ่งหลีกเลี่ยงการใช้สคริปต์เพื่อจัดกลุ่มคำสั่ง kubectl แต่เมื่อใช้ไปป์ไลน์ GitOps ผู้ใช้สามารถอัปเดตคลัสเตอร์ Kubernetes ผ่าน Git ได้
ประโยชน์รวมถึง:
- ปราวิเลียน. กลุ่มการอัปเดตสามารถนำไปใช้ ผสานรวม และตรวจสอบได้ในที่สุด ทำให้เราเข้าใกล้เป้าหมายของการปรับใช้แบบอะตอมมิกมากขึ้น ในทางตรงกันข้าม การใช้สคริปต์ไม่ได้รับประกันการบรรจบกัน (เพิ่มเติมด้านล่างนี้)
- ความปลอดภัย. Kelsey Hightower: “จำกัดการเข้าถึงคลัสเตอร์ Kubernetes ของคุณเฉพาะเครื่องมืออัตโนมัติและผู้ดูแลระบบที่รับผิดชอบในการดีบักหรือบำรุงรักษาคลัสเตอร์” ดูสิ่งนี้ด้วย เกี่ยวกับความปลอดภัยและการปฏิบัติตามข้อกำหนดทางเทคนิคตลอดจน โดยการขโมยข้อมูลรับรองจากสคริปต์เจนกินส์ที่เขียนอย่างไม่ระมัดระวัง
- ประสบการณ์ผู้ใช้. Kubectl เปิดเผยกลไกของโมเดลออบเจ็กต์ Kubernetes ซึ่งค่อนข้างซับซ้อน ตามหลักการแล้ว ผู้ใช้ควรโต้ตอบกับระบบในระดับนามธรรมที่สูงกว่า ที่นี่ฉันจะอ้างถึง Kelsey อีกครั้งและแนะนำให้ดู .
ความแตกต่างระหว่าง CI และซีดี
GitOps ปรับปรุงโมเดล CI/CD ที่มีอยู่
เซิร์ฟเวอร์ CI สมัยใหม่เป็นเครื่องมือในการจัดประสาน โดยเฉพาะอย่างยิ่งเป็นเครื่องมือในการประสานไปป์ไลน์ CI ซึ่งรวมถึงการสร้าง ทดสอบ ผสานเข้ากับ Trunk ฯลฯ เซิร์ฟเวอร์ CI จะทำให้การจัดการไปป์ไลน์แบบหลายขั้นตอนที่ซับซ้อนเป็นแบบอัตโนมัติ สิ่งล่อใจทั่วไปคือการสคริปต์ชุดการอัปเดต Kubernetes และเรียกใช้โดยเป็นส่วนหนึ่งของไปป์ไลน์เพื่อส่งการเปลี่ยนแปลงไปยังคลัสเตอร์ จริงๆ แล้วนี่คือสิ่งที่ผู้เชี่ยวชาญหลายคนทำ อย่างไรก็ตาม นี่ยังไม่เหมาะสม และนี่คือเหตุผล
ควรใช้ CI เพื่อพุชการอัปเดตไปยัง Trunk และคลัสเตอร์ Kubernetes ควรเปลี่ยนตัวเองตามการอัปเดตเหล่านั้นเพื่อจัดการซีดีภายใน เราเรียกมันว่า ต่างจากรุ่น CI push ซีดีเป็นส่วนหนึ่ง การเรียบเรียงรันไทม์.
เหตุใดเซิร์ฟเวอร์ CI จึงไม่ควรทำซีดีผ่านการอัปเดตโดยตรงใน Kubernetes
อย่าใช้เซิร์ฟเวอร์ CI เพื่อประสานการอัปเดตโดยตรงไปยัง Kubernetes เป็นชุดของงาน CI นี่คือรูปแบบการต่อต้านที่เรากำลังพูดถึง บนบล็อกของคุณ
กลับไปที่อลิซและบ็อบกันเถอะ
พวกเขาประสบปัญหาอะไรบ้าง? เซิร์ฟเวอร์ CI ของ Bob จะใช้การเปลี่ยนแปลงกับคลัสเตอร์ แต่หากเกิดข้อขัดข้องในกระบวนการ Bob จะไม่ทราบว่าคลัสเตอร์อยู่ในสถานะใด (หรือควรเป็น) หรือจะแก้ไขได้อย่างไร เช่นเดียวกับในกรณีที่ประสบความสำเร็จ
สมมติว่าทีมของ Bob ได้สร้างอิมเมจใหม่ จากนั้นแพตช์การปรับใช้เพื่อปรับใช้อิมเมจ (ทั้งหมดจากไปป์ไลน์ CI)
หากอิมเมจสร้างขึ้นตามปกติ แต่ไปป์ไลน์ล้มเหลว ทีมงานจะต้องค้นหา:
- มีการอัปเดตออกมาแล้วหรือยัง?
- เรากำลังเปิดตัวโครงสร้างใหม่หรือไม่? สิ่งนี้จะนำไปสู่ผลข้างเคียงที่ไม่จำเป็นหรือไม่ - โดยมีความเป็นไปได้ที่จะมีภาพเดียวกันที่ไม่เปลี่ยนรูปสองภาพหรือไม่
- เราควรรอการอัปเดตครั้งถัดไปก่อนที่จะรันบิลด์หรือไม่
- เกิดอะไรขึ้นกันแน่? ขั้นตอนใดที่ต้องทำซ้ำ (และขั้นตอนใดปลอดภัยที่จะทำซ้ำ)
การสร้างเวิร์กโฟลว์ที่ใช้ Git ไม่ได้รับประกันว่าทีมของ Bob จะไม่พบปัญหาเหล่านี้ พวกเขายังสามารถทำผิดพลาดได้ด้วย Commit Push, แท็ก หรือพารามิเตอร์อื่นๆ อย่างไรก็ตาม แนวทางนี้ยังคงใกล้เคียงกับแนวทางแบบทั้งหมดหรือไม่มีเลยอย่างชัดเจนมาก
โดยสรุป นี่คือสาเหตุที่เซิร์ฟเวอร์ CI ไม่ควรจัดการกับซีดี:
- สคริปต์การอัพเดตไม่ได้ถูกกำหนดไว้เสมอไป มันง่ายที่จะทำผิดพลาดในตัวพวกเขา
- เซิร์ฟเวอร์ CI ไม่ได้มาบรรจบกันกับโมเดลคลัสเตอร์ที่ประกาศ
- เป็นการยากที่จะรับประกันความเป็นเอกภาพ ผู้ใช้จะต้องเข้าใจความหมายเชิงลึกของระบบ
- การกู้คืนจากความล้มเหลวบางส่วนทำได้ยากกว่า
หมายเหตุเกี่ยวกับ Helm: หากคุณต้องการใช้ Helm เราขอแนะนำให้รวมเข้ากับตัวดำเนินการ GitOps เช่น . สิ่งนี้จะช่วยให้แน่ใจว่าการบรรจบกัน ตัวหมวกเองนั้นไม่ได้ถูกกำหนดไว้หรือเป็นอะตอม
GitOps เป็นวิธีที่ดีที่สุดในการใช้การจัดส่งอย่างต่อเนื่องสำหรับ Kubernetes
ทีมของ Alice และ Bob ใช้ GitOps และค้นพบว่าการทำงานกับผลิตภัณฑ์ซอฟต์แวร์ รักษาประสิทธิภาพและความเสถียรในระดับสูงกลายเป็นเรื่องง่ายขึ้นมาก เรามาจบบทความนี้ด้วยภาพประกอบที่แสดงให้เห็นว่าแนวทางใหม่ของพวกเขาเป็นอย่างไร โปรดทราบว่าเรากำลังพูดถึงแอปพลิเคชันและบริการเป็นส่วนใหญ่ แต่ GitOps สามารถใช้ในการจัดการแพลตฟอร์มทั้งหมดได้
รูปแบบการทำงานของ Kubernetes
ดูแผนภาพต่อไปนี้ โดยนำเสนอ Git และที่เก็บอิมเมจคอนเทนเนอร์เป็นทรัพยากรที่ใช้ร่วมกันสำหรับวงจรชีวิตที่จัดเตรียมไว้สองวงจร:
- ไปป์ไลน์การรวมอย่างต่อเนื่องที่อ่านและเขียนไฟล์ไปยัง Git และสามารถอัปเดตที่เก็บของอิมเมจคอนเทนเนอร์ได้
- ไปป์ไลน์ GitOps รันไทม์ที่รวมการปรับใช้เข้ากับการจัดการและความสามารถในการสังเกต อ่านและเขียนไฟล์ไปยัง Git และสามารถดาวน์โหลดคอนเทนเนอร์อิมเมจได้
การค้นพบหลักคืออะไร?
- แยกความกังวล: โปรดทราบว่าไปป์ไลน์ทั้งสองสามารถสื่อสารได้โดยการอัปเดต Git หรือที่เก็บรูปภาพเท่านั้น กล่าวอีกนัยหนึ่ง มีไฟร์วอลล์ระหว่าง CI และสภาพแวดล้อมรันไทม์ เราเรียกมันว่า "ไฟร์วอลล์ที่ไม่เปลี่ยนรูป" (ไฟร์วอลล์ที่ไม่เปลี่ยนรูป)เนื่องจากการอัปเดตที่เก็บทั้งหมดจะสร้างเวอร์ชันใหม่ หากต้องการข้อมูลเพิ่มเติมเกี่ยวกับหัวข้อนี้ โปรดดูสไลด์ 72-87 .
- คุณสามารถใช้เซิร์ฟเวอร์ CI และ Git ใดก็ได้: GitOps ทำงานได้กับทุกส่วนประกอบ คุณสามารถใช้เซิร์ฟเวอร์ CI และ Git ที่เก็บรูปภาพ และชุดทดสอบที่คุณชื่นชอบต่อไปได้ เครื่องมือการจัดส่งต่อเนื่องอื่นๆ เกือบทั้งหมดในตลาดจำเป็นต้องมีเซิร์ฟเวอร์ CI/Git หรือที่เก็บรูปภาพของตัวเอง นี่อาจกลายเป็นปัจจัยจำกัดในการพัฒนาระบบคลาวด์เนทิฟ ด้วย GitOps คุณสามารถใช้เครื่องมือที่คุ้นเคยได้
- กิจกรรมในฐานะเครื่องมือบูรณาการ: ทันทีที่มีการอัปเดตข้อมูลใน Git Weave Flux (หรือตัวดำเนินการ Weave Cloud) จะแจ้งเตือนรันไทม์ เมื่อใดก็ตามที่ Kubernetes ยอมรับชุดการเปลี่ยนแปลง Git จะได้รับการอัปเดต นี่เป็นโมเดลการรวมอย่างง่ายสำหรับการจัดระเบียบเวิร์กโฟลว์สำหรับ GitOps ดังที่แสดงด้านล่าง
ข้อสรุป
GitOps ให้การรับประกันการอัปเดตที่แข็งแกร่งซึ่งจำเป็นสำหรับเครื่องมือ CI/CD สมัยใหม่:
- ระบบอัตโนมัติ;
- การบรรจบกัน;
- ความเป็นเอกภาพ;
- ระดับ
นี่เป็นสิ่งสำคัญเนื่องจากมีรูปแบบการดำเนินงานสำหรับนักพัฒนาระบบคลาวด์
- เครื่องมือแบบดั้งเดิมสำหรับการจัดการและติดตามระบบจะเชื่อมโยงกับทีมปฏิบัติการที่ดำเนินงานภายในสมุดบัญชี (ชุดขั้นตอนและการปฏิบัติงานประจำ - การแปลโดยประมาณ)เชื่อมโยงกับการใช้งานเฉพาะ
- ในการจัดการคลาวด์เนทิฟ เครื่องมือสังเกตการณ์เป็นวิธีที่ดีที่สุดในการวัดผลลัพธ์ของการปรับใช้ เพื่อให้ทีมพัฒนาสามารถตอบสนองได้อย่างรวดเร็ว
ลองนึกภาพคลัสเตอร์จำนวนมากที่กระจัดกระจายอยู่บนคลาวด์และบริการต่างๆ มากมายพร้อมกับทีมและแผนการปรับใช้ของตนเอง GitOps นำเสนอโมเดลที่ไม่แปรผันตามขนาดสำหรับการจัดการความอุดมสมบูรณ์ทั้งหมดนี้
ปล.จากผู้แปล
อ่านเพิ่มเติมในบล็อกของเรา:
- «";
- «";
- «'
เฉพาะผู้ใช้ที่ลงทะเบียนเท่านั้นที่สามารถเข้าร่วมในการสำรวจได้ , โปรด.
คุณรู้เกี่ยวกับ GitOps ก่อนที่คำแปลทั้งสองนี้จะปรากฏบนHabréหรือไม่?
-
ใช่ ฉันรู้ทุกอย่าง
-
เพียงผิวเผินเท่านั้น
-
ไม่
ผู้ใช้ 35 คนโหวต ผู้ใช้ 10 รายงดออกเสียง
ที่มา: will.com