เวลาเขียนไฟล์ deploy ด้วยชื่ออิมเมจลงท้าย latest เราอ่านได้ง่ายว่าตั้งใจใช้ของใหม่ แต่พอต้องย้อนดูว่าระบบเมื่อวานรันชิ้นงานใด คำว่าใหม่ล่าสุดก็เริ่มตอบได้ไม่ครบ เพราะ tag เดิมอาจถูกย้ายไปชี้อิมเมจอีกชุดแล้ว
ยิ่งมีหลาย environment หรือมีการเริ่ม replica ใหม่ต่างเวลากัน การมีข้อความ image เดียวกันในไฟล์ตั้งค่าอาจยังไม่พอจะยืนยันว่าทุกตัวใช้ bytes ชุดเดียวกันครับ จึงควรมีตัวระบุที่ตามกลับไปถึงผลบิ้วจริง
การแยก tag, digest และบันทึก release จะช่วยให้เลือกทางอ้างอิงที่อ่านรู้เรื่อง พร้อมหลักฐานที่ใช้ตรวจว่าแต่ละระบบได้รับสิ่งใดไปแล้ว
ใน registry ทั่วไป tag สามารถถูกชี้ไปอิมเมจใหม่ได้ ไม่ใช่เฉพาะคำว่า latest ชื่ออย่าง v1.2.3 ก็ไม่ได้กลายเป็น immutable เพียงเพราะหน้าตาเหมือนหมายเลขรุ่น หากระบบยังอนุญาตให้ push ทับชื่อเดิมอยู่
เมื่อทีมบอกว่า release tag ห้ามเปลี่ยน ก็ควรมีวิธีบังคับตามที่ registry รองรับ เช่น นโยบาย tag immutability ไม่พึ่งความจำคน push ทุกครั้ง ส่วน tag ที่ตั้งใจให้เคลื่อนตาม channel ก็ควรถูกเรียกตามหน้าที่นั้นอย่างชัดเจน
Harbor มีตัวเลือกกำหนดกฎ immutability ในระดับโครงการ ซึ่งต้องเลือก pattern และอ่านผลต่อการจัดการ artifact ตามรุ่นที่ใช้ หากตั้งกว้างเกินก็อาจทำให้งานทดลองติดข้อจำกัดที่ไม่ได้ตั้งใจ จึงควรแยก release กับ tag ระหว่างทางตามนโยบายจริง
ตัวชื่อที่อ่านง่ายยังมีประโยชน์สำหรับคน แต่เมื่ออยากรู้ว่าชื่อหนึ่งชี้ไปอะไร ณ เวลาปล่อยงาน ต้องเก็บค่าที่ resolve ได้ในรอบนั้นด้วย ไม่ย้อนอ่าน tag วันนี้แล้วถือว่าเป็นคำตอบเดียวกับเมื่อวานโดยอัตโนมัติ
Digest เป็นตัวระบุแบบ hash ของ object ที่อ้างในระบบอิมเมจ เมื่อเนื้อหาที่เกี่ยวข้องเปลี่ยน ตัวระบุย่อมต่างไป จึงใช้เลือกอิมเมจตาม digest แทนการรอให้ชื่อ tag เคลื่อนไปหาของใหม่ในครั้งที่ pull ได้
รูปแบบอ้างอิงอาจเห็นเป็น registry.example.com/team/web@sha256:... โดยต้องใช้ digest เต็มจริงจาก registry ไม่ใช่ข้อความย่อในตัวอย่าง การดูค่าเพียงไม่กี่ตัวช่วยอ่านบันทึก แต่ขั้นใช้จริงควรตรวจตัวระบุครบตามรูปแบบ
Digest ช่วยเรื่องเลือกเนื้อหา ไม่ได้รับรองด้วยตัวเองว่าใครเป็นคนบิ้ว โค้ดปลอดภัย หรือมาจากแหล่งที่ทีมอนุญาต งานยืนยันแหล่งที่มากับสิทธิ์เผยแพร่ยังเป็นอีกส่วนที่ต้องดู ไม่เปลี่ยนคำว่า hash ให้กลายเป็นคำรับรองความน่าเชื่อถือทั้งหมด
หากใช้ multi-platform image ควรรู้ว่ากำลังบันทึก digest ของ index หรือ manifest ของ platform ใด เครื่องคนละ architecture อาจเลือก artifact ย่อยต่างกันภายใต้ชุดหลาย platform จึงควรเก็บบริบทของระบบที่ตรวจด้วย
บันทึก release ควรตอบได้ว่า source commit ใดผ่าน pipeline ใดแล้วได้ image digest อะไร จากนั้น environment ใดเลือกชิ้นงานนั้นพร้อม config รุ่นใด ไม่ใช้หมายเลข commit เป็นตัวแทนทุกอย่างที่เกิดขึ้นระหว่าง build
โค้ด commit เดียวอาจบิ้วต่างผลได้หาก dependency หรือ base image ที่อ้างเปลี่ยน รวมถึงค่าที่นำไปฝังระหว่าง build จึงควรเก็บข้อมูลที่จำเป็นต่อการตามที่มา ไม่คาดว่าการบิ้วซ้ำทีหลังต้องได้ digest เดิมเสมอเมื่อยังไม่ได้ออกแบบ reproducible build
ส่วน config ควรมีตัวระบุรุ่นหรือ revision ที่ตามได้โดยไม่เผยค่าลับ เช่น revision ของแหล่งตั้งค่าที่ใช้ ไม่คัด secret ทั้งชุดลง release note เพียงเพื่อทำให้บันทึกครบ เพราะงานตรวจที่มาไม่ได้ต้องให้ทุกคนอ่านความลับทั้งหมด
เมื่อส่งต่อจาก UAT ไป prod หากเป้าหมายคือใช้ชิ้นงานเดียวกับที่ทดสอบ ก็ควรส่ง digest เดิมตามแผน ไม่บิ้วใหม่แบบไม่จดเหตุแล้วเรียกว่าของเดิมเพียงเพราะใช้ commit เดียวกันอีกครั้ง
ไฟล์ deploy บอกสิ่งที่ตั้งใจให้ระบบเลือก ส่วน runtime มีข้อมูลของ container หรือ workload ที่เริ่มทำงานแล้ว ควรตรวจทั้งสองอย่าง โดยเฉพาะช่วง rollout ที่อาจมีของเก่าและใหม่อยู่ร่วมกันตามกลยุทธ์การปล่อย
ถ้าใช้ tag ที่เคลื่อนได้ ต้องดูนโยบาย pull กับ cache ของ runtime ประกอบ เพราะการตั้งข้อความ image เดิมไม่ได้ทำให้ทุก container ที่รันอยู่เปลี่ยนเนื้อหาเองในทันที และการเริ่มใหม่อาจเกิดต่างจังหวะกัน
การมีข้อมูลรุ่นในหน้าสถานะที่ไม่เปิดความลับช่วยให้ทีมตรวจจากการใช้งานได้ง่ายขึ้น แต่ยังต้องสัมพันธ์กับหลักฐานฝั่ง deploy ไม่สร้างข้อความเวอร์ชันคงที่ซึ่งถูกคัดลงทุก image แล้วคาดว่าจะบอกของจริงได้ตลอด
ระหว่างตรวจควรเลือกขอบเขตให้ครบ replica ที่เกี่ยวข้อง ไม่ดู instance เดียวแล้วสรุปว่าทั้ง environment รับรุ่นใหม่หมดแล้ว เพราะความต่างนี้มีผลเวลาตามอาการที่เกิดเฉพาะบางคำขอ
ถ้า registry cleanup ลบ artifact ที่ต้องใช้ไป การมี digest ในบันทึกอย่างเดียวก็ไม่ได้ทำให้ดึง bytes กลับมาได้ ควรกำหนด retention ให้สอดคล้องกับระยะที่ต้องตรวจและย้อนระบบ ไม่แยกงานล้างพื้นที่ออกจากแผน release โดยไม่ประสานความหมาย
การ rollback ยังต้องดูความเข้ากันของข้อมูลกับ config ด้วย อิมเมจเก่าอาจไม่เข้าใจ schema ที่เพิ่งย้ายไป การระบุชิ้นงานได้แน่นช่วยเลือกของถูก แต่ไม่ได้ย้อนผลข้างเคียงทุกประเภทที่เกิดตอนรุ่นใหม่ทำงานแล้ว
จึงควรมีบันทึกสิ่งที่เปลี่ยนพร้อมเงื่อนไขกลับ ไม่ใช่เพียงคำสั่งสลับ tag และเมื่อทดสอบทางกลับก็จดสิ่งที่ตรวจจริง ไม่ประกาศว่ากลับรุ่นใดก็ได้จากการมีอิมเมจอยู่ในรายการเท่านั้น
การตามรุ่นที่ระบบรันควรใช้ชื่อ tag ที่มีนโยบายชัดร่วมกับ digest และบันทึกจาก source ถึง deploy ตรวจทั้งสิ่งที่ตั้งใจกับ workload ที่ทำงานจริง พร้อมเก็บ artifact และเงื่อนไขกลับให้สัมพันธ์กับข้อมูล เมื่อแต่ละ environment มีที่มาที่ตรวจได้ เราจะตอบคำถามเรื่องเวอร์ชันได้มากกว่าคำว่า latest หรือหมายเลขที่อาจถูกชี้ทับไปแล้วครับ