Networking พื้นฐานสำหรับ DevOps — รู้จักเครือข่ายก่อน DeployNetworking Fundamentals for DevOps — Know the Network Before You Deploy

# รูปแบบ: 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

# ดู 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 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

# 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

# /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 อีกตัว
    }
}

# เข้า 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
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

# ดู 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

# 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

In the previous post we talked about Kubernetes, and how it keeps containers working together in an orderly way.

But have you ever wondered... how do those containers actually "talk" to each other? How does the site we deploy get its data all the way to a user? 🌐

The answer is Networking — the groundwork every DevOps engineer has to know before putting anything into production with any confidence. 🐕‍🦺

---

TCP/IP Model — The Common Language of the Internet

Every time we open a web page or send data, that data travels through the 4 layers of the TCP/IP model — and each layer has one job: Application (HTTP, DNS — the language apps speak), Transport (TCP/UDP — sending data reliably, or sending it fast), Internet (IP — finding the route to the destination), Network Access (Ethernet/Wi-Fi — actually pushing the bits). Once this model is clear, debugging network issues gets a great deal faster:

💡 An easy way to remember it: Application creates the data → Transport breaks it into pieces → Network finds the route → Link sends it over the wire or the air

TCP vs UDP — What Is the Difference?

The transport layer has 2 main protocols — TCP (Transmission Control Protocol) sends data reliably, with a handshake, retransmission and ordering, which suits web, email and file transfer. UDP (User Datagram Protocol) is fast but guarantees nothing, which suits video streaming, gaming and DNS, where speed matters more than reliability:

Feature	TCP	UDP
Connection	Connection-oriented (3-way handshake)	Connectionless
Reliability	✅ Delivery guaranteed	❌ No guarantee
Ordering	✅ Arrives in order	❌ May arrive shuffled
Speed	Slower (overhead)	Faster
Used for	HTTP, SSH, Email, Database	DNS, Video streaming, Gaming

---

IP Address — Your Address on the Internet

Every device on a network needs an IP Address, the same way every house needs a street number:

IPv4

IPv4 uses a 32-bit address (192.168.1.100, for example) and supports around 4.3 billion addresses — which have already run out! IPv6 uses 128 bits (2001:db8::1, for example) and supports a practically unlimited number, but IPv4 is still everywhere, kept alive through NAT:

# Format: 4 groups, each one 0-255
192.168.1.100      ← Private IP (used inside a network)
203.0.113.50       ← Public IP (used on the internet)

# See your own machine's 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) are for use inside a network only — they cannot be reached directly from the internet and have to go through NAT or a router. Public IPs are the addresses that live on the real internet. DevOps engineers need this distinction because it drives both VPC design and security:

Type	Range	Where it is used
Private	10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16	Inside a LAN, Docker networks
Public	Everything else	On the Internet
Loopback	127.0.0.1 (localhost)	The machine itself

💡 DevOps Tip: when you deploy an app, binding to 127.0.0.1 means only that one machine can reach it. Bind to 0.0.0.0 if it has to be reachable from outside

---

Ports — The Doors of an Application

An IP address says "which machine"; a Port says "which app" on that machine — one box can run a web server (port 80), a database (port 5432) and SSH (port 22) at the same time. Ports 0-1023 are the "well-known ports" and need root privileges; 1024-65535 are free to use. DevOps engineers have to know which service sits on which port in order to set the firewall up correctly:

Port	Service	Description
22	SSH	Remote login to a machine
80	HTTP	Websites (unencrypted)
443	HTTPS	Websites (SSL/TLS encrypted)
3000	Dev Server	React, Next.js development
3306	MySQL	MySQL/MariaDB database
5432	PostgreSQL	PostgreSQL database
6379	Redis	Cache / Message queue
27017	MongoDB	NoSQL database

# See which ports are in use
sudo ss -tlnp       # Linux
sudo lsof -i -P     # macOS
netstat -an          # Windows

# Check whether a port is open
nc -zv server.com 443
curl -I http://server.com:8080

---

DNS — Turning Names into IPs

We remember google.com far more easily than 142.250.199.46 — and DNS is what turns a domain name into an IP address

DNS Record Types

DNS is not only "name → IP" — there are several record types, each with its own job. A DevOps engineer needs at least A, AAAA, CNAME, MX and TXT to set a domain up correctly:

Record	Job	Example
A	Domain → IPv4	example.com → 93.184.216.34
AAAA	Domain → IPv6	example.com → 2606:2800:...
CNAME	Alias pointing at another domain	www → example.com
MX	Mail server	example.com → mail.example.com
NS	Name server responsible for the domain	ns1.cloudflare.com
TXT	Free text (SPF, verification)	v=spf1 include:...

# Look at a DNS record
dig example.com A
dig example.com MX
nslookup example.com

# Check whether DNS has propagated yet
dig @8.8.8.8 mysite.com A      # ask Google DNS
dig @1.1.1.1 mysite.com A      # ask Cloudflare DNS

