DEV Community: reerii code

Docker ฉบับเข้าใจง่าย: Image, Container, Volume, Network และ Docker Compose

reerii code — Wed, 04 Nov 2026 10:33:50 +0000

เคยเจอไหม เขียนโปรเจกต์บน Windows มาอย่างดี รันในเครื่องตัวเองผ่านหมด แต่พอเอาไป deploy บนเซิร์ฟเวอร์ Linux ดันรันไม่ขึ้น เพราะ library บางตัวทำงานต่างกันในคนละสภาพแวดล้อม

หรือบางที ส่งโปรเจกต์ให้เพื่อนไปรัน เพื่อนก็รันไม่ได้อีก เพราะเวอร์ชันที่ติดตั้งไม่ตรงกัน หรือเวอร์ชันตรงกันแล้วแต่ดันอยู่คนละ OS

นี่แหละคือปัญหาคลาสสิก "It works on my machine" และเป็นเหตุผลที่ Docker เกิดขึ้นมา

Docker ต่างจาก VM ยังไง

ถ้ามองแบบหยาบ ๆ Docker ก็คล้าย VM นะ คือแยกแอปออกไปรันในพื้นที่ของตัวเอง แต่ต่างกันตรงนี้

VM (Virtual Machine) คือการจำลองคอมพิวเตอร์ขึ้นมาทั้งเครื่อง มี OS ของตัวเองครบชุด เลยกินทรัพยากรเยอะ และบูตนาน
Docker เอาแค่สิ่งที่แอปต้องใช้จริง ๆ เช่น โค้ด runtime library และ config มัดรวมเป็นก้อนเดียว แล้วใช้ kernel ร่วมกับเครื่องหลัก เลยเบาและเปิดขึ้นได้ในไม่กี่วินาที

ก้อนที่มัดรวมทุกอย่างไว้นั่นแหละ เรียกว่า Image

Image: แม่แบบของแอป

Image มีอยู่ 2 แบบ

Image สำเร็จรูป ที่มีคน build ไว้ให้แล้วบน Docker Hub เช่น mysql, phpmyadmin, node, nginx ดึงมาใช้ได้เลย
Image ของแอปเราเอง อันนี้ต้อง build เอง ถ้าโปรเจกต์มีหน้าเว็บ 1 ตัว กับ API 1 ตัว ก็ต้อง build ออกมาเป็นอย่างละ 1 image

จะ build image ได้ ต้องมีไฟล์ชื่อ Dockerfile อยู่ในแต่ละโปรเจกต์ (web กับ api แยกกันคนละไฟล์) ข้างในจะบอกว่า

ใช้ image ตั้งต้นตัวไหน เช่น node:22-alpine
ตอน build ต้องรันคำสั่งอะไร เช่น npm install
ตอนเปิดแอปให้รันคำสั่งอะไร เช่น npm start หรือ node dist/index.js

ตัวอย่าง Dockerfile ของ API (Node.js) หน้าตาประมาณนี้

# 1) ใช้ image ตั้งต้นเป็น Node.js 22 แบบ alpine (ขนาดเล็ก)
FROM node:22-alpine

# 2) กำหนดโฟลเดอร์ทำงานใน container
WORKDIR /app

# 3) copy ไฟล์ package ก่อน แล้วติดตั้ง dependency
COPY package*.json ./
RUN npm ci --omit=dev

# 4) copy โค้ดที่เหลือเข้าไป
COPY . .

# 5) บอกว่าแอปใช้ port 3000
EXPOSE 3000

# 6) คำสั่งที่รันตอน container เริ่มทำงาน
CMD ["node", "src/index.js"]

💡 ทำไม copy package.json ก่อนโค้ด? เพราะ Docker build เป็นชั้น ๆ (layer) และจำ cache ไว้ ถ้าแก้แค่โค้ดแต่ไม่ได้แก้ dependency รอบหน้าจะไม่ต้อง npm ci ใหม่ build เร็วขึ้นเยอะ

Container: Image ที่ถูกรันแล้ว

แต่ image เฉย ๆ ทำอะไรไม่ได้นะ มันเป็นแค่แม่แบบ จะใช้งานได้ต้องเอาไป run ก่อน ถึงจะกลายเป็น Container ซึ่งก็คือแอปที่กำลังทำงานอยู่จริง เปิดใช้งานได้ตามปกติ

ถ้าเป็นสายเขียนโค้ด ให้นึกว่า image คือ class ส่วน container คือ object ที่ new ออกมา จาก image เดียวจะรันกี่ container ก็ได้

ดังนั้นถ้าโปรเจกต์มี web + api + database ก็จะมี 3 image และพอรันก็จะได้ 3 container

ไม่ยากใช่ไหมล่ะ แค่ build image แล้วรันเป็น container 😄

Volume: ที่เก็บข้อมูลที่ไม่หายไปกับ Container

นอกจาก image กับ container แล้ว ยังมีอีก 2 ตัวที่ต้องรู้จัก ตัวแรกคือ Volume

container ถูกออกแบบมาให้ลบทิ้งแล้วสร้างใหม่ได้ตลอด ถ้าเก็บข้อมูลไว้ข้างใน container พอลบ ข้อมูลก็หายไปด้วย

Volume คือพื้นที่เก็บข้อมูลที่แยกออกมาไว้ข้างนอก container เช่น ไฟล์ฐานข้อมูลของ MySQL หรือรูปที่ผู้ใช้อัปโหลด สมมติวันหนึ่งเราลบ container หรือลบ image ไปเลย แต่ถ้าไม่ได้ลบ volume ข้อมูลที่ใช้งานมาก็ยังอยู่ครบ สร้าง container ใหม่แล้วผูกกับ volume เดิม ข้อมูลก็กลับมาเหมือนเดิม

📌 Volume ไม่ใช่ตัวฐานข้อมูลนะ ตัวฐานข้อมูลคือ container ของ MySQL ส่วน volume คือ "ที่เก็บไฟล์" ของฐานข้อมูลนั้น

Network: ทางเชื่อมระหว่าง Container

ตัวที่สองคือ Network ทำหน้าที่เชื่อม web, api และ database ให้อยู่วงเดียวกัน เรียกใช้งานกันได้เหมือนอยู่ในเครื่องเดียวกัน

ข้อดีคือ container ใน network เดียวกันเรียกหากันด้วย ชื่อ service ได้เลย เช่น API ต่อฐานข้อมูลด้วย host db ไม่ต้องไปจำ IP

⚠️ จุดที่มือใหม่พลาดบ่อย: ชื่อ db หรือ api ใช้ได้เฉพาะตอน container คุยกันเองเท่านั้น หน้าเว็บที่รันอยู่บน browser ของผู้ใช้ไม่ได้อยู่ใน network นี้ เวลาหน้าเว็บเรียก API ต้องเรียกผ่าน port ที่เปิดออกมา เช่น http://localhost:3000 (หรือโดเมนจริงตอน deploy)

สรุป 5 คำที่ต้องรู้

คำ	คืออะไร	เปรียบเทียบ
Dockerfile	ไฟล์สูตร บอกว่าใช้ image อะไร รันคำสั่งอะไร	สูตรอาหาร
Image	แม่แบบที่ build จาก Dockerfile พร้อมทุกอย่างที่แอปต้องใช้	class
Container	image ที่ถูกรันแล้ว คือแอปที่ทำงานอยู่จริง	object
Volume	ที่เก็บข้อมูลถาวร ไม่หายแม้ลบ container	external hard disk
Network	วงเชื่อมให้ container เรียกหากันด้วยชื่อได้	วง LAN ในบ้าน

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

เช็กว่าติดตั้งแล้ว

docker --version
docker compose version

Image

docker pull mysql:8.4              # ดึง image สำเร็จรูปจาก Docker Hub
docker images                      # ดู image ที่มีในเครื่อง
docker build -t my-api ./api       # build image จาก Dockerfile ในโฟลเดอร์ api
docker rmi my-api                  # ลบ image

Container

docker run -d --name api -p 3000:3000 my-api   # รัน container (-d = รันเบื้องหลัง, -p = เปิด port เครื่อง:container)
docker ps                          # ดู container ที่กำลังรัน
docker ps -a                       # ดูทั้งหมด รวมตัวที่หยุดแล้ว
docker logs -f api                 # ดู log แบบ real-time
docker exec -it api sh             # เข้าไปใน container
docker stop api                    # หยุด
docker start api                   # เริ่มใหม่
docker rm api                      # ลบ container

Volume และ Network

docker volume ls                   # ดู volume ทั้งหมด
docker volume create db_data       # สร้าง volume
docker network ls                  # ดู network ทั้งหมด
docker network create app-net      # สร้าง network

ปัญหา: ถ้าทำทุกอย่างด้วยมือ คำสั่งจะยาวมาก

ที่เล่ามาทั้งหมด ถ้าต้องพิมพ์ใน terminal เองทีละคำสั่ง ระบบที่มี database, phpMyAdmin, api และ web จะออกมาหน้าตาแบบนี้

docker network create app-net
docker volume create db_data

docker run -d --name db --network app-net \
  -e MYSQL_ROOT_PASSWORD=changeme -e MYSQL_DATABASE=myapp \
  -v db_data:/var/lib/mysql mysql:8.4

docker run -d --name phpmyadmin --network app-net \
  -e PMA_HOST=db -p 8080:80 phpmyadmin

docker build -t my-api ./api
docker run -d --name api --network app-net \
  -e DB_HOST=db -e DB_USER=root -e DB_PASSWORD=changeme -e DB_NAME=myapp \
  -p 3000:3000 my-api

docker build -t my-web ./web
docker run -d --name web --network app-net -p 80:80 my-web

ยาวใช่ไหม แถมพลาดนิดเดียว เช่น ลืมใส่ --network หรือพิมพ์ชื่อ volume ผิด ระบบก็พังทันที แล้วทุกครั้งที่ย้ายเครื่องก็ต้องมานั่งพิมพ์ใหม่อีก

Docker Compose: เขียนครั้งเดียว รันคำสั่งเดียว

ปัญหานี้เลยเป็นที่มาของ Docker Compose

Docker Compose คือไฟล์ตั้งค่า (YAML) ที่เราเขียนโครงสร้างระบบไว้ว่ามี service อะไรบ้าง ใช้ image ไหน เปิด port อะไร ต่อ volume กับ network ยังไง จากนั้นสั่ง คำสั่งเดียว ระบบก็ขึ้นครบทั้งชุด

ตัวอย่างโครงสร้างโปรเจกต์

my-project/
├── api/
│   ├── src/index.js
│   ├── package.json
│   ├── Dockerfile
│   └── .dockerignore
├── web/
│   ├── src/...
│   ├── package.json
│   ├── Dockerfile
│   └── .dockerignore
├── .env
└── compose.yaml

`api/Dockerfile`

ใช้ไฟล์เดียวกับตัวอย่างด้านบนได้เลย

`web/Dockerfile` (เช่น React/Vue ที่ build ด้วย Vite)

