จากโพสต์ที่แล้วเราพูดถึง Kubernetes ว่าช่วยจัดการ container ให้ทำงานร่วมกันอย่างเป็นระบบ
แต่เคยสงสัยมั้ยว่า... container เหล่านั้น "คุยกัน" ยังไง? เว็บที่เรา deploy ส่งข้อมูลถึง user ได้อย่างไร? 🌐
คำตอบคือ Networking — พื้นฐานที่ DevOps ทุกคนต้องรู้ ก่อนจะ deploy อะไรขึ้น production ได้อย่างมั่นใจ 🐕🦺
TCP/IP Model — ภาษากลางของ Internet
ทุกครั้งที่เราเปิดเว็บหรือส่งข้อมูล ข้อมูลจะเดินทางผ่าน 4 ชั้น (layers) ของ TCP/IP model — แต่ละชั้นมีหน้าที่เฉพาะ: Application (HTTP, DNS — ภาษาที่ apps พูด), Transport (TCP/UDP — ส่งข้อมูลแบบ reliable หรือ fast), Internet (IP — หาเส้นทางไป destination), Network Access (Ethernet/WiFi — ส่ง bits จริงๆ) เข้าใจ model นี้แล้วจะ debug network issues ได้เร็วขึ้นมาก:
💡 จำง่ายๆ: Application สร้างข้อมูล → Transport แบ่งเป็นชิ้น → Network หาเส้นทาง → Link ส่งผ่านสาย/ไร้สาย
TCP vs UDP — ต่างกันยังไง?
Transport layer มี 2 protocols หลัก — TCP (Transmission Control Protocol) ส่งข้อมูลแบบ reliable มี handshake, retransmission, ordering เหมาะกับ web, email, file transfer ส่วน UDP (User Datagram Protocol) ส่งเร็วแต่ไม่ guarantee delivery เหมาะกับ video streaming, gaming, DNS ที่ speed สำคัญกว่า reliability:
| Feature | TCP | UDP |
|---|---|---|
| การเชื่อมต่อ | Connection-oriented (3-way handshake) | Connectionless |
| ความเชื่อถือได้ | ✅ รับประกันข้อมูลถึง | ❌ ไม่รับประกัน |
| ลำดับข้อมูล | ✅ เรียงลำดับ | ❌ อาจสลับ |
| ความเร็ว | ช้ากว่า (overhead) | เร็วกว่า |
| ใช้กับ | HTTP, SSH, Email, Database | DNS, Video streaming, Gaming |
IP Address — ที่อยู่บนโลก Internet
ทุกอุปกรณ์บน network ต้องมี IP Address เหมือนบ้านต้องมีเลขที่อยู่:
IPv4
IPv4 ใช้ 32-bit address (เช่น 192.168.1.100) รองรับ ~4.3 พันล้าน addresses ซึ่งหมดแล้ว! IPv6 ใช้ 128-bit (เช่น 2001:db8::1) รองรับได้แทบไม่จำกัด แต่ IPv4 ยังใช้อยู่ทั่วไปผ่าน NAT:
# รูปแบบ: 4 กลุ่ม, กลุ่มละ 0-255
192.168.1.100 ← Private IP (ใช้ภายใน network)
203.0.113.50 ← Public IP (ใช้บน internet)
# ดู IP ของเครื่องตัวเอง
ip addr show # Linux
ifconfig # macOS
ipconfig # Windows
Private vs Public IP
Private IPs (10.x.x.x, 172.16-31.x.x, 192.168.x.x) ใช้ภายใน network เท่านั้น — ไม่สามารถเข้าถึงจาก internet ได้โดยตรง ต้องผ่าน NAT/router ส่วน Public IPs คือ addresses ที่ใช้บน internet จริง DevOps ต้องเข้าใจความแตกต่างนี้เพราะส่งผลต่อ VPC design และ security:
| ประเภท | Range | ใช้ที่ไหน |
|---|---|---|
| Private | 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 |
ภายใน LAN, Docker network |
| Public | ทุกอย่างที่เหลือ | บน Internet |
| Loopback | 127.0.0.1 (localhost) |
ตัวเครื่องเอง |
💡 DevOps Tip: เวลา deploy app ถ้า bind ที่127.0.0.1จะเข้าได้จากเครื่องเดียว ต้อง bind0.0.0.0ถึงจะเข้าจากภายนอกได้
Ports — ประตูของ Application
IP Address บอกว่า "เครื่องไหน" แต่ Port บอกว่า "app ไหน" บนเครื่องนั้น — เครื่องเดียวรัน web server (port 80), database (port 5432), SSH (port 22) พร้อมกันได้ ports 0-1023 เป็น "well-known ports" ที่ต้องใช้ root privilege, 1024-65535 ใช้ได้อิสระ DevOps ต้องรู้ว่า service ไหนใช้ port ไหน เพื่อตั้ง firewall ได้ถูกต้อง:
| Port | Service | คำอธิบาย |
|---|---|---|
| 22 | SSH | Remote login เข้าเครื่อง |
| 80 | HTTP | เว็บไซต์ (ไม่เข้ารหัส) |
| 443 | HTTPS | เว็บไซต์ (เข้ารหัส SSL/TLS) |
| 3000 | Dev Server | React, Next.js development |
| 3306 | MySQL | ฐานข้อมูล MySQL/MariaDB |
| 5432 | PostgreSQL | ฐานข้อมูล PostgreSQL |
| 6379 | Redis | Cache / Message queue |
| 27017 | MongoDB | ฐานข้อมูล NoSQL |
# ดู port ที่กำลังใช้งาน
sudo ss -tlnp # Linux
sudo lsof -i -P # macOS
netstat -an # Windows
# ตรวจว่า port เปิดอยู่มั้ย
nc -zv server.com 443
curl -I http://server.com:8080
DNS — แปลงชื่อเป็น IP
เราจำ google.com ได้ง่ายกว่า 142.250.199.46 — DNS ทำหน้าที่แปลงชื่อ domain เป็น IP address
DNS Record Types
DNS ไม่ได้มีแค่ "ชื่อ → IP" — มี record types หลายแบบที่ทำหน้าที่ต่างกัน DevOps ต้องรู้อย่างน้อย A, AAAA, CNAME, MX, TXT เพื่อ setup domains ได้ถูกต้อง:
| Record | หน้าที่ | ตัวอย่าง |
|---|---|---|
| A | Domain → IPv4 | example.com → 93.184.216.34 |
| AAAA | Domain → IPv6 | example.com → 2606:2800:... |
| CNAME | Alias ชี้ไป domain อื่น | www → example.com |
| MX | Mail server | example.com → mail.example.com |
| NS | Name server ที่ดูแล domain | ns1.cloudflare.com |
| TXT | ข้อความ (SPF, verification) | v=spf1 include:... |
# ดู DNS record
dig example.com A
dig example.com MX
nslookup example.com
# ตรวจว่า DNS propagate แล้วหรือยัง
dig @8.8.8.8 mysite.com A # ถาม Google DNS
dig @1.1.1.1 mysite.com A # ถาม Cloudflare DNS
Firewall — กำแพงป้องกัน
Firewall คือตัวกรองที่ตัดสินว่า traffic ไหนเข้า-ออกได้ ไหนบล็อก — หลักการคือ "default deny" ปิดทุกอย่างก่อน แล้วเปิดเฉพาะที่จำเป็น เช่น เปิด port 80/443 สำหรับ web, port 22 สำหรับ SSH เฉพาะ IP ที่อนุญาต บน Linux ใช้ ufw (ง่าย) หรือ iptables (powerful) บน cloud ใช้ Security Groups:
# UFW (Ubuntu) — ง่ายที่สุด
sudo ufw enable
sudo ufw allow 22/tcp # SSH
sudo ufw allow 80/tcp # HTTP
sudo ufw allow 443/tcp # HTTPS
sudo ufw deny 3306/tcp # บล็อก MySQL จากภายนอก
sudo ufw status
# iptables — ละเอียดกว่า
sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 3306 -s 10.0.0.0/8 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 3306 -j DROP
🐕 กฎเหล็ก: เปิดเฉพาะ port ที่จำเป็น! Database ports (3306, 5432, 27017) ไม่ควรเปิดให้ public
Load Balancer — กระจาย Traffic
เมื่อ app มี traffic เยอะเกินกว่า server เดียวรับไหว ใช้ Load Balancer กระจาย requests ไปยังหลาย servers — ทำให้ scale ได้ (เพิ่ม server เมื่อ traffic เพิ่ม) และ HA (ถ้า server หนึ่งล่ม traffic ไปอีกตัว) Load Balancer มี 2 แบบ: Layer 4 (TCP level — เร็ว, ง่าย) และ Layer 7 (HTTP level — route ตาม URL path, headers ได้):
Load Balancing Strategies
วิธีกระจาย traffic มีหลายแบบ — เลือกตาม use case: Round Robin (วนรอบ — ง่ายที่สุด), Least Connections (ส่งไป server ที่ว่างที่สุด), IP Hash (user เดิมไป server เดิม — เหมาะกับ session-based apps):
- Round Robin — วนส่งทีละตัว (1 → 2 → 3 → 1 → ...)
- Least Connections — ส่งไปตัวที่ connection น้อยสุด
- IP Hash — user คนเดิมไป server เดิมเสมอ (sticky session)
- Weighted — server แรงกว่าได้ traffic มากกว่า
Reverse Proxy — Nginx ตัวกลาง
Reverse Proxy รับ request จากภายนอกแล้วส่งต่อไปยัง app ข้างหลัง — ช่วยเรื่อง security, SSL, caching:
# /etc/nginx/sites-available/myapp
server {
listen 80;
server_name myapp.com;
# Redirect HTTP → HTTPS
return 301 https://$host$request_uri;
}
server {
listen 443 ssl;
server_name myapp.com;
ssl_certificate /etc/letsencrypt/live/myapp.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/myapp.com/privkey.pem;
location / {
proxy_pass http://localhost:3000; # ส่งต่อไป Node.js app
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
location /api {
proxy_pass http://localhost:8080; # API server อีกตัว
}
}
💡 ทำไมใช้ Reverse Proxy?
✅ SSL termination (จัดการ HTTPS ที่จุดเดียว)
✅ Load balancing ระหว่าง app instances
✅ Caching static files
✅ ซ่อน app server จากภายนอก (security)
SSH — Remote เข้า Server
DevOps ต้องใช้ SSH เป็นเรื่องปกติ — เข้าจัดการ server จากระยะไกล:
# เข้า server
ssh [email protected]
# ใช้ key แทน password (ปลอดภัยกว่า!)
ssh-keygen -t ed25519 -C "[email protected]"
ssh-copy-id [email protected]
# SSH tunneling — เข้าถึง port ที่ถูกบล็อก
ssh -L 3306:localhost:3306 [email protected]
# ตอนนี้เข้า localhost:3306 = เหมือนเข้า MySQL บน server
# SCP — copy ไฟล์ไป server
scp ./app.tar.gz [email protected]:/home/user/
SSH Config — ลดพิมพ์ซ้ำ
# ~/.ssh/config
Host prod
HostName 203.0.113.50
User deploy
IdentityFile ~/.ssh/id_ed25519
Port 22
Host staging
HostName 10.0.1.100
User deploy
ProxyJump prod # เข้าผ่าน prod (bastion host)
# ใช้แค่:
ssh prod
ssh staging
Docker Networking — Container คุยกันยังไง?
กลับมาเชื่อมกับ Docker — containers ใช้ virtual network ที่ Docker สร้างให้ มี 3 modes หลัก: bridge (default — containers คุยกันผ่าน virtual bridge), host (ใช้ network ของ host ตรงๆ — เร็วแต่ไม่ isolate), overlay (ข้าม hosts — ใช้กับ Docker Swarm/K8s) containers ในเครือข่ายเดียวกันเรียกหากันด้วย container name:
# ดู network ที่มี
docker network ls
# NETWORK ID NAME DRIVER
# abc123 bridge bridge ← default
# def456 host host
# ghi789 none null
# สร้าง custom network (แนะนำ!)
docker network create myapp-net
# รัน container ใน network เดียวกัน
docker run -d --name api --network myapp-net node-api
docker run -d --name db --network myapp-net postgres
# container ใน network เดียวกัน เรียกกันด้วย "ชื่อ" ได้!
# ใน api container: postgres://db:5432/mydb ← ใช้ชื่อ "db" แทน IP
🐕 Key Insight: Docker Compose สร้าง network ให้อัตโนมัติ ทุก service เรียกกันด้วยชื่อ service ได้เลย!
เครื่องมือ Networking ที่ DevOps ต้องรู้
สรุป command-line tools สำหรับ debug network issues — จำไม่หมดก็ไม่เป็นไร แค่รู้ว่ามีอะไรบ้าง เมื่อมีปัญหาจะได้เลือกใช้ถูกตัว:
# ping — ทดสอบว่าเครื่องเปิดอยู่มั้ย
ping google.com
# traceroute — ดูเส้นทางข้อมูล
traceroute google.com
# curl — ทดสอบ HTTP request
curl -I https://myapp.com # ดูแค่ header
curl -v https://myapp.com # verbose mode
# dig — ตรวจ DNS
dig myapp.com A +short
# ss / netstat — ดู port ที่เปิด
ss -tlnp
# tcpdump — จับ packet (advanced)
sudo tcpdump -i eth0 port 80 -n
# nmap — scan port (ระวังใช้กับ server ตัวเองเท่านั้น!)
nmap -sT server.com
สรุป
Networking เป็นพื้นฐานที่ทุกอย่างใน DevOps สร้างอยู่บน — Docker networking, Kubernetes services, Load Balancers, VPCs ล้วนใช้ concepts เดียวกัน (TCP/IP, DNS, ports, firewalls) เข้าใจพื้นฐานดี debug ปัญหาได้เร็ว:
- TCP/IP 4 Layers = Application → Transport → Network → Link
- TCP = เชื่อถือได้ (เว็บ, API) | UDP = เร็ว (streaming, gaming)
- IP Address = ที่อยู่เครื่อง | Port = ประตูของ app
- DNS = แปลง domain → IP | ต้องรู้ A, CNAME, MX records
- Firewall = เปิดเฉพาะ port ที่จำเป็น (UFW ง่ายที่สุด)
- Load Balancer = กระจาย traffic | Reverse Proxy = Nginx ตัวกลาง
- SSH = remote เข้า server | ใช้ key + config file
- Docker Network = container คุยกันด้วยชื่อ ใน network เดียวกัน 🐕🦺