โปรโฮสต์ > บล็อก > การบริหาร > การแท็กตามเนื้อหาในตัวรวบรวม WRF: เหตุใดจึงทำงานอย่างไร

การแท็กตามเนื้อหาในตัวรวบรวม WRF: เหตุใดจึงทำงานอย่างไร

การแท็กตามเนื้อหาในตัวรวบรวม WRF: เหตุใดจึงทำงานอย่างไร

เวร เป็นยูทิลิตี้ GitOps CLI แบบโอเพ่นซอร์สของเราสำหรับการสร้างและส่งมอบแอปพลิเคชันไปยัง Kubernetes ใน ปล่อย v1.1 มีการแนะนำคุณสมบัติใหม่ในตัวรวบรวมรูปภาพ: การแท็กรูปภาพตามเนื้อหาหรือ การแท็กตามเนื้อหา. จนถึงขณะนี้ รูปแบบการแท็กทั่วไปใน werf เกี่ยวข้องกับการแท็กอิมเมจ Docker ด้วยแท็ก Git สาขา Git หรือ Git commit แต่รูปแบบทั้งหมดเหล่านี้มีข้อเสียที่ได้รับการแก้ไขอย่างสมบูรณ์ด้วยกลยุทธ์การติดแท็กใหม่ รายละเอียดเกี่ยวกับมันและทำไมมันถึงดีขนาดนั้นยังอยู่ระหว่างการพิจารณา

การเปิดตัวชุดไมโครเซอร์วิสจากที่เก็บ Git เดียว

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

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

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

การแท็กตามสาขา Git และแท็ก Git

สมมติว่ามีการใช้กลยุทธ์การติดแท็กที่ใช้บ่อยที่สุด - แท็กหรือสาขา. สำหรับสาขา Git รูปภาพจะถูกแท็กด้วยชื่อของสาขา สำหรับสาขาเดียวในแต่ละครั้ง จะมีรูปภาพที่เผยแพร่ตามชื่อของสาขานั้นเพียงรูปภาพเดียวเท่านั้น สำหรับแท็ก Git รูปภาพจะถูกแท็กตามชื่อแท็ก

เมื่อมีการสร้างแท็ก Git ใหม่ เช่น เมื่อมีการออกเวอร์ชันใหม่ แท็ก Docker ใหม่สำหรับอิมเมจโปรเจ็กต์ทั้งหมดใน Docker Registry:

  • myregistry.org/myproject/frontend:v1.1.10
  • myregistry.org/myproject/myservice1:v1.1.10
  • myregistry.org/myproject/myservice2:v1.1.10
  • myregistry.org/myproject/myservice3:v1.1.10
  • myregistry.org/myproject/myservice4:v1.1.10
  • myregistry.org/myproject/myservice5:v1.1.10
  • myregistry.org/myproject/database:v1.1.10

ชื่อรูปภาพใหม่เหล่านี้จะถูกส่งผ่านเทมเพลต Helm ไปยังการกำหนดค่า Kubernetes เมื่อเริ่มใช้งานด้วยคำสั่ง werf deploy ฟิลด์กำลังได้รับการปรับปรุง image ในทรัพยากร Kubernetes จะแสดงและรีสตาร์ททรัพยากรที่เกี่ยวข้องเนื่องจากชื่อรูปภาพที่เปลี่ยนไป

ปัญหา: ในกรณีที่อันที่จริงแล้วเนื้อหาของรูปภาพไม่เปลี่ยนแปลงตั้งแต่การเปิดตัวครั้งก่อน (แท็ก Git) แต่มีเพียงแท็ก Docker เท่านั้น สิ่งนี้จะเกิดขึ้น พิเศษ รีสตาร์ทแอปพลิเคชันนี้ และอาจทำให้ระบบหยุดทำงานบางส่วนได้ แม้ว่าจะไม่มีเหตุผลที่แท้จริงในการรีสตาร์ทนี้

ด้วยเหตุนี้ ด้วยรูปแบบการแท็กปัจจุบัน จึงจำเป็นต้องล้อมรั้วที่เก็บ Git แยกกันหลายแห่ง และปัญหาก็เกิดขึ้นจากการจัดระเบียบการเปิดตัวของที่เก็บหลายแห่งเหล่านี้ โดยทั่วไปโครงการดังกล่าวมีภาระมากเกินไปและซับซ้อน เป็นการดีกว่าที่จะรวมบริการต่างๆ ไว้ในที่เก็บข้อมูลเดียวและสร้างแท็ก Docker เพื่อไม่ให้รีสตาร์ทโดยไม่จำเป็น