หน้าเว็บแบบนี้ใช้ Node แค่ตอน build พอได้ไฟล์ static แล้วก็ส่งต่อให้ Nginx เสิร์ฟ เรียกว่า multi-stage build ทำให้ image สุดท้ายเล็กมาก

# Stage 1: build หน้าเว็บ
FROM node:22-alpine AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

# Stage 2: เอาเฉพาะไฟล์ที่ build แล้วไปเสิร์ฟด้วย Nginx
FROM nginx:alpine
COPY --from=build /app/dist /usr/share/nginx/html
EXPOSE 80

`.dockerignore` (ใส่ทั้งใน api และ web)

กันไม่ให้ไฟล์ไม่จำเป็นถูก copy เข้าไปใน image

node_modules
dist
.env
.git

`.env`

เก็บรหัสผ่านแยกไว้ อย่า commit ขึ้น Git (ใส่ไว้ใน .gitignore)

DB_ROOT_PASSWORD=changeme

`compose.yaml`

services:
  db:
    image: mysql:8.4
    restart: unless-stopped
    environment:
      MYSQL_ROOT_PASSWORD: ${DB_ROOT_PASSWORD}
      MYSQL_DATABASE: myapp
    volumes:
      - db_data:/var/lib/mysql        # เก็บข้อมูลไว้ใน volume
    healthcheck:                       # เช็กว่า MySQL พร้อมรับ connection แล้ว
      test: ["CMD", "mysqladmin", "ping", "-h", "127.0.0.1"]
      interval: 5s
      retries: 10
    networks:
      - app-net

  phpmyadmin:
    image: phpmyadmin
    environment:
      PMA_HOST: db                     # เรียก database ด้วยชื่อ service
    ports:
      - "8080:80"
    depends_on:
      - db
    networks:
      - app-net

  api:
    build: ./api                       # build จาก api/Dockerfile
    restart: unless-stopped
    environment:
      DB_HOST: db
      DB_USER: root
      DB_PASSWORD: ${DB_ROOT_PASSWORD}
      DB_NAME: myapp
    ports:
      - "3000:3000"
    depends_on:
      db:
        condition: service_healthy     # รอจน db พร้อมจริง ๆ ค่อยเริ่ม
    networks:
      - app-net

  web:
    build: ./web                       # build จาก web/Dockerfile
    restart: unless-stopped
    ports:
      - "80:80"
    depends_on:
      - api
    networks:
      - app-net

volumes:
  db_data:

networks:
  app-net:

คำสั่ง Docker Compose ที่ใช้บ่อย

docker compose up -d               # build (ถ้ายังไม่มี) + รันทั้งระบบ
docker compose up -d --build       # build image ใหม่ แล้วรัน (ใช้หลังแก้โค้ด)
docker compose ps                  # ดูสถานะทุก service
docker compose logs -f api         # ดู log ของ api
docker compose exec db mysql -u root -p   # เข้า MySQL ใน container
docker compose restart api         # restart เฉพาะ api
docker compose down                # หยุดและลบ container + network (ข้อมูลใน volume ยังอยู่)
docker compose down -v             # ⚠️ ลบ volume ด้วย = ข้อมูลหายหมด!

รันแล้วเปิดดูได้เลย

หน้าเว็บ → http://localhost
API → http://localhost:3000
phpMyAdmin → http://localhost:8080

ข้อควรระวังเล็ก ๆ ที่ช่วยได้เยอะ

docker compose down -v จะลบ volume ข้อมูลในฐานข้อมูลหายหมด ใช้ตอนอยากล้างระบบจริง ๆ เท่านั้น
depends_on เฉย ๆ แค่รอให้ container เริ่ม ไม่ได้รอให้ฐานข้อมูลพร้อมรับ connection เลยต้องใช้ healthcheck คู่กับ condition: service_healthy แบบในตัวอย่าง
ใช้ docker compose (มีเว้นวรรค) เป็นเวอร์ชันปัจจุบัน ส่วน docker-compose (มีขีด) เป็นตัวเก่า และไม่ต้องใส่ version: บนหัวไฟล์แล้ว
บน Windows ใช้ Docker Desktop (WSL 2) container ที่รันอยู่ก็คือ Linux container เหมือนบนเซิร์ฟเวอร์ ปัญหา "Windows รันได้ Linux รันไม่ได้" เลยหายไปเกือบหมด
ระวังเรื่องสถาปัตยกรรม CPU ถ้า build บนเครื่อง ARM (เช่น Mac ชิป M) แล้วจะเอา image ไปรันบนเซิร์ฟเวอร์ x86 ให้ build ด้วย docker buildx build --platform linux/amd64 ...

สรุป

Dockerfile → build ได้ Image → run ได้ Container
Volume เก็บข้อมูลไว้ไม่ให้หายไปกับ container
Network เชื่อม container ให้เรียกหากันด้วยชื่อได้
Docker Compose รวมทุกอย่างไว้ในไฟล์เดียว สั่ง docker compose up -d คำสั่งเดียวจบ

ครั้งหน้าส่งโปรเจกต์ให้เพื่อน แค่แนบ compose.yaml ไปด้วย เพื่อนก็รันได้เหมือนเครื่องเราเป๊ะ ไม่ต้องมานั่งถามว่า "ใช้ Node เวอร์ชันไหน" อีกแล้ว 🐳

Docker คืออะไร? ทำไม dev ทั้งโลกถึงชอบเอาโค้ดไปใส่กล่อง (ฉบับเข้าใจง่าย)

reerii code — Sun, 01 Nov 2026 13:49:28 +0000

สรุปสั้นๆ ก่อนอ่าน (TL;DR)

ปัญหา: "ในเครื่องผมรันได้นะ!" แต่ที่อื่นพัง เพราะ สภาพแวดล้อมไม่เหมือนกัน

Docker = เอาแอป พร้อมทุกอย่างที่แอปต้องใช้ ใส่กล่องใบเดียว ไปรันที่ไหนก็เหมือนเดิม

จำแค่ 3 คำก่อน: Dockerfile (สูตร) → Image (แม่พิมพ์) → Container (ขนมที่รันอยู่จริง)

มีหลายกล่องเมื่อไหร่ ใช้ Docker Compose ไฟล์เดียว คำสั่งเดียว docker compose up -d

🎬 ดูแบบวิดีโอ: DEPLOY 101 EP.6 (ฉบับเต็ม) บน YouTube

1. "ในเครื่องผมรันได้นะ!" ปัญหาที่ dev ทุกคนเคยเจอ

ประโยคนี้ใครเคยพูด ยกมือขึ้น! ผมเองก็เคย และประโยคนี้แหละ คือจุดเริ่มต้นของ Docker

ทำ API เสร็จ เทสในเครื่องผ่านหมด มั่นใจเต็มร้อย แต่พอเอาไปให้เพื่อนรัน หรือขึ้น server จริง… พังแบบงงๆ ทั้งที่โค้ดเดียวกันเป๊ะ

เครื่อง	OS	Node	PostgreSQL	ผลลัพธ์
เครื่องเรา	Windows	22	16	✅ รันได้ สบายใจ
เครื่องเพื่อน	macOS	18	16	❌ บางฟีเจอร์พัง (Node เก่ากว่า)
Server จริง	Linux	20	14	❌ พังตอน migrate (DB เก่า)

ปัญหาไม่ได้อยู่ที่โค้ด แต่อยู่ที่ "สภาพแวดล้อม" (environment) — OS, เวอร์ชัน runtime, เวอร์ชัน database, library ที่ลงไว้ ไม่เหมือนกันสักเครื่อง

แถมยังมีอีก 2 ปัญหาที่ตามมาเสมอ

น้องใหม่เข้าทีม ต้องนั่งลง Node, PostgreSQL, Redis ตามเอกสารเมื่อสองปีก่อน กว่าจะรันได้ หมดไปหนึ่งวัน
เครื่องรก โปรเจกต์ A ใช้ PostgreSQL 14 โปรเจกต์ B ใช้ 16 ลงพร้อมกันก็ตีกันเรื่องพอร์ต เลิกทำแล้วก็ยังค้างอยู่ในเครื่อง

🤔 "งั้นก็ยกคอมเครื่องที่รันได้ ไปตั้งไว้ที่ server เลยสิ!"

ฟังดูบ้า แต่ถูกครึ่งนึง — Docker ก็คือการ "ยกเครื่องเราไปด้วย" แค่ไม่ต้องยกทั้งเครื่อง ยกไปแค่ กล่องใบเดียว

2. Docker คืออะไร?

Docker คือเครื่องมือที่แพ็กแอปของเรา พร้อมทุกอย่างที่แอปต้องใช้ ลงกล่องใบเดียว (Node เวอร์ชันที่ถูก, library, ไฟล์ตั้งค่า, คำสั่งรัน) กล่องนี้เรียกว่า container

นึกถึง ตู้คอนเทนเนอร์บนเรือสินค้า ข้างในเป็นทุเรียนหรือทีวี เรือไม่สนใจ ขอแค่เป็นตู้ขนาดมาตรฐาน ยกขึ้นเรือ ขึ้นรถ ลงท่าไหนก็ได้

Docker ก็เหมือนกัน แอปจะเขียนด้วย Node, Python หรือ Go ไม่สำคัญ ขอแค่อยู่ในกล่อง รันเครื่องไหนก็ได้ผลเหมือนกัน

ได้อะไรจาก Docker?

✅ รันที่ไหนก็เหมือนกัน เครื่องเรารันได้ server ก็รันได้
✅ น้องใหม่คำสั่งเดียวจบ มีแค่ Docker ไม่ต้องลง Node/DB เอง
✅ หลายเวอร์ชันอยู่ด้วยกันได้ PostgreSQL 14 กับ 16 อยู่คนละกล่อง ไม่ตีกัน
✅ เครื่องสะอาด เลิกใช้ก็ลบกล่องทิ้ง
✅ deploy ง่าย VPS, EC2, Cloud Run ก็แค่เอากล่องนี้ไปรัน

Container ไม่ใช่ VM นะ

	VM	Container
เปรียบเหมือน	🏠 บ้านทั้งหลัง	🏢 ห้องในคอนโด
มี OS ของตัวเอง	มีครบชุด	ไม่มี ใช้ kernel ร่วมกับเครื่องแม่
ขนาด	หลาย GB	หลักสิบ–ร้อย MB
เวลาเปิด	เป็นนาที	ไม่กี่วินาที

💡 บน Windows / Mac ตัว Docker Desktop จะแอบรัน Linux ตัวเล็กๆ ให้เบื้องหลัง เราไม่ต้องยุ่งเลย

3. ศัพท์ 7 คำที่ต้องรู้ (เปรียบกับการทำขนม 🍮)

1) Dockerfile = สูตรอาหาร — ไฟล์ข้อความที่จดว่ากล่องต้องมีอะไร ทำทีละขั้นยังไง (ก็คือขั้นตอนตอนเรา deploy บน EC2 เองนั่นแหละ แค่จดให้ Docker ทำแทน)

