Deploy ứng dụng từ public repository: Bitnami, Artifact Hub và best practices

Hướng dẫn Helm

(1) Helm là gì? Vì sao Kubernetes vẫn cần Helm?

(2) Cài đặt Helm và dựng lab Kubernetes local với kind/OrbStack

(3) Cấu trúc Helm Chart: Chart.yaml, values.yaml, templates và thành phần quan trọng

(4) Templates, Values, Functions và Debugging: Làm chủ Go templating trong Helm

(5) Deploy ứng dụng từ public repository: Bitnami, Artifact Hub và best practices

(6) Tự đóng gói ứng dụng Node.js cơ bản thành Helm chart

(7) NodeJS Full-Stack trong Helm phần 1: Kiến trúc chart cho React/Next.js + Express

(8) NodeJS Full-Stack trong Helm phần 2: Thêm PostgreSQL + Redis dependencies

(9) NodeJS Full-Stack trong Helm phần 3: Nginx reverse proxy + production ingress

(10) Multi-environment deployment với Helm: Dev, Staging, Production

(11) Umbrella chart vs microservices strategy: Khi nào dùng cách nào

(12) 13 Best Practices for using Helm

Ở phần 4, mình đã đi qua cách đọc template, helper và flow control trong Helm. Sang phần này, mình chuyển sang thứ gần với công việc hằng ngày hơn: lấy chart có sẵn từ public repository, kiểm tra nó, rồi deploy theo cách đủ an toàn để dùng cho lab và cả môi trường thật. Nếu bạn đang mới làm quen Helm, đây thường là chặng dễ vào nhất vì chưa phải tự viết chart từ đầu.

Lab trong bài dùng Helm 4.1.3, repository Bitnami và các lệnh chạy thử trên môi trường local để inspect chart bằng helm template.

Tại sao nên bắt đầu với public charts

Nếu mục tiêu của bạn là deploy nhanh một stack phổ biến như Nginx, PostgreSQL, Redis, Prometheus hay Grafana thì tự viết chart ngay từ đầu thường không phải nước đi khôn ngoan. Mất thời gian, lại dễ sót đủ thứ linh tinh như probes, ServiceAccount, persistence, RBAC, resource presets, NetworkPolicy hoặc logic upgrade.

Public chart giải quyết sẵn phần khung đó. Bạn chỉ cần tập trung vào 3 việc: chart này có đáng tin không, mặc định của nó có hợp với cluster của bạn không, và mình cần override những gì. Với người mới, đây là cách học Helm rất ổn vì bạn nhìn được chart của người khác viết ra sao, cách họ tổ chức values.yaml thế nào, dependency được khai báo ở đâu và release lifecycle vận hành ra sao.

ℹ️ Public chart giúp bạn học rất nhanh, nhưng đừng hiểu nhầm là cứ thấy chart nổi tiếng là cài thẳng lên production. Phần inspect và hardening vẫn bắt buộc.

Một lợi thế nữa là public charts thường có cộng đồng dùng đông. Khi gặp lỗi, bạn dễ tìm issue, changelog, README, ví dụ cấu hình và kinh nghiệm triển khai thực tế hơn nhiều so với chart tự viết nội bộ. Chỗ này tiết kiệm rất nhiều thời gian vận hành.

Artifact Hub, kiểu “app store” của Helm

Artifact Hub là nơi tập hợp package từ nhiều hệ sinh thái khác nhau, trong đó Helm chart là nhóm rất quen thuộc với anh em Kubernetes. Hiểu nhanh thì nó giống một “app store” cho chart: bạn có thể tìm tên ứng dụng, xem chart đến từ đâu, phiên bản nào đang có, README, metadata, dependency, security report và link về source.

Khi search trên Artifact Hub, mình thường nhìn mấy điểm trước tiên:

• Publisher là ai, có uy tín không
• Chart có còn được cập nhật đều không
• README có rõ ràng không, có hướng dẫn upgrade hay breaking changes không
• Values có nhiều option quá mức hay vừa đủ để vận hành
• Có link về source repository để kiểm tra sâu hơn không

Artifact Hub rất hợp cho bước tìm và sàng lọc ban đầu. Nhưng mình vẫn khuyên sau khi chọn chart, hãy quay lại terminal để inspect bằng Helm CLI. Giao diện web cho bạn góc nhìn nhanh, còn CLI mới là nơi xác nhận manifest sẽ trông ra sao trước khi apply vào cluster.

