Docker on Hoàng Dương

Cài đặt Docker và Docker Compose tự động bằng Bash Script

Sat, 11 Apr 2026 00:00:00 +0000

Tự động hóa cài đặt Docker bằng Bash Script

Khi làm việc với nhiều server, việc cài đặt Docker thủ công từng bước trên mỗi máy là tốn thời gian và dễ sai sót. Giải pháp đơn giản nhất là viết một Bash Script tự động hóa toàn bộ quá trình — từ cài đặt dependencies, thêm Docker repository, đến cài đặt Docker Engine và Docker Compose.

Trong bài viết này, tôi sẽ hướng dẫn bạn viết script cài đặt Docker theo đúng tài liệu chính thức của Docker, đảm bảo luôn lấy phiên bản mới nhất từ repository chính thức.

Yêu cầu hệ thống

Trước khi bắt đầu, hãy đảm bảo server của bạn đáp ứng các điều kiện sau:

Yêu cầu	Chi tiết
Hệ điều hành	Ubuntu 22.04 (Jammy), 24.04 (Noble), 25.10 (Questing), 26.04 (Resolute)
Kiến trúc	x86_64 (amd64), arm64, armhf, s390x, ppc64le
Quyền	Tài khoản có quyền `sudo`
Kết nối mạng	Có kết nối Internet để tải packages

Gỡ cài đặt phiên bản Docker cũ (nếu có)

Theo tài liệu chính thức của Docker, trước khi cài đặt Docker Engine, bạn cần gỡ bỏ các package xung đột có thể đã được cài sẵn bởi hệ điều hành:

1

sudo apt remove docker.io docker-compose docker-compose-v2 docker-doc podman-docker containerd runc

Lưu ý: Lệnh trên có thể báo rằng không có package nào được cài — điều này hoàn toàn bình thường trên server mới.

Viết Bash Script cài đặt Docker

Tạo file script

1

vi install-docker.sh

Nội dung script

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40


#!/bin/bash
set -e

echo "=========================================="
echo " Cài đặt Docker Engine & Docker Compose "
echo "=========================================="

# Bước 1: Cài đặt các packages cần thiết
echo "[1/5] Cài đặt dependencies..."
sudo apt update -y
sudo apt install -y ca-certificates curl gnupg

# Bước 2: Thêm Docker GPG key
echo "[2/5] Thêm Docker GPG key..."
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

# Bước 3: Thêm Docker repository vào apt sources
echo "[3/5] Thêm Docker repository..."
echo \
 "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
 $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
 sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# Bước 4: Cài đặt Docker Engine và Docker Compose plugin
echo "[4/5] Cài đặt Docker Engine..."
sudo apt update -y
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

# Bước 5: Khởi động và enable Docker service
echo "[5/5] Khởi động Docker service..."
sudo systemctl start docker
sudo systemctl enable docker

echo "=========================================="
echo " Cài đặt hoàn tất!"
echo "=========================================="
docker --version
docker compose version

Giải thích từng bước trong script:

Bước	Lệnh	Mục đích
1	`apt install ca-certificates curl gnupg`	Cài các package cần thiết để xác thực GPG key và tải file qua HTTPS
2	`curl ... \| gpg --dearmor`	Tải và chuyển đổi GPG key của Docker sang định dạng binary để `apt` xác thực package
3	`tee /etc/apt/sources.list.d/docker.list`	Thêm Docker repository vào danh sách sources của `apt`, tự động detect kiến trúc và codename
4	`apt install docker-ce ...`	Cài đặt Docker Engine, CLI, containerd, Buildx plugin và Compose plugin
5	`systemctl start/enable docker`	Khởi động Docker daemon và cấu hình tự khởi động cùng hệ thống

Lưu ý quan trọng: Script sử dụng docker-compose-plugin (Compose V2) thay vì docker-compose standalone (V1). Compose V2 được tích hợp trực tiếp vào Docker CLI với lệnh docker compose (không có dấu gạch ngang). Docker đã ngừng hỗ trợ Compose V1 từ tháng 7/2023.

Cấp quyền và chạy script

1
2
3
4
5


# Cấp quyền thực thi
chmod +x install-docker.sh

# Chạy script
sudo bash install-docker.sh

Xác nhận kết quả cài đặt

Sau khi script chạy xong, bạn sẽ thấy output tương tự:

1
2
3
4
5


$ docker --version
Docker version 28.1.1, build 4eba377

$ docker compose version
Docker Compose version v2.35.1

Để kiểm tra Docker hoạt động chính xác, chạy container thử nghiệm:

1

sudo docker run hello-world

Nếu thấy thông báo Hello from Docker!, quá trình cài đặt đã thành công.

Cấu hình sau cài đặt (Post-installation)

Cho phép user thường chạy Docker (không cần sudo)

Theo mặc định, lệnh docker yêu cầu quyền root. Để user thường có thể sử dụng Docker:

1
2
3
4
5
6
7
8


# Thêm user hiện tại vào group docker
sudo usermod -aG docker $USER

# Áp dụng thay đổi group (cần logout/login lại hoặc chạy lệnh sau)
newgrp docker

# Xác nhận — không cần sudo nữa
docker run hello-world

Cấu hình Docker khởi động cùng hệ thống

Script đã thực hiện bước này với systemctl enable docker. Để xác nhận:

1
2


sudo systemctl is-enabled docker
# Output: enabled

Ghi chú triển khai

Khi áp dụng vào dự án của bạn, hãy lưu ý:
- Script chỉ hỗ trợ Ubuntu. Với Debian, CentOS, hoặc Fedora, cần thay đổi URL repository và lệnh package manager tương ứng
- Luôn kiểm tra tài liệu chính thức để đảm bảo các bước cài đặt chưa thay đổi
- set -e ở đầu script đảm bảo script dừng ngay khi có lệnh bị lỗi, tránh cài đặt không đầy đủ
Best practices:
- Sử dụng docker compose (V2) thay vì docker-compose (V1) — V1 đã ngừng hỗ trợ
- Không chạy container bằng user root trong production — cấu hình user thường với group docker
- Sau khi cài đặt, cấu hình Docker daemon phù hợp với môi trường (log driver, storage driver, v.v.)
Troubleshooting:
- Lỗi Permission denied khi chạy docker? → Đảm bảo user đã được thêm vào group docker và đã logout/login lại
- Lỗi Cannot connect to the Docker daemon? → Kiểm tra Docker service: sudo systemctl status docker
- GPG key bị lỗi khi apt update? → Xóa key cũ và chạy lại bước thêm GPG key: sudo rm /etc/apt/keyrings/docker.gpg

Lời kết

Với Bash Script trên, bạn có thể cài đặt Docker Engine và Docker Compose trên bất kỳ server Ubuntu nào chỉ với một lệnh duy nhất. Script sử dụng phương pháp cài đặt chính thức từ Docker repository, đảm bảo:

Luôn lấy phiên bản mới nhất từ repository chính thức
Cài đặt đầy đủ: Docker Engine, CLI, containerd, Buildx, và Compose V2
Tự động khởi động và enable Docker service

Bạn có thể lưu script này vào hệ thống quản lý cấu hình (Ansible, Terraform) hoặc đơn giản clone từ repository để sử dụng trên nhiều server. 🚀

Tài liệu tham khảo

Docker Official - Install Docker Engine on Ubuntu — Hướng dẫn chính thức cài đặt Docker trên Ubuntu
Docker Official - Post-installation steps for Linux — Cấu hình sau cài đặt
Docker Compose - Migrate to Compose V2 — Hướng dẫn chuyển từ Compose V1 sang V2

Docker Build Cache & Layering

Sun, 22 Mar 2026 00:00:00 +0000

Docker Build Cache & Layering

Bạn đã bao giờ tự hỏi tại sao lần build đầu tiên mất 5-10 phút, nhưng lần build thứ hai chỉ mất vài giây? Đó là nhờ Build Cache. Nhưng đôi khi, chỉ thay đổi 1 dòng code mà Docker lại rebuild toàn bộ — đó là vì bạn chưa hiểu cách Layering hoạt động. 🧱

Trong bài viết này, tôi sẽ giải thích chi tiết cơ chế Layer và Build Cache, cách Docker quyết định khi nào dùng cache và khi nào rebuild, cùng các kỹ thuật tối ưu để build nhanh hơn.