2) Image = แม่พิมพ์ — ได้จาก docker build พร้อมรัน และ แก้ไขไม่ได้ อยากเปลี่ยนต้อง build ใหม่

3) Container = ขนมจากแม่พิมพ์ — ได้จาก docker run คือของที่กำลังรันจริง แม่พิมพ์อันเดียวปั๊มได้หลายชิ้น

4) Registry = ร้านขายแม่พิมพ์ — ที่เก็บ image เช่น Docker Hub (มี PostgreSQL, Redis, Nginx สำเร็จรูป) หรือ ghcr.io ของ GitHub ไว้ฝาก image ของเราให้ server ดึงไปรัน

5) Port = เจาะรูกล่อง — กล่องปิดสนิท ข้างนอกเรียกไม่ได้ ต้องเจาะด้วย -p 5000:5000 (อ่านว่า พอร์ตเครื่องเรา : พอร์ตในกล่อง)

6) Volume = ตู้เซฟนอกกล่อง (สำคัญมาก!) — container เหมือนห้องโรงแรม เช็คเอาท์ปุ๊บ ของโดนเคลียร์ ลบกล่องเมื่อไหร่ข้อมูลหาย volume คือที่เก็บข้อมูล นอกกล่อง กล่องพังกี่รอบข้อมูลก็อยู่ ใช้กับไฟล์ database และไฟล์ที่ผู้ใช้อัปโหลด

7) Network = สายโทรศัพท์ระหว่างกล่อง — กล่องที่อยู่ network เดียวกันถึงจะคุยกันได้ และ เรียกกันด้วยชื่อกล่องได้เลย ไม่ต้องจำ IP

สรุป 7 คำในตารางเดียว

ศัพท์	เปรียบเหมือน	คำสั่งที่เกี่ยวข้อง
Dockerfile	สูตรอาหาร	(เขียนไฟล์เอง)
Image	แม่พิมพ์	`docker build`, `docker pull`, `docker images`
Container	ขนมจากแม่พิมพ์	`docker run`, `docker ps`, `docker stop`, `docker rm`
Registry	ร้านขายแม่พิมพ์	`docker pull`, `docker push`
Port	รูที่เจาะเข้ากล่อง	`-p เครื่องเรา:ในกล่อง`
Volume	ตู้เซฟนอกกล่อง	`docker volume create`, `-v`
Network	สายโทรศัพท์	`docker network create`, `--network`

จำประโยคเดียว: สูตรถูก build เป็นแม่พิมพ์ → แม่พิมพ์ถูก run เป็นกล่อง → กล่องใน network เดียวกันเรียกกันด้วยชื่อ → ข้อมูลที่ห้ามหายอยู่ใน volume

4. Image มี 2 แบบ (จุดที่มือใหม่งงที่สุด)

แบบที่ 1: สำเร็จรูป — มีคนทำให้แล้ว

PostgreSQL, MySQL, Redis, Nginx, MongoDB มี image บน Docker Hub ให้แล้ว ไม่ต้องเขียน Dockerfile ไม่ต้อง build ดึงมารันแล้วใส่ค่าตั้งต้นที่มันขอ

# คำสั่งเดียว ได้ database พร้อมใช้
docker run -d --name my_db -e POSTGRES_PASSWORD=password -p 5432:5432 postgres:16

เลข 16 คือ tag = เวอร์ชัน (postgres:14, mysql:8.4, nginx:alpine)
alpine = รุ่นที่ใช้ Linux ตัวเล็กมาก image เลยเบา

แบบที่ 2: ของเรา — ต้องทำเอง

API / Web ที่เราเขียน ไม่มีใครทำ image ให้แน่นอน ต้องลงมือเอง 5 ขั้น

เขียน Dockerfile
docker build → ได้ image
docker run → ได้ container
จัดการ network ให้ API คุยกับ DB ได้
จัดการ volume ให้ข้อมูลไม่หาย

	สำเร็จรูป	ของเรา
ตัวอย่าง	postgres, mysql, redis, nginx	API (Express, Prisma), Web (React)
ต้องเขียน Dockerfile	❌	✅
ได้มาด้วย	`docker pull`	`docker build`

5. เขียน Dockerfile ของ API ทีละบรรทัด

คำสั่งหลัก มีไม่กี่ตัว

คำสั่ง	ทำอะไร	เทียบกับลงเครื่องเอง
`FROM`	เลือก image ฐาน	ลง Node ในเครื่องเปล่า
`WORKDIR`	โฟลเดอร์ทำงานในกล่อง	`cd /app`
`COPY`	copy ไฟล์เข้ากล่อง	อัปโหลดโค้ดขึ้น server
`RUN`	รันคำสั่งตอน build	`npm ci`, `npx tsc`
`ENV`	ตั้งค่า environment	`export NODE_ENV=production`
`EXPOSE`	บอกว่าแอปใช้พอร์ตไหน	จดว่าแอปฟัง 5000
`USER`	เปลี่ยนผู้ใช้ที่รันแอป	ไม่รันด้วย root
`CMD`	คำสั่งตอนกล่องเริ่ม	`node dist/server.js`

🔑 RUN = ทำตอน build (ครั้งเดียว) · CMD = ทำตอน run (ทุกครั้งที่เปิดกล่อง)

Dockerfile ของจริง (multi-stage 3 ชั้น)

เหมือน ครัว 3 โต๊ะ: โต๊ะเตรียมของ → โต๊ะปรุง → จานเสิร์ฟ แล้วเอาไปให้ลูกค้าแค่ จานเสิร์ฟ เศษผักทิ้งไว้ในครัว

# ── Stage 1: เตรียมวัตถุดิบ (deps) ──
FROM node:20-alpine AS deps
WORKDIR /app
COPY package.json package-lock.json ./
COPY prisma ./prisma/
RUN npm ci

# ── Stage 2: ปรุง (builder) ──
FROM node:20-alpine AS builder
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY --from=deps /app/package.json ./
COPY --from=deps /app/prisma ./prisma/
COPY tsconfig.json ./
COPY src ./src/
RUN npx prisma generate && npx tsc -p tsconfig.json

# ── Stage 3: จานเสิร์ฟ (runner) = image ที่ใช้จริง ──
FROM node:20-alpine AS runner
WORKDIR /app
ENV NODE_ENV=production
RUN apk add --no-cache openssl
COPY --from=deps /app/node_modules ./node_modules
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/prisma ./prisma
COPY package.json ./
RUN mkdir -p uploads && chown -R node:node /app
USER node
EXPOSE 5000
CMD ["sh", "-c", "npx prisma migrate deploy && node dist/server.js"]

Stage 1 (deps) — ทำไม copy แค่ package.json กับ lock ก่อน ยังไม่ copy โค้ด?

เพราะ Docker จำผลแต่ละบรรทัดไว้ (layer cache) ถ้าสองไฟล์นี้ไม่เปลี่ยน รอบหน้าจะ ข้าม npm ci ไปเลย แก้โค้ดบ่อยแค่ไหนก็ไม่ต้องรอลง library ใหม่

ส่วน npm ci ลง library ตาม lock เป๊ะๆ ไม่แอบอัปเดตแบบ npm install → ทุกเครื่องได้ผลเหมือนกัน (หัวใจของ Docker)

Stage 2 (builder) — หยิบ node_modules จากชั้นแรกมาใช้ ไม่ต้องลงใหม่ แล้วค่อย copy โค้ด สร้าง Prisma Client และแปลง TypeScript → JavaScript ได้โฟลเดอร์ dist

Stage 3 (runner) — กล่องใบสุดท้ายที่เอาไปใช้จริง

apk add openssl เพราะ Prisma ต้องใช้ แต่ alpine ไม่มีมาให้
หยิบมาแค่ที่จำเป็น ไม่มีโค้ด TypeScript ต้นฉบับ → image เล็ก + ปลอดภัยขึ้น
USER node ไม่รันด้วย root ถ้าโดนเจาะ คนร้ายก็ไม่ได้สิทธิ์ root
EXPOSE เป็นแค่ป้ายบอก ยังไม่ได้เปิดพอร์ตจริง (เปิดจริงตอน -p หรือใน compose)
CMD ทุกครั้งที่กล่องเริ่ม: migrate database ก่อน แล้วค่อยเปิด server

💡 ชั้น runner ยังหยิบ node_modules ชุดเต็มมา เพราะ prisma migrate deploy ต้องใช้ Prisma CLI (มักอยู่ใน devDependencies) อยากให้เล็กลงอีก ค่อยย้าย prisma ไป dependencies แล้วใช้ npm ci --omit=dev

อย่าลืม `.dockerignore`

node_modules
dist
.env
.git
uploads
*.log

ลืม node_modules → ของที่ build มาสำหรับ Windows ติดเข้ากล่อง build ช้าและอาจพัง
ลืม .env → รหัสผ่านหลุดเข้า image ใครได้ image ไปก็เห็นหมด 🚨

Build และรัน

# ปั๊มแม่พิมพ์ (จุด . = โฟลเดอร์ที่มี Dockerfile)
docker build -t upro-pos-api .

# ดู image ที่มี
docker images

# รันเป็น container (ค่าลับส่งตอนรัน ไม่ฝังใน image)
docker run -d --name upro_api -p 5000:5000 --env-file .env upro-pos-api

-t ชื่อ image · -d รันเบื้องหลัง · --name ชื่อกล่อง · --env-file ส่งค่าลับเข้าไปตอนรัน

6. แต่! ของจริงไม่ได้มีกล่องเดียว

ระบบ POS ของผมมีอย่างน้อย 3 กล่อง: API (image ของเรา) + PostgreSQL + Nginx (สำเร็จรูป) ถ้าทำด้วยมือ…

docker network create internal
docker volume create postgres_data
docker volume create uploads_data

docker run -d --name pos_postgres --network internal --restart always \
  -e POSTGRES_USER=postgres -e POSTGRES_PASSWORD=password -e POSTGRES_DB=pos_db \
  -v postgres_data:/var/lib/postgresql/data postgres:16

docker build -t upro-pos-api .
docker run -d --name upro_api --network internal --restart unless-stopped \
  --env-file .env -v uploads_data:/app/uploads upro-pos-api

docker run -d --name upro_nginx --network internal --restart unless-stopped \
  -p 80:80 -v ./nginx/default.conf:/etc/nginx/conf.d/default.conf:ro nginx:alpine

😵 "ต้องสร้าง network เอง volume เอง เชื่อมเองหมด ใครจะไปจำไหว!"

ลืม flag ตัวเดียวก็พัง — ลืม --network API หา DB ไม่เจอ / ลืม -v ข้อมูลหาย
ต้องรันตามลำดับ — DB ต้องขึ้นก่อน API
แก้ทีต้อง stop → rm → พิมพ์ใหม่ทั้งชุด

คำสั่งพื้นฐานที่ยังใช้ทุกวัน (เวลาเช็คปัญหา):

