云原生交付加速!容器镜像服务企业版支持 Helm Chart

本文涉及的产品
容器镜像服务 ACR,镜像仓库100个 不限时长
简介: 2018 年 6 月,Helm 正式加入了 CNCF 孵化项目;2018 年 8 月,据 CNCF 的调研表明,有百分之六十八的开发者选择了 Helm 作为其应用包装方案;2019 年 6 月,阿里云正式开放了开放云原生应用中心,为国内用户提供了海量的本地化 Helm Charts 应用;2019 年 7 月,阿里云镜像服务企业版正式开放了 Helm Charts 托管能力,允许企业版用户完成私有 Helm Charts 的推送、拉取以及批量管理,进一步提速云原生交付链路。

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 的角色。
image.png

从现状来看,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 托管功能开放

image.png

图为基于镜像服务企业版的软件迭代一站式解决方案

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 来自动完成鉴权,提升数据安全性和用户体验。

image.png

图为 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 类型仓库。

image.png

图为容器镜像服务企业版概览界面

安装并配置客户端
从官方下载需要的 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 <本地仓库名称>
​

您可以在企业版控制台查看这些版本的大小信息并便捷管理版本,点击帮助文档,查看更多操作详情。
image

图为企业版 Chart 版本列表界面

未来

阿里云容器镜像服务(ACR)是国内最大的公有云镜像服务平台之一,支撑数万名开发者,十亿级别的镜像拉取,为开发者的每个应用镜像保驾护航。容器镜像服务企业版(ACR EE)是新推出面向企业级客户的安全托管平台,支持容器镜像及 Helm Chart 多种云原生应用资产管理,提供企业版实例独享部署、自定义网络访问控制及 P2P 大规模镜像分发等功能。未来我们将持续改进、优化 Helm Chart 托管能力,提供自定义接入域名,服务端 BYOK 存储加密等企业级功能。

