GitOps: คำศัพท์อื่นหรือความก้าวหน้าในระบบอัตโนมัติ?

พวกเราส่วนใหญ่สังเกตเห็นคำศัพท์ใหม่ในบล็อกหรือการประชุมด้านไอที ไม่ช้าก็เร็วก็ถามคำถามที่คล้ายกัน: "นี่คืออะไร? แค่คำศัพท์อื่น “คำศัพท์” หรือบางสิ่งที่ควรค่าแก่การเอาใจใส่ ศึกษา และให้คำมั่นสัญญากับขอบเขตใหม่ๆ อย่างแท้จริง” สิ่งเดียวกันนี้เกิดขึ้นกับฉันด้วยคำว่า GitOps เมื่อไม่นานมานี้ อัดแน่นไปด้วยบทความที่มีอยู่มากมายตลอดจนความรู้จากเพื่อนร่วมงานจากบริษัท GitLabฉันพยายามคิดว่านี่คือสัตว์ร้ายชนิดใด และการใช้งานจริงอาจมีลักษณะอย่างไร

โดยวิธีการเกี่ยวกับความแปลกใหม่ของคำศัพท์ GitOps แบบสำรวจล่าสุดของเรายังระบุด้วยว่า มากกว่าครึ่งหนึ่งของผู้ตอบแบบสำรวจยังไม่ได้เริ่มทำงานตามหลักการของตน

ดังนั้นปัญหาการจัดการโครงสร้างพื้นฐานจึงไม่ใช่เรื่องใหม่ ผู้ให้บริการระบบคลาวด์หลายรายเปิดให้บริการแก่สาธารณชนทั่วไปมาเป็นเวลาหลายสิบปีแล้ว และดูเหมือนว่าจะทำให้งานของทีมที่รับผิดชอบด้านโครงสร้างพื้นฐานเรียบง่ายและตรงไปตรงมา อย่างไรก็ตาม เมื่อเปรียบเทียบกับกระบวนการพัฒนาแอปพลิเคชัน (ที่ระบบอัตโนมัติกำลังก้าวไปสู่ระดับใหม่) โครงการโครงสร้างพื้นฐานมักจะเกี่ยวข้องกับงานที่ต้องทำด้วยตนเองจำนวนมาก และต้องการความรู้และความเชี่ยวชาญเฉพาะทาง โดยเฉพาะอย่างยิ่งเมื่อพิจารณาจากข้อกำหนดในปัจจุบันในด้านความทนทานต่อข้อผิดพลาด ความยืดหยุ่น ความสามารถในการขยายขนาด และความยืดหยุ่น

บริการคลาวด์ตอบสนองความต้องการเหล่านี้ได้สำเร็จอย่างมากและเป็นแรงผลักดันสำคัญในการพัฒนาแนวทางดังกล่าว ไอเอซี. นี่เป็นสิ่งที่เข้าใจได้ ท้ายที่สุดแล้ว พวกเขาทำให้สามารถกำหนดค่าศูนย์ข้อมูลเสมือนได้อย่างสมบูรณ์: ไม่มีเซิร์ฟเวอร์จริง แร็ค หรือส่วนประกอบเครือข่าย สามารถอธิบายโครงสร้างพื้นฐานทั้งหมดได้โดยใช้สคริปต์และไฟล์การกำหนดค่า

แล้วความแตกต่างคืออะไร? GitOps จาก ไอเอซี? ด้วยคำถามนี้เองที่ทำให้ฉันเริ่มการสอบสวน หลังจากพูดคุยกับเพื่อนร่วมงาน ฉันก็สามารถเปรียบเทียบได้ดังต่อไปนี้:

GitOps

ไอเอซี

รหัสทั้งหมดถูกเก็บไว้ในที่เก็บ git

การกำหนดเวอร์ชันโค้ดเป็นทางเลือก

คำอธิบายรหัสที่ประกาศ / Idempotency

ยอมรับทั้งคำอธิบายที่เปิดเผยและความจำเป็น

การเปลี่ยนแปลงมีผลโดยใช้กลไก Merge Request / Pull Request