docker ps                    # กล่องที่รันอยู่
docker ps -a                 # ทั้งหมด รวมที่หยุดแล้ว
docker logs -f upro_api      # ดู log สดๆ
docker exec -it upro_api sh  # เข้าไปในกล่อง
docker stop upro_api         # หยุด
docker rm upro_api           # ลบ

7. ไม่ต้องห่วง! Docker Compose ช่วยได้

Docker Compose = จดทุกกล่อง ทุกการเชื่อมต่อ ลงไฟล์เดียว (compose.yaml)

ถ้า Dockerfile คือ สูตรขนมหนึ่งชิ้น Compose ก็คือ เมนูจัดเลี้ยงทั้งโต๊ะ

docker compose up -d        # ขึ้นทุกกล่อง (network/volume สร้างให้เอง)
docker compose ps           # ดูสถานะ
docker compose logs -f api  # ดู log กล่อง api
docker compose pull         # ดึง image เวอร์ชันใหม่
docker compose down         # ปิดและลบทุกกล่อง (volume ยังอยู่)

	ทำด้วยมือ	Docker Compose
สร้าง network / volume	พิมพ์เอง	อัตโนมัติ
ลำดับการขึ้น	จำเอง	`depends_on`
ค่าตั้งค่า	กระจายในคำสั่งยาวๆ	ไฟล์เดียว เก็บใน git ได้
น้องใหม่เข้าทีม	ก๊อปทีละบรรทัด	`git clone` + `docker compose up -d`

🤔 "แล้ว API จะรู้ได้ไงว่า database อยู่ IP ไหน?"

ไม่ต้องรู้! ใน Compose ชื่อ service = hostname เรียก postgres:5432 ก็เจอ เหมือนโทรหาเพื่อนด้วยชื่อ ไม่ต้องจำเบอร์

8. ก่อนเขียน compose.yaml ต้องเข้าใจอะไร

Compose ไม่มีอะไรใหม่ — มันคือ flag ของ docker run ที่ย้ายมาเขียนเป็นไฟล์ YAML

YAML ซีเรียสเรื่องเว้นวรรค

ย่อหน้าด้วย space 2 ช่อง ห้ามใช้ tab
key: value ต้องมี space หลัง : เสมอ
รายการหลายตัวใช้ - นำหน้า
เช็คไฟล์ได้ด้วย docker compose config

จับคู่ docker run ↔ compose

docker run	compose.yaml
`--name upro_api`	`container_name:`
ชื่อ image	`image:` หรือ `build: .`
`-p 80:80`	`ports:`
`-e KEY=value`	`environment:`
`--env-file .env`	`env_file: .env`
`-v ชื่อ:/path`	`volumes:`
`--network internal`	`networks:`
`--restart always`	`restart:`
(ไม่มี ต้องจำเอง)	`depends_on:`
`--health-cmd …`	`healthcheck:`

เรื่องที่ต้องเข้าใจให้ขาด

ชื่อ service = hostname → DATABASE_URL=postgresql://postgres:password@postgres:5432/pos_db (คำว่า postgres หลัง @ คือชื่อ service ไม่ใช่ localhost)
ports = เปิดให้ "ข้างนอก" เข้า กล่องที่คุยกันเองใน network ไม่ต้องเปิด ยิ่งเปิดน้อยยิ่งปลอดภัย
volume 2 แบบ: named volume (postgres_data:/var/lib/...) ให้ Docker ดูแล เหมาะกับ DB / bind mount (./nginx/default.conf:/etc/...) เสียบไฟล์จากเครื่องเรา เหมาะกับ config
restart: no · always · unless-stopped (ลุกเสมอ ยกเว้นเราสั่ง stop เอง) · on-failure
depends_on บอกแค่ลำดับ ไม่ได้รอให้พร้อมจริง ต้องใช้คู่กับ healthcheck + condition: service_healthy
รหัสผ่านไม่ควรอยู่ในไฟล์ compose ย้ายไป .env แล้วใส่ .env ใน .gitignore

9. ตัวอย่าง: PostgreSQL (สำหรับคนที่รัน DB เอง)

ถ้าใช้ DB ภายนอกอยู่แล้ว (Supabase, Neon, AWS RDS) ข้ามไฟล์นี้ได้เลย แค่ใส่ DATABASE_URL ใน .env ของ API

services:
  postgres:
    image: postgres:16            # ระบุเวอร์ชันเสมอ อย่าใช้ latest กับ DB
    container_name: pos_postgres
    restart: always               # DB ต้องอยู่ตลอด
    environment:
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: password # ของจริงย้ายไป .env → ${POSTGRES_PASSWORD}
      POSTGRES_DB: pos_db
    ports:
      - "127.0.0.1:5432:5432"     # ต่อได้เฉพาะจากเครื่องตัวเอง
    volumes:
      - postgres_data:/var/lib/postgresql/data   # บรรทัดนี้คือชีวิต!
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres -d pos_db"]
      interval: 10s
      timeout: 5s
      retries: 5

volumes:
  postgres_data:

⚠️ ค่า POSTGRES_* ใช้ แค่ตอนสร้างครั้งแรก ถ้า volume มีข้อมูลแล้ว เปลี่ยนตรงนี้จะไม่มีผล ต้องไปแก้ใน database เอง

10. ตัวอย่าง: API + Nginx (ไฟล์จริงที่ใช้ deploy)

services:
  api:
    image: ghcr.io/reeriicode/upro-pos-api:latest   # ดึง image สำเร็จจาก registry
    container_name: upro_api
    restart: unless-stopped
    env_file: .env                                  # ค่าลับอยู่บน server
    volumes:
      - uploads_data:/app/uploads                   # รูปที่อัปโหลดไม่หาย
    networks:
      - internal
    # ไม่มี ports — ตั้งใจ! ข้างนอกต้องผ่าน Nginx เท่านั้น

  nginx:
    image: nginx:alpine
    container_name: upro_nginx
    restart: unless-stopped
    ports:
      - "80:80"                                     # กล่องเดียวที่เปิดออกโลก
    volumes:
      - ./nginx/default.conf:/etc/nginx/conf.d/default.conf:ro
    depends_on:
      - api
    networks:
      - internal

volumes:
  uploads_data:

networks:
  internal:
    driver: bridge

ทำไมเขียนแบบนี้?

image: แทน build: . — server ไม่ต้องมีโค้ด ไม่ต้องลง Node ไม่ต้องเสียแรง build แค่ดึงแม่พิมพ์มารัน
restart: unless-stopped — ล้มก็ลุก reboot ก็ลุก แต่ถ้าเราตั้งใจ stop จะไม่ดื้อลุกเอง
uploads_data — รูปสินค้าอยู่ในตู้เซฟ อัปเดตกี่รอบก็ไม่หาย (ปัญหารูปหายใน EP แรก จบตรงนี้)
api ไม่มี ports — API ปลอดภัยขึ้น
:ro — กล่องแก้ไฟล์ config เราไม่ได้ (read-only)

nginx/default.conf

server {
    listen 80;
    server_name _;
    client_max_body_size 10M;          # อัปโหลดได้ถึง 10MB

    location / {
        proxy_pass http://api:5000;    # api = ชื่อ service ใน compose
        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;
    }
}

เห็น http://api:5000 ไหม? นี่แหละ ชื่อ service ใช้แทน IP

อยากรวม PostgreSQL ไว้ในไฟล์เดียวกัน

แยกไฟล์ compose = คนละ network เรียกชื่อกันไม่เจอ วิธีง่ายสุดคือรวมไฟล์เดียว แล้วให้ API รอจน DB พร้อมจริง

  api:
    # ...
    depends_on:
      postgres:
        condition: service_healthy   # รอจน pg_isready ผ่านก่อน

Deploy ทั้งวงจร

# ── ที่เครื่องเรา ──
docker build -t ghcr.io/reeriicode/upro-pos-api:latest .
docker push ghcr.io/reeriicode/upro-pos-api:latest

# ── ที่ server ── (มีแค่ compose.yaml, .env, nginx/default.conf)
docker compose pull
docker compose up -d
docker compose logs -f api

🍎 เครื่องเป็น Mac ชิป M แต่ server เป็น Linux x86 → docker build --platform linux/amd64 ...

11. Nginx ต้องมีไหม?

สถานการณ์	ต้องมี Nginx ไหม	กล่อง API เปิด ports ไหม
พัฒนาในเครื่อง	❌ ไม่ต้อง	เปิด `5000:5000`
deploy ขึ้น VPS / EC2	✅ แนะนำ	ไม่เปิด ให้ Nginx ส่งต่อ
Cloud Run / แพลตฟอร์มที่มี proxy	❌ ไม่ต้อง	ตามแพลตฟอร์ม

ตอน deploy Nginx ช่วย: ซ่อน API ไว้ข้างหลัง · ทำ HTTPS ที่เดียว · จำกัดขนาดไฟล์อัปโหลด · เสิร์ฟไฟล์ static เร็ว · หลายแอปบน server เดียว (api.example.com, admin.example.com)

12. มือใหม่ชอบพลาดตรงไหน?

ลืม .dockerignore → node_modules ติดเข้ากล่อง build ช้า/พัง
ยัดรหัสผ่านไว้ใน image → ห้ามเด็ดขาด! ส่งผ่าน env_file ตอนรัน
ใช้ localhost ในกล่อง → localhost = ตัวกล่องเอง ต้องเรียกชื่อ service (postgres, api)
DB ไม่ใช้ volume → ลบกล่องทีเดียว ข้อมูลหายทั้งก้อน
docker compose down -v → -v ลบ volume ด้วย ข้อมูลหายหมด กดเล่นไม่ได้!
เปิด ports ทุกกล่อง → DB เปิด 5432 ให้ทั้งโลก = เชิญมาเดารหัส
แก้ env ของ PostgreSQL แล้วไม่เปลี่ยน → ใช้แค่ตอนสร้างครั้งแรก
build บน Mac ชิป M แล้ว server รันไม่ได้ → ใส่ --platform linux/amd64
YAML ย่อหน้าเพี้ยน → เช็คด้วย docker compose config

13. สรุป

ปัญหา "ในเครื่องเรารันได้ ที่อื่นพัง" เพราะสภาพแวดล้อมไม่เหมือนกัน
แก้ด้วย Docker แพ็กแอปพร้อมทุกอย่างลงกล่อง ไปรันที่ไหนก็เหมือนกัน
Dockerfile สูตร → Image แม่พิมพ์ → Container ของจริงที่รัน + Volume ตู้เซฟ + Network สายโทรศัพท์
Image สำเร็จรูป (PostgreSQL, Nginx) ดึงมาใช้ได้เลย ส่วน API ของเราต้องเขียน Dockerfile แล้ว build เอง
หลายกล่องพิมพ์ยาวเหยียด → Docker Compose ไฟล์เดียว คำสั่งเดียว
Nginx: ตอนพัฒนาไม่ต้องมี ตอน deploy แนะนำให้มี

