正式開放 | 阿里雲 10 億級鏡像服務正式支持 Helm Charts，雲原生交付再加速！

• 2018 年 6 月，Helm 正式加入了 CNCF 孵化項目；
• 2018 年 8 月，據 CNCF 的調研代表，有百分之六十八的開發者選擇了 Helm 做爲其應用包裝方案；
• 2019 年 6 月，阿里雲正式開放了開放雲原生應用中心，爲國內用戶提供了海量的本地化 Helm Charts 應用；
• 2019 年 7 月，阿里雲鏡像服務企業版正式開放了 Helm Charts 託管能力，容許企業版用戶完成私有 Helm Charts 的推送、拉取以及批量管理；
• 2019 年 8 月，雲原生應用大賽開啓（9 月 2 日前都可報名），鼓勵和普及 Helm Charts 在國內的使用。

Helm Chart，到底是什麼呢？

伴隨着雲原生技術的迅速崛起，Kubernetes 事實上已經成爲應用容器化平臺的標準，成爲了雲原生領域的一等公民。它以一種聲明式的容器編排與管理體系，讓軟件交付變得愈來愈標準化。具體來講，Kubernetes 提供了統一模式的 API，能以 YAML 格式的文件定義 Kubernetes 集羣內的資源。這些資源的種類繁多，例如無狀態應用的部署 Deployment，有狀態應用的部署 StatefulSet，配置項 ConfigMap 等等。

這一些 YAML 格式的資源定義使得 Kubernetes 能輕鬆被上下游系統所集成，完成一系列本來須要用非標準化腳本、人工來完成的操做。可是這些文件的缺點也很明顯，當咱們想要建立一個資源時，每每要書寫這樣的一個 YAML 文件，這對於剛入門的開發者來講，存在着一些門檻。同時，當咱們在大團隊中協做，迭代這些資源時，就總以爲直接修改這樣一個文件，會有衝突，沒法回滾，難以溯源，邊界模糊等問題。

所以雲原生社區也衍生出了一系列最佳實踐解決這些痛點，例如：

• 一些人將 YAML 文件都放到一個 Git 倉庫中，依賴於 Git 的版本管理能力來管理線上架構，藉助 CI 平臺完成從 Git 倉庫到線上環境的自動部署，人們把這稱爲 GitOps。GitOps 解決了 YAML 沒法被版本化、變動沒法溯源的問題；
• kubernetes-sigs/kustomize 引入了 YAML 的公共模塊機制，使得不一樣的 YAML 之間能夠彼此引用依賴，使書寫更加方便，維護起來更加清晰；
• 本文的主角 Helm 也是其中一個項目，它提出了 Chart 這個概念。一個 Chart 打包了一個應用的全部Kubernetes 資源的 YAML 文件，對外提供文檔、配置項、版本等信息。而 Helm 自己則是一個命令行工具，咱們可使用 Helm 提交一個 Chart 到 Kubernetes 集羣中，運行在集羣中的控制器（v2 中爲 tiller）會將 Chart 內的資源分別部署到 Kubernetes 集羣中。

人們擅長於用已知來理解未知，咱們就用下表來簡單地介紹 Kubernetes 的世界中 Helm 的角色。

從現狀來看，Helm 已經成爲了應用分發界事實上的標準，但仍能聽到一些反聲音表示：在生產環境中使用，務必三思然後行：

• Helm 的書寫過程就是反人類的，Golang Template 的引入讓事情變得更加複雜；
• Helm 生命週期管理能力很弱，沒法處理複雜的部署；
• v2 版本中 Tiller 的引入，讓 RBAC 變得毫無做用。

Helm Chart 現狀

根據 CNCF 在去年八月份的調研，有百分之六十八的人選擇了 Helm Chart。不只僅是開源軟件的第三方交付，許多企業內部也藉助 Helm 對於運行態 Release 的管理功能，知足其實現軟件迭代過程當中軟件版本化、可追溯、可回滾方面的訴求。

在這些企業內部，用戶使用 Chart 時面臨着 Chart 存儲方案的選擇難題。咱們作了一些調研，其實能被選擇的方案並很少。一些用戶將 Chart 直接放到 Git 倉庫中進行版本化管理，一些客戶則藉助於開源軟件來搭建一個相似於 Docker Hub 的 Chart 倉庫來完成 Chart 託管，而有另一些開源軟件，則實現了一個 Helm 插件，能夠將 Helm Chart 直接推送到相似於 OSS、S3 這樣的對象存儲中去。

然而對於企業級客戶而言，這幾種方案都面臨着一些缺點。Git 倉庫上手快，但其 Chart 內容版本和 Git 倉庫分支沒有關聯；以開源軟件搭建的 Chart 倉庫又是另一個須要維護的應用，增長了基礎架構的依賴；Helm Chart 直接推送到 OSS 中，缺乏企業級的權限管理，管理幾乎都在命令行中完成。

鏡像服務企業版 Helm Chart 託管功能開放

圖 1：基於鏡像服務企業版的軟件迭代一站式解決方案

2019 年 7 月，阿里雲鏡像服務企業版正式開放了 Helm Chart 託管能力，提供了與容器鏡像幾乎同樣的使用體驗，理論上能夠支持無限量的 Helm Chart 託管，提供 99.999999999% 的數據可靠性。類比於其餘同類別的開源產品，咱們作了深度改造，提供了以下的企業級特性：

安全合規