การแท็กโดย Git กระทำ

werf ยังมีกลยุทธ์การแท็กที่เกี่ยวข้องกับ Git commits

Git-commit เป็นตัวระบุเนื้อหาของที่เก็บ Git และขึ้นอยู่กับประวัติการแก้ไขของไฟล์ในที่เก็บ Git ดังนั้นจึงดูสมเหตุสมผลที่จะใช้มันเพื่อแท็กรูปภาพใน Docker Registry

อย่างไรก็ตาม การแท็กโดยคอมมิต Git มีข้อเสียเช่นเดียวกับการแท็กโดยสาขา Git หรือแท็ก Git:

  • สามารถสร้างคอมมิตที่ว่างเปล่าซึ่งจะไม่เปลี่ยนแปลงไฟล์ใดๆ แต่แท็ก Docker ของรูปภาพจะเปลี่ยนไป
  • สามารถสร้างการรวมคอมมิตได้ซึ่งจะไม่เปลี่ยนไฟล์ แต่แท็ก Docker ของรูปภาพจะเปลี่ยนไป
  • การดำเนินการสามารถทำได้โดยเปลี่ยนไฟล์เหล่านั้นใน Git ที่ไม่ได้นำเข้าสู่รูปภาพ และแท็ก Docker ของรูปภาพจะเปลี่ยนไปอีกครั้ง

การแท็กชื่อสาขา Git ไม่ได้สะท้อนถึงเวอร์ชันรูปภาพ

มีปัญหาอื่นที่เกี่ยวข้องกับกลยุทธ์การแท็กสำหรับสาขา Git

การแท็กตามชื่อสาขาจะทำงานได้ตราบใดที่การคอมมิตในสาขานั้นถูกรวบรวมตามลำดับตามลำดับเวลา

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

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

การแท็กตามเนื้อหาคืออะไร?

ดังนั้นการแท็กตามเนื้อหาคืออะไร - การแท็กรูปภาพตามเนื้อหา

หากต้องการสร้างแท็ก Docker จะใช้ไม่ใช่ Git ดั้งเดิม (สาขา Git, แท็ก Git...) ที่ใช้ แต่เป็นการตรวจสอบที่เกี่ยวข้องกับ:

  • เนื้อหาของภาพ. แท็ก ID รูปภาพสะท้อนถึงเนื้อหา เมื่อสร้างเวอร์ชันใหม่ ตัวระบุนี้จะไม่เปลี่ยนแปลงหากไฟล์ในรูปภาพไม่เปลี่ยนแปลง
  • ประวัติความเป็นมาของการสร้างภาพนี้ใน Git. รูปภาพที่เกี่ยวข้องกับสาขา Git ที่แตกต่างกันและประวัติการสร้างที่แตกต่างกันผ่านทาง wef จะมีแท็ก ID ที่แตกต่างกัน

แท็กตัวระบุดังกล่าวเรียกว่า ลายเซ็นบนเวทีภาพ.

แต่ละภาพประกอบด้วยชุดของขั้นตอน: from, before-install, git-archive, install, imports-after-install, before-setup... git-latest-patch ฯลฯ แต่ละขั้นตอนมีตัวระบุที่สะท้อนถึงเนื้อหา - ลายเซ็นบนเวที (ลายเซ็นบนเวที).

ภาพสุดท้ายที่ประกอบด้วยขั้นตอนเหล่านี้ มีแท็กที่เรียกว่าลายเซ็นของชุดขั้นตอนเหล่านี้ - ลายเซ็นขั้นตอน, - ซึ่งเป็นลักษณะทั่วไปสำหรับทุกขั้นตอนของภาพ

สำหรับแต่ละภาพจากการกำหนดค่า werf.yaml ในกรณีทั่วไป จะมีลายเซ็นของตัวเองและแท็ก Docker ตามลำดับ

ลายเซ็นบนเวทีช่วยแก้ปัญหาเหล่านี้ทั้งหมด:

  • ทนต่อคอมมิต Git ที่ว่างเปล่า
  • Resistance to Git มุ่งมั่นที่จะเปลี่ยนแปลงไฟล์ที่ไม่เกี่ยวข้องกับรูปภาพ
  • ไม่นำไปสู่ปัญหาในการยกเครื่องอิมเมจเวอร์ชันปัจจุบันเมื่อรีสตาร์ทบิลด์สำหรับ Git คอมมิตของสาขา