EP หน้า มาลองจับ API ของเรายัดลงกล่องกันจริงๆ deploy รอบหน้าไม่ต้องนั่งลง Node ใหม่อีกแล้ว ฮ่าๆ 🐳📦

DEPLOY 101 — สอน deploy แบบภาษาคน · ติดตามตอนต่อไปได้ที่ dev.to/reeriicode

เลิกให้ API นอนแก้ผ้ารอหน้าบ้าน! ซ่อนหลัง Nginx ซ่ะ

reerii code — Mon, 26 Oct 2026 08:12:05 +0000

บทความนี้เราจะมาทำ Reverse Proxy ด้วย Nginx กัน

โปรเจกต์ของผม frontend deploy ด้วย Vercel ได้ https://uprodd.vercel.app อันนี้ง่าย จบแล้ว อ่าน deploy FE ส่วน backend deploy บน AWS EC2 แบบ VPS อ่าน deploy BE

สิ่งที่ผมได้คือ http://เลขไอพี:5000 ซึ่งก็คือ API ของผมนั่นเอง ผมต้องเปิดพอร์ต 5000 ให้ frontend เข้ามาเรียกได้ ซึ่งไม่ค่อยแนะนำเท่าไหร่

สิ่งที่ผมจะทำคือให้เรียก API ผ่าน http://เลขไอพี/ แทน ปกติแล้ว / ควรเป็นหน้าเว็บ และ /api ควรเป็น API เผื่ออนาคตจะ deploy frontend ไว้ที่ server เดียวกัน แต่ในบทความนี้ผมจะให้ / เป็นของ API ไปก่อน

ทำไมน่ะเหรอ? ก็เพราะมันทำได้ไงล่ะ hahaha

อันนี้คือจะให้เห็นว่า Nginx สามารถกำหนดให้ชี้ไปไหนก็ได้

1. Login เข้า server

ssh -i "ชื่อไฟล์.pem" ec2-user@เลขไอพี

2. เช็กเวอร์ชัน Linux

cat /etc/os-release | grep PRETTY

ของผมเป็น Amazon Linux 2023 ซึ่งใช้ dnf ในการติดตั้งโปรแกรม

3. ติดตั้ง Nginx

sudo dnf install -y nginx

Nginx จะติดตั้งตัวโปรแกรมและสร้างโฟลเดอร์ตั้งค่าไว้ที่ /etc/nginx/ ให้เอง

sudo systemctl enable --now nginx

เปิดใช้งาน Nginx ทันที และตั้งให้ทำงานเองทุกครั้งที่เปิดเครื่อง

4. สร้างไฟล์ตั้งค่า

sudo tee /etc/nginx/conf.d/upro-api.conf > /dev/null <<'EOF'
# จำกัดจำนวน request กันยิงถล่ม
limit_req_zone $binary_remote_addr zone=api_limit:10m rate=20r/s;

server {
    listen 80 default_server;
    server_name ใส่IPเรา;

    server_tokens off;              # ซ่อนเวอร์ชัน Nginx
    client_max_body_size 10m;       # จำกัดขนาด upload

    add_header X-Content-Type-Options "nosniff" always;
    add_header X-Frame-Options "DENY" always;
    add_header Referrer-Policy "no-referrer" always;

    # กันบอทที่สแกนหา .env .git
    location ~ /\. {
        return 404;
    }

    location / {
        limit_req zone=api_limit burst=40 nodelay;

        proxy_pass http://127.0.0.1:5000;
        proxy_http_version 1.1;
        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;

        proxy_connect_timeout 10s;
        proxy_read_timeout 60s;
    }
}
EOF

แบบง่าย ๆ คำสั่งนี้คือ สร้างไฟล์ upro-api.conf (ตั้งชื่ออะไรก็ได้ ขอให้ลงท้ายด้วย .conf) ไว้ในโฟลเดอร์ /etc/nginx/conf.d/ ที่ Nginx สร้างไว้ให้ โดยเอาข้อความทั้งหมดจนถึงคำว่า EOF ไปเป็นเนื้อหาไฟล์

ให้นึกภาพว่า Nginx เป็น ยามหน้าบ้าน ส่วน API ที่พอร์ต 5000 เป็น เจ้าของบ้านที่อยู่ข้างใน

ข้างล่างนี้คือเนื้อหาไฟล์เดียวกัน แต่ใส่คำอธิบายไว้ทุกบรรทัด เอาไว้อ่านทำความเข้าใจ ตอนสร้างจริงใช้ฉบับข้างบนก็พอ

# ── กฎกลาง: ตั้งโควตาก่อน ──
# จำว่าแต่ละ IP ยิงมากี่ครั้ง ให้ได้ไม่เกิน 20 ครั้งต่อวินาที
# จองหน่วยความจำ 10 MB ไว้จด (จดได้ราวแสนกว่า IP)
limit_req_zone $binary_remote_addr zone=api_limit:10m rate=20r/s;

server {
    # ยามยืนเฝ้าประตูพอร์ต 80 (HTTP)
    # default_server = ถ้าคำขอไม่ตรงกับ server อื่น ให้มาที่นี่
    listen 80 default_server;

    # ใช้กับคนที่เข้ามาทาง IP นี้ (ยังไม่มีโดเมน)
    server_name ใส่IPเรา;

    # ไม่บอกคนนอกว่าใช้ Nginx เวอร์ชันไหน คนร้ายจะได้หาช่องโหว่ยากขึ้น
    server_tokens off;

    # อัปโหลดไฟล์ได้ไม่เกิน 10 MB ต่อครั้ง เกินนี้ไม่รับ
    client_max_body_size 10m;

    # ── ส่งคำเตือนความปลอดภัยไปให้เบราว์เซอร์ ──
    # ห้ามเบราว์เซอร์เดาชนิดไฟล์เอง (กันไฟล์ปลอมตัว)
    add_header X-Content-Type-Options "nosniff" always;
    # ห้ามเว็บอื่นเอาหน้าเราไปฝังใน iframe (กันหลอกให้กด)
    add_header X-Frame-Options "DENY" always;
    # เวลากดลิงก์ออกไปเว็บอื่น ไม่ต้องบอกว่ามาจากหน้าไหน
    add_header Referrer-Policy "no-referrer" always;

    # ── ด่านที่ 1: ไล่บอทที่มาหาไฟล์ลับ ──
    # ใครขอ path ที่มีจุดนำหน้า เช่น /.env หรือ /.git
    # ให้ตอบว่า "ไม่มีหน้านี้" (404)
    location ~ /\. {
        return 404;
    }

    # ── ด่านที่ 2: คำขอทั่วไปทั้งหมด ──
    location / {
        # ใช้โควตา 20 ครั้งต่อวินาทีที่ตั้งไว้ข้างบน
        # ยอมให้พุ่งเกินได้อีก 40 ครั้ง (เช่นตอนเปิดหน้าเว็บที่เรียกหลายอย่างพร้อมกัน)
        # เกินจากนั้นปฏิเสธทันที
        limit_req zone=api_limit burst=40 nodelay;

        # ★ หัวใจของ Reverse Proxy ★
        # ส่งคำขอต่อไปให้ API ที่อยู่ในเครื่องเดียวกัน พอร์ต 5000
        proxy_pass http://127.0.0.1:5000;

        # คุยกับ API ด้วย HTTP เวอร์ชัน 1.1
        proxy_http_version 1.1;

        # ── แนบข้อมูลของผู้ใช้จริงไปให้ API ──
        # (ไม่งั้น API จะเห็นทุกคนเป็น "ยาม" คือ 127.0.0.1 หมด)
        # ผู้ใช้พิมพ์ชื่อเว็บอะไรเข้ามา
        proxy_set_header Host $host;
        # IP จริงของผู้ใช้
        proxy_set_header X-Real-IP $remote_addr;
        # เส้นทาง IP ที่ผ่านมาทั้งหมด
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        # ผู้ใช้เข้ามาด้วย http หรือ https
        proxy_set_header X-Forwarded-Proto $scheme;

        # ── เวลารอ ──
        # ต่อหา API ไม่ติดภายใน 10 วินาที ให้ยกเลิก
        proxy_connect_timeout 10s;
        # รอ API ตอบได้นานสุด 60 วินาที
        proxy_read_timeout 60s;
    }
}

จะเห็นว่าเรากำหนดได้ทั้งว่าจะชี้ไปทางไหน และตั้งกฎให้คนที่เข้ามาเรียก API ของเราได้ด้วย

5. ตรวจไฟล์ แล้วสั่งให้ Nginx ใช้ค่าใหม่

sudo nginx -t && sudo systemctl reload nginx

nginx -t เช็กว่าไฟล์ตั้งค่าเขียนถูกไหม ถ้าผ่านค่อย reload ให้ Nginx อ่านค่าใหม่ โดยไม่ต้องปิดเว็บ

6. ทดสอบ

curl -I http://localhost/

ลองยิงเข้า / ที่เครื่องตัวเอง คำขอจะผ่าน Nginx แล้วถูกส่งต่อไปที่ API พอร์ต 5000

ผลที่ได้

API ของเราใช้งานผ่าน Nginx ได้แล้ว

7. ปิดพอร์ต 5000

ตอนนี้พอร์ต 5000 ที่เคยเปิดไว้ต้องปิดได้แล้ว เพราะทุกคนต้องเข้าผ่านพอร์ต 80/443 เท่านั้น ถึงตอนนี้จะยังไม่ได้จดโดเมนก็ตาม แต่ใน EP นี้อยากให้เห็นการตั้งค่า Nginx แบบง่าย ๆ ก่อน งั้นไปปิดพอร์ตกัน

ไปที่ AWS → Security Group

กดที่ Security Group ID ของเรา

ไปที่ Edit inbound rules

แก้ rule ที่เคยเป็นพอร์ต 5000 ให้เป็นพอร์ต 80 ตามรูป ตอนนี้ที่เปิดไว้คือ

22 สำหรับ SSH
80 สำหรับ HTTP
443 สำหรับ HTTPS (เปิดเผื่อไว้ตอนมีโดเมน)

แล้วกด Save

ปิดแค่ที่ Security Group นะ ตัว API ยังรันอยู่ที่พอร์ต 5000 เหมือนเดิม แค่คนข้างนอกเข้าตรงไม่ได้แล้ว แต่ Nginx ที่อยู่เครื่องเดียวกันยังส่งต่อไปได้ปกติ

ตอนนี้เข้าแบบ :5000 ไม่ได้แล้ว ต้องเรียก http://เลขไอพี/ แทน อย่าลืมไปแก้ URL ของ API ฝั่ง frontend ให้ตัด :5000 ออกด้วย

หน้าเว็บดึงข้อมูลได้ปกติ แค่นี้ก็เรียบร้อยแล้ว ได้โดเมนเมื่อไหร่เดี๋ยวมาทำ HTTPS ต่อนะครับ

จัดการ Server เองอาจจะโดนซอยตูดได้ เพราะงันต้องทำ Nginx ด้วยน่ะจ่ะ ทำไงมาดูกัน

