หยุดสงสัย! Docker Network คุยกันท่าไหน? Bridge, Host, Overlay เลือกยังไงให้แอปพลิเคชันของเราทรงพลัง

เคยไหมครับ? เราสร้างแอปพลิเคชันสุดเจ๋งขึ้นมา แยกบริการต่างๆ เป็น Microservices อย่างดีงาม แล้วก็จับมันทั้งหมดใส่ Container ด้วย Docker เพื่อให้ง่ายต่อการ Deploy... ทุกอย่างดูเหมือนจะราบรื่น จนกระทั่งมาถึงคำถามที่ว่า "แล้ว Container พวกนี้มันจะคุยกันยังไง?"

ทำไม Frontend Container ของเราถึงเรียกใช้ Backend API ที่อยู่อีก Container หนึ่งได้? แล้วถ้าวันหนึ่งบริการของเราโตขึ้น จนต้องรัน Container ข้ามเครื่อง Server หลายๆ ตัวล่ะ? จะทำยังไงให้มันยังคุยกันรู้เรื่อง?

นี่ไม่ใช่แค่เรื่องทางเทคนิคที่น่าเบื่อครับ แต่มันคือแก่นของการออกแบบสถาปัตยกรรมแอปพลิเคชันสมัยใหม่ให้แข็งแกร่งและพร้อมที่จะขยายตัว (Scalable) การเข้าใจว่าเครือข่ายของ Docker ทำงานอย่างไร คือการก้าวข้ามจากการเป็นแค่ "ผู้ใช้" Docker ไปสู่การเป็น "สถาปนิก" ที่ออกแบบระบบด้วย Docker ได้อย่างแท้จริง วันนี้เราจะมาเจาะลึกเรื่องนี้กันครับ

พื้นฐานที่ควรรู้ Network Drivers

ก่อนจะไปไกลกว่านี้ Docker จัดการเรื่องเครือข่ายผ่านสิ่งที่เรียกว่า Network Drivers ครับ ซึ่งแต่ละ Driver ก็มีคุณสมบัติและกรณีการใช้งานที่แตกต่างกันออกไป วันนี้เราจะมาโฟกัสที่ 3 ทหารเสือหลักที่ทุกคนต้องเจอ Bridge, Host, และ Overlay

1. Bridge Network - สะพานเชื่อมสู่โลกภายนอก (The Default)

เมื่อไหร่ก็ตามที่เราติดตั้ง Docker และเริ่มรัน Container โดยไม่ได้กำหนดค่า Network ใดๆ เลย Docker จะใช้ Bridge Network เป็นค่าเริ่มต้นให้เราโดยอัตโนมัติ

มันทำงานอย่างไร?

ลองจินตนาการว่า Docker สร้าง "โลกส่วนตัว" หรือเครือข่ายเสมือน (Virtual Private Network) ขึ้นมาบนเครื่องคอมพิวเตอร์ของเรา (Host) Container ทุกตัวที่อยู่ใน Bridge Network นี้ จะได้รับ IP Address ส่วนตัว (เช่น 172.17.0.2, 172.17.0.3) ทำให้มันสามารถคุยกันเองได้โดยตรงผ่าน IP นี้

แล้วถ้า Container อยากจะคุยกับโลกภายนอกล่ะ? Docker จะทำหน้าที่เป็น "สะพาน" (Bridge) ตามชื่อของมันเลยครับ โดยใช้เทคนิคที่เรียกว่า NAT (Network Address Translation) และ Port Mapping

สมมติว่าเรามี Web Server Container ที่รันอยู่บนพอร์ต 80 แต่เราต้องการให้คนจากภายนอกเข้าถึงได้ผ่านพอร์ต 8080 ของเครื่อง Host เราจะใช้คำสั่งแบบนี้

$ docker run -d -p 8080:80 nginx

คำสั่ง -p 8080:80 นี่แหละครับ คือการบอก Docker ให้ "ช่วยแมพพอร์ต 8080 ของเครื่อง Host ไปยังพอร์ต 80 ของ Container นี้ที" เมื่อมีคนเรียกเข้ามาที่ http://<Your_Host_IP>:8080 Docker ก็จะส่ง Traffic นั้นเข้าไปในโลกส่วนตัวให้กับ Nginx Container ของเราทันที

คำสั่งพื้นฐานที่ใช้บ่อย

• ดู Network ทั้งหมด: docker network ls
• สร้าง Bridge Network ใหม่: docker network create --driver bridge my-bridge-network
• รัน Container ใน Network ที่เราสร้าง: docker run -d --network my-bridge-network my-image

เหมาะกับงานแบบไหน?

เหมาะที่สุดสำหรับแอปพลิเคชันที่รัน Container ทั้งหมดอยู่บน เครื่อง Host เดียวกัน เป็นตัวเลือกเริ่มต้นที่ดีและปลอดภัยที่สุดสำหรับการพัฒนาทั่วไป

2. Host Network - ขอยืม Network ของเครื่องแม่ (The High-Performance)

สำหรับ Host Network แนวคิดจะต่างออกไปอย่างสิ้นเชิง แทนที่จะสร้าง "โลกส่วนตัว" ให้ Container มันกลับทำสิ่งที่ตรงกันข้าม คือ ไม่สร้าง ครับ

