Bài 28: CI/CD cơ bản cho SysAdmin/DevOps

# health check
curl -fsS https://example.com/health</pre><h2>4. Tình huống thực tế</h2><div class="note"><p>Sau khi developer merge code, pipeline tự test, build và deploy. SysAdmin cần đảm bảo secret an toàn, server có quyền đúng và health check fail thì rollback.</p></div><h2>5. Quy trình áp dụng an toàn</h2><ol><li>Viết cấu hình hoặc command trong môi trường lab.</li><li>Kiểm tra syntax/plan/status trước khi apply.</li><li>Chạy với phạm vi nhỏ trước.</li><li>Quan sát log, metric và health check.</li><li>Ghi lại thay đổi vào tài liệu vận hành.</li><li>Chuẩn bị rollback hoặc version trước đó.</li></ol><h2>6. Lỗi thường gặp</h2><ul><li>Copy cấu hình từ mạng mà không hiểu biến/môi trường.</li><li>Không lưu file cấu hình vào Git.</li><li>Không kiểm tra log sau khi apply.</li><li>Không có môi trường test/staging.</li></ul><div class="warn"><strong>Lưu ý production:</strong> Công cụ tự động hóa giúp làm nhanh hơn, nhưng cũng có thể làm sai hàng loạt nhanh hơn. Luôn giới hạn phạm vi khi mới triển khai.</div><h2>7. Checklist</h2><div class="check"><ul><li>Có file cấu hình rõ ràng.</li><li>Có bước kiểm tra trước khi apply.</li><li>Có log/health check sau khi apply.</li><li>Có rollback/version cũ.</li><li>Có tài liệu ai chạy, chạy khi nào, kết quả gì.</li></ul></div><h2>8. Bài tập</h2><ol><li>Dựng một lab nhỏ theo lệnh mẫu.</li><li>Chạy lệnh kiểm tra trạng thái trước/sau.</li><li>Tạo một lỗi cấu hình nhỏ và sửa lại.</li><li>Viết checklist production cho chủ đề này.</li></ol><div class="next"><strong>Bài tiếp theo:</strong> Backup database và kiểm tra restore</div></div>

Chốt ý nhanh

Chủ đề	Điểm cần nhớ
CI/CD	Giúp biến thay đổi code hoặc cấu hình thành pipeline có bước kiểm tra rõ ràng trước khi vào production.
Góc nhìn SysAdmin	Không cần viết pipeline quá phức tạp từ đầu; điều quan trọng là hiểu flow build, test, deploy và rollback.
Lợi ích thật	Giảm deploy tay, giảm sai sót, tăng khả năng lặp lại và truy vết thay đổi.

Phần thực hành mở rộng: CI/CD như dây chuyền kiểm soát thay đổi

Nhiều người nghe CI/CD và nghĩ đó là chuyện của developer. Thực ra SysAdmin/DevOps cần hiểu rất rõ, vì pipeline là nơi thay đổi đi vào production. Bài này nên làm cho người học nhìn pipeline như một chuỗi cổng kiểm soát.

Lab 1: Vẽ flow pipeline tối thiểu

push code hoặc config
lint/test
build artifact hoặc image
deploy staging
approve rồi deploy production

Chỉ cần vẽ được flow này là tư duy về CI/CD đã bắt đầu rõ hơn nhiều.

Lab 2: Tạo pipeline tối thiểu cho repo demo

mkdir cicd-lab && cd cicd-lab
git init
echo 'echo hello pipeline' > test.sh
chmod +x test.sh
./test.sh

Sau đó mô phỏng: mỗi lần commit phải chạy test script trước khi được coi là “sẵn sàng deploy”.

Lab 3: Hiểu artifact và immutable output

Tự trả lời 3 câu hỏi:

artifact là gì?
vì sao production nên deploy artifact đã build sẵn thay vì build trực tiếp trên server?
vì sao image tag hoặc version rõ ràng quan trọng?

Lab 4: Mô phỏng deploy có health check

rsync -avh ./ ~/deploy-target/
./test.sh && echo 'deploy allowed'
curl -I http://127.0.0.1 || true

Điểm mấu chốt là sau deploy phải có bước kiểm chứng tối thiểu, không phải đẩy xong là xong.

Lab 5: Viết checklist rollback pipeline

biết version trước đó là gì
biết rollback bằng artifact/image/tag nào
biết rollback config hay rollback app
biết ai xác nhận sau rollback

Tình huống thực tế

Một pipeline yếu thường có dạng: push xong tự deploy thẳng production, không test, không approval, không health check. Nó nhanh, nhưng chỉ cần một commit lỗi là biến cả pipeline thành máy phát sự cố.

Lỗi phổ biến

Build trực tiếp trên production.
Không tách staging và production.
Không version artifact/image rõ ràng.
Không có bước rollback hoặc verify sau deploy.

Kết bài

Nếu bài này ngấm, anh sẽ thấy CI/CD không phải buzzword mà là hệ thống kiểm soát rủi ro thay đổi. Khi pipeline có kỷ luật, production bớt phụ thuộc vào việc “anh nào đó nhớ thao tác đúng”. Bài tiếp theo sẽ quay lại một chủ đề cực thực chiến: backup database và quan trọng hơn là kiểm tra restore.