ไร้ปัญหาพอร์ตชนกัน: สถาปัตยกรรม Direct IP Container Sandbox ระดับสเกล

ไร้ปัญหาพอร์ตชนกัน: สถาปัตยกรรม Direct IP Container Sandbox ระดับสเกล

เมื่อคุณต้องให้บริการระบบพรีวิวแอปพลิเคชันสดๆ พร้อมกันแก่นักพัฒนาหลายพันคน วิธีการจัดการระบบเครือข่าย Container แบบเดิมๆ มักจะชนเพดานอย่างรวดเร็ว นั่นคือปัญหา พอร์ตบนเครื่องแม่ข่ายเต็ม (Host Port Exhaustion)

หากทุกแอปพลิเคชันของผู้ใช้ที่รันบน https://{subdomain}.autobahn.bot ต้องจองพอร์ตที่ไม่ซ้ำกันบนโฮสต์ (เช่น 3001, 3002, 3003) คุณจะต้องเผชิญกับอุปสรรคใหญ่: 1. Ephemeral Port ของ Linux จะหมดลงอย่างรวดเร็วเมื่อมีการใช้งานพร้อมกันหนาแน่น 2. เกิดปัญหา Race Condition ขณะสร้างและทำลาย Container ชั่วคราวอย่างรวดเร็ว 3. ความเสี่ยงด้านความปลอดภัย: พอร์ตใดก็ตามที่เปิดทิ้งไว้บน 0.0.0.0 ย่อมเสี่ยงต่อการถูกเข้าถึงโดยไม่ได้รับอนุญาต

นี่คือวิธีที่ทีมวิศวกรของเราแก้ปัญหานี้ เพื่อให้รองรับ Sandbox ที่แยกตัวเป็นอิสระได้หลายหมื่นตัวบนเครื่อง Hetzner VPS อย่างราบรื่น

สถาปัตยกรรม: Custom Docker Bridge & Direct IP Routing

แทนที่จะนำพอร์ตของ Container มาผูกกับพอร์ตของเครื่องโฮสต์ เราได้สร้าง Docker Network Bridge แยกพิเศษชื่อ `sandbox-net` ที่มีช่วง IP ส่วนตัวระดับ CIDR (172.28.0.0/16)

Subnet ส่วนตัวนี้มอบ IP เฉพาะได้มากถึง 65,534 หมายเลข

เมื่อผู้ใช้เปิดเซสชันเพื่อเริ่มทำโปรเจกต์: 1. Container Sandbox จะถูกสร้างขึ้นบน sandbox-net พร้อมรับ IP ภายในแบบไดนามิกทันที (เช่น 172.28.0.42) 2. ภายใน Container แอปพลิเคชันจะเปิดรับการเชื่อมต่อผ่านพอร์ตมาตรฐานปกติ (เช่น 3000) 3. ไม่มีการผูกพอร์ตใดๆ เข้ากับเครื่องโฮสต์ ตารางพอร์ตของเครื่องเซิร์ฟเวอร์หลักจึงไม่ถูกแตะต้องเลยแม้แต่น้อย

การกระจายคำขอผ่าน Nginx Dynamic Upstream

เมื่อมีคำขอจากผู้ใช้ภายนอกเข้ามาที่ https://project-alpha.autobahn.bot แล้ว Nginx รู้ได้อย่างไรว่าจะส่งต่อไปยังคอนเทนเนอร์ 172.28.0.42:3000?

Nginx Reverse Proxy ด้านหน้าของเราจะแปลงชื่อ Subdomain ผ่าน Cache ตรวจสอบภายในแบบไดนามิก และส่งต่อข้อมูลไปยัง IP ส่วนตัวของ Container บน Docker Bridge โดยตรง:

# Direct Container IP Routing without Host Port Binding
location / {
    proxy_pass http://$target_container_ip:3000;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host $host;
}

เนื่องจาก Nginx และ Container ทั้งหมดอยู่ในอินเทอร์เฟซเน็ตเวิร์กบริดจ์เดียวกัน ข้อมูลจึงเดินทางระหว่างกันด้วย Latency ต่ำระดับเศษส่วนของมิลลิวินาที

ปราการความปลอดภัย 6 ชั้น (6-Layer Security Boundary)

การแยกเน็ตเวิร์กเป็นเพียงครึ่งหนึ่งของความสำเร็จ แต่ละ Container Sandbox ยังได้รับการปกป้องด้วยเกราะป้องกันความปลอดภัยถึง 6 ชั้น:

1. 1Namespace Isolation: แยกกระบวนการ PID, Mount, IPC และ Network ชัดเจน
2. 2Cgroups Resource Limits: กำหนดโควตา RAM เคร่งครัด (ค่าเริ่มต้น 512MB) และจำกัด CPU เพื่อป้องกันไม่ให้มีแอปใดดึงทรัพยากรจนเครื่องค้าง
3. 3Restricted Network Egress: Container สามารถเรียกออกภายนอกได้เฉพาะพอร์ต HTTP/HTTPS ไปยัง Registry ที่ปลอดภัยเท่านั้น การสแกน TCP ทั่วไปและการเข้าถึง LAN ภายในจะถูกบล็อกที่ระดับ iptables
4. 4Read-Only Root Filesystem: สิทธิ์การเขียนข้อมูลถูกจำกัดให้อยู่เฉพาะในไดเรกทอรีชั่วคราว /workspace
5. 5Seccomp Security Profiles: ปิดกั้น System Call ของ Linux ที่อาจเป็นอันตราย
6. 6Environment Sanitization: กุญแจลับของเครื่องแม่ข่ายและ Metadata Endpoint ของระบบคลาวด์จะไม่สามารถเข้าถึงได้โดยสิ้นเชิง

ผลลัพธ์บนสภาพแวดล้อม Production

สถาปัตยกรรม Direct IP นี้ทำงานบนระบบ Production มาตั้งแต่ต้นปี 2026 ปัญหาพอร์ตชนกันลดลงเหลือศูนย์ เวลาในการเปิดเครื่อง Container ลดลงเหลือไม่ถึง 1.8 วินาทีด้วยการใช้ Base Image ที่เตรียมพร้อมไว้ล่วงหน้า และความเสถียรของระบบพรีวิวสูงถึง 99.98%