จัดการ Docker Containers — Mac เบา VM รับหนัก

เราเล่าจากการทดลองจริงในแล็บ ไม่ใช่ทฤษฎี — และให้หลักฐานพูดแทน

จุดเจ็บ: เครื่องมือดี ๆ มีเยอะ แต่ตั้งค่าครั้งแรกยาก คนส่วนใหญ่ติดตรงเริ่มไม่ถูก

เดิมพัน: เสียเวลาเป็นวันกับการตั้งค่าผิด ๆ ทั้งที่ทำให้ถูกตั้งแต่แรกได้

สิ่งที่เราทำในแล็บ: 36 Docker Containers รันบน Mac ค้างหนัก → แบ่ง 2 กลุ่ม (Back Office ย้าย VM / Dev เก็บบน Mac) เชื่อมด้วย SSH Tunnel ไม่ต้องแก้โค้ด ตั้งค่า 30 นาที

Behind the Scenes

จัดการ Docker Containers — จาก 36 ตัวบน Mac ย้ายเหลือ 5 ด้วย SSH Tunnel

36 Containers บน Mac ค้างหนัก → แบ่ง 2 กลุ่ม ย้ายไป VM — Mac กลับมาเร็วใน 30 นาที

อัปเดตล่าสุด: 2026-04-05

Containers ที่รันบน Mac

กลุ่มที่ต้องแบ่ง

SSH Tunnel เชื่อมทุกอย่าง

นาทีตั้งค่าเสร็จ

สรุปสั้นๆ — อ่านแค่นี้ก็เข้าใจ

Mac ค้างเพราะรัน Docker containers 36 ตัวพร้อมกัน — ทั้งที่มี VM (เครื่องเสมือน) RAM 40GB ว่างอยู่
แบ่ง container 2 กลุ่ม: Back Office (database, cache, monitoring → ย้ายไป VM) vs Dev (app ที่กำลังเขียน → เก็บบน Mac)
ใช้ SSH Tunnel (ท่อเชื่อมระหว่างเครื่อง) เชื่อม Mac กับ VM — app ไม่ต้องแก้โค้ดเลย ยังใช้ localhost เหมือนเดิม
3 แนวทาง: ปิดชั่วคราว (ง่ายสุด) / ย้ายไป VM + Tunnel (แนะนำ) / ทำทุกอย่างบน VM (Pro)

Mac เครื่องแรง พัดลมหมุนไม่หยุด RAM ใช้จนเกือบหมด — ทั้งที่ไม่ได้เปิดอะไรนอกจาก VSCode กับ Chrome

เช็คดู: Docker containers (กล่องที่ห่อ software ให้รันแยกกัน) ทำงานอยู่ 36 ตัวพร้อมกัน — Database 4 ตัว, Cache 2 ตัว, Monitoring 5 ตัว, Reverse Proxy 2 ตัว, App อีก 20+ ตัว ทุกอย่างรันบน Mac หมด

ทั้งที่มี VM (Virtual Machine — เครื่องเสมือนบน server) ที่มี RAM 40GB ว่างๆ อยู่ ไม่ได้ใช้งาน

ปัญหาไม่ใช่ว่า Mac ไม่แรง — แต่เอาพนักงาน 36 คนมานั่งโต๊ะตัวเดียว ทั้งที่มีห้องว่างอยู่

Mac รัน 36 Containers — ทำไมถึงค้าง?

Docker container แต่ละตัวกินทั้ง RAM, CPU และ Disk I/O พร้อมกัน — รัน 36 ตัว = Mac ต้องทำงานหนักตลอดเวลา แม้จะไม่ได้ใช้งาน container นั้นอยู่ก็ตาม

ลองนึกภาพแบบนี้:

💻

Mac

= โต๊ะทำงาน (พื้นที่จำกัด)

🏢

VM (เครื่องเสมือน)

= ห้อง server (RAM 40GB)

👷

Container

= พนักงาน ทำงานคนละอย่าง

ตอนนี้เอาพนักงาน 36 คนมานั่งทำงานบนโต๊ะตัวเดียว (Mac) — มันก็แน่นและค้างเป็นธรรมดา ทั้งที่มีห้อง server (VM) ว่างๆ รอใช้งานอยู่

Container ที่ไม่ได้แก้โค้ดทุกวัน ไม่จำเป็นต้องรันบน Mac — ย้ายไปอยู่ VM ก็ทำงานเหมือนกันทุกประการ

Container ควรแบ่งยังไง — Back Office vs Dev?

หลักการแบ่ง container ง่ายมาก: ถ้าไม่ได้เปิดโค้ดของมันใน VSCode → ไม่ต้องรันบน Mac ให้แบ่งออกเป็น 2 กลุ่ม

กลุ่ม 1: "พนักงาน Back Office" → ย้ายไป VM