相关实践学习
通过容器镜像仓库与容器服务快速部署spring-hello应用
本教程主要讲述如何将本地Java代码程序上传并在云端以容器化的构建、传输和运行。
Kubernetes极速入门
Kubernetes(K8S)是Google在2014年发布的一个开源项目,用于自动化容器化应用程序的部署、扩展和管理。Kubernetes通常结合docker容器工作,并且整合多个运行着docker容器的主机集群。 本课程从Kubernetes的简介、功能、架构,集群的概念、工具及部署等各个方面进行了详细的讲解及展示,通过对本课程的学习,可以对Kubernetes有一个较为全面的认识,并初步掌握Kubernetes相关的安装部署及使用技巧。本课程由黑马程序员提供。 &nbsp; 相关的阿里云产品:容器服务 ACK 容器服务 Kubernetes 版(简称 ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情:&nbsp;https://www.aliyun.com/product/kubernetes
目录
相关文章
|
22天前
|
Kubernetes Cloud Native Docker
云原生时代的容器化实践:Docker和Kubernetes入门
【10月更文挑战第37天】在数字化转型的浪潮中,云原生技术成为企业提升敏捷性和效率的关键。本篇文章将引导读者了解如何利用Docker进行容器化打包及部署,以及Kubernetes集群管理的基础操作,帮助初学者快速入门云原生的世界。通过实际案例分析,我们将深入探讨这些技术在现代IT架构中的应用与影响。
69 2
|
20天前
|
运维 Cloud Native 虚拟化
一文吃透云原生 Docker 容器,建议收藏!
本文深入解析云原生Docker容器技术,涵盖容器与Docker的概念、优势、架构设计及应用场景等,建议收藏。关注【mikechen的互联网架构】,10年+BAT架构经验倾囊相授。
一文吃透云原生 Docker 容器,建议收藏!
|
2天前
|
Kubernetes Cloud Native 微服务
探索云原生技术:容器化与微服务架构的融合之旅
本文将带领读者深入了解云原生技术的核心概念,特别是容器化和微服务架构如何相辅相成,共同构建现代软件系统。我们将通过实际代码示例,探讨如何在云平台上部署和管理微服务,以及如何使用容器编排工具来自动化这一过程。文章旨在为开发者和技术决策者提供实用的指导,帮助他们在云原生时代中更好地设计、部署和维护应用。
|
22天前
|
运维 Kubernetes Cloud Native
云原生技术:容器化与微服务架构的完美结合
【10月更文挑战第37天】在数字化转型的浪潮中,云原生技术以其灵活性和高效性成为企业的新宠。本文将深入探讨云原生的核心概念,包括容器化技术和微服务架构,以及它们如何共同推动现代应用的发展。我们将通过实际代码示例,展示如何在Kubernetes集群上部署一个简单的微服务,揭示云原生技术的强大能力和未来潜力。
|
16天前
|
运维 Cloud Native 云计算
云原生之旅:Docker容器化实战
本文将带你走进云原生的世界,深入理解Docker技术如何改变应用部署与运维。我们将通过实际案例,展示如何利用Docker简化开发流程,提升应用的可移植性和伸缩性。文章不仅介绍基础概念,还提供操作指南和最佳实践,帮助你快速上手Docker,开启云原生的第一步。
|
20天前
|
Cloud Native API 持续交付
云原生之旅:从容器到微服务的演进之路
【10月更文挑战第39天】在这篇文章中,我们将一起探索云原生技术的奥秘。通过浅显易懂的语言和生动的比喻,我们将了解云原生技术如何改变软件开发的世界。文章将带领读者从容器的基本概念出发,逐步深入到微服务架构的实践,揭示这些技术如何助力现代应用的快速迭代与可靠部署。准备好,让我们启程进入云原生的精彩世界吧!
|
23天前
|
Kubernetes Cloud Native Docker
云原生技术探索:容器化与微服务的实践之道
【10月更文挑战第36天】在云计算的浪潮中,云原生技术以其高效、灵活和可靠的特性成为企业数字化转型的重要推手。本文将深入探讨云原生的两大核心概念——容器化与微服务架构,并通过实际代码示例,揭示如何通过Docker和Kubernetes实现服务的快速部署和管理。我们将从基础概念入手,逐步引导读者理解并实践云原生技术,最终掌握如何构建和维护一个高效、可扩展的云原生应用。
|
1月前
|
Kubernetes Cloud Native 微服务
云原生之旅:从容器到微服务
【10月更文挑战第29天】在这篇文章中,我们将一起探索云原生的奥秘。云原生不仅仅是一种技术,更是一种文化和方法论。我们将从容器技术开始,逐步深入到微服务架构,最后探讨如何在云平台上实现高效的服务部署和管理。无论你是初学者还是有经验的开发者,这篇文章都将为你提供有价值的见解和实用的技能。让我们一起踏上这段激动人心的云原生之旅吧!
|
1月前
|
运维 Kubernetes Cloud Native
云原生之旅:容器化与微服务的融合
【10月更文挑战第28天】 在数字化转型的浪潮中,云原生技术如星辰般璀璨,引领着企业IT架构的未来。本文将带你穿梭于云原生的世界,探索容器化技术和微服务架构如何携手共舞,打造灵活、高效的应用部署和运维模式。我们将通过实际代码示例,揭示这股力量背后的奥秘,并展现它们是如何为现代软件开发带来革新。准备好了吗?让我们启航,驶向云原生技术的深海。
|
1月前
|
Kubernetes 负载均衡 Cloud Native
云原生应用:Kubernetes在容器编排中的实践与挑战
【10月更文挑战第27天】Kubernetes(简称K8s)是云原生应用的核心容器编排平台,提供自动化、扩展和管理容器化应用的能力。本文介绍Kubernetes的基本概念、安装配置、核心组件(如Pod和Deployment)、服务发现与负载均衡、网络配置及安全性挑战,帮助读者理解和实践Kubernetes在容器编排中的应用。
74 4

相关产品

  • 容器镜像服务