Layer trong Docker là gì?

Mỗi lệnh trong Dockerfile tạo ra một layer (lớp) trong image. Bạn có thể hình dung image như một chồng các lớp xếp chồng lên nhau, mỗi lớp thêm nội dung mới lên trên lớp trước đó.

Cách Layer được tạo ra

1
2
3
4
5
6


FROM node:18-alpine # Layer 1: Base image
WORKDIR /app # Layer 2: Tạo thư mục làm việc
COPY package.json ./ # Layer 3: Copy file package.json
RUN npm install # Layer 4: Cài dependencies
COPY . . # Layer 5: Copy source code
RUN npm run build # Layer 6: Build ứng dụng

Layer	Lệnh Dockerfile	Nội dung
Layer 1	`FROM node:18-alpine`	Base OS + Node.js runtime
Layer 2	`WORKDIR /app`	Tạo và chuyển vào thư mục /app
Layer 3	`COPY package.json ./`	Thêm file package.json
Layer 4	`RUN npm install`	Cài đặt node_modules
Layer 5	`COPY . .`	Thêm toàn bộ source code
Layer 6	`RUN npm run build`	Tạo file build (dist/)

Đặc điểm quan trọng của Layer

Read-only: Mỗi layer sau khi tạo xong là chỉ đọc, không thể thay đổi
Chia sẻ được: Nhiều image có thể dùng chung các layer giống nhau (ví dụ: cùng base image node:18-alpine)
Có thứ tự: Layer sau được xếp chồng lên layer trước, tạo thành file system hoàn chỉnh
Có kích thước: Mỗi layer có dung lượng riêng, tổng tất cả layer = kích thước image

Build Cache hoạt động như thế nào?

Build Cache là cơ chế giúp Docker bỏ qua các bước không cần thiết khi rebuild image. Nếu một layer không thay đổi so với lần build trước, Docker sẽ dùng lại kết quả cũ thay vì chạy lại.

Quy tắc cache của Docker

Docker kiểm tra cache theo thứ tự từng lệnh trong Dockerfile:

1
2
3
4
5


Lệnh 1 → Có cache? ✅ Dùng lại → Tiếp tục
Lệnh 2 → Có cache? ✅ Dùng lại → Tiếp tục
Lệnh 3 → Có cache? ❌ Cache miss → Rebuild từ đây trở đi
Lệnh 4 → Bắt buộc rebuild (vì lệnh 3 đã thay đổi)
Lệnh 5 → Bắt buộc rebuild

Quy tắc quan trọng nhất: Khi một layer bị invalidate (mất cache), tất cả các layer phía sau đều phải rebuild — kể cả khi chúng không thay đổi gì.

Khi nào cache bị invalidate?

Trường hợp	Cache bị mất?	Giải thích
Thay đổi lệnh trong Dockerfile	✅ Có	Docker so sánh chuỗi lệnh, khác → rebuild
File trong `COPY`/`ADD` thay đổi	✅ Có	Docker tính checksum của file, khác → rebuild
Chỉ thay đổi `mtime` của file	❌ Không	Docker không xét thời gian sửa đổi, chỉ xét nội dung
Lệnh `RUN` giống hệt lần trước	❌ Không	Cùng chuỗi lệnh → dùng cache (kể cả kết quả đã cũ)
Layer trước đó bị invalidate	✅ Có	Tất cả layer phía sau đều phải rebuild

Ví dụ minh hoạ cache invalidation

1
2
3
4
5


FROM node:18-alpine # ✅ Cache hit (không đổi)
WORKDIR /app # ✅ Cache hit (không đổi)
COPY . . # ❌ Cache miss (bạn sửa 1 file .js)
RUN npm install # ❌ Phải rebuild (vì COPY ở trên miss)
RUN npm run build # ❌ Phải rebuild (vì layer trước miss)

Chỉ sửa 1 file .js nhỏ, nhưng npm install phải chạy lại dù package.json không đổi. Đây là vấn đề phổ biến nhất khi viết Dockerfile chưa tối ưu.

Kỹ thuật tối ưu Build Cache

Sắp xếp lệnh theo tần suất thay đổi

Nguyên tắc: Lệnh ít thay đổi → đặt trước. Lệnh hay thay đổi → đặt sau.

❌ Chưa tối ưu:

1
2
3
4
5


FROM node:18-alpine
WORKDIR /app
COPY . . # Copy tất cả (thay đổi thường xuyên)
RUN npm install # Phải chạy lại mỗi khi code thay đổi
RUN npm run build

✅ Đã tối ưu:

1
2
3
4
5
6


FROM node:18-alpine
WORKDIR /app
COPY package.json yarn.lock ./ # Ít thay đổi → copy trước
RUN npm install # Chỉ rebuild khi dependencies đổi
COPY . . # Hay thay đổi → copy sau
RUN npm run build

Kết quả: Khi chỉ sửa source code, npm install được cache lại → tiết kiệm 2-5 phút mỗi lần build.

Sử dụng .dockerignore

File .dockerignore giúp loại bỏ các file không cần thiết khỏi build context, giảm nguy cơ cache bị invalidate vô ích.

1
2
3
4
5
6
7
8


# .dockerignore
node_modules
dist
.git
.env
*.log
tmp*
.DS_Store

Tại sao quan trọng? Nếu không có .dockerignore, lệnh COPY . . sẽ copy cả node_modules (hàng trăm MB) và .git vào build context. Bất kỳ thay đổi nào trong các thư mục này đều làm cache miss.

Sử dụng Cache Mounts

Cache mounts cho phép lưu trữ cache của package manager giữa các lần build, kể cả khi layer bị rebuild.

Node.js:

1
2
3
4
5
6
7


FROM node:18-alpine
WORKDIR /app
COPY package.json yarn.lock ./
RUN --mount=type=cache,target=/root/.npm \
 npm install
COPY . .
RUN npm run build

Python:

1
2
3
4
5
6


FROM python:3.11-slim
WORKDIR /app
COPY requirements.txt ./
RUN --mount=type=cache,target=/root/.cache/pip \
 pip install -r requirements.txt
COPY . .

Go:

1
2
3
4
5
6
7
8


FROM golang:1.21-alpine
WORKDIR /app
COPY go.mod go.sum ./
RUN --mount=type=cache,target=/go/pkg/mod \
 --mount=type=cache,target=/root/.cache/go-build \
 go mod download
COPY . .
RUN go build -o /app/server

Lợi ích: Ngay cả khi package.json thay đổi và layer phải rebuild, các package đã tải trước đó vẫn được lưu trong cache mount → chỉ tải package mới, không tải lại toàn bộ.

Multi-stage Build

Multi-stage build giúp tách quá trình build và runtime, giảm kích thước image cuối cùng và tối ưu cache cho từng giai đoạn.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


# Stage 1: Build (layer nặng nhưng không nằm trong image cuối)
FROM node:18-alpine AS builder
WORKDIR /app
COPY package.json yarn.lock ./
RUN npm install
COPY . .
RUN npm run build

# Stage 2: Runtime (chỉ chứa file cần thiết)
FROM nginx:alpine AS production
COPY --from=builder /app/dist /usr/share/nginx/html
EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]

Stage	Mục đích	Kích thước	Có trong image cuối?
builder	Build ứng dụng	~500 MB	❌ Không
production	Chạy ứng dụng	~30 MB	✅ Có

Ví dụ thực tế: Tối ưu Dockerfile cho Node.js

Dockerfile chưa tối ưu

1
2
3
4
5
6


FROM node:18
WORKDIR /app
COPY . .
RUN npm install
RUN npm run build
CMD ["node", "dist/server.js"]

Vấn đề:

❌ Base image lớn (node:18 ~ 900 MB)
❌ COPY . . trước npm install → mọi thay đổi code đều rebuild dependencies
❌ Không có .dockerignore → copy cả node_modules, .git
❌ Không dùng multi-stage → image cuối chứa devDependencies

Dockerfile đã tối ưu

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27


# Stage 1: Install dependencies
FROM node:18-alpine AS deps
WORKDIR /app
COPY package.json package-lock.json ./
RUN --mount=type=cache,target=/root/.npm \
 npm ci --only=production

