บทความ 11

ทำไม Production จึงใช้ Container และต้องวางอย่างไรให้ปลอดภัย

เริ่มจากความหมายของ Image, Container, Registry และ Orchestrator ก่อนอธิบายว่าความสม่ำเสมอ การแยกงาน การ Scale และการ Deploy ช่วย Production อย่างไร รวมทั้งข้อจำกัดและ Security ที่ห้ามมองข้าม

17 นาที Developer, DevOps, ผู้ดูแลระบบ และ Tech Lead 2026-07-17

Infographic ภาพรวม

Registryimage:v24

Container 01

Container 02

Container 03

Container 04

ปัญหาที่ Container แก้

ลองเริ่มจากเหตุการณ์ที่คนทำงานพบจริง

คำว่า “เครื่องผมรันได้” เกิดจากสภาพแวดล้อมไม่เหมือนกัน

โปรแกรมไม่ได้มีแค่ source code แต่พึ่ง runtime, system library, package, configuration และคำสั่งเริ่มทำงาน หากเครื่องนักพัฒนา เครื่องทดสอบ และ Production มีองค์ประกอบคนละเวอร์ชัน ผลก็อาจต่างกัน Container จึงบรรจุ application กับ dependency ที่จำเป็นเป็น Image เดียว แล้วเริ่มเป็น instance ที่เรียกว่า Container อย่างไรก็ตาม Container ไม่ได้ทำให้ระบบปลอดภัยหรือทนทานอัตโนมัติ ทีมยังต้องกำหนด network, secret, storage, resource limit, update และผู้รับผิดชอบให้ครบ

คำที่คุณจะเจอในบทความ

แต่ละคำหมายถึงอะไร และเกี่ยวข้องกับระบบตรงไหน

ไม่ต้องจำทั้งหมดในครั้งเดียว อ่านเพื่อให้รู้หน้าที่คร่าว ๆ ก่อน แล้วค่อยกลับมาเทียบเมื่อเจอคำนั้นในเนื้อหา

Image: แพ็กเกจแบบอ่านอย่างเดียวที่รวม application, runtime และ dependency พร้อม metadata วิธีเริ่มโปรแกรม
Container: process ที่รันจาก Image ภายใต้ขอบเขต filesystem, network และ resource ที่กำหนด
Registry: คลังเก็บและกระจาย Image เช่น Amazon ECR โดยควบคุมสิทธิ์และเก็บหลาย version ได้
Orchestrator: ระบบที่จัดวาง Container ตรวจสุขภาพ เพิ่มลดจำนวน และแทน instance ที่เสีย เช่น ECS หรือ Kubernetes
Immutable: แนวคิดไม่แก้ไฟล์ใน Image ที่ Deploy แล้ว แต่สร้าง Image version ใหม่เพื่อให้ตรวจสอบและย้อนกลับได้
Volume: พื้นที่จัดเก็บที่แยกจากอายุ Container ใช้กับข้อมูลที่ต้องอยู่ต่อหลัง Container ถูกแทน
Health Check: การตรวจว่า instance พร้อมรับงานจริง ไม่ใช่เพียง process ยังไม่หยุด
Resource Limit: เพดาน CPU/Memory ที่ป้องกัน Container หนึ่งใช้ทรัพยากรจนกระทบงานอื่น

ถ้าคุณไม่ได้ทำงานสายเทคนิค ให้เริ่มจากส่วนนี้

ทำไม Production จึงใช้ Container และต้องวางอย่างไรให้ปลอดภัย

Image คือแม่แบบที่เปลี่ยนไม่ได้ ส่วน Container คือ instance ที่กำลังรันจาก Image

Container ช่วยให้ build ครั้งเดียวและนำ artifact เดิมผ่าน Test ไป Production ลดความต่างระหว่างสภาพแวดล้อม

Container แชร์ Kernel ของเครื่อง host จึงเบากว่า VM แต่ไม่ใช่ขอบเขตความปลอดภัยที่สมบูรณ์แบบ

Production ต้องมี Registry, image scanning, non-root user, resource limit, health check, secret management และ orchestrator ที่เหมาะกับขนาดงาน

ภาพขยายความแบบเคลื่อนไหว

ดูความสัมพันธ์ของแต่ละขั้น ก่อนลงรายละเอียด

เลือกแต่ละขั้นเพื่อดูว่าเกิดอะไรขึ้น ต้องตรวจข้อมูลใด และผลจากขั้นหนึ่งส่งต่อไปยังขั้นถัดไปอย่างไร

ขั้น 01 / 05

01 / เข้าใจหน่วยทำงาน

Container ไม่ใช่เครื่องเสมือนขนาดเล็ก แต่เป็น process ที่ถูกแยกขอบเขต

VM จำลองเครื่องและมี operating system ของตัวเอง ส่วน Container ใช้ Kernel ร่วมกับ host แล้วอาศัย namespace แยกมุมมองของ process, filesystem และ network กับ cgroup ควบคุม resource จึงเริ่มเร็วและวางได้หนาแน่นกว่า แต่ช่องโหว่ใน Kernel หรือสิทธิ์ที่เปิดกว้างอาจกระทบขอบเขตได้ งานที่ต้องแยกความเสี่ยงสูงมากจึงอาจยังใช้ VM หรือ sandbox เพิ่มอีกชั้น ไม่ควรเลือกจากคำว่าใหม่กว่า แต่เลือกตาม threat model และรูปแบบการปฏิบัติงาน