Demo với Bitnami repository: nginx, PostgreSQL, Redis

Bitnami là repository rất quen thuộc khi mới học Helm. Chart của họ khá đầy đủ, README tốt, values có cấu trúc rõ, và nhiều ứng dụng phổ biến đều có sẵn. Mình bắt đầu bằng việc add repo và cập nhật index:

helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update

Sau đó search thử chart Nginx:

helm search repo bitnami/nginx --versions | head

NAME              CHART VERSION  APP VERSION  DESCRIPTION
bitnami/nginx     22.6.10        1.29.7       NGINX Open Source is a web server...
bitnami/nginx     22.6.9         1.29.6       NGINX Open Source is a web server...
bitnami/nginx     22.6.8         1.29.6       NGINX Open Source is a web server...

Ở đây có 2 version bạn cần phân biệt:

• Chart version: phiên bản gói Helm
• App version: phiên bản ứng dụng bên trong chart, ví dụ Nginx 1.29.7

Phân biệt 2 thứ này rất quan trọng. Có lúc chart tăng version vì sửa template, logic values hoặc dependency, trong khi app version không đổi. Nếu bạn chỉ nhìn mỗi image tag thì rất dễ bỏ sót thay đổi ở lớp chart.

Inspect nhanh chart Nginx

helm show chart bitnami/nginx
helm show values bitnami/nginx | less

apiVersion: v2
appVersion: 1.29.7
dependencies:
  - name: common
    repository: oci://registry-1.docker.io/bitnamicharts
    version: 2.37.0
name: nginx
version: 22.6.10

Phần dependencies cho thấy chart Nginx của Bitnami đang kéo thêm chart common. Chỗ này đáng để ý vì đôi khi hành vi bạn thấy không nằm hết trong chart chính mà đến từ dependency dùng chung.

Tiếp theo, render manifest để xem Helm sẽ tạo ra gì nếu deploy:

helm template lab-nginx bitnami/nginx \
  --set service.type=ClusterIP \
  --set replicaCount=2 \
  --set image.debug=true

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: lab-nginx
---
apiVersion: v1
kind: Service
metadata:
  name: lab-nginx
spec:
  type: ClusterIP
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: lab-nginx
spec:
  replicas: 2

Chỉ với vài lệnh ngắn, bạn đã thấy chart này không chỉ tạo Deployment mà còn sinh thêm NetworkPolicy, ServiceAccount, TLS secret mẫu, Service và vài resource phụ trợ khác. Đó là lý do mình luôn inspect trước. Cài thẳng mà không nhìn manifest là hơi liều.

PostgreSQL và Redis có gì đáng chú ý

Với chart database hoặc cache, trọng tâm không còn là cổng dịch vụ nữa mà là auth, persistence và tài nguyên.

helm template lab-postgres bitnami/postgresql \
  --set auth.postgresPassword='SuperSecret123!' \
  --set primary.persistence.enabled=false
helm template lab-redis bitnami/redis \
  --set auth.password='RedisSecret123!' \
  --set master.persistence.enabled=false \
  --set replica.replicaCount=1

Trong lab, mình tắt persistence để render nhanh và dễ kiểm tra. Nhưng trên môi trường thật thì ngược lại, bạn gần như luôn phải bật persistence, chọn storage class phù hợp và tính đến backup từ sớm. Public chart cho bạn deploy nhanh, nhưng không tự hiểu yêu cầu dữ liệu của hệ thống bạn đang chạy.

Workflow đầy đủ: search, inspect, install, upgrade, rollback

Khi làm việc với public chart, mình thường đi theo chuỗi này. Nó hơi chậm hơn vài phút đầu, nhưng đổi lại giảm mạnh khả năng deploy nhầm hoặc upgrade ẩu.

1) Search

helm search repo bitnami/nginx --versions
helm search repo bitnami/postgresql --versions
helm search repo bitnami/redis --versions

Bước này dùng để chốt chart version cụ thể, không phải chỉ để xem “có chart hay không”. Nếu dự định lên production, hãy chọn version bạn muốn pin ngay từ đây.

2) Inspect

helm show chart bitnami/nginx --version 22.6.10
helm show values bitnami/nginx --version 22.6.10 > values.nginx.upstream.yaml
helm template web bitnami/nginx --version 22.6.10 -f values-web.yaml