# Stage 2: Build
FROM node:18-alpine AS builder
WORKDIR /app
COPY package.json package-lock.json ./
RUN --mount=type=cache,target=/root/.npm \
 npm ci
COPY . .
RUN npm run build

# Stage 3: Runtime
FROM node:18-alpine AS runtime
WORKDIR /app
ENV NODE_ENV=production

COPY --from=deps /app/node_modules ./node_modules
COPY --from=builder /app/dist ./dist
COPY package.json ./

EXPOSE 3000
CMD ["node", "dist/server.js"]

Cải thiện:

✅ Base image nhỏ (node:18-alpine ~ 170 MB)
✅ Tách COPY package.json riêng → cache dependencies hiệu quả
✅ Cache mount cho npm → tải lại nhanh khi rebuild
✅ Multi-stage → image cuối chỉ chứa production dependencies
✅ Sử dụng npm ci thay npm install → đảm bảo reproducible builds

So sánh kết quả

Tiêu chí	Chưa tối ưu	Đã tối ưu
Kích thước image	~900 MB	~170 MB
Build lần đầu	~5 phút	~5 phút
Rebuild khi đổi code	~5 phút	~30 giây
Rebuild khi đổi deps	~5 phút	~2 phút

Các lệnh hữu ích để debug Cache

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


# Xem chi tiết quá trình build (hiển thị cache hit/miss)
docker build --progress=plain -t myapp .

# Build không dùng cache (force rebuild toàn bộ)
docker build --no-cache -t myapp .

# Chỉ invalidate cache cho stage cụ thể
docker build --no-cache-filter builder -t myapp .

# Xem các layer của image
docker history myapp

# Xem dung lượng build cache
docker builder du

# Xoá build cache
docker builder prune

Đọc output build: Khi build, Docker hiển thị CACHED cho các layer dùng cache:

1
2
3
4


 => CACHED [deps 2/3] COPY package.json package-lock.json ./
 => CACHED [deps 3/3] RUN npm ci --only=production
 => [builder 4/5] COPY . .
 => [builder 5/5] RUN npm run build

Các dòng có CACHED nghĩa là layer đó được lấy từ cache, không cần rebuild.

Ghi chú triển khai

Khi áp dụng vào dự án của bạn, hãy lưu ý các điểm quan trọng:
- Luôn tạo file .dockerignore trước khi viết Dockerfile
- Tách COPY package.json riêng trước RUN npm install
- Sử dụng multi-stage build cho production image
- Cache mount (--mount=type=cache) cần BuildKit (mặc định từ Docker 23.0+)
Best practices:
- Sắp xếp lệnh: ít thay đổi → trước, hay thay đổi → sau
- Dùng npm ci thay npm install trong CI/CD
- Pin version cụ thể cho base image (node:18.12-alpine thay vì node:latest)
Troubleshooting:
- Build chậm dù không đổi gì? → Kiểm tra .dockerignore, có thể file không liên quan đang trigger cache miss
- Cache mount không hoạt động? → Đảm bảo Docker BuildKit đang bật: DOCKER_BUILDKIT=1
- Muốn xem layer nào bị miss? → Dùng docker build --progress=plain

Lời kết

Tóm tắt lại:

Layer = mỗi lệnh trong Dockerfile tạo ra một lớp trong image
Build Cache = Docker lưu lại kết quả các layer để dùng lại khi rebuild
Cache invalidation = khi một layer thay đổi, tất cả layer phía sau đều phải rebuild
Tối ưu = sắp xếp lệnh hợp lý + .dockerignore + cache mounts + multi-stage build

Chỉ cần hiểu và áp dụng 4 kỹ thuật trên, bạn có thể giảm thời gian build Docker từ 5 phút xuống dưới 30 giây cho phần lớn trường hợp. 🚀

Nếu bạn thấy bài viết này hữu ích, hãy nhớ ⭐ star repo hoặc 📱 chia sẻ với bạn bè nhé! 😊

Tài liệu tham khảo

CI/CD với GitHub Actions cho ứng dụng Docker

Sun, 08 Mar 2026 00:00:00 +0000

GitHub Actions + Docker — Tự động hóa từ code đến container

Khi bạn đã biết viết Dockerfile và dùng Docker Compose, bước tiếp theo là tự động hóa quá trình build và push Docker image mỗi khi code thay đổi. GitHub Actions là công cụ CI/CD miễn phí tích hợp sẵn trong GitHub, rất phù hợp để bắt đầu.

Trong bài viết này, mình sẽ hướng dẫn bạn từ cơ bản đến thực hành: tạo workflow build Docker image, push lên registry, và tối ưu với cache.

GitHub Actions là gì?

GitHub Actions là nền tảng CI/CD được tích hợp trực tiếp trong GitHub, cho phép bạn tự động hóa workflow phát triển phần mềm ngay trong repository.

Các khái niệm cơ bản

Khái niệm	Giải thích
Workflow	File YAML định nghĩa pipeline, lưu trong `.github/workflows/`
Event	Sự kiện kích hoạt workflow (push, pull_request, tag…)
Job	Một nhóm các bước (steps) chạy trên cùng một runner
Step	Một bước đơn lẻ trong job (chạy lệnh hoặc dùng action)
Action	Thành phần tái sử dụng, có thể do cộng đồng hoặc Docker cung cấp
Runner	Máy ảo thực thi workflow (GitHub cung cấp miễn phí Ubuntu, Windows, macOS)

Cấu trúc thư mục

1
2
3
4
5
6
7


my-project/
├── .github/
│ └── workflows/
│ └── docker-build.yml # Workflow file
├── Dockerfile
├── src/
└── ...

Docker Official Actions

Docker cung cấp bộ Actions chính thức giúp bạn build và push image một cách chuẩn hóa:

Action	Chức năng
docker/login-action	Đăng nhập vào Docker registry
docker/setup-buildx-action	Thiết lập Docker Buildx (hỗ trợ build nâng cao)
docker/build-push-action	Build và push Docker image
docker/metadata-action	Tự động tạo tags và labels từ Git metadata
docker/setup-qemu-action	Cài QEMU cho multi-platform build

Workflow cơ bản — Build và Push lên Docker Hub

Chuẩn bị secrets

Trước khi tạo workflow, bạn cần thêm secrets trong repo GitHub:

Vào Settings → Secrets and variables → Actions
Thêm 2 secrets:
- DOCKERHUB_USERNAME — Tên tài khoản Docker Hub
- DOCKERHUB_TOKEN — Access token (tạo tại hub.docker.com/settings/security)

Tạo workflow file

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32


# .github/workflows/docker-build.yml
name: Build and Push Docker Image

on:
 push:
 branches: [main]
 pull_request:
 branches: [main]

jobs:
 build:
 runs-on: ubuntu-latest

 steps:
 - name: Checkout code
 uses: actions/checkout@v4

 - name: Login to Docker Hub
 uses: docker/login-action@v3
 with:
 username: ${{ secrets.DOCKERHUB_USERNAME }}
 password: ${{ secrets.DOCKERHUB_TOKEN }}

 - name: Set up Docker Buildx
 uses: docker/setup-buildx-action@v3

 - name: Build and push
 uses: docker/build-push-action@v6
 with:
 context: .
 push: ${{ github.event_name != 'pull_request' }}
 tags: ${{ secrets.DOCKERHUB_USERNAME }}/myapp:latest

Giải thích từng phần

Phần	Ý nghĩa
`on: push: branches: [main]`	Chạy workflow khi push code lên branch `main`
`on: pull_request`	Chạy khi tạo PR (chỉ build, không push)
`actions/checkout@v4`	Clone code từ repo về runner
`docker/login-action@v3`	Đăng nhập Docker Hub bằng secrets
`docker/setup-buildx-action@v3`	Cài Docker Buildx — hỗ trợ cache, multi-platform
`docker/build-push-action@v6`	Build image từ Dockerfile và push lên registry
`push: ${{ github.event_name != 'pull_request' }}`	Chỉ push image khi không phải PR (tránh push image chưa review)

Push lên GitHub Container Registry (GHCR)

Ngoài Docker Hub, bạn có thể push image lên GHCR — registry miễn phí của GitHub, tiện lợi vì không cần tạo tài khoản bên ngoài.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48


# .github/workflows/docker-ghcr.yml
name: Build and Push to GHCR

on:
 push:
 branches: [main]
 tags: ["v*"]