reerii code — Sat, 24 Oct 2026 07:52:12 +0000

ปัญหาของการเปิดพอร์ตตรง ๆ

ลองนึกภาพว่าเราทำเว็บเสร็จแล้ว บนเซิร์ฟเวอร์มีโปรแกรม 2 ตัว รันอยู่คนละพอร์ต

Frontend (หน้าเว็บ) รันที่พอร์ต 3000
Backend (API) รันที่พอร์ต 8000

วิธีที่ง่ายที่สุดคือเปิดพอร์ตทั้งสองให้คนนอกเข้าได้ตรง ๆ ผู้ใช้ก็เข้าเว็บได้ทันที แต่ทำแบบนี้ก็เหมือนบ้านที่เปิดประตูทุกห้องออกสู่ถนน โดยไม่มียามเฝ้าสักคน

ปัญหาที่จะตามมา

URL จำยาก ดูไม่น่าเชื่อถือ ผู้ใช้ต้องพิมพ์ http://203.0.113.10:3000 หรือ http://203.0.113.10:8000 ถึงจะมีโดเมนก็ยังต้องต่อท้ายด้วยพอร์ต เช่น http://example.com:3000 แถมยังไม่มี HTTPS เบราว์เซอร์จะขึ้นเตือนว่า "ไม่ปลอดภัย"
โดนบอตสแกนพอร์ต เซิร์ฟเวอร์ที่เพิ่งเปิดอาจโดนสแกนภายในไม่กี่นาที ยิ่งเปิดพอร์ตไว้มาก ก็ยิ่งมีประตูให้ลองงัดมาก
ไม่มีการจำกัดจำนวน request (Rate Limit) ใครจะยิงเข้ามาเป็นหมื่นครั้ง หรือเดารหัสผ่านซ้ำไปเรื่อย ๆ ก็ทำได้ จนเซิร์ฟเวอร์รับไม่ไหว
หน้าผู้ดูแลระบบเปิดโล่ง path อย่าง /api/admin/users ใครรู้ URL ก็ลองเข้าได้ ไม่มีด่านกั้นก่อนถึงตัว API
อัปโหลดไฟล์ใหญ่แค่ไหนก็ได้ ถ้าไม่จำกัดขนาด มีคนส่งไฟล์ใหญ่ ๆ เข้ามาไม่กี่ครั้ง ดิสก์หรือหน่วยความจำก็เต็มได้

แก้ปัญหาเหล่านี้ด้วย Nginx

Nginx คืออะไร?
Nginx คือโปรแกรมเว็บเซิร์ฟเวอร์ที่ติดตั้งบนเครื่องเซิร์ฟเวอร์ คอยรับคำขอ (request) จากเบราว์เซอร์ แล้วส่งข้อมูลกลับไป (response) ผ่าน HTTP หรือ HTTPS

จริง ๆ แล้ว Nginx ทำได้หลายหน้าที่

Web Server เสิร์ฟไฟล์หน้าเว็บ (HTML, CSS, JS, รูปภาพ) ให้ผู้ใช้โดยตรง
Reverse Proxy ยืนอยู่หน้าแอปของเรา รับคำขอแทน แล้วส่งต่อไปยังแอปที่รันอยู่ข้างใน เช่น API ที่ localhost:8000 พอได้ผลลัพธ์ก็ส่งกลับให้ผู้ใช้
- รวมหลายบริการไว้ใต้โดเมนเดียวได้ เช่น /api ไปที่ API ส่วน / ไปที่หน้าเว็บ
Load Balancer แบ่งคำขอไปให้เซิร์ฟเวอร์หลายตัวที่ทำงานเหมือนกัน จะได้ไม่มีตัวไหนรับงานหนักเกินไป วิธีแบ่งที่ใช้บ่อย
- Round Robin: แจกวนไปทีละตัวตามลำดับ
- Least Connections: ส่งให้ตัวที่มีงานค้างน้อยที่สุด
- IP Hash: ผู้ใช้คนเดิมได้ไปที่ตัวเดิมทุกครั้ง
อื่น ๆ เช่น ทำ HTTPS, จำกัดจำนวน request, จำกัดขนาดไฟล์อัปโหลด, บล็อกบาง path หรือบาง IP และเก็บ cache

แบบเดิม (เปิดพอร์ตตรง)

แต่ถ้ามี Nginx คั่นกลาง

จะเห็นว่าผู้ใช้เข้ามาทางประตูเดียว (พอร์ต 80/443) แล้ว Nginx จะพาไปที่ไหนก็ได้ตามที่เราตั้งไว้ ถ้ามีโดเมนเดียวก็แบ่งตาม path

example.com/ → localhost:3000 (หน้าเว็บ)
example.com/api → localhost:8000 (API)

ถ้ามีหลายโดเมนหรือ subdomain ก็แยกตามชื่อได้ เช่น

n8n.example.com → localhost:5678 (n8n)

จากนั้นใช้ firewall (เช่น ufw) ปิดพอร์ต 3000, 8000, 5678 ไม่ให้คนนอกเข้าตรง ๆ เหลือเปิดแค่ 80 กับ 443 ทุกคำขอจึงต้องผ่าน Nginx ก่อนเสมอ

ถึงตรงนี้หลายคนอาจสงสัยว่า ทำไม Nginx ต้องเปิดถึง 2 พอร์ต?

พอร์ต 80 ใช้กับ HTTP (ไม่เข้ารหัส)
พอร์ต 443 ใช้กับ HTTPS (เข้ารหัส มีรูปแม่กุญแจ)

การจะใช้ HTTPS ได้ต้องมีใบรับรอง SSL ซึ่งใบฟรีอย่าง Let's Encrypt ปกติจะออกให้กับโดเมน ถ้ายังไม่มีโดเมนก็ใช้ HTTP ผ่านพอร์ต 80 ไปก่อน

พอมีโดเมนและได้ใบรับรองแล้ว ก็ตั้งค่าให้ใครที่เข้ามาทาง HTTP (พอร์ต 80) ถูกส่งเตะไปที่ HTTPS (พอร์ต 443) ทันที แต่ยังต้องเปิดพอร์ต 80 ไว้นะ เพราะต้องใช้รับคนที่พิมพ์ http:// เข้ามา ก็ใช้พอร์ต 80 ตรวจสอบโดเมนตอนต่ออายุใบรับรองด้วย

สรุปคือ ทุกคนต้องเข้ามาทาง 80/443 เท่านั้น แล้วให้ Nginx เป็นด่านตรวจคำขอตามกฎที่เราตั้งไว้ เช่น จำกัดจำนวน request จำกัดขนาดไฟล์ หรือบล็อกบาง path

ส่วนพอร์ต 3000, 8000, 5678 ที่บอกว่า "ปิด" ไม่ได้แปลว่าปิดแอปนะ แค่ปิดที่ firewall ไม่ให้คนข้างนอกเข้าตรง ๆ ได้ แต่ในเครื่องเดียวกันยังใช้งานได้ปกติ Nginx จึงยังส่งต่อไปที่ localhost:3000 ได้เหมือนเดิม

ในบทความนี้จะเน้นเรื่อง Reverse Proxy เป็นหลักน่ะ บางคนอาจไม่เห็นภาพ เรามาทำ Reverse Proxy ง่ายๆ โดยยังไม่มี Domain น่ะ hahaha ว่าทำยังไง จะได้เห็นภาพมากขึ้น อ่านต่อเลิกให้ API นอนแก้ผ้ารอหน้าบ้าน! ซ่อนหลัง Nginx ซ่ะ

Deploy API เเบบ VPS โดยใช้ AWS EC2(free) Express, Prisma

reerii code — Sat, 17 Oct 2026 15:01:41 +0000

หลังจากที่เราได้เข้าใจการ deploy คร่าว ๆ แล้ว จาก deploy คืออะไร?

เรามาลองทำจริงกันเลยดีกว่า ก่อนอื่นเราจะใช้เจ้าไหนดี อันนี้แล้วแต่ชอบเลย มีทั้ง Oracle Cloud, Google Cloud, AWS

แน่นอนผมต้องใช้ของฟรีอยู่แล้ว เลือกมาหนึ่งเจ้า ผมเลือก AWS ละกัน ต้องบอกก่อนว่าเป้าหมายของเราคือ ต้องการเครื่อง server หรือคอมพิวเตอร์ 1 เครื่องที่อยู่บน cloud ซึ่งจะได้เลข IP Public มา นั่นคือที่อยู่ของ server เรา และนั่นแหละคือสิ่งที่เราต้องการ

ไปที่เว็บ AWS

ก่อนอื่นต้องสมัครก่อนเว้ย

สิ่งที่เขาให้เราคือเครดิต 100 ดอลลาร์ตอนสมัคร และได้เพิ่มอีกสูงสุด 100 ดอลลาร์เมื่อลองใช้บริการพื้นฐานของ AWS (ไปอ่านเพิ่มเติมได้นะ) หลังจากนั้นก็ยืนยัน Gmail ให้เรียบร้อย แล้วก็ใส่เลขบัตรให้เรียบร้อยด้วย ไม่ต้องกลัวโดนหักเงินนะจ๊ะ

Free Plan: ไม่มีค่าใช้จ่ายจนกว่าจะเปลี่ยนเป็น Paid Plan แต่ใช้ได้ไม่ครบทุกบริการ ถ้าลืมปิดเครื่อง ค่าใช้จ่ายจะหักจากเครดิต ไม่ใช่บัตรเครดิต ข้อควรระวังคือ AWS จะปิดบัญชีอัตโนมัติเมื่อครบ 6 เดือน หรือเมื่อเครดิตหมด แล้วแต่อย่างไหนถึงก่อน และขยายเกิน 6 เดือนไม่ได้ เว้นแต่จะอัปเกรดเป็น Paid Plan (หลังบัญชีปิด ยังมีเวลา 90 วันให้อัปเกรดเพื่อเปิดบัญชีกลับมาได้)

เลือก Free แล้วกด Complete sign up ได้เลย
หลังจากนั้นจะมาที่หน้านี้

แน่นอนว่าต้องไปที่ Console

เปิด sidebar

ไปที่ EC2

EC2 คืออะไร?

EC2 (Elastic Compute Cloud) คือบริการเช่าเครื่องเซิร์ฟเวอร์เสมือน (virtual machine) บน AWS เทียบได้กับ VPS ทั่วไป คือได้เครื่อง Linux มา 1 เครื่อง
ไปที่ Instances (instance = เครื่องเซิร์ฟเวอร์หนึ่งเครื่อง)

แน่นอนว่าเราเลือกระบบปฏิบัติการที่ถนัดได้เลย
ปกติก็จะเลือก Ubuntu
คิดว่าผมจะเลือก Ubuntu ล่ะสิ ไม่! ผมจะเลือก Amazon Linux ทำไมน่ะหรอ ก็เพราะไม่เคยลองไง แค่อยากลองเฉย ๆ hahaha!