---

Firewall — The Wall That Protects You

A Firewall is the filter that decides which traffic may come in and go out, and which gets blocked — and the principle is "default deny": close everything first, then open only what is genuinely needed. Open ports 80/443 for the web, for instance, and port 22 for SSH from permitted IPs only. On Linux you use ufw (easy) or iptables (powerful); in the cloud you use Security Groups:

# UFW (Ubuntu) — the easiest of the lot
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      # block MySQL from outside
sudo ufw status

# iptables — finer-grained
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

🐕 The iron rule: open only the ports you actually need! Database ports (3306, 5432, 27017) should never be exposed to the public

---

Load Balancer — Spreading the Traffic

When an app gets more traffic than a single server can carry, a Load Balancer spreads the requests across several servers — which gives you scale (add a server as traffic grows) and HA (if one server dies, the traffic goes to another). Load balancers come in 2 kinds: Layer 4 (TCP level — fast and simple) and Layer 7 (HTTP level — able to route on URL path or headers):

Load Balancing Strategies

There are several ways to spread the traffic — pick by use case: Round Robin (take turns — the simplest), Least Connections (send to whichever server is least busy), IP Hash (the same user always lands on the same server — right for session-based apps):

• Round Robin — one after another, in turn (1 → 2 → 3 → 1 → ...)
• Least Connections — send to the server with the fewest connections
• IP Hash — the same user always goes to the same server (sticky session)
• Weighted — the stronger server takes more of the traffic

---

Reverse Proxy — Nginx in the Middle

A Reverse Proxy takes requests from outside and forwards them to the app sitting behind it — which helps with security, SSL and 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;    # forward to the 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;    # a separate API server
    }
}

💡 Why use a Reverse Proxy?
✅ SSL termination (handle HTTPS in one place)
✅ Load balancing between app instances
✅ Caching static files
✅ Hiding the app server from the outside (security)

---

SSH — Reaching a Server Remotely

Using SSH is routine for DevOps work — it is how we manage a server from a distance:

# Log into a server
ssh [email protected]

# Use a key instead of a password (safer!)
ssh-keygen -t ed25519 -C "[email protected]"
ssh-copy-id [email protected]

# SSH tunnelling — reach a port that is blocked
ssh -L 3306:localhost:3306 [email protected]
# now localhost:3306 = the MySQL on that server

# SCP — copy a file to the server
scp ./app.tar.gz [email protected]:/home/user/

SSH Config — Stop Typing the Same Thing

# ~/.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      # go in via prod (bastion host)

# then all you type is:
ssh prod
ssh staging

---

Docker Networking — How Do Containers Talk?

Back to Docker — containers use a virtual network that Docker builds for them, with 3 main modes: bridge (the default — containers talk through a virtual bridge), host (use the host's network directly — fast, but no isolation), overlay (across hosts — used with Docker Swarm and K8s). Containers on the same network reach each other by container name:

# List the networks you have
docker network ls
# NETWORK ID     NAME      DRIVER
# abc123         bridge    bridge    ← default
# def456         host      host
# ghi789         none      null

# Create a custom network (recommended!)
docker network create myapp-net

# Run containers on the same network
docker run -d --name api --network myapp-net node-api
docker run -d --name db  --network myapp-net postgres

# containers on one network can call each other by "name"!
# inside the api container: postgres://db:5432/mydb  ← the name "db" instead of an IP

🐕 Key Insight: Docker Compose creates the network for you automatically — every service can reach every other by its service name straight away!

---

The Networking Tools Every DevOps Engineer Needs

A round-up of the command-line tools for debugging network issues — you do not have to memorise them all, only to know what exists, so that when trouble comes you pick the right one:

# ping — test whether a machine is up
ping google.com

# traceroute — see the route the data takes
traceroute google.com

# curl — test an HTTP request
curl -I https://myapp.com        # headers only
curl -v https://myapp.com        # verbose mode

# dig — check DNS
dig myapp.com A +short

# ss / netstat — see which ports are open
ss -tlnp

# tcpdump — capture packets (advanced)
sudo tcpdump -i eth0 port 80 -n

# nmap — port scanning (careful: only against your own servers!)
nmap -sT server.com

---

Summary

Networking is the foundation everything else in DevOps is built on — Docker networking, Kubernetes services, load balancers and VPCs all rest on the same concepts (TCP/IP, DNS, ports, firewalls). Know the fundamentals well and you debug problems fast:

• TCP/IP 4 Layers = Application → Transport → Network → Link
• TCP = reliable (web, APIs) | UDP = fast (streaming, gaming)
• IP Address = the machine's address | Port = the app's door
• DNS = domain → IP | know your A, CNAME and MX records
• Firewall = open only the ports you need (UFW is the easiest)
• Load Balancer = spread the traffic | Reverse Proxy = Nginx in the middle
• SSH = remote access to a server | use a key plus a config file
• Docker Network = containers on one network talk by name 🐕‍🦺