Lab 11 — Helm CI/CD
🎯 Mục tiêu
Sau Lab này, bạn sẽ:
- Hiểu Helm Chart được đưa vào CI/CD như thế nào.
- Biết các bước cơ bản để validate → package → publish → deploy Helm Chart.
- Tạo một pipeline tự động kiểm tra Helm Chart.
- Publish Chart lên OCI Registry.
- Hiểu cách tách CI và CD trong thực tế.
- Biết những điểm cần review khi AI viết Helm CI/CD pipeline.
Lab này không nhằm dạy GitHub Actions syntax.
Mục tiêu là hiểu pipeline cần làm gì và tại sao.
1. 🤔 Vấn đề thực tế
Ở Lab trước, chúng ta đã có:
Helm Chart
↓
helm package
↓
OCI Registry
Nhưng nếu Developer phải tự làm:
helm lint .
helm package .
helm push ...
thì rất dễ xảy ra lỗi.
Ví dụ:
Developer A
↓
Quên helm lint
↓
Chart lỗi
↓
Push lên Registry
↓
Production deploy lỗi
Hoặc:
Developer B
↓
Sửa Chart
↓
Quên tăng version
↓
Push lại artifact cũ
Đây là lý do CI/CD xuất hiện.
Thay vì:
Developer
│
├── lint
├── test
├── package
└── push
chúng ta muốn:
Developer
│
│ git push
▼
CI/CD
│
├── Validate
├── Test
├── Package
├── Publish
└── Deploy
2. 🧠 Hiểu nhanh: CI và CD
CI — Continuous Integration
CI có nhiệm vụ:
Kiểm tra thay đổi có an toàn để merge/release hay không.
Ví dụ:
Pull Request
│
▼
helm lint
│
▼
helm template
│
▼
Tests
│
▼
PASS / FAIL
CD — Continuous Delivery / Deployment
CD đưa artifact đã được kiểm tra đến environment.
Chart
│
▼
OCI Registry
│
▼
Dev
│
▼
Staging
│
▼
Production
Mental model đơn giản:
CI = "Có deploy được không?"
CD = "Deploy nó ở đâu và khi nào?"
3. 🏗️ Architecture
Một Helm CI/CD pipeline thực tế:
Git Repository
│
Pull Request / Push
│
▼
┌──────────────┐
│ CI │
├──────────────┤
│ helm lint │
│ helm template│
│ helm test │
└──────┬───────┘
│
PASS
│
▼
helm package
│
▼
OCI Registry
│
┌─────────┼─────────┐
▼ ▼ ▼
Dev Staging Prod
Điều quan trọng là:
Không deploy Chart chưa qua validation.
4. 🧠 Pipeline nên chia thành các Stage
Thay vì nghĩ về hàng chục câu lệnh, chỉ cần nhớ:
1. Validate
2. Test
3. Package
4. Publish
5. Deploy
Có thể hình dung:
┌───────────┐
│ Code │
└─────┬─────┘
▼
┌───────────┐
│ Validate │
└─────┬─────┘
▼
┌───────────┐
│ Test │
└─────┬─────┘
▼
┌───────────┐
│ Package │
└─────┬─────┘
▼
┌───────────┐
│ Publish │
└─────┬─────┘
▼
┌───────────┐
│ Deploy │
└───────────┘
5. 🚀 Chuẩn bị Lab
Sử dụng Chart của các Lab trước:
todo-app/
├── Chart.yaml
├── values.yaml
└── templates/
Kiểm tra:
helm lint .
Sau đó:
helm template todo-app .
Nếu cả hai đều chạy thành công, Chart đã sẵn sàng để đưa vào CI.
6. 🧪 Exercise 1 — Helm Lint trong CI
Tại sao?
helm lint giúp phát hiện những lỗi cơ bản trong Chart.
Ví dụ:
helm lint .
Kết quả:
1 chart(s) linted, 0 chart(s) failed
Trong CI, chúng ta muốn:
Developer
│
▼
Pull Request
│
▼
helm lint
│
┌──┴──┐
▼ ▼
PASS FAIL
│ │
▼ ▼
Next Stop
Nếu lint fail:
Pipeline nên dừng.
7. 🧪 Exercise 2 — Render Chart
helm lint chưa đủ.
Một Chart có thể:
helm lint
↓
PASS
nhưng khi render:
helm template todo-app .
lại tạo ra Kubernetes YAML không đúng với mong muốn.
Vì vậy CI nên kiểm tra cả:
helm template todo-app .
Mental model:
Chart
│
▼
Template Engine
│
▼
Kubernetes YAML
Bạn đang kiểm tra:
"Helm thực sự sẽ tạo ra Kubernetes manifests như thế nào?"
8. 🧠 helm template rất quan trọng
Ví dụ:
replicas: {{ .Values.replicaCount }}
CI có thể render:
replicas: 3
Bạn có thể review:
Chart
↓
Rendered YAML
↓
Kubernetes Manifest
Đây cũng là một trong những công cụ bạn sẽ sử dụng rất nhiều khi debugging Helm.
9. 🧪 Exercise 3 — Validate bằng Values của Production
Không chỉ render:
helm template todo-app .
Production có thể sử dụng:
values-prod.yaml
Vì vậy cần kiểm tra:
helm template todo-app . \
-f values-prod.yaml
Điều này quan trọng vì:
Default Values
│
└── Có thể PASS
Production Values
│
└── Có thể FAIL
Một Chart chạy được ở Dev không có nghĩa nó chắc chắn render đúng ở Production.
10. 🧠 Test trước khi Package
Một pipeline tốt:
helm lint
↓
helm template
↓
Tests
↓
Package
Không nên:
helm package
↓
Publish
↓
Mới phát hiện lỗi
Nguyên tắc:
Fail as early as possible.
Phát hiện lỗi càng sớm thì càng rẻ để sửa.
11. 📦 Package Chart trong CI
Sau khi validation pass:
helm package .
Tạo:
todo-app-1.0.0.tgz
Pipeline lúc này:
Chart Source
│
▼
helm lint
│
▼
helm template
│
▼
helm package
│
▼
todo-app-1.0.0.tgz
File .tgz chính là artifact.
12. 🧠 Artifact là gì?
Artifact là sản phẩm được tạo ra sau quá trình build.
Ví dụ:
Source Code
│
▼
Build
│
▼
Artifact
Với Helm:
Chart Source
│
▼
helm package
│
▼
todo-app-1.0.0.tgz
Artifact này có thể:
Publish
↓
Store
↓
Deploy
13. 🚀 Publish lên OCI Registry
Sau khi package:
helm push todo-app-1.0.0.tgz \
oci://registry.example.com/helm
Pipeline:
Git
│
▼
Validate
│
▼
Test
│
▼
Package
│
▼
OCI Registry
Từ đây application team có thể deploy:
helm upgrade --install todo-app \
oci://registry.example.com/helm/todo-app \
--version 1.0.0
14. 🔐 Secrets trong CI
Đây là phần rất quan trọng trong production.
Không được viết:
password: my-secret-password
trong repository.
Thay vào đó:
CI/CD
│
├── Registry Username
├── Registry Token
└── Cloud Credentials
được lưu trong:
Secrets
Pipeline lấy credential khi chạy.
Mental model:
Repository
│
│ ❌ No password
▼
CI
│
│ Secret
▼
OCI Registry
AI có thể viết syntax authentication cho bạn. Nhưng bạn phải nhận biết ngay nếu AI hard-code credential vào YAML.
15. 🧪 Exercise 4 — Tạo CI Pipeline
Nếu sử dụng GitHub Actions, tạo:
.github/
└── workflows/
└── helm-ci.yaml
Một pipeline tối giản:
name: Helm CI
on:
pull_request:
paths:
- "helm/**"
jobs:
validate:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Setup Helm
uses: azure/setup-helm@v4
- name: Lint
run: helm lint ./helm/todo-app
- name: Render
run: |
helm template todo-app ./helm/todo-app
Bạn không cần học thuộc file này.
Hãy tập trung đọc nó theo flow:
Checkout
↓
Install Helm
↓
Lint
↓
Render
16. 🧠 Review Pipeline như thế nào?
Khi AI viết pipeline cho bạn, hãy hỏi:
Có checkout source không?
Có install Helm không?
Có helm lint không?
Có helm template không?
Có validate production values không?
Có test không?
Có package không?
Có version rõ ràng không?
Có credential hard-code không?
Artifact được push vào đâu?
Đây mới là kỹ năng quan trọng.
17. 🧪 Exercise 5 — Build Release Pipeline
Bây giờ mở rộng pipeline:
Pull Request
│
▼
CI
├── lint
├── template
└── test
Khi merge vào main:
main
│
▼
Package
│
▼
Publish
│
▼
OCI Registry
Architecture:
Pull Request
│
▼
┌─────────┐
│ CI │
├─────────┤
│ lint │
│ render │
│ test │
└────┬────┘
│
PASS
│
▼
Merge
│
▼
┌─────────┐
│ Release │
├─────────┤
│ package │
│ push │
└────┬────┘
│
▼
OCI Registry
18. 🧠 CI và CD không nhất thiết phải là một Job
Đây là cách thiết kế dễ quản lý hơn:
CI
│
├── Lint
├── Render
└── Test
↓
Release
│
├── Package
└── Publish
↓
CD
│
├── Dev
├── Staging
└── Production
Tại sao?
Vì:
Pull Request
không nên tự động deploy Production.
19. 🏗️ Production Flow
Một workflow phổ biến:
Developer
│
▼
Pull Request
│
▼
CI
│
├── lint
├── template
└── test
│
▼
Merge main
│
▼
Release
│
├── package
└── publish
│
▼
OCI Registry
│
▼
Dev
│
▼
Staging
│
▼
Production
20. 🧠 Deployment Strategy
Không nhất thiết:
Publish
↓
Production
ngay lập tức.
Một cách an toàn hơn:
Publish
↓
Dev
↓
Test
↓
Staging
↓
Approval
↓
Production
Điều này gọi là promotion — đưa cùng một artifact qua nhiều environment.
Điểm quan trọng:
❌ Build lại cho từng environment
✅ Build một lần → Promote nhiều lần
21. 🧪 Exercise 6 — Deploy bằng Helm
Giả sử Chart đã được publish:
oci://registry.example.com/helm/todo-app
Dev:
helm upgrade --install todo-app \
oci://registry.example.com/helm/todo-app \
--version 1.2.0 \
-f values-dev.yaml
Staging:
helm upgrade --install todo-app \
oci://registry.example.com/helm/todo-app \
--version 1.2.0 \
-f values-staging.yaml
Production:
helm upgrade --install todo-app \
oci://registry.example.com/helm/todo-app \
--version 1.2.0 \
-f values-prod.yaml
Chú ý:
Chart Version
│
└── 1.2.0
│
┌─────┼─────┐
▼ ▼ ▼
Dev Stage Prod
Cùng một Chart version.
Khác nhau chủ yếu ở:
values-dev.yaml
values-staging.yaml
values-prod.yaml
22. 🚨 Một lỗi production rất phổ biến
Có người thiết kế:
Dev
↓
Build Chart
↓
Staging
↓
Build Chart lại
↓
Production
↓
Build Chart lại
Điều này tạo ra:
Dev Chart ≠ Production Chart
và rất khó debug.
Tốt hơn:
Build
↓
Chart 1.2.0
↓
Registry
├── Dev
├── Staging
└── Production
Build once, deploy many.
23. 🧠 Versioning trong CI/CD
Pipeline không nên tùy tiện:
latest
Ví dụ:
todo-app:latest
khó biết Production đang chạy gì.
Tốt hơn:
todo-app:1.2.0
Hoặc version được gắn theo Git tag:
v1.2.0
Flow:
Git Tag
│
▼
v1.2.0
│
▼
Chart Version
│
▼
OCI Registry
24. 🧪 Exercise 7 — Release bằng Git Tag
Tạo tag:
git tag v1.2.0
git push origin v1.2.0
Pipeline có thể sử dụng tag này để xác định release version.
Mental model:
Git
│
└── v1.2.0
│
▼
Helm Chart
│
▼
todo-app-1.2.0.tgz
│
▼
OCI Registry
Bạn không cần nhớ cách implement tự động versioning.
Điều cần hiểu là:
Git release → Chart version → Registry artifact
25. 🧠 Rollback trong CI/CD
Giả sử Production:
1.2.0
Release:
1.3.0
nhưng có bug.
Helm cho phép rollback:
helm rollback todo-app
Hoặc bạn có thể deploy lại version cũ:
helm upgrade --install todo-app \
oci://registry.example.com/helm/todo-app \
--version 1.2.0 \
-f values-prod.yaml
Mental model:
Production
│
▼
1.3.0
│
│ Bug
▼
Rollback
│
▼
1.2.0
Đây là một lý do quan trọng để artifact phải được version hóa và giữ lại.
26. 🧪 Exercise 8 — Simulate Rollback
Deploy:
1.0.0
Sau đó:
1.1.0
Kiểm tra:
helm history todo-app
Bạn sẽ thấy các revision.
Sau đó rollback:
helm rollback todo-app 1
Kiểm tra:
helm history todo-app
Mục tiêu:
1.0.0
↓
1.1.0
↓
Rollback
↓
1.0.0
27. 🧠 Helm History vs Chart Version
Đây là một điểm cần phân biệt:
Chart Version
và:
Helm Release Revision
Ví dụ:
Chart:
1.0.0
1.1.0
Release history:
REVISION
1
2
3
Hai khái niệm khác nhau.
Chart Version
↓
Artifact version
Release Revision
↓
History của deployment
Không cần học sâu hơn ở Lab này.
28. 🚨 Production Tips
1. CI phải fail khi validation fail
helm lint FAIL
↓
Pipeline STOP
Không được:
lint FAIL
↓
continue
↓
publish
2. Không publish Chart chưa test
Validate
↓
Test
↓
Package
↓
Publish
3. Không hard-code secret
❌ password: xxx
Dùng:
✅ CI Secret
4. Pin version
❌ latest
Ưu tiên:
✅ 1.2.0
5. Production nên có approval
Ví dụ:
Dev
↓
Staging
↓
Manual Approval
↓
Production
Điều này đặc biệt hữu ích với production environment quan trọng.
6. Giữ artifact cũ
Đừng xóa ngay:
1.0.0
1.1.0
1.2.0
Vì bạn có thể cần:
Rollback
29. 🧪 Final Exercise — Hoàn thiện Pipeline
Hãy thiết kế pipeline cho:
todo-app/
├── Chart.yaml
├── values.yaml
├── values-dev.yaml
├── values-staging.yaml
├── values-prod.yaml
└── templates/
Pipeline yêu cầu:
Pull Request
helm lint
↓
helm template
↓
helm template -f values-prod.yaml
↓
Tests
Nếu tất cả pass:
PASS
Merge vào main
Package
↓
Publish OCI
Deploy Dev
Chart 1.0.0
↓
values-dev.yaml
Deploy Staging
Chart 1.0.0
↓
values-staging.yaml
Deploy Production
Approval
↓
Chart 1.0.0
↓
values-prod.yaml
Architecture cuối:
Git
│
Pull Request
│
▼
┌────────────┐
│ CI │
├────────────┤
│ lint │
│ template │
│ test │
└─────┬──────┘
│
PASS
│
Merge
│
▼
┌────────────┐
│ Release │
├────────────┤
│ package │
│ publish │
└─────┬──────┘
│
▼
OCI Registry
│
▼
1.0.0
│
┌──────────┼──────────┐
▼ ▼ ▼
Dev Staging Prod
▲
│
Approval
30. 🎯 Tổng kết
Sau Lab này, bạn không cần nhớ hàng loạt syntax của GitHub Actions.
Chỉ cần nhớ pipeline:
Validate
↓
Test
↓
Package
↓
Publish
↓
Deploy
Và 5 nguyên tắc:
1. Fail early — phát hiện lỗi càng sớm càng tốt.
2. Build once — tạo một artifact duy nhất.
3. Version everything — Chart và artifact phải xác định được version.
4. Promote the same artifact — Dev → Staging → Production dùng cùng artifact.
5. Never hard-code secrets — credential phải được quản lý bởi CI/CD secret mechanism.
🧠 Mental Model cuối Lab
Nếu AI đưa cho bạn một file:
.github/workflows/helm-release.yaml
Bạn không cần đọc thuộc từng dòng.
Hãy nhìn nó và tự hỏi:
Git
│
▼
┌──────────┐
│ Validate │
└────┬─────┘
▼
Testing
│
▼
Packaging
│
▼
OCI Registry
│
▼
Version 1.2.0
│
┌──────┼──────┐
▼ ▼ ▼
Dev Stage Prod
Nếu bạn hiểu được flow này, bạn đã nắm được phần Helm CI/CD quan trọng nhất.
Và đây cũng là điểm phù hợp với mục tiêu học Helm của bạn: không cần trở thành Helm syntax expert, mà cần đủ khả năng đọc, review, debug và thiết kế flow release.
All rights reserved