เออ! ตามนี้ละกัน ที่จริงไม่ต้องตั้งค่าอะไรเลย ใช้ค่าเริ่มต้นได้ แต่ที่เราต้องสนใจคือ Key pair

Key pair คืออะไร?

Key pair คือ "กุญแจ" สำหรับเข้าเครื่อง instance ผ่าน SSH ใช้แทนรหัสผ่าน มี 2 ชิ้นที่ทำงานคู่กัน

Public key (กุญแจสาธารณะ): AWS ฝังไว้ในเครื่อง instance ให้ เปรียบเหมือนแม่กุญแจที่ติดไว้หน้าประตู
Private key (กุญแจส่วนตัว): ไฟล์ที่เราดาวน์โหลดเก็บไว้ เปรียบเหมือนลูกกุญแจ ใครมีไฟล์นี้ก็เข้าเครื่องได้

หยุด ๆ ๆ ไม่ต้องอธิบายยาวขนาดนั้นก็ได้ ที่จริงมันคือไฟล์ที่เอาไว้ login แค่มีไฟล์นี้ก็เข้าไปใช้งานเครื่อง server ได้แล้ว (เพราะงั้นห้ามทำหาย และห้ามส่งให้ใครเด็ดขาด)

ตั้งชื่อไฟล์ แล้วเลือก type จะเป็น RSA หรือ ED25519 ก็ได้ ED25519 ใหม่กว่าและสั้นกว่า แต่ RSA รองรับโปรแกรมได้กว้างกว่า ผมเลือกตามนี้ ส่วนนามสกุลไฟล์แล้วแต่เลย (ใช้ CMD/Terminal ให้เลือก .pem ถ้าใช้ PuTTY ให้เลือก .ppk) พอกด Create key pair มันก็จะดาวน์โหลดไฟล์ให้ทันที ง่ายยยยย

ส่วนอันนี้คือ

Allow SSH traffic from (พอร์ต 22): ช่องสำหรับเข้าไปสั่งงานเครื่องผ่าน terminal ต้องติ๊กไว้ ไม่อย่างนั้นเข้าเครื่องไม่ได้นะเว้ย ส่วนช่องข้าง ๆ แนะนำให้เลือก My IP (เฉพาะ IP เราเข้าได้) ถ้าเลือก Anywhere บอตทั่วโลกจะมาสุ่มเจาะพอร์ตนี้ทั้งวัน
Allow HTTPS traffic from the internet (พอร์ต 443): สำหรับเว็บแบบ https:// ใช้ตอนเรามี domain แล้ว
Allow HTTP traffic from the internet (พอร์ต 80): สำหรับเว็บแบบ http://

ที่จริงอันนี้ต้องอธิบายอีกทีในหัวข้อ Nginx ว่าทำไมต้องเปิดพอร์ตเหล่านี้ด้วย ตอนนี้ติ๊กแค่ข้อแรกก่อน
ที่เหลือใช้ค่าเริ่มต้นไปเลย ไว้มาแก้ทีหลังได้

กดสร้างเครื่องที่ Launch instance แค่นี้เราก็ได้เครื่อง server มาแล้ว ง่ายยยยยยยใช่ไหมล่ะ

EZ

หลังจากนั้นกด View all instances

และนี่คือเครื่องที่เราสร้างเมื่อกี้ มีสถานะเป็น Running คือกำลังทำงานอยู่
กดเข้าไปก็จะเห็นรายละเอียดต่าง ๆ ที่เรากำหนดไว้

และแน่นอนว่าสิ่งที่เราอยากได้ก็คือเลข IP Public นั่นเอง

⚠️ ระวัง: ถ้าเรากด Stop แล้ว Start เครื่องใหม่ เลข IP Public จะเปลี่ยน (แค่ Reboot ไม่เปลี่ยน) ถ้าอยากได้ IP ถาวรให้ไปขอ Elastic IP มาผูกกับเครื่อง (มีค่าใช้จ่าย หักจากเครดิต)

หลังจากนั้นเลื่อนลงมา

กดที่ Security เพื่อดูว่าเราเปิดพอร์ตอะไรไว้บ้าง

พอร์ต 22 คือที่เราจะ login เข้าไปแบบ SSH ส่วน 443 กับ 80 เป็นเรื่องของ Nginx นะจ๊ะ hahaha

การ login ด้วยไฟล์ .pem

เปิด CMD ในโฟลเดอร์ที่มีไฟล์ .pem (ของผมอยู่ที่ Downloads) แล้วใช้คำสั่ง

ssh -i ชื่อไฟล์.pem ec2-user@IP-Public

ใครใช้ Mac หรือ Linux ต้องสั่ง chmod 400 ชื่อไฟล์.pem ก่อน ไม่งั้น ssh จะไม่ยอมให้เข้า พร้อมขึ้นข้อความ UNPROTECTED PRIVATE KEY FILE

เข้าเครื่องได้แล้ว ต่อไปเราต้องการ clone project ของเราลงมา ซึ่งต้องใช้คำสั่ง Git ใช่ไหมล่ะ ก็ต้องติดตั้ง git ก่อน แล้วก็ Node ด้วย เพราะเราจะรัน API Express ของเรา

sudo dnf install -y git

curl -fsSL https://rpm.nodesource.com/setup_22.x | sudo bash -
sudo dnf install -y nodejs

เลือกเวอร์ชันให้ตรงกับที่ API เราใช้ (ตัวอย่างนี้คือ 22)

node -v && npm -v

เช็กเวอร์ชันของ Node กับ npm
แค่นี้ก็เรียบร้อย ไปขั้นตอนถัดไปกัน

โหลด Project ลงมา

git clone url

ถ้า project เป็น Public ก็ clone ได้เลย แต่ถ้าเป็น Private ล่ะ เราต้องยืนยันว่า project นี้เป็นของเราจริง ๆ ทำยังไง? ก็เอา Token จาก GitHub มายืนยัน ง่ายมาก ไปที่

Settings → Developer settings → Personal access tokens → Tokens (classic)

กด Generate new token (classic) เพื่อสร้าง token

ตั้งชื่อ แล้วติ๊กสิทธิ์ที่ต้องใช้ ผมติ๊กแค่ repo แล้วกดสร้าง

ทางเลือกที่ปลอดภัยกว่า: ใช้ Fine-grained token แล้วให้สิทธิ์แค่ repo นี้ repo เดียว แบบ Contents: Read-only พอ ถ้า token หลุดก็เสียหายน้อยกว่า

อย่าลืมนะฮะ ต้อง copy เก็บไว้ให้ดี เพราะพอปิดหน้านั้นไป token จะไม่โชว์อีกแล้ว ฟิ้ววว
ได้มาแล้วก็กลับไปที่ server

git clone url

มันจะให้ใส่ Username ของ GitHub ส่วนช่อง Password ให้วาง Token ที่เพิ่งได้มา (ไม่ใช่รหัสผ่าน GitHub นะ)

แค่นี้ก็เรียบร้อยแล้ววววว

การตั้งค่า .env

เข้าไปในโฟลเดอร์ project แล้วสร้างไฟล์ .env

ls

cd ชื่อProject

nano .env

วางค่า env ของ Production ลงไป เสร็จแล้วกด Ctrl + X เพื่อออก มันจะถามว่า Save modified buffer? ให้กด Y แล้ว Enter

ติดตั้ง package, migrate และ build

ก่อนอื่นต้องติดตั้ง package ก่อน (เครื่องใหม่ยังไม่มี node_modules)

npm ci

แล้วค่อยรันต่อ

npm run prisma:deploy && npm run db:seed && npm run build

prisma migrate deploy สร้างหรืออัปเดตตารางใน Supabase ตาม migration ที่มีอยู่
db:seed ใส่ข้อมูลตั้งต้น
build คอมไพล์โค้ด API

ขึ้นแบบนี้ก็แสดงว่าถูกต้องเรียบร้อย
ลองเช็กดู

ls

ถ้าเห็นโฟลเดอร์ชื่อ dist คือไฟล์ที่ build แล้ว ที่เหลือแค่สั่ง run

รันด้วย PM2

sudo npm i -g pm2

ติดตั้ง PM2 แบบ global (ใช้ได้ทั้งเครื่อง) PM2 เป็นตัวจัดการโปรเซสของ Node.js ทำหน้าที่

รันแอปเป็นเบื้องหลัง ปิด terminal แล้วแอปยังทำงานต่อ
ถ้าแอป crash จะรีสตาร์ตให้เอง
เก็บ log ไว้ดูย้อนหลัง

pm2 start dist/server.js --name upro-api

สั่งรันไฟล์ dist/server.js ที่ได้มาจาก npm run build เมื่อกี้ และตั้งชื่อโปรเซสว่า upro-api ไว้เรียกใช้ทีหลัง

pm2 save

บันทึกรายการโปรเซสที่รันอยู่ตอนนี้

แต่ pm2 save อย่างเดียวยังไม่พอนะ ถ้าเครื่องรีบูต API จะไม่เปิดขึ้นมาเอง ต้องสั่งอีกคำสั่ง

pm2 startup

มันจะพิมพ์คำสั่งที่ขึ้นต้นด้วย sudo env PATH=... ออกมา ให้ copy คำสั่งนั้นไปรัน แล้วตามด้วย pm2 save อีกรอบ แค่นี้รีบูตกี่ทีแอปก็กลับมาเอง

คำสั่ง PM2 ที่ใช้บ่อย

pm2 list ดูสถานะ
pm2 logs upro-api ดู log ตอนหา error
pm2 restart upro-api รีสตาร์ตหลัง build ใหม่

และแน่นอน เช็กว่า API ทำงานได้ไหม

sleep 6 && curl -i http://localhost:5000/health

ถ้าได้ HTTP/1.1 200 OK ก็เสร็จแล้ววววว เย้!

แต่ ๆ ๆ ลองไปเช็กที่ Browser ดูสิ

ลองเปิด http://IP:5000/health ในเบราว์เซอร์

มันไม่ได้ใช่ไหมล่ะ

ทำไมใน server ได้ แต่นอก server ไม่ได้?

ก็เพราะเรายังไม่ได้เปิด firewall หรือพูดง่าย ๆ คือยังไม่ได้เปิดประตูนั่นเอง ซึ่งเปิดง่ายมาก

ไปที่ Security Group → Edit inbound rules เพื่อไปเปิดพอร์ต

กด Add rule

ตั้งค่าประมาณนี้ คือ Type: Custom TCP, Port: 5000 (พอร์ต API ของเรา), Source: 0.0.0.0/0 (Vercel ต้องเรียกเข้ามาได้) แต่แนะนำให้ทำ Nginx นะจ๊ะ อันนี้แค่ deploy ให้ใช้งานได้ก่อนเท่านั้น

ลองเปิด http://IP:5000/health ในเบราว์เซอร์อีกที ขึ้น OK ก็เรียบร้อยแล้ววว แค่นี้ API ของเราก็ใช้งานได้แล้ว