permissions:
 contents: read
 packages: write

jobs:
 build:
 runs-on: ubuntu-latest

 steps:
 - name: Checkout code
 uses: actions/checkout@v4

 - name: Login to GitHub Container Registry
 uses: docker/login-action@v3
 with:
 registry: ghcr.io
 username: ${{ github.actor }}
 password: ${{ secrets.GITHUB_TOKEN }}

 - name: Set up Docker Buildx
 uses: docker/setup-buildx-action@v3

 - name: Extract metadata (tags, labels)
 id: meta
 uses: docker/metadata-action@v5
 with:
 images: ghcr.io/${{ github.repository }}
 tags: |
 type=ref,event=branch
 type=semver,pattern={{version}}
 type=semver,pattern={{major}}.{{minor}}
 type=sha

 - name: Build and push
 uses: docker/build-push-action@v6
 with:
 context: .
 push: true
 tags: ${{ steps.meta.outputs.tags }}
 labels: ${{ steps.meta.outputs.labels }}

Điểm khác biệt so với Docker Hub

Tiêu chí	Docker Hub	GHCR
Registry URL	`docker.io` (mặc định)	`ghcr.io`
Authentication	Username + Access Token	`GITHUB_TOKEN` (tự động)
Giá	Miễn phí (giới hạn pull)	Miễn phí (theo quota GitHub)
Tích hợp	Phổ biến nhất	Tích hợp sâu với GitHub

Tự động tạo tags với Metadata Action

Thay vì đặt tag thủ công (latest, v1.0), bạn có thể dùng docker/metadata-action để tự động tạo tags dựa trên Git events:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


- name: Extract metadata
 id: meta
 uses: docker/metadata-action@v5
 with:
 images: user/myapp
 tags: |
 type=ref,event=branch
 type=ref,event=pr
 type=semver,pattern={{version}}
 type=semver,pattern={{major}}.{{minor}}
 type=sha

Kết quả tags theo từng event

Git Event	Ví dụ	Docker Tag
Push branch `main`	`refs/heads/main`	`main`
Push branch `dev`	`refs/heads/dev`	`dev`
Pull Request #42	`refs/pull/42/merge`	`pr-42`
Push tag `v1.2.3`	`refs/tags/v1.2.3`	`1.2.3`, `1.2`
Commit SHA	`abc1234`	`sha-abc1234`

Tối ưu build với Cache

Mỗi lần workflow chạy, Docker phải build lại từ đầu. Để tăng tốc đáng kể, hãy sử dụng cache.

GitHub Actions Cache (Khuyến nghị)

1
2
3
4
5
6
7
8


- name: Build and push
 uses: docker/build-push-action@v6
 with:
 context: .
 push: true
 tags: user/myapp:latest
 cache-from: type=gha
 cache-to: type=gha,mode=max

Ưu điểm: Đơn giản nhất, sử dụng GitHub Cache API, không cần cấu hình thêm.

Registry Cache

1
2
3
4
5
6
7
8


- name: Build and push
 uses: docker/build-push-action@v6
 with:
 context: .
 push: true
 tags: user/myapp:latest
 cache-from: type=registry,ref=user/myapp:buildcache
 cache-to: type=registry,ref=user/myapp:buildcache,mode=max

Ưu điểm: Cache được lưu trên registry, có thể chia sẻ giữa nhiều CI runners.

So sánh các loại cache

Loại cache	Ưu điểm	Nhược điểm
GitHub Actions (gha)	Đơn giản, không cần setup thêm	Giới hạn 10GB/repo
Registry	Chia sẻ được, persistent	Tốn bandwidth upload
Inline	Gắn liền với image	Chỉ hỗ trợ `min` mode

Ví dụ thực tế — Workflow hoàn chỉnh

Dưới đây là workflow hoàn chỉnh kết hợp tất cả best practices:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58


# .github/workflows/docker-ci.yml
name: Docker CI/CD

on:
 push:
 branches: [main, dev]
 tags: ["v*.*.*"]
 pull_request:
 branches: [main]

env:
 REGISTRY: ghcr.io
 IMAGE_NAME: ${{ github.repository }}

permissions:
 contents: read
 packages: write

jobs:
 build-and-push:
 runs-on: ubuntu-latest

 steps:
 - name: Checkout code
 uses: actions/checkout@v4

 - name: Set up Docker Buildx
 uses: docker/setup-buildx-action@v3

 - name: Login to GHCR
 if: github.event_name != 'pull_request'
 uses: docker/login-action@v3
 with:
 registry: ${{ env.REGISTRY }}
 username: ${{ github.actor }}
 password: ${{ secrets.GITHUB_TOKEN }}

 - name: Extract metadata
 id: meta
 uses: docker/metadata-action@v5
 with:
 images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}
 tags: |
 type=ref,event=branch
 type=ref,event=pr
 type=semver,pattern={{version}}
 type=semver,pattern={{major}}.{{minor}}
 type=sha

 - name: Build and push
 uses: docker/build-push-action@v6
 with:
 context: .
 push: ${{ github.event_name != 'pull_request' }}
 tags: ${{ steps.meta.outputs.tags }}
 labels: ${{ steps.meta.outputs.labels }}
 cache-from: type=gha
 cache-to: type=gha,mode=max

Luồng hoạt động

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


Developer push code lên GitHub
 ↓
GitHub Actions tự động kích hoạt
 ↓
Checkout code → Setup Buildx → Login Registry
 ↓
Tự động tạo tags từ Git metadata
 ↓
Build Docker image (có cache)
 ↓
Push image lên GHCR (nếu không phải PR)
 ↓
Image sẵn sàng để deploy 🚀

Troubleshooting phổ biến

Lỗi authentication

Lỗi:

1

Error: denied: denied

Nguyên nhân: Secrets chưa được cấu hình hoặc token hết hạn.

Giải pháp:

Kiểm tra secrets trong Settings → Secrets and variables → Actions
Với GHCR: đảm bảo có permissions: packages: write trong workflow
Với Docker Hub: tạo lại Access Token tại hub.docker.com

Build chậm

Nguyên nhân: Không sử dụng cache hoặc Dockerfile chưa tối ưu layer.

Giải pháp:

1
2
3


# Thêm cache vào build step
cache-from: type=gha
cache-to: type=gha,mode=max

Và đảm bảo Dockerfile tận dụng layer caching (copy package.json trước, COPY . . sau).

Lỗi permission khi push lên GHCR

Lỗi:

1

Error: unexpected status from HEAD request: 403 Forbidden

Giải pháp: Thêm permissions vào workflow:

1
2
3


permissions:
 contents: read
 packages: write

Ghi chú triển khai

Khi áp dụng vào dự án của bạn, hãy lưu ý các điểm quan trọng:
- Luôn dùng secrets cho credentials, không bao giờ hardcode token trong workflow
- Sử dụng push: ${{ github.event_name != 'pull_request' }} để tránh push image từ PR chưa review
- Pin version cho actions (dùng @v3, @v6 thay vì @main)
Best practices:
- Sử dụng docker/metadata-action để quản lý tags tự động
- Bật cache (type=gha) để tăng tốc build
- Tách workflow cho build + test và deploy riêng biệt
Troubleshooting:
- Xem logs chi tiết trong tab Actions của repo GitHub
- Dùng docker compose config để validate cấu hình trước khi push
- Kiểm tra quota cache GitHub tại Settings → Actions → Cache

Lời kết

GitHub Actions + Docker là combo mạnh mẽ để tự động hóa pipeline từ code đến container image. Với các workflow trong bài viết này, bạn có thể:

✅ Tự động build Docker image mỗi khi push code
✅ Push image lên Docker Hub hoặc GHCR
✅ Tự động tạo tags theo Git metadata (branch, tag, SHA)
✅ Tối ưu tốc độ build với cache

Nếu bạn thấy bài viết này hữu ích, hãy nhớ ⭐ star repo hoặc 📱 chia sẻ với bạn bè nhé! 😊

Tài liệu tham khảo

GitHub Actions Documentation — Tài liệu chính thức GitHub Actions
Docker Build GitHub Actions — Hướng dẫn chính thức Docker cho GitHub Actions
Docker/build-push-action — Repository chính thức của Build and Push Action
Cache management with GitHub Actions — Hướng dẫn cache cho Docker build trên GitHub Actions

