Hoàng Dương

Cron Job với Bash: tự động hóa theo lịch cho DevOps

Sun, 28 Jun 2026 00:00:00 +0000

Cron job trong Bash cho DevOps

Ở bài trước chúng ta đã quản lý biến, .env, tham số CLI và các biến đặc biệt trong Bash. Khi script đã chạy ổn định bằng tay, bước tiếp theo thường là: làm sao để nó tự chạy đúng thời điểm?

cron là công cụ kinh điển trên Linux/Unix để chạy command hoặc script theo lịch. Với DevOps, cron thường dùng cho backup định kỳ, dọn log, healthcheck, đồng bộ file, tạo report, kiểm tra chứng chỉ SSL hoặc gọi một endpoint bảo trì nhẹ.

Điểm quan trọng: cron chạy trong môi trường tối giản hơn terminal của bạn. Vì vậy script chạy đúng khi gọi tay chưa chắc chạy đúng trong cron nếu thiếu PATH, working directory, biến môi trường hoặc log rõ ràng.

Cron và crontab là gì

cron là daemon chạy nền, đọc các bảng lịch và thực thi command khi tới thời điểm phù hợp. Bảng lịch đó thường được gọi là crontab.

Một số lệnh cơ bản:

1
2
3


crontab -l # xem crontab của user hiện tại
crontab -e # chỉnh crontab
crontab -r # xóa crontab của user hiện tại

Bạn có thể chỉnh crontab của user hiện tại bằng crontab -e. Trên server production, hãy cẩn thận với crontab -r vì lệnh này xóa toàn bộ lịch của user đó.

Ví dụ một dòng cron đơn giản:

1

*/5 * * * * /opt/scripts/check-health.sh >> /var/log/check-health.log 2>&1

Dòng trên chạy script mỗi 5 phút và ghi cả stdout/stderr vào file log.

Cú pháp lịch 5 trường

Một cron job phổ biến có 5 trường thời gian, sau đó là command:

1
2
3
4
5
6
7


* * * * * command-to-run
│ │ │ │ │
│ │ │ │ └── day of week: 0-7 (0 hoặc 7 thường là Chủ nhật)
│ │ │ └──── month: 1-12
│ │ └────── day of month: 1-31
│ └──────── hour: 0-23
└────────── minute: 0-59

Một vài ví dụ hay gặp:

1
2
3
4
5
6


* * * * * # mỗi phút
*/5 * * * * # mỗi 5 phút
0 * * * * # đầu mỗi giờ
30 2 * * * # 02:30 mỗi ngày
0 3 * * 0 # 03:00 Chủ nhật hằng tuần
0 1 1 * * # 01:00 ngày đầu mỗi tháng

Cron cũng hỗ trợ danh sách, range và bước nhảy:

1
2


0 9,17 * * 1-5 # 09:00 và 17:00 từ thứ Hai đến thứ Sáu
*/10 8-18 * * * # mỗi 10 phút trong khung 08:00-18:59

Khi viết lịch cho production, nên thêm comment phía trên để người sau hiểu mục đích của job.

Shortcut `@daily`, `@hourly`, `@reboot`

Nhiều hệ thống cron hỗ trợ các shortcut giúp crontab dễ đọc hơn:

1
2
3
4
5


@hourly /opt/scripts/hourly-report.sh
@daily /opt/scripts/backup-db.sh
@weekly /opt/scripts/cleanup-old-logs.sh
@monthly /opt/scripts/monthly-report.sh
@reboot /opt/scripts/start-worker.sh

@daily thường tương đương chạy một lần mỗi ngày vào nửa đêm. @reboot chạy khi cron daemon khởi động, thường dùng cho tác vụ nhẹ sau khi server boot.

Không nên lạm dụng @reboot cho service quan trọng. Với daemon dài hạn, systemd service thường phù hợp hơn vì có restart policy, dependency và log rõ ràng qua journalctl.

Viết script Bash thân thiện với cron

Script chạy từ cron nên tự chuẩn bị môi trường cần thiết thay vì phụ thuộc vào shell tương tác.

Ví dụ khung script tốt:

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


#!/usr/bin/env bash
set -euo pipefail

PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
SCRIPT_DIR="$(cd -- "$(dirname -- "${BASH_SOURCE[0]}")" && pwd)"
LOG_DIR="/var/log/example-app"

mkdir -p "${LOG_DIR}"

log_info() {
 printf '%s [INFO] %s\n' "$(date -Is)" "$*"
}

log_error() {
 printf '%s [ERROR] %s\n' "$(date -Is)" "$*" >&2
}

cd "${SCRIPT_DIR}"
log_info "Script started"

Các điểm cần chú ý:

Khai báo shebang rõ ràng.
Bật set -euo pipefail để lỗi không bị nuốt im lặng.
Đặt PATH trong script hoặc trong crontab.
Dùng path tuyệt đối cho file quan trọng.
Ghi log có timestamp.
Không giả định cron chạy từ thư mục project.

Redirect log trong cron

Cron có thể gửi output qua mail nội bộ nếu hệ thống cấu hình mail. Trong thực tế DevOps, ghi log vào file thường dễ kiểm soát hơn.

Ví dụ redirect stdout và stderr:

1

*/5 * * * * /opt/scripts/check-health.sh >> /var/log/check-health.log 2>&1

Ý nghĩa:

>> /var/log/check-health.log: append stdout vào file.
2>&1: chuyển stderr vào cùng nơi với stdout.

Nếu muốn tách log lỗi riêng:

1

*/5 * * * * /opt/scripts/check-health.sh >> /var/log/check-health.out 2>> /var/log/check-health.err

Với job chạy thường xuyên, cần có chiến lược rotate log bằng logrotate hoặc tự giới hạn dung lượng, nếu không file log có thể đầy disk.

Kiểm tra log cron

Vị trí log cron phụ thuộc distro và cấu hình logging.

Trên nhiều hệ thống Ubuntu/Debian dùng syslog:

1

grep CRON /var/log/syslog

Trên hệ thống dùng systemd journal:

1
2


journalctl -u cron
journalctl -u crond

Một số distro dùng service tên crond thay vì cron. Nếu không chắc, kiểm tra service:

1
2


systemctl status cron
systemctl status crond

Lưu ý: log cron thường chỉ cho biết cron đã gọi command hay chưa, không đảm bảo command thành công. Muốn biết script lỗi gì, bạn vẫn cần redirect output hoặc tự ghi log trong script.

Vấn đề `PATH` và environment trong cron

Cron không load đầy đủ .bashrc, .profile hoặc environment giống terminal của bạn. Đây là nguyên nhân phổ biến khiến script chạy tay thì đúng, nhưng vào cron lại lỗi command not found.

Ví dụ nên đặt PATH ở đầu crontab:

1
2
3
4


SHELL=/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

*/5 * * * * /opt/scripts/check-health.sh >> /var/log/check-health.log 2>&1

Hoặc dùng path tuyệt đối cho command trong script:

1

/usr/bin/curl --fail --silent --show-error https://example.com/health

Với biến môi trường riêng của app, ưu tiên load từ file config do bạn kiểm soát:

1
2
3
4
5


set -a
source /etc/example-app/backup.env
set +a

: "${DATABASE_URL:?DATABASE_URL is required}"

Không đặt secret trực tiếp trong crontab nếu nhiều người có quyền đọc crontab hoặc backup hệ thống. Với secret quan trọng, dùng secret manager, file quyền hạn chặt chẽ hoặc cơ chế secret của nền tảng đang dùng.

Thực hành DevOps: backup database hằng đêm

Ví dụ dưới đây minh họa script backup PostgreSQL hằng đêm. Script dùng biến môi trường từ file cấu hình, tạo thư mục backup, nén output và xóa bản backup cũ.

File /opt/scripts/backup-db.sh:

 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


#!/usr/bin/env bash
set -euo pipefail

PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
ENV_FILE="/etc/example-app/backup.env"
BACKUP_DIR="/var/backups/example-app"
RETENTION_DAYS="${RETENTION_DAYS:-7}"

log() {
 printf '%s [%s] %s\n' "$(date -Is)" "$1" "$2"
}

if [[ ! -r "${ENV_FILE}" ]]; then
 log "ERROR" "Cannot read env file: ${ENV_FILE}" >&2
 exit 1
fi

set -a
source "${ENV_FILE}"
set +a

: "${DATABASE_NAME:?DATABASE_NAME is required}"
: "${DATABASE_USER:?DATABASE_USER is required}"
: "${DATABASE_HOST:?DATABASE_HOST is required}"

mkdir -p "${BACKUP_DIR}"

backup_file="${BACKUP_DIR}/${DATABASE_NAME}-$(date +%Y%m%d%H%M%S).sql.gz"

log "INFO" "Starting backup to ${backup_file}"

pg_dump \
 --host "${DATABASE_HOST}" \
 --username "${DATABASE_USER}" \
 --dbname "${DATABASE_NAME}" \
 --format plain \
 --no-owner \
 | gzip > "${backup_file}"

find "${BACKUP_DIR}" -type f -name "${DATABASE_NAME}-*.sql.gz" -mtime +"${RETENTION_DAYS}" -delete

log "INFO" "Backup completed"

File /etc/example-app/backup.env:

1
2
3
4
5


DATABASE_NAME=blog_app
DATABASE_USER=backup_user
DATABASE_HOST=db-01.example.com
PGPASSWORD=<database-password>
RETENTION_DAYS=14

Đặt quyền file config chặt chẽ:

1
2
3


sudo chown root:root /etc/example-app/backup.env
sudo chmod 600 /etc/example-app/backup.env
sudo chmod 700 /opt/scripts/backup-db.sh

Thêm cron job chạy lúc 02:30 mỗi ngày:

1

30 2 * * * /opt/scripts/backup-db.sh >> /var/log/backup-db.log 2>&1

Trong môi trường thật, hãy test restore định kỳ. Backup chỉ có giá trị khi bạn biết chắc có thể khôi phục được.

Thực hành DevOps: healthcheck mỗi 5 phút

Ví dụ script kiểm tra endpoint /health, retry nhẹ rồi ghi log. Nếu endpoint vẫn lỗi, script trả exit code khác 0 để cron log lại trạng thái lỗi.

File /opt/scripts/check-health.sh:

 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


#!/usr/bin/env bash
set -euo pipefail

PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
HEALTH_URL="${HEALTH_URL:-https://example.com/health}"
MAX_ATTEMPTS="${MAX_ATTEMPTS:-3}"
DELAY_SECONDS="${DELAY_SECONDS:-5}"

log() {
 printf '%s [%s] %s\n' "$(date -Is)" "$1" "$2"
}

attempt=1

while (( attempt <= MAX_ATTEMPTS )); do
 if curl --fail --silent --show-error --max-time 10 "${HEALTH_URL}" > /dev/null; then
 log "INFO" "Healthcheck OK: ${HEALTH_URL}"
 exit 0
 fi

 log "WARN" "Healthcheck attempt ${attempt}/${MAX_ATTEMPTS} failed"

 if (( attempt == MAX_ATTEMPTS )); then
 log "ERROR" "Healthcheck failed after ${MAX_ATTEMPTS} attempts" >&2
 exit 1
 fi

 sleep "${DELAY_SECONDS}"
 ((attempt++))
done

Crontab:

1

*/5 * * * * HEALTH_URL=https://example.com/health /opt/scripts/check-health.sh >> /var/log/check-health.log 2>&1

Inline environment variable như trên phù hợp với giá trị không nhạy cảm. Nếu cần token hoặc header bí mật, hãy load từ file quyền hạn chặt chẽ hoặc secret manager thay vì đặt thẳng trong crontab.

Tránh job chạy chồng lên nhau

Nếu một job chạy lâu hơn chu kỳ cron, lần chạy mới có thể bắt đầu khi lần cũ chưa xong. Điều này nguy hiểm với backup, cleanup hoặc deploy.

Một cách phổ biến là dùng flock:

1

*/5 * * * * flock -n /tmp/check-health.lock /opt/scripts/check-health.sh >> /var/log/check-health.log 2>&1

flock -n sẽ không chờ lock. Nếu job cũ còn chạy, job mới thoát ngay. Với backup:

1

30 2 * * * flock -n /tmp/backup-db.lock /opt/scripts/backup-db.sh >> /var/log/backup-db.log 2>&1

Không phải hệ thống nào cũng cài sẵn flock, nhưng trên nhiều distro Linux nó nằm trong gói util-linux. Nếu môi trường của bạn không có flock, cần dùng cơ chế lock khác và xử lý stale lock cẩn thận.

Sai sót thường gặp

Quên redirect log: Job lỗi nhưng không có output để debug.
Phụ thuộc vào working directory: Cron không đảm bảo chạy trong thư mục project.
Thiếu PATH: Command như docker, kubectl, node, python có thể không tìm thấy.
Dùng path tương đối: File config, log, backup nên dùng path tuyệt đối.
Không kiểm soát job chạy chồng: Backup/cleanup có thể chạy đồng thời và gây hỏng dữ liệu.
Đặt secret trực tiếp trong crontab: Khó quản lý quyền và audit.
Không test command trước khi lưu crontab: Nên chạy script bằng đúng user sẽ chạy cron.

Ghi chú triển khai

Khi áp dụng vào dự án của bạn, hãy chuẩn hóa mỗi cron job theo checklist nhỏ:
- Script có shebang, set -euo pipefail và path tuyệt đối.
- Crontab có comment mô tả mục đích job.
- Output được redirect vào log hoặc gửi về hệ thống logging.
- Job dài có lock để tránh chạy chồng.
- Secret nằm trong nơi phù hợp, không hardcode trong script public.
Best practices:
- Test script bằng tay với đúng user: sudo -u <app-user> /opt/scripts/job.sh.
- Ghi timestamp trong log để dễ đối chiếu sự cố.
- Đặt PATH rõ ràng trong script hoặc crontab.
- Dùng flock cho job có thể chạy lâu.
- Theo dõi dung lượng log/backup bằng logrotate hoặc retention policy.
Troubleshooting:
- Job không chạy? → Kiểm tra crontab -l, cú pháp lịch, timezone và log cron.
- Job chạy nhưng command lỗi? → Kiểm tra file log riêng của script.
- Chạy tay đúng nhưng cron sai? → Kiểm tra PATH, working directory, permission và biến môi trường.

Lời kết

Cron giúp Bash script trở thành một phần của lịch vận hành tự động: backup hằng đêm, healthcheck định kỳ, cleanup log hoặc tạo report. Nhưng để cron job đáng tin cậy, bạn cần viết script tự chủ về môi trường, dùng path tuyệt đối, ghi log rõ ràng và tránh chạy chồng khi job có thể kéo dài.

Ở bài tiếp theo, chúng ta sẽ đi vào debug script Bash: bash -x, bash -n, set -x, set -e, set -u, pipefail, trap ERR, PS4 và shellcheck để tìm lỗi nhanh hơn.

Tài liệu tham khảo

man7.org — crontab(5) — Tham khảo cú pháp crontab, 5 trường thời gian và các biến môi trường trong cron.
man7.org — cron(8) — Mô tả cron daemon và cách cron xử lý lịch chạy.
man7.org — flock(1) — Tham khảo flock để tránh job chạy chồng.
PostgreSQL Documentation — pg_dump — Tài liệu chính thức về pg_dump dùng trong ví dụ backup.
curl Documentation — Tham khảo --fail, --silent, --show-error, --max-time dùng trong ví dụ healthcheck.

Quản lý biến và môi trường trong Bash cho DevOps

Wed, 24 Jun 2026 00:00:00 +0000

Vì sao biến môi trường quan trọng trong Bash

Ở bài trước chúng ta đã tách logic thành function để script dễ tái sử dụng hơn. Khi script bắt đầu chạy trong nhiều môi trường — local, staging, production, CI/CD runner — vấn đề tiếp theo là: cấu hình lấy từ đâu và truyền vào như thế nào?

Biến trong Bash giúp lưu giá trị tạm thời trong script. Biến môi trường giúp truyền cấu hình cho process con như docker, kubectl, aws, curl hoặc ứng dụng mà script khởi chạy. Nếu quản lý biến không rõ ràng, script rất dễ deploy nhầm môi trường, lộ secret, hoặc chạy sai vì thiếu config.

Biến cục bộ và cách gán giá trị

Cú pháp gán biến trong Bash không có khoảng trắng quanh dấu =:

1
2
3


APP_NAME="blog-api"
ENVIRONMENT="staging"
RETRY_COUNT=3

Khi đọc biến, dùng $VAR hoặc ${VAR}. Trong script thực tế, ${VAR} thường rõ ràng hơn khi nối chuỗi:

1
2


echo "Deploying ${APP_NAME} to ${ENVIRONMENT}"
LOG_FILE="/var/log/${APP_NAME}.log"

Một lỗi rất phổ biến là thêm khoảng trắng:

1

APP_NAME = "blog-api" # sai: Bash hiểu APP_NAME là command

Khi giá trị có khoảng trắng hoặc ký tự đặc biệt, luôn quote biến:

1
2


BACKUP_DIR="/opt/backups/blog api"
mkdir -p "${BACKUP_DIR}"

Không quote biến có thể làm path bị tách thành nhiều argument, gây lỗi khó đoán trong script vận hành.

`export`: khi nào biến trở thành environment variable

Biến Bash bình thường chỉ tồn tại trong shell hiện tại. Process con không tự thấy biến đó:

1
2


APP_ENV="staging"
bash -c 'echo "APP_ENV=$APP_ENV"' # rỗng

Muốn process con đọc được, dùng export:

1
2


export APP_ENV="staging"
bash -c 'echo "APP_ENV=$APP_ENV"' # APP_ENV=staging

Trong DevOps, export thường dùng khi gọi CLI hoặc chạy ứng dụng:

1
2
3
4


export AWS_PROFILE="staging"
export KUBECONFIG="${HOME}/.kube/staging-config"

kubectl get pods

Bạn cũng có thể truyền biến chỉ cho một command:

1

APP_ENV="staging" ./run-migration.sh

Cách này gọn và an toàn hơn nếu biến chỉ cần tồn tại cho đúng một lệnh.

Xem, đặt và xóa biến với `env`, `set`, `unset`

Một vài command hữu ích khi debug môi trường chạy script:

1
2
3
4


env # in environment variables
printenv APP_ENV # in một biến môi trường cụ thể
set # in cả shell variables, functions và environment variables
unset APP_ENV # xóa biến

env phù hợp để kiểm tra process con sẽ thấy gì. set chi tiết hơn, nhưng output dài và có thể chứa dữ liệu nhạy cảm, nên hạn chế paste nguyên output vào ticket hoặc log.

Ví dụ kiểm tra biến bắt buộc:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


require_env() {
 local name="$1"

 if [[ -z "${!name:-}" ]]; then
 echo "ERROR: missing required env ${name}" >&2
 return 1
 fi
}

require_env "APP_ENV"
require_env "DATABASE_URL"

Cú pháp ${!name} là indirect expansion: nếu name="APP_ENV", Bash sẽ đọc giá trị của biến APP_ENV.

Đọc cấu hình từ file `.env`

File .env giúp tách config khỏi code:

1
2
3


APP_ENV=staging
APP_PORT=8080
BACKUP_DIR=/opt/backups/blog

Cách đơn giản để load file:

1
2
3


set -a
source .env
set +a

set -a làm các biến được gán sau đó tự động export, nên process con có thể đọc được.

Tuy nhiên, source .env sẽ thực thi nội dung file như Bash code. Vì vậy chỉ dùng với file bạn kiểm soát, không source file upload từ user hoặc nguồn không tin cậy.

Một pattern an toàn hơn cho script deploy:

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


ENV_FILE="${1:-.env}"

if [[ ! -f "${ENV_FILE}" ]]; then
 echo "ERROR: env file not found: ${ENV_FILE}" >&2
 exit 1
fi

set -a
source "${ENV_FILE}"
set +a

: "${APP_ENV:?APP_ENV is required}"
: "${APP_PORT:?APP_PORT is required}"

Dòng : "${VAR:?message}" khiến script dừng ngay nếu biến chưa được set hoặc rỗng. Đây là cách fail-fast rất hữu ích trước khi chạy deploy.

Nhận tham số CLI bằng `getopts`

Không phải cấu hình nào cũng nên nằm trong .env. Những giá trị thay đổi theo lần chạy, như môi trường đích hoặc chế độ dry-run, nên nhận qua flag:

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


#!/usr/bin/env bash
set -euo pipefail

ENVIRONMENT="staging"
DRY_RUN="false"

while getopts ":e:n" opt; do
 case "${opt}" in
 e)
 ENVIRONMENT="${OPTARG}"
 ;;
 n)
 DRY_RUN="true"
 ;;
 ?)
 echo "Usage: $0 [-e environment] [-n]" >&2
 exit 2
 ;;
 esac
done

echo "environment=${ENVIRONMENT} dry_run=${DRY_RUN}"

Chạy thử:

1

./deploy.sh -e production -n

getopts phù hợp cho option ngắn như -e production, -n. Nếu cần long option như --environment, bạn có thể tự parse bằng case, nhưng nên giữ format đơn giản để script dễ bảo trì.

`$IFS`: kiểm soát cách Bash tách chuỗi

IFS là Internal Field Separator — tập ký tự Bash dùng để tách word khi xử lý một số expansion và lệnh read. Mặc định gồm space, tab và newline.

Khi đọc file từng dòng, dùng pattern này để giữ nguyên khoảng trắng đầu/cuối và không xử lý backslash đặc biệt:

1
2
3
4
5


while IFS= read -r server; do
 [[ -z "${server}" || "${server}" == \#* ]] && continue
 echo "Checking ${server}"
 ssh "deploy@${server}" "hostname && uptime"
done < servers.txt

Khi tách chuỗi CSV đơn giản:

1
2
3
4
5
6


TARGETS="web-01,web-02,web-03"
IFS=',' read -r -a servers <<< "${TARGETS}"

for server in "${servers[@]}"; do
 echo "Deploy to ${server}"
done

Tránh đổi IFS global nếu không cần. Nếu phải đổi, hãy giới hạn trong một dòng hoặc một scope nhỏ để không làm hỏng phần khác của script.

Các biến đặc biệt thường gặp

Bash có nhiều biến đặc biệt rất hữu ích khi viết script vận hành:

Biến	Ý nghĩa
`$0`	Tên script đang chạy
`$1`, `$2`	Tham số vị trí
`$@`	Toàn bộ tham số, nên dùng `"$@"`
`$#`	Số lượng tham số
`$?`	Exit code của command vừa chạy
`$$`	PID của shell hiện tại
`$!`	PID của background process gần nhất
`${BASH_SOURCE[0]}`	Đường dẫn file script hiện tại trong Bash

Ví dụ dùng $! và wait để theo dõi background job:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


./long-healthcheck.sh &
healthcheck_pid=$!

echo "Healthcheck PID: ${healthcheck_pid}"

if wait "${healthcheck_pid}"; then
 echo "Healthcheck passed"
else
 echo "Healthcheck failed" >&2
 exit 1
fi

Ví dụ lấy thư mục chứa script, không phụ thuộc bạn chạy script từ đâu:

1
2


SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
source "${SCRIPT_DIR}/lib/log.sh"

Pattern này rất hữu ích khi script cần load file config hoặc thư viện nằm cạnh nó.

Ví dụ DevOps: script deploy đọc `.env`, nhận flag và validate biến

Ví dụ dưới đây mô phỏng một script deploy nhỏ. Script nhận môi trường qua -e, hỗ trợ dry-run bằng -n, load file .env.<environment>, validate biến bắt buộc rồi chạy lệnh deploy.

 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


#!/usr/bin/env bash
set -euo pipefail

ENVIRONMENT="staging"
DRY_RUN="false"

usage() {
 echo "Usage: $0 [-e staging|production] [-n]" >&2
}

while getopts ":e:n" opt; do
 case "${opt}" in
 e) ENVIRONMENT="${OPTARG}" ;;
 n) DRY_RUN="true" ;;
 ?) usage; exit 2 ;;
 esac
done

case "${ENVIRONMENT}" in
 staging|production) ;;
 *)
 echo "ERROR: unsupported environment: ${ENVIRONMENT}" >&2
 exit 2
 ;;
esac

SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
ENV_FILE="${SCRIPT_DIR}/.env.${ENVIRONMENT}"

if [[ ! -f "${ENV_FILE}" ]]; then
 echo "ERROR: env file not found: ${ENV_FILE}" >&2
 exit 1
fi

set -a
source "${ENV_FILE}"
set +a

: "${APP_NAME:?APP_NAME is required}"
: "${IMAGE_TAG:?IMAGE_TAG is required}"
: "${DEPLOY_HOST:?DEPLOY_HOST is required}"

cmd=(ssh "deploy@${DEPLOY_HOST}" "docker service update --image ${APP_NAME}:${IMAGE_TAG} ${APP_NAME}")

printf 'Environment: %s\n' "${ENVIRONMENT}"
printf 'Command: %q ' "${cmd[@]}"
printf '\n'

if [[ "${DRY_RUN}" == "true" ]]; then
 echo "Dry-run mode: command was not executed"
 exit 0
fi

"${cmd[@]}"

File .env.staging có thể như sau:

1
2
3


APP_NAME=blog-api
IMAGE_TAG=2026.06.24
DEPLOY_HOST=webserver-01

Điểm quan trọng trong ví dụ:

Không hardcode host/image tag trong script.
Validate môi trường hợp lệ trước khi source file.
Dùng set -a để export config cho process con nếu cần.
Dùng dry-run để kiểm tra lệnh trước khi chạy thật.
Quote biến khi dựng path và argument.

Sai sót thường gặp

Gán biến có khoảng trắng quanh =: NAME = value là sai trong Bash.
Không quote biến: Path có khoảng trắng hoặc ký tự glob như * có thể làm script chạy sai.
Export quá nhiều: Chỉ export biến mà process con cần đọc.
Source .env không tin cậy: .env là Bash code khi dùng source, có thể thực thi lệnh.
Đưa secret vào log: Tránh set -x quanh đoạn xử lý token/password.
Dùng $1 trực tiếp với set -u: Hãy dùng ${1:-} hoặc validate trước.
Đổi IFS global: Có thể làm hỏng loop hoặc parse argument ở đoạn sau.

Ghi chú triển khai

Khi áp dụng vào dự án của bạn, hãy phân loại cấu hình:
- Giá trị cố định theo môi trường → .env.staging, .env.production hoặc config file riêng.
- Giá trị thay đổi theo lần chạy → flag CLI qua getopts.
- Secret → biến môi trường từ CI/CD secret store hoặc vault, không commit vào git.
Best practices:
- Bật set -u để phát hiện biến chưa khai báo, nhưng dùng ${VAR:-} khi biến optional.
- Validate biến bắt buộc sớm bằng : "${VAR:?message}".
- Dùng printenv VAR để debug một biến thay vì in toàn bộ environment.
- Prefix biến theo app, ví dụ BLOG_APP_ENV, để tránh trùng tên.
- Không commit file .env chứa secret; chỉ commit .env.example.
Troubleshooting:
- Process con không thấy biến? → Kiểm tra bạn đã export chưa.
- Script chạy đúng local nhưng sai cron/CI? → Kiểm tra PATH, working directory và biến môi trường runner cung cấp.
- .env không load đúng? → Kiểm tra file có syntax Bash hợp lệ, không có khoảng trắng quanh =.

Lời kết

Quản lý biến tốt giúp Bash script chạy ổn định hơn giữa nhiều môi trường. Hãy giữ code và config tách biệt, validate biến bắt buộc trước khi thao tác thật, quote biến khi dùng trong command, và chỉ export những gì process con cần.

Ở bài tiếp theo, chúng ta sẽ đi vào cron job với Bash: cú pháp lịch chạy, crontab, @daily, @reboot, log cron, vấn đề PATH và ví dụ backup/healthcheck tự động.

Tài liệu tham khảo

GNU Bash Manual — Shell Parameters — Tài liệu chính thức về positional parameters và special parameters.
GNU Bash Manual — Bourne Shell Builtins — Tham khảo export, set, unset, getopts, source.
GNU Bash Manual — Word Splitting — Giải thích vai trò của IFS trong word splitting.
The Open Group — Shell Command Language — Tham khảo chuẩn POSIX shell về biến, quoting và expansion.

Function trong Bash: tái sử dụng code hiệu quả cho DevOps

Tue, 09 Jun 2026 00:00:00 +0000

Function trong Bash cho DevOps

Ở bài trước chúng ta đã dùng grep, awk và sed để xử lý log/config. Khi script bắt đầu dài hơn, bạn sẽ gặp một vấn đề mới: nhiều đoạn code bị lặp lại — kiểm tra file, ghi log, validate biến môi trường, retry command, tạo backup trước khi sửa config.

Function giúp gom một nhóm lệnh thành một khối có tên, có thể gọi lại nhiều lần. Với DevOps, đây là bước quan trọng để biến các script “chạy được” thành script dễ đọc, dễ test và dễ bảo trì hơn.

Khai báo function trong Bash

Bash hỗ trợ hai kiểu khai báo phổ biến:

1
2
3
4
5
6
7


log_info() {
 echo "INFO: $1"
}

function log_error {
 echo "ERROR: $1" >&2
}

Trong thực tế, kiểu name() { ...; } thường được dùng nhiều vì ngắn gọn và portable hơn giữa các shell kiểu POSIX. Với bài này, chúng ta tập trung vào Bash nên cả hai đều chạy được.

Gọi function giống gọi command:

1
2


log_info "Starting deploy"
log_error "Deploy failed"

Lưu ý khoảng trắng và dấu ; khi viết một dòng:

1

say_hello() { echo "hello"; }

Nếu viết nhiều dòng, dấu ; trước } không cần thiết vì newline đã kết thúc command.

Function nhận tham số bằng `$1`, `$@`, `$#`

Trong function, Bash dùng các positional parameters giống script:

$1, $2, …: tham số thứ nhất, thứ hai, …
$@: toàn bộ tham số, giữ từng argument riêng khi được quote thành "$@".
$#: số lượng tham số.
$0: tên script, không phải tên function.

Ví dụ function kiểm tra service:

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


check_service() {
 local service_name="$1"

 if systemctl is-active --quiet "${service_name}"; then
 echo "OK: ${service_name} is running"
 else
 echo "ERROR: ${service_name} is not running" >&2
 return 1
 fi
}

check_service "nginx"
check_service "docker"

Khi cần truyền toàn bộ argument sang command khác, dùng "$@":

1
2
3
4
5
6


run_cmd() {
 echo "+ $*"
 "$@"
}

run_cmd ls -lah /var/log

"$@" giữ nguyên ranh giới argument. Đây là lựa chọn an toàn hơn so với $* khi tham số có khoảng trắng.

Validate tham số đầu vào

Function nên kiểm tra tham số bắt buộc ngay từ đầu để lỗi rõ ràng hơn.

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


require_arg() {
 local name="$1"
 local value="${2:-}"

 if [[ -z "${value}" ]]; then
 echo "ERROR: Missing required argument: ${name}" >&2
 return 2
 fi
}

backup_file() {
 local file_path="${1:-}"

 require_arg "file_path" "${file_path}" || return $?

 if [[ ! -f "${file_path}" ]]; then
 echo "ERROR: Not a regular file: ${file_path}" >&2
 return 1
 fi

 cp -- "${file_path}" "${file_path}.bak.$(date +%Y%m%d%H%M%S)"
}

Dùng ${1:-} giúp tránh lỗi “unbound variable” khi script bật set -u mà function được gọi thiếu tham số.

Return value trong Bash là exit code

Function Bash không return dữ liệu dạng string như nhiều ngôn ngữ lập trình. return trong Bash trả về exit code từ 0 đến 255:

0: thành công.
Khác 0: lỗi hoặc trạng thái đặc biệt.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


is_readable_file() {
 local file_path="$1"
 [[ -f "${file_path}" && -r "${file_path}" ]]
}

if is_readable_file "./app.env"; then
 echo "app.env is readable"
else
 echo "Cannot read app.env" >&2
fi

Ở ví dụ trên, function không cần viết return rõ ràng. Exit code của lệnh cuối cùng ([[ ... ]]) sẽ trở thành exit code của function.

Nếu muốn function “trả về dữ liệu”, hãy in ra stdout rồi dùng command substitution:

1
2
3
4
5


get_timestamp() {
 date +%Y%m%d%H%M%S
}

backup_name="app.env.$(get_timestamp).bak"

Nguyên tắc thực dụng: dùng exit code cho đúng/sai, dùng stdout cho dữ liệu.

Biến local để tránh side effect

Theo mặc định, biến trong function Bash là global trong phạm vi shell hiện tại. Dùng local để giới hạn biến trong function.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


build_backup_path() {
 local source_file="$1"
 local timestamp
 local base_name

 timestamp="$(date +%Y%m%d%H%M%S)"
 base_name="$(basename "${source_file}")"

 echo "./backup/${base_name}.${timestamp}.bak"
}

Không dùng local, các biến như timestamp hoặc base_name có thể vô tình ghi đè biến cùng tên ở nơi khác trong script. Đây là lỗi khó debug khi script lớn dần.

Một thói quen tốt là khai báo local gần nơi dùng và quote biến khi truyền vào command:

1
2


local target_dir="${1:-./backup}"
mkdir -p "${target_dir}"

Tách function vào file khác với `source`

Khi nhiều script cùng cần logging, validation hoặc retry, bạn có thể tách function vào file thư viện nhỏ.

Ví dụ cấu trúc:

1
2
3
4


scripts/
├── deploy.sh
└── lib/
 └── log.sh

File scripts/lib/log.sh:

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


#!/usr/bin/env bash

log_info() {
 printf '[INFO] %s\n' "$*"
}

log_warn() {
 printf '[WARN] %s\n' "$*" >&2
}

log_error() {
 printf '[ERROR] %s\n' "$*" >&2
}

File scripts/deploy.sh:

1
2
3
4
5
6
7
8
9


#!/usr/bin/env bash
set -euo pipefail

SCRIPT_DIR="$(cd -- "$(dirname -- "${BASH_SOURCE[0]}")" && pwd)"
source "${SCRIPT_DIR}/lib/log.sh"

log_info "Starting deploy"
log_warn "This is a warning message"
log_error "This is an error message"

source chạy nội dung file trong shell hiện tại, nên các function trong log.sh sẽ có sẵn cho deploy.sh. Trong Bash, ${BASH_SOURCE[0]} giúp xác định đường dẫn file script hiện tại tốt hơn $0 khi file được source hoặc gọi từ thư mục khác.

Thực hành DevOps: thư viện logging nhỏ

Một thư viện logging tối thiểu nên có timestamp, level và tách stdout/stderr hợp lý.

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


#!/usr/bin/env bash

_log() {
 local level="$1"
 shift

 printf '%s [%s] %s\n' "$(date -Is)" "${level}" "$*"
}

log_info() {
 _log "INFO" "$@"
}

log_warn() {
 _log "WARN" "$@" >&2
}

log_error() {
 _log "ERROR" "$@" >&2
}

Đặt function nội bộ tên _log là convention đơn giản để báo hiệu “không gọi trực tiếp từ bên ngoài”. Bash không có private function thật sự, nên đây chỉ là quy ước.

Dùng trong script healthcheck:

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


#!/usr/bin/env bash
set -euo pipefail

SCRIPT_DIR="$(cd -- "$(dirname -- "${BASH_SOURCE[0]}")" && pwd)"
source "${SCRIPT_DIR}/lib/log.sh"

check_url() {
 local url="$1"

 if curl --fail --silent --show-error --max-time 5 "${url}" > /dev/null; then
 log_info "Healthcheck OK: ${url}"
 else
 log_error "Healthcheck failed: ${url}"
 return 1
 fi
}

check_url "https://example.com/health"

Ở đây curl --fail giúp HTTP 4xx/5xx được xem là lỗi, --silent --show-error giảm noise nhưng vẫn in lỗi cần thiết, và --max-time tránh script treo quá lâu.

Thực hành DevOps: retry command bằng function

Retry là pattern rất thường gặp khi gọi API, pull image, kiểm tra service vừa restart hoặc chạy lệnh có thể lỗi tạm thờ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


retry() {
 local max_attempts="$1"
 local delay_seconds="$2"
 shift 2

 local attempt=1

 while (( attempt <= max_attempts )); do
 if "$@"; then
 return 0
 fi

 echo "WARN: attempt ${attempt}/${max_attempts} failed: $*" >&2

 if (( attempt == max_attempts )); then
 return 1
 fi

 sleep "${delay_seconds}"
 ((attempt++))
 done
}

retry 5 3 curl --fail --silent --show-error https://example.com/health

Điểm quan trọng:

shift 2 bỏ hai tham số cấu hình để phần còn lại là command cần chạy.
"$@" chạy command với argument được giữ nguyên.
Function trả 0 ngay khi command thành công, trả 1 sau khi hết số lần thử.

Bạn có thể kết hợp với logging library:

1
2
3
4
5
6


if retry 5 3 curl --fail --silent --show-error https://example.com/health; then
 log_info "Service is healthy"
else
 log_error "Service is still unhealthy after retry"
 exit 1
fi

Thực hành DevOps: deploy script có function rõ ràng

Ví dụ script deploy nhỏ, tách từng bước thành function để dễ đọc hơ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
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


#!/usr/bin/env bash
set -euo pipefail

APP_DIR="${APP_DIR:-/opt/example-app}"
SERVICE_NAME="${SERVICE_NAME:-example-app}"

log_info() {
 printf '%s [INFO] %s\n' "$(date -Is)" "$*"
}

log_error() {
 printf '%s [ERROR] %s\n' "$(date -Is)" "$*" >&2
}

require_dir() {
 local dir_path="$1"

 if [[ ! -d "${dir_path}" ]]; then
 log_error "Directory not found: ${dir_path}"
 return 1
 fi
}

pull_latest_code() {
 git -C "${APP_DIR}" pull --ff-only
}

restart_service() {
 sudo systemctl restart "${SERVICE_NAME}"
}

verify_service() {
 systemctl is-active --quiet "${SERVICE_NAME}"
}

main() {
 require_dir "${APP_DIR}"
 log_info "Pulling latest code"
 pull_latest_code

 log_info "Restarting ${SERVICE_NAME}"
 restart_service

 log_info "Verifying ${SERVICE_NAME}"
 if verify_service; then
 log_info "Deploy completed"
 else
 log_error "Service is not active after restart"
 return 1
 fi
}

main "$@"

Pattern main "$@" giúp script có entrypoint rõ ràng. Các function phía trên định nghĩa hành vi, còn main mô tả luồng chạy chính.

Sai sót thường gặp

Quên local: Biến trong function có thể ghi đè biến global ngoài ý muốn.
Dùng return "text": return chỉ dành cho exit code số; muốn trả text thì echo/printf ra stdout.
Không quote "$@": Command wrapper dễ hỏng khi argument có khoảng trắng.
Gọi function trước khi khai báo: Bash đọc và chạy từ trên xuống; function phải được định nghĩa trước khi gọi.
Dùng $1 trực tiếp khi bật set -u: Nếu thiếu tham số, script lỗi ngay. Dùng ${1:-} rồi validate.
Ghi log lỗi ra stdout: Error/warn nên đi stderr (>&2) để stdout còn dùng cho dữ liệu/pipeline.

Ghi chú triển khai

Khi áp dụng vào dự án của bạn, hãy bắt đầu bằng các function nhỏ cho phần lặp lại nhiều nhất:
- log_info, log_warn, log_error.
- require_file, require_dir, require_env.
- retry cho lệnh có lỗi tạm thời.
- backup_file trước khi sửa config.
Best practices:
- Dùng local cho biến trong function.
- Dùng return cho trạng thái thành công/thất bại, stdout cho dữ liệu.
- Dùng "$@" khi wrapper function gọi command khác.
- Tách thư viện chung vào scripts/lib/*.sh và load bằng source với đường dẫn dựa trên ${BASH_SOURCE[0]}.
- Giữ function làm một việc rõ ràng; nếu function quá dài, tách tiếp.
Troubleshooting:
- Function trả sai trạng thái? → In thử $? ngay sau khi gọi hoặc chạy bash -x script.sh.
- Biến bị đổi bất ngờ? → Kiểm tra function thiếu local.
- source không tìm thấy file? → Kiểm tra SCRIPT_DIR và chạy script từ thư mục khác để test.

Lời kết

Function là bước nâng cấp tự nhiên khi bạn viết Bash cho DevOps nhiều hơn một vài dòng. Chúng giúp tái sử dụng logic, gom logging/validation/retry vào nơi chung, giảm copy-paste và làm luồng deploy/healthcheck rõ ràng hơn.

Ở bài tiếp theo, chúng ta sẽ đi vào quản lý biến và môi trường trong Bash: biến local vs export, .env, getopts, $IFS và các biến đặc biệt như $?, $$, $!.

Tài liệu tham khảo

GNU Bash Manual — Shell Functions — Tài liệu chính thức về function, positional parameters và exit status.
GNU Bash Manual — Bourne Shell Builtins — Tham khảo return, shift và các builtin liên quan.
GNU Bash Manual — Bash Variables — Tham khảo ${BASH_SOURCE[@]} và các biến Bash đặc biệt.
curl Documentation — Tham khảo --fail, --silent, --show-error, --max-time dùng trong ví dụ healthcheck.

Text Processing trong Bash: grep, awk, sed cho DevOps

Mon, 08 Jun 2026 00:00:00 +0000

Text processing trong Bash cho DevOps

Ở bài trước chúng ta đã xử lý file: đọc, ghi, redirect, tee, find và xargs. Nhưng file text chỉ thật sự hữu ích khi bạn biết lọc, trích xuất và biến đổi dữ liệu trong đó.

Trong DevOps, grep, awk và sed xuất hiện ở khắp nơi: lọc log lỗi, lấy status code từ access log, đếm IP truy cập nhiều nhất, thay đổi config trước khi deploy, hoặc tạo report nhanh từ output của command. Bài này đi qua ba công cụ theo hướng thực dụng, có ví dụ gần với vận hành hằng ngày.

grep: tìm dòng khớp pattern

grep đọc input và in ra những dòng khớp pattern. Đây thường là bước đầu tiên khi bạn cần tìm nhanh thông tin trong log hoặc config.

1
2


grep "ERROR" app.log
grep "server_name" /etc/nginx/conf.d/*.conf

Một số option hay dùng:

1
2
3
4
5
6


grep -n "ERROR" app.log # in kèm line number
grep -i "timeout" app.log # ignore case
grep -v "healthcheck" app.log # loại trừ dòng khớp
grep -r "DATABASE_URL" ./config # tìm đệ quy trong thư mục
grep -E "ERROR|WARN" app.log # extended regex
grep -F "[literal]" app.log # fixed string, không coi là regex

Theo GNU grep, -E dùng extended regular expression, còn -F dùng fixed strings. Khi pattern là chuỗi literal đơn giản, grep -F giúp tránh lỗi do ký tự như ., [, * bị hiểu là regex.

grep context: xem dòng trước và sau lỗi

Khi debug log, chỉ một dòng lỗi thường chưa đủ. GNU grep hỗ trợ context:

1
2
3


grep -A 3 "ERROR" app.log # 3 dòng sau match
grep -B 3 "ERROR" app.log # 3 dòng trước match
grep -C 3 "ERROR" app.log # 3 dòng trước và sau match

Ví dụ xem lỗi deploy kèm ngữ cảnh:

1

grep -n -C 5 "deploy failed" ./logs/deploy.log

Khi có nhiều nhóm match cách xa nhau, grep mặc định chèn dòng -- để phân tách context group. Điều này hữu ích khi đọc terminal, nhưng nếu output đưa vào script khác, bạn nên nhớ dòng separator này có thể xuất hiện.

grep trong pipeline DevOps

Ví dụ lọc log ứng dụng, bỏ healthcheck và chỉ xem lỗi nghiêm trọng:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


#!/usr/bin/env bash
set -euo pipefail

LOG_FILE="${1:-./logs/app.log}"

if [[ ! -r "${LOG_FILE}" ]]; then
 echo "ERROR: Cannot read log file: ${LOG_FILE}"
 exit 1
fi

grep -E "ERROR|FATAL" "${LOG_FILE}" | grep -v "healthcheck" || true

Vì grep trả exit code 1 khi không có match, pipeline có thể làm script dừng nếu đang dùng set -e. Trong tình huống “không có lỗi” là bình thường, thêm || true ở cuối pipeline là chấp nhận được. Với pipeline quan trọng hơn, hãy xử lý exit code rõ ràng bằng if grep ...; then ... fi.

awk: xử lý theo dòng và theo cột

awk đọc input theo record, mặc định mỗi dòng là một record. Mỗi dòng được tách thành field: $1, $2, $3… Toàn bộ dòng là $0.

1
2


awk '{ print $1 }' access.log
awk '{ print $1, $9 }' access.log

Một số biến built-in quan trọng:

NR: số record đã đọc từ đầu input.
NF: số field của record hiện tại.
$0: toàn bộ dòng hiện tại.
$1, $2, …: field thứ nhất, thứ hai, …
FS: field separator input.
OFS: output field separator.

Ví dụ in số dòng và số field:

1

awk '{ print NR, NF, $0 }' app.log

Theo GNU awk manual, NR tăng mỗi khi awk đọc record mới, còn NF là số field của record hiện tại. Đây là hai biến rất hữu ích khi cần validate dữ liệu text nhanh.

awk BEGIN, END và điều kiện

BEGIN chạy trước khi đọc input. END chạy sau khi đọc hết input. Phần giữa là rule áp dụng cho từng dòng.

1

awk 'BEGIN { print "status,count" } { count[$9]++ } END { for (code in count) print code "," count[code] }' access.log

Ví dụ dễ đọc hơn, đếm HTTP status code từ Nginx access log dạng phổ biến:

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


awk '
 BEGIN {
 print "status,count"
 }
 {
 status[$9]++
 }
 END {
 for (code in status) {
 print code "," status[code]
 }
 }
' access.log

Trong access log phổ biến, $1 thường là IP client, $7 là path và $9 là HTTP status. Tuy nhiên format log có thể khác theo cấu hình Nginx/Apache, nên hãy kiểm tra vài dòng mẫu trước khi hardcode vị trí field.

awk với delimiter tùy chỉnh

Mặc định awk tách field theo whitespace. Với file dạng key-value hoặc CSV đơn giản, dùng -F để chọn delimiter.

1
2


awk -F= '{ print $1, $2 }' app.env
awk -F: '{ print $1, $7 }' /etc/passwd

Ví dụ đọc file .env và bỏ comment/dòng rỗng:

1
2
3
4
5
6
7


awk -F= '
 /^[[:space:]]*#/ { next }
 NF < 2 { next }
 {
 print "key=" $1
 }
' .env

Với CSV phức tạp có quote, comma bên trong field hoặc escape, awk -F, không đủ an toàn. Khi đó nên dùng parser CSV đúng nghĩa bằng Python, Go hoặc công cụ chuyên dụng.

sed: thay thế và chỉnh text theo dòng

sed là stream editor: đọc input, áp dụng script, rồi ghi output. Lệnh nổi tiếng nhất là substitute:

1
2


sed 's/old/new/' file.txt # thay match đầu tiên mỗi dòng
sed 's/old/new/g' file.txt # thay tất cả match trên mỗi dòng

Theo GNU sed manual, cú pháp cơ bản là s/regexp/replacement/flags. Flag g thay tất cả match trong dòng thay vì chỉ match đầu tiên.

Ví dụ đổi endpoint trong file config và ghi ra file mới:

1

sed 's|http://localhost:8080|https://api.example.com|g' app.conf > app.conf.new

Ở đây dùng delimiter | thay vì / để tránh phải escape nhiều dấu / trong URL.

sed theo address và in-place edit

Bạn có thể giới hạn sed chỉ tác động trên dòng khớp pattern hoặc range.

1
2


sed '/^LOG_LEVEL=/s/=.*$/=debug/' app.env
sed '10,20s/enabled=false/enabled=true/' feature.conf

GNU sed hỗ trợ -i để chỉnh file tại chỗ. Nếu truyền suffix, sed tạo backup trước khi rename file tạm thành file gốc:

1

sed -i.bak 's/^LOG_LEVEL=.*/LOG_LEVEL=info/' app.env

Cẩn thận với sed -i:

Luôn test không -i trước để xem output.
Dùng suffix như .bak khi chỉnh file quan trọng.
Khác biệt cú pháp sed -i giữa GNU sed và BSD/macOS sed có thể làm script kém portable.

Thực hành DevOps: parse Nginx log

Giả sử access log có format phổ biến:

1
2
3


203.0.113.10 - - [08/Jun/2026:10:12:01 +0700] "GET /api/health HTTP/1.1" 200 12
198.51.100.23 - - [08/Jun/2026:10:12:02 +0700] "POST /api/login HTTP/1.1" 401 64
203.0.113.10 - - [08/Jun/2026:10:12:03 +0700] "GET /api/users HTTP/1.1" 200 532

Lọc lỗi 4xx/5xx bằng awk:

1

awk '$9 ~ /^[45][0-9][0-9]$/ { print $1, $7, $9 }' access.log

Đếm top IP truy cập nhiều nhất:

1
2
3


awk '{ count[$1]++ } END { for (ip in count) print count[ip], ip }' access.log \
 | sort -nr \
 | head -n 10

Đếm status code:

1
2


awk '{ status[$9]++ } END { for (code in status) print code, status[code] }' access.log \
 | sort -n

Nếu bạn muốn bỏ các request healthcheck khỏi thống kê:

1
2
3


grep -v '"GET /api/health ' access.log \
 | awk '{ status[$9]++ } END { for (code in status) print code, status[code] }' \
 | sort -n

Thực hành DevOps: đổi config trước khi deploy

Ví dụ script cập nhật LOG_LEVEL và FEATURE_FLAG trong file .env, có backup trước khi sửa.

 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


#!/usr/bin/env bash
set -euo pipefail

ENV_FILE="${1:-./app.env}"
LOG_LEVEL="${LOG_LEVEL:-info}"
FEATURE_FLAG="${FEATURE_FLAG:-false}"

if [[ ! -f "${ENV_FILE}" ]]; then
 echo "ERROR: env file not found: ${ENV_FILE}"
 exit 1
fi

if [[ ! -w "${ENV_FILE}" ]]; then
 echo "ERROR: env file is not writable: ${ENV_FILE}"
 exit 1
fi

cp -- "${ENV_FILE}" "${ENV_FILE}.bak.$(date +%Y%m%d%H%M%S)"

sed -i.bak \
 -e "s/^LOG_LEVEL=.*/LOG_LEVEL=${LOG_LEVEL}/" \
 -e "s/^FEATURE_FLAG=.*/FEATURE_FLAG=${FEATURE_FLAG}/" \
 "${ENV_FILE}"

if ! grep -q '^LOG_LEVEL=' "${ENV_FILE}"; then
 echo "LOG_LEVEL=${LOG_LEVEL}" >> "${ENV_FILE}"
fi

if ! grep -q '^FEATURE_FLAG=' "${ENV_FILE}"; then
 echo "FEATURE_FLAG=${FEATURE_FLAG}" >> "${ENV_FILE}"
fi

Script này minh họa cách phối hợp công cụ:

cp tạo backup rõ ràng trước khi chỉnh.
sed thay giá trị nếu key đã tồn tại.
grep -q kiểm tra key có tồn tại chưa.
>> append key còn thiếu.

Lưu ý: không đưa secret thật vào ví dụ hoặc commit. Với secret, ưu tiên biến môi trường, secret manager hoặc CI/CD secret store.

Thực hành DevOps: report lỗi từ log

Ví dụ tạo report ngắn gồm tổng số lỗi và top endpoint trả 5xx:

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


#!/usr/bin/env bash
set -euo pipefail

ACCESS_LOG="${1:-./access.log}"
REPORT_FILE="${2:-./error-report.txt}"

if [[ ! -r "${ACCESS_LOG}" ]]; then
 echo "ERROR: Cannot read access log: ${ACCESS_LOG}"
 exit 1
fi

{
 echo "Error report generated at $(date -Is)"
 echo
 echo "Total 5xx responses:"
 awk '$9 ~ /^5[0-9][0-9]$/ { total++ } END { print total + 0 }' "${ACCESS_LOG}"
 echo
 echo "Top 5 endpoints with 5xx:"
 awk '$9 ~ /^5[0-9][0-9]$/ { count[$7]++ } END { for (path in count) print count[path], path }' "${ACCESS_LOG}" \
 | sort -nr \
 | head -n 5
} > "${REPORT_FILE}"

echo "Wrote ${REPORT_FILE}"

Đây là dạng script rất hữu ích để chạy từ cron hoặc CI job sau test load, miễn là bạn hiểu rõ format log đầu vào.

Sai sót thường gặp

Dùng regex khi chỉ cần literal: Nếu pattern có ký tự đặc biệt như [, ., *, cân nhắc grep -F.
Quên grep exit code: Không có match là exit code 1, không nhất thiết là lỗi nghiệp vụ.
Hardcode field log mà không kiểm tra format: $9 là status code với format phổ biến, nhưng không phải mọi log đều như vậy.
Dùng awk -F, cho CSV phức tạp: CSV có quote/comma bên trong field cần parser đúng nghĩa.
Chạy sed -i ngay trên file quan trọng: Test output trước, dùng backup suffix hoặc copy file trước khi sửa.
Không quote biến trong script: Khi truyền file path vào grep, awk, sed, luôn quote "${FILE}".

Ghi chú triển khai

Khi áp dụng vào dự án của bạn, chọn công cụ theo mục tiêu:
- Tìm/lọc dòng → grep.
- Trích cột, tính tổng, đếm nhóm → awk.
- Thay thế text theo dòng/pattern → sed.
Best practices:
- Dùng grep -n khi debug để biết line number.
- Dùng grep -C khi cần context quanh lỗi.
- Dùng awk với BEGIN/END để tạo report có header/footer.
- Dùng delimiter khác trong sed khi xử lý URL/path, ví dụ s|old|new|g.
- Với chỉnh sửa config, backup trước và verify sau bằng grep hoặc test config của service.
Troubleshooting:
- Pipeline dừng vì grep không match? → Xử lý exit code bằng if grep ... hoặc || true khi hợp lý.
- awk in sai cột? → In thử awk '{ print NR, NF, $0 }' để kiểm tra field.
- sed không thay gì? → Kiểm tra pattern có anchor đúng không, delimiter có cần escape không.

Lời kết

grep, awk và sed là bộ ba nền tảng để biến Bash thành công cụ xử lý log/config cực nhanh. grep giúp tìm đúng dòng, awk giúp phân tích theo cột và tổng hợp số liệu, còn sed giúp chỉnh sửa text có kiểm soát. Khi kết hợp với kỹ năng xử lý file ở bài trước, bạn đã có thể tạo nhiều script DevOps nhỏ nhưng rất hữu ích.

Ở bài tiếp theo, chúng ta sẽ đi vào function trong Bash: tách logic thành hàm, truyền tham số, dùng local, xử lý return code và xây dựng thư viện logging nhỏ để tái sử dụng.

Tài liệu tham khảo

GNU Grep Manual — Tài liệu chính thức về grep, regex, -E, -F, -n, -A, -B, -C.
GNU Awk Manual — Tài liệu chính thức về field, NR, NF, BEGIN, END và awk program.
GNU Sed Manual — Tài liệu chính thức về s/regexp/replacement/flags, address và -i.
GNU Coreutils Manual — sort — Tham khảo thêm cho các pipeline thống kê với sort.

Xử lý file trong Bash: đọc, ghi và quản lý an toàn cho DevOps

Mon, 08 Jun 2026 00:00:00 +0000

Xử lý file trong Bash cho DevOps

Ở bài trước chúng ta đã dùng vòng lặp để xử lý nhiều server, nhiều dòng log và retry các lệnh có thể lỗi tạm thời. Bước tiếp theo rất tự nhiên là xử lý file: đọc log, ghi report, append output, tạo file cấu hình, tìm file cũ và truyền danh sách file cho lệnh khác.

Trong DevOps, phần lớn automation nhỏ đều chạm tới file: log của service, file .env, config Nginx, manifest YAML, danh sách host, artifact build hoặc backup. Bài này tập trung vào các pattern Bash thực dụng: cat, head, tail, redirect, here-doc, tee, đọc từng dòng, kiểm tra file, find, xargs và hai ví dụ thực hành.

Đọc nhanh nội dung file với cat, tac, head, tail

cat đọc một hoặc nhiều file rồi ghi ra standard output. Theo GNU Coreutils, nếu không truyền file, cat đọc từ standard input.

1
2


cat /etc/os-release
cat app.log deploy.log

Một vài lệnh hay dùng khi xem log hoặc config:

1
2
3
4
5
6


head -n 20 app.log # 20 dòng đầu
head -c 1K app.log # 1 KiB đầu tiên
tail -n 50 app.log # 50 dòng cuối
tail -f app.log # theo dõi log đang tăng
tail -F app.log # phù hợp hơn khi log có thể bị rotate
tac app.log | head -n 20 # xem 20 dòng cuối theo thứ tự đảo ngược

tail -f theo dõi file descriptor hiện tại. Khi log bị rotate, file cũ có thể bị rename và app mở file mới. GNU tail -F tương đương --follow=name --retry, thường tiện hơn cho log vận hành vì nó cố mở lại file theo tên.

Redirect output: ghi mới, append và tách stdout/stderr

Bash xử lý redirect từ trái sang phải. Một số dạng phổ biến:

1
2
3
4
5
6


command > output.log # ghi stdout, overwrite file
command >> output.log # append stdout
command 2> error.log # ghi stderr
command > output.log 2>&1 # ghi stdout + stderr vào cùng file
command &> output.log # Bash shorthand cho stdout + stderr
command &>> output.log # append stdout + stderr

Ví dụ ghi log cho một bước deploy:

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


#!/usr/bin/env bash
set -euo pipefail

LOG_DIR="./logs"
LOG_FILE="${LOG_DIR}/deploy.log"
mkdir -p "${LOG_DIR}"

{
 echo "===== Deploy started at $(date -Is) ====="
 echo "Running migration..."
 ./migrate.sh
 echo "Restarting service..."
 ./restart-service.sh
 echo "===== Deploy finished at $(date -Is) ====="
} >> "${LOG_FILE}" 2>&1

Dùng block { ...; } >> "${LOG_FILE}" 2>&1 giúp gom log của nhiều lệnh vào cùng một file mà không phải lặp redirect ở từng dòng.

Lưu ý: > sẽ ghi đè file. Nếu muốn giảm rủi ro overwrite nhầm trong shell hiện tại, có thể bật set -o noclobber; khi cần ghi đè có chủ đích, dùng >| file.

Here-doc: tạo file cấu hình từ script

Here-doc (<<EOF) đưa nhiều dòng text vào stdin của một lệnh. Nó rất hữu ích khi cần tạo config mẫu, unit file, hoặc payload JSON nhỏ.

1
2
3
4
5


cat > app.env <<EOF
APP_ENV=production
APP_PORT=8080
LOG_LEVEL=info
EOF

Nếu delimiter không được quote, Bash sẽ expand biến bên trong here-doc:

1
2
3
4
5


APP_PORT="8080"

cat > app.env <<EOF
APP_PORT=${APP_PORT}
EOF

Nếu muốn giữ nguyên $, backtick hoặc ${VAR} trong file output, quote delimiter:

1
2
3
4


cat > template.env <<'EOF'
APP_PORT=${APP_PORT}
DATABASE_URL=${DATABASE_URL}
EOF

Theo Bash Manual, khi dùng <<-EOF, Bash sẽ bỏ các tab ở đầu dòng trong here-doc. Cách này giúp script dễ đọc hơn, nhưng chỉ strip tab, không strip space.

tee: vừa hiển thị vừa lưu file

Redirect > sẽ đưa output vào file và thường không còn hiển thị trên terminal. tee copy standard input ra standard output và đồng thời ghi vào file.

1
2


./healthcheck.sh | tee healthcheck.log
./healthcheck.sh | tee -a healthcheck.log

Theo GNU Coreutils, tee sẽ overwrite file nếu không dùng -a; tee -a append vào file.

Ví dụ vừa xem log build vừa lưu lại artifact log:

1
2
3
4
5
6
7


#!/usr/bin/env bash
set -euo pipefail

LOG_DIR="./logs"
mkdir -p "${LOG_DIR}"

./build.sh 2>&1 | tee -a "${LOG_DIR}/build.log"

Ở đây 2>&1 đặt trước pipe để stderr cũng đi qua tee. Nếu chỉ viết ./build.sh | tee ..., nhiều lỗi trên stderr vẫn hiện ra terminal nhưng không được lưu vào file log.

Đọc file theo từng dòng

Pattern an toàn khi đọc file line-by-line là while IFS= read -r LINE; do ...; done < file.

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


#!/usr/bin/env bash
set -euo pipefail

SERVER_FILE="${1:-servers.txt}"

if [[ ! -r "${SERVER_FILE}" ]]; then
 echo "ERROR: Cannot read ${SERVER_FILE}"
 exit 1
fi

while IFS= read -r SERVER; do
 [[ -n "${SERVER}" ]] || continue
 [[ "${SERVER}" != \#* ]] || continue

 echo "Checking ${SERVER}"
done < "${SERVER_FILE}"

Giải thích nhanh:

IFS= giữ nguyên khoảng trắng đầu/cuối dòng.
read -r không coi \ là escape character.
done < "${SERVER_FILE}" tránh pattern cat file | while ..., vốn có thể làm vòng lặp chạy trong subshell ở một số shell và làm mất biến sau vòng lặp.
Quote "${SERVER_FILE}" để đường dẫn có khoảng trắng vẫn hoạt động.

Kiểm tra file, thư mục và quyền trước khi thao tác

Trước khi đọc/ghi/xóa file trong automation, hãy kiểm tra điều kiện rõ ràng. Một số test hay dùng trong [[ ... ]]:

1
2
3
4
5
6
7


[[ -e "${PATH_NAME}" ]] # tồn tại
[[ -f "${PATH_NAME}" ]] # regular file
[[ -d "${PATH_NAME}" ]] # directory
[[ -r "${PATH_NAME}" ]] # readable
[[ -w "${PATH_NAME}" ]] # writable
[[ -x "${PATH_NAME}" ]] # executable/searchable
[[ -s "${PATH_NAME}" ]] # tồn tại và size > 0

Ví dụ backup config chỉ khi file tồn tại và đọc được:

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


#!/usr/bin/env bash
set -euo pipefail

CONFIG_FILE="${1:-/etc/example/app.conf}"
BACKUP_DIR="${BACKUP_DIR:-./backup}"

if [[ ! -f "${CONFIG_FILE}" ]]; then
 echo "ERROR: Not a regular file: ${CONFIG_FILE}"
 exit 1
fi

if [[ ! -r "${CONFIG_FILE}" ]]; then
 echo "ERROR: Cannot read: ${CONFIG_FILE}"
 exit 1
fi

mkdir -p "${BACKUP_DIR}"
cp -- "${CONFIG_FILE}" "${BACKUP_DIR}/$(basename "${CONFIG_FILE}").$(date +%Y%m%d%H%M%S).bak"

Dấu -- sau cp giúp kết thúc danh sách option. Đây là thói quen tốt khi biến có thể bắt đầu bằng -.

find: tìm file theo điều kiện

find phù hợp khi cần tìm file theo tên, loại, thời gian, kích thước hoặc thư mục con.

1
2
3


find /var/log -type f -name "*.log"
find /var/log -type f -name "*.log" -mtime +7
find ./backup -type f -name "*.bak" -size +100M

Một số điều kiện thường gặp:

-type f: chỉ file thường.
-type d: chỉ thư mục.
-name "*.log": match theo tên.
-mtime +7: file có modification time hơn 7 ngày.
-size +100M: file lớn hơn 100 MiB theo cú pháp GNU find.
-maxdepth 1: không đi quá sâu khỏi thư mục hiện tại.

Ví dụ xem log cũ hơn 14 ngày nhưng chưa xóa:

1

find /var/log/my-app -type f -name "*.log" -mtime +14 -print

Khi viết script cleanup, nên chạy -print trước để review danh sách, sau đó mới đổi sang hành động xóa hoặc archive.

xargs: truyền danh sách file cho lệnh khác

xargs đọc dữ liệu từ stdin, gom thành argument và chạy command. Nó hữu ích khi danh sách file dài hoặc cần truyền kết quả của find cho lệnh khác.

Không nên dùng dạng mặc định cho file name tùy ý:

1

find ./logs -type f -name "*.log" | xargs gzip

Mặc định xargs tách input theo whitespace, nên tên file có space, tab hoặc newline có thể bị hiểu sai. GNU findutils khuyến nghị dùng find -print0 kết hợp xargs -0 để phân tách bằng NUL character:

1

find ./logs -type f -name "*.log" -print0 | xargs -0 gzip

Nếu dùng GNU xargs, thêm -r để không chạy command khi input rỗng:

1

find ./logs -type f -name "*.log" -print0 | xargs -r -0 gzip

Một lựa chọn khác là dùng find -exec ... {} +, portable và tránh pipe:

1

find ./logs -type f -name "*.log" -exec gzip -- {} +

Thực hành DevOps: rotate log thủ công

Trong production, log rotation thường nên giao cho logrotate hoặc logging stack. Nhưng hiểu một script rotate nhỏ giúp bạn nắm rõ các thao tác file: kiểm tra size, rename, tạo file mới, compress và cleanup.

 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


#!/usr/bin/env bash
set -euo pipefail

LOG_FILE="${1:-./logs/app.log}"
MAX_SIZE_MB="${MAX_SIZE_MB:-100}"
KEEP_DAYS="${KEEP_DAYS:-14}"

if [[ ! -f "${LOG_FILE}" ]]; then
 echo "ERROR: Log file not found: ${LOG_FILE}"
 exit 1
fi

LOG_DIR="$(dirname "${LOG_FILE}")"
LOG_NAME="$(basename "${LOG_FILE}")"
SIZE_MB="$(du -m "${LOG_FILE}" | awk '{print $1}')"

if (( SIZE_MB < MAX_SIZE_MB )); then
 echo "OK: ${LOG_FILE} is ${SIZE_MB}MB, no rotation needed"
 exit 0
fi

TIMESTAMP="$(date +%Y%m%d%H%M%S)"
ROTATED_FILE="${LOG_DIR}/${LOG_NAME}.${TIMESTAMP}"

mv -- "${LOG_FILE}" "${ROTATED_FILE}"
: > "${LOG_FILE}"
gzip -- "${ROTATED_FILE}"

find "${LOG_DIR}" -type f -name "${LOG_NAME}.*.gz" -mtime +"${KEEP_DAYS}" -print -delete

echo "Rotated ${LOG_FILE} -> ${ROTATED_FILE}.gz"

Một vài lưu ý:

: > "${LOG_FILE}" tạo file rỗng mới bằng shell builtin : và redirect output rỗng.
Script này phù hợp để học hoặc dùng cho service nhỏ. Với app đang ghi log liên tục, rotate thủ công có thể cần signal/reopen log tùy ứng dụng.
Dùng find ... -print -delete để vừa thấy file nào bị xóa vừa cleanup.

Thực hành DevOps: backup config trước khi deploy

Trước khi deploy, một bước an toàn là backup các file config quan trọng vào thư mục riêng theo timestamp.

 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


#!/usr/bin/env bash
set -euo pipefail

BACKUP_ROOT="${BACKUP_ROOT:-./config-backups}"
TIMESTAMP="$(date +%Y%m%d%H%M%S)"
BACKUP_DIR="${BACKUP_ROOT}/${TIMESTAMP}"

CONFIG_FILES=(
 "/etc/example/app.conf"
 "/etc/example/worker.conf"
 "/etc/nginx/conf.d/example.conf"
)

mkdir -p "${BACKUP_DIR}"

for CONFIG_FILE in "${CONFIG_FILES[@]}"; do
 if [[ ! -r "${CONFIG_FILE}" ]]; then
 echo "WARN: Skip unreadable config: ${CONFIG_FILE}"
 continue
 fi

 TARGET="${BACKUP_DIR}${CONFIG_FILE}"
 mkdir -p "$(dirname "${TARGET}")"
 cp -p -- "${CONFIG_FILE}" "${TARGET}"
 echo "Backed up ${CONFIG_FILE}"
done

find "${BACKUP_ROOT}" -mindepth 1 -maxdepth 1 -type d -mtime +30 -print -exec rm -rf -- {} +

cp -p giữ lại mode, ownership và timestamp nếu quyền hệ thống cho phép. TARGET="${BACKUP_DIR}${CONFIG_FILE}" giữ nguyên cấu trúc đường dẫn gốc bên trong thư mục backup, giúp restore dễ hơn.

Sai sót thường gặp

Dùng > khi muốn append: > overwrite file; dùng >> hoặc tee -a nếu muốn ghi nối tiếp.
Đặt sai thứ tự redirect: command 2>&1 >file khác command >file 2>&1. Bash xử lý redirect từ trái sang phải.
Quên quote đường dẫn: Luôn dùng "${FILE}", đặc biệt với path đọc từ input.
Dùng xargs mặc định với file name tùy ý: Ưu tiên find -print0 | xargs -0 hoặc find -exec ... {} +.
Xóa file ngay khi chưa review: Với cleanup, chạy find ... -print trước, sau đó mới thêm -delete hoặc rm.
Tạo here-doc bị expand ngoài ý muốn: Quote delimiter (<<'EOF') nếu muốn giữ nguyên ${VAR} trong file output.

Ghi chú triển khai

Khi áp dụng vào dự án của bạn, hãy phân biệt rõ thao tác:
- Xem nhanh file/log → cat, head, tail, tail -F.
- Ghi log script → redirect block hoặc tee -a.
- Tạo config nhiều dòng → here-doc, quote delimiter nếu cần template literal.
- Tìm/xử lý nhiều file → find, find -exec ... {} +, hoặc find -print0 | xargs -0.
Best practices:
- Bắt đầu script bằng set -euo pipefail khi phù hợp.
- Kiểm tra -r, -w, -f, -d trước khi thao tác nguy hiểm.
- Dùng -- trước biến path trong các lệnh như cp, mv, rm, gzip.
- Với cleanup, log lại file bị tác động bằng -print hoặc echo.
Troubleshooting:
- File log không ghi đủ stderr? → Đảm bảo có 2>&1 trước pipe hoặc redirect đúng thứ tự.
- tail -f không thấy log mới sau rotate? → Thử tail -F.
- Script lỗi với tên file có space? → Kiểm tra quote biến và cách dùng xargs.

Lời kết

Xử lý file là kỹ năng cốt lõi khi viết Bash cho DevOps. Khi nắm chắc redirect, here-doc, tee, đọc từng dòng, kiểm tra quyền, find và xargs, bạn có thể viết các script nhỏ nhưng an toàn hơn cho log, config, backup và cleanup.

Ở bài tiếp theo, chúng ta sẽ đi vào text processing với grep, awk và sed: lọc log, trích cột, thay đổi config và đếm dữ liệu từ file text hiệu quả hơn.

Tài liệu tham khảo

GNU Bash Manual — Redirections — Tài liệu chính thức về redirect, file descriptor và here-doc.
GNU Coreutils Manual — cat — Cách cat đọc và ghi file/stdin/stdout.
GNU Coreutils Manual — head — Tài liệu chính thức về head -n, head -c.
GNU Coreutils Manual — tail — Tài liệu chính thức về tail -f, tail -F, --follow=name.
GNU Coreutils Manual — tee — Tài liệu chính thức về tee và tee -a.
GNU Findutils Manual — Tài liệu chính thức về find, xargs, -print0 và xargs -0.

Vòng lặp trong Bash: for, while, until cho tự động hóa DevOps

Tue, 02 Jun 2026 00:00:00 +0000

Vòng lặp trong Bash cho DevOps

Ở bài trước chúng ta đã dùng điều kiện để script biết rẽ nhánh theo trạng thái hệ thống. Nhưng trong công việc DevOps, rất nhiều tác vụ không chỉ chạy một lần: kiểm tra nhiều server, đọc từng dòng log, retry một lệnh có thể lỗi tạm thời, hoặc xử lý hàng loạt file cấu hình.

Vòng lặp trong Bash giúp bạn lặp lại một khối lệnh theo danh sách, theo điều kiện, hoặc cho đến khi một điều kiện được thoả mãn. Bài này đi qua for, while, until, break, continue và các ví dụ thực hành gần với vận hành hằng ngày.

for in — lặp qua danh sách

Theo GNU Bash Manual, dạng for name in words; do ...; done sẽ mở rộng danh sách words, rồi chạy khối lệnh một lần cho từng phần tử. Ở mỗi lượt lặp, biến name nhận giá trị hiện tại.

Cú pháp phổ biến:

1
2
3


for item in item1 item2 item3; do
 echo "Đang xử lý: ${item}"
done

Ví dụ — kiểm tra nhanh nhiều host bằng ping:

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


#!/usr/bin/env bash
set -euo pipefail

HOSTS=("web-01" "web-02" "db-01")

for HOST in "${HOSTS[@]}"; do
 echo "Checking ${HOST}..."
 if ping -c 1 -W 2 "${HOST}" >/dev/null 2>&1; then
 echo "OK: ${HOST} reachable"
 else
 echo "WARN: ${HOST} unreachable"
 fi
done

Điểm quan trọng là dùng "${HOSTS[@]}" thay vì ${HOSTS[@]} trần. Cách quote này giữ nguyên từng phần tử array, kể cả khi giá trị có khoảng trắng.

for kiểu C — lặp theo bộ đếm

Bash cũng hỗ trợ dạng for (( expr1; expr2; expr3 )), tương tự ngôn ngữ C. Dạng này phù hợp khi bạn cần bộ đếm rõ ràng: chạy đúng N lần, đánh số retry, hoặc tạo tên file theo index.

1
2
3
4
5
6


#!/usr/bin/env bash
set -euo pipefail

for (( i = 1; i <= 5; i++ )); do
 echo "Attempt ${i}/5"
done

Ví dụ — tạo 3 file log giả lập cho môi trường test:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


#!/usr/bin/env bash
set -euo pipefail

LOG_DIR="/tmp/bash-loop-demo"
mkdir -p "${LOG_DIR}"

for (( i = 1; i <= 3; i++ )); do
 LOG_FILE="${LOG_DIR}/app-${i}.log"
 echo "$(date -Is) demo log ${i}" > "${LOG_FILE}"
 echo "Created ${LOG_FILE}"
done

Trong (( ... )), bạn có thể dùng toán tử số học quen thuộc như <=, ++, +=. Tên biến không bắt buộc có $ ở phía trước.

while — lặp khi điều kiện còn đúng

while chạy khối lệnh miễn là lệnh kiểm tra trả exit code 0. Đây là lựa chọn tốt khi số lần lặp chưa biết trước: đọc file đến hết, chờ service sẵn sàng, hoặc polling một endpoint.

Cú pháp:

1
2
3


while <lệnh_kiểm_tra>; do
 <lệnh_cần_lặp>
done

Ví dụ — đọc file log theo từng dòng và lọc dòng lỗi:

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


#!/usr/bin/env bash
set -euo pipefail

LOG_FILE="${1:-/var/log/app/app.log}"

if [[ ! -r "${LOG_FILE}" ]]; then
 echo "ERROR: Không đọc được log file: ${LOG_FILE}"
 exit 1
fi

while IFS= read -r LINE; do
 if [[ "${LINE}" == *"ERROR"* ]]; then
 echo "Found error: ${LINE}"
 fi
done < "${LOG_FILE}"

IFS= read -r LINE là pattern nên dùng khi đọc từng dòng:

IFS= tránh việc Bash tự cắt khoảng trắng đầu/cuối dòng.
read -r giữ nguyên dấu \, không coi nó là ký tự escape.
done < "${LOG_FILE}" đưa file vào stdin của vòng lặp, tránh cần gọi cat không cần thiết.

until — lặp cho đến khi điều kiện đúng

until gần giống while, nhưng logic ngược lại: nó chạy khối lệnh miễn là lệnh kiểm tra trả non-zero, và dừng khi điều kiện trả 0.

Cú pháp:

1
2
3


until <lệnh_kiểm_tra>; do
 <lệnh_cần_lặp>
done

Ví dụ — chờ một endpoint healthcheck sẵn sàng:

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


#!/usr/bin/env bash
set -euo pipefail

HEALTH_URL="${1:-http://localhost:8080/health}"
MAX_WAIT_SECONDS="30"
WAITED="0"

until curl -fsS "${HEALTH_URL}" >/dev/null; do
 if (( WAITED >= MAX_WAIT_SECONDS )); then
 echo "ERROR: Service is not healthy after ${MAX_WAIT_SECONDS}s"
 exit 1
 fi

 echo "Waiting for service healthcheck... (${WAITED}s)"
 sleep 2
 WAITED=$(( WAITED + 2 ))
done

echo "OK: Service is healthy"

until đọc rất tự nhiên trong các tình huống “lặp cho tới khi thành công”. Nếu team của bạn thấy while ! command; do ... dễ hiểu hơn, dùng while cũng hoàn toàn ổn.

break và continue

break thoát khỏi vòng lặp hiện tại. continue bỏ qua phần còn lại của lượt lặp hiện tại và chuyển sang lượt tiếp theo. Theo GNU Bash Manual, cả hai đều dùng được trong for, while, until và select.

Ví dụ — bỏ qua file không phải .log, dừng khi gặp log quá lớn:

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


#!/usr/bin/env bash
set -euo pipefail

for FILE in /var/log/*.log; do
 [[ -e "${FILE}" ]] || continue

 if [[ "${FILE}" != *.log ]]; then
 continue
 fi

 SIZE_MB="$(du -m "${FILE}" | awk '{print $1}')"

 if (( SIZE_MB > 1024 )); then
 echo "Stop: ${FILE} is larger than 1GB"
 break
 fi

 echo "Process ${FILE} (${SIZE_MB}MB)"
done

Dòng [[ -e "${FILE}" ]] || continue xử lý trường hợp glob /var/log/*.log không match file nào. Nếu không có file, Bash có thể giữ nguyên pattern thành chuỗi literal, nên cần kiểm tra tồn tại trước khi xử lý.

Thực hành DevOps: lặp qua danh sách server SSH

Ví dụ này đọc danh sách server từ file, SSH vào từng host và chạy một lệnh kiểm tra ngắn. Tên server, user và command đều dùng placeholder chung, không phụ thuộc môi trường thật.

Tạo file servers.txt:

1
2
3


webserver-01
webserver-02
worker-01

Tạo script check_servers.sh:

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


#!/usr/bin/env bash
set -euo pipefail

SERVER_FILE="${1:-servers.txt}"
SSH_USER="${SSH_USER:-deploy}"
REMOTE_COMMAND="uptime"

if [[ ! -r "${SERVER_FILE}" ]]; then
 echo "ERROR: Cannot read server file: ${SERVER_FILE}"
 exit 1
fi

while IFS= read -r SERVER; do
 [[ -n "${SERVER}" ]] || continue
 [[ "${SERVER}" != \#* ]] || continue

 echo "===== ${SERVER} ====="
 if ssh -o BatchMode=yes -o ConnectTimeout=5 "${SSH_USER}@${SERVER}" "${REMOTE_COMMAND}"; then
 echo "OK: ${SERVER}"
 else
 echo "WARN: command failed on ${SERVER}"
 fi
 echo
done < "${SERVER_FILE}"

Chạy thử:

1
2


chmod +x check_servers.sh
./check_servers.sh servers.txt

Một vài điểm đáng chú ý:

BatchMode=yes giúp SSH không hỏi password/passphrase trong automation. Nếu key chưa sẵn sàng, lệnh sẽ fail thay vì treo script.
ConnectTimeout=5 tránh chờ quá lâu khi một host không phản hồi.
Dòng rỗng và dòng comment bắt đầu bằng # được bỏ qua bằng continue.
Không hardcode user nhạy cảm: script lấy SSH_USER từ biến môi trường, mặc định là deploy.

Thực hành DevOps: retry lệnh thất bại

Trong vận hành, có những lỗi chỉ tạm thời: network chập chờn, registry chưa phản hồi, endpoint vừa restart xong. Vòng lặp giúp bạn retry có kiểm soát thay vì chạy lại thủ công.

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


#!/usr/bin/env bash
set -euo pipefail

URL="${1:-https://example.com/health}"
MAX_RETRIES="5"
SLEEP_SECONDS="3"

for (( attempt = 1; attempt <= MAX_RETRIES; attempt++ )); do
 echo "Attempt ${attempt}/${MAX_RETRIES}: ${URL}"

 if curl -fsS "${URL}" >/dev/null; then
 echo "OK: endpoint is reachable"
 exit 0
 fi

 if (( attempt == MAX_RETRIES )); then
 echo "ERROR: endpoint is still unreachable after ${MAX_RETRIES} attempts"
 exit 1
 fi

 sleep "${SLEEP_SECONDS}"
done

Ở đây, curl -f trả lỗi nếu HTTP status là 4xx/5xx, -sS giữ output gọn nhưng vẫn in lỗi khi thất bại. Exit code cuối cùng giúp pipeline biết nên tiếp tục hay dừng.

Sai sót thường gặp

Lặp qua output của ls: for FILE in $(ls) dễ vỡ khi tên file có khoảng trắng hoặc ký tự đặc biệt. Hãy dùng glob (for FILE in *.log) hoặc find ... -print0 cho case phức tạp.
Quên quote biến: Luôn dùng "${VAR}", đặc biệt khi biến là đường dẫn, hostname hoặc dữ liệu đọc từ file.
Dùng pipe làm mất biến ngoài vòng lặp: cat file | while read ... thường chạy vòng lặp trong subshell, thay đổi biến bên trong có thể không còn sau vòng lặp. Ưu tiên while ...; done < file.
Vòng lặp vô hạn không có điều kiện dừng: Khi dùng while true, luôn có break, timeout, hoặc giới hạn số lần thử.
Không xử lý dòng rỗng/comment: Khi đọc danh sách server hoặc config, nên bỏ qua dòng rỗng và comment để script bền hơn.

Ghi chú triển khai

Khi áp dụng vào dự án của bạn, hãy xác định rõ vòng lặp đang lặp theo danh sách hay theo trạng thái:
- Có danh sách sẵn → thường dùng for.
- Đọc từng dòng hoặc chờ điều kiện còn đúng → thường dùng while.
- Chờ cho đến khi lệnh thành công → cân nhắc until.
Best practices:
- Dùng IFS= read -r khi đọc file theo dòng.
- Quote array bằng "${ARRAY[@]}" khi lặp qua danh sách.
- Với retry, luôn có MAX_RETRIES và SLEEP_SECONDS rõ ràng.
- Với SSH automation, thêm timeout và tránh prompt tương tác.
Troubleshooting:
- Vòng lặp không chạy? → Kiểm tra danh sách đầu vào có rỗng không, glob có match file không.
- Script dừng giữa chừng khi dùng set -e? → Một lệnh trong vòng lặp trả non-zero nhưng chưa được bọc bằng if, ||, hoặc xử lý exit code.
- Đọc file bị mất khoảng trắng? → Đảm bảo dùng IFS= read -r LINE.

Lời kết

Vòng lặp là nền tảng để Bash chuyển từ các script chạy một lần sang automation thật sự: xử lý nhiều server, nhiều file, nhiều dòng log và nhiều lần retry. Khi kết hợp for, while, until với điều kiện ở bài trước, bạn đã có thể viết các script DevOps nhỏ nhưng rất hữu dụng cho kiểm tra, triển khai và vận hành hằng ngày.

Ở bài tiếp theo, chúng ta sẽ đi vào xử lý file trong Bash: đọc, ghi, redirect output, dùng tee, find, xargs và các pattern quản lý log/config an toàn hơn.

Tài liệu tham khảo

GNU Bash Manual — Looping Constructs — Tài liệu chính thức về for, while, until.
GNU Bash Manual — Bourne Shell Builtins — Tài liệu chính thức về break và continue.
GNU Bash Manual — Bash Builtin Commands — Tài liệu chính thức về read, mapfile và các builtin khác.
ShellCheck Wiki — SC2045 — Vì sao không nên lặp qua output của ls.

Điều kiện trong Bash: if, case và xử lý logic cho DevOps

Sun, 24 May 2026 00:00:00 +0000

Điều kiện trong Bash cho DevOps

Ở bài đầu tiên chúng ta đã viết script tuyến tính — chạy lần lượt từ trên xuống dưới. Trong thực tế vận hành, script thường phải ra quyết định: nếu service đã chạy thì bỏ qua, nếu disk vượt ngưỡng thì cảnh báo, nếu môi trường là production thì cần xác nhận trước khi deploy.

Điều kiện trong Bash chính là công cụ giúp script phản ứng linh hoạt với trạng thái hệ thống. Bài này sẽ đi qua if/elif/else, các toán tử so sánh, kiểm tra file và case…esac — kèm các ví dụ DevOps mà bạn có thể đem dùng ngay.

if / elif / else

Cú pháp cơ bản:

1
2
3
4
5
6
7


if [[ <điều_kiện> ]]; then
 <lệnh khi đúng>
elif [[ <điều_kiện_khác> ]]; then
 <lệnh khi điều kiện khác đúng>
else
 <lệnh khi tất cả đều sai>
fi

Một vài lưu ý:

Trong Bash hiện đại, ưu tiên dùng [[ ... ]] thay cho [ ... ]. [[ ]] là conditional expression của Bash, hỗ trợ thêm pattern matching và an toàn hơn với biến chứa khoảng trắng.
Mỗi if phải kết thúc bằng fi. Nếu quên, bash -n script.sh sẽ báo lỗi cú pháp ngay.
Khối lệnh thường thụt vào 2 khoảng trắng để dễ đọc.

Ví dụ rất nhỏ — kiểm tra script có được chạy với quyền root hay không:

1
2
3
4
5
6
7


#!/usr/bin/env bash

if [[ "${EUID}" -eq 0 ]]; then
 echo "Đang chạy với quyền root."
else
 echo "Không phải root, một số lệnh có thể bị từ chối."
fi

EUID là biến built-in của Bash, chứa effective user ID. User root luôn có EUID=0.

Toán tử so sánh số

Khi so sánh số nguyên, dùng các toán tử dạng -eq, -ne, -gt…

Toán tử	Ý nghĩa
`-eq`	bằng (`equal`)
`-ne`	khác (`not equal`)
`-gt`	lớn hơn (`greater`)
`-ge`	lớn hơn hoặc bằng
`-lt`	nhỏ hơn (`less`)
`-le`	nhỏ hơn hoặc bằng

Ví dụ kiểm tra dung lượng ổ đĩa /:

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


#!/usr/bin/env bash
set -euo pipefail

DISK_USAGE_PERCENT="$(df -P / | awk 'NR==2 {gsub("%", "", $5); print $5}')"

if [[ "${DISK_USAGE_PERCENT}" -ge 90 ]]; then
 echo "CRITICAL: Disk / đã dùng ${DISK_USAGE_PERCENT}%"
 exit 2
elif [[ "${DISK_USAGE_PERCENT}" -ge 80 ]]; then
 echo "WARNING: Disk / đã dùng ${DISK_USAGE_PERCENT}%"
 exit 1
else
 echo "OK: Disk / ở mức ${DISK_USAGE_PERCENT}%"
fi

Script trả exit code 0/1/2 tương ứng OK/WARN/CRIT. Đây là quy ước rất quen với các hệ giám sát như Nagios/Icinga và cũng dễ dùng trong cron hoặc pipeline CI/CD.

Mẹo: Bạn có thể dùng cú pháp (( ... )) cho số học, ví dụ if (( DISK_USAGE_PERCENT >= 80 )); then. Khi nằm trong (( )), bạn không cần $ trước tên biến và có thể dùng >=, <=, == quen thuộc.

Toán tử so sánh chuỗi

Với chuỗi, dùng các toán tử khác:

Toán tử	Ý nghĩa
`=` / `==`	bằng
`!=`	khác
`-z STR`	chuỗi rỗng
`-n STR`	chuỗi không rỗng
`<` / `>`	so sánh thứ tự (chỉ trong `[[ ]]`)

Ví dụ — gate môi trường trước khi deploy:

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


#!/usr/bin/env bash
set -euo pipefail

ENVIRONMENT="${1:-}"

if [[ -z "${ENVIRONMENT}" ]]; then
 echo "Usage: $0 <dev|staging|production>"
 exit 1
fi

if [[ "${ENVIRONMENT}" == "production" ]]; then
 read -r -p "Bạn chắc chắn deploy lên PRODUCTION? (yes/no): " CONFIRM
 if [[ "${CONFIRM}" != "yes" ]]; then
 echo "Đã huỷ deploy."
 exit 1
 fi
fi

echo "Bắt đầu deploy lên ${ENVIRONMENT}..."

Lưu ý quan trọng: luôn quote biến ("${ENVIRONMENT}"). Nếu để $ENVIRONMENT trần và biến rỗng, biểu thức [[ $ENVIRONMENT == "production" ]] vẫn chạy được, nhưng các script tương tự với [ ... ] có thể lỗi cú pháp khi biến rỗng.

Kiểm tra file và thư mục

Bash có sẵn các toán tử dùng để kiểm tra trạng thái file:

Toán tử	Ý nghĩa
`-e`	tồn tại (file hoặc thư mục)
`-f`	tồn tại và là file thường
`-d`	tồn tại và là thư mục
`-r`	đọc được
`-w`	ghi được
`-x`	thực thi được
`-s`	file tồn tại và có kích thước > 0
`-L`	là symbolic link

Ví dụ — script đảm bảo thư mục log tồn tại và file cấu hình hợp lệ trước khi chạy app:

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


#!/usr/bin/env bash
set -euo pipefail

APP_NAME="manager-blog"
CONFIG_FILE="/etc/${APP_NAME}/app.env"
LOG_DIR="/var/log/${APP_NAME}"

if [[ ! -f "${CONFIG_FILE}" ]]; then
 echo "ERROR: Không tìm thấy file cấu hình ${CONFIG_FILE}"
 exit 1
fi

if [[ ! -r "${CONFIG_FILE}" ]]; then
 echo "ERROR: Không có quyền đọc ${CONFIG_FILE}"
 exit 1
fi

if [[ ! -d "${LOG_DIR}" ]]; then
 echo "Tạo thư mục log: ${LOG_DIR}"
 mkdir -p "${LOG_DIR}"
fi

echo "Tiền kiểm tra OK, sẵn sàng start ${APP_NAME}."

Dấu ! ở đầu biểu thức là phép phủ định — [[ ! -f ... ]] đọc là “nếu file không tồn tại”.

Kết hợp nhiều điều kiện (AND / OR)

Có hai cách phổ biến để ghép điều kiện:

Cách 1 — ghép trong cùng [[ ]] bằng && và ||:

1
2
3


if [[ -f "/etc/nginx/nginx.conf" && -r "/etc/nginx/nginx.conf" ]]; then
 echo "Cấu hình Nginx tồn tại và đọc được."
fi

Cách 2 — nối hai lệnh test riêng bằng &&/|| ở mức shell:

1
2


command -v docker >/dev/null 2>&1 && echo "Docker đã được cài"
command -v docker >/dev/null 2>&1 || echo "Docker chưa được cài"

Trong script automation, cách 1 dễ đọc hơn khi điều kiện liên quan chặt với nhau. Cách 2 phù hợp khi bạn muốn “nếu lệnh này thành công thì làm tiếp”, ví dụ:

1

mkdir -p /backup/db && tar -czf /backup/db/dump.tar.gz /var/lib/db

Nếu mkdir thất bại, lệnh tar sẽ không chạy.

case…esac — khi if/elif quá dài

Khi cần so khớp biến với nhiều giá trị khác nhau, case thường gọn và dễ đọc hơn chuỗi if/elif.

Cú pháp:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


case <biến> in
 <pattern1>)
 <lệnh>
 ;;
 <pattern2>|<pattern3>)
 <lệnh>
 ;;
 *)
 <lệnh mặc định>
 ;;
esac

Ví dụ — script điều phối thao tác cho một service:

 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


#!/usr/bin/env bash
set -euo pipefail

ACTION="${1:-}"
SERVICE_NAME="nginx"

case "${ACTION}" in
 start)
 echo "Khởi động ${SERVICE_NAME}..."
 sudo systemctl start "${SERVICE_NAME}"
 ;;
 stop)
 echo "Dừng ${SERVICE_NAME}..."
 sudo systemctl stop "${SERVICE_NAME}"
 ;;
 restart|reload)
 echo "Khởi động lại ${SERVICE_NAME}..."
 sudo systemctl restart "${SERVICE_NAME}"
 ;;
 status)
 sudo systemctl status "${SERVICE_NAME}" --no-pager
 ;;
 *)
 echo "Usage: $0 {start|stop|restart|reload|status}"
 exit 1
 ;;
esac

case hỗ trợ pattern theo kiểu glob, nên bạn có thể viết dev*), *.log), [0-9]*) … rất tiện cho việc phân nhánh theo môi trường hoặc loại file.

Thực hành DevOps: check_service.sh

Ghép các kiến thức ở trên thành một script kiểm tra service và disk thực tế.

Tạo file check_service.sh:

 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


#!/usr/bin/env bash
set -euo pipefail

SERVICE_NAME="${1:-nginx}"
DISK_THRESHOLD="${2:-80}"

echo "========================================"
echo " Service & Disk Check"
echo " Service : ${SERVICE_NAME}"
echo " Threshold : ${DISK_THRESHOLD}%"
echo "========================================"

# 1) Kiểm tra systemctl có sẵn không
if ! command -v systemctl >/dev/null 2>&1; then
 echo "ERROR: Hệ thống không có systemctl, script dừng."
 exit 1
fi

# 2) Kiểm tra service đang chạy hay không
if systemctl is-active --quiet "${SERVICE_NAME}"; then
 echo "OK: Service ${SERVICE_NAME} đang chạy."
else
 echo "WARN: Service ${SERVICE_NAME} không chạy. Đang thử restart..."
 if sudo systemctl restart "${SERVICE_NAME}"; then
 echo "OK: Đã restart ${SERVICE_NAME}."
 else
 echo "ERROR: Restart ${SERVICE_NAME} thất bại."
 exit 2
 fi
fi

# 3) Kiểm tra dung lượng disk theo ngưỡng truyền vào
DISK_USAGE_PERCENT="$(df -P / | awk 'NR==2 {gsub("%", "", $5); print $5}')"

case 1 in
 $(( DISK_USAGE_PERCENT >= 90 )) )
 echo "CRITICAL: Disk / đã dùng ${DISK_USAGE_PERCENT}%."
 exit 2
 ;;
 $(( DISK_USAGE_PERCENT >= DISK_THRESHOLD )) )
 echo "WARNING: Disk / đã dùng ${DISK_USAGE_PERCENT}% (ngưỡng ${DISK_THRESHOLD}%)."
 exit 1
 ;;
 *)
 echo "OK: Disk / ở mức ${DISK_USAGE_PERCENT}%."
 ;;
esac

Chạy thử:

1
2


chmod +x check_service.sh
./check_service.sh nginx 80

Điểm đáng chú ý:

Dùng systemctl is-active --quiet để kiểm tra trạng thái — đây là cách “đúng chuẩn” thay vì parse output bằng grep.
Trả exit code có ý nghĩa (0/1/2) để cron, alertmanager hoặc pipeline CI/CD nhận biết mức độ.
Pattern case 1 in $(( ... )) ) là một kỹ thuật nhỏ: biểu thức số học trả về 1 khi điều kiện đúng, 0 khi sai — vì vậy nhánh nào “khớp” số 1 sẽ chạy. Nếu thấy khó đọc, bạn hoàn toàn có thể quay về if/elif/else cho rõ ràng.

Sai sót thường gặp

Quên dấu cách trong [[ ]]: Bash yêu cầu khoảng trắng quanh dấu [[, ]] và quanh toán tử. [[$A == "x"]] sẽ lỗi cú pháp.
Dùng = cho số nguyên: [[ "${COUNT}" = 1 ]] so sánh dạng chuỗi. Khi cần so sánh số, dùng -eq hoặc đưa vào (( )).
Không quote biến: Nếu biến rỗng, biểu thức có thể bị Bash phân tích sai trong [ ] (POSIX). [[ ]] an toàn hơn, nhưng vẫn nên giữ thói quen "${VAR}".
Quên ;; trong case: Mỗi nhánh case phải kết thúc bằng ;;. Quên là Bash sẽ tiếp tục chạy sang nhánh sau khi nhánh đó match.
Lẫn lộn &&/|| với pipeline: cmd1 && cmd2 chỉ chạy cmd2 khi cmd1 thành công (exit 0). Đừng nhầm với pipe | dùng để chuyển stdout.

Ghi chú triển khai

Khi áp dụng vào dự án của bạn, hãy nghĩ về exit code trước khi viết logic: script này khi nào trả 0, khi nào trả khác 0? Điều này ảnh hưởng trực tiếp tới cron và pipeline.
Best practices:
- Ưu tiên [[ ]] thay cho [ ] trong script Bash thuần.
- Luôn có nhánh *) mặc định trong case để bắt giá trị không hợp lệ và in usage.
- Khi điều kiện vượt quá 4–5 nhánh if/elif, cân nhắc chuyển sang case hoặc tách thành function.
- Đặt biến ngưỡng (threshold) lên đầu file hoặc nhận từ tham số CLI — không hardcode rải rác trong code.
Troubleshooting:
- Script không vào đúng nhánh? → Chạy với bash -x script.sh để xem giá trị biến sau khi expand.
- Báo lỗi unary operator expected? → Thường do biến rỗng trong [ -f $FILE ]. Đổi sang [[ -f "${FILE}" ]].
- case không match? → Kiểm tra pattern có cần quote không. Trong case, phía bên phải in là pattern (glob), không phải chuỗi đơn thuần.

Lời kết

Điều kiện là bước đầu tiên giúp script Bash của bạn “có não” — biết phản ứng theo trạng thái thay vì chạy mù. Với if/elif/else, case…esac, các toán tử so sánh số, chuỗi và kiểm tra file, bạn đã đủ công cụ để viết những script vận hành thực tế như healthcheck, gate deploy, hay điều phối service.

Ở bài tiếp theo, chúng ta sẽ đi vào vòng lặp trong Bash với for, while, until, kèm các ví dụ tự động hoá lặp qua danh sách server và đọc file log theo dòng.

Tài liệu tham khảo

GNU Bash Manual — Conditional Constructs — Tài liệu chính thức về if, case, select.
GNU Bash Manual — Bash Conditional Expressions — Đầy đủ các toán tử file, chuỗi, số dùng trong [[ ]] và test.
GNU Bash Manual — Shell Arithmetic — Cú pháp (( ... )) cho biểu thức số học.
ShellCheck — Công cụ lint giúp phát hiện các lỗi quote, so sánh sai kiểu trước khi đưa script vào production.

Cơ bản Bash Script trong DevOps

Sat, 23 May 2026 00:00:00 +0000

Cơ bản Bash Script trong DevOps

Trong công việc DevOps, có rất nhiều tác vụ lặp lại hằng ngày: kiểm tra dung lượng ổ đĩa, xem service còn chạy không, backup file cấu hình, gom log, hoặc chạy một chuỗi lệnh deploy đơn giản. Nếu làm thủ công từng bước, bạn rất dễ quên lệnh, gõ sai tham số hoặc mất thời gian khi phải thao tác trên nhiều server.

Bash Script giúp đóng gói các lệnh đó thành một file có thể chạy lại nhiều lần. Đây là kỹ năng nền tảng trước khi bạn đi sâu vào CI/CD, Docker, Kubernetes, Cloud CLI hay automation phức tạp hơn.

Bash là gì?

Bash là viết tắt của Bourne Again SHell — một chương trình shell phổ biến trên Linux và macOS. Shell nhận lệnh từ người dùng, diễn giải lệnh đó, rồi yêu cầu hệ điều hành thực thi.

Khi bạn gõ lệnh trong terminal như:

1
2
3


ls -lah
df -h
cat /etc/os-release

bạn đang tương tác với shell. Khi gom nhiều lệnh vào một file text, file đó trở thành shell script. Theo tài liệu chính thức của GNU Bash, một shell script là file văn bản chứa các lệnh shell; khi được Bash chạy, Bash đọc và thực thi các lệnh trong file đó rồi thoát.

Vì sao DevOps cần biết Bash?

Bash không thay thế các công cụ như Ansible, Terraform hay Jenkins, nhưng nó là lớp keo rất hữu ích để nối các công cụ lại với nhau.

Tình huống DevOps	Bash giúp gì?
Kiểm tra server nhanh	Gom `hostname`, `df`, `free`, `uptime` vào một script
Deploy ứng dụng nhỏ	Chạy pull code, build, restart service theo đúng thứ tự
Dọn log hoặc file tạm	Tự động tìm và xoá file cũ theo lịch
CI/CD pipeline	Viết step build/test/deploy có exit code rõ ràng
Tích hợp tool	Gọi `docker`, `kubectl`, `aws`, `curl`, `jq` từ một script

Điểm mạnh của Bash là có sẵn trên hầu hết server Linux, không cần cài runtime phức tạp. Với những tác vụ nhỏ, một script 20–50 dòng thường đủ nhanh, dễ đọc và dễ đưa vào pipeline.

Script đầu tiên với hello.sh

Tạo file hello.sh:

1

vi hello.sh

Thêm nội dung sau:

1
2
3
4


#!/usr/bin/env bash

echo "Hello DevOps!"
echo "Script đang chạy trên máy: $(hostname)"

Chạy script bằng Bash:

1

bash hello.sh

Hoặc cấp quyền thực thi rồi chạy trực tiếp:

1
2


chmod +x hello.sh
./hello.sh

Shebang dùng để làm gì?

Dòng đầu tiên:

1

#!/usr/bin/env bash

được gọi là shebang. Nó cho hệ điều hành biết nên dùng chương trình nào để chạy file này. Cách viết #!/usr/bin/env bash thường linh hoạt hơn #!/bin/bash vì Bash có thể nằm ở vị trí khác nhau tuỳ hệ thống.

Làm việc với biến

Biến giúp script lưu giá trị để tái sử dụng. Cú pháp gán biến trong Bash không có khoảng trắng quanh dấu =:

1
2
3
4
5


APP_NAME="manager-blog"
ENVIRONMENT="staging"

echo "Ứng dụng: $APP_NAME"
echo "Môi trường: ${ENVIRONMENT}"

Nên dùng ${VAR} khi ghép biến với chuỗi để tránh Bash hiểu nhầm tên biến:

1
2
3
4


BACKUP_DIR="/backup"
APP_NAME="manager-blog"

echo "File backup: ${BACKUP_DIR}/${APP_NAME}.tar.gz"

Một số biến đặc biệt hay gặp

Biến	Ý nghĩa
`$0`	Tên script đang chạy
`$1`	Tham số đầu tiên truyền vào script
`$#`	Tổng số tham số
`$?`	Exit code của lệnh vừa chạy
`$$`	Process ID của shell hiện tại

Ví dụ script nhận tên môi trường:

1
2
3
4
5


#!/usr/bin/env bash

ENVIRONMENT="${1:-dev}"

echo "Deploy tới môi trường: ${ENVIRONMENT}"

Chạy thử:

1

bash deploy-message.sh staging

Nếu không truyền tham số, ${1:-dev} sẽ dùng giá trị mặc định là dev.

Một số lệnh cơ bản thường dùng

echo

echo in nội dung ra màn hình, rất hữu ích để hiển thị trạng thái trong script:

1
2


echo "Bắt đầu kiểm tra hệ thống..."
echo "Hoàn tất."

read

read đọc input từ người dùng:

1
2
3
4


#!/usr/bin/env bash

read -r -p "Nhập tên service cần kiểm tra: " SERVICE_NAME
echo "Bạn muốn kiểm tra service: ${SERVICE_NAME}"

Trong script, nên dùng read -r để tránh việc dấu backslash bị diễn giải ngoài ý muốn.

cat

cat thường dùng để xem nhanh nội dung file hoặc tạo file mẫu:

1

cat /etc/os-release

Tạo file cấu hình bằng here-document:

1
2
3
4


cat > app.env <<'EOF'
APP_ENV=staging
APP_PORT=8080
EOF

ls

ls liệt kê file/thư mục:

1

ls -lah /var/log

Trong script production, nếu cần xử lý danh sách file phức tạp, bạn nên cẩn thận với tên file có khoảng trắng. Các bài sau về xử lý file sẽ đi sâu hơn vào chủ đề này.

Thực hành DevOps: check_system.sh

Ví dụ dưới đây tạo một script kiểm tra nhanh thông tin hệ thống: hostname, hệ điều hành, uptime, CPU load, RAM và dung lượng ổ đĩa root.

Tạo file:

1

vi check_system.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


#!/usr/bin/env bash
set -euo pipefail

echo "========================================"
echo " System quick check"
echo "========================================"

HOSTNAME_VALUE="$(hostname)"
KERNEL_VALUE="$(uname -sr)"
UPTIME_VALUE="$(uptime -p 2>/dev/null || uptime)"
DISK_USAGE_PERCENT="$(df -P / | awk 'NR==2 {gsub("%", "", $5); print $5}')"

if [[ -r /proc/loadavg ]]; then
 LOAD_1M="$(awk '{print $1}' /proc/loadavg)"
else
 LOAD_1M="$(uptime | awk -F'load average: ' '{print $2}' | awk -F',' '{print $1}')"
fi

echo "Hostname : ${HOSTNAME_VALUE}"
echo "Kernel : ${KERNEL_VALUE}"
echo "Uptime : ${UPTIME_VALUE}"
echo "Load 1m : ${LOAD_1M}"
echo "Disk / : ${DISK_USAGE_PERCENT}%"

if command -v free >/dev/null 2>&1; then
 echo
 echo "Memory:"
 free -h
else
 echo
 echo "Memory: command 'free' không có trên hệ thống này."
fi

echo
if (( DISK_USAGE_PERCENT >= 80 )); then
 echo "WARNING: Dung lượng ổ đĩa / đã vượt ngưỡng 80%."
 exit 1
else
 echo "OK: Dung lượng ổ đĩa / vẫn trong ngưỡng an toàn."
fi

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

1
2


chmod +x check_system.sh
./check_system.sh

Output có thể tương tự:

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


========================================
 System quick check
========================================
Hostname : webserver-01
Kernel : Linux 6.8.0-31-generic
Uptime : up 3 days, 4 hours, 12 minutes
Load 1m : 0.21
Disk / : 42%

Memory:
 total used free shared buff/cache available
Mem: 3.8Gi 1.1Gi 720Mi 32Mi 2.0Gi 2.4Gi
Swap: 2.0Gi 0B 2.0Gi

OK: Dung lượng ổ đĩa / vẫn trong ngưỡng an toàn.

Điểm đáng chú ý trong script:

set -euo pipefail giúp script dừng khi gặp lỗi, khi dùng biến chưa khai báo, hoặc khi một lệnh trong pipeline bị lỗi.
df -P / dùng định dạng POSIX để output ổn định hơn khi parse bằng awk.
command -v free kiểm tra lệnh free có tồn tại trước khi gọi.
exit 1 khi disk vượt ngưỡng giúp CI/CD hoặc cron job nhận biết script đang báo lỗi.

Debug script với bash -n và bash -x

Khi script dài hơn, bạn cần kiểm tra lỗi cú pháp và xem Bash thực thi từng lệnh như thế nào.

Kiểm tra cú pháp với bash -n

1

bash -n check_system.sh

Tuỳ chọn -n yêu cầu Bash đọc lệnh nhưng không thực thi. Nó hữu ích để phát hiện lỗi như thiếu fi, thiếu dấu nháy, hoặc sai cú pháp vòng lặp.

Trace từng lệnh với bash -x

1

bash -x check_system.sh

Tuỳ chọn -x in ra từng lệnh sau khi Bash đã expand biến và trước khi thực thi. Đây là cách rất nhanh để biết script đang nhận giá trị nào.

Bạn cũng có thể bật/tắt trace trong một đoạn cụ thể:

1
2
3


set -x
DISK_USAGE_PERCENT="$(df -P / | awk 'NR==2 {gsub("%", "", $5); print $5}')"
set +x

Lưu ý bảo mật: Không bật set -x quanh đoạn xử lý secret/token vì giá trị nhạy cảm có thể bị in ra log.

Best practice khi mới viết Bash

Một vài thói quen nhỏ sẽ giúp script dễ đọc và ít lỗi hơn:

Luôn quote biến: dùng "${VAR}" thay vì $VAR, đặc biệt khi giá trị có khoảng trắng.
Đặt tên biến rõ nghĩa: DISK_USAGE_PERCENT dễ hiểu hơn D hoặc VALUE.
Dùng set -euo pipefail có chủ đích: tốt cho nhiều script automation, nhưng cần hiểu luồng lỗi trước khi dùng trong script phức tạp.
Kiểm tra command trước khi dùng: command -v docker, command -v jq, command -v kubectl.
Không hardcode thông tin nhạy cảm: token, password, private key nên lấy từ environment variable hoặc secret manager.
Trả exit code rõ ràng: exit 0 cho thành công, khác 0 cho lỗi để cron/CI/CD nhận biết.
Chạy bash -n trước khi deploy: đây là bước kiểm tra nhanh nhưng rất hữu ích.

Ghi chú triển khai

Khi áp dụng vào dự án của bạn, hãy bắt đầu bằng các script nhỏ, rõ mục tiêu: check_system.sh, backup_config.sh, restart_service.sh. Đừng cố viết một script quá lớn ngay từ đầu.
Best practices:
- Đặt script trong thư mục riêng như scripts/ hoặc ops/.
- Thêm README ngắn mô tả cách chạy, tham số đầu vào và ví dụ output.
- Với script chạy trong CI/CD, luôn kiểm tra exit code và log đủ thông tin để debug.
Troubleshooting:
- Lỗi Permission denied? → Chạy chmod +x script.sh hoặc dùng bash script.sh.
- Lỗi command not found? → Kiểm tra command đã cài chưa và biến PATH có đúng không.
- Script chạy khác giữa local và server? → Kiểm tra phiên bản Bash bằng bash --version và hệ điều hành bằng cat /etc/os-release.

Lời kết

Bash Script là kỹ năng nền tảng nhưng rất thực dụng trong DevOps. Chỉ với vài lệnh cơ bản như echo, read, cat, ls, kết hợp biến và kiểm tra exit code, bạn đã có thể tự động hóa nhiều tác vụ vận hành hằng ngày.

Ở bài tiếp theo, chúng ta sẽ đi vào điều kiện trong Bash với if/elif/else, toán tử so sánh, kiểm tra file và case...esac — những thành phần giúp script bắt đầu có logic xử lý linh hoạt hơn.

Tài liệu tham khảo

GNU Bash Manual — Tài liệu chính thức về Bash, shell scripts, biến, builtins và các tuỳ chọn như -n, -x.
GNU Bash Reference Manual - Shell Scripts — Mô tả cách Bash đọc và thực thi shell script.
GNU Bash Reference Manual - The Set Builtin — Tham khảo các tuỳ chọn set, bao gồm -u, -x, -n.

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é! 😊

Tài liệu tham khảo

Cách cài đặt Docker trên Ubuntu

Sun, 30 Nov 2025 00:00:00 +0000

Giới thiệu về Docker

Docker là một nền tảng phổ biến trong DevOps để triển khai ứng dụng bằng container. Container cho phép bạn đóng gói ứng dụng cùng với tất cả các dependencies và cấu hình cần thiết, giúp ứng dụng chạy nhất quán trên mọi môi trường từ development đến production.

Lợi ích của Docker:

⚡ Tính nhất quán: Ứng dụng chạy giống nhau trên mọi môi trường
🚀 Tốc độ: Khởi động container nhanh hơn so với virtual machine
📦 Đóng gói: Dễ dàng chia sẻ và triển khai ứng dụng
🔄 Scalability: Dễ dàng mở rộng và quản lý nhiều container

Bài viết này hướng dẫn bạn cách cài đặt Docker trên Ubuntu 20.04 và 22.04 một cách đơn giản và hiệu quả, sử dụng repository chính thức của Docker để đảm bảo bạn luôn có phiên bản mới nhất và ổn định.

Yêu cầu trước khi cài đặt

Trước khi bắt đầu, hãy đảm bảo bạn có:

🖥 Máy chủ Ubuntu 20.04 hoặc 22.04 đã được cài đặt
🔐 Quyền sudo để thực thi các lệnh quản trị
🌐 Kết nối internet để tải các gói cài đặt
⏱ Thời gian: Quá trình cài đặt mất khoảng 5-10 phút

Cập nhật hệ thống

Trước khi cài đặt Docker, hãy đảm bảo hệ thống được cập nhật đầy đủ. Điều này giúp đảm bảo bạn có các bản vá bảo mật mới nhất và các gói phụ thuộc cần thiết.

1

sudo apt update && sudo apt upgrade -y

💡 Lưu ý:

Lệnh apt update cập nhật danh sách các gói có sẵn từ repository
Lệnh apt upgrade -y tự động cài đặt các bản cập nhật mà không cần xác nhận
Quá trình này có thể mất vài phút tùy thuộc vào số lượng gói cần cập nhật

Cài đặt Docker

Cài đặt các gói phụ thuộc

Các gói này cần thiết để Docker có thể tải và xác thực các gói từ repository chính thức:

apt-transport-https: Cho phép APT sử dụng giao thức HTTPS
ca-certificates: Cung cấp chứng chỉ SSL/TLS để xác thực kết nối bảo mật
curl: Công cụ để tải xuống các file từ internet
software-properties-common: Cung cấp các tiện ích để quản lý repository

1

sudo apt install -y apt-transport-https ca-certificates curl software-properties-common

Thêm repository Docker chính thức

Để cài đặt Docker từ nguồn chính thức, chúng ta cần thêm GPG key và repository của Docker vào hệ thống. Điều này đảm bảo bạn nhận được các bản cập nhật chính thức và bảo mật từ Docker.

Bước 1: Thêm GPG key của Docker

GPG key được sử dụng để xác thực tính toàn vẹn của các gói Docker:

1

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg

Bước 2: Thêm Docker repository

Thêm repository Docker vào danh sách nguồn của APT. Lệnh này tự động phát hiện phiên bản Ubuntu của bạn ($(lsb_release -cs)) và thêm repository phù hợp:

1

echo "deb [arch=amd64 signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

💡 Giải thích:

arch=amd64: Chỉ định kiến trúc 64-bit
signed-by: Chỉ định GPG key để xác thực
$(lsb_release -cs): Tự động lấy tên code name của Ubuntu (ví dụ: jammy cho Ubuntu 22.04)
stable: Sử dụng channel ổn định (có thể dùng test hoặc nightly cho các phiên bản thử nghiệm)

Cài đặt Docker Engine

Sau khi đã thêm repository, cập nhật danh sách gói và cài đặt Docker Engine:

1
2


sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io

📦 Các gói được cài đặt:

docker-ce: Docker Community Edition - phiên bản mã nguồn mở của Docker
docker-ce-cli: Docker Command Line Interface - công cụ dòng lệnh để tương tác với Docker
containerd.io: Container runtime - công cụ quản lý vòng đời container ở mức thấp

⏱ Thời gian cài đặt: Quá trình này thường mất 2-5 phút tùy thuộc vào tốc độ internet của bạn.

Kiểm tra Docker

Sau khi cài đặt, hãy kiểm tra xem Docker đã được khởi động và hoạt động chưa:

1

sudo systemctl status docker

Kết quả mong đợi: Bạn sẽ thấy trạng thái active (running) nếu Docker đã khởi động thành công.

Nếu Docker chưa chạy, bạn có thể khởi động và kích hoạt Docker để tự động khởi động khi hệ thống boot:

1
2


sudo systemctl start docker
sudo systemctl enable docker

💡 Giải thích các lệnh:

systemctl start docker: Khởi động dịch vụ Docker ngay lập tức
systemctl enable docker: Cấu hình Docker tự động khởi động khi hệ thống khởi động lại

Chạy thử Docker

Để xác nhận Docker đã hoạt động đúng, chạy container mẫu hello-world:

1

sudo docker run hello-world

Kết quả mong đợi: Nếu thấy thông báo “Hello from Docker!” cùng với các thông tin về Docker, nghĩa là bạn đã cài đặt thành công! 🎉

🔍 Container hello-world làm gì?

Container này tải xuống image hello-world từ Docker Hub (nếu chưa có)
Chạy container và hiển thị thông báo chào mừng
Tự động dừng sau khi hoàn thành

Cấu hình quyền cho user

Mặc định, Docker yêu cầu quyền root để chạy các lệnh. Để chạy Docker không cần sudo, bạn cần thêm user hiện tại vào nhóm docker:

1
2


sudo usermod -aG docker $USER
newgrp docker

💡 Giải thích:

usermod -aG docker $USER: Thêm user hiện tại vào nhóm docker (nhóm này có quyền truy cập Docker daemon)
newgrp docker: Áp dụng thay đổi nhóm ngay lập tức mà không cần đăng xuất

⚠ Lưu ý quan trọng:

Sau khi thực hiện lệnh này, bạn có thể cần đăng xuất và đăng nhập lại để thay đổi có hiệu lực
Hoặc bạn có thể mở terminal mới để áp dụng thay đổi
Việc thêm user vào nhóm docker cho phép user đó có quyền tương đương root trên Docker daemon, vì vậy chỉ thêm những user đáng tin cậy

Kiểm tra quyền mới:

Sau khi cấu hình, thử chạy Docker không cần sudo:

1

docker run hello-world

Nếu lệnh chạy thành công mà không cần sudo, bạn đã cấu hình đúng! ✅

Gỡ cài đặt Docker (nếu cần)

Nếu bạn muốn gỡ cài đặt Docker hoàn toàn khỏi hệ thống, thực hiện các bước sau:

Bước 1: Gỡ cài đặt các gói Docker

1

sudo apt remove -y docker-ce docker-ce-cli containerd.io

Bước 2: Xóa dữ liệu Docker

Dữ liệu Docker (images, containers, volumes, networks) được lưu trong /var/lib/docker. Để xóa hoàn toàn:

1

sudo rm -rf /var/lib/docker

⚠ Cảnh báo: Lệnh này sẽ xóa TẤT CẢ dữ liệu Docker bao gồm:

Tất cả images đã tải về
Tất cả containers (đang chạy và đã dừng)
Tất cả volumes và networks
Tất cả dữ liệu trong containers

Bước 3: Xóa cấu hình Docker (tùy chọn)

Nếu muốn xóa hoàn toàn mọi dấu vết của Docker:

1
2


sudo rm -rf /var/lib/containerd
sudo rm -rf /etc/docker

Các lệnh Docker cơ bản

Sau khi cài đặt Docker, đây là một số lệnh cơ bản bạn nên biết:

Lệnh	Mô tả
`docker --version`	Kiểm tra phiên bản Docker
`docker ps`	Liệt kê các container đang chạy
`docker ps -a`	Liệt kê tất cả containers (bao gồm đã dừng)
`docker images`	Liệt kê tất cả images
`docker pull <image>`	Tải image từ Docker Hub
`docker run <image>`	Chạy container từ image
`docker stop <container>`	Dừng container đang chạy
`docker rm <container>`	Xóa container
`docker rmi <image>`	Xóa image

Troubleshooting

Vấn đề: Docker daemon không khởi động

Nguyên nhân: Có thể do xung đột với các dịch vụ khác hoặc cấu hình sai.

Giải pháp:

1
2
3
4
5


# Kiểm tra log của Docker
sudo journalctl -u docker

# Khởi động lại Docker
sudo systemctl restart docker

Vấn đề: Permission denied khi chạy Docker

Nguyên nhân: User chưa được thêm vào nhóm docker.

Giải pháp:

1
2
3
4
5


# Thêm user vào nhóm docker
sudo usermod -aG docker $USER

# Đăng xuất và đăng nhập lại, hoặc chạy:
newgrp docker

Vấn đề: Không thể kết nối đến Docker daemon

Nguyên nhân: Docker daemon chưa được khởi động.

Giải pháp:

1
2
3
4
5


# Kiểm tra trạng thái
sudo systemctl status docker

# Khởi động Docker
sudo systemctl start docker

Lời kết

Vậy là chúng ta đã hoàn tất cài đặt Docker trên Ubuntu! 🎉 Giờ đây, bạn có thể bắt đầu:

🐳 Tạo và chạy containers cho các ứng dụng của mình
📦 Sử dụng Docker images có sẵn từ Docker Hub
🚀 Triển khai ứng dụng một cách nhất quán và dễ dàng
🔄 Quản lý môi trường development và production hiệu quả hơn

Docker là một công cụ mạnh mẽ trong thế giới DevOps. Hãy tiếp tục khám phá các tính năng của Docker như Docker Compose, Docker Swarm, và tích hợp với các công cụ CI/CD để tối ưu hóa quy trình phát triển của bạn!

📖 Tài liệu tham khảo:

Tài liệu chính thức của Docker
Docker Hub - Kho lưu trữ images lớn nhất
Best practices cho Docker

Chúc bạn thành công với Docker! 🚀😊

Tối ưu Docker cho Java

Sat, 29 Nov 2025 00:00:00 +0000

Dockerfile Contest 2025 – Java tối ưu extreme

Dockerfile Contest 2025 thúc đẩy cộng đồng DevOps Việt Nam đánh giá lại cách viết Dockerfile để đạt bảo mật, tối ưu, tường minh. Bài viết này tổng hợp riêng cho hạng mục Java Spring Boot, nơi các tác giả tập trung tối ưu JRE, giảm kích thước image và chuẩn hóa quy trình build.

I. Hạng mục JAVA (Spring Boot Service)

Hạng mục Java tập trung vào các ý tưởng:

Tối ưu JRE: dùng jlink và jdeps để tạo custom JRE chỉ chứa module cần thiết.
Tối ưu security & dependency: tự động cập nhật dependency an toàn, giảm CVE.
Multi-stage build: tách rõ stage build và runtime, dùng distroless hoặc base image tối ưu.
Healthcheck rõ ràng: dùng wget hoặc Java native healthcheck để giám sát container.

Dockerfile TOP 1 (Java) – Spring Boot Template + Distroless

Kỹ thuật	Giải thích theo tác giả	Nguồn tham khảo
Custom JRE bằng jlink	Dùng `jdeps` phân tích fat JAR để lấy danh sách module, sau đó `jlink` tạo JRE chỉ chứa module cần, giảm đáng kể kích thước runtime.
Multi-stage build rõ ràng	Stage `build` dùng `eclipse-temurin:21-jdk` để build Gradle; stage runtime dùng `gcr.io/distroless/base-debian12` chỉ chạy JRE.
Phân tách Healthcheck Stage	Tạo stage `healthcheck` dùng BusyBox, copy `wget` vào runtime để healthcheck mà không phải cài thêm full curl/wget từ package manager.
Distroless Runtime	Dùng distroless base để giảm attack surface (không shell, không package manager), image gọn và an toàn hơn.
Pin nguồn & license	Thêm LABEL `org.opencontainers.image.source`, `version`, `licenses` để dễ truy vết source code và tuân thủ license.

Dockerfile TOP 1 (JAVA)

 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
60
61
62
63
64
65
66
67
68
69
70
71


# Build stage
FROM eclipse-temurin:21-jdk AS build

WORKDIR /app

# Copy gradle wrapper and properties first for better caching
COPY gradlew gradlew.bat build.gradle ./
COPY gradle/ gradle/

# Download Gradle distribution (cached)
RUN --mount=type=cache,target=/root/.gradle ./gradlew --version

# Copy source code
COPY src/ src/

# Build the application
RUN --mount=type=cache,target=/root/.gradle ./gradlew --no-daemon clean bootJar \
 -Dspring-framework.version=6.2.11 \
 -Dtomcat.version=10.1.47

# Extract the application dependencies
RUN jar xf build/libs/spring-boot-template.jar

# Analyze the dependencies contained into the fat jar
RUN jdeps --ignore-missing-deps -q \
 --recursive \
 --multi-release 21 \
 --print-module-deps \
 --class-path 'BOOT-INF/lib/*' \
 build/libs/spring-boot-template.jar > deps.info

# Create the custom JRE
RUN jlink \
 --verbose \
 --add-modules $(cat deps.info) \
 --compress zip-9 \
 --no-header-files \
 --no-man-pages \
 --output /custom_jre

# Healthcheck stage
FROM busybox:1.36.0-musl AS healthcheck

# Runtime stage
FROM gcr.io/distroless/base-debian12
ENV JAVA_HOME=/opt/java/openjdk
ENV PATH="$JAVA_HOME/bin:$PATH"
COPY --from=build /custom_jre $JAVA_HOME

# Copy wget for healthcheck
COPY --from=healthcheck /bin/wget /usr/bin/wget

WORKDIR /app

# Copy application insights config
COPY lib/applicationinsights.json ./

# Copy the built JAR
COPY --from=build /app/build/libs/spring-boot-template.jar /app.jar

# Add labels
LABEL org.opencontainers.image.source="https://github.com/hmcts/spring-boot-template" \
 org.opencontainers.image.version="0.0.1" \
 org.opencontainers.image.licenses="MIT"

EXPOSE 8080

HEALTHCHECK --interval=30s --timeout=3s --start-period=10s --retries=3 \
 CMD ["/usr/bin/wget", "--quiet", "--output-document=/dev/null", "http://localhost:8080/health"]

CMD ["java", "-jar", "/app.jar"]

Dockerfile TOP 2 (Java) – Gradle Auto Dependency Update + Custom Healthcheck

Kỹ thuật	Giải thích theo tác giả	Nguồn tham khảo
Gradle Dependency Updates	Dùng plugin `dependencyUpdates` để sinh report, sau đó script shell parse report và tự động update version plugin/ext/dependency trong `build.gradle`.
Force Dependency Upgrade	Biến `DEPENDENCIES_FORCE_UPDATE` cho phép chỉ định `group:name:version` để ép cập nhật những dependency quan trọng, thường là những lib dính CVE.
Native Java Healthcheck	Viết class `HealthCheck.java` dùng `HttpURLConnection` gọi `/health`, giúp healthcheck không phụ thuộc curl/wget.
Distroless Base Java	Runtime dùng `hmctspublic.azurecr.io/base/java:21-distroless`, image Java 21 tối ưu sẵn cho production.
Cache Gradle	Mount cache `/root/.gradle` để tăng tốc `./gradlew` trong stage build.

Dockerfile TOP 2 (JAVA)

 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
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135


# Stage 1 — Build application using Gradle
FROM gradle:8.14.3-jdk21-alpine AS builder

WORKDIR /app

# Caching wrapper and build configuration before build 
COPY gradlew ./
COPY gradle gradle
COPY build.gradle build.gradle

# Caching gradle/download
RUN ./gradlew --no-daemon help

# Copy src code
COPY src/main src/main

# Check dependency need to update
RUN ./gradlew --no-daemon dependencyUpdates -Drevision=release

# Auto update for auto vulnerability fixing 
RUN REPORT_FILE="build/dependencyUpdates/report.txt" && \
 echo "=== Parsing $REPORT_FILE ===" && \
 \
 PLUGINS_TO_UPGRADE=${PLUGINS_TO_UPGRADE:-"org.springframework.boot org.sonarqube com.github.ben-manes.versions uk.gov.hmcts.java"} && \
 EXTS_TO_UPGRADE=${EXTS_TO_UPGRADE:-"org.apache.logging.log4j ch.qos.logback"} && \
 DEPENDENCIES_FORCE_UPDATE=${DEPENDENCIES_FORCE_UPDATE:-"org.apache.commons:commons-lang3:3.19.0"} && \
 \
 escape_sed() { printf '%s\n' "$1" | sed 's/[.[\*^$/&]/\\&/g'; } && \
 \
 # --- Plugin updates ---
 for plugin in $PLUGINS_TO_UPGRADE; do \
 LINE=$(grep -A1 "$plugin" "$REPORT_FILE" | grep '\[' | head -1 || true); \
 OLD_VERSION=$(echo "$LINE" | sed -E 's/.*\[(.*) -> .*\].*/\1/' || true); \
 NEW_VERSION=$(echo "$LINE" | sed -E 's/.*\[.* -> (.*)\].*/\1/' || true); \
 if [ -n "$NEW_VERSION" ] && [ "$NEW_VERSION" != "$OLD_VERSION" ]; then \
 echo "===== Upgrading plugin $plugin: $OLD_VERSION → $NEW_VERSION"; \
 ESC_OLD=$(escape_sed "$OLD_VERSION"); \
 ESC_NEW=$(escape_sed "$NEW_VERSION"); \
 sed -i "s#id '$plugin' version '$ESC_OLD'#id '$plugin' version '$ESC_NEW'#g" build.gradle; \
 fi; \
 done && \
 \
 # --- ext{} version updates ---
 for prefix in $EXTS_TO_UPGRADE; do \
 LINE=$(grep -A1 "$prefix" "$REPORT_FILE" | grep '\[' | head -1 || true); \
 OLD_VERSION=$(echo "$LINE" | sed -E 's/.*\[(.*) -> .*\].*/\1/' || true); \
 NEW_VERSION=$(echo "$LINE" | sed -E 's/.*\[.* -> (.*)\].*/\1/' || true); \
 if [ -n "$NEW_VERSION" ] && [ "$NEW_VERSION" != "$OLD_VERSION" ]; then \
 echo "===== Upgrading prefix $prefix: $OLD_VERSION → $NEW_VERSION"; \
 ESC_OLD=$(escape_sed "$OLD_VERSION"); \
 ESC_NEW=$(escape_sed "$NEW_VERSION"); \
 sed -i "s/\"$ESC_OLD\"/\"$ESC_NEW\"/g" build.gradle; \
 fi; \
 done && \
 \
 # --- Force dependency updates with explicit GAV ---
 for dep in $DEPENDENCIES_FORCE_UPDATE; do \
 GROUP=$(echo "$dep" | cut -d':' -f1); \
 NAME=$(echo "$dep" | cut -d':' -f2); \
 NEW_VERSION=$(echo "$dep" | cut -d':' -f3); \
 if [ -z "$GROUP" ] || [ -z "$NAME" ] || [ -z "$NEW_VERSION" ]; then \
 echo "====== Invalid DEPENDENCIES_FORCE_UPDATE format for $dep, expected group:name:version"; \
 continue; \
 fi; \
 echo "====== Forcing dependency update: $GROUP:$NAME → $NEW_VERSION"; \
 ESC_GROUP=$(escape_sed "$GROUP"); \
 ESC_NAME=$(escape_sed "$NAME"); \
 ESC_NEW=$(escape_sed "$NEW_VERSION"); \
 if grep -q "$ESC_GROUP" build.gradle | grep -q "$ESC_NAME"; then \
 # Replace existing dependency version
 sed -i "s#group: '$ESC_GROUP', name: '$ESC_NAME', version: '[^']*'#group: '$ESC_GROUP', name: '$ESC_NAME', version: '$ESC_NEW'#g" build.gradle; \
 else \
 # Insert new dependency inside dependencies { }
 echo "====== Adding new dependency $GROUP:$NAME:$NEW_VERSION"; \
 sed -i "/dependencies\s*{/a\ implementation group: '$GROUP', name: '$NAME', version: '$NEW_VERSION'" build.gradle; \
 fi; \
 done && \
 \
 echo "Version upgrade complete!" && \
 cat build.gradle

# Build the application JAR after dependency check
RUN ./gradlew --no-daemon bootJar

# Generate java healthcheck class
RUN mkdir -p /app/health && cat > /app/health/HealthCheck.java <<'EOF'
import java.net.HttpURLConnection;
import java.net.URL;
import java.time.Instant;

public class HealthCheck {
 public static void main(String[] args) {
 String healthUrl = "http://localhost:8080/health";
 try {
 URL url = new URL(healthUrl);
 HttpURLConnection conn = (HttpURLConnection) url.openConnection();
 conn.setConnectTimeout(2000);
 conn.setReadTimeout(2000);
 conn.setRequestMethod("GET");

 int code = conn.getResponseCode();
 if (code == 200) {
 System.out.println(Instant.now() + "Healthcheck OK (" + code + ")");
 System.exit(0);
 } else {
 System.err.println(Instant.now() + "Healthcheck failed (" + code + ")");
 System.exit(1);
 }
 } catch (Exception e) {
 System.err.println(Instant.now() + " Healthcheck error: " + e.getMessage());
 System.exit(1);
 }
 }
}
EOF

# Compile HealthCheck.java file
RUN javac /app/health/HealthCheck.java

# Stage 2 — Runtime image (auto-updated base)
FROM hmctspublic.azurecr.io/base/java:21-distroless

WORKDIR /app

# Copy compiled app
COPY --from=builder /app/build/libs/*.jar app.jar

# Copy complied healthcheck class
COPY --from=builder /app/health/HealthCheck.class /app/HealthCheck.class

EXPOSE 8080
ENTRYPOINT ["java", "-jar", "app.jar"]

HEALTHCHECK --interval=15s --timeout=5s --start-period=10s --retries=3 \
 CMD ["java", "HealthCheck"]

Dockerfile TOP (Java) – Dung Cao (Alpine JDK/JRE tối ưu)

Kỹ thuật	Giải thích theo tác giả	Nguồn tham khảo
Tách riêng JDK/JRE bằng ARG	Dùng `ARG BUILD_JDK_IMAGE` và `RUNTIME_IMAGE` để dễ đổi base image (JDK cho build, JRE cho runtime), vẫn giữ Dockerfile đơn giản.
Gradle cache với BuildKit	Dùng `--mount=type=cache,target=/cache/.gradle` cho các lệnh `./gradlew` để tối ưu thời gian build lặp lại.
Không chạy test trong build image	`bootJar -x test` giúp build nhanh hơn cho môi trường CI/CD và Docker contest (ưu tiên ra artifact).
Non-root user + chown	Tạo user/group `app`, `--chown=app:app` khi copy JAR đảm bảo runtime an toàn, tuân CIS Docker Benchmark.
Healthcheck với curl	Cài `curl` (apk add –no-cache) rồi dùng `curl -fsS` tới `/health` cho healthcheck rõ ràng, dễ debug.
JVM tuning cho container	`JAVA_OPTS` bật `UseContainerSupport`, `MaxRAMPercentage=75`, `G1GC`, `ExitOnOutOfMemoryError`, heap dump path… giúp JVM hiểu giới hạn container và fail-fast khi OOM.

Dockerfile TOP (JAVA) – Dung Cao

 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
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101


# Dockerfile.txt
# === Alpine build optimized for Dockerfile Contest 2025 ===
# Focus: security, lightweight, clear, maintainable

# Build-time arguments
ARG BUILD_JDK_IMAGE=eclipse-temurin:21-jdk-alpine-3.22
ARG RUNTIME_IMAGE=eclipse-temurin:21-jre-alpine-3.22

# ---------- Stage: builder ----------
FROM ${BUILD_JDK_IMAGE} AS builder

# Set non-interactive environment & reproducible timezone
ENV TZ=UTC \
 LANG=C.UTF-8 \
 LC_ALL=C.UTF-8 \
 GRADLE_USER_HOME=/cache/.gradle

WORKDIR /workspace

# Copy Gradle wrapper and descriptors
COPY gradlew .
COPY gradle/ gradle/
COPY build.gradle ./

RUN chmod +x ./gradlew

# Resolve dependencies using BuildKit cache mount
RUN --mount=type=cache,target=/cache/.gradle \
 ./gradlew --no-daemon dependencies || true

# Copy application source
COPY src/ src/

RUN --mount=type=cache,target=/cache/.gradle \
 ./gradlew --no-daemon clean bootJar -x test \
 -Dspring-framework.version=6.2.11 \
 -Dcommons-lang3.version=3.18.0 \
 -Dtomcat.version=10.1.47

# ---------- Stage: runtime ----------
FROM ${RUNTIME_IMAGE} AS runtime

ARG VERSION
ARG VCS_REF
ARG BUILD_DATE
ARG LICENSE="MIT License"
ARG SOURCE="contest-submission"

# OCI Labels (metadata)
LABEL org.opencontainers.image.title="spring-boot-template" \
 org.opencontainers.image.description="Spring Boot Java application built for Dockerfile Contest 2025" \
 org.opencontainers.image.url="${SOURCE}" \
 org.opencontainers.image.source="${SOURCE}" \
 org.opencontainers.image.version="${VERSION}" \
 org.opencontainers.image.revision="${VCS_REF}" \
 org.opencontainers.image.licenses="${LICENSE}" \
 org.opencontainers.image.created="${BUILD_DATE}" \
 org.opencontainers.image.authors="Dung Cao"

# Create non-root user
RUN addgroup -S app && adduser -S app -G app

WORKDIR /app

# Copy application jar
COPY lib/applicationinsights.json applicationinsights.json
COPY --from=builder --chown=app:app /workspace/build/libs/*.jar app.jar

# Install curl for healthcheck
RUN apk add --no-cache curl \
 && rm -rf /var/cache/apk/*

# Expose HTTP port
EXPOSE 8080

# Healthcheck
HEALTHCHECK --interval=10s --timeout=3s --start-period=10s --retries=3 \
 CMD curl -fsS http://127.0.0.1:8080/health || exit 1

# JVM optimization
ENV JAVA_OPTS="\
 -XX:+UseContainerSupport \
 -XX:MaxRAMPercentage=75.0 \
 -Djava.security.egd=file:/dev/./urandom \
 -Dserver.shutdown=graceful \
 -Dspring.lifecycle.timeout-per-shutdown-phase=10s \
 -Dfile.encoding=UTF-8 \
 -XX:+ExitOnOutOfMemoryError \
 -XX:+UseG1GC \
 -XX:+HeapDumpOnOutOfMemoryError \
 -XX:HeapDumpPath=/tmp \
 "

# Graceful termination signal
STOPSIGNAL SIGTERM

# Switch to non-root user
USER app

# --- Entry point ---
ENTRYPOINT ["sh", "-c", "exec java ${JAVA_OPTS} -jar /app/app.jar"]

Dockerfile TOP (tham khảo – Java) – HMCTS Spring Boot Template (Layered + jlink)

Kỹ thuật	Giải thích theo tác giả	Nguồn tham khảo
Gradle cache + tách layer	Dùng BuildKit cache `id=gradle-cache` cho Gradle, sau đó dùng `jarmode=layertools` để extract các lớp `dependencies`, `spring-boot-loader`, `snapshot-dependencies`, `application` giúp cache Docker layer tối đa.
Custom JRE với jlink	Chạy `jlink` với danh sách module Java chọn tay để tạo JRE tối thiểu (`/jre-minimal`), giảm hơn 100MB so với JDK full.
Alpine runtime tối thiểu	Runtime base `alpine:3.21` chỉ cài `ca-certificates`, `tzdata`, `tini`, `curl`, sau đó chạy với non-root `appuser`.
JAVA_TOOL_OPTIONS cho container	Tối ưu JVM: `UseContainerSupport`, `MaxRAMPercentage`, `UseG1GC`, `UseStringDeduplication`, `ExitOnOutOfMemoryError`,… để tối ưu memory & GC trong container.
OCI labels rất đầy đủ	Ghi rõ `vendor`, `authors`, `source`, `version`, `revision`, `base.name`, `base.digest`, `com.hmcts.*`… giúp traceability cho tổ chức.
Healthcheck dùng curl	Healthcheck `/health` qua `curl -f`, retry có cấu hình hợp lý cho Spring Boot khởi động.

Dockerfile TOP (tham khảo – JAVA) – HMCTS Spring Boot Template

 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
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137


# syntax=docker/dockerfile:1.7

# ============================================================================
# STAGE 1: Application builder with optimized caching
# ============================================================================
FROM eclipse-temurin:21-jdk-alpine@sha256:89517925fa675c6c4b770bee7c44d38a7763212741b0d6fca5a5103caab21a97 AS builder

# Install build dependencies (minimal)
RUN apk add --no-cache binutils && \
 rm -rf /var/cache/apk/*

WORKDIR /build

# Copy Gradle wrapper and dependency definition files first
# This layer will be cached until these files change
COPY gradle/ gradle/
COPY gradlew build.gradle ./

# Download dependencies with BuildKit cache mount for faster subsequent builds
RUN --mount=type=cache,id=gradle-cache,target=/root/.gradle,sharing=locked \
 chmod +x gradlew && \
 ./gradlew dependencies --no-daemon --parallel --console=plain

# Copy only production source code (exclude tests, docs, etc.)
COPY src/main/ src/main/

# Build optimized JAR with cache mount
RUN --mount=type=cache,id=gradle-cache,target=/root/.gradle,sharing=locked \
 ./gradlew bootJar --no-daemon --parallel --console=plain -x test && \
 mkdir -p /app && \
 mv build/libs/spring-boot-template.jar /app/app.jar

# Extract Spring Boot layers for optimal Docker layer caching
WORKDIR /app
RUN java -Djarmode=layertools -jar app.jar extract --destination /app/extracted

# Create minimal custom JRE with jlink (reduces size by >100MB)
# Only include Java modules actually needed by Spring Boot
RUN $JAVA_HOME/bin/jlink \
 --add-modules java.base,java.compiler,java.desktop,java.instrument,java.management,java.management.rmi,java.naming,java.net.http,java.prefs,java.rmi,java.scripting,java.security.jgss,java.security.sasl,java.sql,jdk.httpserver,jdk.jfr,jdk.unsupported \
 --strip-debug \
 --no-man-pages \
 --no-header-files \
 --compress=zip-9 \
 --output /jre-minimal

# ============================================================================
# STAGE 3: Minimal runtime image
# ============================================================================
FROM alpine:3.21@sha256:5405e8f36ce1878720f71217d664aa3dea32e5e5df11acbf07fc78ef5661465b

# Install only critical runtime dependencies
# ca-certificates: for HTTPS connections
# tini: proper init system for PID 1
# tzdata: timezone support
# curl: for healthcheck
RUN apk upgrade --no-cache && \
 apk add --no-cache \
 ca-certificates \
 tzdata \
 tini \
 curl && \
 rm -rf /var/cache/apk/* /tmp/*

# Create non-root user for security (CIS Docker Benchmark compliance)
RUN addgroup -g 1654 -S appgroup && \
 adduser -u 1654 -S appuser -G appgroup

# Copy minimal custom JRE from builder
COPY --from=builder --chown=1654:1654 /jre-minimal /opt/java

# Set up application directory with proper ownership
WORKDIR /app

# Copy Spring Boot layers in optimal order (least to most frequently changed)
# This maximizes Docker layer cache efficiency
COPY --from=builder --chown=1654:1654 /app/extracted/dependencies/ ./
COPY --from=builder --chown=1654:1654 /app/extracted/spring-boot-loader/ ./
COPY --from=builder --chown=1654:1654 /app/extracted/snapshot-dependencies/ ./
COPY --from=builder --chown=1654:1654 /app/extracted/application/ ./

# Switch to non-root user (security best practice)
USER 1654:1654

# Set JAVA_HOME and PATH
ENV JAVA_HOME=/opt/java \
 PATH="/opt/java/bin:${PATH}"

# Optimal JVM flags for containerized Spring Boot applications
# - UseContainerSupport: respect container memory limits
# - MaxRAMPercentage: use max 75% of container memory for heap
# - UseG1GC: best GC for containers with predictable pause times
# - UseStringDeduplication: reduce memory footprint
# - ExitOnOutOfMemoryError: fail fast on OOM
# - TieredCompilation with level 1: faster startup, good for short-lived containers
ENV JAVA_TOOL_OPTIONS="-XX:+UseContainerSupport \
 -XX:MaxRAMPercentage=75.0 \
 -XX:InitialRAMPercentage=50.0 \
 -XX:+UseG1GC \
 -XX:MaxGCPauseMillis=100 \
 -XX:+UseStringDeduplication \
 -XX:+ParallelRefProcEnabled \
 -XX:+DisableExplicitGC \
 -XX:+ExitOnOutOfMemoryError \
 -Djava.security.egd=file:/dev/./urandom \
 -Djava.awt.headless=true"

# Application server port
EXPOSE 8080

# Comprehensive OCI labels for traceability and compliance
LABEL org.opencontainers.image.title="Spring Boot Template" \
 org.opencontainers.image.description="HMCTS Spring Boot Template - Optimized for Contest 2025" \
 org.opencontainers.image.vendor="HMCTS Reform Programme" \
 org.opencontainers.image.authors="HMCTS <hmcts@justice.gov.uk>" \
 org.opencontainers.image.source="https://github.com/hmcts/spring-boot-template" \
 org.opencontainers.image.version="0.0.1" \
 org.opencontainers.image.revision="contest-2025" \
 org.opencontainers.image.licenses="MIT" \
 org.opencontainers.image.base.name="docker.io/library/alpine:3.21" \
 org.opencontainers.image.base.digest="sha256:5405e8f36ce1878720f71217d664aa3dea32e5e5df11acbf07fc78ef5661465b" \
 maintainer="HMCTS Reform Team" \
 com.hmcts.app.name="spring-boot-template" \
 com.hmcts.build.date="2025-10-27"

# Health check using Spring Boot Actuator /health endpoint
# Using curl for lightweight health checks
HEALTHCHECK --interval=30s --timeout=5s --start-period=60s --retries=3 \
 CMD curl -f http://localhost:8080/health || exit 1

# Use tini as init system for proper signal handling
# Ensures graceful shutdown and zombie process reaping
ENTRYPOINT ["/sbin/tini", "--"]

# Run Spring Boot application
# Using exec form to ensure proper signal propagation
CMD ["java", "org.springframework.boot.loader.launch.JarLauncher"]

Ghi chú triển khai

Khi áp dụng cho dự án Java của bạn, hãy giữ nguyên các nguyên tắc chính mà các Dockerfile trên thể hiện:
- Multi-stage build rõ ràng (builder + runtime).
- Tối ưu JRE (dùng jdeps + jlink, base image Java distroless hoặc JRE-only image).
- Healthcheck rõ ràng (native Java hoặc wget/curl).
- Tối ưu dependency (tự động hoặc thủ công) để giảm CVE.
Khi copy template về dự án riêng, bạn nên:
- Cập nhật lại LABEL org.opencontainers.image.source cho đúng repository của bạn.
- Điều chỉnh endpoint healthcheck (/health, /actuator/health…) cho trùng với app thực tế.
- Thử build và scan image với các tool như Trivy để kiểm tra security sau khi tối ưu.

Tối ưu Docker cho Python

Sun, 23 Nov 2025 00:00:00 +0000

Dockerfile Contest 2025 – Python tối ưu extreme

Dockerfile Contest 2025 thúc đẩy cộng đồng DevOps Việt Nam đánh giá lại cách viết Dockerfile để đạt bảo mật, tối ưu, tường minh. Dưới đây là phần tổng hợp riêng cho hạng mục Python (ứng dụng FastAPI backend service).

I. Hạng mục PYTHON (Tối ưu cho Backend Service)

Hạng mục Python tập trung vào việc tối ưu kích thước image, bảo mật (patch CVE), và hiệu năng runtime cho các ứng dụng FastAPI. Các giải pháp đa dạng từ distroless, Alpine tối giản, đến wheel-based builds.

Dockerfile TOP 1 (Python) – Thanh Nguyen The

Kỹ thuật	Giải thích theo tác giả	Nguồn tham khảo
UV Package Manager	Sử dụng `uv` thay vì pip để tăng tốc độ cài đặt dependencies và quản lý virtual environment hiệu quả hơn.
Distroless Base Image	Dùng `gcr.io/distroless/base-debian12:nonroot` để giảm attack surface, không có shell, package manager, hoặc các công cụ không cần thiết.
Multi-arch Support	Hỗ trợ cả amd64 và arm64 bằng cách copy shared libraries theo kiến trúc tương ứng.
Shared Libraries Copy	Copy các thư viện cần thiết (libc, libm, libz, libgcc_s) từ builder stage để ứng dụng chạy được trong distroless.
Security Patching	Nâng cấp starlette lên 0.49.1 để fix CVE-2025-62727 và CVE-2025-54121 mà không cần sửa pyproject.toml.
LD_LIBRARY_PATH	Thiết lập biến môi trường để hệ thống tìm thấy shared libraries tại thư mục tùy chỉnh.

Dockerfile TOP 1 (Python)

 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
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98


FROM ghcr.io/astral-sh/uv:python3.13-bookworm-slim@sha256:6b8ac7bb76766ffe9f6cc20f56789755d539e8d0e605d8983131227c5c8b87a1 AS builder
ENV UV_LINK_MODE=copy

ARG TARGETARCH
# Copy shared libraries đủ để chạy ứng dụng trong môi trường distroless
# Kiểm tra shared libraries cần thiết với lệnh:
# ldd $(which python3) và các thư viện khác trong virtual environment sau khi cài đặt các package cần thiết (kiểm tra trước khi build)
# Mỗi kiến trúc sẽ đặt thư viện trong các thư mục khác nhau, ví dụ: /lib/x86_64-linux-gnu/ cho amd64, /lib/aarch64-linux-gnu/ cho arm64
# do đó cần xác định kiến trúc và copy từ thư mục tương ứng. 
# TARGETARCH là built-in arg của docker buildx, tự động nhận giá trị (amd64 hoặc arm64) khi build multi-arch
# Shared libraries copy ở lệnh phía dưới là chưa đủ để chạy ứng dụng, tuy nhiên gcr.io/distroless/base-debian12 (image sử dụng làm base image cho runtime tại runtime state) đã có sẵn một số shared libraries nên chỉ cần copy những thư viện còn thiếu.
# gcr.io/distroless/base-debian12:nonroot không có shell, kiểm tra shared libraries bằng cách sử dụng gcr.io/distroless/base-debian12:debug
# gcr.io/distroless/base-debian12:debug tương tự gcr.io/distroless/base-debian12:nonroot nhưng có thêm shell để phục vụ debug.
RUN if [ "$TARGETARCH" = "amd64" ]; then \
 LIBARCH="x86_64"; \
 elif [ "$TARGETARCH" = "arm64" ]; then \
 LIBARCH="aarch64"; \
 else \
 LIBARCH="unknown"; \
 fi && \
 mkdir -p /lib/multi-arch && \
 cp /lib/${LIBARCH}-linux-gnu/libc.so.6 /lib/multi-arch/ && \
 cp /lib/${LIBARCH}-linux-gnu/libm.so.6 /lib/multi-arch/ && \
 cp /lib/${LIBARCH}-linux-gnu/libz.so.1 /lib/multi-arch/ && \
 cp /lib/${LIBARCH}-linux-gnu/libgcc_s.so.1 /lib/multi-arch/

WORKDIR /build

# Sử dụng cache để tăng tốc độ build
# Cài đặt dependencies trong uv virtual environment
# Sử dụng mount type=bind để bind các file uv.lock và pyproject.toml từ host vào container mount thay vì copy.
# --frozen để đảm bảo chỉ cài đặt đúng phiên bản dependencies trong uv.lock, không update uv.lock
# --no-install-project để không cài đặt project hiện tại (chỉ cài đặt dependencies)
# --no-dev để không cài đặt dev dependencies
# --no-editable để không cài đặt editable mode
# starlette 0.46.2 dính CVE-2025-62727 CVE-2025-54121, nâng cấp để vá lỗi bảo mật (do thay đổi pyproject.toml và file uv.lock sẽ vi phạm nội quy nên chạy lệnh install riêng)

RUN --mount=type=cache,target=/root/.cache/uv \
 --mount=type=bind,source=uv.lock,target=uv.lock \
 --mount=type=bind,source=pyproject.toml,target=pyproject.toml \
 uv sync --frozen --no-install-project --no-dev --no-editable && \
 uv pip install "starlette==0.49.1" --no-deps

# Sử dụng distroless làm base image cho runtime để đảm bảo tính bảo mật và tối ưu kích thước image
# Chọn distroless thay vì alpine vì alpine sử dụng musl libc, trong khi python và nhiều thư viện phổ biến trong python được biên dịch với glibc, dẫn đến các vấn đề tương thích.
# distroless giúp ứng dụng chạy ổn định hơn và cũng rất nhẹ.
# cc-debian12 có nhiều shared libraries cần thiết cho python và các package phổ biến hơn so với base-debian12
# tuy nhiên khi đã kiểm tra kỹ các shared libraries cần thiết (với lệnh ldd) và copy đầy đủ từ builder stage thì base-debian12 sẽ giúp tối ưu kích thước image hơn mà vẫn đảm bảo ứng dụng chạy ổn định.
FROM gcr.io/distroless/base-debian12:nonroot@sha256:10136f394cbc891efa9f20974a48843f21a6b3cbde55b1778582195d6726fa85 AS runtime

LABEL maintainer="Thanh Nguyen The"
LABEL maintainer.email="thanhnt.devops@gmail.com"
LABEL maintainer.company="VIETNAM NATIONAL CYBER SECURITY TECHNOLOGY CORPORATION"
LABEL maintainer.youtube="DevOps Mentor"
LABEL image.description="Secure, minimal Python app using UV and Distroless"

WORKDIR /app

# Copy các thư viện và python từ builder stage
COPY --from=builder /lib/multi-arch/ /lib/multi-arch/
COPY --from=builder /usr/local/lib/libpython3.13.so.1.0 /usr/local/lib/libpython3.13.so.1.0
COPY --from=builder /usr/local/lib/python3.13/ /usr/local/lib/python3.13/
COPY --from=builder /usr/local/bin/python /usr/local/bin/python3
# Copy virtual environment từ builder
COPY --from=builder --chown=nonroot:nonroot /build/.venv/ /app/.venv/

# Copy source code - chỉ copy những gì cần thiết
COPY --chown=nonroot:nonroot src/ ./src/

# Thiết lập environment variables
# Do runtime limit là 1 vCPU, 512MB RAM nên thiết lập WORKERS=2 thay vì 3 (nguy cơ OOM). Công thức worker = (2 x số lượng vCPU + 1) chỉ áp dụng trong trường hợp > 1GB RAM
# LD_LIBRARY_PATH để hệ thống có thể tìm thấy các shared libraries cần thiết tại thư mục mới thay vì thư mục mặc đinh (/lib/x86_64-linux-gnu hoặc /lib/aarch64-linux-gnu)
# shared libraries không có trong /lib/multi-arch sẽ tiếp tục được load từ thư mục mặc định của hệ thống
ENV PATH="/app/.venv/bin/:$PATH" \
 PYTHONPATH="/app/src/" \
 LANG=C.UTF-8 \
 PYTHONUNBUFFERED=1 \
 PYTHONFAULTHANDLER=1 \
 PYTHONDONTWRITEBYTECODE=1 \
 PYTHONHASHSEED=random \
 HOST=0.0.0.0 \
 PORT=8080 \
 WORKERS=2 \
 LOGGING__LEVEL=INFO \
 LOGGING__FORMAT=PLAIN \
 COFFEE_API__HOST="https://api.sampleapis.com/coffee/" \
 APP_VERSION=0.1.0 \
 GIT_COMMIT_SHA=sha \
 LD_LIBRARY_PATH=/lib/multi-arch

# nonroot user mặc định đã được sử dụng trong distroless base-debian12:nonroot nên không cần thiết phải thêm lệnh phía dưới
# USER nonroot:nonroot

# Expose port mặc định
EXPOSE 8080

# Command để chạy ứng dụng
ENTRYPOINT ["python", "src/python_service_template/app.py"]

Dockerfile TOP 2 (Python) – newnol

Kỹ thuật	Giải thích theo tác giả	Nguồn tham khảo
Alpine Base Image	Sử dụng `python:3.13-alpine` để có image nhỏ hơn so với Debian-based images.
Security Patches	Cập nhật các package có CVE: starlette, fastapi, aiohttp, pydantic, structlog, uvloop, uvicorn lên phiên bản an toàn.
Ultra Aggressive Optimization	Strip tất cả `.so` files, xóa `__pycache__`, test, doc, examples, typing stubs, license files để giảm kích thước.
Python Stdlib Cleanup	Xóa các module không cần thiết như pip, setuptools, wheel, tkinter, distutils, lib2to3, idlelib, test, unittest.
Non-root User	Tạo user UID 10001 với quyền tối thiểu để tăng bảo mật.
Healthcheck	Sử dụng wget để kiểm tra endpoint `/health/` với timeout ngắn.

Dockerfile TOP 2 (Python)

 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
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128


# syntax=docker/dockerfile:1.7

# =============================================================================
# DOCKERFILE ULTRA OPTIMIZED + SECURITY PATCHED
# Mục tiêu: Nhẹ (<110MB) + Bảo mật cao (0 CVEs)
# =============================================================================

# -----------------------------------------------------------------------------
# Stage 1: Dependencies Builder
# -----------------------------------------------------------------------------
FROM python:3.13-alpine@sha256:e5fa639e49b85986c4481e28faa2564b45aa8021413f31026c3856e5911618b1 AS deps

ENV PIP_NO_CACHE_DIR=1 \
 PIP_DISABLE_PIP_VERSION_CHECK=1 \
 PYTHONDONTWRITEBYTECODE=1 \
 PYTHONUNBUFFERED=1

RUN --mount=type=cache,target=/var/cache/apk \
 apk add --no-cache --virtual .build-deps \
 build-base \
 python3-dev \
 cargo

# Install dependencies với PATCHED versions để fix CVEs
# Note: FastAPI 0.116+ required for starlette 0.49.1+ support
RUN --mount=type=cache,target=/root/.cache/pip \
 python -m pip install --no-cache-dir --prefix=/install \
 "aiohttp>=3.12.14,<4.0.0" \
 "asgi-correlation-id>=4.3.4,<5.0.0" \
 "fastapi>=0.116.0" \
 "prometheus-fastapi-instrumentator>=7.0.0,<8.0.0" \
 "pydantic>=2.11.0,<3.0.0" \
 "pydantic-settings>=2.9.1,<3.0.0" \
 "structlog>=25.3.0,<26.0.0" \
 "uvloop>=0.21.0,<0.22.0" \
 "uvicorn[standard]>=0.30.0,<0.31.0"

# ULTRA AGGRESSIVE optimization
RUN apk add --no-cache binutils \
 # Strip ALL .so files aggressively
 && find /install -type f \( -name '*.so*' -o -name '*.a' \) -exec strip --strip-all {} + 2>/dev/null || true \
 # Remove all bytecode
 && find /install \( -type d -name __pycache__ -o -type f -name '*.py[co]' \) -delete 2>/dev/null || true \
 # Remove test/doc/examples
 && find /install -type d \( -name tests -o -name testing -o -name test -o -name doc -o -name docs -o -name example -o -name examples \) -prune -exec rm -rf {} + 2>/dev/null || true \
 # Minimize .dist-info
 && find /install -name '*.dist-info' -type d -exec sh -c 'cd "$1" && find . -type f ! -name "METADATA" ! -name "top_level.txt" ! -name "RECORD" -delete' _ {} \; 2>/dev/null || true \
 # Remove typing stubs, headers, C files
 && find /install -type f \( -name '*.pyi' -o -name '*.c' -o -name '*.h' -o -name '*.cpp' -o -name '*.cc' \) -delete \
 # Remove license files
 && find /install -type f \( -name 'LICENSE*' -o -name 'COPYING*' -o -name 'NOTICE*' -o -name 'AUTHORS*' -o -name 'CHANGELOG*' -o -name 'README*' \) -delete 2>/dev/null || true \
 && apk del binutils .build-deps

# -----------------------------------------------------------------------------
# Stage 2: Runtime (ULTRA MINIMAL + SECURE)
# -----------------------------------------------------------------------------
FROM python:3.13-alpine@sha256:e5fa639e49b85986c4481e28faa2564b45aa8021413f31026c3856e5911618b1 AS runtime

LABEL org.opencontainers.image.title="Python Service Template" \
 org.opencontainers.image.description="Production-ready FastAPI service - Optimized & Secured" \
 org.opencontainers.image.version="0.1.0" \
 org.opencontainers.image.authors="newnol <contact@newnol.io.vn>" \
 maintainer="newnol" \
 security.scan="trivy-passed"

ENV PYTHONDONTWRITEBYTECODE=1 \
 PYTHONUNBUFFERED=1 \
 PIP_NO_CACHE_DIR=1 \
 HOST=0.0.0.0 \
 PORT=5000 \
 WORKERS=1 \
 PYTHONPATH=/app/src \
 TZ=UTC

# Install ONLY wget for healthcheck
RUN --mount=type=cache,target=/var/cache/apk \
 apk add --no-cache wget

WORKDIR /app

# Create non-root user
RUN addgroup -g 10001 -S app \
 && adduser -u 10001 -S -G app -h /app -s /sbin/nologin app

# Copy dependencies
COPY --from=deps --chown=app:app /install /usr/local

# Copy source (minimal)
COPY --chown=app:app src/ ./src/

# Permissions
RUN chmod -R 550 /app

# EXTREME Python stdlib cleanup
RUN rm -rf \
 /usr/local/lib/python3.13/ensurepip \
 /usr/local/lib/python3.13/site-packages/pip* \
 /usr/local/lib/python3.13/site-packages/setuptools* \
 /usr/local/lib/python3.13/site-packages/wheel* \
 /usr/local/lib/python3.13/distutils \
 /usr/local/lib/python3.13/lib2to3 \
 /usr/local/lib/python3.13/idlelib \
 /usr/local/lib/python3.13/tkinter \
 /usr/local/lib/python3.13/turtledemo \
 /usr/local/lib/python3.13/test \
 /usr/local/lib/python3.13/unittest/test \
 /usr/local/bin/pip* \
 /usr/local/bin/2to3* \
 /usr/local/bin/idle* \
 2>/dev/null || true

# Clean up more unused stdlib modules
RUN cd /usr/local/lib/python3.13 && rm -rf \
 turtle.py \
 pydoc_data \
 2>/dev/null || true

USER app

EXPOSE 5000

# Heathcheck 
HEALTHCHECK --interval=15s --timeout=3s --start-period=10s --retries=2 \
 CMD wget --no-verbose --tries=1 -O /dev/null http://127.0.0.1:${PORT}/health/ || exit 1

STOPSIGNAL SIGTERM

CMD ["python", "src/python_service_template/app.py"]

Dockerfile TOP (Python) – Wheel-based Build

Kỹ thuật	Giải thích	Nguồn tham khảo
Wheel-based Installation	Build tất cả dependencies thành wheel files, sau đó cài đặt offline để tăng tốc độ build và đảm bảo reproducibility.
Dynamic Security Patching	Sử dụng Python script để parse `pyproject.toml`, tự động nâng cấp fastapi và starlette lên phiên bản an toàn mà không cần sửa file gốc.
PIP_ONLY_BINARY	Chỉ sử dụng wheel files, không build từ source, giúp build nhanh hơn và tránh lỗi compilation.
Offline Installation	Cài đặt từ wheel files local, không cần kết nối internet ở runtime stage.
Native Healthcheck	Sử dụng Python `http.client` thay vì external tools như curl/wget, giảm dependencies.
Non-root User	Tạo user UID 10001 với home directory riêng để tăng bảo mật.

Dockerfile TOP (Python)

 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
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102


# syntax=docker/dockerfile:1.7
#
##############################
# builder
##############################
FROM python:3.13-slim AS builder

ENV PIP_DISABLE_PIP_VERSION_CHECK=1 \
 PIP_NO_CACHE_DIR=1 \
 PIP_ONLY_BINARY=:all: \
 PYTHONDONTWRITEBYTECODE=1 \
 PYTHONUNBUFFERED=1

WORKDIR /app

# Pre-cache manifests
COPY pyproject.toml README.md LICENSE* ./

# Fix HIGH vulnerable issue: CVE-2025-62727 by upgrading starlette and fastapi.
RUN --mount=type=cache,target=/root/.cache/pip python - <<'PY'
import tomllib, pathlib, re
def parse_req(s:str):
 m = re.match(r'^\s*([A-Za-z0-9_.-]+)(\[[^\]]+\])?\s*(.*)$', s)
 if m:
 name, extras, rest = m.group(1), (m.group(2) or ''), (m.group(3) or '')
 return name, extras, rest
 name = re.split(r'[><=~!; ]', s, 1)[0]
 return name, '', s[len(name):]

data = tomllib.loads(pathlib.Path('pyproject.toml').read_text())
deps = data.get('project', {}).get('dependencies', [])
safe = []
present = set()
for d in deps:
 name, extras, rest = parse_req(d)
 norm = name.lower().replace('_','-')
 if norm == 'fastapi':
 safe.append(f'fastapi{extras}>=0.118,<0.121')
 else:
 safe.append(d)
 present.add(norm)
if 'starlette' not in present:
 safe.append('starlette>=0.49.1,<0.50')
pathlib.Path('/requirements.safe.txt').write_text('\n'.join(safe) + '\n')
print('Resolved safe deps:', *safe, sep='\n- ')
PY

# Wheel ALL dependencies from the safe list
RUN --mount=type=cache,target=/root/.cache/pip \
 pip wheel --wheel-dir /wheels -r /requirements.safe.txt

# Build wheel of the project itself
COPY src/ ./src/
RUN --mount=type=cache,target=/root/.cache/pip \
 pip wheel --wheel-dir /wheels .


##############################
# runtime
##############################
FROM python:3.13-slim AS runtime

ARG VERSION=0.1.0
ARG VCS_REF=sha
ARG BUILD_DATE

LABEL org.opencontainers.image.title="python-service-template" \
 org.opencontainers.image.description="Dockerfile contest build" \
 org.opencontainers.image.version=$VERSION \
 org.opencontainers.image.revision=$VCS_REF \
 org.opencontainers.image.created=$BUILD_DATE \
 org.opencontainers.image.licenses="Apache-2.0"

ENV PYTHONDONTWRITEBYTECODE=1 \
 PYTHONUNBUFFERED=1 \
 PYTHONOPTIMIZE=2 \
 HOST=0.0.0.0 \
 PORT=5000 \
 WORKERS=1 \
 APP_VERSION=$VERSION \
 GIT_COMMIT_SHA=$VCS_REF

# Non-root
RUN useradd --create-home --uid 10001 --shell /usr/sbin/nologin appuser
WORKDIR /home/appuser

# Install offline: install ALL safe deps, then the app wheel with --no-deps
COPY --from=builder /wheels /wheels
COPY --from=builder /requirements.safe.txt /requirements.safe.txt
RUN pip install --no-index --find-links=/wheels -r /requirements.safe.txt \
 && pip install --no-index --find-links=/wheels --no-deps \
 python-service-template --no-compile \
 && rm -rf /wheels /requirements.safe.txt

EXPOSE 5000

HEALTHCHECK --interval=30s --timeout=2s --start-period=10s --retries=3 \
 CMD python -c "import sys, http.client; c=http.client.HTTPConnection('127.0.0.1', int(__import__('os').environ.get('PORT','5000')), timeout=1); c.request('GET','/health'); r=c.getresponse(); sys.exit(0 if r.status==200 else 1)" || exit 1

USER 10001:10001

CMD ["python", "-m", "python_service_template.app"]

Dockerfile TOP (Python) – Khiem Doan

Kỹ thuật	Giải thích	Nguồn tham khảo
UV Package Manager	Sử dụng `uv` để quản lý dependencies nhanh hơn pip, với cache mount để tăng tốc rebuild.
Alpine + Tini	Sử dụng Alpine Linux nhẹ và tini làm init system để xử lý signals đúng cách.
Security Patching	Nâng cấp starlette lên 0.50.0 để fix các CVE mà không cần sửa pyproject.toml.
Non-root User	Tạo user nonroot với UID/GID 14406, một UID không phổ biến để tránh conflict.
Healthcheck với curl	Sử dụng curl để kiểm tra health endpoint và grep để verify response JSON.
OCI Labels	Thêm đầy đủ OCI labels với metadata về version, build date, revision, source.

Dockerfile TOP (Python)

 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
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75


# syntax=docker/dockerfile:1.19

FROM python:3.13-alpine3.22 AS deps

RUN --mount=type=cache,target=/root/.cache/pip \
 pip install --no-compile uv==0.9.2

WORKDIR /app

COPY pyproject.toml uv.lock ./

RUN --mount=type=cache,target=/root/.cache/uv \
 uv sync --frozen --no-dev --no-install-project \
 && uv pip install starlette==0.50.0

FROM python:3.13-alpine3.22 AS final

RUN pip install -U pip

RUN --mount=type=cache,target=/var/cache/apk \
 apk add --no-cache \
 curl=8.14.1-r2 \
 tini=0.19.0-r3

ARG VERSION="0.1.0"
ARG BUILD_DATE="2025-11-10T00:00:00Z"
ARG REVISION="unknown"
ARG GIT_COMMIT_SHA="unknown"

LABEL org.opencontainers.image.title="python-service-template" \
 org.opencontainers.image.description="A batteries-included template for building robust, production-ready Python backend services with FastAPI" \
 org.opencontainers.image.authors="Khiem Doan" \
 org.opencontainers.image.version=$VERSION \
 org.opencontainers.image.created=$BUILD_DATE \
 org.opencontainers.image.revision=$REVISION \
 org.opencontainers.image.source="https://github.com/khiemdoan/" \
 org.opencontainers.image.licenses="MIT"

ENV USER=nonroot \
 GROUP=nonroot \
 UID=14406 \
 GID=14406

RUN addgroup -g "$GID" "$GROUP" \
 && adduser -D -u "$UID" -G "$GROUP" "$USER"

USER $USER

WORKDIR /app

COPY --chown=$USER:$GROUP src/ src/

COPY --from=deps --chown=$USER:$GROUP /app/.venv /app/.venv

ENV PATH="/app/.venv/bin:$PATH" \
 PYTHONPATH="/app/src" \
 PYTHONUNBUFFERED=1 \
 PYTHONDONTWRITEBYTECODE=1 \
 HOST=0.0.0.0 \
 PORT=3000 \
 WORKERS=1 \
 LOGGING__LEVEL=INFO \
 LOGGING__FORMAT=PLAIN \
 COFFEE_API__HOST=https://api.sampleapis.com/coffee/ \
 APP_VERSION=$VERSION \
 GIT_COMMIT_SHA=$GIT_COMMIT_SHA

EXPOSE $PORT

HEALTHCHECK --timeout=1s \
 CMD curl -f "http://localhost:${PORT}/health/" | grep '"heartbeat":"HEALTHY"' || exit 1

ENTRYPOINT ["/sbin/tini", "--"]

CMD ["python", "src/python_service_template/app.py"]

Ghi chú triển khai

Các Dockerfile trên chỉ mang tính tham khảo kiến trúc; khi áp dụng vào dự án Python/FastAPI của bạn, hãy giữ nguyên nguyên tắc: multi-stage build, security patching, non-root user, pin SHA256 cho base images.
Distroless vs Alpine: Distroless an toàn hơn (không có shell, package manager) nhưng cần copy shared libraries thủ công. Alpine nhẹ và dễ debug hơn nhưng có thể gặp vấn đề tương thích với một số Python packages.
UV vs PIP: UV nhanh hơn pip đáng kể (10-100x) và quản lý virtual environment tốt hơn, nhưng cần cài đặt thêm.
Security: Luôn cập nhật dependencies để fix CVE, đặc biệt là các package phổ biến như starlette, fastapi, uvicorn.
Healthcheck: Nên sử dụng native Python http.client hoặc curl/wget tùy vào base image và yêu cầu bảo mật.

Tối ưu Docker cho Node.js

Tue, 18 Nov 2025 00:00:00 +0000

Dockerfile Contest 2025 – React/Node tối ưu extreme

Dockerfile Contest 2025 thúc đẩy cộng đồng DevOps Việt Nam đánh giá lại cách viết Dockerfile để đạt bảo mật, tối ưu, tường minh. Dưới đây là phần tổng hợp riêng cho hạng mục React (ứng dụng Node.js build ra static assets).

I. Hạng mục REACT (Tối ưu cho Static Web Serving)

Hạng mục React tập trung giảm kích thước image và tăng tốc phục vụ file tĩnh. Một số đội ngũ tự biên dịch HTTP server hoặc chạy trên FROM scratch nhằm đạt footprint thấp nhất.

Giải Docker Image nhẹ nhất (TOP Tinh Gọn) – Nguyễn Phúc Bảo Lâm

Kỹ thuật	Giải thích theo tác giả	Nguồn tham khảo
Lựa chọn Project	Tận dụng lợi thế app static (React) để dễ đạt image nhỏ hơn so với Java/Python.
Base Image Cực Đoan	Dùng `lipanski/docker-static-website:latest`, bản BusyBox được tinh gọn chỉ giữ HTTP server (~92 KB).
Pre-compression Nén Tối Đa	Nén trước toàn bộ asset với Gzip level 9, xóa file gốc, giúp image cuối cùng ~300 KB.
Healthcheck	Ghi `"OK"` vào `dist/health` để có endpoint kiểm tra nhanh.

Dockerfile – Docker Image nhẹ nhất

 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
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116



# syntax=docker/dockerfile:1.7

# ==============================================================================

# Build Stage - Using Node Alpine for minimal size

# ==============================================================================

FROM node:22.21.1-alpine3.21@sha256:af8023ec879993821f6d5b21382ed915622a1b0f1cc03dbeb6804afaf01f8885 AS builder

# Install pnpm with specific version from package.json and gzip for pre-compression

ENV PNPM_HOME="/pnpm"

ENV PATH="$PNPM_HOME:$PATH"

RUN corepack enable && \

 corepack prepare pnpm --activate

WORKDIR /app

# Copy package files for dependency installation (optimized layer caching)

COPY package.json pnpm-lock.yaml ./

# Install dependencies with cache mount for faster rebuilds

# Installs all dependencies (including devDependencies needed for build: typescript, vite, tailwindcss, etc.)

RUN --mount=type=cache,id=pnpm,target=/pnpm/store \

 pnpm install --frozen-lockfile

# Copy only necessary source files (exclude tests, docs, config files not needed for build)

COPY tsconfig.json tsconfig.node.json vite.config.ts tailwind.config.ts postcss.config.js ./

COPY index.html ./

COPY public ./public

COPY src ./src

# Build the application

RUN pnpm run build && \

 # Verify build output exists

 test -d dist && test -f dist/index.html && \

 # Remove bundle visualizer output (not needed in production, saves ~100KB compressed)

 rm -f dist/stats.html && \

 # Create a minimal health check endpoint (1 byte file for ultra-fast response)

 echo "OK" > dist/health && \

 # Pre-compress all static files with gzip (level 9 = maximum compression)

 find dist -type f \( \

 -name "*.html" -o \

 -name "*.css" -o \

 -name "*.js" -o \

 -name "*.json" -o \

 -name "*.xml" -o \

 -name "*.txt" -o \

 -name "*.svg" \

 \) -exec sh -c 'gzip -9 "{}"' \;

# ==============================================================================

# Production Stage - Using lipanski/docker-static-website for extreme minimal footprint (92.5 KB base)

# ==============================================================================

FROM lipanski/docker-static-website:latest AS production

# Add OCI labels for metadata

LABEL org.opencontainers.image.title="Vite React Template" \

 org.opencontainers.image.description="Production-ready Vite React application with extreme minimal footprint" \

 org.opencontainers.image.version="0.4.0" \

 org.opencontainers.image.licenses="MIT OR Apache-2.0" \

 org.opencontainers.image.base.name="lipanski/docker-static-website:latest"

# Copy built assets from builder stage

# lipanski/docker-static-website serves from /home/static

COPY --from=builder /app/dist /home/static

# Expose port (BusyBox httpd uses port 3000 by default)

EXPOSE 3000

# The base image already has CMD set to run BusyBox httpd

# It automatically serves .gz files when Accept-Encoding: gzip is present

# No additional configuration needed - inherited from base image

Dockerfile TOP 1 (React) – Nguyễn Hữu Phương

Kỹ thuật	Giải thích theo tác giả	Nguồn tham khảo
FROM SCRATCH & Static Linking	Stage cuối `scratch`, nên Nginx phải build tĩnh ở Stage 2.
Tối ưu Binary Nginx	Tắt >30 module, giảm binary ~76% (5.2 MB).
Nén Binary (UPX)	Dùng `upx --best --lzma`, giảm thêm ~56%.
Nén Song Song	Chạy Gzip và Brotli song song để chuyển tải CPU sang build-time.
Bảo mật Image Base	Pin SHA256 cho mọi base image.
Healthcheck tối giản	Dùng `nginx -t -q`, không cần curl/wget.

Dockerfile TOP 1 (React)

 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
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448



# syntax=docker/dockerfile:1.7

# Multi-arch support: Automatically provided by buildx

ARG BUILDPLATFORM

ARG TARGETPLATFORM

ARG TARGETARCH

ARG BUILD_DATE

ARG GIT_COMMIT=unknown

ARG NGINX_VERSION=1.26.2

ARG NODE_VERSION=20

ARG ALPINE_VERSION=3.20

# ==============================================================================

# Stage 1: Application Build

# ==============================================================================

FROM node:${NODE_VERSION}-alpine@sha256:2d5e8a8a51bc341fd5f2eed6d91455c3a3d147e91a14298fc564b5dc519c1666 AS builder

WORKDIR /app

# Setup pnpm with corepack

ENV PNPM_HOME="/pnpm" \

 PATH="$PNPM_HOME:$PATH"

RUN corepack enable && corepack prepare pnpm@9.12.2 --activate

# Install dependencies with cache mount

COPY package.json pnpm-lock.yaml .npmrc ./

RUN --mount=type=cache,id=pnpm,target=/pnpm/store \

 pnpm install --frozen-lockfile --prefer-offline

# Copy source and build configuration

COPY tsconfig.json tsconfig.node.json vite.config.ts ./

COPY postcss.config.js tailwind.config.ts biome.json ./

COPY index.html ./

COPY public ./public

COPY src ./src

# Build and clean artifacts

ENV NODE_ENV=production

RUN pnpm build && \

 find dist -type f \( -name "*.map" -o -name ".*" \) -delete && \

 rm -f dist/stats.html

# ==============================================================================

# Stage 2: Static Nginx Binary Builder

# ==============================================================================

FROM alpine:${ALPINE_VERSION}@sha256:765942a4039992336de8dd5db680586e1a206607dd06170ff0a37267a9e01958 AS nginx-builder

ARG NGINX_VERSION

ARG TARGETPLATFORM

ARG BUILDPLATFORM

ENV NGINX_SHA256=627fe086209bba80a2853a0add9d958d7ebbdffa1a8467a5784c9a6b4f03d738

# Log build platform info for multi-arch

RUN echo "Building on $BUILDPLATFORM for $TARGETPLATFORM"

# Install build dependencies

RUN apk add --no-cache \

 gcc g++ musl-dev make linux-headers curl \

 pcre-dev pcre2-dev zlib-dev zlib-static \

 openssl-dev openssl-libs-static upx

# Download and verify nginx

WORKDIR /tmp

RUN curl -fSL "https://nginx.org/download/nginx-${NGINX_VERSION}.tar.gz" -o nginx.tar.gz && \

 echo "${NGINX_SHA256} nginx.tar.gz" | sha256sum -c -

# Build fully static nginx with minimal modules

RUN tar -xzf nginx.tar.gz && \

 cd "nginx-${NGINX_VERSION}" && \

 ./configure \

 --prefix=/usr/local/nginx \

 --sbin-path=/usr/local/nginx/sbin/nginx \

 --conf-path=/etc/nginx/nginx.conf \

 --pid-path=/run/nginx.pid \

 --lock-path=/run/nginx.lock \

 --error-log-path=/dev/stderr \

 --http-log-path=/dev/stdout \

 --user=nobody \

 --group=nobody \

 # Performance features

 --with-threads \

 --with-file-aio \

 --with-http_ssl_module \

 --with-http_v2_module \

 --with-http_gzip_static_module \

 --with-http_stub_status_module \

 --with-pcre \

 --with-pcre-jit \

 # Static linking and optimization

 --with-cc-opt='-static -Os -ffunction-sections -fdata-sections' \

 --with-ld-opt='-static -Wl,--gc-sections' \

 # Disable unnecessary modules

 --without-http_charset_module \

 --without-http_ssi_module \

 --without-http_userid_module \

 --without-http_auth_basic_module \

 --without-http_mirror_module \

 --without-http_autoindex_module \

 --without-http_geo_module \

 --without-http_map_module \

 --without-http_split_clients_module \

 --without-http_referer_module \

 --without-http_rewrite_module \

 --without-http_proxy_module \

 --without-http_fastcgi_module \

 --without-http_uwsgi_module \

 --without-http_scgi_module \

 --without-http_grpc_module \

 --without-http_memcached_module \

 --without-http_limit_conn_module \

 --without-http_limit_req_module \

 --without-http_empty_gif_module \

 --without-http_browser_module \

 --without-http_upstream_hash_module \

 --without-http_upstream_ip_hash_module \

 --without-http_upstream_least_conn_module \

 --without-http_upstream_random_module \

 --without-http_upstream_keepalive_module \

 --without-http_upstream_zone_module \

 --without-mail_pop3_module \

 --without-mail_imap_module \

 --without-mail_smtp_module \

 --without-stream_limit_conn_module \

 --without-stream_access_module \

 --without-stream_geo_module \

 --without-stream_map_module \

 --without-stream_split_clients_module \

 --without-stream_return_module \

 --without-stream_set_module \

 --without-stream_upstream_hash_module \

 --without-stream_upstream_least_conn_module \

 --without-stream_upstream_random_module \

 --without-stream_upstream_zone_module && \

 make -j"$(nproc)" && \

 make install

# Optimize binary: strip symbols + UPX compression

RUN strip --strip-all /usr/local/nginx/sbin/nginx && \

 upx --best --lzma /usr/local/nginx/sbin/nginx && \

 /usr/local/nginx/sbin/nginx -V

# ==============================================================================

# Stage 3: Asset Compression

# ==============================================================================

FROM alpine:${ALPINE_VERSION}@sha256:765942a4039992336de8dd5db680586e1a206607dd06170ff0a37267a9e01958 AS compressor

RUN apk add --no-cache brotli gzip findutils

WORKDIR /app

COPY --from=builder /app/dist ./dist

# Parallel compression: gzip + brotli for all text-based assets

RUN find dist -type f \

 \( -name "*.html" -o -name "*.css" -o -name "*.js" -o \

 -name "*.json" -o -name "*.svg" -o -name "*.xml" \) \

 -print0 | xargs -0 -P"$(nproc)" -I {} sh -c 'gzip -9 -k -f "{}" && brotli -q 11 -f "{}"'

# ==============================================================================

# Stage 4: Minimal Filesystem Preparation

# ==============================================================================

FROM alpine:${ALPINE_VERSION}@sha256:765942a4039992336de8dd5db680586e1a206607dd06170ff0a37267a9e01958 AS rootfs

# Create directory structure

RUN mkdir -p \

 /rootfs/etc/nginx/conf.d \

 /rootfs/usr/share/nginx/html \

 /rootfs/var/log/nginx \

 /rootfs/var/cache/nginx \

 /rootfs/usr/local/nginx/{client_body,proxy,fastcgi,uwsgi,scgi}_temp \

 /rootfs/tmp \

 /rootfs/run && \

 chmod 1777 /rootfs/tmp

# Create minimal user database (nobody user)

RUN echo "nobody:x:65534:65534:nobody:/:/sbin/nologin" > /rootfs/etc/passwd && \

 echo "nobody:x:65534:" > /rootfs/etc/group

# Copy nginx configuration

COPY nginx.conf /rootfs/etc/nginx/conf.d/default.conf

COPY --from=nginx-builder /etc/nginx/mime.types /rootfs/etc/nginx/mime.types

COPY --from=compressor /app/dist /rootfs/usr/share/nginx/html

# Create main nginx.conf

RUN cat > /rootfs/etc/nginx/nginx.conf <<'EOF'

worker_processes auto;

error_log stderr warn;

pid /run/nginx.pid;

events {

 worker_connections 1024;

 use epoll;

 multi_accept on;

}

http {

 include /etc/nginx/mime.types;

 default_type application/octet-stream;

 access_log /dev/stdout;

 # Performance optimizations

 sendfile on;

 tcp_nopush on;

 tcp_nodelay on;

 keepalive_timeout 65;

 server_tokens off;

 # Compression

 gzip on;

 gzip_static on;

 gzip_vary on;

 gzip_types text/plain text/css application/json application/javascript text/xml application/xml image/svg+xml;

 include /etc/nginx/conf.d/*.conf;

}

EOF

# Set proper ownership

RUN chown -R 65534:65534 \

 /rootfs/usr/share/nginx/html \

 /rootfs/var/log/nginx \

 /rootfs/var/cache/nginx \

 /rootfs/usr/local/nginx \

 /rootfs/tmp \

 /rootfs/run

# ==============================================================================

# Stage 5: Final Distroless Image (FROM SCRATCH)

# ==============================================================================

FROM scratch

# Re-declare build args for metadata

ARG BUILD_DATE

ARG GIT_COMMIT=unknown

# OCI metadata labels

LABEL org.opencontainers.image.title="Vite React - Distroless" \

 org.opencontainers.image.description="Distroless minimal image (<6MB) - UPX compressed" \

 org.opencontainers.image.version="2.2.0-distroless-upx" \

 org.opencontainers.image.created="${BUILD_DATE}" \

 org.opencontainers.image.revision="${GIT_COMMIT}" \

 org.opencontainers.image.base.name="scratch" \

 org.opencontainers.image.source="https://github.com/riipandi/vite-react-template" \

 org.opencontainers.image.licenses="MIT OR Apache-2.0" \

 maintainer="contest-2025-optimized"

# Copy static nginx binary and minimal filesystem

COPY --from=nginx-builder /usr/local/nginx/sbin/nginx /usr/sbin/nginx

COPY --from=rootfs /rootfs /

# Run as non-root user (nobody = 65534)

USER 65534:65534

EXPOSE 3000

# Lightweight healthcheck using nginx config test

HEALTHCHECK --interval=30s --timeout=3s --start-period=5s --retries=3 \

 CMD ["/usr/sbin/nginx", "-t", "-q"]

STOPSIGNAL SIGTERM

ENTRYPOINT ["/usr/sbin/nginx"]

CMD ["-g", "daemon off;"]

Dockerfile TOP 2 (React) – Trần Quốc Toàn

Kỹ thuật	Giải thích theo tác giả	Nguồn tham khảo
Healthcheck Native C	Viết chương trình C mở socket đến cổng 3000, trả về exit code 0/1.
Thu thập Shared Library	Dùng `ldd` để copy đúng thư viện cần cho Nginx khi chạy trong `scratch`.
Cấu hình Nginx tối giản	Tắt `http_rewrite`, `http_proxy`, `mail_*`… vì chỉ phục vụ static.
Non-root User	Tạo user UID 101 chạy trong image để tăng bảo mật.

Dockerfile TOP 2 (React)

 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
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268



# STAGE 1: The Builder (Custom Nginx Build) 

FROM alpine:3.19 AS builder

# Multi-arch support

ARG TARGETARCH

RUN apk add --no-cache build-base pcre2-dev zlib-dev openssl-dev

# Download and verify Nginx source with SHA256 checksum

ARG NGINX_VERSION=1.27.0

ARG NGINX_SHA256=b7230e3cf87eaa2d4b0bc56aadc920a960c7873b9991a1b66ffcc08fc650129c

ADD --checksum=sha256:${NGINX_SHA256} https://nginx.org/download/nginx-${NGINX_VERSION}.tar.gz /tmp/

RUN tar -xzf /tmp/nginx-${NGINX_VERSION}.tar.gz -C /tmp

# Configure Nginx with minimal modules (static file serving only)

RUN cd /tmp/nginx-${NGINX_VERSION} && \

 ./configure \

 --prefix=/etc/nginx \

 --sbin-path=/usr/sbin/nginx \

 --conf-path=/etc/nginx/nginx.conf \

 --pid-path=/var/run/nginx.pid \

 --error-log-path=/dev/stderr \

 --http-log-path=/dev/stdout \

 --user=nginx \

 --group=nginx \

 --without-http_rewrite_module \

 --without-http_gzip_module \

 --without-http_proxy_module \

 --without-http_fastcgi_module \

 --without-http_uwsgi_module \

 --without-http_scgi_module \

 --without-mail_pop3_module \

 --without-mail_imap_module \

 --without-mail_smtp_module && \

 make && \

 make install && rm -rf /tmp/* && strip /usr/sbin/nginx

# Create file Nginx main config (include snippet file)

RUN { \

 mkdir -p /etc/nginx/conf.d && \

 cat > /etc/nginx/nginx.conf; \

 } <<EOF

events {

 worker_connections 1024;

}

http {

 include /etc/nginx/mime.types;

 client_body_temp_path /var/cache/nginx/client_body_temp;

 include /etc/nginx/conf.d/default.conf;

}

EOF

RUN mkdir -p /etc/nginx/conf.d && \

 cat > /etc/nginx/mime.types <<'EOF'

types {

 text/html html;

 text/css css;

 application/javascript js;

 image/png png;

 application/json json;

}

EOF

# Create minimal user/group files (no full /etc/passwd needed in scratch image)

RUN echo "nginx:x:101:101:nginx:/var/cache/nginx:/sbin/nologin" > /etc/passwd && \

 echo "nginx:x:101:" > /etc/group

# Build static healthcheck binary (no external dependencies like wget/curl needed)

RUN { \

 cat > /tmp/healthcheck.c && \

 gcc -static -O2 -o /healthcheck /tmp/healthcheck.c; \

 } <<EOF

#include <netdb.h>

#include <unistd.h>

#include <sys/socket.h>

#include <netinet/in.h>

int main() {

 struct hostent *h = gethostbyname("localhost");

 if (!h) return 1;

 int sock = socket(AF_INET, SOCK_STREAM, 0);

 if (sock < 0) return 1;

 struct sockaddr_in addr;

 addr.sin_family = AF_INET;

 addr.sin_port = htons(3000);

 addr.sin_addr = *(struct in_addr *)h->h_addr_list[0];

 int result = connect(sock, (struct sockaddr *)&addr, sizeof(addr));

 close(sock);

 return (result == 0) ? 0 : 1;

}

EOF

# Collect shared libraries required by Nginx (supports multi-arch)

RUN mkdir -p /staging/lib /staging/usr/lib && \

 ldd /usr/sbin/nginx | tr -s '[:space:]' '\n' | grep '^/' | \

 xargs -I '{}' sh -c 'mkdir -p /staging$(dirname {}) && cp -L {} /staging$(dirname {})'

# Create mount point directories for tmpfs (writable dirs in read-only container)

RUN mkdir -p /var/cache/nginx /var/run /tmp && chown -R 101:101 /var/cache/nginx /var/run /tmp

# STAGE 2: App Builder (Build React App) 

FROM node:20.11.0-alpine3.19 AS app_builder

WORKDIR /app

RUN corepack enable && corepack prepare pnpm@9.12.2 --activate

# Copy dependencies files first for caching

COPY package.json pnpm-lock.yaml ./

RUN --mount=type=cache,target=/root/.local/share/pnpm/store,sharing=locked \

 pnpm install --frozen-lockfile --prefer-offline

# Copy config files

COPY tsconfig.json tsconfig.node.json vite.config.ts ./

COPY postcss.config.js tailwind.config.ts index.html ./

# Copy source code (avoid copying tests, stories, etc.)

COPY public/ ./public/

COPY src/ ./src/

RUN pnpm build && \

 test -f dist/index.html || (echo "Build failed" && exit 1)

# STAGE 3: Production Image (FROM scratch) 

FROM scratch

LABEL org.opencontainers.image.title="Vite React Template" \

 org.opencontainers.image.description="Minimal Vite React SPA with custom Nginx built from scratch" \

 org.opencontainers.image.version="1.0.0" \

 org.opencontainers.image.licenses="MIT" \

 org.opencontainers.image.base.name="scratch" \

 org.opencontainers.image.authors="Contest 2025"

# Copy file user/group

COPY --from=builder /etc/passwd /etc/group /etc/

# Copy mount points to image

COPY --chown=101:101 --from=builder /var/cache/nginx /var/cache/nginx

COPY --chown=101:101 --from=builder /var/run /var/run

COPY --chown=101:101 --from=builder /tmp /tmp

# Copy Nginx and shared libraries

COPY --from=builder /usr/sbin/nginx /usr/sbin/nginx

COPY --from=builder /staging/ /

# Copy main Nginx config (just created)

COPY --from=builder /etc/nginx/nginx.conf /etc/nginx/nginx.conf

# Copy file config from project into included location

COPY nginx.conf /etc/nginx/conf.d/default.conf

# Copy remaining necessary files

COPY --from=builder /etc/nginx/mime.types /etc/nginx/mime.types

COPY --from=app_builder /app/dist /usr/share/nginx/html

COPY --from=builder /healthcheck /healthcheck

USER 101:101

EXPOSE 3000

HEALTHCHECK --interval=30s --timeout=3s --retries=3 \

 CMD ["/healthcheck"]

CMD ["/usr/sbin/nginx", "-g", "daemon off;"]

Dockerfile TOP 3 (React) – Go + FastHTTP

Kỹ thuật	Giải thích	Nguồn tham khảo
Go Server (FastHTTP)	Dùng `github.com/valyala/fasthttp` thay cho Nginx.
Asset Embedding	`//go:embed dist` để nhúng toàn bộ asset vào binary.
Nén Binary tối đa	Build tĩnh, strip, rồi `upx --ultra-brute --lzma`.
Healthcheck tích hợp	Binary Go tự đảm nhiệm khi chạy `-health`.

Dockerfile TOP 3 (React)

 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
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246



# Stage 1: Build frontend

FROM node:20-alpine AS builder

RUN corepack enable pnpm

WORKDIR /app

COPY package.json pnpm-lock.yaml ./

RUN pnpm install --frozen-lockfile

COPY tsconfig*.json vite.config.ts postcss.config.js tailwind.config.ts ./

COPY index.html ./

COPY src ./src

COPY public ./public

RUN pnpm build

# Clean up dist (remove source maps, licenses, stats, robots.txt, etc.)

RUN find /app/dist -type f -name '*.map' -delete \

 && find /app/dist -type f -name '*.LICENSE.*' -delete \

 && find /app/dist -type f -name '*.txt' -delete \

 && find /app/dist -type f -name 'stats.html' -delete \

 && find /app/dist -type f -name 'robots.txt' -delete \

 && find /app/dist -type f -name '_redirects' -delete

# Stage 2: Build Go server with FastHTTP

FROM golang:1.21-alpine AS go-builder

WORKDIR /app

# Cài strip và upx

RUN apk add --no-cache binutils upx

# Copy dist files để embed

COPY --from=builder /app/dist ./dist

# Tạo go.mod và main.go với FastHTTP

RUN cat > go.mod << 'GOMOD'

module server

go 1.21

require github.com/valyala/fasthttp v1.51.0

GOMOD

RUN cat > main.go << 'GOSRC'

package main

import (

 "embed"

 "log"

 "os"

 "path"

 "strings"

 "github.com/valyala/fasthttp"

)

//go:embed dist

var distFiles embed.FS

func main() {

 port := os.Getenv("PORT")

 if port == "" {

 port = "3000"

 }

 // FastHTTP handler

 handler := func(ctx *fasthttp.RequestCtx) {

 pathStr := string(ctx.Path())



 // Check if it's a static asset (has file extension)

 if strings.Contains(path.Base(pathStr), ".") {

 // Try to serve static file

 file, err := distFiles.Open("dist" + pathStr)

 if err == nil {

 defer file.Close()



 // Set content type based on extension

 ext := path.Ext(pathStr)

 switch ext {

 case ".js":

 ctx.SetContentType("application/javascript")

 case ".css":

 ctx.SetContentType("text/css")

 case ".svg":

 ctx.SetContentType("image/svg+xml")

 case ".png":

 ctx.SetContentType("image/png")

 case ".jpg", ".jpeg":

 ctx.SetContentType("image/jpeg")

 case ".ico":

 ctx.SetContentType("image/x-icon")

 default:

 ctx.SetContentType("application/octet-stream")

 }



 // Copy file content to response

 ctx.Response.SetBodyStream(file, -1)

 return

 }

 }



 // SPA fallback - serve index.html for all routes

 file, err := distFiles.Open("dist/index.html")

 if err != nil {

 ctx.SetStatusCode(404)

 ctx.SetBodyString("Not Found")

 return

 }

 defer file.Close()



 ctx.SetContentType("text/html; charset=utf-8")

 ctx.Response.SetBodyStream(file, -1)

 }

 // healthcheck

 if len(os.Args) > 1 && os.Args[1] == "-health" {

 _, _, err := fasthttp.Get(nil, "http://127.0.0.1:"+port)

 if err != nil {

 os.Exit(1)

 }

 os.Exit(0)

 }

 log.Printf("FastHTTP server on :%s", port)

 log.Fatal(fasthttp.ListenAndServe(":"+port, handler))

}

GOSRC

# Download dependencies và build với tối ưu extreme

RUN go mod tidy

RUN CGO_ENABLED=0 GOOS=linux go build -ldflags="-s -w" -trimpath -o server main.go

RUN strip server

RUN upx --ultra-brute --lzma server

# Stage 3: Ultra-minimal runtime (scratch)

FROM scratch

# Copy binary (chứa cả static files)

COPY --from=go-builder /app/server /server

EXPOSE 3000

# Thêm USER 1000

USER 1000

HEALTHCHECK --interval=30s --timeout=3s --start-period=5s --retries=3 \

 CMD ["/server", "-health"]

CMD ["/server"]

Dockerfile TOP (React) – Nginx tự biên dịch trên Alpine

Kỹ thuật	Giải thích	Nguồn tham khảo
Nginx Biên Dịch	Build Nginx 1.27.3 từ source, bật module cần cho SPA (`gzip_static`, `ssl`).
Pre-compression	`gzip -k -9` cho asset, phục vụ qua `gzip_static on`.
Security Headers inline	Thêm `X-Frame-Options`, `X-Content-Type-Options`, `X-XSS-Protection`.
Healthcheck	Dựa trên `wget` kiểm tra HTTP 200 tại cổng 3000.

Dockerfile TOP (React)

 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
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268



# =========================



# Giai đoạn 1: Node base

# =========================

# Môi trường build cho Vite/React: chỉ cài những thứ tối thiểu để biên dịch

FROM alpine:3.20@sha256:765942a4039992336de8dd5db680586e1a206607dd06170ff0a37267a9e01958 AS node-base

RUN apk add --no-cache nodejs npm git python3 g++ make && \

 npm install -g pnpm@9.12.2 && npm cache clean --force

# =========================

# Giai đoạn 2: Builder

# =========================

# Dùng cache mount cho pnpm để tăng tốc build lại; xóa source map; nén gzip sẵn

FROM node-base AS builder

WORKDIR /app

COPY package.json pnpm-lock.yaml ./

RUN --mount=type=cache,id=pnpm-custom,target=/root/.local/share/pnpm/store \

 pnpm install --frozen-lockfile --prefer-offline

# Sao chép cấu hình & mã nguồn

COPY index.html ./

COPY vite.config.ts tsconfig.json tsconfig.node.json ./

COPY postcss.config.js tailwind.config.ts ./

COPY public ./public

COPY src ./src

# Build & tối ưu artefact tĩnh

RUN pnpm run build && \

 find /app/dist -name "*.map" -type f -delete || true && \

 find /app/dist -type f \( -name '*.html' -o -name '*.js' -o -name '*.css' -o -name '*.svg' -o -name '*.json' \) \

 -exec gzip -k -9 {} \;

# ======================================

# Giai đoạn 3: Nginx builder (tự biên dịch)

# ======================================

# Biên dịch nginx 1.27.3 với module tối thiểu cho SPA + nén tĩnh

FROM alpine:3.20@sha256:765942a4039992336de8dd5db680586e1a206607dd06170ff0a37267a9e01958 AS nginx-builder

RUN apk add --no-cache --virtual .build-deps gcc libc-dev make pcre2-dev zlib-dev openssl-dev linux-headers && \

 wget -O /tmp/nginx.tar.gz https://nginx.org/download/nginx-1.27.3.tar.gz && \

 tar -xzf /tmp/nginx.tar.gz -C /tmp && cd /tmp/nginx-1.27.3 && \

 ./configure \

 --prefix=/etc/nginx \

 --sbin-path=/usr/sbin/nginx \

 --modules-path=/usr/lib/nginx/modules \

 --conf-path=/etc/nginx/nginx.conf \

 --error-log-path=/var/log/nginx/error.log \

 --http-log-path=/var/log/nginx/access.log \

 --pid-path=/var/run/nginx.pid \

 --lock-path=/var/run/nginx.lock \

 --http-client-body-temp-path=/var/cache/nginx/client_temp \

 --http-proxy-temp-path=/var/cache/nginx/proxy_temp \

 --user=nginx --group=nginx \

 --with-http_ssl_module --with-http_v2_module \

 --with-http_gzip_static_module --with-http_stub_status_module \

 --with-threads --with-file-aio \

 --without-http_autoindex_module --without-http_browser_module \

 --without-http_geo_module --without-http_map_module \

 --without-http_memcached_module --without-http_userid_module \

 --without-mail_pop3_module --without-mail_imap_module \

 --without-mail_smtp_module --without-http_split_clients_module \

 --without-http_uwsgi_module --without-http_scgi_module \

 --without-http_grpc_module && \

 make -j$(nproc) && make install && strip /usr/sbin/nginx && \

 rm -rf /tmp/nginx* && apk del .build-deps

# ======================================

# Giai đoạn 4: Runtime base tối giản

# ======================================

# Chỉ giữ runtime deps; tạo user non-root; chuẩn bị thư mục và quyền

FROM alpine:3.20@sha256:765942a4039992336de8dd5db680586e1a206607dd06170ff0a37267a9e01958 AS custom-runtime-base

RUN apk add --no-cache pcre2 zlib openssl tzdata && \

 addgroup -g 101 -S nginx && \

 adduser -S -D -H -u 101 -h /var/cache/nginx -s /sbin/nologin -G nginx -g nginx nginx && \

 mkdir -p /var/cache/nginx /var/log/nginx /etc/nginx/conf.d /usr/share/nginx/html && \

 chown -R nginx:nginx /var/cache/nginx /var/log/nginx /usr/share/nginx/html

COPY --from=nginx-builder /usr/sbin/nginx /usr/sbin/nginx

COPY --from=nginx-builder /etc/nginx /etc/nginx

# ======================================

# Giai đoạn 5: Runtime cuối

# ======================================

FROM custom-runtime-base AS runtime

LABEL org.opencontainers.image.title="SvnFrs-Dockerfile_Contest_2025" \

 org.opencontainers.image.description="SPA production trên Alpine với Nginx tự biên dịch, tối ưu và bảo mật" \

 org.opencontainers.image.version="1.0.0" \

 org.opencontainers.image.licenses="MIT" \

 org.opencontainers.image.created="2025-10-28" \

 org.opencontainers.image.base.name="alpine:3.20"

# Ứng dụng tĩnh đã build

COPY --from=builder --chown=nginx:nginx /app/dist /usr/share/nginx/html

# Cấu hình Nginx tối thiểu (inline) bật gzip_static để phục vụ file .gz

RUN echo 'server { \

 listen 3000; server_name localhost; \

 root /usr/share/nginx/html; index index.html; \

 gzip_static on; gzip_vary on; \

 location / { try_files $uri $uri/ /index.html; expires 1y; add_header Cache-Control "public, immutable"; } \

 location = /index.html { expires -1; add_header Cache-Control "no-cache"; } \

 add_header X-Frame-Options "SAMEORIGIN" always; \

 add_header X-Content-Type-Options "nosniff" always; \

 add_header X-XSS-Protection "1; mode=block" always; \

}' > /etc/nginx/conf.d/default.conf && \

echo 'worker_processes auto; error_log /var/log/nginx/error.log warn; pid /var/run/nginx.pid; \

events { worker_connections 1024; } http { include /etc/nginx/mime.types; default_type application/octet-stream; sendfile on; keepalive_timeout 65; include /etc/nginx/conf.d/*.conf; }' > /etc/nginx/nginx.conf && \

echo 'types { \

 text/html html htm shtml; text/css css; text/javascript js; application/json json; \

 image/svg+xml svg svgz; image/x-icon ico; image/png png; image/jpeg jpeg jpg; \

 font/woff2 woff2; application/wasm wasm; \

}' > /etc/nginx/mime.types

# Thư mục tạm/ngầm của Nginx + phân quyền trước khi chuyển USER

RUN mkdir -p /var/cache/nginx/client_temp \

 /var/cache/nginx/proxy_temp \

 /etc/nginx/fastcgi_temp \

 /etc/nginx/proxy_temp \

 /etc/nginx/client_body_temp \

 /etc/nginx/uwsgi_temp \

 /etc/nginx/scgi_temp && \

 chown -R nginx:nginx /var/cache/nginx \

 /var/log/nginx \

 /usr/share/nginx/html \

 /etc/nginx/fastcgi_temp \

 /etc/nginx/proxy_temp \

 /etc/nginx/client_body_temp \

 /etc/nginx/uwsgi_temp \

 /etc/nginx/scgi_temp && \

 chmod -R 755 /var/cache/nginx \

 /etc/nginx/fastcgi_temp \

 /etc/nginx/proxy_temp \

 /etc/nginx/client_body_temp \

 /etc/nginx/uwsgi_temp \

 /etc/nginx/scgi_temp && \

 touch /var/run/nginx.pid && \

 chown nginx:nginx /var/run/nginx.pid

# Healthcheck rẻ: HTTP 200 ở cổng 3000

RUN apk add --no-cache wget

HEALTHCHECK --interval=30s --timeout=3s --start-period=5s --retries=3 \

CMD wget --quiet --tries=1 --spider http://localhost:3000/ || exit 1

EXPOSE 3000

STOPSIGNAL SIGQUIT

USER nginx

CMD ["nginx", "-g", "daemon off;"]

Ghi chú triển khai

Các Dockerfile trên chỉ mang tính tham khảo kiến trúc; khi áp dụng vào dự án Node.js/React của bạn, hãy giữ nguyên nguyên tắc: multi-stage build, pre-compress, non-root, pin SHA.

Giới thiệu về Nginx

Mon, 10 Mar 2025 00:00:00 +0000

Nginx là gì?

NGINX là một phần mềm web server mã nguồn mở đáng tin cậy

Nginx là một phần mềm web server mã nguồn mở, hoạt động theo kiến trúc bất đồng bộ (asynchronous) hướng sự kiện (event-driven). ban đầu được phát triển để phục vụ http cache, nhưng sau này được mở rộng để hỗ trợ reverse proxy, http load balancing và các giao thức truyền mail như imap4, pop3, smtp.

Ra mắt vào tháng 10/2014, Nginx được nhiều công ty lớn như google, adobe, netflix, wordpress sử dụng nhờ khả năng xử lý hàng nghìn kết nối đồng thời.

Cách hoạt động của Nginx

NGINX cũng hoạt động tương tự như các server khác

Nginx hoạt động theo mô hình xử lý bất đồng bộ, khác với cách xử lý tuần tự của các web server truyền thống.

Mỗi tiến trình (process) sẽ có nhiều worker connections để xử lý các yêu cầu.
Worker connections gửi yêu cầu đến worker process, worker process chuyển tiếp đến master process để xử lý.
Nhờ cơ chế này, một worker connection có thể xử lý đến 1024 yêu cầu cùng lúc, giúp Nginx xử lý hàng ngàn yêu cầu hiệu quả.

Các tính năng của Nginx

Máy chủ NGINX có nhiều tính năng và ưu điểm vượt trội trong lập trình

Nginx sở hữu nhiều tính năng vượt trội:

⚡ xử lý hơn 10.000 kết nối đồng thời với mức sử dụng bộ nhớ thấp.
📂 phục vụ tập tin tĩnh (static files) và lập chỉ mục tập tin.
🔄 cân bằng tải và hỗ trợ proxy ngược với bộ nhớ đệm (cache).
🚀 hỗ trợ fastcgi, uwsgi, scgi và memcached.
🛠 kiến trúc modular và nén gzip tự động.
🔐 hỗ trợ mã hóa ssl/tls.
🔀 rewrite url bằng regular expressions.
🌐 hỗ trợ websockets và giới hạn số kết nối đồng thời.
📡 tương thích với ipv6.

So sánh Nginx và Apache server

So với Apache server, NGINX server có khá nhiều ưu điểm

Apache server:

xử lý yêu cầu bằng mô hình chia luồng (forked threaded) hoặc keep-alive.
có thể xử lý cả nội dung tĩnh và động.

Nginx server:

sử dụng vòng lặp sự kiện không đồng bộ (non-blocking event loop).
xử lý nội dung tĩnh hiệu quả hơn Apache.
tốc độ xử lý truy vấn nhanh hơn và tiết kiệm tài nguyên hơn.
cần bộ xử lý riêng để hỗ trợ nội dung động.

Hướng dẫn kiểm tra Nginx của website

Bạn có thể dựa vào các công cụ sẵn có để kiếm tra website có chạy Nginx

Bạn có thể kiểm tra website có chạy Nginx hay không bằng cách kiểm tra http header:

Mở trang web cần kiểm tra trên trình duyệt chrome.
Nhấn ctrl + shift + i hoặc f12 để mở chrome devtools.
Chuyển sang tab network.
Chọn một request bất kỳ và xem phần headers.

Ngoài ra, bạn có thể sử dụng công cụ như pingdom hoặc gtmetrix để kiểm tra.

Lời kết

Nginx đã và đang trở thành một trong những web server phổ biến nhất nhờ hiệu suất cao, khả năng xử lý hàng nghìn kết nối đồng thời và nhiều tính năng mạnh mẽ. Dù bạn cần một giải pháp để phục vụ nội dung tĩnh, cân bằng tải hay làm reverse proxy, Nginx đều có thể đáp ứng một cách hiệu quả. Hy vọng bài viết này giúp bạn hiểu rõ hơn về Nginx và cách nó hoạt động. Nếu bạn đang cân nhắc triển khai một web server tối ưu cho dự án của mình, hãy thử nghiệm Nginx và khám phá những lợi ích mà nó mang lại! 🚀😊

Hướng dẫn cài đặt Nginx trên Ubuntu 24.04

Mon, 10 Mar 2025 00:00:00 +0000

Giới thiệu

Nginx là một ứng dụng web server mã nguồn mở giúp triển khai các ứng dụng web tĩnh và động trên máy chủ. Nginx có thể hoạt động như một web server, load balancer, reverse proxy hoặc HTTP cache, hỗ trợ tích hợp với các ứng dụng hiện có để xây dựng một hệ thống hoàn chỉnh hoặc phân phối ứng dụng web qua địa chỉ IP hoặc tên miền.

Bài viết này hướng dẫn cách cài đặt Nginx trên Ubuntu 24.04 và thiết lập ứng dụng web mẫu để chạy trên máy chủ của bạn.

Yêu cầu trước khi bắt đầu

Trước khi tiến hành, hãy đảm bảo bạn đã thực hiện các bước sau:

🚀 Triển khai một máy chủ Ubuntu 24.04.
🌍 Tạo một bản ghi A (A record) cho tên miền hoặc subdomain trỏ đến địa chỉ IP của máy chủ. Ví dụ: app.example.com.
🔐 Truy cập máy chủ qua SSH và tạo một người dùng không phải root có quyền sudo.
🔄 Cập nhật hệ thống.

Cài đặt NGINX trên Ubuntu 24.04

Gói NGINX mới nhất có sẵn trong kho APT mặc định trên Ubuntu 24.04. Thực hiện các bước sau để cập nhật hệ thống và cài đặt NGINX.

🔄 Cập nhật danh sách gói hệ thống

1

sudo apt update

📦 Cài đặt NGINX

1

sudo apt install nginx -y

🔍 Kiểm tra phiên bản NGINX đã cài đặt

1

sudo nginx -version

Kết quả đầu ra sẽ tương tự như sau:

1

nginx version: nginx/1.24.0 (Ubuntu)

Quản lý dịch vụ NGINX

NGINX sử dụng dịch vụ nginx trong systemd để quản lý thời gian chạy và các tiến trình của web server trên máy chủ. Thực hiện các bước sau để kích hoạt dịch vụ NGINX và quản lý các tiến trình web server.

🚀 Kích hoạt dịch vụ NGINX khởi động cùng hệ thống

1

sudo systemctl enable nginx

Kết quả:

1
2


Synchronizing state of nginx.service with SysV service script with /usr/lib/systemd/systemd-sysv-install.
Executing: /usr/lib/systemd/systemd-sysv-install enable nginx

▶ Khởi động dịch vụ NGINX

1

sudo systemctl start nginx

⏹ Dừng dịch vụ NGINX

1

sudo systemctl stop nginx

🔄 Khởi động lại dịch vụ NGINX

1

sudo systemctl restart nginx

🔍 Kiểm tra trạng thái dịch vụ NGINX

1

sudo systemctl status nginx

Kết quả mẫu:

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


● nginx.service - A high performance web server and a reverse proxy server
 Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; preset: enabled)
 Active: active (running) since Wed 2024-06-26 10:55:50 UTC; 1min 0s ago
 Docs: man:nginx(8)
 Process: 2397 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
 Process: 2399 ExecStart=/usr/sbin/nginx -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
 Main PID: 2400 (nginx)
 Tasks: 2 (limit: 1068)
 Memory: 1.7M (peak: 2.4M)
 CPU: 13ms
 CGroup: /system.slice/nginx.service
 ├─2400 "nginx: master process /usr/sbin/nginx -g daemon on; master_process on;"
 └─2401 "nginx: worker process"

Dựa vào giá trị Active: active (running), NGINX đang chạy trên máy chủ. Nếu trạng thái hiển thị Active: active (failed), hãy kiểm tra và dừng bất kỳ tiến trình nào đang sử dụng cổng HTTP 80, sau đó khởi động lại dịch vụ NGINX.

Tạo nginx virtual host

Nginx virtual host bao gồm các cấu hình đặc biệt giúp máy chủ web phân phối các tệp ứng dụng web từ một thư mục cụ thể bằng một tên miền cụ thể trên máy chủ của bạn. các bước sau đây sẽ hướng dẫn tạo một cấu hình virtual host mẫu để phân phối tệp ứng dụng web một cách an toàn trên máy chủ.

📂 Tạo tệp cấu hình virtual host mới

Trong thư mục /etc/nginx/sites-available, tạo một tệp cấu hình mới, ví dụ: app.example.com.conf.

1

$ sudo nano /etc/nginx/sites-available/app.example.com.conf

Thêm các cấu hình sau vào tệp:

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


server {
 listen 80;
 listen [::]:80;

 server_name app.example.com;

 root /var/www/app.example.com;
 index index.html;

 location / {
 try_files $uri $uri/ =404;
 }
}

Lưu và đóng tệp.

✅ Kiểm tra cấu hình Nginx

Kiểm tra xem cấu hình Nginx có lỗi không:

1

$ sudo nginx -t

Kết quả:

1
2


nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

🔗 Kích hoạt virtual host

Liên kết tệp cấu hình vào thư mục /etc/nginx/sites-enabled để kích hoạt virtual host:

1

$ sudo ln -s /etc/nginx/sites-available/app.example.com.conf /etc/nginx/sites-enabled/

📁 Tạo thư mục web root

1

$ sudo mkdir -p /var/www/app.example.com

📝 Tạo tệp html mẫu

Tạo tệp index.html trong thư mục web root:

1

$ sudo nano /var/www/app.example.com/index.html

Thêm nội dung sau vào tệp:

1
2
3
4
5
6


<html>
 <head></head>
 <body>
 <h1>Hello Hoang Duong</h1>
 </body>
</html>

Lưu và đóng tệp.

🔄 Khởi động lại nginx

1

$ sudo systemctl restart nginx

🌍 Kiểm tra virtual host

Sử dụng lệnh curl để kiểm tra virtual host:

1

$ curl http://app.example.com

Kết quả:

1

Hello Hoang Duong

Bảo mật máy chủ web Nginx

SSL certificates giúp mã hóa giao tiếp giữa trình duyệt của người dùng và máy chủ Nginx thông qua HTTPS. Mặc định, Nginx lắng nghe kết nối đến trên cổng HTTP 80 không an toàn. Thực hiện các bước sau để tạo chứng chỉ SSL đáng tin cậy từ Let’s Encrypt và bảo mật máy chủ Nginx để chấp nhận các yêu cầu kết nối HTTPS được mã hóa.

Cài đặt Certbot – Let’s Encrypt Client 🔧

Cài đặt gói Certbot sử dụng Snap:

1

$ sudo snap install --classic certbot

Kiểm tra phiên bản Certbot đã cài trên máy chủ:

1

$ sudo certbot --version

📌 Đầu ra mẫu:

1

certbot 2.11.0

Tạo chứng chỉ SSL cho Nginx

Tạo chứng chỉ SSL mới cho tên miền của bạn. Thay thế app.example.com bằng tên miền thực tế trong cấu hình Virtual Host Nginx:

1

$ sudo certbot --nginx -d app.example.com --agree-tos

Quá trình này sẽ:

✅ Tạo chứng chỉ SSL hợp lệ
✅ Tự động cấu hình Nginx để sử dụng SSL
✅ Kích hoạt HTTPS trên máy chủ web của bạn

Kiểm tra tự động gia hạn chứng chỉ 🔄

Các chứng chỉ SSL từ Let’s Encrypt có thời hạn 90 ngày. Để đảm bảo không bị hết hạn, bạn có thể kiểm tra tiến trình tự động gia hạn:

1

$ sudo certbot renew --dry-run

Nếu không có lỗi nào xảy ra, nghĩa là chứng chỉ sẽ được tự động gia hạn đúng hạn.

Kiểm tra trang web hoạt động với https

Mở trình duyệt và truy cập:

1

https://app.example.com

Nếu thấy biểu tượng ổ khóa 🔒, tức là SSL đã được cài đặt thành công! 🚀

Thiết lập quy tắc tường lửa UFW

Uncomplicated Firewall (UFW) được cài đặt và kích hoạt mặc định trên Ubuntu 24.04. Thực hiện các bước sau để cấu hình tường lửa, cho phép máy chủ Nginx lắng nghe kết nối HTTP và HTTPS.

Cho phép kết nối HTTP (Cổng 80)🔌

Chạy lệnh sau để mở kết nối HTTP:

1

$ sudo ufw allow 80/tcp

Cho phép kết nối HTTPS (Cổng 443) 🔐

Chạy lệnh sau để mở kết nối HTTPS:

1

$ sudo ufw allow 443/tcp

Kiểm tra trạng thái tường lửa 🔢

Chạy lệnh sau để xác nhận quy tắc kết nối:

1

$ sudo ufw status

👉 Đầu ra mẫu:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


Status: active

To Action From
-- ------ ----
22/tcp ALLOW Anywhere
80/tcp ALLOW Anywhere
443/tcp ALLOW Anywhere
22/tcp (v6) ALLOW Anywhere (v6)
80/tcp (v6) ALLOW Anywhere (v6)
443/tcp (v6) ALLOW Anywhere (v6)

🛡 Sau khi thiết lập xong, máy chủ sẽ chỉ cho phép kết nối an toàn qua HTTP và HTTPS

Lời kết

Chúc bạn cài đặt thành công Nginx trên máy chủ Ubuntu 24.04 và cấu hình web server để phục vụ các ứng dụng web. Nginx hỗ trợ nhiều cấu hình virtual host giúp bạn triển khai các ứng dụng web một cách an toàn. Ngoài ra, bạn có thể tích hợp Nginx với các ứng dụng khác như MySQL và PHP để xây dựng các ứng dụng web động. Để biết thêm thông tin chi tiết và các tùy chọn cấu hình khác, vui lòng truy cập tài liệu chính thức chính thức của Nginx. 🚀😊

Trỏ tên miền về hosting

Thu, 27 Feb 2025 00:00:00 +0000

Tại sao cần phải trỏ tên miền về hosting?

Tên miền và hosting là hai yếu tố quan trọng giúp website hoạt động.

Tên miền là địa chỉ website.
Hosting là nơi lưu trữ dữ liệu website.

Lý do cần trỏ tên miền

Kết nối tên miền với hosting để website hiển thị trên internet.
Giúp mọi người truy cập website bằng địa chỉ dễ nhớ.

Cách thực hiện

Lấy thông tin nameserver hoặc IP từ nhà cung cấp.
Cấu hình trong trang quản lý domain.

Ba cách trỏ tên miền về hosting đơn giản nhất

Trỏ tên miền bằng nameserver

Các bước thực hiện:

Đăng nhập trình quản trị tên miền.
Chọn tên miền cần trỏ.

Chọn tên miền muốn trỏ về hosting

Thay đổi nameserver mặc định thành nameserver của hosting (thông tin này có trong email từ nhà cung cấp hosting).

Thay đổi Nameserver mặc định thành Nameserver của hosting đã đăng ký

Chờ cập nhật (vài phút đến vài giờ, tuỳ vào server có thể cao nhất tới 24h).
Kiểm tra bằng cách truy cập tên miền.

Trỏ tên miền bằng IP (A record)

Các bước thực hiện:

Đăng nhập trình quản trị tên miền.

Chọn tên miền muốn trỏ về hosting, sau đó chọn mục cấu hình DNS

Chọn mục cấu hình DNS.
Thêm 2 bản ghi A record:
- @ → IP của hosting (Địa chỉ IP của hosting từ email nhà cung cấp gửi).
- www → IP của hosting.

Thêm hai bản A record

Lưu thay đổi và chờ cập nhật (Quá trình này có thể nhanh hoặc lâu tùy thuộc vào hệ thống DNS. Có thể từ vài phút đến vài giờ).

Trỏ tên miền bằng nameserver trung gian

Để trỏ tên miền về hosting bằng Nameserver trung gian như CloudFlare, Namecheap FreeDNS, Incapsula, bạn có thể thực hiện theo các bước sau:

Các bước thực hiện:

Đăng ký tài khoản tại Nameserver trung gian > Xác nhận các bản ghi cần thiết để thêm website vào Nameserver trung gian.
Truy cập vào khu vực quản lý tên miền của nhà cung cấp và thực hiện thay đổi Nameserver để trỏ tên miền về hosting qua Nameserver trung gian.
Chờ cập nhật để hoàn tất.

Một số lỗi thường gặp khi trỏ tên miền về hosting

Khi trỏ tên miền về hosting, bạn có thể gặp một số lỗi phổ biến khiến website không hoạt động đúng cách. Hiểu và khắc phục các lỗi này sẽ giúp đảm bảo quá trình cấu hình diễn ra suôn sẻ.

Sai tên miền của hosting

Khi đăng ký hosting, nhà cung cấp yêu cầu khai báo tên miền. Nếu nhập sai hoặc trỏ về một tên miền không khớp, website sẽ không hoạt động.

Sử dụng cả hai cách trỏ tên miền

Nếu bạn đã trỏ tên miền bằng nameserver, không nên thay đổi sang IP (A record) và ngược lại, vì điều này có thể gây lỗi xung đột DNS.

Nhập sai loại bản ghi DNS

Có nhiều loại bản ghi DNS như:

A record: Trỏ tên miền về IP của hosting.
CNAME: Chuyển hướng một tên miền sang tên miền khác.
MX record: Cấu hình email.

Nhập sai loại bản ghi có thể làm gián đoạn kết nối đến hosting.

Nhập sai địa chỉ IP của hosting

IP hosting thường dài và dễ nhập sai. Bạn nên sao chép trực tiếp từ email của nhà cung cấp để tránh nhầm lẫn với IP của máy tính cá nhân hoặc thiết bị khác.

Nếu gặp lỗi, hãy kiểm tra lại thông tin và chờ một thời gian để DNS cập nhật hoàn tất.

Video hướng dẫn chi tiết

Nếu bạn muốn xem hướng dẫn trực quan hơn, có thể tham khảo video dưới đây. Video này sẽ giúp bạn hiểu rõ từng bước trong việc trỏ tên miền về hosting, từ cách lấy thông tin nameserver đến việc cập nhật trong trình quản lý tên miền.

― Nguồn, F8 Official ✔

Lời kết

Việc trỏ tên miền về hosting là một bước quan trọng để website của bạn có thể hoạt động chính xác trên Internet. Dù thực hiện theo cách nào—sử dụng nameserver, A record, hay nameserver trung gian—bạn cũng cần kiểm tra kỹ thông tin và kiên nhẫn chờ DNS cập nhật. Nếu gặp lỗi, hãy xem lại cài đặt và thử lại 🔄. Chúc bạn thực hiện thành công và website hoạt động ổn định! 🚀 Nếu có vấn đề, cứ để lại comment, tôi sẽ xem thử nhé! 💬😊

Deploy Website lên hosting đơn giản nhất (HTML/CSS hoặc React/Vue.js)

Wed, 26 Feb 2025 00:00:00 +0000

Cách up website lên Hosting thông qua File Manager và cPanel nhanh nhất từ A-Z

Việc upload website lên hosting là bước thiết yếu để đưa website của bạn hoạt động trên internet. Quá trình này không chỉ đơn giản là chuyển dữ liệu, mà còn liên quan đến việc đảm bảo mọi thứ hoạt động mượt mà và an toàn. Bài viết này sẽ giúp bạn hiểu rõ các bước cần thiết, từ chuẩn bị file và database, đến các công cụ hỗ trợ upload hiệu quả.

Điểm chính cần nắm

Trước khi bắt tay vào việc upload website lên hosting, bạn cần lưu ý một số yếu tố quan trọng. Mình sẽ giúp bạn dễ dàng hiểu và nắm bắt các bước thực hiện:

✅ Bạn cần chuẩn bị gì khi upload website lên hosting: Chuẩn bị file website, database, quyền truy cập control panel và phần mềm FTP như FileZilla.

✅ Các cách upload website lên hosting: Chọn hosting uy tín, sau đó sử dụng File Manager, FTP, plugin WordPress, SSH hoặc nhờ hỗ trợ từ nhà cung cấp.

✅ Lý do cần upload website lên hosting: Giúp công khai website, tăng bảo mật, cải thiện tốc độ và dễ quản lý.

✅ Bốn bước để upload web lên hosting:

Upload file website vào thư mục public_html qua File Manager hoặc FTP.
Kiểm tra xem các file đã đúng vị trí chưa.
Tạo database trên cPanel, import dữ liệu qua phpMyAdmin và cấu hình kết nối.
Truy cập website để kiểm tra xem mọi thứ đã hoạt động ổn định chưa.

Cần chuẩn bị gì khi upload website lên hosting?

Để upload website lên hosting, trước tiên bạn cần phải chuẩn bị một số vấn đề sau đây:

File website: Những file này có thể là toàn bộ dữ liệu bên trong phần public_html cũ hoặc file source code hay bản backup (sao lưu) dữ liệu mới nhất thay cho source code.

📌 Lưu ý khi triển khai website React/Vue.js

Khi build một ứng dụng React hoặc Vue.js, ta không tải toàn bộ mã nguồn lên máy chủ,
mà chỉ cần upload thư mục chứa các file tĩnh đã được build.

🔹 Các bước build và nén tệp:
Chạy lệnh build:
React:
1
npm run build
Vue.js:
1
npm run build
Sau khi build xong, thư mục output thường là build/ (React) hoặc dist/ (Vue.js).

Nén thư mục build hoặc dist thành file ZIP trước khi tải lên máy chủ.
📤 Khi tải lên máy chủ:
Nếu dùng cPanel, có thể giải nén trực tiếp trong thư mục public_html.
Nếu dùng SSH/SFTP, tải lên và giải nén bằng lệnh:
1
unzip build.zip -d /var/www/html/
Đảm bảo cấu hình máy chủ (Apache/Nginx) để trỏ vào thư mục chứa file index.html.

File database (nếu có).
Truy cập control panel của tài khoản hosting mới.
Phần mềm FTP client như FileZilla.

Để tải trang web lên hosting, bạn cần truy cập control panel của tài khoản hosting bằng phần mềm FTP như FileZilla. Nếu trang web đã có, bạn có thể dễ dàng sao lưu và tải lên bằng tính năng sao lưu của CMS hoặc cPanel.

Chọn nhà cung cấp hosting uy tín, tin cậy

Web Hosting chất lượng không chỉ đảm bảo tốc độ mà còn quyết định hiệu suất vận hành lâu dài của website. Vì vậy, việc lựa chọn nhà cung cấp hosting cần được thực hiện cẩn thận, dựa trên các tiêu chí sau:

Hỗ trợ trực tuyến: Đảm bảo nhà cung cấp có dịch vụ hỗ trợ khách hàng 24/7, giúp bạn nhanh chóng giải quyết sự cố.
Quyền kiểm soát tài khoản hosting: Bạn cần được cung cấp toàn quyền quản lý tài khoản hosting, bao gồm quyền truy cập vào cPanel hoặc các công cụ tương đương.
Khả năng mở rộng: Hosting nên có khả năng nâng cấp tài nguyên khi nhu cầu của bạn tăng cao, như dung lượng lưu trữ, băng thông hoặc số lượng tên miền.
Chính sách hoàn tiền minh bạch: Các chính sách hoàn tiền linh hoạt sẽ giúp bạn an tâm hơn khi thử nghiệm dịch vụ.
Dịch vụ cộng thêm miễn phí: Ưu tiên nhà cung cấp hỗ trợ thêm các tiện ích như SSL miễn phí, sao lưu định kỳ hoặc dịch vụ di chuyển website.
Đăng ký tên miền được công nhận bởi ICANN: Để bảo vệ thương hiệu của bạn, hãy chọn nhà cung cấp tên miền uy tín và được chứng nhận bởi ICANN.

Lưu ý: Hãy tìm hiểu kỹ về đánh giá của người dùng và uy tín của nhà cung cấp thông qua các diễn đàn hoặc trang đánh giá trước khi đưa ra quyết định. Điều này sẽ giúp bạn chọn được dịch vụ phù hợp nhất với nhu cầu phát triển website.

Lựa chọn phương pháp upload website lên hosting

Có 5 phương pháp chính để upload website lên hosting, tùy thuộc vào nhu cầu và công cụ bạn sử dụng:

Sử dụng công cụ quản lý file (File Manager)

Là công cụ quản lý file trực tiếp trên nền tảng web của hosting, thường được tích hợp sẵn trong cPanel hoặc các trình quản lý hosting khác.

Ưu điểm:

Miễn phí.
Dễ dàng sử dụng.

Nhược điểm:

Hạn chế dung lượng file tải lên (thường tối đa 256 MB).
Chỉ giải nén được các file nhỏ hơn dung lượng này.

Lưu ý: Khi dùng File Manager, bạn chỉ có thể tải hoặc giải nén file có dung lượng tối đa 256MB. Nếu muốn tải file lớn hơn, sử dụng FTP và giải nén qua SSH sẽ là lựa chọn tối ưu.

Hình 1: Truy cập vào File Manager

Sử dụng giao thức truyền tải file (FTP)

Giao thức FTP (File Transfer Protocol) cho phép bạn tải file lên hosting thông qua phần mềm FTP client như FileZilla. Đây là phương pháp hiệu quả và không giới hạn dung lượng file tải lên.

Ưu điểm:

Không giới hạn dung lượng tải lên.
Tải file lớn nhanh chóng và tiện lợi.

Nhược điểm:

Cần cài đặt phần mềm FTP client.
Cần thông tin đăng nhập FTP từ hosting.
Bảo mật không cao, có thể sử dụng SFTP để an toàn hơn.

Hình 2: Thông tin FPT

Sử dụng Plugin Di Chuyển WordPress

Nếu bạn sử dụng WordPress, các plugin như All in One WP Migration có thể giúp bạn di chuyển toàn bộ website một cách tự động.

Ưu điểm:

Dễ sử dụng, không cần kiến thức kỹ thuật cao.
Kéo thả file đơn giản.

Nhược điểm:

Giới hạn dung lượng file tải lên (thường là 256 MB).
Với file lớn hơn, cần chuyển sang FTP và SSH.

Lưu ý: Plugin này có giới hạn dung lượng, nếu muốn tải file lớn, bạn cần chuyển sang FTP và giải nén qua SSH. Sau khi upload, nhớ chuyển dữ liệu trong thư mục con ra ngoài public_html để website hoạt động chính xác.

Hình 3: Sử dụng WordPress Migration Plugin

Sử dụng SSH (Secure Shell)

SSH là cách tải và quản lý file qua dòng lệnh, phù hợp với những file lớn hoặc yêu cầu tốc độ cao.

Ưu điểm:

Nhanh chóng, không giới hạn dung lượng.
Có thể giải nén file trực tiếp trên server.

Nhược điểm:

Yêu cầu kỹ năng sử dụng lệnh cơ bản và quyền truy cập SSH từ nhà cung cấp hosting.

Hình 4: Sử dụng SSH upload website

Import Site – Trình nhập website tự động

Một số nhà cung cấp dịch vụ hosting cung cấp công cụ Import Site giúp tải và giải nén website vào thư mục public_html một cách nhanh chóng.

Ưu điểm:

Quá trình tải lên nhanh chóng và dễ dàng.
Không cần nhiều kiến thức kỹ thuật.

Nhược điểm:

Phụ thuộc vào nhà cung cấp hosting có hỗ trợ công cụ này.
Không phải nhà cung cấp hosting nào cũng cung cấp công cụ này.

Gợi ý: Kiểm tra với nhà cung cấp hosting xem họ có hỗ trợ công cụ nhập trang web hay không.

Hình 5: Tool nhập website

Nhờ sự hỗ trợ từ nhà cung cấp hosting

Hầu hết các nhà cung cấp hosting đều có dịch vụ hỗ trợ di chuyển website, đặc biệt khi bạn chuyển từ dịch vụ hosting cũ sang nhà cung cấp mới.

Ưu điểm:

Tiết kiệm thời gian và tránh sai sót kỹ thuật.
Được thực hiện bởi đội ngũ chuyên gia.

Nhược điểm:

Có thể mất phí nếu nhà cung cấp không hỗ trợ miễn phí.
Thời gian xử lý phụ thuộc vào đội ngũ hỗ trợ.

Gợi ý: Hãy kiểm tra chính sách hỗ trợ di chuyển website của nhà cung cấp hosting trước khi yêu cầu dịch vụ.

Hình 6: Nhờ sự hỗ trợ từ nhà cung cấp hosting

📌 Lưu ý sau khi upload website lên hosting

Di chuyển toàn bộ dữ liệu từ thư mục con (nếu có) ra ngoài public_html để website hoạt động chính xác.

Kiểm tra lại cấu trúc file và kết nối database (nếu có) để tránh lỗi khi vận hành.

Chọn phương pháp phù hợp nhất dựa trên kích thước file, nền tảng website và khả năng kỹ thuật của bạn.

Lý do cần upload website lên Hosting

Việc upload website lên hosting không chỉ là bước cần thiết để đưa website của bạn ra công chúng, mà còn mang lại nhiều lợi ích quan trọng giúp website hoạt động ổn định, bảo mật và hiệu quả. Dưới đây là những lý do bạn nên thực hiện việc này:

Xuất bản website và tiếp cận toàn cầu

Khi bạn upload website lên hosting, website sẽ trở nên công khai và có thể truy cập từ bất kỳ đâu trên thế giới qua tên miền (domain) của bạn. Nếu không làm điều này, chỉ riêng bạn mới có thể truy cập website từ máy tính cá nhân.

Bảo mật và an toàn dữ liệu

Hosting chuyên nghiệp mang lại những biện pháp bảo mật mạnh mẽ, chẳng hạn như chứng chỉ SSL, tường lửa và các công cụ bảo vệ dữ liệu khác. Điều này giúp đảm bảo an toàn cho website và cả dữ liệu thương hiệu khỏi các nguy cơ tấn công, mất mát hoặc xâm nhập dữ liệu, một vấn đề mà việc lưu trữ website trên máy tính cá nhân sẽ khó đảm bảo được.

Tăng tốc độ và hiệu suất Website

Các máy chủ hosting được tối ưu để xử lý lưu lượng truy cập lớn và cung cấp tốc độ internet nhanh chóng, giúp tăng cường hiệu suất tải trang của website. Điều này có nghĩa là người dùng sẽ có trải nghiệm mượt mà hơn, đồng thời giảm thiểu tình trạng website bị “lag” hoặc tải chậm, một yếu tố quan trọng trong việc giữ chân người truy cập.

Hình 7: Tăng tốc độ và hiệu suất Website

Tính ổn định và tin cậy

Khi website được lưu trữ trên hosting, bạn không phải lo lắng về việc duy trì phần cứng hay kết nối mạng. Các nhà cung cấp hosting sẽ đảm bảo server luôn hoạt động ổn định với thời gian uptime cao, giúp website của bạn luôn sẵn sàng phục vụ người dùng mà không gặp phải sự cố downtime kéo dài.

Quản lý website dễ dàng và tiện lợi

Các nhà cung cấp hosting cung cấp giao diện quản lý thân thiện và dễ sử dụng, giúp bạn dễ dàng theo dõi, tối ưu và bảo trì website. Từ việc sao lưu dữ liệu, nâng cấp phần mềm cho đến việc tối ưu hóa hiệu suất, tất cả đều trở nên đơn giản hơn khi bạn sử dụng dịch vụ hosting chuyên nghiệp.

Tính mở rộng và phát triển lâu dài

Hosting không chỉ phục vụ website trong giai đoạn đầu, mà còn hỗ trợ khả năng mở rộng khi website của bạn phát triển. Nếu lưu trữ trên máy tính cá nhân, bạn sẽ gặp khó khăn khi website tăng trưởng về lưu lượng truy cập hay yêu cầu về tài nguyên. Hosting chuyên nghiệp sẽ giúp bạn dễ dàng nâng cấp tài nguyên mà không phải lo lắng về việc mất dữ liệu hay gián đoạn dịch vụ.

Hình 8: Tính mở rộng và phát triển lâu dài

Tóm lại, việc upload website lên hosting mang lại những lợi ích vượt trội về bảo mật, hiệu suất, tính ổn định và khả năng quản lý, giúp website của bạn hoạt động hiệu quả và bền vững. Đây là bước quan trọng để không chỉ bảo vệ dữ liệu mà còn tạo ra một nền tảng vững chắc để phát triển website trong tương lai. Vì vậy, nếu bạn muốn website của mình hoạt động trơn tru và dễ dàng truy cập từ mọi nơi, việc upload lên hosting là điều không thể thiếu.

Bước 1: Chọn cách upload file website lên host

Cách 1: Upload website lên hosting bằng File Manager qua cPanel

Cách 2: Upload website lên hosting bằng FTP client

Sau khi bạn đã lựa chọn xong cách để upload, dưới đây là hướng dẫn cách upload website lên hosting đơn giản, bạn có thể tham khảo.

—Cách 1: Upload website lên hosting bằng File Manager qua cPanel— (Dễ nhất)

Truy cập cPanel của tài khoản hosting và làm theo hướng dẫn dưới đây:

Bước 1: Click vào icon File Manager, đặt bên dưới mục Files.

Chọn File Manager
Hình ảnh minh họa: Chọn File Manager

Chọn File Manager

Bước 2: Trong File Manager, mở thư mục public_html.

Mở thư mục public_html
Hình ảnh minh họa: Mở thư mục public_html

Mở thư mục public_html

Bước 3: Chọn Upload sau khi truy cập vào thư mục public_html.

Chọn Upload
Hình ảnh minh họa: Chọn Upload

Chọn Upload

Bước 4: Chọn Select File để chọn từng file hoặc kéo thả vào vùng nhận file.

Chọn file
Hình ảnh minh họa: Chọn file

Chọn file

Bước 5: Trong ví dụ này, mình kéo thả file wordpress.zip.

Chọn file zip wordpress
Hình ảnh minh họa: Chọn file zip wordpress (hoặc file dist.zip/build.zip)

Chọn file zip wordpress

Bước 6: Khi upload xong, quay lại File Manager để thấy file archive đã xuất hiện trong thư mục public_html. Click chuột phải và nhấn Extract để giải nén file archive.

Extract file
Hình ảnh minh họa: Extract file

Extract file

Bước 7: Chọn vị trí file archive cần extract, ở ví dụ này sẽ lưu vào /public_html.

Chọn vị trí file cần extract
Hình ảnh minh họa: Chọn vị trí file cần extract

Chọn vị trí file cần extract

Bước 8: Sau khi giải nén file, bạn có thể xem các file đã được giải nén trong thư mục public_html. Đây là thư mục gốc của website.

Quay lại thư mục ban đầu để xem
Hình ảnh minh họa: Quay lại thư mục ban đầu để xem

Quay lại thư mục ban đầu để xem

Bước 9: Trang web đã tải xong. Bạn có thể truy cập vào trang web bằng cách nhập URL vào trình duyệt.

Màn hình chọn ngôn ngữ trong quá trình cài đặt WordPress (Nếu có)

—Cách 2: Upload website lên hosting bằng FTP client—

Một số người dùng thích tải trang web của họ lên dịch vụ hosting qua FTP, ví dụ: FileZilla, SmartFTP, CoreFTP hoặc bất kỳ phần mềm nào khác. Trong các hướng dẫn sau, mình sẽ sử dụng FileZilla.

Những lưu ý trước khi upload website lên hosting:

Kiến thức và kỹ năng của bạn: Nếu bạn không có nhiều kiến thức về hosting, File Manager sẽ dễ sử dụng hơn. Nếu bạn thành thạo, FTP client sẽ giúp tải lên nhanh hơn.
Kích thước của website: Nếu website có dung lượng lớn, FTP client sẽ thuận tiện hơn vì không giới hạn dung lượng tải lên.
Yêu cầu đặc thù của website: Nếu website yêu cầu cấu hình server đặc biệt, bạn nên hỏi nhà cung cấp hosting để chọn cách upload phù hợp.

Bước 1: Trước tiên, bạn cần lấy thông tin FTP thông qua FTP Access. Nếu quên mật khẩu, bạn có thể đặt mật khẩu mới qua phần Change account password.

Lấy thông tin qua FTP Access
Hình ảnh minh họa: Lấy thông tin qua FTP Access

Lấy thông tin qua FTP Access

Bước 2: Mở FileZilla, điền thông tin FTP để truy cập và nhấn Quickconnect.

Chọn Quickconnect
Hình ảnh minh họa: Chọn Quickconnect

Chọn Quickconnect

Bước 3: Sau khi kết nối với FileZilla, tìm dữ liệu trang web và kéo chúng từ bên trái của phần mềm sang bên phải, thư mục đích là public_html. Bạn cần giải nén file archive trước, vì FTP không có chức năng giải nén.

Kéo thả dữ liệu từ bên trái của phần mềm sang bên phải
Hình ảnh minh họa: Kéo thả dữ liệu từ bên trái của phần mềm sang bên phải

Kéo thả dữ liệu từ bên trái của phần mềm sang bên phải

Bước 4: Tương tự, bạn có thể upload file nén qua FTP bằng cách kéo thả từ trái sang phải. Sau đó, giải nén chúng thông qua File Manager.

Upload file nén qua FTP
Hình ảnh minh họa: Upload file nén qua FTP

Upload file nén qua FTP

Bước 5: Sau khi tải trang web lên hosting, bạn có thể truy cập trang web bằng cách nhập URL vào trình duyệt. Bạn sẽ thấy trang cài đặt mặc định của website và có thể tùy chỉnh trang này để phù hợp với nhu cầu của mình.

Bước 2: Kiểm tra xem file đã ở trong thư mục public_html hay chưa

Sau khi upload website lên hosting, bước đầu tiên bạn cần làm là kiểm tra xem các file đã được tải đầy đủ vào thư mục public_html chưa. Bạn có thể mở thư mục public_html và kiểm tra xem tất cả các file đã nằm trong đó chưa. Nếu bạn tạo ra thư mục mới sau khi upload và giải nén website backup, người dùng sẽ phải truy cập theo đường dẫn dạng example.com/something thay vì example.com. Để khắc phục điều này, bạn có thể sử dụng File Manager hoặc FTP theo các bước sau:

Truy cập vào thư mục chứa các file của website.
Chọn toàn bộ các file và nhấn chuột phải, sau đó chọn nút Move.
Lựa chọn thư mục đích là public_html và nhấn Proceed.

Nếu website của bạn đã được vận hành một thời gian, bạn cũng cần phải upload database lên hosting nếu chưa thực hiện.

Sau khi đã đảm bảo các file đã được di chuyển đúng vào thư mục public_html, bạn có thể kiểm tra website bằng cách mở trình duyệt và truy cập vào tên miền của mình. Nếu tên miền chưa được trỏ đúng, bạn có thể sử dụng các phương pháp sau để kiểm tra và sửa lỗi DNS:

Sửa file hosts trên máy tính để giả lập thay đổi DNS.
Sử dụng các công cụ online để kiểm tra tên miền.
Cài đặt plugin trình duyệt để tạo file host ảo.

Ngoài ra, nếu bạn cần di chuyển website từ thư mục con lên thư mục gốc (public_html), bạn có thể sử dụng File Manager hoặc FTP để thực hiện. Và bạn đừng quên tải lại cơ sở dữ liệu lên hosting nếu cần thiết.

Bước 3: Tiến hành upload database lên website hosting

Thực hiện bước này khi website của người dùng đã có sẵn database. Nếu không, bạn có thể bỏ qua bước này.

Tạo database trên cPanel

Tạo một database mới tại section MySQL Databases. Khi tạo database bạn cần điền và ghi chú lại những thông số database như sau:

MySQL Database
MySQL User
MySQL Host
MySQL Password

Tạo database mới

Di chuyển vào phpMyAdmin của database

Khi sử dụng phpMyAdmin để quản lý database, hãy import database MySQL. Nếu bạn muốn upload vào một database có sẵn, hãy xóa dữ liệu trước để tránh lỗi khi tải lên từ máy tính.

Di chuyển vào phpMyAdmin

Di chuyển vào tab Import và upload dữ liệu vào database

Nếu là lần đầu tạo database, chỉ cần vào tab Import để upload dữ liệu vào database trống. Bạn đã có một file SQL từ bản sao lưu của trang web, có thể là file dạng text với đuôi .sql hoặc dạng nén như .sql.zip hay .sql.gz. Hãy nhấn nút Choose File để chọn file cơ sở dữ liệu và sau đó bấm nút Go để bắt đầu quá trình tải lên. Khi phpMyAdmin hoàn tất và hiển thị thông báo Import has been successfully finished, 302 queries executed, có nghĩa là quá trình tải lên cơ sở dữ liệu đã hoàn tất.

Import dữ liệu vào database

Cập nhật file cấu hình để kết nối website và database

Sau khi tải database lên server, bạn cần mở file cấu hình PHP script để điền thông tin như host, tên database, tên người dùng và mật khẩu. File cấu hình có thể có tên và vị trí khác nhau tùy thuộc vào phần mềm bạn sử dụng. Ví dụ, với WordPress, file cấu hình là wp-config.php và nằm trong thư mục chứa WordPress (thường là public_html).

⚠ Lưu ý:

Nếu cơ sở dữ liệu của bạn có kích thước lớn, hãy cân nhắc chia nhỏ database thành nhiều file để quá trình tải lên diễn ra nhanh chóng hơn.

Nếu database chứa các ký tự đặc biệt, nhớ chuyển đổi chúng sang định dạng ASCII trước khi thực hiện upload.

Trong trường hợp gặp lỗi khi import, bạn cần kiểm tra xem database có bị hỏng hay không. Nếu bị lỗi, hãy tạo lại một cơ sở dữ liệu mới và thử lại.

Cuối cùng, sau khi upload xong, đừng quên kiểm tra website của bạn để đảm bảo mọi thứ hoạt động bình thường.

Cập nhật file cấu hình để kết nối website và database

Sau khi tải database lên server, bạn cần mở file cấu hình PHP script để điền thông tin như host, tên database, tên người dùng và mật khẩu.

File cấu hình có thể có tên và vị trí khác nhau tùy thuộc vào phần mềm bạn sử dụng. Ví dụ, với WordPress, file cấu hình là wp-config.php và nằm trong thư mục chứa WordPress (thường là public_html).

Bước 4: Kiểm tra website đã hoạt động ổn định hay chưa

Để đảm bảo website của bạn hoạt động ổn định sau khi tải lên và trỏ tên miền, bạn cần thực hiện một số bước kiểm tra quan trọng:

Kiểm tra truy cập website

Truy cập bằng tên miền hoặc địa chỉ IP: Nếu bạn có thể truy cập thành công, website đã hoạt động ổn định.
Chờ DNS cập nhật: Nếu tên miền vừa được cập nhật, bạn có thể cần đợi khoảng 24 giờ để DNS được quảng bá rộng rãi.
Kiểm tra ngay lập tức bằng:
- 🖥 Sử dụng file host: Chỉnh sửa file host trên máy tính để mô phỏng thay đổi DNS.
- 🌐 Công cụ online: Kiểm tra website bằng các dịch vụ kiểm tra DNS trực tuyến.
- 🔌 Plugin browser: Cài đặt plugin giúp tạo file host ảo để kiểm tra các thay đổi DNS.

Kiểm tra các chức năng của website

Thử truy cập các trang khác nhau, kiểm tra liên kết.
Kiểm tra xem các tính năng của website có hoạt động đúng không.

Kiểm tra tốc độ tải trang

Sử dụng các công cụ như Google PageSpeed Insights, GTmetrix để kiểm tra hiệu suất.

Kiểm tra các lỗi trên website

Lỗi 404: Trang không tìm thấy.
Lỗi 500: Lỗi máy chủ hosting.
Lỗi 503: Máy chủ đang bảo trì.

Kiểm tra trên nhiều trình duyệt & thiết bị

Dùng Chrome, Firefox, Safari, Edge trên máy tính, điện thoại, máy tính bảng.

Kiểm tra vào các thời điểm khác nhau trong ngày

Website có thể hoạt động khác nhau vào những thời điểm khác nhau.

👉 Nếu phát hiện lỗi nhưng không biết cách xử lý, hãy liên hệ với nhà cung cấp hosting để được hỗ trợ. 🚀

Lời kết

Upload website lên hosting là một bước quan trọng để website của bạn có thể hoạt động ổn định trên môi trường trực tuyến. Bằng cách chuẩn bị đúng đắn và thực hiện theo các bước hướng dẫn, bạn sẽ đảm bảo rằng website của mình luôn sẵn sàng phục vụ người dùng một cách hiệu quả.

💡 Nếu bạn có bất kỳ câu hỏi nào hoặc cần hỗ trợ thêm, hãy để lại câu hỏi trong phần bình luận dưới đây. Mình sẽ sớm giúp bạn tìm ra lời giải đáp.

Cảm ơn bạn đã theo dõi bài viết 🚀

Giám sát ứng dụng (Application Monitoring)

Tue, 25 Feb 2025 00:00:00 +0000

Giám sát ứng dụng (Application Monitoring)

Giám sát ứng dụng là quá trình theo dõi và phân tích liên tục các ứng dụng phần mềm nhằm đảm bảo chúng hoạt động tối ưu, phát hiện sự cố và cung cấp những hiểu biết sâu sắc về hiệu suất của hệ thống. Việc giám sát bao gồm các chỉ số quan trọng như:

⏳ Thời gian phản hồi
❌ Tỷ lệ lỗi
🖥 Sử dụng tài nguyên (CPU, RAM, Disk)
🔄 Hiệu suất giao dịch

Các công cụ giám sát ứng dụng giúp thu thập, phân tích dữ liệu để phát hiện bất thường, cảnh báo sớm các vấn đề tiềm ẩn, đồng thời cung cấp cái nhìn toàn diện về hành vi của ứng dụng. Nhờ đó, doanh nghiệp có thể chủ động xử lý sự cố, tối ưu hiệu suất và nâng cao trải nghiệm người dùng.

Jaeger - Công cụ tracing phân tán

Jaeger là một hệ thống giám sát phân tán mã nguồn mở do Uber phát triển, giúp theo dõi và khắc phục sự cố trong các hệ thống microservices phức tạp.

Tính năng chính:

🌐 Theo dõi yêu cầu phân tán
🔎 Phân tích quan hệ giữa các dịch vụ
📊 Xác định nguyên nhân gốc rễ của vấn đề
🛠 Hỗ trợ OpenTracing – dễ dàng tích hợp với các hệ thống khác

Ví dụ cài đặt Jaeger với Docker

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


docker run -d --name jaeger \
 -e COLLECTOR_ZIPKIN_HTTP_PORT=9411 \
 -p 5775:5775/udp \
 -p 6831:6831/udp \
 -p 6832:6832/udp \
 -p 5778:5778 \
 -p 16686:16686 \
 -p 14268:14268 \
 -p 14250:14250 \
 -p 9411:9411 \
 jaegertracing/all-in-one:1.37

Sau khi cài đặt, tra cứu Jaeger UI tại http://localhost:16686

📌 Tài nguyên tham khảo:

📖 Tài liệu Jaeger
🛠 GitHub - jaegertracing

New Relic - Giám sát hiệu năng ứng dụng

New Relic là một nền tảng quan sát đám mây cung cấp cái nhìn toàn diện về phần mềm và cơ sở hạ tầng. Nó hỗ trợ giám sát hiệu suất thời gian thực, phân tích dữ liệu và cảnh báo tự động.

Tính năng chính:

📈 Theo dõi hiệu suất ứng dụng (APM)
🔎 Phân tích logs và truy vết lỗi
🚀 Theo dõi trải nghiệm người dùng trên web và mobile
🤖 AI-powered analytics – tự động phát hiện sự cố

Ví dụ cài đặt New Relic Agent trong Node.js

1

npm install newrelic --save

Sau đó, bạn cần thêm require(’newrelic’) ở dòng đầu tiên trong file main:

1
2
3
4
5


require('newrelic'); #Thêm thư viện newrelic
const express = require('express');
const app = express();
app.get('/', (req, res) => res.send('Hello, New Relic!'));
app.listen(3000, () => console.log('App running on port 3000'));

📌 Tài nguyên tham khảo:

🌐 Trang web New Relic
🎥 Bản demo nền tảng New Relic

Datadog - Giải pháp giám sát toàn diện

Datadog là một nền tảng giám sát và phân tích mạnh mẽ dành cho các ứng dụng quy mô lớn. Nó hỗ trợ nhiều lĩnh vực từ giám sát hạ tầng, hiệu suất ứng dụng đến quản lý logs và trải nghiệm người dùng.

Tính năng chính:

🔗 400+ tích hợp với các công cụ DevOps
📊 Theo dõi toàn bộ hệ thống trên dashboard trực quan
⚠ Thiết lập cảnh báo thông minh
📡 Hỗ trợ giám sát cloud-native

Ví dụ vài đặt Datadog Agent

1
2


DD_AGENT_MAJOR_VERSION=7 DD_API_KEY=<YOUR_API_KEY> \
DD_SITE="datadoghq.com" bash -c "$(curl -L https://s3.amazonaws.com/dd-agent/scripts/install_script.sh)"

Sau khi cài đặt, truy cập Datadog dashboard để xem các metric của bạn.

📌 Tài nguyên tham khảo:

🌐 Trang web Datadog
📖 Tài liệu Datadog

Kết luận

Việc giám sát ứng dụng đóng vai trò quan trọng trong việc đảm bảo hiệu suất và độ tin cậy của hệ thống. Các công cụ như Jaeger, New Relic và Datadog cung cấp các giải pháp toàn diện giúp doanh nghiệp theo dõi, phân tích và tối ưu hóa hệ thống phần mềm một cách hiệu quả. Chọn công cụ phù hợp sẽ giúp bạn quản lý ứng dụng tốt hơn, phát hiện sớm lỗi và cải thiện trải nghiệm người dùng.

🚀 Hãy triển khai giám sát để tối ưu hóa hiệu suất ứng dụng của bạn!

👉 Bước tiếp theo: Tìm hiểu về Artifacts trong phát triển phần mềm, artifacts là các tệp hoặc sản phẩm được tạo ra trong quá trình phát triển và triển khai ứng dụng.

GitOps - Tự động hoá triển khai với Git

Tue, 25 Feb 2025 00:00:00 +0000

Giới thiệu

GitOps là một phương pháp quản lý hạ tầng và triển khai ứng dụng bằng cách sử dụng Git làm nguồn sự thật duy nhất (single source of truth). Phương pháp này giúp tự động hóa quy trình triển khai, đảm bảo tính nhất quán và tăng cường khả năng theo dõi các thay đổi.

GitOps mở rộng thực tiễn của DevOps bằng cách áp dụng các nguyên tắc của kiểm soát phiên bản (version control) và tích hợp liên tục (CI/CD) vào quản lý hạ tầng. Thay vì thực hiện thủ công, mọi thay đổi được thực hiện qua pull request và tự động đồng bộ với hệ thống thực tế.

Lợi ích của GitOps

✅ Kiểm soát phiên bản: Tất cả các thay đổi được theo dõi trong Git, dễ dàng kiểm tra và quay lại trạng thái cũ khi cần.

✅ Tự động hoá triển khai: Sử dụng các công cụ như ArgoCD hoặc FluxCD để tự động đồng bộ hệ thống.

✅ Tăng cường bảo mật: Mọi thay đổi cần thông qua Git, giúp kiểm soát truy cập và hạn chế rủi ro thao tác trực tiếp.

✅ Khả năng phục hồi cao: Hệ thống có thể nhanh chóng phục hồi trạng thái ban đầu khi gặp sự cố bằng cách áp dụng lại cấu hình từ Git.

✅ Cải thiện hợp tác nhóm: Các thay đổi đều được ghi nhận và xem xét qua pull request, giúp các thành viên làm việc hiệu quả hơn.

Các công cụ GitOps phổ biến

ArgoCD - Triển khai liên tục mạnh mẽ

ArgoCD là một công cụ triển khai liên tục (CD) dành cho Kubernetes, giúp tự động hóa quá trình triển khai bằng cách theo dõi trạng thái của ứng dụng trong Git và đồng bộ với môi trường thực tế.

🔹 Tính năng nổi bật:

Tự động đồng bộ trạng thái ứng dụng với Git.
Giao diện web trực quan để theo dõi trạng thái triển khai.
Hỗ trợ Helm, Kustomize, và các công cụ quản lý cấu hình khác.

🔹Ví dụ triển khai ArgoCD

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


apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
 name: my-app
 namespace: argocd
spec:
 destination:
 namespace: default
 server: https://kubernetes.default.svc
 source:
 repoURL: https://github.com/my-org/my-repo.git
 targetRevision: HEAD
 path: manifests
 syncPolicy:
 automated:
 selfHeal: true
 prune: true

FluxCD - Quản lý triển khai tự động

FluxCD là một công cụ GitOps giúp triển khai ứng dụng lên Kubernetes bằng cách theo dõi Git repository và tự động cập nhật hệ thống khi có thay đổi.

🔹 Tính năng nổi bật:

Theo dõi repository Git và triển khai ứng dụng tự động.
Hỗ trợ Helm, Kustomize, và nhiều hệ thống CI/CD khác.
Cung cấp khả năng cập nhật hình ảnh container tự động.

🔹 Ví dụ triển khai FluxCD:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


apiVersion: source.toolkit.fluxcd.io/v1beta1
kind: GitRepository
metadata:
 name: my-app-repo
 namespace: flux-system
spec:
 interval: 1m0s
 url: https://github.com/my-org/my-repo.git
 ref:
 branch: main

So sánh ArgoCD và FluxCD

Tính năng	ArgoCD	FluxCD
UI trực quan	✅ Có	❌ Không
Hỗ trợ Helm	✅ Có	✅ Có
Cập nhật hình ảnh container tự động	❌ Không	✅ Có
Triển khai Canary/Rollback	✅ Có	✅ Có

Kết luận

GitOps giúp đơn giản hóa quy trình triển khai ứng dụng bằng cách sử dụng Git làm trung tâm kiểm soát. Với các công cụ như ArgoCD và FluxCD, doanh nghiệp có thể dễ dàng tự động hóa triển khai, đảm bảo tính nhất quán và cải thiện khả năng phục hồi hệ thống.

🔗 Tài liệu tham khảo:

Bạn đã thử áp dụng GitOps vào dự án của mình chưa? Hãy chia sẻ trải nghiệm của bạn! 🚀

👉 Bước tiếp theo: Tìm hiểu về Service Mesh một lớp hạ tầng phần mềm giúp quản lý giao tiếp giữa các dịch vụ trong hệ thống microservices. Nó cung cấp các tính năng như cân bằng tải, bảo mật, quan sát, kiểm soát lưu lượng và khắc phục lỗi, giúp dịch vụ giao tiếp với nhau một cách hiệu quả mà không cần thay đổi mã nguồn ứng dụng.

Mẫu thiết kế đám mây (Cloud Design Patterns)

Tue, 25 Feb 2025 00:00:00 +0000

Giới thiệu

Mẫu thiết kế đám mây là những giải pháp có thể tái sử dụng cho các vấn đề phổ biến trong kiến trúc điện toán đám mây. Các mẫu này giúp giải quyết các thách thức liên quan đến khả năng mở rộng, độ tin cậy, bảo mật và hiệu suất trong các hệ thống phân tán.

Chúng cung cấp các phương pháp tốt nhất để thiết kế và triển khai ứng dụng đám mây, bao gồm quản lý dữ liệu, xử lý tin nhắn, đảm bảo tính kiên cố (resiliency) và triển khai. Một số ví dụ phổ biến:

Circuit Breaker: Ngăn chặn lỗi lan rộng trong hệ thống bằng cách ngắt kết nối tạm thời khi phát hiện lỗi.
CQRS (Command Query Responsibility Segregation): Tách biệt các thao tác đọc và ghi dữ liệu để cải thiện hiệu suất.
Sidecar Pattern: Tách các thành phần phụ của ứng dụng vào một tiến trình hoặc container riêng để tăng tính linh hoạt.

Khả dụng (Availability)

Khả dụng (Availability) là phần trăm thời gian hệ thống hoạt động đúng như mong đợi, còn được gọi là uptime. Yếu tố này có thể bị ảnh hưởng bởi lỗi phần cứng/phần mềm, vấn đề hạ tầng, tấn công mạng hoặc tải hệ thống quá cao.

Các nhà cung cấp dịch vụ đám mây thường đưa ra thỏa thuận mức dịch vụ (SLA - Service Level Agreement), quy định thời gian uptime cam kết. Ví dụ, một công ty có thể đảm bảo 99.99% thời gian hoạt động.

🔹Ví dụ: Một hệ thống cam kết 99.99% uptime tức là chỉ được phép ngừng hoạt động tối đa 52 phút/năm.

Quản lý dữ liệu (Data Management)

Quản lý dữ liệu là yếu tố quan trọng trong các ứng dụng đám mây, ảnh hưởng đến hầu hết các thuộc tính chất lượng. Dữ liệu thường được lưu trữ ở nhiều địa điểm khác nhau để cải thiện hiệu suất, mở rộng quy mô hoặc đảm bảo tính sẵn sàng. Điều này đặt ra các thách thức như:

Duy trì tính nhất quán dữ liệu khi dữ liệu được đồng bộ trên nhiều máy chủ.
Bảo mật dữ liệu khi lưu trữ, truyền tải và cấp quyền truy cập.
Khả năng mở rộng để đáp ứng nhu cầu tăng trưởng.

🔹Ví dụ: Hệ thống ngân hàng cần đảm bảo mọi giao dịch đều đồng nhất giữa các trung tâm dữ liệu để tránh sai lệch số dư tài khoản.

Thiết Kế & triển Khai (Design and Implementation)

Thiết kế tốt giúp hệ thống dễ bảo trì, nhất quán và có thể tái sử dụng trong nhiều tình huống khác nhau. Các quyết định trong giai đoạn thiết kế và triển khai ảnh hưởng trực tiếp đến chi phí và chất lượng tổng thể của ứng dụng đám mây.

Nguyên tắc thiết kế quan trọng:

Tính nhất quán: Các thành phần phải tuân theo một cấu trúc nhất định.
Khả năng mở rộng: Hệ thống có thể xử lý lưu lượng cao mà không bị suy giảm hiệu suất.
Tái sử dụng: Các thành phần có thể dùng lại trong nhiều ứng dụng khác nhau.

🔹Ví dụ: Một hệ thống e-commerce sử dụng kiến trúc microservices để có thể dễ dàng mở rộng từng dịch vụ riêng lẻ (ví dụ: thanh toán, giỏ hàng, tìm kiếm sản phẩm).

Quản lý & giám sát (Management and Monitoring)

Quản lý và giám sát DevOps bao gồm toàn bộ quá trình phát triển từ lập kế hoạch, phát triển, kiểm thử, triển khai đến vận hành. Một hệ thống giám sát tốt giúp theo dõi trạng thái của ứng dụng, dịch vụ và hạ tầng trong môi trường sản xuất.

🔹 Các thành phần giám sát quan trọng:

Real-time streaming: Theo dõi hệ thống trong thời gian thực.
Historical replay: Lưu trữ lịch sử để phân tích lỗi.
Visualization: Hiển thị dữ liệu trực quan để dễ dàng đánh giá hệ thống.

🔹 Ví dụ: Sử dụng Prometheus + Grafana để giám sát hiệu suất của các container Kubernetes.

Kết luận

Các mẫu thiết kế đám mây giúp tối ưu hóa kiến trúc hệ thống bằng cách cung cấp giải pháp cho các thách thức phổ biến như hiệu suất, bảo mật và khả năng mở rộng. Việc áp dụng các mẫu thiết kế phù hợp giúp doanh nghiệp xây dựng hệ thống mạnh mẽ, linh hoạt và dễ bảo trì.

✅ Tổng kết: Bạn đã hoàn thành hành trình khám phá về DevOps, phương pháp kết hợp phát triển (Development) và vận hành (Operations) để tăng tốc triển khai phần mềm, nâng cao độ tin cậy hệ thống và tối ưu quy trình làm việc. Cảm ơn bạn đã đồng hành, hy vọng những kiến thức này sẽ giúp ích cho bạn trong hành trình tiếp theo! 🚀

Quản lý Artifacts trong phát triển phần mềm

Tue, 25 Feb 2025 00:00:00 +0000

Artifacts là gì?

Artifacts là các sản phẩm được tạo ra trong suốt vòng đời phát triển phần mềm. Chúng có thể bao gồm:

📜 Mã nguồn (Source code): Các tệp chứa logic ứng dụng.
🏗 Binaries: Các tệp thực thi hoặc thư viện được biên dịch.
📖 Tài liệu (Documentation): Hướng dẫn sử dụng, API specs.
⚙ Tệp cấu hình (Configuration files): Các thiết lập cần thiết để chạy ứng dụng.
🛠 Kết quả kiểm thử (Test results): Báo cáo từ các quy trình kiểm thử.

Việc quản lý artifacts giúp đảm bảo tính nhất quán, dễ dàng theo dõi và triển khai phần mềm hiệu quả hơn.

Các công cụ quản lý Artifacts phổ biến

Artifactory

Artifactory là một giải pháp DevOps cho việc lưu trữ, quản lý và phân phối các artifacts. Nó hỗ trợ nhiều định dạng như Docker, npm, Maven, Python, Go, và hơn thế nữa.

Cài đặt Artifactory trên Docker:

1
2
3
4
5


# Kéo image Artifactory
docker pull releases-docker.jfrog.io/jfrog/artifactory-oss:latest

# Chạy container
docker run --name artifactory -d -p 8081:8081 releases-docker.jfrog.io/jfrog/artifactory-oss:latest

Sau khi cài đặt, bạn có thể truy cập giao diện web qua http://localhost:8081.

Nexus Repository Manager

Nexus là một trong những công cụ phổ biến để quản lý binary artifacts, đặc biệt trong môi trường Java.

Cài đặt Nexus trên Linux:

1
2
3
4


wget https://download.sonatype.com/nexus/3/latest-unix.tar.gz
tar -xvf latest-unix.tar.gz
cd nexus-3.*
./bin/nexus start

Sau khi chạy, bạn có thể truy cập Nexus tại http://localhost:8081.

3. Cloudsmith

Cloudsmith là một nền tảng quản lý artifacts dựa trên đám mây, hỗ trợ nhiều định dạng gói tin như Docker, Helm, npm, pip.

Cách tải và đẩy package lên Cloudsmith:

1
2
3
4
5


# Cài đặt CLI của Cloudsmith
pip install cloudsmith-cli

# Đẩy một package lên kho lưu trữ
cloudsmith push python my-org/my-repo my-package-1.0.0.tar.gz

Cloudsmith giúp đơn giản hóa quá trình quản lý và phân phối gói phần mềm.

Kết luận

Việc quản lý artifacts đóng vai trò quan trọng trong quy trình phát triển phần mềm. Sử dụng các công cụ như Artifactory, Nexus, và Cloudsmith giúp đảm bảo tính tổ chức, bảo mật và hiệu quả trong việc lưu trữ và triển khai ứng dụng. Tùy vào nhu cầu của dự án, bạn có thể chọn công cụ phù hợp để tối ưu hóa quy trình DevOps của mình!

🛠 Bạn đang sử dụng công cụ nào để quản lý artifacts? Hãy chia sẻ kinh nghiệm của bạn!

👉 Bước tiếp theo: Tìm hiểu về GitOps quá trình cung cấp và cấu hình tài nguyên (máy chủ, mạng, lưu trữ, tài khoản) để hệ thống hoặc ứng dụng có thể hoạt động hiệu quả.

Service Mesh - Quản lý giao tiếp giữa Microservices

Tue, 25 Feb 2025 00:00:00 +0000

Giới thiệu

Service Mesh là một lớp hạ tầng phần mềm giúp quản lý giao tiếp giữa các dịch vụ trong hệ thống microservices. Nó cung cấp các tính năng như cân bằng tải, bảo mật, quan sát, kiểm soát lưu lượng và khắc phục lỗi, giúp dịch vụ giao tiếp với nhau một cách hiệu quả mà không cần thay đổi mã nguồn ứng dụng.

Các công cụ Service Mesh phổ biến gồm: Istio, Linkerd, Consul.

Lợi ích của Service Mesh

✅ Tự động quản lý giao tiếp giữa các dịch vụ - Không cần thay đổi mã nguồn ứng dụng.
✅ Bảo mật nâng cao - Mã hóa TLS, xác thực dịch vụ, chính sách RBAC.
✅ Tối ưu hiệu suất - Hỗ trợ cân bằng tải thông minh và kiểm soát lưu lượng.
✅ Quan sát toàn diện - Theo dõi logs, metrics và tracing để giám sát hệ thống.
✅ Khả năng phục hồi cao - Giúp phát hiện và xử lý lỗi tự động.

Các công cụ Service Mesh phổ biến

1⃣ Istio - Giải pháp mạnh mẽ nhất

Istio là một nền tảng Service Mesh mã nguồn mở cung cấp khả năng kiểm soát, bảo mật và quan sát dịch vụ trong hệ thống Kubernetes.

🔹 Tính năng chính:

Hỗ trợ mTLS để bảo mật giao tiếp giữa các dịch vụ.
Cân bằng tải thông minh, retry, timeout.
Quản lý API Gateway và chính sách truy cập dịch vụ.

🔹 Ví dụ cấu hình Istio Gateway:

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


apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
 name: my-gateway
spec:
 selector:
 istio: ingressgateway
 servers:
 - port:
 number: 80
 name: http
 protocol: HTTP
 hosts:
 - "example.com"

📖 Tài liệu Istio

2⃣ Linkerd - Dễ triển khai & hiệu năng cao

Linkerd là Service Mesh nhẹ, tối ưu hóa hiệu suất cho Kubernetes, giúp giảm độ trễ và tài nguyên sử dụng.

🔹 Tính năng chính:

Tự động mã hóa TLS (mTLS) cho toàn bộ giao tiếp.
Hỗ trợ giám sát tracing và metrics dễ dàng.
Cài đặt nhanh chỉ với một lệnh CLI.

🔹 Ví dụ cấu hình Linkerd:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


apiVersion: linkerd.io/v1alpha2
kind: ServiceProfile
metadata:
 name: my-service.default.svc.cluster.local
spec:
 routes:
 - name: "GET /health"
 condition:
 method: GET
 pathRegex: "/health"
 isRetryable: true

📖 Tài liệu Linkerd

3⃣ Consul - Hỗ trợ Service Mesh & Service Discovery

Consul không chỉ là một Service Mesh, mà còn cung cấp Service Discovery, quản lý cấu hình, và bảo mật giao tiếp giữa các dịch vụ.

🔹 Tính năng chính:

Hỗ trợ service discovery cho cả Kubernetes và hệ thống truyền thống.
Kết hợp với Envoy Proxy để quản lý giao tiếp.
Cho phép multi-cluster và hybrid cloud.

🔹 Ví dụ cấu hình Consul Service Registration:

1
2
3
4
5
6
7


{
 "service": {
 "name": "web",
 "port": 8080,
 "connect": { "sidecar_service": {} }
 }
}

📖 Tài liệu Consul

So sánh các Service Mesh phổ biến

Tính năng	Istio	Linkerd	Consul
UI trực quan	✅ Có	❌ Không	✅ Có
Hỗ trợ mTLS	✅ Có	✅ Có	✅ Có
Hiệu năng cao	⚠ Cần tối ưu	✅ Nhanh	⚠ Trung bình
Hỗ trợ Service Discovery	❌ Không	❌ Không	✅ Có

Kết luận

Service Mesh giúp đơn giản hóa việc quản lý giao tiếp giữa các microservices, đảm bảo bảo mật, giám sát và hiệu suất cao.

💡 Nếu bạn đang tìm kiếm một giải pháp mạnh mẽ nhất, hãy thử Istio.
💡 Nếu ưu tiên hiệu năng cao và dễ triển khai, hãy chọn Linkerd.
💡 Nếu bạn cần service discovery và multi-cloud, hãy xem xét Consul.

📖 Tài liệu tham khảo:
🔗 Tài liệu Istio
🔗 Tài liệu Linkerd
🔗 Tài liệu Consul

Bạn đã thử triển khai Service Mesh nào chưa? Hãy chia sẻ trải nghiệm của bạn! 🚀

👉 Bước cuối cùng: Tìm hiểu về Cloud Design Patterns tập hợp các mẫu thiết kế đã được kiểm chứng, giúp xây dựng các ứng dụng trên đám mây hiệu quả, linh hoạt và có khả năng mở rộng. Chúng giải quyết các vấn đề phổ biến như tính sẵn sàng cao, khả năng chịu lỗi, mở rộng theo nhu cầu và bảo mật trong môi trường điện toán đám mây.

CI/CD - Tích hợp liên tục và triển khai liên tục

Mon, 24 Feb 2025 00:00:00 +0000

CI/CD là gì?

CI/CD (Continuous Integration/Continuous Deployment) là một phương pháp giúp tự động hóa quá trình phát triển phần mềm, giúp giảm lỗi, tăng tốc độ triển khai và cải thiện chất lượng sản phẩm.

Continuous Integration (CI): Tích hợp liên tục, giúp phát hiện lỗi sớm bằng cách tự động kiểm thử mỗi khi có thay đổi trong mã nguồn.
Continuous Deployment (CD): Triển khai liên tục, đảm bảo phần mềm được phát hành một cách tự động và nhanh chóng.

Các công cụ CI/CD phổ biến

Jenkins

Jenkins là một máy chủ tự động hóa mã nguồn mở phổ biến, giúp xây dựng, kiểm thử và triển khai phần mềm một cách tự động.

📌 Đặc điểm nổi bật:

Hỗ trợ nhiều plugin, dễ dàng tích hợp với các công cụ DevOps.
Giao diện web trực quan, dễ dàng cấu hình.
Hỗ trợ cả môi trường Windows và Linux.

💡 Ví dụ: Cấu hình một pipeline đơn giản trong Jenkinsfile

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


pipeline {
 agent any
 stages {
 stage('Build') {
 steps {
 echo 'Building the application...'
 }
 }
 stage('Test') {
 steps {
 echo 'Running tests...'
 }
 }
 stage('Deploy') {
 steps {
 echo 'Deploying the application...'
 }
 }
 }
}

📖 Tài nguyên hữu ích:

CircleCI

CircleCI là một nền tảng CI/CD mạnh mẽ, hỗ trợ nhiều ngôn ngữ lập trình và tích hợp tốt với GitHub, Bitbucket.

📌 Đặc điểm nổi bật:

Hỗ trợ build song song để tăng tốc độ xử lý.
Tích hợp tốt với Docker và Kubernetes.
Có phiên bản cloud và self-hosted.

💡 Ví dụ: Cấu hình một pipeline CircleCI trong .circleci/config.yml

1
2
3
4
5
6
7
8
9


version: 2.1
jobs:
 build:
 docker:
 - image: circleci/node:14
 steps:
 - checkout
 - run: npm install
 - run: npm test

📖 Tài nguyên hữu ích:

GitLab CI/CD

GitLab CI/CD là một hệ thống tích hợp sẵn trong GitLab, cho phép tự động hóa quá trình kiểm thử và triển khai ngay trong Git repository.

📌 Đặc điểm nổi bật:

Hỗ trợ tự động hóa toàn bộ pipeline từ build, test đến deploy.
Có sẵn trong GitLab, không cần công cụ bên ngoài.
Hỗ trợ cả chạy pipeline trên Docker container.

💡 Ví dụ: Cấu hình pipeline GitLab CI/CD trong .gitlab-ci.yml

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


stages:
 - build
 - test
 - deploy

test:
 stage: test
 script:
 - npm install
 - npm test

📖 Tài nguyên hữu ích:

GitHub Actions

GitHub Actions là công cụ CI/CD được tích hợp trực tiếp vào GitHub, giúp tự động hóa quá trình kiểm thử và triển khai mỗi khi có thay đổi trong repository.

📌 Đặc điểm nổi bật:

Tích hợp chặt chẽ với GitHub, dễ dàng thiết lập workflow.
Hỗ trợ nhiều hệ điều hành và ngôn ngữ lập trình.
Có thể sử dụng marketplace với hàng nghìn actions có sẵn.

💡 Ví dụ: Workflow GitHub Actions trong .github/workflows/main.yml

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


name: Node.js CI
on: [push, pull_request]
jobs:
 build:
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v3
 - name: Setup Node.js
 uses: actions/setup-node@v3
 with:
 node-version: 14
 - run: npm install
 - run: npm test

📖 Tài nguyên hữu ích:

Kết luận

CI/CD giúp tăng tốc quá trình phát triển phần mềm, giảm thiểu lỗi và nâng cao chất lượng sản phẩm. Tùy theo nhu cầu và môi trường làm việc, bạn có thể chọn Jenkins, CircleCI, GitLab CI/CD hoặc GitHub Actions để triển khai hệ thống CI/CD của mình. 🚀

👉 Bước tiếp theo: Tìm hiểu về Secret Management quá trình lưu trữ, quản lý và bảo vệ các thông tin nhạy cảm như mật khẩu, khóa API, chứng chỉ và token truy cập để ngăn chặn rò rỉ dữ liệu và đảm bảo bảo mật hệ thống. 💡

Container Orchestration

Mon, 24 Feb 2025 00:00:00 +0000

Container Orchestration là gì?

Container orchestration là quá trình quản lý và tự động hóa vòng đời của container, bao gồm triển khai, mở rộng và kết nối mạng giữa các container trên nhiều máy chủ. Đây là công nghệ quan trọng để chạy các ứng dụng phức tạp trong môi trường sản xuất.

Bằng cách sử dụng các công cụ như Kubernetes, Docker Swarm, và Apache Mesos, các tổ chức có thể đảm bảo tính khả dụng cao, khả năng mở rộng và độ tin cậy cho ứng dụng của mình. Container orchestration giúp tự động hóa các tác vụ vận hành và tạo nền tảng vững chắc cho microservices, cloud-native development, và DevOps.

📚 Tài nguyên miễn phí hữu ích:

Kubernetes

Kubernetes là nền tảng mã nguồn mở phổ biến nhất để quản lý container. Nó cho phép triển khai container trên nhiều máy chủ, xác định mức độ sẵn sàng, logic triển khai và mở rộng thông qua YAML.

Kubernetes có nguồn gốc từ Borg, nền tảng nội bộ của Google, và đã trở thành kỹ năng quan trọng đối với các kỹ sư DevOps. Nhiều tổ chức đã thành lập đội ngũ Platform Engineering chuyên về Kubernetes để hỗ trợ các nhóm phát triển sản phẩm.

📚 Tài nguyên miễn phí hữu ích:

📌 Ví dụ:

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


apiVersion: apps/v1
kind: Deployment
metadata:
 name: my-app
spec:
 replicas: 3
 selector:
 matchLabels:
 app: my-app
 template:
 metadata:
 labels:
 app: my-app
 spec:
 containers:
 - name: my-app
 image: my-app-image:latest

GKE / EKS / AKS

GKE - Google Kubernetes Engine

Google Kubernetes Engine (GKE) là dịch vụ Kubernetes được quản lý bởi Google Cloud. Nó giúp triển khai, quản lý và mở rộng ứng dụng container với Kubernetes mà không cần tự quản lý cụm máy chủ.

EKS - Amazon Elastic Kubernetes Service

Amazon Elastic Kubernetes Service (EKS) là dịch vụ Kubernetes được AWS cung cấp. Nó tự động quản lý control plane của Kubernetes và tích hợp với các dịch vụ AWS khác.

AKS - Azure Kubernetes Service

Azure Kubernetes Service (AKS) là dịch vụ Kubernetes của Microsoft Azure. AKS hỗ trợ giám sát, bảo mật, mở rộng tự động và tích hợp với Azure DevOps.

📚 Tài nguyên miễn phí hữu ích:

☁ Google Kubernetes Engine (GKE)
🟧 Amazon Elastic Kubernetes Service (EKS)
🔵 Azure Kubernetes Service (AKS)
🎥 Hướng dẫn AWS EKS
🎥 Google Kubernetes Engine là gì?

ECS / Fargate

ECS là dịch vụ quản lý container chạy trên EC2 của AWS, cho phép kiểm soát hạ tầng máy chủ.

Fargate là dịch vụ quản lý container serverless, giúp chạy container mà không cần quản lý máy chủ hoặc cụm máy.

📚 Tài nguyên miễn phí hữu ích:

📌 Ví dụ:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


{
 "family": "my-task",
 "containerDefinitions": [
 {
 "name": "my-container",
 "image": "my-container-image:latest",
 "memory": 512,
 "cpu": 256
 }
 ]
}

Docker Swarm

Docker Swarm là tập hợp các máy (vật lý hoặc ảo) chạy Docker và được cấu hình thành một cụm (cluster). Quản lý cụm được thực hiện bởi swarm manager, và các máy tham gia cụm được gọi là nodes.

📚 Tài nguyên hữu ích:

📌 Ví dụ:

1
2
3
4
5


// Khởi tạo Swarm
$ docker swarm init

// Triển khai dịch vụ trên Swarm
$ docker service create --name web -p 80:80 nginx

Kết luận

Container orchestration đóng vai trò quan trọng trong việc quản lý ứng dụng container, giúp đơn giản hóa vận hành, tối ưu tài nguyên và tăng cường tính sẵn sàng. Các công cụ như Kubernetes, Docker Swarm, ECS, Fargate cung cấp nhiều giải pháp linh hoạt cho các doanh nghiệp hiện đại. Việc lựa chọn công cụ phù hợp sẽ giúp doanh nghiệp tận dụng tối đa sức mạnh của container hóa và điện toán đám mây. 🚀

👉 Bước tiếp theo: Tìm hiểu về Application Monitoring theo dõi, đo lường và phân tích hiệu suất, trạng thái và hành vi của ứng dụng để phát hiện sự cố, tối ưu hóa hiệu suất và đảm bảo trải nghiệm người dùng tốt. Các công cụ phổ biến như Prometheus, Grafana, Datadog, New Relic giúp thu thập dữ liệu từ ứng dụng, máy chủ và hạ tầng để cung cấp cảnh báo và báo cáo chi tiết.

Giám sát hạ tầng (Infrastructure Monitoring)

Mon, 24 Feb 2025 00:00:00 +0000

Giám sát hạ tầng (Infrastructure Monitoring) là gì?

Giám sát hạ tầng là quá trình theo dõi hiệu suất và trạng thái của hệ thống, giúp phát hiện sự cố kịp thời và tối ưu hóa hoạt động. Đây là một lĩnh vực rộng lớn với nhiều công cụ khác nhau, mỗi công cụ có ưu nhược điểm riêng. Hiểu rõ các công cụ này sẽ giúp bạn chọn giải pháp phù hợp với mục tiêu giám sát của mình.

Các công cụ giám sát phổ biến

Grafana

📝 Giới thiệu: Grafana là một ứng dụng web mã nguồn mở chuyên dùng để phân tích dữ liệu và trực quan hóa. Nó kết nối với nhiều nguồn dữ liệu khác nhau như cơ sở dữ liệu thời gian thực, cơ sở dữ liệu quan hệ và dịch vụ đám mây.

🔹 Tính năng nổi bật:

Trực quan hóa dữ liệu mạnh mẽ với nhiều loại biểu đồ.
Hỗ trợ nhiều plugin mở rộng.
Hệ thống cảnh báo theo thời gian thực.
Xác thực người dùng và kiểm soát truy cập theo vai trò.

📌 Ví dụ: Sử dụng Grafana để giám sát mức sử dụng CPU và RAM của hệ thống, giúp phát hiện và xử lý sự cố quá tải.

📚 Tài nguyên hữu ích:

Prometheus

📝 Giới thiệu: Prometheus là một công cụ giám sát và cảnh báo mã nguồn mở, đặc biệt phù hợp với các hệ thống microservices và container hóa như Kubernetes.

🔹 Tính năng nổi bật:

Mô hình dữ liệu đa chiều.
Hỗ trợ ngôn ngữ truy vấn PromQL mạnh mẽ.
Cơ chế thu thập dữ liệu theo mô hình pull.
Quản lý cảnh báo thông minh với Alertmanager.

📌 Ví dụ: Sử dụng Prometheus để thu thập và phân tích số lượng request đến một API, giúp xác định thời điểm tải cao và tối ưu hóa hiệu suất.

📚 Tài nguyên hữu ích:

🔗Trang chủ Prometheus
🎥Giới thiệu về Prometheus

Zabbix

📝 Giới thiệu: Zabbix là một nền tảng giám sát mã nguồn mở, hỗ trợ theo dõi toàn diện các thành phần trong hệ thống như máy chủ, mạng, ứng dụng và dịch vụ.

🔹 Tính năng nổi bật:

Hỗ trợ nhiều phương thức thu thập dữ liệu: Agent, SNMP, IPMI, script tùy chỉnh.
Cảnh báo và thông báo theo thời gian thực.
Hệ thống dashboard và báo cáo chi tiết.
Mở rộng dễ dàng cho các môi trường lớn.

📌 Ví dụ: Sử dụng Zabbix để giám sát trạng thái của các server trong hệ thống, phát hiện downtime và gửi cảnh báo ngay lập tức.

📚 Tài nguyên hữu ích:

🔗Trang chủ Zabbix
📖Hướng dẫn sử dụng Zabbix

Kết luận

Mỗi công cụ giám sát có ưu điểm riêng:

Grafana: Mạnh về trực quan hóa dữ liệu.
Prometheus: Phù hợp với môi trường container và microservices.
Zabbix: Giải pháp giám sát tổng thể cho hệ thống lớn.

Tùy vào nhu cầu cụ thể, bạn có thể kết hợp nhiều công cụ để xây dựng hệ thống giám sát tối ưu cho mình. 🚀

👉 Bước tiếp theo: Tìm hiểu về Logs Management quá trình thu thập, lưu trữ, xử lý và phân tích log từ các hệ thống, ứng dụng và thiết bị nhằm theo dõi hoạt động, phát hiện sự cố, đảm bảo bảo mật và hỗ trợ khắc phục sự cố nhanh chóng.

Infrastructure Provisioning với Terraform

Mon, 24 Feb 2025 00:00:00 +0000

Provisioning là gì?

Provisioning đề cập đến quá trình thiết lập và cấu hình hạ tầng CNTT cần thiết để hỗ trợ ứng dụng hoặc dịch vụ. Điều này bao gồm việc phân bổ và chuẩn bị tài nguyên như máy chủ, lưu trữ, mạng và môi trường phần mềm.

Mặc dù provisioning có thể được thực hiện thủ công, nhưng trong DevOps hiện đại, quá trình này thường được tự động hóa bằng các công cụ như Terraform, Pulumi, CloudFormation. Việc sử dụng Infrastructure-as-Code (IaC) giúp định nghĩa toàn bộ quy trình provisioning trong các tệp script được quản lý phiên bản, giúp đảm bảo tính nhất quán, giảm lỗi do con người và cải thiện khả năng mở rộng, phục hồi sau thảm họa.

📖 Tài nguyên miễn phí để tìm hiểu:

Terraform - Giải pháp IaC mạnh mẽ

Terraform là công cụ Infrastructure-as-Code (IaC) mã nguồn mở do HashiCorp phát triển, giúp định nghĩa, triển khai và quản lý hạ tầng trên đa đám mây hoặc on-premises bằng các tập tin cấu hình khai báo (declarative).

Lợi ích khi sử dụng Terraform

✅ Hỗ trợ đa nền tảng: AWS, Azure, Google Cloud, Kubernetes, v.v. ✅ Quản lý trạng thái (state management): Giúp theo dõi tài nguyên hạ tầng. ✅ Khả năng mở rộng và tái sử dụng: Dễ dàng modular hóa cấu hình. ✅ Tích hợp CI/CD: Tự động hóa triển khai hạ tầng.

Ví dụ: Tạo một EC2 instance trên AWS

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


provider "aws" {
 region = "us-east-1"
}

resource "aws_instance" "web" {
 ami = "ami-12345678"
 instance_type = "t2.micro"
 tags = {
 Name = "Terraform-Instance"
 }
}

📖 Tài nguyên miễn phí để tìm hiểu:

AWS CDK - Một sự thay thế?

AWS Cloud Development Kit (AWS CDK) là framework mã nguồn mở để provisioning hạ tầng AWS bằng mã trong các ngôn ngữ như TypeScript, Python, Java, C#, Go. AWS CDK sử dụng CloudFormation để triển khai tài nguyên một cách an toàn và có thể lặp lại.

📖 Tài nguyên miễn phí để tìm hiểu:

Kết luận

Terraform là công cụ hàng đầu cho Infrastructure-as-Code, mang đến sự linh hoạt và khả năng tự động hóa mạnh mẽ trên nhiều nền tảng cloud khác nhau. Nếu bạn làm việc nhiều với AWS và muốn triển khai bằng các ngôn ngữ lập trình, AWS CDK cũng là một lựa chọn đáng cân nhắc.

Tùy vào yêu cầu của dự án, bạn có thể lựa chọn công cụ phù hợp để quản lý hạ tầng hiệu quả hơn. 🚀

👉 Bước tiếp theo: Tìm hiểu về Configuration Management quá trình quản lý, giám sát và tự động hóa cấu hình hệ thống, phần mềm và hạ tầng để đảm bảo tính nhất quán, ổn định và dễ dàng kiểm soát trong suốt vòng đời của chúng. Nó giúp theo dõi và kiểm soát thay đổi, giảm lỗi do cấu hình thủ công và hỗ trợ triển khai nhanh chóng. Các công cụ phổ biến bao gồm Ansible, Puppet, Chef và SaltStack.

Quản lý cấu hình (Configuration Management)

Mon, 24 Feb 2025 00:00:00 +0000

Quản lý cấu hình (Configuration Management)

Quản lý cấu hình là quy trình quản lý và duy trì tính nhất quán của các thành phần trong hệ thống công nghệ thông tin. Trong lĩnh vực phần mềm, nó bao gồm việc giám sát, theo dõi và quản lý các thay đổi cấu hình của hệ thống trong suốt vòng đời sản phẩm. Việc áp dụng quản lý cấu hình giúp tăng tính đồng bộ, giảm nguy cơ lỗi, và đảm bảo sự tuân thủ các tiêu chuẩn trong quy trình CI/CD (Continuous Integration and Continuous Deployment).

Các công cụ quản lý cấu hình phổ biến

Ansible

Ansible là một công cụ tự động hóa mở, chủ yếu dùng cho quản lý cấu hình, triển khai ứng dụng và tự động hóa tác vụ.

🔄 Đặc điểm:

Sử dụng YAML (playbooks) để xác định trạng thái mong muốn.
Hoạt động không cần cài đặt agent.
Phù hợp với quy mô nhỏ đến lớn.

💡 Ví dụ sử dụng Ansible:

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


- name: Cài đặt và khởi động Nginx
 hosts: all
 become: yes
 tasks:
 - name: Cài đặt Nginx
 apt:
 name: nginx
 state: present
 - name: Khởi động Nginx
 service:
 name: nginx
 state: started

📖 Tài nguyên miễn phí hữu ích:

Chef

Chef (hiện thuộc Progress Chef) là một trong những công cụ quản lý cấu hình đầu tiên. Nó sử dụng ngôn ngữ Ruby và đề cao tính idempotence (đảm bảo chạy n nhiều lần vẫn cùng kết quả).

🔄 Đặc điểm:

Dựa trên client/server.
Có Chef-Solo cho triển khai độc lập.
Phù hợp với môi trường doanh nghiệp.

💡 Ví dụ sử dụng Chef:

1
2
3
4
5
6
7


package 'nginx' do
 action :install
end

service 'nginx' do
 action [:enable, :start]
end

📖 Tài nguyên miễn phí hữu ích:

Puppet

Puppet là một công cụ quản lý cấu hình theo mô hình declarative, hoạt động theo kiểu client/server và hỗ trợ nhiều hệ điều hành.

🔄 Đặc điểm:

Quản lý quy mô lớn.
Kiểm tra và áp dụng cấu hình định kỳ.
Tích hợp với nhiều công cụ DevOps.

💡 Ví dụ sử dụng Puppet:

1
2
3
4
5
6
7
8


package { 'nginx':
 ensure => installed,
}

service { 'nginx':
 ensure => running,
 enable => true,
}

📖 Tài nguyên miễn phí hữu ích:

Kết luận

Quản lý cấu hình là một yếu tố quan trọng trong quy trình DevOps, giúp đảm bảo hệ thống hoạt động nhất quán, giảm thiểu lỗi và nâng cao độ tin cậy. Tùy thuộc vào nhu cầu và quy mô, doanh nghiệp có thể chọn Ansible, Chef hoặc Puppet để quản lý hạ tầng một cách hiệu quả.

👉 Bước tiếp theo: Tìm hiểu về Continuous Integration and Continuous Deployment (CI/CD), là quy trình tự động hóa trong phát triển phần mềm giúp tích hợp, kiểm thử và triển khai ứng dụng một cách liên tục.

Quản lý khoá bí mật (Secret Management)

Mon, 24 Feb 2025 00:00:00 +0000

Secret Management là gì?

Secret Management là quá trình bảo vệ, lưu trữ và phân phối an toàn các thông tin nhạy cảm như mật khẩu, khóa API và chứng chỉ trong hệ thống công nghệ thông tin của tổ chức. Nó giúp ngăn chặn truy cập trái phép đồng thời đảm bảo các hệ thống và người dùng được ủy quyền có thể sử dụng thông tin khi cần thiết.

Secret Management thường bao gồm các tính năng:

Mã hóa dữ liệu khi lưu trữ và truyền tải.
Kiểm soát truy cập, chỉ cho phép người hoặc hệ thống có quyền mới được truy cập.
Cơ chế quay vòng khóa để thay đổi mật khẩu định kỳ.
Tích hợp với các hệ thống DevOps để tự động hóa quy trình bảo mật.

🔗 Tham khảo thêm:

HashiCorp Vault

HashiCorp Vault là công cụ quản lý bí mật giúp bảo vệ dữ liệu nhạy cảm như mật khẩu, khóa API và khóa mã hóa.

Đặc điểm nổi bật:

Quản lý tập trung giúp dễ dàng kiểm soát các bí mật.
Hỗ trợ nhiều phương thức xác thực như LDAP, Kubernetes.
Cung cấp bí mật động (Dynamic Secrets) giúp tạo bí mật tạm thời khi cần.
Mã hóa dữ liệu mạnh mẽ khi lưu trữ và truyền tải.

🔗 Ví dụ:

Lưu trữ và quản lý chứng chỉ TLS cho một cấu trúc microservices.

Tích hợp với Kubernetes để cấp bí mật động cho Pod mỗi khi khởi chạy.

Tạo mật khẩu tạm thời cho cơ sở dữ liệu nhằm giảm rủi ro bị lộ thông tin.

Ví dụ thực tế:

1⃣ Cấp mật khẩu động cho PostgreSQL bằng Vault

Giả sử bạn có một cơ sở dữ liệu PostgreSQL và muốn cấp tài khoản tạm thời:

1

vault write database/creds/postgres-role

Lệnh này sẽ tạo một tài khoản mới với thời gian tồn tại giới hạn.

2⃣ Sử dụng Vault để quản lý khóa API trong ứng dụng Node.js

Bạn có thể truy xuất khóa API từ Vault trong mã nguồn của mình:

1
2
3


const { execSync } = require('child_process');
const secret = execSync('vault kv get -field=value secret/my-api-key').toString();
console.log(`API Key: ${secret}`);

🔗 Tài nguyên hữu ích:

Công cụ quản lý khoá bí mật trên Cloud

AWS Secrets Manager

Cung cấp dịch vụ lưu trữ và quản lý bí mật an toàn trên AWS với khả năng tự động quay vòng mật khẩu và tích hợp với các dịch vụ AWS khác.

Google Cloud Secret Manager

Giải pháp quản lý bí mật trên Google Cloud, cho phép tự động xoay vòng mật khẩu và kiểm soát truy cập dễ dàng.

Azure Key Vault

Dịch vụ của Microsoft Azure giúp lưu trữ và quản lý khóa, mật khẩu và chứng chỉ số an toàn.

🔗 Ví dụ:

AWS Secrets Manager: Lưu trữ API key của một ứng dụng web, đảm bảo API key không bị lộ trong mã nguồn.

HashiCorp Vault: Quản lý mật khẩu truy cập vào cơ sở dữ liệu PostgreSQL.

Azure Key Vault: Lưu trữ và bảo mật các khóa mã hóa của ứng dụng.

Ví dụ thực tế:

1⃣ Sử dụng AWS Secrets Manager để quản lý khóa API

Giả sử bạn có một ứng dụng web cần truy cập vào dịch vụ bên thứ ba thông qua API key. Thay vì lưu trữ khóa API trong mã nguồn, bạn có thể lưu trữ nó trong AWS Secrets Manager và gọi nó khi cần:

1

aws secretsmanager get-secret-value --secret-id my-api-key

2⃣ Tạo bí mật động với HashiCorp Vault

HashiCorp Vault có thể tạo mật khẩu tạm thời cho cơ sở dữ liệu, giúp tăng cường bảo mật. Ví dụ, bạn có thể tạo một tài khoản tạm thời cho PostgreSQL:

1

vault write database/creds/my-role

🔗 Tài nguyên hữu ích:

📄 AWS Secrets Manager – Dịch vụ quản lý bí mật của AWS
📄 Google Cloud Secret Manager – Dịch vụ quản lý bí mật của Google Cloud
📄 Azure Key Vault – Dịch vụ quản lý khóa và bí mật của Azure
🎥 Demo AWS Secrets Manager – Hướng dẫn sử dụng AWS Secrets Manager
🎥 Google Cloud Secret Manager – Giới thiệu Google Cloud Secret Manager
🎥 Azure Key Vault và cách sử dụng – Hướng dẫn sử dụng Azure Key Vault

Sealed Secrets

Sealed Secrets là một công cụ cho Kubernetes giúp mã hóa dữ liệu nhạy cảm thành các SealedSecrets, có thể lưu trữ an toàn ngay cả trong môi trường công khai như GitHub.

Cách hoạt động:

Mã hóa: Người dùng tạo một SealedSecret từ Kubernetes Secret.
Lưu trữ: SealedSecret có thể được commit vào Git.
Giải mã: Chỉ có Kubernetes Controller trong cluster mới có thể giải mã và khôi phục thành Kubernetes Secret thông thường.

💡 Điểm nổi bật:

Sử dụng mã hóa bất đối xứng đảm bảo chỉ controller có thể giải mã dữ liệu.
Hỗ trợ GitOps giúp quản lý bí mật trong repository Git an toàn.
Dễ dàng tích hợp với Kubernetes để bảo vệ dữ liệu nhạy cảm.

🔗 Tài nguyên hữu ích:

🛠 Sealed Secrets trên GitHub
📄 Tài liệu Sealed Secrets

Tích hợp Secret Management vào CI/CD

Các công cụ CI/CD như Azure DevOps, Travis CI và AWS CodePipeline hỗ trợ quản lý bí mật bằng cách tích hợp với các hệ thống Secret Management để bảo vệ thông tin nhạy cảm trong quá trình triển khai.

Azure DevOps

Azure DevOps cung cấp Azure Key Vault để lưu trữ và quản lý bí mật an toàn. Các pipeline trong Azure DevOps có thể truy xuất bí mật từ Key Vault để sử dụng trong quá trình triển khai.

Travis CI

Travis CI hỗ trợ mã hóa biến môi trường, giúp bảo vệ khóa API và thông tin nhạy cảm trong quá trình build.

AWS CodePipeline

AWS CodePipeline có thể tích hợp với AWS Secrets Manager để truy xuất bí mật trong quá trình triển khai ứng dụng.

Kết luận

Quản lý bí mật đóng vai trò quan trọng trong bảo mật hệ thống hiện đại. Việc sử dụng các công cụ như HashiCorp Vault, AWS Secrets Manager, Google Cloud Secret Manager, Azure Key Vault, Sealed Secrets, Azure DevOps, Travis CI và AWS CodePipeline giúp đảm bảo an toàn cho thông tin nhạy cảm, hỗ trợ triển khai DevOps an toàn và tuân thủ các tiêu chuẩn bảo mật.

👉 Bước tiếp theo: Giám sát hạ tầng Infrastructure Monitoring quá trình theo dõi và phân tích hiệu suất, tính sẵn sàng và trạng thái của các thành phần hạ tầng công nghệ thông tin như máy chủ, mạng, lưu trữ, cơ sở dữ liệu và dịch vụ điện toán đám mây, giúp phát hiện sớm sự cố, tối ưu hóa tài nguyên và đảm bảo hệ thống hoạt động ổn định. 🚀

Quản lý logs (Logs Management)

Mon, 24 Feb 2025 00:00:00 +0000

Quản lý logs là gì?

Quản lý logs là quá trình thu thập, tổng hợp, phân tích, lưu trữ và truy xuất logs từ các ứng dụng và hệ thống hạ tầng. Logs chứa thông tin quan trọng về hoạt động của hệ thống, giúp phát hiện sự cố, tối ưu hóa hiệu suất và đảm bảo tuân thủ bảo mật.

Các công cụ quản lý logs phổ biến

Elastic Stack (ELK Stack)

📝 Giới thiệu: Elastic Stack, trước đây gọi là ELK Stack, bao gồm Elasticsearch (công cụ tìm kiếm và phân tích), Logstash (xử lý dữ liệu), Kibana (trực quan hóa) và Beats (thu thập dữ liệu). Đây là giải pháp phổ biến để quản lý logs với khả năng mở rộng cao.

🔹 Tính năng nổi bật:

Tìm kiếm và phân tích logs theo thời gian thực.
Hỗ trợ nhiều định dạng dữ liệu khác nhau.
Khả năng mở rộng tốt với môi trường doanh nghiệp.
Cung cấp giao diện trực quan với Kibana.

Sử dụng Elastic Stack để thu thập logs từ các máy chủ web, phân tích lỗi và tạo dashboard giám sát lưu lượng truy cập.

📚 Tài nguyên hữu ích:

🔗Trang chủ Elastic Stack
🎥Tổng quan về Elastic Stack

Loki

📝 Giới thiệu: Loki là hệ thống thu thập logs do Grafana Labs phát triển, tối ưu cho Kubernetes và container. Loki không lưu trữ toàn bộ logs mà chỉ lập chỉ mục metadata, giúp tiết kiệm tài nguyên.

🔹 Tính năng nổi bật:

Tích hợp chặt chẽ với Grafana.
Sử dụng LogQL, ngôn ngữ truy vấn tương tự PromQL.
Tối ưu cho môi trường Kubernetes và container.
Tiết kiệm tài nguyên so với các giải pháp khác.

Sử dụng Loki để theo dõi logs từ các container trong Kubernetes, giúp phát hiện lỗi ứng dụng nhanh chóng.

📚 Tài nguyên hữu ích:

🔗Trang chủ Loki
📖Tài liệu Loki

Graylog

📝 Giới thiệu: Graylog là nền tảng quản lý logs mã nguồn mở, hỗ trợ thu thập, lưu trữ và phân tích logs theo thời gian thực. Hệ thống này cung cấp giao diện web thân thiện và hỗ trợ nhiều loại dữ liệu logs khác nhau.

🔹 Tính năng nổi bật:

Hỗ trợ nhiều giao thức thu thập logs như Syslog, GELF.
Giao diện tìm kiếm mạnh mẽ.
Tích hợp tính năng cảnh báo khi phát hiện sự cố.
Hỗ trợ truy vấn logs theo thời gian thực.

Sử dụng Graylog để theo dõi logs từ các hệ thống bảo mật, giúp phát hiện hành vi xâm nhập trái phép.

📚 Tài nguyên hữu ích:

🔗Trang chủ Graylog
🎥Hướng dẫn sử dụng Graylog

Ví dụ về mã nguồn

Dưới đây là cách gửi logs đến một hệ thống thu thập logs bằng JavaScript:

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


const winston = require('winston');

const logger = winston.createLogger({
 level: 'info',
 format: winston.format.json(),
 transports: [
 new winston.transports.Console(),
 new winston.transports.File({ filename: 'app.log' })
 ]
});

// Ghi log
logger.info('Ứng dụng đã khởi động thành công');
logger.warn('Cảnh báo: Dữ liệu đầu vào không hợp lệ');
logger.error('Lỗi: Không thể kết nối cơ sở dữ liệu');

Kết luận

Quản lý logs đóng vai trò quan trọng trong việc giám sát hệ thống và xử lý sự cố nhanh chóng. Các công cụ như Elastic Stack, Loki, và Graylog cung cấp giải pháp mạnh mẽ để thu thập, phân tích và trực quan hóa logs. Việc lựa chọn công cụ phù hợp sẽ giúp nâng cao hiệu quả vận hành hệ thống của bạn. 🚀

👉 Bước tiếp theo: Tìm hiểu về Container Orchestration quá trình tự động quản lý, triển khai, mở rộng và điều phối các container trong môi trường hạ tầng, giúp đảm bảo tính sẵn sàng, khả năng mở rộng và tối ưu tài nguyên hệ thống. Các công cụ phổ biến cho Container Orchestration bao gồm Kubernetes, Docker Swarm và Apache Mesos.

Serverless và các nền tảng liên quan

Mon, 24 Feb 2025 00:00:00 +0000

Serverless là gì?

Serverless là mô hình điện toán đám mây nơi nhà cung cấp dịch vụ quản lý hoàn toàn cơ sở hạ tầng, giúp lập trình viên chỉ cần tập trung vào viết mã. Hệ thống sẽ tự động phân bổ tài nguyên theo nhu cầu và chỉ tính phí dựa trên tài nguyên thực tế sử dụng. Kiến trúc serverless thường được áp dụng cho các ứng dụng microservices, xử lý sự kiện và giúp giảm thiểu chi phí vận hành.

📖 Tài nguyên miễn phí để tìm hiểu:

AWS Lambda

AWS Lambda là một dịch vụ serverless của AWS, cho phép chạy mã mà không cần quản lý máy chủ. Lambda tự động mở rộng theo nhu cầu, hỗ trợ nhiều ngôn ngữ lập trình và dễ dàng tích hợp với các dịch vụ khác của AWS. Nó phù hợp với xử lý dữ liệu, tự động hóa tác vụ, xây dựng microservices.

🖥 Ví dụ: Triển khai một function trên AWS Lambda

1
2
3
4
5
6


import json
def lambda_handler(event, context):
 return {
 'statusCode': 200,
 'body': json.dumps('Hello from AWS Lambda!')
 }

📖 Tài nguyên miễn phí để tìm hiểu:

Cloudflare

Cloudflare là một công ty cung cấp dịch vụ CDN, bảo mật, tối ưu hiệu suất cho website. Cloudflare đóng vai trò là proxy ngược, giúp tăng tốc tải trang và bảo vệ website khỏi các cuộc tấn công. Công ty được thành lập năm 2009 và lên sàn chứng khoán vào năm 2019.

📖 Tài nguyên miễn phí để tìm hiểu:

Vercel

Vercel là nền tảng triển khai frontend giúp đưa các ứng dụng web lên cloud một cách nhanh chóng. Nó hỗ trợ React, Next.js, Vue, Angular, tích hợp với GitHub, và cho phép triển khai chỉ với một lệnh push.

📖 Tài nguyên miễn phí để tìm hiểu:

Kết Luận

Serverless giúp tự động hóa triển khai, giảm chi phí, dễ dàng mở rộng. Các nền tảng phổ biến:

AWS Lambda: Xử lý sự kiện không cần máy chủ.
Cloudflare: CDN và bảo mật website.
Vercel: Triển khai frontend nhanh chóng.

Việc lựa chọn nền tảng phụ thuộc vào nhu cầu, công nghệ và chi phí của bạn. 🚀

👉 Bước tiếp theo: Tìm hiểu về Provisioning quá trình cung cấp và cấu hình tài nguyên (máy chủ, mạng, lưu trữ, tài khoản) để hệ thống hoặc ứng dụng có thể hoạt động hiệu quả.

Application Gateway

Sun, 23 Feb 2025 00:00:00 +0000

Thiết lập các thành phần mạng quan trọng

Bài viết này sẽ giúp bạn biết các thành phần mạng quan trọng:

🔹 Forward Proxy
🔹 Reverse Proxy
🔹 Load Balancer
🔹 Firewall
🔹 Caching Server
🔹 Web Server

Load Balancer

Load Balancer hoạt động như một “cảnh sát giao thông” đứng trước các máy chủ và điều hướng yêu cầu từ khách hàng đến các máy chủ phù hợp. Điều này giúp tối ưu hóa tốc độ, tận dụng tài nguyên hiệu quả và tránh tình trạng quá tải.

🔹 Nếu một máy chủ bị lỗi, Load Balancer sẽ chuyển hướng lưu lượng sang các máy chủ còn lại.

🔹 Có thể triển khai với các thuật toán như Round Robin, Least Connections, IP Hash…

Ví dụ cấu hình Load Balancer với Nginx:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


upstream backend_servers {
 server backend1.example.com;
 server backend2.example.com;
}

server {
 listen 80;
 location / {
 proxy_pass http://backend_servers;
 }
}

📚 Tham khảo thêm:
📄 Load Balancing là gì?
📄 Các thuật toán Load Balancing
📄 Nginx Reverse Proxy & Load Balancing
🎥 Video: Load Balancer hoạt động như thế nào?

Forward Proxy

Forward Proxy là một máy chủ trung gian đứng giữa client và internet, chuyển tiếp yêu cầu từ client đến server đích. Nó giúp ẩn danh, bảo mật, kiểm soát truy cập và caching nội dung.

🔹 Được sử dụng phổ biến trong các mạng doanh nghiệp để giám sát và kiểm soát truy cập.

🔹 Hỗ trợ vượt qua kiểm duyệt và hạn chế địa lý.

Ví dụ cấu hình Forward Proxy với Squid:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


apt update && apt install squid -y

# Chỉnh sửa file cấu hình
nano /etc/squid/squid.conf

# Thêm cấu hình đơn giản
http_access allow all
http_port 3128

# Khởi động lại dịch vụ
systemctl restart squid

📚 Tham khảo thêm:
📄 Forward Proxy là gì?
📄 So sánh Forward Proxy và Reverse Proxy
🎥 Video: Proxy hoạt động như thế nào?

Reverse Proxy

Reverse Proxy là một máy chủ trung gian nhận yêu cầu từ client và chuyển tiếp đến máy chủ backend thích hợp. Nó giúp cân bằng tải, caching, bảo mật và SSL termination.

🔹 Giúp che giấu thông tin của máy chủ backend để tăng cường bảo mật.

🔹 Hỗ trợ phân phối lưu lượng và tối ưu hiệu suất ứng dụng.

Ví dụ cấu hình Reverse Proxy với Nginx:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


server {
 listen 80;
 server_name example.com;

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

📚 Tham khảo thêm:
📄 Reverse Proxy là gì?
📄 Hướng dẫn Nginx Reverse Proxy
🎥 Video: Reverse Proxy và ứng dụng thực tế

Firewall

Firewall là một thiết bị bảo mật mạng giám sát và lọc lưu lượng vào/ra dựa trên chính sách bảo mật của tổ chức.

🔹 Ngăn chặn truy cập trái phép vào hệ thống nội bộ.

🔹 Hỗ trợ các quy tắc kiểm soát lưu lượng dữ liệu.

Ví dụ cấu hình Firewall với UFW (Uncomplicated Firewall):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# Cài đặt UFW
apt install ufw -y

# Mở cổng SSH
ufw allow 22/tcp

# Chặn tất cả kết nối khác
ufw default deny incoming

# Kích hoạt UFW
ufw enable

📚 Tham khảo thêm:
📄 Firewall là gì?
📄 Các loại Firewall phổ biến
🎥 Video: Giới thiệu về Firewall

Nginx

Nginx là một máy chủ web mã nguồn mở, được sử dụng rộng rãi nhờ khả năng xử lý nhiều kết nối đồng thời với hiệu suất cao.

🔹 Hỗ trợ web server, reverse proxy, load balancing, caching.

🔹 Thích hợp cho hệ thống microservices và container.

Ví dụ cấu hình Nginx đơn giản:

1
2
3
4
5
6


server {
 listen 80;
 server_name example.com;
 root /var/www/html;
 index index.html;
}

📚 Tham khảo thêm:
📄 Hướng dẫn cài đặt Nginx trên Ubuntu
🎥 Video: Nginx trong 100 giây

Apache

Apache là một trong những máy chủ web phổ biến nhất, hỗ trợ nhiều module mở rộng và tương thích với nhiều hệ điều hành.

🔹 Dễ dàng cấu hình với file .conf.

🔹 Hỗ trợ SSL/TLS, xác thực người dùng, URL rewriting…

Ví dụ cấu hình Apache đơn giản:

1
2
3
4
5
6
7
8


<VirtualHost *:80>
 ServerName example.com
 DocumentRoot /var/www/html
 <Directory /var/www/html>
 AllowOverride All
 Require all granted
 </Directory>
</VirtualHost>

📚 Tham khảo thêm:
📄 Trang chủ Apache
🎥 Video: Cài đặt Apache trên Ubuntu

Kết luận

🔹 Load Balancer giúp phân phối lưu lượng hiệu quả, giảm tải cho máy chủ.
🔹 Forward Proxy hỗ trợ ẩn danh, caching và kiểm soát truy cập từ client.
🔹 Reverse Proxy giúp tăng cường bảo mật, caching và tối ưu hệ thống backend.
🔹 Firewall bảo vệ hệ thống khỏi truy cập trái phép.
🔹 Nginx & Apache là hai web server phổ biến, phục vụ nội dung web và ứng dụng.

Bằng cách triển khai các thành phần này, bạn có thể xây dựng một hệ thống mạng mạnh mẽ, bảo mật và hiệu quả. 🚀

👉 Bước tiếp theo: Tìm hiểu về Networking Protocols tập hợp các quy tắc và tiêu chuẩn xác định cách các thiết bị trong mạng giao tiếp với nhau. Chúng đảm bảo dữ liệu được truyền tải chính xác, an toàn và hiệu quả giữa các hệ thống khác nhau.

Containers, Docker và LXC

Sun, 23 Feb 2025 00:00:00 +0000

Containers, Docker và LXC

Containers là môi trường nhẹ, di động và cách ly giúp đóng gói ứng dụng cùng với tất cả các phụ thuộc của chúng, đảm bảo triển khai đồng nhất trên nhiều môi trường khác nhau. Công nghệ container giúp đơn giản hóa quá trình triển khai ứng dụng, hỗ trợ mô hình kiến trúc microservices, và tối ưu hóa tài nguyên hệ thống.

Containers là gì?

Containers là một phương pháp ảo hóa ở cấp độ hệ điều hành, cho phép chạy nhiều ứng dụng cô lập trên cùng một kernel. Không giống như máy ảo (VM) yêu cầu hệ điều hành riêng biệt cho mỗi môi trường, container chỉ sử dụng nhân hệ điều hành của máy chủ, giúp giảm chi phí tài nguyên và tăng hiệu suất.

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

🏋 Nhẹ: Chia sẻ kernel với hệ điều hành máy chủ, giảm bớt tài nguyên tiêu thụ.
🚀 Di động: Chạy nhất quán trên nhiều nền tảng từ máy cá nhân đến cloud.
🔒 Cô lập: Ứng dụng và thư viện được đóng gói riêng biệt.
📈 Hiệu suất cao: Không cần khởi động hệ điều hành riêng biệt như máy ảo.

Docker - Nền tảng container phổ biến nhất

Docker là một nền tảng mã nguồn mở giúp tự động hóa việc triển khai ứng dụng bằng cách sử dụng công nghệ container. Docker giúp đóng gói ứng dụng với toàn bộ thư viện và cấu hình cần thiết để chạy trên nhiều môi trường khác nhau.

Tính năng nổi bật của Docker

📦 Docker Engine: Công cụ để tạo và chạy container.
🔄 Docker Compose: Quản lý nhiều container trong một ứng dụng.
🏗 Docker Hub: Kho lưu trữ và chia sẻ hình ảnh container.

Ví dụ sử dụng Docker:

1

docker run -d -p 80:80 nginx

Lệnh trên sẽ chạy một container Nginx trên cổng 80.

📚 Tài nguyên hữu ích:

📖 Tài liệu Docker
🎥 Docker trong 5 phút

LXC - Linux Containers

LXC (Linux Containers) là một phương pháp ảo hóa cấp hệ điều hành cho phép chạy nhiều hệ thống Linux cô lập trên cùng một kernel.

Đặc điểm của LXC:

🏗 Tạo môi trường gần giống máy ảo nhưng hiệu suất cao hơn.
⚡ Khởi động nhanh hơn so với VM truyền thống.
🔍 Sử dụng các công nghệ của Linux như cgroups và namespaces.

Ví dụ tạo một container LXC:

1
2


lxc-create -n my-container -t ubuntu
lxc-start -n my-container -d

📚 Tài nguyên hữu ích:

📖 Trang chủ LXC
🎥 Hướng dẫn sử dụng LXC

Kết luận

Containers giúp triển khai ứng dụng nhanh chóng, hiệu quả và tiết kiệm tài nguyên. Docker là lựa chọn phổ biến cho phát triển ứng dụng, trong khi LXC phù hợp hơn cho mô phỏng hệ điều hành đầy đủ. Hãy chọn công cụ phù hợp với nhu cầu của bạn! 🚀

👉 Bước tiếp theo: Tìm hiểu về Application Gateway một dịch vụ quản lý traffic tầng ứng dụng giúp tối ưu hóa, bảo mật và kiểm soát luồng truy cập giữa client và backend. Nó có thể đóng vai trò như một reverse proxy, bảo vệ hệ thống và đảm bảo request được xử lý đúng cách.

Dịch vụ Cloud

Sun, 23 Feb 2025 00:00:00 +0000

Cloud Providers

Các nhà cung cấp dịch vụ đám mây cung cấp một lớp API để trừu tượng hóa cơ sở hạ tầng, giúp triển khai tài nguyên dựa trên các tiêu chuẩn bảo mật và mô hình thanh toán. Dù thực tế các dịch vụ đám mây chạy trên các máy chủ trong trung tâm dữ liệu, nhưng nhờ vào các lớp trừu tượng, chúng tạo cảm giác như đang tương tác với một nền tảng duy nhất. Khả năng triển khai, cấu hình và bảo mật tài nguyên nhanh chóng đã giúp cloud trở thành yếu tố quan trọng trong thành công và sự phức tạp của DevOps hiện đại.

📖 Tài nguyên miễn phí để tìm hiểu:

AWS (Amazon Web Services)

AWS là nền tảng điện toán đám mây hàng đầu từ năm 2011, vượt xa Azure và Google Cloud. AWS cung cấp hơn 200 dịch vụ, hoạt động trên quy mô toàn cầu. AWS mang đến giải pháp tính toán linh hoạt và tiết kiệm chi phí, bao gồm: sức mạnh tính toán, lưu trữ dữ liệu, phân phối nội dung, v.v.

🖥 Ví dụ: Tạo một EC2 instance bằng AWS CLI

1

aws ec2 run-instances --image-id ami-12345678 --count 1 --instance-type t2.micro --key-name MyKeyPair --security-groups MySecurityGroup

📖 Tài nguyên miễn phí để tìm hiểu:

Microsoft Azure

Azure là nền tảng điện toán đám mây của Microsoft, cung cấp IaaS, PaaS, SaaS cùng nhiều dịch vụ như phân tích, AI, máy học, bảo mật. Azure hỗ trợ nhiều công cụ và ngôn ngữ lập trình, giúp doanh nghiệp phát triển nhanh chóng.

🖥 Ví dụ: Triển khai ứng dụng trên Azure App Service

1

az webapp create --resource-group MyResourceGroup --plan MyAppServicePlan --name MyUniqueApp --runtime "PYTHON:3.8"

📖 Tài nguyên miễn phí để tìm hiểu:

Google Cloud Platform (GCP)

Google Cloud cung cấp hơn 150 dịch vụ, hoạt động trên cùng hạ tầng với các sản phẩm của Google như Search, Gmail, YouTube. Dịch vụ bao gồm: VMs, cơ sở dữ liệu, AI/ML, Kubernetes, v.v.

🖥 Ví dụ: Tạo một VM trên Google Cloud

1

gcloud compute instances create my-instance --machine-type=e2-medium --image-project=debian-cloud --image-family=debian-11

📖 Tài nguyên miễn phí để tìm hiểu:

🔗 Trang chủ Google Cloud
📖 5 mẹo để trở thành Google Cloud Certified
🎥 Khóa học Google Cloud Platform - 2023
🌍 Bài viết hay về Google Cloud

DigitalOcean

DigitalOcean là nhà cung cấp cơ sở hạ tầng đám mây tập trung vào sự đơn giản, chi phí thấp, dễ sử dụng. DigitalOcean cung cấp dịch vụ như máy ảo (Droplets), cơ sở dữ liệu, Kubernetes, lưu trữ đối tượng, phù hợp với startup và developer.

🖥 Ví dụ: Tạo một Droplet trên DigitalOcean bằng API

1

curl -X POST -H "Content-Type: application/json" -H "Authorization: Bearer YOUR_TOKEN" -d '{"name":"example-droplet","region":"nyc3","size":"s-1vcpu-1gb","image":"ubuntu-20-04-x64"}' "https://api.digitalocean.com/v2/droplets"

📖 Tài nguyên miễn phí để tìm hiểu:

🔗 Trang chủ DigitalOcean
📄 Hacktoberfest của DigitalOcean
🎥 Hướng dẫn Kubernetes trên DigitalOcean
🌍 Bài viết hay về DigitalOcean

Kết Luận

Các nhà cung cấp dịch vụ cloud như AWS, Azure, GCP, DigitalOcean cung cấp giải pháp linh hoạt cho mọi nhu cầu máy chủ, lưu trữ, AI, DevOps. Mỗi nền tảng có ưu điểm riêng:

AWS: Toàn diện, nhiều dịch vụ nhất.
Azure: Tích hợp tốt với hệ sinh thái Microsoft.
GCP: Tối ưu cho AI, dữ liệu lớn.
DigitalOcean: Đơn giản, phù hợp với startup.

Việc chọn nền tảng phù hợp phụ thuộc vào mục tiêu, ngân sách, nhu cầu kỹ thuật của bạn. 🚀

👉 Bước tiếp theo: Tìm hiểu về Serverless mô hình điện toán đám mây cho phép chạy ứng dụng mà không cần quản lý máy chủ. Các nhà cung cấp cloud tự động phân bổ tài nguyên, mở rộng quy mô và tính phí dựa trên lượng tài nguyên thực tế được sử dụng, giúp tối ưu chi phí và đơn giản hóa triển khai.

Dịch vụ lưu trữ mã nguồn

Sun, 23 Feb 2025 00:00:00 +0000

Dịch vụ lưu trữ mã nguồn (Repo Hosting Services)

Khi làm việc nhóm, bạn cần một nơi lưu trữ mã nguồn từ xa để mọi người có thể truy cập, tạo nhánh riêng, cũng như tạo hoặc xem xét các pull request. Các dịch vụ này thường bao gồm theo dõi vấn đề (issue tracking), đánh giá mã (code review) và tích hợp liên tục (CI/CD). Một số lựa chọn phổ biến gồm GitHub, GitLab, Bitbucket và AWS CodeCommit.

📚 Tài nguyên miễn phí để tìm hiểu thêm:

🔗 GitHub
🔗 GitLab
🔗 BitBucket
🎥 GitHub vs GitLab vs Bitbucket - Nên chọn cái nào?

GitHub

GitHub là một nền tảng quản lý mã nguồn dựa trên Git, cung cấp dịch vụ lưu trữ kho mã trên nền tảng đám mây. Nó hỗ trợ các tính năng như theo dõi lỗi, quản lý nhiệm vụ, và wiki dự án. GitHub cho phép đánh giá mã qua pull request, theo dõi vấn đề và hỗ trợ lập trình cộng tác với các tính năng như fork và star.

GitHub hỗ trợ cả kho mã công khai và riêng tư, giúp nó trở thành lựa chọn phổ biến cho cả dự án mã nguồn mở và phát triển cá nhân. Hệ sinh thái GitHub bao gồm:

🚀 GitHub Actions: Tự động hóa quy trình làm việc.
📦 GitHub Packages: Quản lý gói phần mềm.
🌐 GitHub Pages: Lưu trữ trang web tĩnh miễn phí.

📚 Tài nguyên miễn phí để tìm hiểu thêm:

🗺 Lộ trình Git & GitHub
🔗 Trang chủ GitHub
📖 Cách sử dụng Git trong nhóm phát triển chuyên nghiệp
🎥 GitHub là gì?
📰 Bài viết hay về GitHub

GitLab

GitLab là một công cụ DevOps toàn diện, cung cấp quản lý kho mã Git kèm theo wiki, theo dõi vấn đề và các tính năng CI/CD tích hợp sẵn. Đây là một nền tảng DevOps hoàn chỉnh, bao gồm tất cả các giai đoạn từ lập kế hoạch, phát triển, kiểm thử đến triển khai và giám sát.

GitLab hỗ trợ cả phiên bản đám mây và tự lưu trữ, phù hợp với các tổ chức có yêu cầu bảo mật cao. Một số tính năng nổi bật của GitLab gồm:

🔄 Tích hợp CI/CD: Hỗ trợ kiểm thử và triển khai tự động.
📦 Container & Package Registry: Quản lý và lưu trữ gói phần mềm.
🔎 Quét bảo mật mã nguồn: Phát hiện lỗ hổng trong code.

📚 Tài nguyên miễn phí để tìm hiểu thêm:

Bitbucket

Bitbucket là một dịch vụ lưu trữ kho mã nguồn của Atlassian, hỗ trợ cả Git và Mercurial. Nó tích hợp chặt chẽ với các công cụ Atlassian khác như Jira và Trello, giúp quản lý dự án dễ dàng hơn. Bitbucket cung cấp cả phiên bản đám mây và tự lưu trữ.

Một số tính năng đáng chú ý của Bitbucket:

🔍 Code Review & Pull Requests: Hỗ trợ đánh giá mã.
🔄 Bitbucket Pipelines: CI/CD tích hợp sẵn.
📖 Wiki & Issue Tracking: Quản lý tài liệu và theo dõi vấn đề.
🔐 Hỗ trợ repo riêng tư miễn phí: Phù hợp với nhóm nhỏ.

📚 Tài nguyên miễn phí để tìm hiểu thêm:

Kết luận

Việc lựa chọn dịch vụ lưu trữ kho mã nguồn phụ thuộc vào nhu cầu của nhóm phát triển. Nếu bạn cần một nền tảng phổ biến với hệ sinh thái rộng lớn, GitHub là một lựa chọn mạnh mẽ. Nếu muốn một giải pháp DevOps tích hợp đầy đủ, GitLab sẽ phù hợp hơn. Còn nếu bạn đã sử dụng hệ sinh thái Atlassian, Bitbucket sẽ là lựa chọn tốt nhất.

Hãy cân nhắc nhu cầu dự án và mức độ tích hợp mong muốn để đưa ra quyết định phù hợp! 🚀

👉 Bước tiếp theo: Tìm hiểu về Containers giúp đóng gói ứng dụng cùng với tất cả các thư viện, cấu hình và dependencies để chạy nhất quán trên nhiều môi trường khác nhau.

Giao thức mạng (Networking Protocols)

Sun, 23 Feb 2025 00:00:00 +0000

Giao thức mạng (Networking Protocols)

Giao thức mạng là tập hợp các quy tắc chuẩn hóa giúp dữ liệu được truyền, nhận và hiểu đúng cách trên các mạng máy tính. Chúng xác định định dạng, thời gian, trình tự và kiểm soát lỗi trong quá trình truyền dữ liệu. Một số giao thức quan trọng bao gồm:

TCP/IP: Bộ giao thức nền tảng cho giao tiếp trên Internet.
HTTP/HTTPS: Giao thức truyền tải siêu văn bản dùng cho web.
FTP/SFTP: Giao thức truyền tải tệp tin.
SMTP/POP3/IMAP: Giao thức truyền tải email.
DNS: Giao thức phân giải tên miền.
DHCP: Giao thức cấp phát địa chỉ IP tự động.
SSL/TLS: Giao thức bảo mật dữ liệu.
UDP: Giao thức truyền tải không kết nối, nhanh chóng.

Hệ thống tên miền (DNS)

DNS (Domain Name System) là hệ thống phân giải tên miền, giúp chuyển đổi tên miền dễ nhớ (vd: www.example.com) thành địa chỉ IP (192.168.1.1) mà máy tính có thể hiểu được.

Ví dụ cấu hình DNS trong Linux:

1
2
3
4
5
6
7
8
9


# Kiểm tra DNS của một tên miền
nslookup example.com

dig example.com

# Chỉnh sửa file hosts để ánh xạ tên miền
sudo nano /etc/hosts
# Thêm dòng sau:
192.168.1.100 mycustomdomain.com

🔗 Tài nguyên tham khảo:

Giao thức HTTP

HTTP (Hypertext Transfer Protocol) là giao thức truyền tải dữ liệu trên web theo mô hình yêu cầu - phản hồi.

Ví dụ gửi yêu cầu HTTP bằng cURL:

1
2
3
4
5
6
7


# Gửi yêu cầu GET
curl -X GET https://jsonplaceholder.typicode.com/posts/1

# Gửi yêu cầu POST
curl -X POST https://jsonplaceholder.typicode.com/posts \
 -H "Content-Type: application/json" \
 -d '{"title": "Hello", "body": "World"}'

🔗 Tài nguyên tham khảo:

HTTPS và bảo mật (SSL/TLS)

HTTPS là phiên bản bảo mật của HTTP, sử dụng SSL/TLS để mã hóa dữ liệu, đảm bảo an toàn khi truyền tải trên Internet.

Ví dụ thiết lập HTTPS với Nginx:

1
2
3
4
5
6


server {
 listen 443 ssl;
 server_name example.com;
 ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
 ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
}

🔗 Tài nguyên tham khảo:

SSH - Kết nối bảo mật

SSH (Secure Shell) là giao thức giúp kết nối an toàn đến máy chủ từ xa.

Ví dụ sử dụng SSH để kết nối từ xa:

1
2
3
4
5


# Kết nối đến máy chủ từ xa
ssh user@example.com

# Sao chép tệp tin từ máy chủ về máy cục bộ
scp user@example.com:/path/to/file ./localfile

🔗 Tài nguyên tham khảo:

Kết Luận

Giao thức mạng là nền tảng của mọi hệ thống trực tuyến, từ duyệt web đến gửi email. Hiểu và biết cách sử dụng chúng giúp cải thiện bảo mật và hiệu suất của hệ thống. Hãy thử áp dụng các lệnh trên để kiểm tra và cấu hình hệ thống của bạn! 🚀

👉 Bước tiếp theo: Tìm hiểu về Cloud Providers các công ty cung cấp dịch vụ điện toán đám mây, cho phép cá nhân và doanh nghiệp truy cập tài nguyên như máy chủ, lưu trữ, cơ sở dữ liệu, AI, và các dịch vụ khác qua internet mà không cần đầu tư hạ tầng phần cứng.

Hệ thống quản lý phiên bản (Version Control Systems)

Sun, 23 Feb 2025 00:00:00 +0000

Hệ thống quản lý phiên bản (Version Control Systems)

Version control systems (VCS) là các công cụ giúp theo dõi sự thay đổi của mã nguồn và tệp theo thời gian. Chúng hỗ trợ làm việc nhóm, quản lý lịch sử thay đổi và duy trì nhiều phiên bản của mã nguồn. Có hai loại VCS chính:

Hệ thống tập trung (Centralized VCS - CVCS): Sử dụng một kho lưu trữ trung tâm, ví dụ như Subversion (SVN), CVS.
Hệ thống phân tán (Distributed VCS - DVCS): Mỗi người dùng có một bản sao đầy đủ của kho lưu trữ, bao gồm toàn bộ lịch sử. Ví dụ phổ biến nhất là Git.

Git là một hệ thống quản lý phiên bản phân tán mạnh mẽ, cho phép làm việc ngoại tuyến, hỗ trợ nhanh chóng các thao tác nhánh (branching) và hợp nhất (merging), giúp tăng cường khả năng cộng tác.

Git - Công Cụ Quản Lý Phiên Bản Phổ Biến Nhất

Cài Đặt Git

Nếu chưa cài đặt Git, bạn có thể tải về từ git-scm.com hoặc sử dụng lệnh sau:

1
2
3


sudo apt install git # Ubuntu/Debian
yum install git # CentOS/RHEL
brew install git # macOS

Xác nhận cài đặt Git:

1
2
3
4


git --version

# output: 
# git version 2.47.1.windows.1

Các Lệnh Cơ Bản Trong Git

Dưới đây là các lệnh Git phổ biến, được sắp xếp từ cơ bản đến nâng cao:

Khởi Tạo & Cấu Hình

1

git init # Khởi tạo kho lưu trữ Git

1
2


git config --global user.name "Tên Của Bạn" # Cấu hình tên
git config --global user.email "email@example.com" # Cấu hình email

Làm Việc Với Kho Lưu Trữ

1

git clone <repo_url> # Sao chép một kho lưu trữ từ xa về máy

1

git status # Kiểm tra trạng thái của các tệp

Thêm & Lưu Thay Đổi

1

git add <file> # Thêm tệp vào vùng tạm

1

git commit -m "Mô tả thay đổi" # Lưu thay đổi vào lịch sử

Làm Việc Với Kho Lưu Trữ Từ Xa

1

git remote add origin <repo_url> # Liên kết kho lưu trữ từ xa

1

git push -u origin main # Đẩy thay đổi lên nhánh chính

1

git pull origin main # Cập nhật thay đổi mới nhất từ kho lưu trữ từ xa

Làm Việc Với Nhánh

1

git branch new-feature # Tạo nhánh mới

1

git checkout new-feature # Chuyển sang nhánh mới

1

git merge new-feature # Gộp nhánh vào nhánh hiện tại

Theo Dõi Lịch Sử

1

git log # Xem lịch sử commit

1

git diff # So sánh thay đổi giữa các phiên bản

Tài Nguyên Học Git Miễn Phí

Kết Luận

Sử dụng Git giúp quản lý mã nguồn dễ dàng hơn, hỗ trợ làm việc nhóm hiệu quả và bảo vệ dữ liệu quan trọng của dự án. Việc hiểu và thành thạo Git là kỹ năng cần thiết cho mọi lập trình viên.

👉 Bước tiếp theo: Tìm hiểu về GitHub & GitLab để quản lý kho lưu trữ Git trên nền tảng đám mây.

Kiến thức về Terminal

Sun, 23 Feb 2025 00:00:00 +0000

Kiến thức về Terminal

Terminal là một giao diện văn bản giúp người dùng tương tác với hệ thống máy tính thông qua CLI (Command Line Interface - Giao diện dòng lệnh). Đây là công cụ quan trọng để quản lý hệ thống, thực thi lệnh, và tự động hóa các tác vụ.

Tài Nguyên Miễn Phí

🔹 Ví dụ:

1
2


ls -l # Liệt kê tệp trong thư mục hiện tại
pwd # Hiển thị đường dẫn thư mục hiện tại

Giám Sát Tiến Trình (Process Monitoring)

Giám sát tiến trình là quá trình quan sát và phân tích liên tục các tiến trình trong hệ thống IT để đảm bảo hiệu suất, hiệu quả và tuân thủ quy định. Nó giúp theo dõi các thông số quan trọng như tài nguyên sử dụng, hành vi của từng tiến trình hoặc ứng dụng đang chạy trong hệ thống.

Công Cụ Được Đề Xuất

🟣 lsof - Liệt kê thông tin về các tệp được mở bởi tiến trình.

Tài Nguyên Miễn Phí

🔹 Ví dụ:

1
2


lsof -i :80 # Liệt kê tiến trình sử dụng cổng 80
ps aux # Hiển thị tất cả tiến trình đang chạy

Giám Sát Hiệu Suất (Performance Monitoring)

Giám sát hiệu suất giúp thu thập, phân tích và báo cáo các chỉ số hiệu suất chính từ ứng dụng, mạng, máy chủ và cơ sở dữ liệu.

Công Cụ Được Đề Xuất

🟣 vmstat - Công cụ theo dõi bộ nhớ ảo và hiệu suất hệ thống.

Tài Nguyên Miễn Phí

🔹 Ví dụ:

1

vmstat 5 10 # Cập nhật trạng thái hệ thống mỗi 5 giây trong 10 lần

Công Cụ Mạng (Networking Tools)

Các công cụ mạng hỗ trợ giám sát, phân tích, khắc phục sự cố và quản lý hệ thống mạng.

Công Cụ Được Đề Xuất

🟣 Wireshark - Phân tích gói tin sâu.
🟣 Nmap - Quét mạng và kiểm tra bảo mật.
Ping - Kiểm tra kết nối cơ bản.
Traceroute - Xác định đường đi của gói tin trong mạng.
Netstat - Hiển thị kết nối mạng.
Tcpdump - Ghi và phân tích gói tin trên dòng lệnh.
Iperf - Kiểm tra hiệu suất mạng.
Netcat - Thực hiện nhiều tác vụ mạng khác nhau.
Nslookup/Dig - Truy vấn DNS.
PuTTY - Kết nối từ xa qua SSH hoặc Telnet.

🔹 Ví dụ:

1
2


ping google.com # Kiểm tra kết nối đến Google
nmap -sS 192.168.1.1 # Quét cổng máy chủ nội bộ

Xử Lý Văn Bản (Text Manipulation)

Các công cụ hỗ trợ chỉnh sửa, xử lý và chuyển đổi dữ liệu văn bản.

Công Cụ Được Đề Xuất

🟣 sed - Chỉnh sửa luồng dữ liệu.
🟣 awk - Quét mẫu và trích xuất dữ liệu.
🟣 grep - Tìm kiếm văn bản bằng biểu thức chính quy.
cut, sort, tr, uniq - Các lệnh hỗ trợ xử lý dữ liệu văn bản.

🔹 Ví dụ:

1
2


grep "error" logfile.txt # Tìm từ "error" trong logfile.txt
awk '{print $1}' data.txt # Lấy cột đầu tiên từ file data.txt

Bash Scripts

Bash là một shell mạnh mẽ trên Unix/Linux, giúp thực hiện lệnh và tự động hóa tác vụ.

🔹 Ví dụ:

1
2


#!/bin/bash
echo "Hello, World!"

Trình Soạn Thảo (Editors)

Trình soạn thảo văn bản là công cụ quan trọng để chỉnh sửa và quản lý tệp văn bản.

Công Cụ Được Đề Xuất

🟣 Vim - Mạnh mẽ, tùy biến cao, phù hợp cho lập trình viên.
🟣 Emacs - Linh hoạt, có nhiều plugin hỗ trợ.
Sublime Text - Tốc độ cao, giao diện thân thiện.
Visual Studio Code - Mã nguồn mở, hỗ trợ gỡ lỗi, mở rộng, tích hợp công cụ phát triển.

🔹 Ví dụ:

1
2


vim myfile.txt # Mở tệp bằng Vim
nano myfile.txt # Mở tệp bằng Nano

Kết Luận

Hiểu và sử dụng thành thạo các công cụ trên giúp bạn làm việc hiệu quả hơn trong môi trường Linux và DevOps. Các công cụ 🟣 được đánh dấu là những công cụ phổ biến và mạnh mẽ nhất, được nhiều chuyên gia khuyến nghị. Bạn có thể tìm hiểu sâu hơn thông qua các tài nguyên miễn phí đi kèm. Nếu có điều gì cần làm rõ hoặc bổ sung, hãy phản hồi để mình cập nhật nhé!

👉 Bước tiếp theo: Nâng cao kiến thức về hệ thống quản lý phiên bản (Version Control Systems) để theo dõi, quản lý và cộng tác hiệu quả trên mã nguồn.

Học về Linux & Hệ Điều Hành

Sat, 22 Feb 2025 00:00:00 +0000

Tại sao Linux quan trọng trong DevOps?

Linux là nền tảng của hầu hết các hệ thống server, container (Docker, Kubernetes), và cloud. DevOps cần nắm vững Linux để:

✅ Quản lý server hiệu quả.
✅ Viết script tự động hóa.
✅ Xử lý file, user, tiến trình.
✅ Tối ưu hệ thống và bảo mật.

Hệ điều hành là gì?

Hệ điều hành (OS) là phần mềm quản lý tài nguyên phần cứng và phần mềm của máy tính, cung cấp dịch vụ chung cho các chương trình. Nó đóng vai trò trung gian giữa ứng dụng và phần cứng, xử lý các nhiệm vụ như:

🔹 Quản lý bộ nhớ.
🔹 Lập lịch tiến trình.
🔹 Quản lý hệ thống file.
🔹 Kiểm soát thiết bị.

Các hệ điều hành phổ biến:

💻 Máy tính cá nhân: Windows, macOS, Linux (Ubuntu, Fedora,…)
📱 Thiết bị di động: iOS, Android
🖥 Máy chủ: Ubuntu Server, Red Hat Enterprise Linux, Windows Server

Mỗi hệ điều hành có đặc điểm, giao diện và khả năng tương thích khác nhau. Chúng đóng vai trò quan trọng trong bảo mật hệ thống, tối ưu hiệu suất và cung cấp trải nghiệm người dùng nhất quán.

Các lệnh Linux cơ bản

Dưới đây là một số lệnh Linux quan trọng:

Kiểm tra hệ thống

1
2
3


uname -a # Hiển thị thông tin hệ điều hành
uptime # Thời gian hoạt động của hệ thống
free -m # Kiểm tra bộ nhớ RAM

Quản lý file & thư mục

1
2
3


ls -l # Liệt kê file với thông tin chi tiết
mkdir mydir # Tạo thư mục mới
rm -rf mydir # Xóa thư mục và nội dung bên trong

Quản lý tiến trình

1
2
3


top # Hiển thị tiến trình đang chạy
ps aux # Liệt kê tất cả tiến trình
kill -9 PID # Dừng tiến trình theo PID

Quản lý người dùng

1
2
3


whoami # Xem user hiện tại
sudo useradd devops # Tạo user mới
sudo passwd devops # Đặt mật khẩu cho user

Script Bash kiểm tra tài nguyên hệ thống

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


#!/bin/bash

echo "==== Thông tin hệ thống ===="
uname -a

echo "==== Thời gian hoạt động ===="
uptime

echo "==== Bộ nhớ RAM ===="
free -m

▶ Cách chạy script:

1
2


chmod +x system_check.sh # Cấp quyền thực thi cho script
./system_check.sh # Chạy script trong terminal

Tài nguyên học tập

Dưới đây là một số tài nguyên miễn phí để tìm hiểu thêm về hệ điều hành:

Kết luận

✅ Linux là kỹ năng bắt buộc trong DevOps.
✅ Học cách dùng terminal & Bash scripting.

👉 Bước tiếp theo: Tìm hiểu sâu hơn về terminal và cách sử dụng CLI để làm việc hiệu quả với hệ thống.

Chọn ngôn ngữ lập trình

Fri, 21 Feb 2025 00:00:00 +0000

Tại sao cần chọn ngôn ngữ lập trình?

Trong DevOps, bạn sẽ cần sử dụng ngôn ngữ lập trình để:

✅ Viết script tự động hóa.
✅ Quản lý server và cloud.
✅ Tạo tool hỗ trợ CI/CD.
✅ Xây dựng và triển khai hạ tầng dưới dạng code (Infrastructure as Code - IaC).

Việc chọn ngôn ngữ phù hợp giúp bạn làm việc hiệu quả hơn với hệ thống, tự động hóa nhiều quy trình và cải thiện tốc độ phát triển phần mềm.

Ngôn ngữ phù hợp cho DevOps

Python (Khuyến nghị chính)

Lý do chọn Python:

Cú pháp dễ đọc, dễ học.
Thư viện phong phú hỗ trợ tự động hóa như fabric, paramiko, boto3 (AWS SDK), pyinfra.
Hỗ trợ mạnh mẽ trong quản lý Cloud (AWS, GCP, Azure).

Ứng dụng thực tế:

Viết script deploy code tự động.
Tạo bot quản lý server.
Xây dựng API quản lý hệ thống.

Ví dụ: Script SSH tự động deploy với Paramiko

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


import paramiko

def deploy_code(host, user, password, command):
 client = paramiko.SSHClient()
 client.set_missing_host_key_policy(paramiko.AutoAddPolicy())
 client.connect(hostname=host, username=user, password=password)
 stdin, stdout, stderr = client.exec_command(command)
 print(stdout.read().decode())
 client.close()

deploy_code('192.168.1.100', 'ubuntu', 'yourpassword', 'git pull origin main && systemctl restart app')

Bash (Cần biết cơ bản)

Lý do chọn Bash:

Là shell script phổ biến nhất trên Linux.
Giúp bạn thao tác nhanh với hệ thống.
Tối ưu cho quản lý server và tự động hóa task nhỏ.

Ứng dụng thực tế:

Viết script tự động update server.
Tạo cron job chạy định kỳ.
Quản lý user và permission trên Linux.

Ví dụ: Script tự động update server

1
2


#!/bin/bash
sudo apt update && sudo apt upgrade -y

Go (Golang) (Nếu làm với Kubernetes)

Lý do chọn Go:

Hiệu suất cao, dễ dàng biên dịch thành binary nhỏ gọn.
Kubernetes và nhiều công cụ DevOps như Terraform được viết bằng Go.

Ứng dụng thực tế:

Viết tool quản lý container.
Tạo plugin cho Kubernetes.
Xây dựng các công cụ DevOps riêng.

Ví dụ: In ra thông tin hệ thống bằng Go

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


package main
import (
 "fmt"
 "os"
)

func main() {
 hostname, _ := os.Hostname()
 fmt.Println("Hostname:", hostname)
}

Groovy (Nếu làm việc với Jenkins)

Lý do chọn Groovy:

Là ngôn ngữ chính để viết pipeline trong Jenkins.
Cú pháp linh hoạt, dễ dàng mở rộng và tích hợp với Java.

Ứng dụng thực tế:

Viết pipeline CI/CD cho Jenkins.
Tạo script quản lý hệ thống.
Tự động hóa các bước build, test, deploy.

Ví dụ: Pipeline cơ bản trong Jenkinsfile

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


pipeline {
 agent any
 stages {
 stage('Build') {
 steps {
 echo 'Building the project...'
 sh 'mvn clean package'
 }
 }
 stage('Test') {
 steps {
 echo 'Running tests...'
 sh 'mvn test'
 }
 }
 stage('Deploy') {
 steps {
 echo 'Deploying application...'
 sh './deploy.sh'
 }
 }
 }
}

Kết luận

✅ Python + Bash là lựa chọn tốt nhất để bắt đầu DevOps.
✅ Nếu làm việc với Kubernetes, học thêm Go.
✅ Nếu làm việc với Jenkins, học Groovy để viết pipeline.

👉 Bước tiếp theo: Học cơ bản về Linux & hệ điều hành.

Lộ trình trở thành DevOps engineer

Thu, 20 Feb 2025 00:00:00 +0000

Hiểu về DevOps

DevOps là sự kết hợp giữa phát triển phần mềm (development) và vận hành hệ thống (operations), nhằm tăng cường sự hợp tác và tự động hóa trong quy trình phát triển và triển khai phần mềm.

Học một ngôn ngữ lập trình

Việc thành thạo ít nhất một ngôn ngữ lập trình là cần thiết để tự động hóa và quản lý hệ thống hiệu quả.

Ngôn ngữ phổ biến

Python
Go
Ruby

Nắm vững kiến thức về hệ điều hành

Linux: Hệ điều hành phổ biến trong môi trường server.
Windows: Quan trọng trong các doanh nghiệp sử dụng hạ tầng Microsoft.

Tìm hiểu về mạng máy tính và bảo mật

Các chủ đề cần quan tâm:

Giao thức mạng: HTTP, HTTPS, FTP, TCP/IP.
Bảo mật mạng: Tường lửa, VPN, SSL/TLS.

Sử dụng các công cụ quản lý mã nguồn

Quản lý mã nguồn hiệu quả là yếu tố quan trọng trong DevOps.

Git: Hệ thống quản lý phiên bản phổ biến.

Hiểu về quản lý cấu hình và hạ tầng như mã

Tự động hóa cấu hình giúp duy trì sự nhất quán và hiệu quả.

Ansible: Công cụ tự động hóa.
Terraform: Quản lý hạ tầng bằng cách định nghĩa nó trong mã nguồn.

Thành thạo containerization và orchestration

Docker: Nền tảng container phổ biến.
Kubernetes: Hệ thống điều phối container mạnh mẽ.

Thiết lập và quản lý CI/CD

Jenkins: Máy chủ tự động hóa mã nguồn mở.
GitLab CI/CD: Hỗ trợ CI/CD hiệu quả.

Giám sát và logging

Prometheus: Hệ thống giám sát.
ELK stack: Bộ công cụ phân tích log.

Tìm hiểu về dịch vụ đám mây

Nhà cung cấp phổ biến:

AWS
Google Cloud
Microsoft Azure

Kết luận

Trở thành một kỹ sư DevOps đòi hỏi kiến thức rộng và kỹ năng thực hành sâu. Hãy liên tục học hỏi và thực hành để đạt được mục tiêu của bạn.

Lưu ý: Lộ trình này được tổng hợp từ nhiều nguồn và kinh nghiệm thực tế, nhằm mang đến cho bạn cái nhìn tổng quan và chi tiết nhất về con đường trở thành kỹ sư DevOps. 🎯🚀

DevOps Roadmap 2025

Devops là gì ?

Wed, 19 Feb 2025 00:00:00 +0000

Giới thiệu về DevOps?

DevOps là một phương pháp kết hợp giữa phát triển phần mềm (Development - Dev) và vận hành hệ thống (Operations - Ops) nhằm tối ưu hóa quá trình phát triển, triển khai và vận hành ứng dụng. DevOps giúp các nhóm phát triển và vận hành làm việc cùng nhau hiệu quả hơn thông qua các công cụ, quy trình tự động và văn hóa làm việc.

Vì sao DevOps quan trọng?

Tăng tốc độ phát triển

DevOps giúp tự động hóa các quy trình như kiểm thử, triển khai và giám sát, giúp rút ngắn thời gian đưa sản phẩm ra thị trường.

Cải thiện chất lượng sản phẩm

Việc tích hợp kiểm thử tự động và CI/CD giúp phát hiện lỗi sớm, giảm thiểu rủi ro khi triển khai phần mềm.

Tăng cường độ tin cậy

Các công cụ giám sát và logging giúp phát hiện sự cố nhanh chóng, giảm downtime và đảm bảo hệ thống luôn hoạt động ổn định.

Hợp tác tốt hơn giữa các nhóm

DevOps giúp phá bỏ rào cản giữa nhóm phát triển và vận hành, tạo môi trường làm việc chung hiệu quả hơn.

Các thành phần chính của DevOps

CI/CD (Continuous Integration & Continuous Deployment)

CI/CD giúp tự động hóa quá trình tích hợp mã nguồn, kiểm thử và triển khai, giảm thiểu lỗi khi đưa sản phẩm lên môi trường production.

Infrastructure as Code (IaC)

IaC cho phép quản lý hạ tầng như code, giúp dễ dàng triển khai và mở rộng hệ thống.

Giám sát và Logging

Các công cụ như Prometheus, Grafana, ELK Stack giúp giám sát và phân tích log để nhanh chóng xử lý sự cố.

Containerization và Orchestration

Docker và Kubernetes giúp đóng gói, quản lý và mở rộng ứng dụng linh hoạt.

Các công cụ phổ biến trong DevOps

CI/CD: Jenkins, GitHub Actions, GitLab CI/CD
IaC: Terraform, Ansible, CloudFormation
Giám sát: Prometheus, Grafana, ELK Stack
Container & Orchestration: Docker, Kubernetes
Quản lý mã nguồn: Git, GitHub, GitLab

Kết luận

DevOps là một phương pháp quan trọng giúp cải thiện tốc độ phát triển, chất lượng sản phẩm và tối ưu hóa vận hành hệ thống. Trong các bài viết tiếp theo của series, chúng ta sẽ tìm hiểu sâu hơn về từng khía cạnh của DevOps, từ CI/CD, Infrastructure as Code đến giám sát hệ thống.

Ví dụ về Docker

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


# Sử dụng Node.js làm nền tảng
FROM node:18

# Đặt thư mục làm việc trong container
WORKDIR /app

# Sao chép file package.json và cài đặt dependencies
COPY package.json .
RUN npm install

# Sao chép toàn bộ mã nguồn vào container
COPY . .

# Mở cổng 3000 cho ứng dụng
EXPOSE 3000

# Lệnh chạy ứng dụng
CMD ["npm", "start"]

💡 Hãy theo dõi blog để cập nhật các bài viết mới nhất về DevOps!

Giới thiệu

Sat, 25 Jan 2025 00:00:00 +0000

Hoàng Dương

Fresher Full-stack · DevOps Enthusiast

“And, when you want something, all the universe conspires in helping you to achieve it.”

Thông tin cá nhân

Họ và tên: Hoàng Dương
Vị trí: Fresher Full-stack
Địa chỉ: Tân Bình, TP.HCM, Việt Nam
Email: duonghn.work@gmail.com
LinkedIn: LinkedIn
GitHub: GitHub
Telegram: Telegram

Giới thiệu chung

Tôi là Fresher Full-stack với niềm đam mê về phát triển Backend và DevOps. Tôi đang áp dụng kiến thức từ đại học vào các thách thức phát triển thực tế và đóng góp hiệu quả vào các dự án được giao. Với sự quan tâm mạnh mẽ về các công nghệ backend, tôi có mục tiêu dài hạn là sử dụng nền tảng này để chuyển đổi thành chuyên gia DevOps Engineer hoặc Systems Architect trong tương lai.

Tôi đã tích lũy kinh nghiệm phát triển web full-stack với thành công trong việc triển khai dự án quy mô sản xuất, các quy trình làm việc hiện đại và việc triển khai sẵn sử dụng.

Kinh nghiệm làm việc

Freelance Web Developer

Vị trí: Full-stack Developer | Tháng 3/2025 - Hiện tại | Remote

Xây dựng và triển khai dự án web full-stack sử dụng Spring Boot, NestJS và Next.js, React
Xử lý yêu cầu của khách hàng, định giá và triển khai trên môi trường server
Đã hoàn thành thành công hơn 3 dự án khách hàng và cải thiện hiệu suất triển khai thông qua Docker và Nginx

Intern Web Developer

Vị trí: Full-stack Developer Intern | Tháng 10/2024 - Tháng 2/2025 | Thực tập công ty

Xây dựng giao diện web và RESTful APIs sử dụng Spring Boot và Next.js trong quy trình Scrum và kiến trúc Microservices
Đóng góp vào việc phân tích hệ thống, tối ưu hóa CI/CD, triển khai hạ tầng sử dụng Infrastructure as Code (IaC)
Hợp tác trong nhóm sử dụng Git/GitHub

Các dự án nổi bật

DevOps Blog

Vị trí: Full-stack Developer & Content Creator | Tháng 2/2025 - Hiện tại

Xây dựng blog kỹ thuật sử dụng static site generator tập trung vào chủ đề DevOps, tối ưu hóa Docker và hạ tầng cloud
Xuất bản các bài viết kỹ thuật bao gồm kỹ thuật tối ưu hóa Docker, cấu hình Nginx, quy trình CI/CD và best practices cho các ứng dụng containerized
Triển khai và duy trì site sản xuất với domain tùy chỉnh, quy trình build tự động và công cụ quản lý nội dung

Xem Blog | GitHub Repository

Tourism Digitalization Platform (360° Virtual Travel)

Vị trí: Full-stack Developer - Graduation Thesis | Tháng 5/2025 - Tháng 8/2025

Xây dựng nền tảng du lịch dựa trên microservices (Spring Boot, Node.js, Python/Flask, Next.js) để quản lý các đích đến ảo 360° tương tác
Thiết kế hạ tầng Docker Compose với Kong Gateway, RabbitMQ, PostgreSQL/MongoDB và các frontend Next.js riêng biệt cho client và admin
Triển khai định tuyến API an toàn (JWT, rate limiting, logging) và pipelines media để tải, trích xuất và phục vụ các tài sản 360°

GitHub Repository

Online Testing Platform (IRT-CAT)

Vị trí: Full-stack Developer - Team of 5 | Tháng 4/2025 - Tháng 7/2025

Xây dựng nền tảng kiểm tra thích ứng sử dụng mô hình 3PL-IRT và CAT, bao gồm các module backend cho học sinh/thi/ngân hàng câu hỏi với các tham số độ khó cho từng mục và quy trình chấm điểm 3PL-IRT tự động

Live Demo

Document Conversion & OCR System

Vị trí: DevOps Support / Full-stack Developer - Team of 6 | Tháng 10/2024 - Tháng 2/2025

Tạo hệ thống xử lý tài liệu dựa trên OCR (PDF → DOCX, trích xuất ID) với xử lý thời gian thực
Đạt độ chính xác nhận dạng văn bản hơn 98% và giảm thời gian xử lý 60% với kiến trúc microservices
Đóng góp vào việc triển khai trên Google Cloud Platform (GCP) sử dụng tiếp cận IaC với Terraform và các quy trình CI/CD thông qua GitHub và Jenkins
Hợp tác với đồng nghiệp để thiết lập lập lịch container và triển khai sản xuất sử dụng Helm và Kubernetes

Học vấn

Đại học Thủy Lợi

Bằng: Kỹ sư (B.Eng.) ngành Công nghệ Thông tin | 2021 - 2025

Đại học Luật TP.HCM

Chứng chỉ: Chứng chỉ Digital Marketing | 2021 - 2022

Thành tích & Chứng chỉ

Microsoft 365 Copilot Development - Microsoft Learn
Gemini Certified Educator - Google
Introduction to GitHub - GitHub
Introduction to Git - GitHub
Information Technology Onboarding Certificate - Professional Certification

Kỹ năng kỹ thuật

Ngôn ngữ lập trình

Java - Spring Boot
JavaScript - Next.js, React, NodeJS (ExpressJS), NestJS
TypeScript - Angular, NestJS
Python - Flask, Scripts

Frameworks & Libraries

Spring Boot, Next.js, NodeJS, TailwindCSS, Angular

Cơ sở dữ liệu

PostgreSQL, MongoDB, MySQL

DevOps & Cloud

Docker, Nginx, Terraform (IaC), Jenkins, Google Cloud Platform (GCP), AWS EC2 (basic)

Công cụ phát triển

Git, GitHub, GitLab, Krpano, Postman

Soft Skills

Teamwork, problem solving, communication, self-learning

Lĩnh vực quan tâm

Backend Developer, DevOps Engineer, Systems Architect

Mục tiêu nghề nghiệp

Tôi mong muốn trở thành một Backend Developer có kinh nghiệm và tiếp tục phát triển thành DevOps Engineer, nơi tôi có thể:

Ứng dụng kiến thức và kỹ năng vào các hệ thống thực tế
Đóng góp vào sự phát triển của doanh nghiệp
Tiếp tục học hỏi để nâng cao chuyên môn
Làm chủ các công nghệ cloud và infrastructure as code
Xây dựng các hệ thống scalable, reliable và high-performance

Liên hệ

Nếu bạn quan tâm đến hồ sơ của tôi, hãy kết nối qua:

Email: duonghn.work@gmail.com
LinkedIn: LinkedIn Profile
GitHub: GitHub Profile
Telegram: Telegram

Cảm ơn bạn đã dành thời gian ghé thăm! Rất mong được kết nối và hợp tác trong tương lai!

Liên kết

Sat, 25 Jan 2025 00:00:00 +0000

Tổng hợp các kênh kết nối cá nhân, kho mã nguồn dự án tiêu biểu và hệ thống tài nguyên kỹ thuật chọn lọc về Full-stack, DevOps, Cloud Infrastructure và Linux Systems Administration.

Kết nối cá nhân

MÃ NGUỒN

GitHub

Kho mã nguồn cá nhân lưu trữ các dự án web Full-stack, cấu hình Docker Compose, hạ tầng IaC và kịch bản tự động hóa CI/CD.

github.com/HoangDuonng XEM HỒ SƠ →

NGHỀ NGHIỆP

Hồ sơ chuyên nghiệp cập nhật lộ trình phát triển kỹ năng Full-stack, kinh nghiệm làm việc và định hướng nghề nghiệp DevOps.

linkedin.com/in/hoangduonng KẾT NỐI →

TRAO ĐỔI

Kênh trao đổi trực tiếp phục vụ thảo luận kỹ thuật, chia sẻ kiến thức công nghệ và trao đổi nhanh về công việc.

t.me/hoanngduong NHẮN TIN →

LIÊN HỆ

Email

Hộp thư làm việc chính thức tiếp nhận thông tin tuyển dụng, đề xuất hợp tác phát triển dự án và phản hồi kỹ thuật.

duonghn.work@gmail.com GỬI EMAIL →

Dự án tiêu biểu

MICROSERVICES

Travel 360

Nền tảng số hóa du lịch kiến trúc microservices (Spring Boot, Node.js, Python, Next.js), tích hợp Kong API Gateway, RabbitMQ, PostgreSQL/MongoDB, Docker Compose và trình phát ảnh toàn cảnh 360°.

github.com/HoangDuonng/Travel_360 XEM REPO →

DEVOPS & STATIC SITE

DevOps Blog

Blog kỹ thuật chuyên sâu về DevOps, tối ưu hóa container Docker, cấu hình Nginx Reverse Proxy, tự động hóa CI/CD pipelines và quản trị hệ thống Linux với thiết kế Ampcode Chronicle.

github.com/HoangDuonng/Manage_Blog XEM REPO →

ALGORITHM & FULL-STACK

Online Testing Platform

Hệ thống khảo thí trực tuyến thích ứng ứng dụng mô hình toán 3PL-IRT và CAT, hỗ trợ ngân hàng câu hỏi phân tầng độ khó và tự động đánh giá năng lực thí sinh theo thời gian thực.

ued-smart.education.vnu.edu.vn TRUY CẬP HỆ THỐNG →

GCP & IAC

Document Conversion & OCR System

Hệ thống xử lý và nhận dạng văn bản thời gian thực (PDF sang DOCX, trích xuất căn cước), đạt độ chính xác >98%, triển khai trên hạ tầng GCP với Terraform (IaC), Kubernetes, Helm và CI/CD.

github.com/HoangDuonng XEM DỰ ÁN →

Tài nguyên & Công cụ DevOps đề xuất

CONTAINERIZATION

Docker Docs

Tài liệu chính thức về Docker Engine, multi-stage builds, tối ưu hóa kích thước image, quản lý volume và điều phối dịch vụ với Docker Compose.

docs.docker.com XEM TÀI LIỆU →

ORCHESTRATION

Kubernetes Docs

Cẩm nang điều phối container quy mô sản xuất: cấu trúc Pods, Deployments, Services, Ingress Controllers, ConfigMaps và cơ chế tự phục hồi.

kubernetes.io/docs XEM TÀI LIỆU →

SYSADMIN

Linux Journey

Lộ trình học tập quản trị hệ thống Linux từ cơ bản đến nâng cao: dòng lệnh shell, phân quyền tập tin, quản lý tiến trình và cấu hình mạng.

linuxjourney.com HỌC NGAY →

WEB SERVER

Nginx Documentation

Tài liệu cấu hình Web Server và Reverse Proxy: cân bằng tải (Load Balancing), mã hóa SSL/TLS, bộ nhớ đệm (Caching) và tối ưu hóa HTTP/2.

nginx.org/en/docs XEM TÀI LIỆU →

CI/CD

GitHub Actions

Nền tảng tự động hóa CI/CD: thiết lập pipeline kiểm thử tự động, build container đa nền tảng và tự động triển khai mã nguồn vào production.

docs.github.com/en/actions XEM TÀI LIỆU →

IAC

Terraform Documentation

Tài liệu Infrastructure as Code (IaC) của HashiCorp: định nghĩa hạ tầng dưới dạng mã nguồn, quản lý state và tự động hóa cấp phát tài nguyên đa đám mây.

developer.hashicorp.com/terraform XEM TÀI LIỆU →

Lưu trữ

Wed, 01 Jan 2025 00:00:00 +0000

Search

Mon, 01 Jan 0001 00:00:00 +0000

Hoàng Dương

Cron Job với Bash: tự động hóa theo lịch cho DevOps

Cron job trong Bash cho DevOps

Cron và crontab là gì

Cú pháp lịch 5 trường

Shortcut @daily, @hourly, @reboot

Viết script Bash thân thiện với cron

Redirect log trong cron

Kiểm tra log cron

Vấn đề PATH và environment trong cron

Thực hành DevOps: backup database hằng đêm

Thực hành DevOps: healthcheck mỗi 5 phút

Tránh job chạy chồng lên nhau

Sai sót thường gặp

Ghi chú triển khai

Lời kết

Tài liệu tham khảo

Quản lý biến và môi trường trong Bash cho DevOps

Vì sao biến môi trường quan trọng trong Bash

Biến cục bộ và cách gán giá trị

export: khi nào biến trở thành environment variable

Xem, đặt và xóa biến với env, set, unset

Đọc cấu hình từ file .env

Nhận tham số CLI bằng getopts

$IFS: kiểm soát cách Bash tách chuỗi

Các biến đặc biệt thường gặp

Ví dụ DevOps: script deploy đọc .env, nhận flag và validate biến

Sai sót thường gặp

Ghi chú triển khai

Lời kết

Tài liệu tham khảo

Function trong Bash: tái sử dụng code hiệu quả cho DevOps

Function trong Bash cho DevOps

Khai báo function trong Bash

Function nhận tham số bằng $1, $@, $#

Validate tham số đầu vào

Return value trong Bash là exit code

Biến local để tránh side effect

Tách function vào file khác với source

Thực hành DevOps: thư viện logging nhỏ

Thực hành DevOps: retry command bằng function

Thực hành DevOps: deploy script có function rõ ràng

Sai sót thường gặp

Ghi chú triển khai

Lời kết

Tài liệu tham khảo

Text Processing trong Bash: grep, awk, sed cho DevOps

Text processing trong Bash cho DevOps

grep: tìm dòng khớp pattern

grep context: xem dòng trước và sau lỗi

grep trong pipeline DevOps

awk: xử lý theo dòng và theo cột

awk BEGIN, END và điều kiện

awk với delimiter tùy chỉnh

sed: thay thế và chỉnh text theo dòng

sed theo address và in-place edit

Thực hành DevOps: parse Nginx log

Thực hành DevOps: đổi config trước khi deploy

Thực hành DevOps: report lỗi từ log

Sai sót thường gặp

Ghi chú triển khai

Lời kết

Tài liệu tham khảo

Xử lý file trong Bash: đọc, ghi và quản lý an toàn cho DevOps

Xử lý file trong Bash cho DevOps

Đọc nhanh nội dung file với cat, tac, head, tail

Redirect output: ghi mới, append và tách stdout/stderr

Here-doc: tạo file cấu hình từ script

tee: vừa hiển thị vừa lưu file

Đọc file theo từng dòng

Kiểm tra file, thư mục và quyền trước khi thao tác

find: tìm file theo điều kiện

xargs: truyền danh sách file cho lệnh khác

Thực hành DevOps: rotate log thủ công

Thực hành DevOps: backup config trước khi deploy

Sai sót thường gặp

Ghi chú triển khai

Lời kết

Tài liệu tham khảo

Vòng lặp trong Bash: for, while, until cho tự động hóa DevOps

Shortcut `@daily`, `@hourly`, `@reboot`

Vấn đề `PATH` và environment trong cron

`export`: khi nào biến trở thành environment variable

Xem, đặt và xóa biến với `env`, `set`, `unset`

Đọc cấu hình từ file `.env`

Nhận tham số CLI bằng `getopts`

`$IFS`: kiểm soát cách Bash tách chuỗi

Ví dụ DevOps: script deploy đọc `.env`, nhận flag và validate biến

Function nhận tham số bằng `$1`, `$@`, `$#`

Tách function vào file khác với `source`