Ở đây bạn nên đọc 3 thứ: metadata chart, file values mặc định và manifest render ra sau khi override. Nếu chart có README dài, mình còn xem thêm các mục về persistence, ingress, securityContext, metrics và upgrade notes.

3) Install

cat > values-web.yaml <<'EOF'
replicaCount: 2
service:
  type: ClusterIP
resources:
  requests:
    cpu: 100m
    memory: 128Mi
  limits:
    cpu: 500m
    memory: 512Mi
EOF
helm install web bitnami/nginx \
  --namespace demo \
  --create-namespace \
  --version 22.6.10 \
  -f values-web.yaml

Cài đặt bằng file values riêng giúp bạn kiểm soát thay đổi tốt hơn nhiều so với nhét một đống --set trên command line. Với lab đơn giản thì --set vẫn ổn. Nhưng qua 4 đến 5 key là bắt đầu khó đọc, khó review và rất dễ quên.

4) Upgrade

helm upgrade web bitnami/nginx \
  --namespace demo \
  --version 22.6.10 \
  -f values-web.yaml

Trước mỗi lần upgrade, mình thường làm thêm hai việc nhỏ nhưng đáng tiền: backup values đang dùng và xem diff giữa version cũ với version mới. Nếu cluster có nhiều release, đây là thói quen cứu bạn khỏi khá nhiều pha “hôm qua vẫn chạy mà”.

5) History và rollback

helm history web -n demo
helm rollback web 2 -n demo

Rollback là một trong những lý do làm nhiều người thích Helm. Nhưng cũng cần nhớ, rollback chart không đồng nghĩa rollback dữ liệu. Với PostgreSQL hoặc Redis, nếu release mới đã làm thay đổi schema, config hoặc ghi dữ liệu theo cách khác, câu chuyện sẽ phức tạp hơn nhiều. Helm cứu phần manifest rất tốt, còn dữ liệu thì bạn vẫn phải có chiến lược riêng.

Kinh nghiệm khi dùng public charts

Chọn version cụ thể, đừng để latest quyết định thay bạn

Luôn chỉ rõ --version khi install hoặc upgrade. Nếu không pin version, bạn đang để index của repository quyết định lần sau mình deploy cái gì. Chỗ này cực kỳ nguy hiểm khi làm CI/CD hoặc cần tái tạo môi trường.

Backup values đang chạy

helm get values web -n demo -a > backup-values-web-$(date +%F).yaml

Không ít sự cố đến từ việc team nghĩ là đang dùng file values A, nhưng release thật trên cluster đã bị sửa thủ công từ lâu. Backup values giúp bạn biết trạng thái thực tế của release, không phải trạng thái trong trí nhớ.

Kiểm tra bảo mật mặc định

Public chart tốt thường đã có sẵn một số thiết lập an toàn như runAsNonRoot, readOnlyRootFilesystem, allowPrivilegeEscalation: false hoặc giới hạn ServiceAccount token. Nhưng bạn không nên mặc định tin rằng chart nào cũng ổn. Cứ render manifest rồi grep lại cho chắc.

helm template web bitnami/nginx -f values-web.yaml | grep -E 'runAsNonRoot|allowPrivilegeEscalation|readOnlyRootFilesystem'

⚠️ Nếu chart bật quá nhiều thứ mặc định mà bạn không hiểu, đừng tắt đại. Hãy đọc README và template trước. Tắt sai có thể làm chart chạy được nhưng mất lớp bảo vệ quan trọng.

Dùng values file theo môi trường

Mình thường tách values-dev.yaml, values-staging.yaml và values-prod.yaml. Cùng một chart, nhưng tài nguyên, persistence, ingress, autoscaling và secret reference có thể khác rất nhiều giữa các môi trường.

Không nhét secret thẳng vào Git

Bitnami charts cho phép set password khá tiện bằng --set hoặc values file, nhưng điều đó không có nghĩa bạn nên commit password vào repo. Hãy kết hợp Helm với External Secrets, Sealed Secrets hoặc cơ chế secret management mà team bạn đang dùng.

Troubleshooting public charts

Khi public chart có vấn đề, mình thường chia lỗi thành 4 nhóm. Cách chia này giúp khoanh vùng khá nhanh.

