เป็นยูทิลิตี้ GitOps CLI แบบโอเพ่นซอร์สของเราสำหรับการสร้างและส่งมอบแอปพลิเคชันไปยัง Kubernetes ตามที่สัญญาไว้ ถือเป็นจุดเริ่มต้นของการเพิ่มคุณสมบัติใหม่ๆ เพื่อดำเนินการและแก้ไขแนวทางดั้งเดิม ตอนนี้เรามีความยินดีที่จะนำเสนอเวอร์ชัน 1.1 ซึ่งเป็นก้าวสำคัญในการพัฒนาและเป็นรากฐานสำหรับอนาคต นักสะสม เวิร์ฟ รุ่นนี้มีวางจำหน่ายแล้วที่ .
พื้นฐานของการเปิดตัวคือสถาปัตยกรรมใหม่ของพื้นที่จัดเก็บบนเวทีและการเพิ่มประสิทธิภาพการทำงานของนักสะสมทั้งสอง (สำหรับ Stapel และ Dockerfile) สถาปัตยกรรมการจัดเก็บข้อมูลใหม่เปิดความเป็นไปได้ในการใช้แอสเซมบลีแบบกระจายจากหลายโฮสต์และแอสเซมบลีแบบขนานบนโฮสต์เดียวกัน
การเพิ่มประสิทธิภาพการทำงานรวมถึงการกำจัดการคำนวณที่ไม่จำเป็นในขั้นตอนการคำนวณลายเซ็นของขั้นตอนและการเปลี่ยนกลไกในการคำนวณการตรวจสอบไฟล์ให้มีประสิทธิภาพมากขึ้น การเพิ่มประสิทธิภาพนี้จะช่วยลดเวลาเฉลี่ยในการสร้างโปรเจ็กต์โดยใช้ wef และบิลด์ที่ไม่ได้ใช้งาน เมื่อทุกขั้นตอนมีอยู่ในแคช ขั้นตอนการจัดเก็บตอนนี้รวดเร็วมาก ในกรณีส่วนใหญ่ การรีสตาร์ทบิลด์จะใช้เวลาน้อยกว่า 1 วินาที! นอกจากนี้ยังใช้กับขั้นตอนการตรวจสอบขั้นตอนในกระบวนการทำงานของทีมด้วย werf deploy и werf run.
นอกจากนี้ ในข่าวประชาสัมพันธ์ฉบับนี้ ยังมีกลยุทธ์สำหรับการแท็กรูปภาพตามเนื้อหา - การแท็กตามเนื้อหาซึ่งขณะนี้เปิดใช้งานตามค่าเริ่มต้นและเป็นรายการเดียวที่แนะนำ
มาดูนวัตกรรมที่สำคัญใน wef v1.1 กันดีกว่า และในขณะเดียวกันก็บอกคุณเกี่ยวกับแผนการสำหรับอนาคต
มีอะไรเปลี่ยนแปลงใน wef v1.1?
รูปแบบการตั้งชื่อสเตจใหม่และอัลกอริธึมสำหรับการเลือกสเตจจากแคช
กฎการสร้างชื่อบนเวทีใหม่ ตอนนี้ แต่ละสเตจบิลด์จะสร้างชื่อสเตจที่ไม่ซ้ำกัน ซึ่งประกอบด้วย 2 ส่วน: ลายเซ็นต์ (เหมือนในเวอร์ชัน 1.0) พร้อมด้วยตัวระบุชั่วคราวที่ไม่ซ้ำกัน
ตัวอย่างเช่น ชื่อรูปภาพแบบเต็มพื้นที่อาจมีลักษณะดังนี้:
werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835
...หรือโดยทั่วไป:
werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC
ที่นี่:
-
SIGNATUREเป็นลายเซ็นสเตจซึ่งแสดงถึงตัวระบุเนื้อหาสเตจและขึ้นอยู่กับประวัติการแก้ไขใน Git ที่นำไปสู่เนื้อหานี้ -
TIMESTAMP_MILLISECเป็นตัวระบุรูปภาพที่ไม่ซ้ำใครที่รับประกันซึ่งสร้างขึ้นในขณะที่สร้างรูปภาพใหม่
อัลกอริธึมสำหรับการเลือกสเตจจากแคชจะขึ้นอยู่กับการตรวจสอบความสัมพันธ์ของคอมมิต Git:
- Werf คำนวณลายเซ็นของขั้นตอนหนึ่ง
- В ขั้นตอนการจัดเก็บ ลายเซ็นที่กำหนดอาจมีหลายขั้นตอน Werf เลือกทุกขั้นตอนที่ตรงกับลายเซ็น
- หากสเตจปัจจุบันเชื่อมโยงกับ Git (git-archive, สเตจแบบกำหนดเองพร้อมแพตช์ Git:
install,beforeSetup,setup; หรือ git-latest-patch) จากนั้น werf จะเลือกเฉพาะขั้นตอนที่เกี่ยวข้องกับการคอมมิตที่เป็นบรรพบุรุษของการคอมมิตปัจจุบัน (ซึ่งเรียกว่าบิลด์) - จากขั้นตอนที่เหมาะสมที่เหลือ จะมีการเลือกขั้นตอนหนึ่ง - เก่าที่สุดตามวันที่สร้าง
สเตจสำหรับสาขา Git ที่แตกต่างกันสามารถมีลายเซ็นเดียวกันได้ แต่เวิร์ฟจะป้องกันไม่ให้แคชที่เกี่ยวข้องกับสาขาต่างๆ ถูกใช้ระหว่างสาขาเหล่านี้ แม้ว่าลายเซ็นจะตรงกันก็ตาม
.
อัลกอริธึมใหม่สำหรับการสร้างและบันทึกสเตจในที่เก็บข้อมูลสเตจ
เมื่อเลือกสเตจจากแคช หาก werf ไม่พบสเตจที่เหมาะสม กระบวนการประกอบสเตจใหม่จะเริ่มต้นขึ้น
โปรดทราบว่ากระบวนการหลายรายการ (บนโฮสต์หนึ่งรายการขึ้นไป) สามารถเริ่มสร้างขั้นตอนเดียวกันในเวลาเดียวกันโดยประมาณได้ Werf ใช้อัลกอริธึมการบล็อกในแง่ดี ขั้นตอนการจัดเก็บ ในขณะที่บันทึกภาพที่รวบรวมใหม่เข้ามา ขั้นตอนการจัดเก็บ. ด้วยวิธีนี้ เมื่อการสร้างสเตจใหม่พร้อมแล้ว ให้ทำการบล็อกทันที ขั้นตอนการจัดเก็บ และบันทึกภาพที่รวบรวมใหม่ไว้ที่นั่นเฉพาะในกรณีที่ไม่มีภาพที่เหมาะสมอยู่ที่นั่นอีกต่อไป (ตามลายเซ็นและพารามิเตอร์อื่น ๆ - ดูอัลกอริธึมใหม่สำหรับการเลือกสเตจจากแคช).
รูปภาพที่ประกอบใหม่รับประกันว่าจะมีตัวระบุที่ไม่ซ้ำกันโดย TIMESTAMP_MILLISEC (ดูรูปแบบการตั้งชื่อเวทีใหม่). ในกรณีที่ใน ขั้นตอนการจัดเก็บ จะพบรูปภาพที่เหมาะสม werf จะทิ้งรูปภาพที่รวบรวมใหม่และจะใช้รูปภาพจากแคช
กล่าวอีกนัยหนึ่ง: กระบวนการแรกในการสร้างอิมเมจให้เสร็จสิ้น (กระบวนการที่เร็วที่สุด) จะได้รับสิทธิ์ในการจัดเก็บข้อมูลในขั้นตอนการจัดเก็บ (จากนั้นจะเป็นอิมเมจเดียวนี้ที่จะใช้สำหรับบิลด์ทั้งหมด) กระบวนการสร้างที่ช้าจะไม่ปิดกั้นกระบวนการที่เร็วกว่าจากการบันทึกผลลัพธ์การสร้างของระยะปัจจุบันและก้าวไปสู่การสร้างครั้งถัดไป
.
ปรับปรุงประสิทธิภาพของตัวสร้าง Dockerfile
ในขณะนี้ ไปป์ไลน์ของสเตจสำหรับรูปภาพที่สร้างจาก Dockerfile ประกอบด้วยสเตจเดียว - dockerfile. เมื่อคำนวณลายเซ็น จะมีการคำนวณผลรวมตรวจสอบของไฟล์ contextซึ่งจะใช้ในระหว่างการประกอบ ก่อนการปรับปรุงนี้ เราจะดำเนินการผ่านไฟล์ทั้งหมดซ้ำๆ และรับผลรวมตรวจสอบโดยการสรุปบริบทและโหมดของแต่ละไฟล์ ตั้งแต่เวอร์ชัน 1.1 เป็นต้นไป werf สามารถใช้เช็คซัมที่คำนวณแล้วซึ่งจัดเก็บไว้ในที่เก็บ Git
อัลกอริทึมจะขึ้นอยู่กับ . อัลกอริทึมคำนึงถึงบันทึกในบัญชี .dockerignore และสำรวจแผนผังไฟล์แบบวนซ้ำเมื่อจำเป็นเท่านั้น ดังนั้นเราจึงแยกจากการอ่านระบบไฟล์และการพึ่งพาอัลกอริธึมกับขนาด context ไม่มีนัยสำคัญ
อัลกอริธึมยังตรวจสอบไฟล์ที่ไม่ได้ติดตาม และหากจำเป็น จะพิจารณาไฟล์เหล่านั้นในเช็คซัม
ปรับปรุงประสิทธิภาพเมื่อนำเข้าไฟล์
เวอร์ชันของ werf v1.1 จะใช้เซิร์ฟเวอร์ rsync เมื่อใด . ก่อนหน้านี้ การนำเข้าเสร็จสิ้นในสองขั้นตอนโดยใช้การต่อเชื่อมไดเร็กทอรีจากระบบโฮสต์
ประสิทธิภาพการนำเข้าบน macOS ไม่ถูกจำกัดด้วยโวลุ่ม Docker อีกต่อไป และการนำเข้าจะเสร็จสิ้นภายในระยะเวลาเดียวกันกับ Linux และ Windows
การแท็กตามเนื้อหา
Werf v1.1 รองรับสิ่งที่เรียกว่าการแท็กตามเนื้อหารูปภาพ - การแท็กตามเนื้อหา. แท็กของรูปภาพ Docker ที่ได้จะขึ้นอยู่กับเนื้อหาของรูปภาพเหล่านั้น
เมื่อรันคำสั่ง werf publish --tags-by-stages-signature หรือ werf ci-env --tagging-strategy=stages-signature เผยแพร่ภาพของสิ่งที่เรียกว่า ลายเซ็นบนเวที ภาพ. รูปภาพแต่ละรูปจะถูกแท็กด้วยลายเซ็นของตัวเองในแต่ละขั้นตอนของรูปภาพ ซึ่งคำนวณตามกฎเดียวกันกับลายเซ็นปกติของแต่ละขั้นตอนแยกจากกัน แต่เป็นตัวระบุทั่วไปของรูปภาพ
ลายเซ็นของขั้นตอนรูปภาพขึ้นอยู่กับ:
- เนื้อหาของภาพนี้
- ประวัติการเปลี่ยนแปลง Git ที่นำไปสู่เนื้อหานี้
พื้นที่เก็บข้อมูล Git จะมีการกระทำจำลองที่ไม่เปลี่ยนแปลงเนื้อหาของไฟล์รูปภาพเสมอ ตัวอย่างเช่น คอมมิตโดยแสดงความคิดเห็นเท่านั้น หรือการคอมมิตแบบรวม หรือคอมมิตที่เปลี่ยนแปลงไฟล์เหล่านั้นใน Git ซึ่งจะไม่ถูกนำเข้าลงในอิมเมจ
เมื่อใช้การแท็กตามเนื้อหา ปัญหาของการรีสตาร์ทแอปพลิเคชันพ็อดใน Kubernetes โดยไม่จำเป็นเนื่องจากการเปลี่ยนชื่อรูปภาพจะได้รับการแก้ไข แม้ว่าเนื้อหาของรูปภาพจะไม่เปลี่ยนแปลงก็ตาม อย่างไรก็ตาม นี่คือหนึ่งในเหตุผลที่ทำให้ไม่สามารถจัดเก็บไมโครเซอร์วิสจำนวนมากของแอปพลิเคชันเดียวไว้ในที่เก็บ Git เดียว
นอกจากนี้ การแท็กตามเนื้อหาเป็นวิธีการแท็กที่เชื่อถือได้มากกว่าการแท็กบนสาขา Git เนื่องจากเนื้อหาของรูปภาพผลลัพธ์ไม่ได้ขึ้นอยู่กับลำดับที่ไปป์ไลน์ถูกดำเนินการในระบบ CI สำหรับการประกอบหลายคอมมิตของสาขาเดียวกัน
มันเป็นสิ่งสำคัญ: เริ่มตั้งแต่บัดนี้เป็นต้นไป ขั้นตอนลายเซ็น - เป็น กลยุทธ์การติดแท็กเดียวที่แนะนำ. มันจะถูกใช้เป็นค่าเริ่มต้นในคำสั่ง werf ci-env (เว้นแต่คุณจะระบุรูปแบบการติดแท็กอื่นอย่างชัดเจน)
. นอกจากนี้ จะมีการตีพิมพ์เผยแพร่แยกต่างหากสำหรับฟีเจอร์นี้ด้วย อัพเดท (3 เมษายน): บทความพร้อมรายละเอียด .
ระดับการบันทึก
ขณะนี้ผู้ใช้มีโอกาสที่จะควบคุมเอาต์พุต ตั้งค่าระดับการบันทึก และทำงานกับข้อมูลการแก้ไขจุดบกพร่อง เพิ่มตัวเลือกแล้ว --log-quiet, --log-verbose, --log-debug.
ตามค่าเริ่มต้น ผลลัพธ์จะมีข้อมูลขั้นต่ำ:
เมื่อใช้เอาต์พุตแบบละเอียด (--log-verbose) คุณสามารถดูวิธีการทำงานของ wef:
เอาต์พุตโดยละเอียด (--log-debug) นอกเหนือจากข้อมูลการแก้ไขข้อบกพร่องแล้ว ยังมีบันทึกของไลบรารีที่ใช้อีกด้วย ตัวอย่างเช่น คุณสามารถดูว่าการโต้ตอบกับ Docker Registry เกิดขึ้นได้อย่างไรและยังบันทึกสถานที่ที่ใช้ไปเป็นจำนวนมาก:
แผนต่อไป
คำเตือน! ตัวเลือกที่อธิบายด้านล่างถูกทำเครื่องหมายไว้ v1.1 จะวางจำหน่ายในเวอร์ชันนี้หลายตัวในอนาคตอันใกล้นี้ การอัปเดตจะมาผ่านการอัปเดตอัตโนมัติ . คุณสมบัติเหล่านี้ไม่ส่งผลกระทบต่อส่วนที่เสถียรของฟังก์ชัน v1.1 ลักษณะที่ปรากฏไม่จำเป็นต้องมีการแทรกแซงจากผู้ใช้ด้วยตนเองในการกำหนดค่าที่มีอยู่
รองรับการใช้งาน Docker Registry ต่างๆ อย่างเต็มรูปแบบ (ใหม่)
- เวอร์ชัน: v1.1
- วันที่: มีนาคม
เป้าหมายคือให้ผู้ใช้ใช้งานแบบกำหนดเองโดยไม่มีข้อจำกัดเมื่อใช้ werf
ในปัจจุบัน เราได้ระบุชุดโซลูชันต่อไปนี้ซึ่งเราจะรับประกันการสนับสนุนเต็มรูปแบบ:
- ค่าเริ่มต้น (ไลบรารี/รีจิสทรี)*,
- AWS ECR
- สีฟ้า*,
- นักเทียบท่าฮับ
- GCR*,
- แพ็คเกจ GitHub
- รีจิสทรี GitLab*,
- ท่าเรือ*,
- ท่าเรือ.
โซลูชันที่ Werf รองรับอย่างสมบูรณ์ในปัจจุบันจะมีเครื่องหมายดอกจันกำกับไว้ สำหรับคนอื่นก็มีการสนับสนุน แต่ก็มีข้อจำกัด
สามารถระบุปัญหาหลักได้สองประการ:
- โซลูชันบางอย่างไม่รองรับการลบแท็กโดยใช้ Docker Registry API ซึ่งทำให้ผู้ใช้ไม่สามารถใช้การล้างข้อมูลอัตโนมัติของ werf นี่เป็นเรื่องจริงสำหรับแพ็คเกจ AWS ECR, Docker Hub และ GitHub
- โซลูชันบางอย่างไม่รองรับสิ่งที่เรียกว่า Nested Repositories (Docker Hub, GitHub Package และ Quay) หรือรองรับ แต่ผู้ใช้ต้องสร้างด้วยตนเองโดยใช้ UI หรือ API (AWS ECR)
เราจะแก้ไขปัญหาเหล่านี้และปัญหาอื่นๆ โดยใช้ API ดั้งเดิมของโซลูชัน งานนี้ยังรวมถึงการครอบคลุมรอบการทำงานของเวิร์ฟทั้งหมดพร้อมการทดสอบสำหรับแต่ละงานด้วย
การสร้างรูปภาพแบบกระจาย (↑)
- เวอร์ชัน: v1.2 v1.1 (ลำดับความสำคัญในการใช้งานฟีเจอร์นี้เพิ่มขึ้น)
- วันที่: มีนาคม-เมษายน มีนาคม
ในขณะนี้ werf v1.0 และ v1.1 สามารถใช้ได้บนโฮสต์เฉพาะแห่งเดียวเท่านั้นสำหรับการดำเนินการสร้างและเผยแพร่อิมเมจ และปรับใช้แอปพลิเคชันกับ Kubernetes
เพื่อเปิดความเป็นไปได้ของการทำงานแบบกระจายของ werf เมื่อมีการเปิดตัวการสร้างและการปรับใช้แอปพลิเคชันใน Kubernetes บนโฮสต์ที่กำหนดเองหลายเครื่องและโฮสต์เหล่านี้ไม่ได้บันทึกสถานะระหว่างบิลด์ (รันเนอร์ชั่วคราว) werf จำเป็นต้องใช้ความสามารถในการใช้งาน Docker Registry เป็นที่เก็บเวที
ก่อนหน้านี้ เมื่อโปรเจ็กต์ werf ยังคงเรียกว่า dapp ก็มีโอกาสเช่นนี้ อย่างไรก็ตาม เราพบปัญหาหลายประการที่ต้องนำมาพิจารณาเมื่อใช้ฟังก์ชันนี้ใน WRF
หมายเหตุ. คุณลักษณะนี้ไม่ต้องการให้ตัวรวบรวมทำงานภายในพ็อด Kubernetes เนื่องจาก ในการดำเนินการนี้ คุณต้องยกเลิกการพึ่งพาเซิร์ฟเวอร์ Docker ในเครื่อง (ในพ็อด Kubernetes ไม่มีการเข้าถึงเซิร์ฟเวอร์ Docker ในเครื่อง เนื่องจากกระบวนการเองกำลังทำงานในคอนเทนเนอร์ และ werf ไม่และจะไม่รองรับ ทำงานร่วมกับเซิร์ฟเวอร์ Docker ผ่านเครือข่าย) การสนับสนุนสำหรับการรัน Kubernetes จะดำเนินการแยกกัน
การสนับสนุนอย่างเป็นทางการสำหรับ GitHub Actions (ใหม่)
- เวอร์ชัน: v1.1
- วันที่: มีนาคม
รวมเอกสาร WRF (ส่วน การอ้างอิง и ให้คำแนะนำ) รวมถึง GitHub Action อย่างเป็นทางการสำหรับการทำงานกับ werf
นอกจากนี้ มันจะช่วยให้ werf สามารถทำงานกับนักวิ่งชั่วคราวได้
กลไกของการโต้ตอบของผู้ใช้กับระบบ CI จะขึ้นอยู่กับการวางป้ายกำกับในคำขอดึงเพื่อเริ่มต้นการดำเนินการบางอย่างเพื่อสร้าง/เผยแพร่แอปพลิเคชัน
การพัฒนาและการปรับใช้แอปพลิเคชันในท้องถิ่นด้วย werf (↓)
- เวอร์ชัน: v1.1
- วันที่: มกราคม-กุมภาพันธ์ เมษายน
เป้าหมายหลักคือการบรรลุการกำหนดค่าแบบรวมศูนย์เดียวสำหรับการปรับใช้แอปพลิเคชันทั้งภายในเครื่องและในการใช้งานจริงโดยไม่ต้องดำเนินการที่ซับซ้อนทันที
werf จำเป็นต้องมีโหมดการทำงานซึ่งจะสะดวกในการแก้ไขโค้ดแอปพลิเคชันและรับข้อเสนอแนะจากแอปพลิเคชันที่ทำงานอยู่ทันทีเพื่อทำการดีบัก
อัลกอริธึมการทำความสะอาดใหม่ (ใหม่)
- เวอร์ชัน: v1.1
- วันที่: เมษายน
ในเวอร์ชันปัจจุบันของ wef v1.1 อยู่ในขั้นตอน cleanup ไม่มีข้อกำหนดในการทำความสะอาดรูปภาพสำหรับรูปแบบการแท็กตามเนื้อหา - รูปภาพเหล่านี้จะสะสม
นอกจากนี้ เวอร์ชันปัจจุบันของ werf (v1.0 และ v1.1) ใช้นโยบายการล้างข้อมูลที่แตกต่างกันสำหรับรูปภาพที่เผยแพร่ภายใต้รูปแบบการแท็ก: สาขา Git, แท็ก Git หรือคอมมิต Git
อัลกอริธึมใหม่สำหรับการล้างรูปภาพตามประวัติการคอมมิตใน Git ซึ่งรวมเป็นหนึ่งเดียวสำหรับแผนการแท็กทั้งหมดได้ถูกประดิษฐ์ขึ้น:
- เก็บรูปภาพไม่เกิน N1 ที่เชื่อมโยงกับการคอมมิตล่าสุดของ N2 สำหรับแต่ละ git HEAD (สาขาและแท็ก)
- จัดเก็บอิมเมจสเตจ N1 ไม่เกิน N2 ที่เกี่ยวข้องกับการคอมมิตล่าสุดของ NXNUMX สำหรับแต่ละ git HEAD (สาขาและแท็ก)
- จัดเก็บอิมเมจทั้งหมดที่ใช้ในทรัพยากรคลัสเตอร์ Kubernetes (สแกนบริบท kube ทั้งหมดของไฟล์การกำหนดค่าและเนมสเปซ คุณสามารถจำกัดการทำงานนี้ได้ด้วยตัวเลือกพิเศษ)
- จัดเก็บรูปภาพทั้งหมดที่ใช้ในรายการการกำหนดค่าทรัพยากรที่บันทึกไว้ในการเผยแพร่ Helm
- สามารถลบรูปภาพได้หากไม่ได้เชื่อมโยงกับ HEAD ใดๆ จาก git (เช่น เนื่องจาก HEAD ที่เกี่ยวข้องถูกลบไปแล้ว) และไม่ได้ใช้ในรายการใดๆ ในคลัสเตอร์ Kubernetes และในรุ่น Helm
การสร้างภาพคู่ขนาน (↓)
- เวอร์ชัน: v1.1
- วันที่: มกราคม-กุมภาพันธ์ เมษายน*
werf เวอร์ชันปัจจุบันรวบรวมรูปภาพและสิ่งประดิษฐ์ที่อธิบายไว้ในนั้น werf.yamlตามลำดับ มีความจำเป็นต้องขนานกระบวนการประกอบภาพและสิ่งประดิษฐ์ในขั้นตอนที่เป็นอิสระรวมทั้งให้ผลลัพธ์ที่สะดวกและให้ข้อมูล
* หมายเหตุ: กำหนดเวลามีการเปลี่ยนแปลงเนื่องจากลำดับความสำคัญที่เพิ่มขึ้นสำหรับการติดตั้งแอสเซมบลีแบบกระจาย ซึ่งจะเพิ่มความสามารถในการปรับขนาดแนวนอนมากขึ้น เช่นเดียวกับการใช้ werf กับ GitHub Actions การประกอบแบบขนานเป็นขั้นตอนถัดไปในการปรับให้เหมาะสม ซึ่งให้ความสามารถในการปรับขนาดแนวตั้งเมื่อประกอบหนึ่งโครงการ
เปลี่ยนไปใช้ Helm 3 (↓)
- เวอร์ชัน: v1.2
- วันที่: กุมภาพันธ์-มีนาคม พฤษภาคม*
รวมถึงการโยกย้ายไปยังฐานรหัสใหม่ และวิธีที่สะดวกในการย้ายการติดตั้งที่มีอยู่ที่ได้รับการพิสูจน์แล้ว
* หมายเหตุ: การเปลี่ยนมาใช้ Helm 3 จะไม่เพิ่มคุณสมบัติที่สำคัญให้กับ werf เนื่องจากคุณสมบัติหลักทั้งหมดของ Helm 3 (ผสาน 3 ทางและไม่มีหางเสือ) ได้ถูกนำไปใช้ใน werf แล้ว นอกจากนี้เวิร์ฟยังมี นอกเหนือจากที่ระบุไว้ อย่างไรก็ตาม การเปลี่ยนแปลงนี้ยังคงอยู่ในแผนของเราและจะมีการนำไปใช้
Jsonnet สำหรับอธิบายการกำหนดค่า Kubernetes (↓)
- เวอร์ชัน: v1.2
- วันที่: มกราคม-กุมภาพันธ์ เมษายน-พฤษภาคม
Werf จะรองรับคำอธิบายการกำหนดค่าสำหรับ Kubernetes ในรูปแบบ Jsonnet ในเวลาเดียวกัน werf จะยังคงเข้ากันได้กับ Helm และจะมีตัวเลือกรูปแบบคำอธิบายให้เลือก
เหตุผลก็คือ ตามความเห็นของหลายๆ คน เทมเพลต Go มีอุปสรรคในการเข้าสูงและความเข้าใจในโค้ดของเทมเพลตเหล่านี้ก็ลดลงเช่นกัน
ความเป็นไปได้ของการแนะนำระบบคำอธิบายการกำหนดค่า Kubernetes อื่นๆ (เช่น Kustomize) ก็อยู่ระหว่างการพิจารณาเช่นกัน
ทำงานภายใน Kubernetes (↓)
- เวอร์ชัน: v1.2
- วันที่: เมษายน-พฤษภาคม พฤษภาคม-มิถุนายน
เป้าหมาย: ตรวจสอบให้แน่ใจว่าอิมเมจถูกสร้างขึ้นและส่งมอบแอปพลิเคชันโดยใช้รันเนอร์ใน Kubernetes เหล่านั้น. คุณสามารถสร้าง เผยแพร่ ล้าง และปรับใช้อิมเมจใหม่ๆ ได้โดยตรงจากพ็อด Kubernetes
หากต้องการใช้ความสามารถนี้ คุณต้องสร้างอิมเมจแบบกระจายก่อน (ดูจุดด้านบน).
นอกจากนี้ยังต้องการการสนับสนุนสำหรับโหมดการทำงานของตัวสร้างโดยไม่ต้องใช้เซิร์ฟเวอร์ Docker (เช่น รุ่น Kaniko หรือรุ่นในพื้นที่ผู้ใช้)
Werf จะสนับสนุนการสร้างบน Kubernetes ไม่เพียงแต่กับ Dockerfile เท่านั้น แต่ยังรวมถึง Stapel builder ด้วยการสร้างใหม่เพิ่มเติมและ Ansible
ก้าวสู่การพัฒนาแบบเปิด
เรารักชุมชนของเรา (, ) และเราต้องการให้ผู้คนจำนวนมากขึ้นเรื่อยๆ ช่วยทำให้เวิร์ฟดีขึ้น เข้าใจทิศทางที่เรากำลังก้าวไป และมีส่วนร่วมในการพัฒนา
เมื่อไม่นานมานี้มีการตัดสินใจเปลี่ยนไปใช้ เพื่อเปิดเผยขั้นตอนการทำงานของทีมงานของเรา ตอนนี้คุณสามารถดูแผนงานทันที รวมถึงงานปัจจุบันในด้านต่อไปนี้:
- ;
- ;
- ;
- .
มีงานมากมายที่มีปัญหา:
- ลบสิ่งที่ไม่เกี่ยวข้องออก
- สิ่งที่มีอยู่จะถูกนำมาเป็นรูปแบบเดียวโดยมีรายละเอียดและรายละเอียดเพียงพอ
- มีการเพิ่มประเด็นใหม่เกี่ยวกับแนวคิดและข้อเสนอแนะ
วิธีเปิดใช้งานเวอร์ชัน v1.1
รุ่นนี้มีวางจำหน่ายแล้วที่ (ในช่อง มั่นคง и หินแข็ง อย่างไรก็ตาม การเผยแพร่จะปรากฏขึ้นเมื่อมีความเสถียรเกิดขึ้น ea เองก็มีความเสถียรเพียงพอต่อการใช้งานแล้วเพราะว่า ผ่านช่องทางต่างๆ แอลฟา и เบต้า). เปิดใช้งานแล้ว ด้วยวิธีต่อไปนี้:
source $(multiwerf use 1.1 ea)
werf COMMAND ...ข้อสรุป
สถาปัตยกรรมการจัดเก็บข้อมูลขั้นใหม่และการเพิ่มประสิทธิภาพตัวสร้างสำหรับตัวสร้าง Stapel และ Dockerfile เปิดความเป็นไปได้ในการใช้งานบิลด์แบบกระจายและแบบขนานใน werf คุณสมบัติเหล่านี้จะปรากฏในเวอร์ชัน v1.1 เดียวกันเร็วๆ นี้ และจะพร้อมใช้งานโดยอัตโนมัติผ่านกลไกการอัปเดตอัตโนมัติ (สำหรับผู้ใช้ ).
ในรุ่นนี้ มีการเพิ่มกลยุทธ์การแท็กตามเนื้อหารูปภาพ - การแท็กตามเนื้อหาซึ่งกลายเป็นกลยุทธ์เริ่มต้น บันทึกคำสั่งหลักยังได้รับการปรับปรุงใหม่: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.
ขั้นตอนสำคัญถัดไปคือการเพิ่มชุดประกอบแบบกระจาย การสร้างแบบกระจายมีลำดับความสำคัญสูงกว่าการสร้างแบบขนานตั้งแต่เวอร์ชัน 1.0 เนื่องจากเพิ่มมูลค่าให้กับ Werf: การปรับขนาดแนวตั้งของตัวสร้างและการสนับสนุนสำหรับตัวสร้างชั่วคราวในระบบ CI/CD ต่างๆ รวมถึงความสามารถในการให้การสนับสนุนอย่างเป็นทางการสำหรับ GitHub Actions . ดังนั้น กำหนดเวลาในการดำเนินการสำหรับแอสเซมบลีแบบคู่ขนานจึงถูกเลื่อนออกไป อย่างไรก็ตาม เรากำลังดำเนินการเพื่อนำความเป็นไปได้ทั้งสองไปใช้โดยเร็วที่สุด
ติดตามข่าว! และอย่าลืมแวะมาเยี่ยมชมเราได้ที่ เพื่อสร้างปัญหา ค้นหาปัญหาที่มีอยู่และเพิ่มข้อดี สร้างประชาสัมพันธ์ หรือเพียงแค่ดูการพัฒนาของโครงการ
PS
อ่านเพิ่มเติมในบล็อกของเรา:
- «»
- «";
- ชุดบันทึกย่อเกี่ยวกับนวัตกรรมใน WERF:
- «";
- «";
- «";
- «'
ที่มา: will.com