ข้อตกลง การอนุมัติ และความร่วมมือเป็นทางเลือก

กระบวนการเปิดตัวการอัปเดตจะเป็นไปโดยอัตโนมัติ

กระบวนการเปิดตัวการอัปเดตไม่ได้มาตรฐาน (อัตโนมัติ ด้วยตนเอง การคัดลอกไฟล์ การใช้บรรทัดคำสั่ง ฯลฯ)

กล่าวอีกนัยหนึ่ง GitOps ถือกำเนิดขึ้นโดยอาศัยหลักการเป็นหลัก ไอเอซี. ประการแรก ขณะนี้โครงสร้างพื้นฐานและการกำหนดค่าสามารถจัดเก็บได้ในลักษณะเดียวกับแอปพลิเคชัน โค้ดนี้จัดเก็บง่าย แบ่งปัน เปรียบเทียบ และใช้ความสามารถในการกำหนดเวอร์ชันได้ง่าย เวอร์ชัน สาขา ประวัติ และทั้งหมดนี้อยู่ในสถานที่ที่ทุกคนในทีมเข้าถึงได้แบบสาธารณะ ดังนั้นการใช้ระบบควบคุมเวอร์ชันจึงกลายเป็นการพัฒนาตามธรรมชาติโดยสมบูรณ์ โดยเฉพาะคอมไพล์ที่ได้รับความนิยมมากที่สุด

ในทางกลับกัน ทำให้กระบวนการจัดการโครงสร้างพื้นฐานเป็นอัตโนมัติได้ ตอนนี้สามารถทำได้เร็วขึ้น เชื่อถือได้มากขึ้น และราคาถูกลง นอกจากนี้หลักการของ CI / CD ยังเป็นที่รู้จักและได้รับความนิยมในหมู่นักพัฒนาซอฟต์แวร์อยู่แล้ว จำเป็นเท่านั้นที่จะถ่ายโอนและประยุกต์ใช้ความรู้และทักษะที่รู้อยู่แล้วกับพื้นที่ใหม่ อย่างไรก็ตาม แนวทางปฏิบัติเหล่านี้ไปไกลกว่าคำจำกัดความมาตรฐานของโครงสร้างพื้นฐานในฐานะโค้ด ดังนั้นแนวคิดนี้ GitOps.

ความอยากรู้ GitOpsแน่นอนว่าไม่ใช่ผลิตภัณฑ์ ปลั๊กอิน หรือแพลตฟอร์มที่เกี่ยวข้องกับผู้ขายรายใด มันเป็นกระบวนทัศน์และชุดหลักการมากกว่า คล้ายกับคำอื่นที่เราคุ้นเคย: DevOps

บริษัท GitLab เราได้พัฒนาคำจำกัดความสองคำของคำศัพท์ใหม่นี้: เชิงทฤษฎีและปฏิบัติ เริ่มจากทฤษฎีกันก่อน:

GitOps เป็นวิธีการที่ใช้หลักการ DevOps ที่ดีที่สุดที่ใช้สำหรับการพัฒนาแอปพลิเคชัน เช่น การควบคุมเวอร์ชัน การทำงานร่วมกัน การจัดระบบ CI/CD และนำไปใช้กับความท้าทายในการจัดการโครงสร้างพื้นฐานแบบอัตโนมัติ

กระบวนการทั้งหมด GitOps ฉันทำงานโดยใช้เครื่องมือที่มีอยู่ รหัสโครงสร้างพื้นฐานทั้งหมดถูกจัดเก็บไว้ในที่เก็บ git ที่คุ้นเคยอยู่แล้ว การเปลี่ยนแปลงจะต้องผ่านกระบวนการอนุมัติเช่นเดียวกับรหัสโปรแกรมอื่น ๆ และกระบวนการเปิดตัวเป็นแบบอัตโนมัติ ซึ่งช่วยให้เราลดข้อผิดพลาดของมนุษย์ เพิ่มความน่าเชื่อถือและความสามารถในการทำซ้ำได้

จากมุมมองเชิงปฏิบัติเราจะอธิบาย GitOps ดังต่อไปนี้:

เราได้กล่าวถึงโครงสร้างพื้นฐานในฐานะโค้ดซึ่งเป็นหนึ่งในองค์ประกอบสำคัญของสูตรนี้แล้ว มาแนะนำผู้เข้าร่วมที่เหลือกันดีกว่า

คำขอรวม (ชื่ออื่น Pull Request) ในแง่กระบวนการ MR คือการร้องขอเพื่อใช้การเปลี่ยนแปลงรหัสแล้วรวมสาขา แต่ในแง่ของเครื่องมือที่เราใช้ นี่เป็นโอกาสมากกว่าที่จะได้ภาพที่สมบูรณ์ของการเปลี่ยนแปลงทั้งหมดที่เกิดขึ้น ไม่เพียงแต่โค้ดที่รวบรวมมาจากจำนวนคอมมิตที่กำหนดเท่านั้น แต่ยังรวมถึงบริบท ผลการทดสอบ และ ผลลัพธ์ที่คาดหวังขั้นสุดท้าย หากเรากำลังพูดถึงโค้ดโครงสร้างพื้นฐาน เราก็สนใจว่าโครงสร้างพื้นฐานจะเปลี่ยนแปลงไปอย่างไร มีการเพิ่มหรือลบหรือเปลี่ยนแปลงทรัพยากรใหม่จำนวนเท่าใด ควรอยู่ในรูปแบบที่สะดวกและอ่านง่ายกว่า สำหรับผู้ให้บริการระบบคลาวด์ เป็นความคิดที่ดีที่จะรู้ว่าผลกระทบทางการเงินจากการเปลี่ยนแปลงนี้จะเป็นอย่างไร

แต่ MR ยังเป็นวิธีการทำงานร่วมกัน การโต้ตอบ และการสื่อสารอีกด้วย สถานที่ที่ระบบการตรวจสอบและถ่วงดุลเข้ามามีบทบาท ตั้งแต่ความคิดเห็นง่ายๆ ไปจนถึงการอนุมัติและการอนุมัติอย่างเป็นทางการ

องค์ประกอบสุดท้าย: ดังที่เราทราบกันดีอยู่แล้วว่า CI/CD ทำให้กระบวนการเปลี่ยนแปลงโครงสร้างพื้นฐานและการทดสอบเป็นไปโดยอัตโนมัติ (ตั้งแต่การตรวจสอบไวยากรณ์อย่างง่ายไปจนถึงการวิเคราะห์โค้ดสแตติกที่ซับซ้อนมากขึ้น) และในการตรวจจับการเบี่ยงเบนที่ตามมา: ความแตกต่างระหว่างสถานะจริงและสถานะที่ต้องการของระบบ ตัวอย่างเช่น อันเป็นผลมาจากการเปลี่ยนแปลงด้วยตนเองโดยไม่ได้รับอนุญาตหรือความล้มเหลวของระบบ

ใช่แล้ว คำว่า GitOps ไม่ได้แนะนำเราให้รู้จักกับสิ่งใหม่ทั้งหมด ไม่คิดค้นล้อใหม่ แต่เพียงใช้ประสบการณ์ที่สั่งสมมาในพื้นที่ใหม่ แต่นี่คือจุดที่ความแข็งแกร่งของเขาอยู่

และหากคุณสนใจว่าทั้งหมดนี้ดูเป็นอย่างไรในทางปฏิบัติ ฉันขอเชิญคุณมาดูของเรา ระดับปริญญาโทซึ่งฉันจะบอกคุณทีละขั้นตอนถึงวิธีใช้ GitLab:

• ใช้หลักการพื้นฐานของ GitOps

• สร้างและทำการเปลี่ยนแปลงโครงสร้างพื้นฐานคลาวด์ (โดยใช้ตัวอย่างของ Yandex Cloud)

• ตรวจจับการเบี่ยงเบนของระบบจากสถานะที่ต้องการโดยอัตโนมัติโดยใช้การตรวจสอบแบบแอคทีฟ

https://bit.ly/34tRpwZ

ที่มา: will.com