• Lỗi values: sai key, sai kiểu dữ liệu, sai indentation
• Lỗi tương thích cluster: StorageClass, IngressClass, Pod Security, API version
• Lỗi tài nguyên: CPU, RAM, PVC, quota namespace
• Lỗi lifecycle: upgrade làm vỡ config, hook chạy lỗi, dependency đổi hành vi

Một bộ lệnh cơ bản nhưng rất hữu ích:

helm lint ./my-chart
helm status web -n demo
helm get values web -n demo -a
helm get manifest web -n demo
kubectl get pods -n demo
kubectl describe pod <pod-name> -n demo
kubectl logs <pod-name> -n demo

Với public chart, đừng chỉ nhìn lỗi từ pod. Nhiều khi vấn đề đến từ giá trị bạn ghi đè không đúng key nên chart rơi về default. Nhìn lại helm get values và helm get manifest thường cho câu trả lời nhanh hơn ngồi đoán.

💡 Nếu chart đổi cấu trúc values giữa hai major version, hãy đọc changelog trước khi upgrade. Đây là kiểu lỗi rất phổ biến khi dùng public charts lâu ngày.

Khi nào nên fork hoặc customize chart

Không phải lúc nào public chart cũng đủ. Có vài trường hợp mình sẽ nghĩ đến chuyện fork hoặc tự build chart riêng:

• Chart chính thức không còn maintain hoặc update quá chậm
• Bạn cần logic template riêng mà values hiện tại không đáp ứng được
• Phải tích hợp sâu với policy, naming convention, sidecar, init container hoặc CRD nội bộ
• Muốn kiểm soát chặt dependency, image source và quy trình release
• Cần chuẩn hóa cho nhiều team dùng chung một chart nội bộ

Nếu chỉ cần đổi vài biến cấu hình, thêm annotation, chỉnh resource hoặc đổi ingress thì chưa cần fork. Dùng values override là đủ. Fork sớm quá dễ kéo theo gánh nặng bảo trì về sau, nhất là khi upstream ra bản vá bảo mật liên tục mà chart nội bộ của bạn lại đứng yên.

Phần tiếp theo của series sẽ nói sâu hơn về lúc nào nên tự viết hoặc custom chart cho ứng dụng riêng. Bạn có thể theo dõi tại bài 6 về custom Helm charts.

FAQ: public charts vs custom charts

Public chart có phù hợp production không?

Có, nếu chart được bảo trì tốt và bạn đã inspect kỹ values, security, persistence, upgrade path. Rất nhiều hệ thống production chạy bằng public chart, đặc biệt với các ứng dụng phổ biến.

Khi nào nên chuyển từ public chart sang custom chart?

Khi nhu cầu của bạn vượt ra ngoài khả năng override thông thường, hoặc upstream không còn theo kịp yêu cầu kỹ thuật, bảo mật, compliance và quy trình release của team.

Bitnami có phải lựa chọn duy nhất cho người mới?

Không. Bitnami chỉ là điểm bắt đầu dễ tiếp cận. Bạn vẫn có thể dùng chart từ vendor chính thức hoặc chart cộng đồng khác, miễn là kiểm tra nguồn phát hành, mức độ maintain và tài liệu đi kèm.

Dùng --set hay file values tốt hơn?

Lab nhỏ thì --set nhanh. Môi trường thật nên dùng file values. Dễ review, dễ lưu version control, dễ backup và dễ tái tạo release hơn.

Rollback bằng Helm có đủ để cứu mọi sự cố không?

Không. Helm rollback xử lý tốt phần release manifest. Nếu dữ liệu đã thay đổi, schema đã migrate hoặc image mới làm phát sinh side effect, bạn vẫn cần backup và kế hoạch khôi phục dữ liệu riêng.

Tổng kết

Public repository là cách vào Helm nhanh và thực dụng nhất. Artifact Hub giúp bạn tìm chart. Bitnami cho bạn một điểm khởi đầu dễ học. Còn Helm CLI giúp bạn kiểm tra chart trước khi đụng vào cluster. Khi đã quen workflow search, inspect, install, upgrade và rollback, bạn sẽ thấy dùng public chart không phải là cài cho nhanh rồi phó mặc, mà là tận dụng công sức upstream trong khi vẫn giữ quyền kiểm soát ở phía mình.

Sang phần 6, mình sẽ đi vào bài toán custom chart: khi nào nên tự viết, khi nào chỉ cần bọc chart cũ, và cách tránh biến chart nội bộ thành cục nợ bảo trì.