Triển khai Node.js với Docker + Nginx

Tue, 10 Feb 2026 00:00:00 +0000

Triển khai Node.js với Docker + Nginx — Case Study

Bạn đã viết xong API bằng Node.js, test local ngon lành. Nhưng khi đưa lên server thật, bạn gặp hàng loạt câu hỏi:

Làm sao chạy app ổn định, tự restart khi crash?
Làm sao để client không truy cập thẳng vào port 3000?
Làm sao xử lý SSL, rate limit, static files?

Câu trả lời: Docker + Nginx reverse proxy. Trong bài viết này, tôi sẽ hướng dẫn bạn triển khai một ứng dụng Node.js (Express) từ đầu đến cuối, sử dụng Docker để đóng gói và Nginx làm reverse proxy phía trước.

Kiến trúc tổng quan

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


Client (Browser / Mobile)
 │
 ▼
 ┌──────────┐
 │ Nginx │ ← Port 80/443 (HTTP/HTTPS)
 │ (proxy) │
 └────┬─────┘
 │ proxy_pass http://app:3000
 ▼
 ┌──────────┐
 │ Node.js │ ← Port 3000 (internal)
 │ (Express)│
 └──────────┘

Nginx đứng trước nhận request từ client, sau đó chuyển tiếp (proxy) đến Node.js chạy bên trong. Client không bao giờ truy cập trực tiếp vào Node.js.

Tại sao cần Nginx phía trước?

Lý do	Giải thích
Reverse proxy	Ẩn port thật của app, client chỉ thấy port 80/443
Static files	Nginx phục vụ file tĩnh (CSS, JS, ảnh) nhanh hơn Node.js rất nhiều
SSL termination	Nginx xử lý HTTPS, Node.js chỉ nhận HTTP thuần
Rate limiting	Giới hạn request ở tầng Nginx, bảo vệ Node.js khỏi quá tải
Load balancing	Khi scale nhiều instance Node.js, Nginx phân phối request

Bước 1: Tạo ứng dụng Node.js (Express)

Cấu trúc project

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


my-app/
├── src/
│ └── server.js
├── package.json
├── package-lock.json
├── Dockerfile
├── .dockerignore
├── nginx/
│ └── default.conf
└── docker-compose.yml

File `package.json`

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


{
 "name": "my-app",
 "version": "1.0.0",
 "main": "src/server.js",
 "scripts": {
 "start": "node src/server.js"
 },
 "dependencies": {
 "express": "^4.21.0"
 }
}

File `src/server.js`

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


const express = require("express");
const app = express();
const PORT = process.env.PORT || 3000;

app.get("/", (req, res) => {
 res.json({ message: "Hello from Node.js!", timestamp: new Date() });
});

app.get("/health", (req, res) => {
 res.json({ status: "ok" });
});

app.listen(PORT, "0.0.0.0", () => {
 console.log(`Server running on port ${PORT}`);
});

Lưu ý: app.listen(PORT, "0.0.0.0") — phải bind 0.0.0.0 để container nhận được request từ bên ngoài. Nếu bind 127.0.0.1 (localhost), Nginx sẽ không thể kết nối đến app.

Bước 2: Viết Dockerfile cho Node.js

File `.dockerignore`

1
2
3
4


node_modules
npm-debug.log
.git
.env

Theo tài liệu chính thức của Docker, Dockerfile cho Node.js nên dùng multi-stage build, tạo non-root user và sử dụng cache mount để tối ưu.

File `Dockerfile`

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27


# Stage 1: Install dependencies
FROM node:18-alpine AS deps
WORKDIR /app

COPY package.json package-lock.json ./
RUN --mount=type=cache,target=/root/.npm \
 npm ci --only=production

# Stage 2: Production
FROM node:18-alpine AS production
WORKDIR /app

# Tạo non-root user (theo best practice từ Docker docs)
RUN addgroup -g 1001 -S nodejs && \
 adduser -S nodejs -u 1001 -G nodejs

ENV NODE_ENV=production

COPY --from=deps /app/node_modules ./node_modules
COPY src ./src
COPY package.json ./

USER nodejs

EXPOSE 3000

CMD ["node", "src/server.js"]

Giải thích:

Kỹ thuật	Mục đích
`node:18-alpine`	Base image nhỏ (~170 MB thay vì ~900 MB của `node:18`)
Multi-stage build	Stage `deps` cài dependencies, stage `production` chỉ copy kết quả
`npm ci`	Cài đặt chính xác theo `package-lock.json`, đảm bảo reproducible builds
`--mount=type=cache`	Cache npm packages giữa các lần build
Non-root user	Không chạy app bằng root, tăng bảo mật
`COPY src ./src`	Chỉ copy source code cần thiết, không copy toàn bộ project

Bước 3: Cấu hình Nginx làm Reverse Proxy

File `nginx/default.conf`

Theo tài liệu chính thức của Nginx, directive proxy_pass được dùng để chuyển tiếp request đến server khác. Các header proxy_set_header cần được thiết lập để server backend nhận đúng thông tin client.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33


upstream nodejs_app {
 server app:3000;
}

server {
 listen 80;
 server_name _;

 # Giới hạn kích thước request body (chống upload quá lớn)
 client_max_body_size 10m;

 location / {
 proxy_pass http://nodejs_app;

 # Chuyển tiếp thông tin client gốc đến Node.js
 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;

 # Hỗ trợ WebSocket (nếu app cần)
 proxy_http_version 1.1;
 proxy_set_header Upgrade $http_upgrade;
 proxy_set_header Connection "upgrade";
 }

 # Health check endpoint (Nginx trả thẳng, không cần qua Node.js)
 location = /nginx-health {
 access_log off;
 return 200 "ok";
 add_header Content-Type text/plain;
 }
}

Giải thích các directive quan trọng:

Directive	Ý nghĩa
`upstream nodejs_app`	Định nghĩa nhóm backend server. Khi scale nhiều instance, thêm server vào đây
`proxy_pass http://nodejs_app`	Chuyển tiếp request đến upstream đã định nghĩa
`proxy_set_header Host $host`	Giữ nguyên hostname gốc từ client (mặc định Nginx đổi thành `$proxy_host`)
`proxy_set_header X-Real-IP`	Gửi IP thật của client đến Node.js (không phải IP của Nginx)
`proxy_set_header X-Forwarded-For`	Chuỗi IP qua các proxy, giúp Node.js biết client thật
`proxy_set_header X-Forwarded-Proto`	Cho Node.js biết client dùng HTTP hay HTTPS
`proxy_http_version 1.1`	Bắt buộc để hỗ trợ WebSocket và keep-alive

Bước 4: Docker Compose — Kết nối tất cả

Theo Docker Compose production guide, khi deploy production nên: bỏ volume bind cho code, set restart policy, và tách file compose cho từng môi trường.

File `docker-compose.yml`

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47


services:
 app:
 build:
 context: .
 dockerfile: Dockerfile
 target: production
 container_name: nodejs-app
 restart: unless-stopped
 environment:
 - NODE_ENV=production
 - PORT=3000
 expose:
 - "3000"
 healthcheck:
 test:
 [
 "CMD",
 "wget",
 "--quiet",
 "--tries=1",
 "--spider",
 "http://localhost:3000/health",
 ]
 interval: 30s
 timeout: 5s
 retries: 3
 start_period: 10s
 networks:
 - app-network

 nginx:
 image: nginx:1.27-alpine
 container_name: nginx-proxy
 restart: unless-stopped
 ports:
 - "80:80"
 volumes:
 - ./nginx/default.conf:/etc/nginx/conf.d/default.conf:ro
 depends_on:
 app:
 condition: service_healthy
 networks:
 - app-network

networks:
 app-network:
 driver: bridge

Các điểm quan trọng:

Cấu hình	Giải thích
`expose: "3000"`	Chỉ mở port nội bộ giữa các container, không expose ra host
`ports: "80:80"`	Chỉ Nginx được expose ra ngoài
`depends_on: condition: service_healthy`	Nginx chỉ start sau khi Node.js healthy
`restart: unless-stopped`	Tự restart khi crash, trừ khi bạn chủ động stop
`:ro` (read-only)	Mount config Nginx ở chế độ chỉ đọc
`networks: app-network`	Cả 2 container cùng network, Nginx gọi `app:3000` qua tên service