มันทำงานอย่างไร?

Container ที่ใช้ Host Network จะทลายกำแพงของตัวเองออกมา แล้วใช้ Network Stack ของเครื่อง Host โดยตรงเลย นั่นหมายความว่า

• ไม่มี IP ส่วนตัว: Container จะไม่ได้ IP Address ของตัวเอง แต่จะใช้ IP Address ของเครื่อง Host เลย
• ประสิทธิภาพสูงสุด: เนื่องจากไม่มีชั้นของ NAT มาคั่นกลาง ทำให้การรับส่งข้อมูลเร็วขึ้น เพราะไม่ต้องมีการแปลที่อยู่ไปมา
• ความเสี่ยงเรื่อง Port Conflict: ข้อเสียที่สำคัญที่สุดคือเรื่องพอร์ต ถ้า Container ของเราต้องการใช้พอร์ต 80 มันก็จะใช้พอร์ต 80 ของเครื่อง Host ทันที หากมีโปรแกรมอื่นหรือ Container อื่นใช้พอร์ตนั้นอยู่แล้ว ก็จะเกิดข้อผิดพลาด (Port Conflict) และไม่สามารถรันได้ เราไม่สามารถทำ Port Mapping แบบ Bridge ได้อีกต่อไป

$ docker run --network host my-image

เหมาะกับงานแบบไหน?

เมื่อ ประสิทธิภาพของเครือข่ายคือสิ่งสำคัญที่สุด และคุณยอมรับความเสี่ยงเรื่องการจัดการพอร์ตที่อาจจะชนกันได้ เหมาะกับงานที่ต้องการลด Latency ของ Network ลงให้เหลือน้อยที่สุด

3. Overlay Network - ตาข่ายข้ามจักรวาล (The Multi-Host)

มาถึงพระเอกตัวจริงสำหรับระบบใหญ่ๆ อย่าง Microservices ที่ต้องรันบน Server หลายๆ ตัว หรือที่เรียกว่า Cluster นั่นก็คือ Overlay Network

มันทำงานอย่างไร?

ลองนึกภาพว่าเรามีเครื่อง Server (Docker Host) 3 เครื่อง และมี Container ของแอปพลิเคชันเรากระจายกันรันอยู่บนเครื่องทั้งสาม จะทำยังไงให้ Frontend Container บนเครื่องที่ 1 คุยกับ Backend Container บนเครื่องที่ 3 ได้ราวกับว่ามันอยู่ในเครือข่ายเดียวกัน?

Overlay Network คือคำตอบครับ มันจะสร้าง "เครือข่ายเสมือนซ้อนทับ" (Overlay) ขึ้นมาบนเครือข่ายจริงๆ ของเครื่อง Host ทั้งหมด ทำให้เกิดเป็นเครือข่ายแบบกระจายศูนย์ (Distributed Network) ที่ครอบคลุมทุก Host ใน Cluster

เทคโนโลยีเบื้องหลังที่นิยมใช้คือ VXLAN (Virtual Extensible LAN) ซึ่งจะทำการห่อหุ้ม (Encapsulate) แพ็กเก็ตข้อมูลของ Container แล้วส่งข้ามเครือข่ายของ Host ไป พอถึงปลายทางก็จะแกะห่อออก ทำให้ Container ทั้งหมดรู้สึกเหมือนเชื่อมต่ออยู่บน Switch ตัวเดียวกัน แม้จะอยู่คนละซีกโลกก็ตาม

Overlay Network คือหัวใจสำคัญของเครื่องมือจัดการ Cluster อย่าง Docker Swarm และเป็นแนวคิดพื้นฐานใน Kubernetes เช่นกัน

คำสั่ง (ใน Docker Swarm)

# สร้าง Overlay Network
$ docker network create --driver overlay my-overlay-network

# สร้าง Service ที่ใช้ Network นี้
$ docker service create --name my-service --network my-overlay-network my-image

เหมาะกับงานแบบไหน?

จำเป็นอย่างยิ่ง สำหรับการสื่อสารระหว่าง Container ที่รันอยู่บน Docker Host หลายๆ เครื่อง หรือเมื่อคุณใช้งาน Docker Swarm

สรุป - เลือก Network Driver ให้ถูกกับงาน

บทสรุป

การทำความเข้าใจโมเดลเครือข่ายของ Docker ไม่ใช่แค่การท่องจำคำสั่งครับ แต่มันคือการได้มาซึ่งพลังในการออกแบบแอปพลิเคชันที่ยืดหยุ่น ทรงพลัง และพร้อมรับมือกับการเติบโตในอนาคต จากแอปพลิเคชันง่ายๆ ที่มีสอง Container บนเครื่องของคุณ ไปจนถึงระบบ Microservices ที่ซับซ้อนบน Cloud Cluster ขนาดใหญ่ "เครือข่าย" คือกาวที่เชื่อมทุกอย่างเข้าไว้ด้วยกัน

เมื่อคุณเข้าใจว่า Container "คุยกัน" อย่างไร คุณก็จะสามารถเลือกเครื่องมือที่เหมาะสมกับงาน และสร้างระบบที่ดีขึ้นได้อย่างแน่นอนครับ

Source: https://dev.to/caffinecoder54/docker-networking-deep-dive-understanding-bridge-host-and-overlay-networks-1kac