พวกนี้ไม่ต้องอยู่บน Mac เพราะไม่ได้แก้โค้ดของมัน — แค่ต้อง "รันอยู่เฉยๆ" ให้บริการ

Container	ทำหน้าที่อะไร	ทำไมไม่ต้องอยู่บน Mac
PostgreSQL / MySQL	เก็บข้อมูล (Database)	แค่รับคำสั่ง ไม่ต้องแก้โค้ด
Redis / Dragonfly	Cache (ที่เก็บข้อมูลชั่วคราวให้เร็ว)	รันอยู่เฉยๆ ดูผ่าน browser ได้
Prometheus / Grafana	Monitoring (ดูสถานะระบบ)	ดูผ่าน browser ได้อยู่แล้ว
Portainer	จัดการ container ผ่าน web	ดูผ่าน browser เหมือนกัน
Nginx / Traefik	Reverse Proxy (จัดการ traffic เข้าออก)	รันบน server เหมาะกว่า

กลุ่ม 2: "พนักงานที่ต้องคุยด้วยตลอด" → เก็บบน Mac

พวกนี้คือ app ที่กำลังเขียนโค้ดอยู่ — ต้องอยู่ใกล้มือเพราะต้องแก้ → restart → ดูผลบ่อย

Container	ทำไมต้องอยู่บน Mac
App ที่กำลัง develop	ต้องแก้โค้ด → restart → ดูผลบ่อย
Frontend ที่กำลังทำ	ต้อง Hot Reload (อัปเดตหน้าจออัตโนมัติ) เร็ว

หลักการง่ายๆ: ถ้าไม่ได้เปิดโค้ดของมันใน VSCode → มันไม่ต้องรันบน Mac

Cursor Prompt: "ช่วยดู docker-compose.yml ของโปรเจกต์นี้ แล้วแยก services ออกเป็น 2 ไฟล์: docker-compose.infra.yml สำหรับ database, cache, monitoring ที่จะรันบน VM กับ docker-compose.dev.yml สำหรับ app ที่กำลังพัฒนา"

🔗

เชื่อม Mac กับ VM — SSH Tunnel ทำได้ง่ายกว่าที่คิด

ย้าย database ไป VM แล้ว app บน Mac ยังเรียกใช้ได้เหมือนเดิม ไม่ต้องแก้โค้ดสักบรรทัด

SSH Tunnel คืออะไร — ทำไมต้องรู้?

SSH Tunnel (ท่อเชื่อมเข้ารหัสระหว่าง 2 เครื่อง) แก้ปัญหาสำคัญ: ถ้าย้าย Database ไป VM แล้ว app บน Mac จะคุยกับ Database ยังไง?

คิดซะว่า SSH Tunnel เป็น "สายโทรศัพท์ภายใน" ระหว่าง Mac กับ VM — app บน Mac ยังพูดว่า "ติดต่อ Database ที่ localhost" เหมือนเดิม แต่จริงๆ สายโทรศัพท์วิ่งไปถึง VM อัตโนมัติ

ไม่มี Tunnel — app หา Database ไม่เจอ

💻

Mac (app)

── ✗ ──

🏢

VM (DB)

มี Tunnel — เชื่อมถึงกันอัตโนมัติ

💻

Mac

(app ที่ develop)

localhost:5432

══ SSH Tunnel ══▶

🏢

(Database + Infra)

:5432

SSH Tunnel = app ไม่ต้องรู้ด้วยซ้ำว่า Database อยู่คนละเครื่อง — ยังใช้ localhost เหมือนเดิม ไม่ต้องแก้โค้ดแม้แต่บรรทัดเดียว

ผลลัพธ์: app บน Mac ยังใช้ localhost:5432 เหมือนเดิม ไม่ต้องแก้ connection string (ที่อยู่สำหรับเชื่อมต่อ) เลย แต่จริงๆ ข้อมูลวิ่งไปถึง Database บน VM อัตโนมัติ

สร้าง SSH Tunnel ยังไง?

การสร้าง SSH Tunnel ใช้คำสั่งเดียว เปิดทางเชื่อม 3 services พร้อมกัน — ไม่ต้องติดตั้งอะไรเพิ่ม เพราะ Mac มี SSH มาให้อยู่แล้ว

คำสั่ง SSH Tunnel — เปิด 3 services พร้อมกัน

ssh -N -L 5432:localhost:5432 \
      -L 6381:localhost:6381 \
      -L 3000:localhost:3000 \
      myserver

ส่วน	ความหมาย
`-N`	บอกว่าไม่ต้องเปิด shell แค่เปิดทางเชื่อม
`-L 5432:localhost:5432`	port 5432 บน Mac → วิ่งไป port 5432 บน VM
`myserver`	SSH alias (ชื่อย่อ) ของ VM ที่ตั้งไว้ใน config