Bước 5: Build và chạy

1
2
3
4
5
6
7
8


# Build và chạy tất cả
docker compose up --build -d

# Xem logs
docker compose logs -f

# Kiểm tra trạng thái
docker compose ps

Kiểm tra hoạt động:

1
2
3
4
5
6
7
8


# Request qua Nginx (port 80)
curl http://localhost

# Kiểm tra health của Node.js
curl http://localhost/health

# Kiểm tra health của Nginx
curl http://localhost/nginx-health

Kết quả mong đợi:

1

{ "message": "Hello from Node.js!", "timestamp": "2026-02-10T12:00:00.000Z" }

Bước 6: Deploy lại khi thay đổi code

Theo Docker Compose docs, khi cập nhật code, bạn chỉ cần rebuild service cần thiết:

1
2
3


# Rebuild chỉ service app (không ảnh hưởng Nginx)
docker compose build app
docker compose up --no-deps -d app

Flag --no-deps đảm bảo chỉ restart service app, không restart Nginx. Client không bị gián đoạn.

Mở rộng: Scale nhiều instance Node.js

Khi traffic tăng, bạn có thể chạy nhiều instance Node.js và để Nginx load balance:

1

docker compose up --scale app=3 -d

Cập nhật nginx/default.conf để Nginx biết có nhiều instance:

1
2
3
4
5


upstream nodejs_app {
 # Docker Compose DNS tự động resolve tên service
 # thành tất cả container IP đang chạy
 server app:3000;
}

Khi dùng Docker Compose với --scale, Docker DNS tự động resolve app thành tất cả IP của các container app. Nginx sẽ round-robin request đến từng instance.

Ghi chú triển khai

Khi áp dụng vào dự án của bạn, hãy lưu ý:
- Luôn dùng expose thay vì ports cho service backend — chỉ Nginx mới cần expose ra ngoài
- Bind 0.0.0.0 trong Node.js, không bind 127.0.0.1
- Dùng npm ci thay npm install để đảm bảo reproducible builds
- Tạo non-root user trong Dockerfile cho bảo mật
Best practices:
- Dùng docker compose up --no-deps -d app khi chỉ cần redeploy app
- Pin version cho base image (node:18-alpine, nginx:1.27-alpine) thay vì latest
- Tách docker-compose.prod.yml riêng cho production config
Troubleshooting:
- Nginx báo 502 Bad Gateway? → Node.js chưa start xong hoặc bind sai address. Kiểm tra docker compose logs app
- Không kết nối được giữa Nginx và Node.js? → Đảm bảo cả 2 cùng network và dùng đúng tên service trong proxy_pass
- Request bị timeout? → Kiểm tra client_max_body_size và proxy_read_timeout trong Nginx config

Lời kết

Tóm tắt lại flow triển khai:

Viết app Node.js (Express) với health check endpoint
Dockerfile multi-stage build + non-root user
Nginx config reverse proxy với proxy_pass và các header cần thiết
Docker Compose kết nối app + Nginx, chỉ expose port 80
Deploy bằng docker compose up --build -d
Update bằng docker compose build app && docker compose up --no-deps -d app

Đây là kiến trúc cơ bản nhất để đưa một ứng dụng Node.js lên production. Từ đây bạn có thể mở rộng thêm SSL (Let’s Encrypt), database, monitoring tuỳ nhu cầu. 🚀

Nếu bạn thấy bài viết này hữu ích, hãy nhớ ⭐ star repo hoặc 📱 chia sẻ với bạn bè nhé! 😊

Tài liệu tham khảo

Docker Official - Containerize Node.js — Hướng dẫn chính thức Docker cho Node.js
Docker Compose in Production — Hướng dẫn deploy production với Compose
Nginx Reverse Proxy — Tài liệu chính thức cấu hình reverse proxy
Nginx Beginner’s Guide — Hướng dẫn cơ bản từ nginx.org

Docker Compose cho người mới (v2) — Thực hành

Wed, 04 Feb 2026 00:00:00 +0000

Docker Compose v2 - Công cụ quản lý multi-container

Docker Compose là công cụ giúp bạn định nghĩa và chạy nhiều container cùng lúc thông qua file YAML. Phiên bản v2 mang đến nhiều cải tiến về hiệu suất và tính năng mới.

I. Cài đặt và chuẩn bị

Kiểm tra phiên bản Docker Compose

1
2
3
4
5


# Kiểm tra phiên bản hiện tại
docker compose version

# Output mong muốn (v2.x.x)
Docker Compose version v2.24.5

Cấu trúc project cơ bản

1
2
3
4
5
6
7
8


my-app/
├── docker-compose.yml
├── .env
├── app/
│ ├── Dockerfile
│ └── src/
└── nginx/
 └── nginx.conf

II. Cú pháp Docker Compose v2

File docker-compose.yml cơ bản

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


version: "3.8"

services:
 web:
 build: .
 ports:
 - "3000:3000"
 environment:
 - NODE_ENV=development
 volumes:
 - .:/app
 - /app/node_modules
 depends_on:
 - db

 db:
 image: postgres:15
 environment:
 POSTGRES_DB: myapp
 POSTGRES_USER: user
 POSTGRES_PASSWORD: password
 volumes:
 - postgres_data:/var/lib/postgresql/data
 ports:
 - "5432:5432"

volumes:
 postgres_data:

Sử dụng file .env

1
2
3
4
5
6
7


# .env file
NODE_ENV=development
DB_HOST=db
DB_PORT=5432
DB_NAME=myapp
DB_USER=user
DB_PASSWORD=password

1
2
3
4
5
6
7


# docker-compose.yml
services:
 web:
 environment:
 - NODE_ENV=${NODE_ENV}
 - DB_HOST=${DB_HOST}
 - DB_PORT=${DB_PORT}

III. Best Practices cho Docker Compose v2

Quản lý Networks

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


version: "3.8"

services:
 frontend:
 build: ./frontend
 networks:
 - frontend-network

 backend:
 build: ./backend
 networks:
 - frontend-network
 - backend-network

 database:
 image: postgres:15
 networks:
 - backend-network

networks:
 frontend-network:
 driver: bridge
 backend-network:
 driver: bridge

Health Checks

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


services:
 web:
 build: .
 healthcheck:
 test: ["CMD", "curl", "-f", "http://localhost:3000/health"]
 interval: 30s
 timeout: 10s
 retries: 3
 start_period: 40s

 db:
 image: postgres:15
 healthcheck:
 test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER}"]
 interval: 10s
 timeout: 5s
 retries: 5

Resource Limits

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


services:
 web:
 build: .
 deploy:
 resources:
 limits:
 cpus: "0.5"
 memory: 512M
 reservations:
 cpus: "0.25"
 memory: 256M

IV. Các lệnh Docker Compose v2 thường dùng

Lệnh cơ bản

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


# Khởi chạy services (detached mode)
docker compose up -d

# Xem logs
docker compose logs -f

# Dừng services
docker compose down

# Rebuild và restart
docker compose up --build -d

# Xem trạng thái services
docker compose ps

Lệnh nâng cao

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# Chạy lệnh trong container
docker compose exec web bash

# Scale service
docker compose up --scale web=3 -d

# Xem resource usage
docker compose top

# Validate compose file
docker compose config

V. Ví dụ thực tế: Web App với Database

Node.js + PostgreSQL + Redis

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59


version: "3.8"

services:
 app:
 build:
 context: .
 dockerfile: Dockerfile
 ports:
 - "3000:3000"
 environment:
 - NODE_ENV=development
 - DATABASE_URL=postgresql://user:password@db:5432/myapp
 - REDIS_URL=redis://redis:6379
 volumes:
 - .:/app
 - /app/node_modules
 depends_on:
 db:
 condition: service_healthy
 redis:
 condition: service_started
 restart: unless-stopped

 db:
 image: postgres:15-alpine
 environment:
 POSTGRES_DB: myapp
 POSTGRES_USER: user
 POSTGRES_PASSWORD: password
 volumes:
 - postgres_data:/var/lib/postgresql/data
 - ./init.sql:/docker-entrypoint-initdb.d/init.sql
 healthcheck:
 test: ["CMD-SHELL", "pg_isready -U user"]
 interval: 10s
 timeout: 5s
 retries: 5
 restart: unless-stopped

 redis:
 image: redis:7-alpine
 command: redis-server --appendonly yes
 volumes:
 - redis_data:/data
 restart: unless-stopped

 nginx:
 image: nginx:alpine
 ports:
 - "80:80"
 volumes:
 - ./nginx.conf:/etc/nginx/nginx.conf
 depends_on:
 - app
 restart: unless-stopped

