มีการพูดถึงหัวข้อของที่เก็บโมโนมากกว่าหนึ่งครั้งและตามกฎแล้วทำให้เกิดความขัดแย้งอย่างมาก โดยการสร้าง ในฐานะเครื่องมือโอเพ่นซอร์สที่ออกแบบมาเพื่อปรับปรุงกระบวนการสร้างโค้ดแอปพลิเคชันจากอิมเมจ Git ไปยัง Docker (แล้วส่งไปยัง Kubernetes) เราไม่คิดมากเกี่ยวกับตัวเลือกที่ดีที่สุด สำหรับเรา สิ่งสำคัญอันดับแรกคือต้องจัดหาทุกสิ่งที่จำเป็นสำหรับผู้สนับสนุนที่มีความคิดเห็นต่างกัน (แน่นอนว่าหากสิ่งนี้ไม่ขัดแย้งกับสามัญสำนึก)
การสนับสนุน mono-repo ล่าสุดของ werf เป็นตัวอย่างที่ดีของสิ่งนี้ แต่ก่อนอื่น มาดูกันว่าการสนับสนุนนี้โดยทั่วไปเกี่ยวข้องกับการใช้ werf อย่างไร และ Docker Registry เกี่ยวข้องกับอะไร ...
ปัญหา
ลองจินตนาการถึงสถานการณ์ดังกล่าว บริษัทมีทีมพัฒนาจำนวนมากที่ทำงานในโครงการอิสระ แอปพลิเคชันส่วนใหญ่ทำงานบน Kubernetes ดังนั้นจึงถูกคอนเทนเนอร์ ในการจัดเก็บคอนเทนเนอร์ รูปภาพ คุณต้องมีรีจิสตรี (registry) บริษัทจึงใช้ Docker Hub ด้วยบัญชีเดียว COMPANY. คล้ายกับระบบจัดเก็บซอร์สโค้ดส่วนใหญ่ Docker Hub ไม่อนุญาตให้มีลำดับชั้นของที่เก็บซ้อนกัน, เช่น COMPANY/PROJECT/IMAGE. ในกรณีนั้น… คุณจะจัดเก็บแอปพลิเคชันที่ไม่ใช่เสาหินในรีจิสทรีด้วยข้อจำกัดนี้ได้อย่างไรโดยไม่ต้องสร้างบัญชีแยกต่างหากสำหรับแต่ละโครงการ
บางทีบางคนคุ้นเคยกับสถานการณ์ที่อธิบายโดยตรง แต่ลองพิจารณาปัญหาของการจัดระเบียบที่เก็บข้อมูลแอปพลิเคชันโดยทั่วไปเช่น โดยไม่มีการอ้างอิงถึงตัวอย่างข้างต้นและ Docker Hub
วิธีของการแก้ปัญหา
หากสมัคร เสาหินมาในหนึ่งภาพ จึงไม่มีคำถามใด ๆ และเราเพียงบันทึกรูปภาพลงในรีจีสทรีคอนเทนเนอร์ของโครงการ
เมื่อแอปพลิเคชันแสดงเป็นองค์ประกอบหลายส่วน ไมโครเซอร์วิสจากนั้นจำเป็นต้องมีวิธีการบางอย่าง ในตัวอย่างเว็บแอปพลิเคชันทั่วไปประกอบด้วยสองรูปภาพ: frontend и backend - ตัวเลือกที่เป็นไปได้คือ:
- เก็บภาพในที่เก็บข้อมูลที่ซ้อนกันแยกกัน:
- เก็บทุกอย่างไว้ในที่เก็บข้อมูลเดียว และพิจารณาชื่อรูปภาพในแท็ก ดังต่อไปนี้:
NB: จริง ๆ แล้วมีตัวเลือกอื่นสำหรับการบันทึกในที่เก็บต่าง ๆ PROJECT-frontend и PROJECT-backendแต่เราจะไม่พิจารณาเนื่องจากความซับซ้อนของการสนับสนุน การจัดระเบียบ และการกระจายสิทธิ์ระหว่างผู้ใช้
การสนับสนุน
ในขั้นต้น werf จำกัด ตัวเองไว้ที่ที่เก็บซ้อนกัน - โชคดีที่การลงทะเบียนส่วนใหญ่รองรับคุณสมบัตินี้ เริ่มตั้งแต่รุ่น เพิ่มการทำงานกับการลงทะเบียนซึ่ง ไม่รองรับการซ้อนและ Docker Hub เป็นหนึ่งในนั้น จากจุดนั้น ผู้ใช้มีทางเลือกในการจัดเก็บอิมเมจแอปพลิเคชัน
ใช้งานได้ภายใต้ตัวเลือก --images-repo-mode=multirepo|monorepo (ค่าเริ่มต้น multirepo, เช่น. เก็บไว้ในที่เก็บข้อมูลที่ซ้อนกัน) กำหนดรูปแบบที่จัดเก็บรูปภาพในรีจิสทรี ก็เพียงพอแล้วที่จะเลือกโหมดที่ต้องการเมื่อใช้คำสั่งพื้นฐาน และทุกอย่างจะไม่เปลี่ยนแปลง
เนื่องจากตัวเลือก werf ส่วนใหญ่สามารถตั้งค่าได้ ตัวแปรสภาพแวดล้อมในระบบ CI / CD โดยปกติแล้วโหมดการจัดเก็บจะตั้งค่าได้ง่ายทั่วโลกสำหรับทั้งโครงการ ตัวอย่างเช่น, ในกรณีของ GitLab เพียงเพิ่มตัวแปรสภาพแวดล้อมในการตั้งค่าโครงการ: การตั้งค่า -> CI / CD -> ตัวแปร: WERF_IMAGES_REPO_MODE: multirepo|monorepo.
หากเราพูดถึงการเผยแพร่รูปภาพและการเปิดตัวแอปพลิเคชัน (คุณสามารถอ่านรายละเอียดเกี่ยวกับกระบวนการเหล่านี้ได้ในบทความเอกสารที่เกี่ยวข้อง: и ) จากนั้นโหมดจะกำหนดเทมเพลตที่คุณสามารถทำงานกับรูปภาพได้เท่านั้น
ปีศาจอยู่ในรายละเอียด
ความแตกต่างและปัญหาหลักเมื่อเพิ่มวิธีการจัดเก็บข้อมูลใหม่คือการทำความสะอาดรีจิสทรี (สำหรับคุณสมบัติการล้างข้อมูลที่รองรับโดย werf โปรดดู ).
เมื่อทำความสะอาด werf จะพิจารณาอิมเมจที่ใช้ในคลัสเตอร์ Kubernetes รวมถึงนโยบายที่กำหนดค่าโดยผู้ใช้ นโยบายขึ้นอยู่กับการแบ่งแท็กออกเป็นกลยุทธ์ กลยุทธ์ที่รองรับในปัจจุบัน:
- 3 กลยุทธ์ที่เชื่อมโยงโดย Git ดั้งเดิม เช่น แท็ก แบรนช์ และคอมมิต
- 1 กลยุทธ์สำหรับแท็กที่กำหนดเองโดยพลการ
เราบันทึกข้อมูลเกี่ยวกับกลยุทธ์แท็กเมื่อเผยแพร่รูปภาพในป้ายกำกับของรูปภาพสุดท้าย ความหมายนั้นเป็นสิ่งที่เรียกว่า เมตาแท็ก - จำเป็นต้องใช้นโยบายบางอย่าง ตัวอย่างเช่น เมื่อลบสาขาหรือแท็กออกจากที่เก็บ Git มีเหตุผลที่จะลบที่เกี่ยวข้อง ไม่ได้ใช้ รูปภาพจากรีจิสทรีซึ่งครอบคลุมโดยส่วนหนึ่งของนโยบายของเรา
เมื่อบันทึกไว้ในที่เก็บเดียว (monorepo) ในแท็กรูปภาพ นอกจากเมตาแท็กแล้ว ยังสามารถเก็บชื่อของรูปภาพได้อีกด้วย: PROJECT:frontend-META-TAG. ในการแยกสิ่งเหล่านี้ เราไม่ได้แนะนำตัวคั่นเฉพาะใดๆ แต่เพียงแค่เพิ่มค่าที่จำเป็นให้กับป้ายกำกับของภาพสุดท้ายเมื่อทำการเผยแพร่
NB: หากคุณสนใจที่จะดูทุกสิ่งที่อธิบายไว้ในซอร์สโค้ด werf จุดเริ่มต้นก็สามารถเป็นได้ .
ในบทความนี้ เราจะไม่ให้ความสำคัญกับปัญหาและเหตุผลของวิธีการของเรา: เกี่ยวกับกลยุทธ์การติดแท็ก การจัดเก็บข้อมูลในป้ายกำกับและกระบวนการเผยแพร่โดยรวม ทั้งหมดนี้อธิบายโดยละเอียดในรายงานล่าสุดโดย Dmitry Stolyarov: “'
สรุป
การขาดการสนับสนุนสำหรับการลงทะเบียนที่ไม่ได้ซ้อนกันไม่ได้เป็นปัจจัยปิดกั้นสำหรับเราหรือผู้ใช้ werf ที่เรารู้จัก ท้ายที่สุด คุณสามารถเพิ่มการลงทะเบียนอิมเมจแยกต่างหาก (หรือเปลี่ยนเป็นคอนเทนเนอร์รีจิสตรีแบบมีเงื่อนไขใน Google Cloud) ... อย่างไรก็ตาม การลบข้อ จำกัด ดังกล่าวดูมีเหตุผลเพื่อให้เครื่องมือมีความสะดวกมากขึ้นในชุมชน DevOps ที่กว้างขึ้น เราประสบปัญหาหลักในการทำงานซ้ำของกลไกการล้างข้อมูลรีจิสทรีของคอนเทนเนอร์ เมื่อทุกอย่างพร้อมแล้ว เป็นเรื่องดีที่ได้รู้ว่ามันกลายเป็นเรื่องง่ายสำหรับใครบางคน และเรา (ในฐานะผู้พัฒนาหลักของโครงการ) จะไม่มีปัญหาใด ๆ ที่เห็นได้ชัดเจนในการสนับสนุนคุณสมบัตินี้เพิ่มเติม
อยู่กับเราและเร็ว ๆ นี้เราจะบอกคุณเกี่ยวกับนวัตกรรมอื่น ๆ ใน !
PS
อ่านเพิ่มเติมในบล็อกของเรา:
- «";
- «'
ที่มา: will.com