บันทึก. แปล: ในชุมชน Kubernetes เทรนด์ที่เรียกว่า GitOps กำลังได้รับความนิยมอย่างเห็นได้ชัด ดังที่เราได้เห็นเป็นการส่วนตัว KubeCon Europe 2019 คำนี้ค่อนข้างใหม่ โดยหัวหน้าของ Weaveworks - Alexis Richardson - และหมายถึงการใช้เครื่องมือที่นักพัฒนาคุ้นเคย (โดยหลักคือ Git จึงเป็นชื่อ) เพื่อแก้ไขปัญหาการปฏิบัติงาน โดยเฉพาะอย่างยิ่ง เรากำลังพูดถึงการทำงานของ Kubernetes โดยจัดเก็บการกำหนดค่าไว้ใน Git และเผยแพร่การเปลี่ยนแปลงไปยังคลัสเตอร์โดยอัตโนมัติ Matthias Jg พูดถึงสองแนวทางในการเปิดตัวนี้ในบทความนี้
ปีล่าสุด, (อันที่จริงเหตุการณ์นี้เกิดขึ้นอย่างเป็นทางการในเดือนสิงหาคม 2017 - โดยประมาณ) มีแนวทางใหม่ในการปรับใช้แอปพลิเคชันใน Kubernetes เรียกว่า GitOps และมีพื้นฐานมาจากแนวคิดพื้นฐานที่ว่าเวอร์ชันการปรับใช้ได้รับการติดตามในสภาพแวดล้อมที่ปลอดภัยของที่เก็บ Git
ข้อดีหลักของแนวทางนี้มีดังนี้::
- การกำหนดเวอร์ชันและประวัติการเปลี่ยนแปลง. สถานะของคลัสเตอร์ทั้งหมดจะถูกจัดเก็บไว้ในที่เก็บ Git และการปรับใช้จะได้รับการอัปเดตผ่านการคอมมิตเท่านั้น นอกจากนี้ การเปลี่ยนแปลงทั้งหมดสามารถติดตามได้โดยใช้ประวัติการคอมมิต
- ย้อนกลับโดยใช้คำสั่ง Git ที่คุ้นเคย... ที่ราบ
git resetอนุญาตให้คุณรีเซ็ตการเปลี่ยนแปลงในการปรับใช้ รัฐที่ผ่านมามีอยู่เสมอ - พร้อมควบคุมการเข้าถึง. โดยทั่วไปแล้ว ระบบ Git จะมีข้อมูลที่ละเอียดอ่อนจำนวนมาก ดังนั้นบริษัทส่วนใหญ่จึงให้ความสำคัญกับการปกป้องเป็นพิเศษ ดังนั้น การป้องกันนี้ยังใช้กับการดำเนินการที่มีการปรับใช้ด้วย
- นโยบายสำหรับการปรับใช้. ระบบ Git ส่วนใหญ่สนับสนุนนโยบายแบบแยกสาขา ตัวอย่างเช่น เฉพาะคำขอดึงเท่านั้นที่สามารถอัปเดตหลักได้ และการเปลี่ยนแปลงจะต้องได้รับการตรวจสอบและยอมรับโดยสมาชิกในทีมคนอื่น เช่นเดียวกับการควบคุมการเข้าถึง นโยบายเดียวกันนี้ใช้กับการอัปเดตการปรับใช้
อย่างที่คุณเห็นแล้วว่าวิธี GitOps มีประโยชน์มากมาย ในปีที่ผ่านมา มี XNUMX แนวทางที่ได้รับความนิยมเป็นพิเศษ อันหนึ่งเป็นแบบพุช ส่วนอีกอันเป็นแบบดึง ก่อนที่เราจะดูสิ่งเหล่านั้น เรามาดูก่อนว่าการใช้งาน Kubernetes โดยทั่วไปจะเป็นอย่างไร
วิธีการปรับใช้
ในช่วงไม่กี่ปีที่ผ่านมา มีการจัดตั้งวิธีการและเครื่องมือต่างๆ สำหรับการปรับใช้ใน Kubernetes:
- อิงตามเทมเพลต Kubernetes/Kustomize ดั้งเดิม. นี่เป็นวิธีที่ง่ายที่สุดในการปรับใช้แอปพลิเคชันบน Kubernetes นักพัฒนาสร้างไฟล์ YAML พื้นฐานและนำไปใช้ เพื่อกำจัดการเขียนเทมเพลตเดิมซ้ำอย่างต่อเนื่อง Kustomize ได้รับการพัฒนา (เปลี่ยนเทมเพลต Kubernetes ให้เป็นโมดูล) บันทึก. แปล: Kustomize ได้รับการรวมเข้ากับ kubectl ด้วย .
- แผนภูมิหางเสือ. แผนภูมิ Helm ช่วยให้คุณสร้างชุดเทมเพลต คอนเทนเนอร์เริ่มต้น ไซด์คาร์ ฯลฯ ซึ่งใช้ในการปรับใช้แอปพลิเคชันที่มีตัวเลือกการปรับแต่งที่ยืดหยุ่นมากกว่าการใช้เทมเพลต วิธีการนี้อิงตามไฟล์ YAML ที่สร้างเทมเพลต Helm เติมพารามิเตอร์ต่างๆ แล้วส่งไปยัง Tiller ซึ่งเป็นส่วนประกอบของคลัสเตอร์ที่ปรับใช้กับคลัสเตอร์ และอนุญาตให้อัปเดตและย้อนกลับได้ สิ่งสำคัญคือ Helm เพียงแทรกค่าที่ต้องการลงในเทมเพลตแล้วนำไปใช้ในลักษณะเดียวกับที่ทำในแนวทางดั้งเดิม (อ่านเพิ่มเติมเกี่ยวกับวิธีการทำงานทั้งหมดและวิธีใช้งานในของเรา - ประมาณ แปล.). มีแผนภูมิ Helm สำเร็จรูปที่หลากหลายซึ่งครอบคลุมงานที่หลากหลาย
- เครื่องมือทางเลือก. มีเครื่องมือทางเลือกมากมาย สิ่งที่เหมือนกันทั้งหมดคือเปลี่ยนไฟล์เทมเพลตบางไฟล์ให้เป็นไฟล์ YAML ที่ Kubernetes อ่านได้ แล้วจึงใช้งาน
ในงานของเรา เราใช้แผนภูมิ Helm สำหรับเครื่องมือที่สำคัญอย่างต่อเนื่อง (เนื่องจากมีหลายอย่างพร้อมอยู่แล้ว ซึ่งทำให้ชีวิตง่ายขึ้นมาก) และไฟล์ Kubernetes YAML “บริสุทธิ์” สำหรับการปรับใช้แอปพลิเคชันของเราเอง
ดึงผลัก
ในบล็อกโพสต์ล่าสุดของฉัน ฉันได้แนะนำเครื่องมือนี้ ซึ่งช่วยให้คุณสามารถคอมมิตเทมเพลตไปยังที่เก็บ Git และอัปเดตการปรับใช้หลังจากคอมมิตหรือพุชคอนเทนเนอร์แต่ละครั้ง ประสบการณ์ของฉันแสดงให้เห็นว่าเครื่องมือนี้เป็นหนึ่งในเครื่องมือหลักในการส่งเสริมแนวทางดึง ดังนั้นฉันมักจะพูดถึงมัน หากคุณต้องการทราบข้อมูลเพิ่มเติมเกี่ยวกับวิธีการใช้งาน ที่นี่ .
NB! ประโยชน์ทั้งหมดของการใช้ GitOps ยังคงเหมือนเดิมสำหรับทั้งสองวิธี
วิธีการดึงตาม
วิธีการดึงขึ้นอยู่กับข้อเท็จจริงที่ว่าการเปลี่ยนแปลงทั้งหมดถูกนำไปใช้จากภายในคลัสเตอร์ มีผู้ปฏิบัติงานภายในคลัสเตอร์ที่ตรวจสอบที่เก็บ Git และ Docker Registry ที่เกี่ยวข้องเป็นประจำ หากมีการเปลี่ยนแปลงใดๆ เกิดขึ้น สถานะของคลัสเตอร์จะได้รับการอัปเดตภายใน โดยทั่วไปกระบวนการนี้ถือว่ามีความปลอดภัยสูง เนื่องจากไม่มีไคลเอ็นต์ภายนอกที่สามารถเข้าถึงสิทธิ์ของผู้ดูแลระบบคลัสเตอร์ได้
จุดเด่น:
- ไม่มีไคลเอ็นต์ภายนอกมีสิทธิ์ทำการเปลี่ยนแปลงคลัสเตอร์ การอัปเดตทั้งหมดจะเปิดตัวจากภายใน
- เครื่องมือบางอย่างยังช่วยให้คุณสามารถซิงโครไนซ์การอัปเดตแผนภูมิ Helm และเชื่อมโยงกับคลัสเตอร์ได้
- Docker Registry สามารถสแกนหาเวอร์ชันใหม่ได้ หากมีอิมเมจใหม่ พื้นที่เก็บข้อมูล Git และการปรับใช้จะได้รับการอัปเดตเป็นเวอร์ชันใหม่
- เครื่องมือดึงสามารถกระจายไปยังเนมสเปซต่างๆ ด้วยที่เก็บ Git และสิทธิ์ที่แตกต่างกัน ด้วยเหตุนี้ จึงสามารถใช้แบบจำลองหลายผู้เช่าได้ ตัวอย่างเช่น ทีม A อาจใช้เนมสเปซ A ทีม B อาจใช้เนมสเปซ B และทีมโครงสร้างพื้นฐานอาจใช้โกลบอลสเปซ
- ตามกฎแล้วเครื่องมือมีน้ำหนักเบามาก
- รวมกับเครื่องมือต่างๆ เช่น ผู้ปฏิบัติงาน ข้อมูลลับสามารถจัดเก็บแบบเข้ารหัสในพื้นที่เก็บข้อมูล Git และดึงข้อมูลภายในคลัสเตอร์
- ไม่มีการเชื่อมต่อกับไปป์ไลน์ซีดีเนื่องจากการปรับใช้เกิดขึ้นภายในคลัสเตอร์
cons:
- การจัดการข้อมูลลับในการปรับใช้จากแผนภูมิ Helm นั้นยากกว่าข้อมูลปกติ เนื่องจากต้องสร้างข้อมูลเหล่านี้ก่อนในรูปแบบของความลับที่ปิดผนึก จากนั้นจึงถอดรหัสโดยผู้ปฏิบัติงานภายใน และหลังจากนั้นเท่านั้นจึงจะพร้อมใช้งานในเครื่องมือดึง จากนั้นคุณสามารถรันรีลีสใน Helm ด้วยค่าในความลับที่ปรับใช้แล้ว วิธีที่ง่ายที่สุดคือการสร้างความลับด้วยค่า Helm ทั้งหมดที่ใช้สำหรับการปรับใช้ ถอดรหัส และส่งมอบให้กับ Git
- เมื่อคุณใช้วิธีดึง คุณจะผูกติดอยู่กับการดึงเครื่องมือ สิ่งนี้จำกัดความสามารถในการปรับแต่งกระบวนการปรับใช้ในคลัสเตอร์ ตัวอย่างเช่น Kustomize มีความซับซ้อนเนื่องจากต้องทำงานก่อนที่เทมเพลตสุดท้ายจะถูกส่งไปยัง Git ฉันไม่ได้บอกว่าคุณไม่สามารถใช้เครื่องมือแบบสแตนด์อโลนได้ แต่เครื่องมือเหล่านั้นจะยากกว่าในการรวมเข้ากับกระบวนการปรับใช้ของคุณ
วิธีการผลักดันตาม
ในแนวทางพุช ระบบภายนอก (ส่วนใหญ่เป็นไปป์ไลน์ซีดี) จะเรียกใช้การปรับใช้ไปยังคลัสเตอร์หลังจากคอมมิตไปยังพื้นที่เก็บข้อมูล Git หรือหากไปป์ไลน์ CI ก่อนหน้าสำเร็จ ในแนวทางนี้ ระบบจะสามารถเข้าถึงคลัสเตอร์ได้
ข้อดี:
- ความปลอดภัยถูกกำหนดโดยพื้นที่เก็บข้อมูล Git และไปป์ไลน์บิวด์
- การปรับใช้แผนภูมิ Helm นั้นง่ายกว่าและรองรับปลั๊กอิน Helm
- ข้อมูลลับนั้นจัดการได้ง่ายกว่าเนื่องจากข้อมูลลับสามารถใช้ในไปป์ไลน์และยังสามารถจัดเก็บแบบเข้ารหัสใน Git ได้ (ขึ้นอยู่กับการตั้งค่าของผู้ใช้)
- ไม่มีการเชื่อมต่อกับเครื่องมือเฉพาะใดๆ เนื่องจากสามารถใช้ได้ทุกประเภท
- การอัปเดตเวอร์ชันคอนเทนเนอร์สามารถเริ่มต้นได้โดยไปป์ไลน์บิวด์
cons:
- ข้อมูลการเข้าถึงคลัสเตอร์อยู่ภายในระบบบิลด์
- การอัปเดตคอนเทนเนอร์การปรับใช้ยังง่ายกว่าด้วยกระบวนการดึง
- การพึ่งพาระบบ CD อย่างมาก เนื่องจากไปป์ไลน์ที่เราต้องการอาจถูกเขียนขึ้นสำหรับ Gitlab Runners จากนั้นทีมงานจึงตัดสินใจย้ายไปที่ Azure DevOps หรือ Jenkins... และจะต้องย้ายไปป์ไลน์บิวด์จำนวนมาก
ผลลัพธ์: ดันหรือดึง?
ตามปกติแล้ว แต่ละวิธีก็มีข้อดีและข้อเสียต่างกันไป งานบางอย่างทำง่ายกว่ากับงานหนึ่งและยากกว่ากับอีกงานหนึ่ง ตอนแรกฉันกำลังปรับใช้ด้วยตนเอง แต่หลังจากที่ฉันพบบทความสองสามบทความเกี่ยวกับ Weave Flux ฉันจึงตัดสินใจใช้กระบวนการ GitOps สำหรับทุกโครงการ สำหรับเทมเพลตพื้นฐาน นี่เป็นเรื่องง่าย แต่แล้วฉันก็เริ่มประสบปัญหากับแผนภูมิ Helm ในเวลานั้น Weave Flux นำเสนอ Helm Chart Operator เวอร์ชันพื้นฐานเท่านั้น แต่ถึงแม้ตอนนี้งานบางอย่างจะยากขึ้นเนื่องจากจำเป็นต้องสร้างความลับด้วยตนเองและนำไปใช้ คุณอาจโต้แย้งว่าวิธีการดึงมีความปลอดภัยมากกว่ามาก เนื่องจากข้อมูลประจำตัวของคลัสเตอร์ไม่สามารถเข้าถึงได้ภายนอกคลัสเตอร์ ทำให้มีความปลอดภัยมากขึ้นจนคุ้มค่ากับความพยายามพิเศษ
หลังจากคิดอยู่พักหนึ่ง ฉันก็มาถึงข้อสรุปที่ไม่คาดคิดว่าไม่เป็นเช่นนั้น หากเราพูดถึงส่วนประกอบที่ต้องการการป้องกันสูงสุด รายการนี้รวมถึงพื้นที่จัดเก็บข้อมูลลับ ระบบ CI/CD และที่เก็บ Git ข้อมูลภายในนั้นมีความเสี่ยงมากและต้องการการปกป้องสูงสุด นอกจากนี้ หากมีคนเข้าไปในพื้นที่เก็บข้อมูล Git ของคุณและสามารถพุชโค้ดไปที่นั่น พวกเขาสามารถปรับใช้สิ่งที่พวกเขาต้องการ (ไม่ว่าจะเป็นการดึงหรือการพุช) และแทรกซึมเข้าไปในระบบของคลัสเตอร์ ดังนั้น ส่วนประกอบที่สำคัญที่สุดที่ต้องได้รับการปกป้องคือพื้นที่เก็บข้อมูล Git และระบบ CI/CD ไม่ใช่ข้อมูลรับรองคลัสเตอร์ หากคุณมีนโยบายและการควบคุมความปลอดภัยที่กำหนดค่าไว้อย่างดีสำหรับระบบประเภทนี้ และข้อมูลประจำตัวของคลัสเตอร์จะถูกแยกลงในไปป์ไลน์เป็นความลับเท่านั้น การรักษาความปลอดภัยเพิ่มเติมของวิธีการดึงอาจไม่มีคุณค่าเท่าที่คิดไว้ในตอนแรก
ดังนั้น หากวิธีการดึงใช้แรงงานเข้มข้นกว่า และไม่ได้ให้ผลประโยชน์ด้านความปลอดภัย สมเหตุสมผลไหมที่จะใช้เฉพาะวิธีการพุชเท่านั้น แต่อาจมีบางคนแย้งว่าในแนวทางแบบพุชคุณเชื่อมโยงกับระบบซีดีมากเกินไปและบางทีอาจเป็นการดีกว่าที่จะไม่ทำเช่นนี้เพื่อที่จะดำเนินการย้ายข้อมูลได้ง่ายขึ้นในอนาคต
ในความคิดของฉัน (เช่นเคย) คุณควรใช้สิ่งที่เหมาะสมที่สุดสำหรับกรณีเฉพาะหรือการรวม โดยส่วนตัวแล้ว ฉันใช้ทั้งสองวิธี: Weave Flux สำหรับการปรับใช้แบบดึงซึ่งส่วนใหญ่รวมบริการของเราเอง และวิธีการพุชด้วย Helm และปลั๊กอิน ซึ่งทำให้ง่ายต่อการใช้แผนภูมิ Helm กับคลัสเตอร์ และช่วยให้คุณสร้างความลับได้อย่างราบรื่น ฉันคิดว่าคงไม่มีวิธีแก้ปัญหาเดียวที่เหมาะสำหรับทุกกรณี เนื่องจากมีความแตกต่างมากมายอยู่เสมอและขึ้นอยู่กับแอปพลิเคชันเฉพาะ อย่างที่บอกไป ฉันขอแนะนำ GitOps เป็นอย่างยิ่ง - มันทำให้ชีวิตง่ายขึ้นมากและปรับปรุงความปลอดภัย
ฉันหวังว่าประสบการณ์ของฉันในหัวข้อนี้จะช่วยให้คุณตัดสินใจได้ว่าวิธีใดที่เหมาะกับประเภทการปรับใช้งานของคุณมากกว่า และฉันยินดีที่จะรับฟังความคิดเห็นของคุณ
ป.ล. หมายเหตุจากนักแปล
ข้อเสียของโมเดล pull คือ เป็นการยากที่จะใส่ manifest ที่แสดงผลลงใน Git แต่ไม่มีข้อเสียที่ไปป์ไลน์ CD ในโมเดล pull แยกจากการเปิดตัว และโดยพื้นฐานแล้วจะกลายเป็นไปป์ไลน์หมวดหมู่ สมัครอย่างต่อเนื่อง. ดังนั้น จะต้องใช้ความพยายามมากขึ้นในการรวบรวมสถานะจากการปรับใช้ทั้งหมด และจัดให้มีการเข้าถึงบันทึก/สถานะ โดยเฉพาะอย่างยิ่งโดยอ้างอิงกับระบบซีดี
ในแง่นี้ โมเดลพุชช่วยให้เราสามารถรับประกันการเปิดตัวได้เป็นอย่างน้อย เนื่องจากอายุการใช้งานของไปป์ไลน์สามารถเท่ากับอายุการใช้งานของการเปิดตัวได้
เราลองทั้งสองรุ่นและได้ข้อสรุปเช่นเดียวกับผู้เขียนบทความ:
- Pull Model เหมาะสำหรับเราในการจัดระเบียบการอัปเดตส่วนประกอบของระบบบนคลัสเตอร์จำนวนมาก (ดู ).
- โมเดลพุชที่ใช้ GitLab CI เหมาะอย่างยิ่งสำหรับการเปิดตัวแอปพลิเคชันโดยใช้แผนภูมิ Helm ในขณะเดียวกัน การเปิดตัวการปรับใช้ภายในไปป์ไลน์จะได้รับการตรวจสอบโดยใช้เครื่องมือ . อย่างไรก็ตาม ในบริบทของโครงการนี้ของเรา เราได้ยิน “GitOps” อยู่ตลอดเวลาเมื่อเราพูดคุยถึงปัญหาเร่งด่วนของวิศวกร DevOps ที่จุดยืนของเราที่ KubeCon Europe'19
PPS จากผู้แปล
อ่านเพิ่มเติมในบล็อกของเรา:
- «";
- «";
- «";
- «'
เฉพาะผู้ใช้ที่ลงทะเบียนเท่านั้นที่สามารถเข้าร่วมในการสำรวจได้ , โปรด.
คุณใช้ GitOps หรือไม่?
-
ใช่ ดึงแนวทาง
-
ใช่แล้ว ดัน
-
ใช่ครับ ดึง+ดัน
-
ใช่อย่างอื่น
-
ไม่
ผู้ใช้ 30 คนโหวต ผู้ใช้ 10 รายงดออกเสียง
ที่มา: will.com