Tip: ตั้ง SSH alias ใน config file ครั้งเดียว แล้วใช้ชื่อสั้นๆ แทน IP address ได้ตลอด — สะดวกและปลอดภัยกว่าพิมพ์ IP ทุกครั้ง

Cursor Prompt: "ช่วยเขียน SSH config file สำหรับเชื่อม Mac กับ VM ที่มี PostgreSQL port 5432, Redis port 6381, Grafana port 3000 — ใช้ SSH Tunnel แบบ auto-reconnect ด้วย autossh พร้อม keepalive"

SSH Tunnel = คำสั่งเดียว ไม่ต้องติดตั้งอะไรเพิ่ม app ไม่ต้องแก้โค้ด — เปิดทางเชื่อมกี่ port ก็ได้พร้อมกัน

📊

จาก 36 Containers → เหลือแค่ 5 บน Mac

ลดจาก 36 ตัว เหลือแค่ตัวที่กำลัง develop จริงๆ — Mac กลับมาเร็วเหมือนเครื่องใหม่

36 Containers ของจริง — จัดการยังไง?

จาก 36 containers ที่ running อยู่บน Mac ลองใช้หลักการ "Back Office vs Dev" แบ่งออกเป็น 3 กลุ่มชัดเจน

ย้ายไป VM (~28 ตัว)

📦 infrastructure — monitoring, reverse proxy ต่างๆ

📦 database — PostgreSQL, MySQL, Redis, Dragonfly

📦 portainer — จัดการ container ผ่าน web

📦 background jobs — งานที่รันอัตโนมัติ เช่น email, cron

📦 staging apps — app ที่ไม่ได้ develop อยู่ตอนนี้

เก็บบน Mac (4-5 ตัว)

💻 app ที่กำลังแก้โค้ด — ต้อง restart ดูผลบ่อย

💻 frontend ที่กำลังทำ — ต้อง hot reload เร็ว

💻 docker-in-docker — ถ้าจำเป็นสำหรับ build

ปิดไปเลย (3-4 ตัว)

🔴 stopped containers — ปิดอยู่แล้ว ดีแล้ว ปล่อยไว้

🔴 โปรเจกต์เก่า — ไม่ได้ develop ไม่ต้อง run ไม่ต้องเปิด

จาก 36 containers → ย้ายไป VM ~28 ตัว + ปิดอีก 3-4 ตัว → เหลือบน Mac แค่ 4-5 ตัว — Mac เร็วขึ้นทันทีโดยไม่ต้องซื้อ RAM เพิ่ม

3 แนวทาง — เลือกแบบไหนดี?

การจัดการ Docker containers บน Mac มี 3 แนวทางหลัก — แต่ละแบบเหมาะกับสถานการณ์และระดับความพร้อมที่ต่างกัน

⭐

A: ปิด containers ที่ไม่ใช้

ความยาก: ง่ายมาก

ผลลัพธ์: Mac เร็วขึ้นทันที

ข้อเสีย: ต้องเปิด/ปิดเองทุกครั้ง

วิธีทำ: คลิก Stop ใน OrbStack

เหมาะกับ: แก้ปัญหาเฉพาะหน้า

⭐⭐⭐

B: ย้ายไป VM + SSH Tunnel

ความยาก: ตั้งค่าครั้งแรก ~30 นาที

ผลลัพธ์: Mac เบามาก + services ใช้ได้หมด

ข้อเสีย: ต้องเปิด tunnel ก่อนทำงาน

วิธีทำ: ย้าย docker-compose ไป VM + ตั้ง tunnel

เหมาะกับ: ใช้งานระยะยาว ✅ แนะนำ

⭐⭐⭐⭐

C: ทุกอย่างบน VM + Remote Dev

ความยาก: ต้องปรับ workflow ทั้งหมด

ผลลัพธ์: Mac แทบไม่โดนใช้เลย

ข้อเสีย: ต้องมี internet ตลอด มี latency บ้าง

วิธีทำ: VSCode Remote SSH เข้า VM

เหมาะกับ: คนที่มี server แรงๆ (RAM 40GB+)

แนะนำแนวทาง B สำหรับคนที่มี VM อยู่แล้ว — สมดุลระหว่างความง่ายกับผลลัพธ์ ตั้งค่าครั้งเดียวใช้ได้ตลอด

แนวทาง B: ขั้นตอนทำจริง

01แยก docker-compose เป็น 2 ไฟล์

แยก services ที่เป็น infra (database, cache, monitoring) ออกจาก dev — ให้ Cursor AI ช่วยแยกได้เลย ใช้เวลาไม่ถึง 5 นาที

02ส่ง infra compose ไป VM แล้วรัน