นี่คือกลยุทธ์การแท็กที่แนะนำในขณะนี้ และเป็นค่าเริ่มต้นใน wef สำหรับระบบ CI ทั้งหมด

วิธีเปิดใช้งานและใช้งานใน werf

คำสั่งนี้มีตัวเลือกที่เกี่ยวข้องแล้ว werf publish: --tag-by-stages-signature=true|false

ในระบบ CI กลยุทธ์การแท็กจะถูกระบุโดยคำสั่ง werf ci-env. ก่อนหน้านี้ พารามิเตอร์ถูกกำหนดไว้แล้ว werf ci-env --tagging-strategy=tag-or-branch. ตอนนี้ถ้าคุณระบุ werf ci-env --tagging-strategy=stages-signature หรือไม่ระบุตัวเลือกนี้ werf จะใช้กลยุทธ์การแท็กตามค่าเริ่มต้น stages-signature. ทีม werf ci-env จะตั้งค่าสถานะที่จำเป็นสำหรับคำสั่งโดยอัตโนมัติ werf build-and-publish (หรือ werf publish) ดังนั้นจึงไม่จำเป็นต้องระบุตัวเลือกเพิ่มเติมสำหรับคำสั่งเหล่านี้

ตัวอย่างเช่น คำสั่ง:

werf publish --stages-storage :local --images-repo registry.hello.com/web/core/system --tag-by-stages-signature

...สามารถสร้างภาพดังต่อไปนี้:

  • registry.hello.com/web/core/system/backend:4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d
  • registry.hello.com/web/core/system/frontend:f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6

ที่นี่ 4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d เป็นลายเซ็นของขั้นตอนของภาพ backendและ f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6 - ลายเซ็นของขั้นตอนภาพ frontend.

เมื่อใช้ฟังก์ชันพิเศษ werf_container_image и werf_container_env ไม่จำเป็นต้องเปลี่ยนแปลงอะไรในเทมเพลต Helm: ฟังก์ชันเหล่านี้จะสร้างชื่อรูปภาพที่ถูกต้องโดยอัตโนมัติ

ตัวอย่างการกำหนดค่าในระบบ CI:

type multiwerf && source <(multiwerf use 1.1 beta)
type werf && source <(werf ci-env gitlab)
werf build-and-publish|deploy

ข้อมูลเพิ่มเติมเกี่ยวกับการกำหนดค่ามีอยู่ในเอกสารประกอบ:

เบ็ดเสร็จ

  • ทางเลือกใหม่ werf publish --tag-by-stages-signature=true|false.
  • ค่าตัวเลือกใหม่ werf ci-env --tagging-strategy=stages-signature|tag-or-branch (หากไม่ได้ระบุ ค่าเริ่มต้นจะเป็น stages-signature).
  • หากก่อนหน้านี้คุณใช้ตัวเลือกการแท็กสำหรับ Git คอมมิต (WERF_TAG_GIT_COMMIT หรือตัวเลือก werf publish --tag-git-commit COMMIT) จากนั้นอย่าลืมเปลี่ยนไปใช้กลยุทธ์การติดแท็ก ขั้นตอนลายเซ็น.
  • เป็นการดีกว่าถ้าเปลี่ยนโปรเจ็กต์ใหม่เป็นรูปแบบการติดแท็กใหม่ทันที
  • เมื่อถ่ายโอนไปยัง werf 1.1 ขอแนะนำให้เปลี่ยนโปรเจ็กต์เก่าเป็นรูปแบบการแท็กใหม่ แต่โปรเจ็กต์เก่า แท็กหรือสาขา ยังคงได้รับการสนับสนุน

การแท็กตามเนื้อหาช่วยแก้ปัญหาทั้งหมดที่กล่าวถึงในบทความ:

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

ใช้มัน! และอย่าลืมแวะมาเยี่ยมชมเราได้ที่ GitHubเพื่อสร้างปัญหาหรือค้นหาปัญหาที่มีอยู่ เพิ่มข้อดี สร้างประชาสัมพันธ์ หรือเพียงแค่ดูการพัฒนาของโครงการ

PS

อ่านเพิ่มเติมในบล็อกของเรา:

ที่มา: will.com

เพิ่มความคิดเห็น