เเต่นี้คือเราเปิดประตูหลัง อาจจะโดนซอยตูดได้ เพราะงันต้องทำ Nginx น่ะจ่ะ ทำไงติดตามน่ะจ่ะ

Deploy Web เเบบ PaaS ด้วย Vercel (Free)

reerii code — Sat, 17 Oct 2026 13:33:44 +0000

ไปที่ vercel

ไป login ให้เสร็จเรียบร้อย เเนะนำ login ด้วย Github

เมือขึ้นหน้านี้ เราจะเห็นได้ว่ามี Project ของเรา ที่เราเชื่อมกับ Github

กด import website ของเรา

ตั้งชื่อ subdomain เช่น ถ้าเราตั้ง uprodd จะได้ subdomain คือ uprodd.vercel.app

สวนคำสั่ง build ไม่ต้อง เพราะว่ามันรู้อยู่เเล้วว่าเป็น React มันจัดการให้อยู่เเล้ว สวน env ก็ใส่ตามที่เรา ตั้งค่า

เเต่ของผมตั้ง set การคุยกับ API คือ /api เพราะผมได้ตั้งค่าใน versel.json เป็นเเบบนี้

ความหมายคือ
Web = https://uprodd.vercel.app
API = https://uprodd.vercel.app/api จะใช้เเทน http://ip:port ของ server api

ทำไม่ต้องใช้เเบบนี้

เพาะผมใช้ Login ของ Google ซึ่งมันรองรับเเค่ https:// ที่จริงไป deploy api เจ้าอื่นที่ให้ Subdomain เลยก็ได้ เเต่ api ของผม ผม deploy เเบบ VPS (free)ซึงมันได้ IP public มา

สำหรับใครที่ไม่ได้ใช้ Google หรือ มี Domain API อยู่เเล้ว ไม่ต้องทำขั้นตอนนี้เลยก็ได้
เเค่นี้ก็ สามารถ deploy ได้เเล้ว

รอให้มัน build เเค่นี้ก็สามารถ ใช้งาน Website ได้เเล้ว

Deploy คืออะไร ?

reerii code — Thu, 15 Oct 2026 07:44:25 +0000

Deploy คือ ง่ายๆเลยคือการเอาเว็บของเราไปวางใว้บน server ให้คนอื่นเข้ามาใช้งานได้

เเล้วทำไม่ต้อง Deploy ล่ะ?

ก็เพราะถ้าไม่ deploy คนอื่นเข้ามาใช้เว็บเราไม่ได้ไงล่ะ hahaha
อ่าวกวนตีนนี้วาาา
โอเครๆ เดียวอธิบายดีๆ ตอนเรา dev เว็บอยู่เนี่ย เว็บมันรันอยู่บน local หรือก็คือในเครื่องเราเอง เราเปิด localhost ได้ แต่เพื่อนเราเปิดไม่ได้ เพราะมันอยู่ในเครื่องเรา ไม่ได้อยู่บนอินเทอร์เน็ต

อยากให้คนอื่นดูเว็บเดี๋ยวนี้ ทำไงดี?

มีทางลัดอยู่ทางนึง เรียกว่า Tunneling ก็คือเปิดอุโมงค์จากเครื่องเราออกไปอินเทอร์เน็ต แล้วมันจะสร้าง URL สาธารณะชั่วคราวให้ ส่งลิงก์ให้เพื่อนเปิดได้เลย เครื่องมือที่นิยมก็ ngrok หรือ Cloudflare Tunnel วิธีนี้เหมาะกับตอนทำ prototype ให้ลูกค้าดูระบบคร่าว ๆ

แต่!

ครื่องเราต้องเปิดไว้ตลอดนะจ๊ะ ปิดฝาโน้ตบุ๊กไปกินข้าวเมื่อไหร่ เว็บดับเมื่อนั้น
ถ้าอยากให้คนใช้ได้ยาว ๆ ทั้งวันทั้งคืน ยังไงก็ต้อง deploy

Deploy ยากไหม?

บอกเลย ง่ายกว่าที่คิด  ปกติบน local เราทำยังไง บน server ก็ทำแบบนั้นแหละ
เอ้ย จริงดิ?

จริง…สัก 90% อีก 10% ต้องแก้นิดหน่อย เพราะเครื่องเราอาจเป็น Windows หรือ Mac แต่ server ส่วนใหญ่เป็น Linux

แล้วทำไมไม่ใช้ Docker ล่ะ มันแก้ปัญหา OS ไม่ตรงกันได้นี่?

ใช่ ใช้ได้ แต่ก่อนจะไป Docker ต้องเข้าใจ deploy แบบพื้นฐานก่อน ว่าเบื้องหลังมันทำอะไรบ้าง ไม่งั้นวันไหน Docker พัง จะงงว่าพังตรงไหน

Deploy มีกี่แบบ?

หลัก ๆ มี 3 แบบ

แบบที่ 1 VPS

แบบที่ 1 VPS คือเช่าคอมพิวเตอร์ 1 เครื่องบน cloud แล้วเข้าไปผ่าน SSH ใช้ terminal เป็นหลัก ก็เหมือนทำบน local แค่เปลี่ยนจาก Windows เป็น Linux

ข้อดีคือคุมได้ทุกอย่าง ข้อเสียคือต้องทำเองทุกอย่าง ตั้งแต่ติดตั้ง Node เปิด firewall ไปจนถึงตั้ง Nginx  เจ้าดัง ๆ ก็ AWS EC2, Google Cloud, Oracle Cloud

แบบที่ 2 PaaS (Platform as a Service)

แบบที่ 2 PaaS (Platform as a Service) สำหรับสายขี้เกียจ…เอ้ย สายที่ไม่อยากดูแล server เอง  แค่เชื่อม GitHub พอ push ขึ้น main ปุ๊บ มัน deploy ให้อัตโนมัติปั๊บ เช่น Vercel, Render  ง่ายใช่ไหมล่ะ

แบบที่ 3 Docker

แบบที่ 3 Docker แพ็กโปรเจกต์เราเป็น image แล้วเอาไปรันที่ไหนก็ได้ จะเป็น Google Cloud Run หรือเอาไปรันบน VPS ก็ได้

ปัญหาคือ API ผมดันเก็บไฟล์รูปไว้ใน folder ของ API เองน่ะสิ แถมยังใช้ WebSocket อีก

แล้วมันผิดตรงไหน?

Vercel เป็น serverless คือตื่นมาทำงานก็ต่อเมื่อมี request เข้ามา ทำเสร็จก็ทิ้ง เหมือนห้องที่โดนรีเซ็ตทุกครั้ง รูปที่อัปโหลดไว้ก็หายเกลี้ยง แล้วก็ไม่รองรับ WebSocket ด้วย เพราะมันไม่ได้เปิดค้างไว้ให้เชื่อมต่อตลอด
ส่วน Render กับ Cloud Run ถึงจะรัน server ค้างไว้ได้ แต่พื้นที่เก็บไฟล์เป็นแบบชั่วคราว restart หรือ deploy ใหม่เมื่อไหร่ รูปก็หายเหมือนกัน

ทางแก้มี 2 ทาง

ทางที่ 1 แก้โค้ด ย้ายรูปไปเก็บข้างนอก เช่น Supabase Storage หรือ AWS S3 ฐานข้อมูลก็ใช้ของภายนอก ให้ API เป็นแค่ทางผ่านของข้อมูลเฉย ๆ ไม่เก็บอะไรไว้กับตัว แบบนี้ใช้ PaaS ได้สบาย
ทางที่ 2 ไม่อยากแก้โค้ด ก็ใช้ VPS ไปเลย เพราะมันคือคอมพิวเตอร์จริง ๆ 1 เครื่อง ไฟล์ไม่หาย WebSocket ก็เปิดค้างได้

เเต่ในครั้งนี้จะ deploy เริ่มต้นใช้เเบบ VPS เพราะจะได้เข้าใจ การ deploy พื้นฐานก่อน

Stack ผมคือ หน้าเว็บใช้ React, API ใช้ Express
Web → Vercel ง่ายสุด จบ
API → VPS

ก่อน deploy ต้องเข้าใจกระบวนการหลักก่อน

นึกถึงตอนเริ่มพัฒนาโปรเจกต์ เราทำอะไรก่อน?

git clone <url>

git clone โค้ดลงมา

npm install

ติดตั้ง dependency

อ้าว ทำไมต้อง install อีก โค้ดก็โหลดมาแล้วนี่?

เพราะของที่เราติดตั้งใน Node.js มันไปกองอยู่ใน folder node_modules ซึ่งหนักมาก ไม่มีใครบ้าโยนขึ้น GitHub หรอก ปกติจะใส่ไว้ใน .gitignore

สิ่งที่เราดึงโค้ดจาก Github มีเเต่โค้ด ไม่มี dependency ซึ่งเราต้องติดตั้ง

แล้วเครื่องใหม่จะรู้ได้ไงว่าต้องติดตั้งอะไรบ้าง?

ดูจาก package.json ไง มันคือรายการที่ติดตั้งใว้ จดไว้ว่าโปรเจกต์ใช้อะไร เวอร์ชันไหน สั่ง npm install ทีเดียว คือจบ

สวนใครที่ใช้ ฝั่ง Python ก็คล้ายกัน ใช้ไฟล์ requirements.txt ในการจด

รันโปรเจกต์

ตอน dev เราใช้ npm run dev แต่ตอน deploy จะใช้ npm start หรือคำสั่งสำหรับรันจริง

แต่ ๆ ๆ ๆ ช้าก่อน!

ใครเขียน JavaScript, HTML, CSS ล้วน ๆ รันได้เลย  แต่ถ้าใช้ TypeScript หรือ framework อย่าง React…พวกนายต้อง build ก่อนเว้ย!

Build คืออะไร?

Build ก็คือการแปลงโค้ดที่เราเขียน ให้กลายเป็นไฟล์ที่พร้อมใช้งานจริง

ทำไมต้องแปลง?

เพราะตัวที่รันโค้ดมันไม่รู้จัก TypeScript หรือ JSX
ฝั่งเว็บ บราวเซอร์อ่านได้แค่ HTML, CSS, JavaScript
ฝั่ง API ตัว Node.js ก็อ่านได้แค่ JavaScript

พอสั่ง

npm run build

มันจะสร้าง folder dist ขึ้นมา ข้างในคือโค้ดที่แปลงเป็น JavaScript หมดแล้ว  จากนั้นก็รัน API ด้วย node dist/server.js (ชื่อไฟล์แล้วแต่คนตั้ง อาจเป็น index.js หรือ main.js)  แค่นี้ API ก็ทำงานแล้ว

แต่ ๆ ๆ ใครใช้ ORM อย่าง Prisma ต้องรันคำสั่งเพิ่มอีกนิด ไม่งั้น API จะคุยกับ database ไม่รู้เรื่อง

พูดมาเยอะ บางคนอาจยังไม่เห็นภาพ  งั้นมาลงมือทำจริงกันเลยดีกว่า! Deploy API ด้วย AWS free