Copy docker-compose.infra.yml ไป VM แล้วสั่ง up — ให้ Cursor AI ช่วยเขียน deploy script ที่ sync ไฟล์อัตโนมัติ

03ตั้ง SSH Tunnel เชื่อม Mac กับ VM

เขียน SSH config + เปิด tunnel เชื่อม Mac กับ VM — คำสั่งเดียวเปิดทุก port ที่ต้องใช้ ไม่ต้องจำ IP

04ทดสอบ + ปิด containers เก่าบน Mac

ทดสอบว่า app บน Mac เรียก database ผ่าน tunnel ได้ปกติ → แล้วค่อยปิด containers เก่าบน Mac ทิ้ง ทีละตัวก็ได้ ไม่ต้องรีบ

⏱️

ระยะสั้น vs ระยะยาว — เริ่มได้เลยวันนี้

วันนี้: ปิด containers ที่ไม่ได้ใช้ให้เหลือ < 10 ตัว → สัปดาห์นี้: ย้าย infra ไป VM แบบถาวร

สรุปแผนระยะสั้น vs ระยะยาว

ระยะสั้น (วันนี้)	ระยะยาว (สัปดาห์นี้)
ปิด containers ที่ไม่ได้ใช้ ให้เหลือ < 10 ตัว	ย้าย DB + infra ไป VM ถาวร
Mac จะเร็วขึ้นทันที ไม่ต้องรอ	Mac เก็บแค่ app ที่กำลัง develop
ไม่ต้องตั้งค่าอะไร แค่คลิก Stop	ตั้งค่าครั้งเดียว ใช้ได้ตลอด

ข้อควรระวัง: ก่อนปิด container ตรวจสอบก่อนว่า app อื่นไม่ได้พึ่งพา container นั้นอยู่ — ถ้าปิด database แล้ว app ที่ต้องใช้จะ error ทันที ปิดทีละตัวแล้วทดสอบ

คำถามที่ถามบ่อย?

ย้าย Database ไป VM แล้ว performance ช้าลงไหม?

ถ้า VM อยู่บน network เดียวกัน (LAN) — latency (ความหน่วง) ต่ำมาก แทบไม่รู้สึกต่างจาก localhost สำหรับ development ไม่มีผลกระทบ ถ้า VM อยู่บน cloud อาจเพิ่ม 1-5ms ซึ่งยังน้อยมากสำหรับการ develop

SSH Tunnel หลุดบ่อยไหม — ต้องเปิดใหม่ทุกวันหรือเปล่า?

ใช้ autossh (ตัวช่วยที่ reconnect อัตโนมัติ) แทน SSH ธรรมดา — autossh จะเชื่อมต่อใหม่เองเมื่อ connection หลุด ตั้งค่าครั้งเดียว ไม่ต้องสนใจอีก ให้ Cursor AI ช่วยเขียน config ได้เลย

ใช้ OrbStack อยู่ ต้องเปลี่ยนเป็น Docker Desktop ไหม?

ไม่ต้องเปลี่ยน — OrbStack เบากว่า Docker Desktop มากและรองรับ SSH Tunnel เหมือนกัน ถ้าใช้ OrbStack อยู่แล้วก็ใช้ต่อได้เลย แค่ย้าย containers ที่ไม่จำเป็นออกจาก Mac เท่านั้น

VSCode Remote SSH ต่างจาก SSH Tunnel ยังไง?

SSH Tunnel = เปิด "ท่อ" เฉพาะ port ที่ต้องใช้ (เช่น database) ยังแก้โค้ดบน Mac อยู่ VSCode Remote SSH = ย้ายทุกอย่างไปแก้โค้ดบน VM เลย Mac เป็นแค่หน้าจอ ทั้งสองใช้ SSH แต่ scope ต่างกัน — Tunnel เหมาะกับคนที่ยังอยากแก้โค้ดบน Mac

VM RAM 40GB พอสำหรับ container กี่ตัว?

container ส่วนใหญ่ (database, cache, monitoring) ใช้ RAM ตัวละ 200MB-2GB — รัน 28 containers บน VM 40GB ใช้ RAM ประมาณ 60-70% ยังมีที่ว่างเหลือ คุ้มค่ากว่ารันบน Mac มาก

ลองจัดการ Docker Containers วันนี้

เริ่มจากเปิด OrbStack หรือ Docker Desktop ดูว่ามี container กี่ตัวที่ running — แล้วถามตัวเองว่า ตัวไหนกำลังแก้โค้ดอยู่จริง? ที่เหลือ stop หรือย้ายไป VM ได้เลย

สิ่งที่ได้ และหลักคิด

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

อยากเห็นระบบแบบนี้ทำงานกับงานของคุณ — ดู ViberQC และลงชื่อรอรอบทดลองที่ hilogiclabs.com