雲原生交付加速！容器鏡像服務企業版支持 Helm Chart

2018 年 6 月，Helm 正式加入了 CNCF 孵化項目；2018 年 8 月，據 CNCF 的調研代表，有百分之六十八的開發者選擇了 Helm 做爲其應用包裝方案；2019 年 6 月，阿里雲正式開放了開放雲原生應用中心，爲國內用戶提供了海量的本地化 Helm Charts 應用；2019 年 7 月，阿里雲鏡像服務企業版正式開放了 Helm Charts 託管能力，容許企業版用戶完成私有 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 託管功能開放

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

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 來自動完成鑑權，提高數據安全性和用戶體驗。

圖爲 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 類型倉庫。

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

安裝並配置客戶端
從官方下載須要的 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/AliyunCont...

初始化

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 <本地倉庫名稱>
​
您能夠在企業版控制檯查看這些版本的大小信息並便捷管理版本，點擊幫助文檔，查看更多操做詳情。

圖爲企業版 Chart 版本列表界面

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