做爲雲服務提供，第一要務即是安全合規。在社區默認的例子裏，Chartmuseum 使用了 Basic Auth 的認證，這種認證一般爲固定的密碼，沒法接入阿里雲 RAM 鑑權體系。在改造中，咱們將 Chartmuseum 改爲了 OAuth 2.0 Bearer Token 的鑑權機制，借鑑了 Registry 與 Docker Engine 之間的鑑權鏈路。同時開發了 Helm 客戶端插件 AliyunContainerService/helm-acr 來自動完成鑑權，提高數據安全性和用戶體驗。

圖 2： OAuth2.0 鑑權鏈路，來自 chartmuseum/auth-server-example

RAM 鑑權管理體系

默認 Chartmuseum 的 UI 控制檯沒法完成一些複雜的操做。咱們但願控制檯能夠容許：

• 多命名空間和 Chart 倉庫管理；
• 不一樣子帳號對不一樣命名空間的權限管理；
  原生的 Chartmuseum 提供了 depth 的參數，用於控制租戶級別：當 depth 等於 0 時，它表現爲一個平面的倉庫，能夠堆聽任意 Chart 版本。當 depth 等於 2 時，它增長了 org（組織），repo（倉庫）的概念以下：

charts
├── org1
│   ├── repoa
│   │   └── nginx-ingress-0.9.3.tgz
├── org2
│   ├── repob
│   │   └── chartmuseum-0.4.0.tgz

爲了讓 Chartmuseum 的層級與咱們現有的容器鏡像保持統一，咱們配置 depth 爲 2，將組織映射到了咱們的命名空間，將倉庫映射到了咱們的倉庫，而這個倉庫則是一片平地，能夠推任意版本的 Chart。

基於這部分關係映射後，咱們經過回調改造將 Chartmuseum 的關係同步映射過來，以下表。結合阿里雲的 RAM 鑑權策略，咱們能夠很是方便地對不一樣子帳號、不一樣命名空間、倉庫進行受權管理。

鏡像服務企業版
├── 命名空間 A
│   ├── Chart 倉庫 A
│   │   └── nginx-ingress-0.9.3.tgz
├── 命名空間 B
│   ├── Chart 倉庫 B
│   │   └── chartmuseum-0.4.0.tgz

自定義網絡 ACL

與企業版中提供的容器鏡像服務一致，咱們對 Helm Chart 託管能力的可訪問入口也提供了自定義網絡 ACL 的能力，您能夠指定不一樣的 VPC、互聯網 IP 地址訪問到不一樣的企業版實例。

動手實踐

容器鏡像服務企業版支持 v2 版本的 Chart 安全託管，在企業版實例概覽頁開啓 Charts 組件，待組件狀態變爲運行中，便可開始託管 Chart 類型倉庫。

圖 3：容器鏡像服務企業版概覽界面

安裝並配置客戶端

從官方下載須要的 Helm Chart 版本。

# 解壓縮
tar -zxvf helm-v2.14.2-linux-amd64.tgz
# 移動至指定位置
mv linux-amd64/helm /usr/local/bin/helm

使用 Helm Chart 託管功能時，請確保客戶端爲 v2 最新版本，能夠經過 helm version -c 確認，建議使用 v2.14.2 版本。

# 安裝 Helm 插件，請注意預先安裝 git
helm plugin install https://github.com/AliyunContainerService/helm-acr
# 初始化
# 1. 若是您當前在容器服務集羣節點上，默認已經有初始化完成的 tiller ，只須要初始化 client。可使用 skip-refresh 命令避免訪問 google Chart 源：
helm init --client-only --skip-refresh
# 2. 若是您當前在自建的 Kubernetes 集羣節點上，而且但願避免訪問 google Chart 源，可使用如下命令：
helm init --skip-refresh

配置本地倉庫映射

您須要指定一個本地倉庫名稱，映射到線上某一個命名空間下的某一個 Chart 倉庫。

export HELM_REPO_USERNAME='<企業版實例訪問憑證中帳號>';
export HELM_REPO_PASSWORD='<企業版實例訪問憑證中密碼>';
helm repo add <本地倉庫名稱> acr://<實例名稱>-chart..cr.aliyuncs.com/<命名空間>/<Chart 倉庫> --username ${HELM_REPO_USERNAME} --password ${HELM_REPO_PASSWORD}

推送 Chart

在簡單配置企業版實例的訪問憑證並打開網絡訪問控制後，就能夠在終端推送 Chart 到 Chart 倉庫中。

# 本地建立一個 Chart
helm create <Chart 名稱>
# 推送 Chart 目錄
helm push <Chart 名稱> <本地倉庫名稱>
# 或者推送 Chart 壓縮包
helm push <Chart 名稱>-<Chart 版本>.tgz <本地倉庫名稱>

您能夠在企業版控制檯查看這些版本的大小信息並便捷管理版本，點擊幫助文檔，查看更多操做詳情。 

圖 4：企業版 Chart 版本列表界面

將來

阿里雲容器鏡像服務（ACR）是國內最大的公有云鏡像服務平臺之一，支撐數萬名開發者，十億級別的鏡像拉取，爲開發者的每一個應用鏡像保駕護航。容器鏡像服務企業版（ACR EE）是新推出面向企業級客戶的安全託管平臺，支持容器鏡像及 Helm Chart 多種雲原生應用資產管理，提供企業版實例獨享部署、自定義網絡訪問控制及 P2P 大規模鏡像分發等功能。將來咱們將持續改進、優化 Helm Chart 託管能力，提供自定義接入域名，服務端 BYOK 存儲加密等企業級功能。

原文連接 本文爲雲棲社區原創內容，未經容許不得轉載。