[บันทึกความเข้าใจ] การนำ Docker Image ไปใช้อย่างมั่นใจ

ในปัจจุบันเมื่อผมต้องการจะ Deploy ตัว Software ของผมที่ทำเสร็จพร้อมกับทดสอบเรียบร้อยแล้ว ผมก็แค่เข้า Docker ที่เครื่องที่ผมต้องการจะ Deploy จากนั้นก็ทำการ Pull Image ที่เราต้องการลงมาแล้วทำการเรียกใช้งาน สั้น ๆ ง่าย ๆ แต่ภายใต้ความเรียบง่ายนี้ ผมจะมาเล่าเกี่ยวกับเทคนิคที่จะช่วยลดข้อผิดพลาดในการใช้งาน Docker Image ครับ

ควรระบุเลข Version ของ Dependency แต่ละตัวไว้ใน Dockerfile ด้วย

เราเคยได้ยินปัญหาเกี่ยวกับโปรแกรมเมอร์ที่บอกว่า
“โปรแกรมมันทำงานเครื่องผมได้ ไม่รูู้ทำไมพอลง Production แล้วใช้งานไม่ได้”
ปัญหาตรงนี้ อาจเกิดขึ้นได้จากการที่ Dependency ของ Software เรา Version ไม่ถูกต้อง เช่น
เราทดสอบบน Python 2.x แต่ตอน Deploy ทำบน Python 3.x
เราเขียนโค้ดและทดสอบผ่านทุกอย่างบน Windows แต่ต้องไป Deploy บน Ubuntu
ปัญหาเหล่านี้อาจเกิดขึ้นได้ และใช้เวลานานในการแก้ไข เมื่อใช้ Dockerfile เราก็ควรจะระบุ Version ของของที่เราต้องการไปไว้เลย ซึ่งจะทำให้มั่นใจได้ว่าจะไม่เกิดข้อผิดพลาดจากความต่างของ Version

**ตัวอย่างที่ไม่ดี** ของ Dockerfile โดยหากไม่ระบุ Tag/Version จะทำการใช้ตัวล่าสุดเสมอ

ใช้ Docker Image เดียวกันในการนำไป Deploy ทุก ๆ Environment

**ตัวอย่างที่ไม่ดี** การสร้าง Image ใหม่ทุกครั้งเมื่อต้องการนำไป Deploy ที่ต่าง ๆ

สืบมาจากข้อด้านบนนะครับ หากเราไม่ได้มีการระบุเลข Tag/Version ใน Dockerfile ไว้ ไฟล์ Image ที่เราได้ออกมาอาจจะต่างไปจากเดิม ยกตัวอย่างเช่น
Base Image ที่ Build ครั้งแรกใน Development -> เราได้ Ubuntu 18.01
Base Image ที่ Build ครั้งต่อมาใน Testing -> เวอร์ชั่น Ubuntu มีการอัพเดทกลายเป็น 18.04 (Latest)

เมื่อเกิดกาดเปลี่ยนแปลงเราจะมั่นใจได้อย่างไรว่า การเปลี่ยนแปลงนั้นไม่ส่งผลกับ Software ของเรา ? ทุกการเปลี่ยนแปลงต้องมีการทดสอบ

โดยวิธีที่แนะนำสำหรับวิธีนี้คือ เปลี่ยนจากการ Rebuild มาเป็นการ Promote แทน
เราใช้ Image เดียวกันทั้งใช้นำไปทดสอบแบบต่าง ๆ ใน Pipeline ของเรา และเมื่อผ่านการทดสอบในขั้นตอนนั้น ก็จะทำการ Promote Image ชิ้นนั้นว่าผ่าน และพร้อมนำไปทดสอบในขั้นตอนต่อไป อย่างนี้ไปจนหมดกระบวนการใน Pipeline ของเรา โดยเราจะมองว่า Docker Image เป็น Release Candidate และเมื่อเราต้องการนำ Image ไป Deploy ก็แค่เพียงนำ Image ที่ถูก Promote แล้วว่าผ่านทุกขั้นตอนในการทดสอบแล้ว ไปขึ้น Production ซึ่งในกระบวนการนี้ขึ้นอยู่ว่า Pipeline ของเราว่าเป็นอย่างไร

ตัวอย่าง Release Candidates บน CI Machine แสดงว่ามี Artifact ไหนที่ผ่านการทดสอบใดบ้าง

ซึ่งในข้อนี้ทุกอย่างสามารถทำให้เป็น Automation ได้นะครับ โดยอาศัยเครื่องมือพวก Continuous Integration จัดการ Process ภายใต้ Pipeline ของเรา