volumes:
 postgres_data:
 redis_data:

File nginx.conf

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


events {
 worker_connections 1024;
}

http {
 upstream app {
 server app:3000;
 }

 server {
 listen 80;

 location / {
 proxy_pass http://app;
 proxy_set_header Host $host;
 proxy_set_header X-Real-IP $remote_addr;
 }
 }
}

VI. Override và Multiple Environments

docker-compose.override.yml

1
2
3
4
5
6
7
8
9


# docker-compose.override.yml (tự động load)
version: "3.8"

services:
 app:
 volumes:
 - .:/app
 environment:
 - DEBUG=true

Environment-specific files

1
2
3
4
5


# Development
docker compose -f docker-compose.yml -f docker-compose.dev.yml up -d

# Production
docker compose -f docker-compose.yml -f docker-compose.prod.yml up -d

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# docker-compose.prod.yml
version: "3.8"

services:
 app:
 restart: always
 deploy:
 resources:
 limits:
 memory: 1G
 environment:
 - NODE_ENV=production

Ghi chú triển khai

Khi áp dụng vào dự án của bạn, hãy lưu ý các điểm quan trọng:
- Luôn sử dụng .env file cho sensitive data
- Implement health checks cho critical services
- Sử dụng named volumes cho persistent data
- Cấu hình restart policies phù hợp
Best practices:
- Tách biệt networks cho security
- Sử dụng specific image tags thay vì latest
- Implement proper logging strategy
Troubleshooting:
- Sử dụng docker compose logs để debug
- Kiểm tra docker compose config trước khi deploy
- Monitor resource usage với docker compose top

Lời kết

Docker Compose v2 là công cụ mạnh mẽ giúp bạn quản lý multi-container applications một cách dễ dàng. Với các best practices trên, bạn có thể xây dựng và triển khai ứng dụng một cách chuyên nghiệp và hiệu quả! 🚀

Hãy thử nghiệm với các ví dụ trên và dần dần áp dụng vào dự án thực tế của bạn. 😊

Docker cơ bản: Image vs Container

Sun, 25 Jan 2026 00:00:00 +0000

Docker Image và Container - Hai khái niệm thiết yếu

Khi bắt đầu với Docker, hai khái niệm quan trọng nhất bạn cần hiểu là Image và Container. Nhiều người mới thường nhầm lẫn giữa chúng, nhưng thực chất chúng đóng vai trò khác nhau trong hệ sinh thái Docker. Image giống như kho chứa recipe (làm công thức), còn Container là thực tế thực thi (món ăn được chuẩn bị). 🍳

Trong bài viết này, tôi sẽ giải thích chi tiết sự khác biệt giữa Image và Container, cách chúng hoạt động cùng nhau, và cung cấp ví dụ thực tế để bạn dễ hiểu hơn.

I. Docker Image là gì?

Docker Image là một template (khuôn mẫu) được sử dụng để tạo ra Container. Nó chứa tất cả mọi thứ cần thiết để chạy một ứng dụng:

Operating system (Hệ điều hành) — thường là Linux minimal
Runtime environment (Môi trường chạy) — Node.js, Python, Java, v.v.
Code ứng dụng
Dependencies (Các thư viện phụ thuộc)
Configuration files (Files cấu hình)
Environment variables (Biến môi trường)

Đặc điểm chính của Docker Image

Read-only: Image là chỉ đọc, không thể thay đổi sau khi đã tạo
Layered structure: Image được xây dựng từ các lớp (layers), mỗi layer đại diện cho một lệnh trong Dockerfile
Reusable: Có thể sử dụng cùng một image để tạo ra nhiều container
Version-controlled: Mỗi image có tag (vd: 1.0, latest, alpine) để quản lý phiên bản

Ví dụ về cấu trúc Image:

Layer	Nội dung
Layer 1	Base OS (Alpine Linux)
Layer 2	System packages (curl, wget)
Layer 3	Node.js runtime (18.x)
Layer 4	Application code
Layer 5	Environment variables

Các lệnh phổ biến với Image

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


# Pull một image từ Docker Hub
docker pull node:18-alpine

# Liệt kê các images đã tải về
docker images

# Xóa một image không sử dụng
docker image rm node:18-alpine

# Xóa tất cả unused images
docker image prune -a

# Build image từ Dockerfile
docker build -t myapp:1.0 .

II. Docker Container là gì?

Docker Container là một thực thể đang chạy (running instance) được tạo ra từ Docker Image. Container có:

Một bộ file hệ thống riêng (filesystem)
Không gian mạng riêng (network isolation)
Process riêng, hoạt động độc lập
Các biến môi trường riêng

Đặc điểm chính của Docker Container

Read-only base + Read-write layer: Container có read-write layer cho phép thay đổi dữ liệu
Isolated: Container cô lập với host và các container khác
Stateful: Container có thể ở các trạng thái: running, stopped, paused, exited
Ephemeral: Container có thể tạo và xóa nhanh chóng (< 1 giây)

Ví dụ về Container:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


# Tạo và chạy container từ image
docker run -d --name myapp node:18-alpine node server.js

# Liệt kê các containers đang chạy
docker ps

# Liệt kê tất cả containers (kể cả đã dừng)
docker ps -a

# Dừng container
docker stop myapp

# Khởi động lại container
docker start myapp

# Xóa container
docker rm myapp

# Xem logs của container
docker logs myapp

So sánh Container với Virtual Machine

Tính chất	Docker Container	Virtual Machine
Hệ điều hành	Chia sẻ kernel với host	Có OS riêng đầy đủ
Thời gian khởi động	~ 1-2 giây	~ 1-2 phút
Dung lượng	MB (10-100 MB)	GB (1-10 GB)
Hiệu năng	Gần như native	Cần virtualization overhead
Số lượng tối đa	Hàng trăm host	Tẽn vài chục host

Docker Container Architecture

III. So sánh chi tiết: Image vs Container

Để dễ hình dung, hãy xem bảng so sánh dưới đây:

Bảng so sánh đầy đủ

Khía cạnh	Image	Container
Công thức	Kho chứa recipe (công thức)	Món ăn được thực hiện
Trạng thái	Static (tĩnh, read-only)	Dynamic (động, read-write)
Thay đổi	Không thay đổi sau khi tạo	Có thể thay đổi khi chạy
Số lượng	Có 1 image, tạo N container	Nhiều container từ cùng 1 image
Thời gian tạo	Chậm (build lần đầu ~5-10 phút)	Nhanh (< 1 giây)
Lưu trữ	Lưu trong Docker cache	Lưu thời gian chạy hoặc volume
Portability	Dễ dàng chia sẻ (push/pull)	Chỉ chạy trên môi trường đã install Docker
Version	Có tag quản lý (1.0, 2.0, latest)	Không có version riêng
Network	Không	Có network riêng
Storage	Lưu trữ tại layers	Có read-write layer trên cùng image

Quan hệ giữa Image và Container

1
2
3
4
5
6
7
8
9


Docker Image (Template)
 ↓
 docker run
 ↓
Docker Container (Running Instance)
 ↓
 docker commit
 ↓
Docker Image mới (updated)

Lưu ý:

Image giống như class trong OOP (Object Oriented Programming)
Container giống như object (instance của class)
Dùng docker run để tạo container từ image
Dùng docker commit để save container thành image mới

IV. Ví dụ thực tế từ đầu đến cuối

Để hiểu rõ hơn, hãy cùng làm một ví dụ chi tiết:

Tạo Dockerfile (để build image)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# Dockerfile
FROM node:18-alpine

WORKDIR /app

COPY package*.json ./
RUN npm install

COPY . .

CMD ["node", "server.js"]

Build image từ Dockerfile

1
2
3
4
5
6
7
8


# Build image với tên myapp và tag 1.0
docker build -t myapp:1.0 .

