Docker คืออะไร และเหตุใดทีมพัฒนาจึงใช้ Container
Container แพ็กแอปกับสิ่งที่ต้องใช้เพื่อรันสม่ำเสมอขึ้น แต่ยังต้องจัดการข้อมูล Secret และการดูแลเครื่องปลายทาง
Docker เป็นเครื่องมือสร้าง แจกจ่าย และรัน Container ซึ่งเป็นกระบวนการที่แยกสภาพแวดล้อมและพึ่งพาไฟล์จาก Image ที่กำหนดไว้ ช่วยลดปัญหา “เครื่องฉันรันได้” เมื่อทีมและ CI ใช้เวอร์ชัน Runtime ต่างกัน แต่ Container ไม่ใช่เครื่องเสมือนเต็มรูปแบบและไม่ได้ทำให้ระบบปลอดภัยโดยอัตโนมัติ
Image กับ Container ต่างกัน
Image คือชุดไฟล์และการตั้งค่าสำหรับสร้างการรัน ส่วน Container คือ Instance ที่กำลังหรือเคยรันจาก Image หนึ่ง การเปลี่ยนโค้ดแล้วสร้าง Image ใหม่ช่วยให้รู้ว่า deploy ชุดใด แต่ข้อมูลที่ต้องอยู่ถาวร เช่น ฐานข้อมูล ไม่ควรพึ่งไฟล์ภายใน Container ที่ลบแล้วหาย ต้องวาง Storage และ Backup แยก
ภาพที่ 1: Image ช่วยให้ชุดโปรแกรมที่ใช้รันชัด แต่ข้อมูลและ Secret ยังต้องดูแลแยก
ตัวอย่างสมมติ: เว็บและ API
ทีมมี Frontend, API และฐานข้อมูล แยก Container เพื่อเริ่มระบบทดสอบได้ด้วยเวอร์ชันที่กำหนด เมื่อย้ายไป Server จริงยังต้องตั้งค่าการเชื่อม เครือข่าย Secret และข้อมูลถาวรให้ถูก การรัน Image เดียวกันไม่รับประกันพฤติกรรมเหมือนกันหากตัวแปรสภาพแวดล้อมหรือข้อมูลต่างกัน
เมื่อไรคุ้มค่า
Container มีประโยชน์เมื่อหลายคนต้องรัน Dependency เดียวกันหรือ Pipeline ต้อง Build/Deploy ซ้ำได้ หากโครงการเป็นเว็บ Static ง่าย ๆ ที่แพลตฟอร์มรับ source โดยตรงอยู่แล้ว การเพิ่ม Docker อาจไม่ช่วยงานหลัก ควรเลือกจากปัญหาการส่งต่อและการเปิดใช้ที่มีจริง
สำหรับรายงาน
วาด Image, Container, Volume และเครือข่ายที่จำเป็น ระบุสิ่งที่อยู่ใน Image กับสิ่งที่ส่งตอนรัน เช่น Secret อย่าใส่รหัสผ่านใน Dockerfile และอย่าอ้างว่า Container แยกความปลอดภัยเทียบเท่า VM โดยไม่ตรวจข้อจำกัด
อ่าน CI/CD และ สภาพแวดล้อม Dev, Staging, Production หรือดู บริการ Web Application
วิเคราะห์กรณีศึกษาเพื่อนำไปเขียนรายงาน
ลองกำหนดกรณีศึกษาเป็น แอปรันได้บนเครื่องผู้พัฒนาแต่พังบน Staging และเขียนขอบเขตให้ชัดว่ามีผู้ใช้กลุ่มใด ข้อมูลใดเข้าสู่ระบบ และต้องการผลลัพธ์อะไร เริ่มจากสภาพก่อนพัฒนา แล้วอธิบายการตัดสินใจที่บทความนี้เกี่ยวข้องโดยใช้ตัวอย่างข้อมูลหรือเหตุการณ์ที่สมมติขึ้นอย่างระบุว่าเป็นตัวอย่าง การกำหนดขอบเขตเช่นนี้ช่วยให้ผู้อ่านแยกหลักการทั่วไปออกจากข้อเท็จจริงของโครงการได้
หลักฐานที่ควรแสดงคือ Dockerfile, Image, Container, environment และ volume ที่ใช้ ควรอธิบายสัญลักษณ์ คำย่อ หรือเงื่อนไขในหลักฐานนั้นให้ผู้อ่านที่ไม่อยู่ในทีมเข้าใจ และบอกว่ามันเชื่อมกับ Requirement ข้อใด ถ้ามีหลายทางเลือก ให้ระบุเหตุผลที่เลือกทางหนึ่งและผลกระทบต่อผู้ใช้ ทีมพัฒนา หรือผู้ดูแลระบบ แทนการเขียนเพียงว่าใช้แนวทางที่ “ดีที่สุด” โดยไม่มีเกณฑ์เปรียบเทียบ
เกณฑ์ประเมินตัวอย่างคือ Image เดียวกันทำงานสม่ำเสมอในสภาพแวดล้อมที่กำหนด ส่วนข้อจำกัดที่ต้องระบุคือ Container ไม่ใช่ VM และไม่ทำให้ข้อมูลในเครื่องอยู่ถาวรเอง หากยังไม่ได้ทดลองกับผู้ใช้หรือข้อมูลจริง ให้เขียนว่าเป็นข้อเสนอเชิงออกแบบ ไม่สรุปเป็นผลที่พิสูจน์แล้ว การมีทั้งเกณฑ์และข้อจำกัดช่วยให้รายงานตรวจสอบเหตุผลได้ และเปิดทางให้ผู้อื่นนำกรณีเดียวกันไปทดสอบซ้ำในบริบทของตน
แหล่งข้อมูลประกอบ
- Docker Docs: What is a container? — หลักการ Container
- Docker Docs: What is an image? — ความต่าง Image กับ Container