คอนเทนเนอร์
Docker: เอนจินคอนเทนเนอร์ที่ทุกตัวอื่นลอกแบบ
Docker ทำให้คอนเทนเนอร์กลายเป็นภาษาพูดทั่วไป: image, registry และ CLI ที่เปลี่ยนคำพูดว่า 'มันรันได้บนเครื่องผม' ให้เป็นคำถามเรื่องการแพ็กเกจ มันยังเป็นเอนจินเริ่มต้นบนงานโฮสติ้งส่วนใหญ่ และพื้นผิวการดำเนินงานของมัน ทั้งสุขอนามัยของ image ความปลอดภัยของ daemon และเวิร์กโฟลว์ Compose เป็นตัวตัดสินว่าคอนเทนเนอร์จะลดความเสี่ยงเชิงปฏิบัติการหรือแค่จัดรูปแบบมันใหม่
ประเด็นสำคัญ
- โมเดลในหัวคือ image บวก layer: ทุก image คือกอง layer ที่แคชไว้ ทุกคำสั่งใน Dockerfile สร้างหนึ่ง layer และลำดับการ build ควบคุมการโดนแคช multi-stage build ทำให้ image สุดท้ายเล็ก (เครื่องมือ build ไม่ถูกส่งขึ้นโปรดักชัน) และแคชของ layer คืองบความเร็วในการ build ของคุณ
- daemon คือพื้นผิวที่ได้รับสิทธิ์สูง: daemon ของ Docker ที่รันเป็น root พร้อม API socket เทียบเท่า root บนโฮสต์ ถ้าส่ง socket เข้าไปในคอนเทนเนอร์ (การผูก -v /var/run/docker.sock แบบคลาสสิก) ก็เท่ากับยกเครื่องทั้งเครื่องให้ไปแล้ว แนวทางปี 2026 คือ rootless mode, user namespace และการตรวจสอบ socket ไม่ใช่ความเคยชิน
- Compose คือมาตรฐานของงานขนาดเล็ก: สแตกหลายบริการที่ประกาศเป็นโค้ดทั้ง volume, network และ healthcheck งานโฮสติ้งส่วนใหญ่ไม่เคยต้องใช้เครื่องจักรของ orchestrator และวินัยของ Compose (ประกาศ dependency ให้ชัด, health check, นโยบาย restart) คือสิ่งที่ทำให้ระบบเล็กนิ่ง
- การกำกับทรัพยากรย้ายไปที่ cgroup: การจำกัดหน่วยความจำและเพดาน CPU ต่อคอนเทนเนอร์เป็นเรื่องบังคับบนโฮสต์ที่ใช้ร่วมกัน (ไม่อย่างนั้น build ที่รั่วครั้งเดียวหรือ cron ที่หลุดการควบคุมก็กินโฮสต์ทั้งเครื่อง) log โดยปริยายกลายเป็นไฟล์ JSON ขนาดมหึมาถ้าไม่ตั้ง rotation ซึ่งคือเหตุการณ์ดิสก์เต็มแบบคลาสสิก
- สุขอนามัยของ image คือสุขอนามัยของซัพพลายเชน: สแกน CVE (เครื่องมือระดับ Trivy บทความเฉพาะของเราครอบคลุมเรื่องนี้) ปัก digest แทน tag ที่เปลี่ยนได้ ความลับไม่ถูกอบลงใน layer (build arg รั่ว ส่วน mount ไม่รั่ว) และ registry ส่วนตัวที่ตรวจสอบลายเซ็นในที่ที่ฝ่ายจัดซื้อให้ความสำคัญ
- ขีดจำกัดที่ต้องยอมรับ: Docker Swarm ยังมีอยู่ แต่โมเมนตัมของอุตสาหกรรมอยู่ข้าง Kubernetes (ดูบทความเฉพาะของเรา) และ registry, storage driver กับโมเดลเครือข่ายต่างก็เพิ่มพื้นผิวการเรียนรู้ จุดที่ลงตัวสำหรับธุรกิจโฮสติ้งยังคือสแตกที่จัดการด้วย Compose บนโฮสต์ไม่กี่เครื่องที่เฝ้าดูอย่างดี
บันทึกจากหน้างาน
เหตุการณ์บนโฮสต์ Docker ที่ทำให้เราตั้งกฎเรื่องเพดานทรัพยากร: คอนเทนเนอร์ build หนึ่งตัวที่ไม่จำกัดอะไรเลยกินหน่วยความจำของโฮสต์จนหมดและพาเอาฐานข้อมูลที่วางอยู่ข้าง ๆ ล่มไปด้วย ทุกอย่างได้ลิมิตในสัปดาห์นั้น และวินัยนี้อยู่รอดผ่าน build ที่หลุดการควบคุมมาอีกสามครั้งโดยไม่มีใครต้องถูกปลุก
คำถามที่พบบ่อย
Docker ตายแล้วหรือเพราะมี Podman
ไม่ Docker ยังเป็นเอนจินเริ่มต้นที่แทบทุกคนรองรับ และ Podman ตั้งใจเลียนแบบ CLI อย่างชัดเจน ทางเลือกจึงอยู่ที่ปรัชญาความปลอดภัยแบบมี daemon กับไม่มี และระบบปฏิบัติการที่ใช้ (RHEL มาพร้อม Podman ส่วนระบบนิเวศ Ubuntu มักยังใช้ Docker) ทั้งสองแบบอยู่ในบทความ docker-vs-podman ของเรา
ห้าก้าวความปลอดภัยแรกบนโฮสต์ Docker คืออะไร
โหมด rootless หรือ userns-remap ไม่ผูก socket เข้าไปในคอนเทนเนอร์ จำกัดทรัพยากรทุกที่ สแกน image อัตโนมัติใน CI และตั้ง log rotation ก่อนเหตุดิสก์เต็มครั้งแรกจะเกิด
คอนเทนเนอร์ทำให้ไม่ต้องแพตช์โฮสต์หรือ
ไม่เลยเด็ดขาด: เคอร์เนลของโฮสต์ เอนจิน และสแตกที่เก็บข้อมูลยังต้องแพตช์ คอนเทนเนอร์แค่ย้ายจังหวะการแพตช์ของชั้นแอปไปที่การ rebuild image ซึ่งเป็นกำไรด้านวินัยก็ต่อเมื่อมีอะไรมาทริกเกอร์ให้ rebuild จริง (นิสัยเรื่องประตู CI ของคอนเทนเนอร์ของเรา)
Docker เกินความจำเป็นเมื่อไร
สำหรับเครื่องที่มีบริการเดียวและรันไทม์เดียว (เซิร์ฟเวอร์ PostgreSQL ตัวเดียว โฮสต์ WordPress ตัวเดียว) การติดตั้งแบบเนทีฟที่แพตช์ดีมีพื้นผิวน้อยกว่าและเฝ้าดูง่ายกว่า คอนเทนเนอร์คุ้มค่าเมื่อความพกพาของ image หรือการแยกบริการหลายอย่างเป็นตัวรับภาระ
Kinetikatech ช่วยเรื่อง คอนเทนเนอร์ ได้อย่างไร
เราเคยรับเรื่องแบบนี้มาเป็นร้อยครั้ง: การจัดการ การประสานงาน และความปลอดภัยของคอนเทนเนอร์ในสภาพแวดล้อมโปรดักชัน กับ การจัดการเซิร์ฟเวอร์และความปลอดภัยเซิร์ฟเวอร์ Linux คุณได้วงจรครบ ตั้งแต่เราประเมิน ลงมือทำ เฝ้าดูตลอดเวลา และรับเรื่องภายใน 30 นาทีเมื่อจำเป็น