Networking — Bridge, Host, Overlay
Các driver mạng của Docker, giao tiếp giữa container qua DNS nội bộ, port mapping, và khi nào dùng network driver nào.
Hầu hết ứng dụng thực tế gồm nhiều container cần nói chuyện với nhau (API service gọi database, service AI gọi vector DB) — hiểu đúng networking giúp bạn tránh những giờ debug "vì sao container A không kết nối được container B" chỉ vì hiểu sai cách Docker cô lập và kết nối mạng giữa các container.
🎯 Mục tiêu học tập
- Phân biệt các network driver chính: bridge, host, none, overlay
- Hiểu cơ chế DNS nội bộ cho phép container gọi nhau bằng tên thay vì IP
- Cấu hình đúng port mapping để expose service ra ngoài container
- Thiết kế network topology hợp lý cho một hệ thống nhiều service
Các Network Driver chính
| Driver | Đặc điểm | Khi nào dùng |
|---|---|---|
| bridge (mặc định) | Mạng ảo riêng trên 1 máy host, container trong cùng bridge network thấy nhau, cô lập với bên ngoài trừ khi publish port | Mặc định cho hầu hết trường hợp chạy nhiều container trên 1 máy |
| host | Container dùng chung network namespace với host — không cô lập mạng, không cần port mapping | Cần hiệu năng mạng tối đa, hoặc công cụ cần truy cập trực tiếp network stack của host (hiếm dùng trong ứng dụng thông thường) |
| none | Không có network nào, container hoàn toàn cô lập mạng | Tác vụ xử lý dữ liệu thuần, không cần mạng (bảo mật tối đa) |
| overlay | Mạng ảo trải rộng qua nhiều máy host khác nhau | Docker Swarm/cluster nhiều node (Module 11) |
DNS nội bộ — gọi Container bằng tên
Khi nhiều container cùng nằm trên 1 user-defined bridge network (không phải bridge mặc định "docker0"), Docker cung cấp DNS nội bộ tự động — mỗi container gọi container khác bằng tên container thay vì phải biết IP (vốn có thể đổi mỗi lần container khởi động lại):
docker network create my-app-net
docker run -d --name db --network my-app-net postgres:16
docker run -d --name api --network my-app-net -e DB_HOST=db my-api-image
# Bên trong container "api", có thể kết nối tới Postgres qua hostname "db" — không cần biết IP thật
DNS nội bộ theo tên container chỉ hoạt động trên user-defined network, không hoạt động trên bridge network mặc định (network "bridge" có sẵn khi cài Docker) — đây là lý do luôn nên tạo network riêng cho ứng dụng thay vì dùng network mặc định.
Port Mapping — Expose service ra ngoài
Container trong cùng network thấy nhau qua port nội bộ mà không cần publish, nhưng để truy cập từ máy
host (hoặc từ internet) vào container, cần "ánh xạ" (publish) port container ra port host bằng
-p:
# -p [port_host]:[port_container]
docker run -d -p 8080:80 nginx
# Truy cập nginx (đang lắng nghe port 80 bên trong container) qua http://localhost:8080
Phân biệt rõ EXPOSE trong Dockerfile (chỉ mang tính tài liệu, không tự publish gì) với
-p lúc chạy container (thực sự mở port ra ngoài) — nhầm lẫn giữa hai khái niệm này là lỗi rất
phổ biến với người mới.
Thiết kế Network Topology cho hệ thống nhiều Service
Với hệ thống có nhiều tầng (ví dụ: nginx → API service → database + cache), nguyên tắc thiết kế tốt: tạo network riêng cho từng "vùng" giao tiếp cần thiết, không gộp tất cả vào 1 network chung nếu không cần — ví dụ database chỉ nên nằm trên network nội bộ mà API service truy cập được, không cần (và không nên) cùng network với nginx public-facing, giảm bề mặt tấn công nếu 1 container bị xâm nhập.
🏋️ Bài tập thực hành
Tạo 1 user-defined bridge network. Chạy 1 container Redis và 1 container Python script kết nối tới Redis bằng hostname (tên container), không dùng IP. Thử lại thí nghiệm này nhưng đặt cả 2 container vào network bridge mặc định — xác nhận kết nối bằng hostname thất bại, chỉ kết nối được bằng IP. Viết lại kết luận ngắn gọn giải thích vì sao.
📚 Tài nguyên học tập
-
Docker — Networking overviewTổng quan networking trong DockerDocs
-
Docker — Networking driversChi tiết từng network driverDocs
✅ Tự đánh giá hoàn thành
- Phân biệt được bridge, host, none, overlay và khi nào dùng loại nào
- Giải thích được vì sao DNS nội bộ chỉ hoạt động trên user-defined network
- Phân biệt rõ EXPOSE (Dockerfile) và -p (docker run)
- Thiết kế được network topology hợp lý cho hệ thống 3+ service