Quản lý cấu hình ứng dụng triển khai trên GKE cluster qua Google Artifact Registry, helm charts, Private helm registry và Argo-CD
Ngày nay xu hướng công nghệ được áp dụng để phát triển và phát hành một ứng dụng là sử dụng Container, cùng với yêu cầu ngày càng cao về tự động hóa, co giãn linh hoạt, tiết kiệm, giảm thiểu sai phạm thì Kuberntes là một lựa chọn hàng đầu vì độ phổ biến và khả năng đáp ứng đầy đủ các yêu cầu ở trên của nó.
Kubnernets đã có thể đáp ứng đúng, đủ yêu cầu về nền tảng để phát hành ứng dụng, dịch vụ nhưng những yêu cầu về vận hành, phát hành ứng dụng sẽ thường xuyên phát sinh những yêu cầu thay đổi cấu hình. Các yêu cầu thay đổi cấu hình sẽ là không tốn thời gian, công sức vận hành đối với những hệ thống có số lượng ứng dụng, dịch vụ không lớn. Tuy nhiên với những hệ thống lớn thì những yêu cầu thay đổi này sẽ là một thách thức không hề nhỏ, nó có thể ngốn hết khoảng thời gian tính bằng nhiều tháng với nhiều người thạm gia mới có thể thực hiện hết được những thay đổi đó.
Để khắc phục vấn đề về yêu cầu cập nhật thay đổi thì việc xây dựng một bộ mẫu để có thể định nghĩa được các cấu hình chung cho các ứng dụng và nó có thể được ghi đè nếu có yêu cầu đặc biệt hoặc tái sử dụng lại ở các ứng dụng khác nhau là một việc cần thiết, để làm việc này thì Helm là một lựa chọn có thể nói là tốt nhất (trong hiểu biết hiện tại 
).
Trong bài viết này chúng ta sẽ trình bày về việc quản lý cầu hình ứng dụng được triển khai trên GKE cluster qua Google Artifact Registry, Helm charts, private helm registry và Argo-CD.
Các thành phần chính và vai trò
GIT - remote reposity
Remote repository là git repo nơi chứa khai báo các sources helm charts của ứng dụng, cái sẽ quản lý cấu hình của ứng dụng và được argocd-repo-server dùng để tạo là final k8s yaml file triển khai lên k8s.
Google artifact registry
Nơi cung cấp private helm registry, chứa các helm artifacts nơi định nghĩ các bộ mẫu của k8s resource.
Helm charts
Khai báo các helm charts của các ứng dụng cần được triển khai, nó chứa các yaml files mô tả về tài nguyên và cấu hình của một kubernetes resource.
Private Helm Registry
Đóng gói và phân phối các ứng dụng sử dụng helm để triển khai trên kubernetes.
Định nghĩa các helm templates cho các kubernetes resources và nó được dùng kết hợp với helm values file được định nghĩa ở helm charts để tạo ra final k8s manifest files dùng để triển khai lên kubernetes.
Helm artifacts sẽ được publish lên helm private registry (google artifact registry (GAR)) như một helm repo, các helm charts của ứng dụng sẽ dependencies tới nó để tạo ra final k8s manifest.
Argo-CD
CD tool giúp quản lý tập chung việc triển khai các tài nguyên của Kubernetes.
Cách hoạt động của ArgoCD các bạn có thể tham khảo ở bài viết Argo-CD hiểu biết cơ bản
Mô hình triển khai
Quản lý cấu hình ứng dụng qua Helm charts và Argo-CD
Helm với Argo-CD
Helm là một thành phần được triển khai trong Argo-CD repo server, nó chịu trách nhiệm tạo ra k8s yaml manifest từ helm charts của ứng dụng, Argo-CD application sẽ dùng k8s yaml manifest để triển khai ứng dụng lên k8s.
Với những helm charts có dependencies tới private helm registry để tạo ra được final k8s yaml manifest thì trước tiên helm client cần lấy được thông tin để xác thực với private helm registry.
Với trường hợp cụ thể là chúng ta publish một helm artifact lên google artifact registry và chỉ cấp quyền truy cập helm repo cho một google service account cụ thể, và các helm charts của ứng dụng sẽ dependencies đến helm repo này thì chúng cần xác định và thực hiện các bước như chỉ định helm config và xác thực helm registry.
Chỉ định helm config trong các containers của argocd repo server
Các configs của helm được định nghĩa các giá mặc định thông qua các ENV của container như
HELM_CONFIG_HOME="/tmp/.config/helm"
HELM_REGISTRY_CONFIG="/tmp/.config/helm/registry/config.json"
HELM_REPOSITORY_CONFIG="/tmp/.config/helm/repositories.yaml"
các configs này chỉ cho helm client biết cần lấy thông tin của helm registry và repo từ đâu.
Helm registry login
Helm client sẽ đọc thông tin từ HELM_REGISTRY_CONFIG để lấy thông tin truy cập helm registry, nếu HELM_REGISTRY_CONFIG không cung cấp đúng thông tin truy cập helm registry thì sẽ phát sinh lỗi không có quyền truy cập. Với cấu hình HELM_REGISTRY_CONFIG mặc định sẽ không có thông tin dùng để xác thực helm registry và đương nhiên bước triển khai bên trên sẽ gặp lỗi, lúc này cần phải thực hiện login helm registry để có thể tiếp tục.
Google Artifacts registry nơi cung cấp helm registry cung cấp tính năng login bằng access token của user/service account qua command
gcloud auth print-access-token | helm registry login -u oauth2accesstoken --password-stdin https://asia-docker.pkg.dev --registry-config /tmp/.config/helm/registry/config.json
yêu cầu:
- ArgoCD được deploy trên GKE và có quyền truy cập tới GAR
- GKE cluster hỗ trợ workload identidy để pod có thể dùng access token của SA xác thực resource của GCP
- User/service account cần có quyền đọc artifact repo chứa helm artifact.
Container Argo-CD repo server không cung cấp gcloud command nên ta phải dùng tới sidecar và Shared Volume để thực hiện việc login helm registry và ghi thông tin login vào HELM_REGISTRY_CONFIG, để làm việc này ta cần update argocd-repo-server deployment để thêm sidecar ,Shared Volume và update helm ENV
Cấu hình Sidecar (container gcp)
- command:
- /bin/sh
- -c
- while true; do echo 'Hit CTRL+C'; gcloud auth configure-docker asia-docker.pkg.dev
-q; gcloud auth print-access-token | helm registry login -u oauth2accesstoken
--password-stdin https://asia-docker.pkg.dev --registry-config /tmp/.config/helm/registry/config.json;
chown -R 1001:1001 /tmp; sleep 900; done
env:
- name: HELM_REGISTRY_CONFIG
value: /tmp/.config/helm/registry/config.json
- name: HELM_REPOSITORY_CONFIG
value: /tmp/.config/helm/repositories.yaml
- name: HELM_CONFIG_HOME
value: /tmp/.config/helm
image: asia.gcr.io/devops/k8s-deployer:v3.11.0 // image có cung cập gcloud command
imagePullPolicy: IfNotPresent
name: gcp
resources: {}
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File
volumeMounts:
- mountPath: /tmp
name: tmp-dir
Cấu hình Shared volume
volumes:
- ...
- emptyDir: {}
name: tmp-dir
mount volume name tmp-dir cho 2 containers gcp và argocd-repo-server
volumeMounts:
- mountPath: /tmp
name: tmp-dir
Cấu hình Helm ENV
Set helm ENV ở 2 containers gcp và argocd-repo-server
env:
- name: HELM_REGISTRY_CONFIG
value: /tmp/.config/helm/registry/config.json
- name: HELM_REPOSITORY_CONFIG
value: /tmp/.config/helm/repositories.yaml
- name: HELM_CONFIG_HOME
value: /tmp/.config/helm
Sau khi thực hiện các bước trên helm client được cài đặt trong argocd-repo-server container đã có thể kéo helm dependencies được khai báo trong helm charts của ứng dụng về để tạo ra final k8s manifest.
Khi chúng ta có nhu cầu cập nhật thay đổi các cấu hình chung cho các ứng dụng thì ta có thể chỉ cần update helm templates của helm artifact repo để áp dụng cho tất cả các ứng dụng dùng nó làm gói phụ thuộc.
Chúng ta cũng không cần cung cấp thông tin xác thực helm registry như username/password để xác thực helm registry vì nó đã được xử lý qua google service account nhờ cơ chế workload identity - impersonate để k8s service account đứng danh google service account truy cập các tài nguyên của google mà google service account được cấp quyền.
Xuyên suốt bài viết vấn đề được đề cập đến là quản lý việc triển khai ứng dụng qua GKE và Argo-CD có sử dụng:
- Google artifact registry để publish một private helm registry cho nội bộ một tổ chức
- Helm charts dùng để định nghĩa kubernets resources cho một ứng dụng và sử dụng private helm registry là một dependencies
- Cách cấu hình sử dụng sidecar container và Shared volume để tạo và chia sẻ thông tin xác thực private helm registry cho các containers của argocd repo server giúp đảm bảo tuân thủ bảo mật và độ ổn định của các dependencies.
Tài liệu tham khảo
All rights reserved
