Shell-Script on 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.

Shell-Script on 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`