รายละเอียดเชิงลึก

ค่อย ๆ ดูทีละส่วนว่าเกิดอะไรขึ้น และควรเตรียมอย่างไร

เราเริ่มจากผลที่คนใช้งานหรือธุรกิจจะพบ แล้วจึงอธิบายว่าทีมเทคนิคต้องตรวจอะไร มีตัวอย่างแบบไหน และจุดใดไม่ควรปล่อยให้เดาเอง

01 / เข้าใจหน่วยทำงาน

Container ไม่ใช่เครื่องเสมือนขนาดเล็ก แต่เป็น process ที่ถูกแยกขอบเขต

02 / Artifact เดียว

Build หนึ่งครั้ง ทดสอบ Image เดิม แล้ว Promote ไป Production

Pipeline ควรดึง source ที่ระบุ commit, สร้าง Image, รัน automated test, สแกนช่องโหว่, สร้าง SBOM และลงชื่อ artifact ก่อนเก็บใน Registry เมื่อต้อง Deploy ให้เลือก Image ด้วย digest ที่แก้ไม่ได้แทน tag ลอยอย่าง latest แล้ว Promote digest เดิมผ่าน environment การ build ใหม่สำหรับ Production แม้ใช้ source เดิมอาจดึง dependency ต่าง version และทำให้สิ่งที่ทดสอบไม่ใช่สิ่งที่เปิดใช้จริง

ใช้ base image ขนาดเล็กและมีเจ้าของ
ล็อก dependency version
เก็บ SBOM
สแกนทั้งตอน build และเมื่อพบ CVE ใหม่
มีนโยบายลบ Image ที่หมดอายุ

03 / ลดสิทธิ์

Image ที่สะอาดยังไม่พอ หากตอนรันเปิดสิทธิ์และ Network กว้างเกินไป

รันด้วย user ที่ไม่ใช่ root, ทำ filesystem เป็น read-only เมื่อทำได้, ตัด Linux capability ที่ไม่ใช้, ห้าม privileged mode, จำกัด egress ไปเฉพาะปลายทางจำเป็น และรับ Secret ผ่านระบบจัดการ Secret โดยไม่เขียนลง Image หรือ environment dump ที่ถูก log ได้ กำหนด CPU/Memory request และ limit เพื่อให้ orchestrator วางงานถูกและหยุดเหตุ memory leak ไม่ให้ลาม พร้อม patch host และ runtime เพราะ Container ไม่ได้แทนการดูแลระบบพื้นฐาน

ถ้าคุณเป็นคนออกแบบหรือดูแลระบบ

กำหนด policy เป็น code และบังคับใน CI/CD หรือ admission control เพื่อไม่ให้การ review ด้วยคนเป็นแนวป้องกันเพียงชั้นเดียว

04 / แยกข้อมูลออก

Container ควรถูกแทนได้ ข้อมูลสำคัญจึงต้องอยู่นอกอายุของ Container

อย่าเก็บไฟล์ผู้ใช้หรือฐานข้อมูลสำคัญไว้ใน writable layer เพราะข้อมูลจะหายเมื่อ instance ถูกแทน ใช้ managed database, object storage หรือ volume ที่มี backup ตามชนิดข้อมูล แยก subnet และ security group ให้ application ติดต่อเฉพาะ database/queue ที่ต้องใช้ ไม่ publish port ภายในทั้งหมดสู่อินเทอร์เน็ต และใช้ TLS ระหว่าง service เมื่อความเสี่ยงต้องการ การตั้งชื่อ service และ discovery ควรคงที่แม้ instance เปลี่ยน IP

05 / เลือกระดับที่เหมาะ

Docker Compose, ECS และ Kubernetes แก้ปัญหาคนละระดับ

Compose เหมาะกับ local development, test environment หรือระบบเล็กที่ยอมรับการดูแลเครื่องเดียวได้ ECS/Fargate ลดงานดูแล control plane และเหมาะกับทีมที่ต้องการ container orchestration บน AWS โดยไม่สร้าง platform ซับซ้อน Kubernetes ให้ความยืดหยุ่นและ ecosystem สูงแต่มีต้นทุนด้านความรู้ ความปลอดภัย การ upgrade และการแก้ incident ไม่ควรเลือก Kubernetes เพียงเพื่อให้ดูเป็นมาตรฐาน หากทีมยังไม่มีคนรับผิดชอบ platform การใช้ managed service ที่ง่ายกว่ามักปลอดภัยและคุมต้นทุนได้ดีกว่า

ก่อนนำไปใช้ ลองตรวจทีละข้อนี้

ใช้ maintained minimal base image

รันเป็น non-root

ล็อก Image ด้วย digest

สแกน CVE และสร้าง SBOM

ไม่ฝัง Secret ใน Image

ตั้ง CPU/Memory limit

กำหนด readiness/liveness check

เก็บข้อมูลถาวรนอก Container

จำกัด ingress/egress

ทดสอบ rolling deploy และ rollback

แหล่งอ้างอิง