# Xem image đã tạo
docker images
# Output:
# REPOSITORY TAG IMAGE ID CREATED SIZE
# myapp 1.0 abc123def456 2 minutes ago 150MB

Tạo và chạy container từ image

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


# Chạy container từ image myapp:1.0
docker run -d \
 --name myapp-container \
 -p 3000:3000 \
 myapp:1.0

# Xem container đang chạy
docker ps
# Output:
# CONTAINER ID IMAGE COMMAND STATUS PORTS
# xyz789ghi012 myapp:1.0 "node server.js" Up 2 minutes 0.0.0.0:3000->3000/tcp

# Xem logs
docker logs myapp-container

Tương tác với container

1
2
3
4
5
6


# Truy cập nội bộ container
docker exec -it myapp-container sh

# Trong container — bạn có thể:
ls -la /app
curl http://localhost:3000

Xóa container và image

1
2
3
4
5
6
7
8


# Dừng container
docker stop myapp-container

# Xóa container
docker rm myapp-container

# Xóa image
docker rmi myapp:1.0

V. Best practices với Image và Container

Quản lý Image

✅ Sử dụng cụ thể hơn (ex: node:18.12-alpine thay vì node:latest)
✅ Giảm kích thước bằng base image nhỏ (alpine, distroless)
✅ Tận dụng cache layer bằng cách xếp lệnh theo thứ tự
✅ Sử dụng .dockerignore để loại bỏ file không cần thiết
✅ Xóa image unused thường xuyên với docker image prune

1
2
3
4


# Ví dụ: Sử dụng image cụ thể
FROM node:18.12.1-alpine
# thay vì
FROM node:latest

Quản lý Container

✅ Đặt tên container rõ ràng (--name app-container)
✅ Sử dụng -d (detached mode) để chạy container background
✅ Thường xuyên quay lại logs khi debug (docker logs -f)
✅ Sử dụng volumes nếu cần persistence dữ liệu
✅ Giới hạn resource với --cpus, --memory

1
2
3
4
5
6
7


# Run container với giới hạn resource
docker run -d \
 --name app \
 --cpus="1.5" \
 --memory="512m" \
 -p 8080:80 \
 myapp:1.0

Troubleshooting phổ biến

Container không thể tạo từ image

Lỗi:

1

Error: Cannot start container from image

Nguyên nhân:

Image chưa được build hoặc pull về
Image bị corrupt
Port đã được sử dụng bởi container khác

Giải pháp:

1
2
3
4
5
6
7
8


# Kiểm tra image đã tồn tại chưa
docker images | grep myapp

# Pull về lại nếu chưa có
docker pull myapp:1.0

# Build lại image
docker build -t myapp:1.0 .

Container không lưu dữ liệu khi dừng

Nguyên nhân: Container là ephemeral, dữ liệu trong container sẽ mất khi nó dừng hoặc xóa.

Giải pháp: Sử dụng Docker Volumes

1
2
3
4
5
6
7
8


# Tạo volume
docker volume create myapp-data

# Gắn volume vào container
docker run -d \
 --name app \
 -v myapp-data:/app/data \
 myapp:1.0

Container không truy cập được từ bên ngoài

Lỗi: Không thể truy cập http://localhost:3000 khi run container

Giải pháp:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


# Đảm bảo được map port từ container → host
docker run -d \
 --name app \
 -p 3000:3000 \
 myapp:1.0

# Nếu là multi-container, sử dụng docker network
docker network create mynet
docker run -d --network mynet --name app1 myapp:1.0
docker run -d --network mynet --name app2 myapp:1.0

Ghi chú triển khai

Khi áp dụng vào dự án của bạn, hãy lưu ý các điểm quan trọng:

Đừng thay đổi trực tiếp container — Hãy build lại image với Dockerfile
Sử dụng docker-compose.yaml để quản lý nhiều container và dependencies
Sử dụng CI/CD để tự động build và push image lên Docker Hub/Registry
Giám sát ресурс với docker stats hoặc Prometheus + Grafana
Backup dữ liệu thường xuyên từ volumes

Best practices:

Luôn đặt tên image và container rõ ràng
Sử dụng tags cụ thể cho môi trường khác nhau (dev, staging, prod)
Viết .dockerignore để giảm kích thước image và tăng tốc build
Sử dụng multi-stage build để tạo image nhỏ nhất

Troubleshooting:

Khi container bị crash, xem logs: docker logs <container-name>
Khi container không thể pull image, kiểm tra network: ping registry-1.docker.io
Khi container không có quyền truy cập file, gắn volume đúng permission

Lời kết

Tóm tắt lại:

Docker Image = Kho chứa recipe (template read-only) — Chứa tất cả thiết lập để chạy ứng dụng
Docker Container = Món ăn được thực hiện (running instance) — Container được tạo từ image, read-write layer
Image là tĩnh, Container là động
Dùng docker run để tạo container từ image
Dùng docker commit để update container thành image mới

Bây giờ bạn đã hiểu rõ sự khác biệt giữa Image và Container. Bước tiếp theo: học cách sử dụng Dockerfile để build image, và Docker Compose để quản lý nhiều container. 🚀

Nếu bạn thấy bài viết này hữu ích, hãy nhớ ⭐ star repo hoặc 📱 chia sẻ với bạn bè nhé! 😊

Docker on Hoàng Dương

Cài đặt Docker và Docker Compose tự động bằng Bash Script

Tự động hóa cài đặt Docker bằng Bash Script

Yêu cầu hệ thống

Gỡ cài đặt phiên bản Docker cũ (nếu có)

Viết Bash Script cài đặt Docker

Tạo file script

Nội dung script

Cấp quyền và chạy script

Xác nhận kết quả cài đặt

Cấu hình sau cài đặt (Post-installation)

Cho phép user thường chạy Docker (không cần sudo)

Cấu hình Docker khởi động cùng hệ thống

Ghi chú triển khai

Lời kết

Tài liệu tham khảo

Docker Build Cache & Layering

Docker Build Cache & Layering

Layer trong Docker là gì?

Cách Layer được tạo ra

Đặc điểm quan trọng của Layer

Build Cache hoạt động như thế nào?

Quy tắc cache của Docker

Khi nào cache bị invalidate?

Ví dụ minh hoạ cache invalidation

Kỹ thuật tối ưu Build Cache

Sắp xếp lệnh theo tần suất thay đổi

Sử dụng .dockerignore

Sử dụng Cache Mounts

Multi-stage Build

Ví dụ thực tế: Tối ưu Dockerfile cho Node.js

Dockerfile chưa tối ưu

Dockerfile đã tối ưu

So sánh kết quả

Các lệnh hữu ích để debug Cache

Ghi chú triển khai

Lời kết

Tài liệu tham khảo

CI/CD với GitHub Actions cho ứng dụng Docker

GitHub Actions + Docker — Tự động hóa từ code đến container

GitHub Actions là gì?

Các khái niệm cơ bản

Cấu trúc thư mục

Docker Official Actions

Workflow cơ bản — Build và Push lên Docker Hub

Chuẩn bị secrets

Tạo workflow file

Giải thích từng phần

Push lên GitHub Container Registry (GHCR)

Điểm khác biệt so với Docker Hub

Tự động tạo tags với Metadata Action

Kết quả tags theo từng event

Tối ưu build với Cache

GitHub Actions Cache (Khuyến nghị)

Registry Cache

So sánh các loại cache

Ví dụ thực tế — Workflow hoàn chỉnh

Luồng hoạt động

Troubleshooting phổ biến

Lỗi authentication

Build chậm

Lỗi permission khi push lên GHCR

Ghi chú triển khai

Lời kết

Tài liệu tham khảo

Triển khai Node.js với Docker + Nginx

Triển khai Node.js với Docker + Nginx — Case Study

Kiến trúc tổng quan

Bước 1: Tạo ứng dụng Node.js (Express)

Cấu trúc project

File package.json

File src/server.js

Bước 2: Viết Dockerfile cho Node.js

File .dockerignore

File Dockerfile

Bước 3: Cấu hình Nginx làm Reverse Proxy

File nginx/default.conf

Bước 4: Docker Compose — Kết nối tất cả

File docker-compose.yml

Bước 5: Build và chạy

File `package.json`

File `src/server.js`

File `.dockerignore`

File `Dockerfile`

File `nginx/default.conf`

File `docker-compose.yml`