In June 2018, Helm officially joined the CNCF incubation program;
In August 2018, according to CNCF, 68 percent of developers chose Helm as their application packaging solution;
In June 2019, Ali Cloud officially opened the Open cloud native Application Center, providing a large number of localized Helm Charts applications for domestic users.
In July 2019, Alibaba Cloud Image Service Enterprise edition officially opened the hosting capability of Helm Charts, allowing enterprise users to complete push, pull and batch management of private Helm Charts.
In August 2019, the Cloud Native Application Competition opened (registration can be accepted before September 2), encouraging and popularizing the use of Helm Charts in China.

Helm Chart, what is it?

With the rapid rise of cloud native technology, Kubernetes has become the de facto standard for application containerization platforms, becoming a first-class citizen in the cloud native space. It standardizes software delivery with a declarative container orchestration and management system. Specifically, Kubernetes provides a unified mode API that defines resources within a Kubernetes cluster in YAML format files. There are many kinds of resources, such as Deployment of stateless applications, Deployment of StatefulSet for stateful applications, ConfigMap, and so on.

These resource definitions in YAML format allow Kubernetes to be easily integrated with upstream and downstream systems to perform a series of operations that would otherwise require manual, non-standard scripting. However, the disadvantages of these files are obvious. When we want to create a resource, we often have to write such a YAML file, which has some barriers for beginners. At the same time, when we were working in a large team and iterating over these resources, there was always a sense that directly modifying such a file would cause conflicts, could not be rolled back, was hard to trace, had blurred boundaries, etc.

As a result, the cloud native community has developed a set of best practices to address these pain points, such as:

Some people put their YAML files in a Git repository, rely on Git’s version management capabilities to manage their online architecture, and use a CI platform to automate deployment from their Git repository to their online environment, known as GitOps. GitOps solves the problem that YAML cannot be versioned and changes cannot be traced;
Kubernetes-sigs/Kustomize introduces the common module mechanism of YAML, which enables different YAMLS to reference and rely on each other, making writing easier and maintaining clearer.
Helm, the protagonist of this paper, is also one of the projects, which proposed the concept of Chart. A Chart package YAML files for all Kubernetes resources of an application, providing documents, configuration items, versions and other information. Helm itself is a command line tool. We can use Helm to submit a Chart to Kubernetes cluster, and the controller (TILler in V2) running in the cluster will deploy the resources in Chart to Kubernetes cluster.

People are good at using the known to understand the unknown, so the following table briefly describes Helm’s role in Kubernetes’ world.

As it stands, Helm has become the de facto standard in the application distribution world, but there are still voices saying: Think twice before using it in production:

Helm’s writing process was anti-human, and the introduction of the Golang Template made things more complicated;
The Helm lifecycle management capability is weak to handle complex deployments;
The introduction of Tiller in v2 rendered RBAC useless.

Helm status Chart

Sixty-eight percent chose Helm Chart, according to a CNCF survey conducted last August. In addition to third-party delivery of open source software, many enterprises also make use of Helm’s management function for running Release to meet their demands of software versioning, traceability and rollback during software iteration.

In these enterprises, users are faced with the problem of choosing Chart storage scheme when using Chart. We did some research, and there weren’t many options. Some users directly put Chart into Git repository for versioning management, some customers use open source software to build a Chart repository similar to Docker Hub to complete Chart hosting, and some other open source software implements a Helm plug-in. You can push Helm Chart directly into object stores such as OSS and S3.

However, for enterprise customers, all of these solutions face some disadvantages. Git repository is fast, but its Chart content version is not associated with Git repository branch; Chart warehouse built with open source software is another application that needs to be maintained, which increases the dependence of infrastructure. Helm Chart is directly pushed to OSS, lacking enterprise-level permission management, which is almost completed in the command line.

Image Services Enterprise Edition Helm Chart hosting is open

Figure 1: Software iteration one-stop solution based on Mirroring Services Enterprise Edition

In July 2019, Ali Cloud Image Service Enterprise edition officially opened the Helm Chart hosting capability, which provides almost the same use experience as container image. Theoretically, it can support unlimited Helm Chart hosting and provide 99.999999999% data reliability. Compared to other open source products in the same category, we have made a deep transformation to provide the following enterprise-level features:

Safety compliance

As a cloud service provider, the first priority is security compliance. In the default example of the community, Chartmuseum uses Basic Auth authentication, which is usually a fixed password and cannot access ali Cloud RAM authentication system. In the transformation, we changed Chartmuseum into OAuth 2.0 Bearer Token authentication mechanism, referring to the authentication link between Registry and Docker Engine. Helm is developed at the same time the client plug-in AliyunContainerService/Helm – acr to automatically complete authentication, improve data security and user experience.

Figure 2: OAuth2.0 authentication link, from ChartMuseum/Auth-server-Example

RAM authentication Management system

By default, Chartmuseum’s UI console cannot perform complex operations. We want the console to allow:

Multi-namespace and Chart warehouse management;
Different subaccounts manage permissions on different namespaces. The native Chartmuseum provides a depth parameter to control the tenant level: when depth equals 0, it appears as a flat repository that can stack any Chart version. When depth is equal to 2, it adds org (organization), repO (repository) concepts as follows:

Charts ├ ─ ─ org1 │ ├ ─ ─ repoa │ │ └ ─ ─ nginx - ingress - 0.9.3. TGZ ├ ─ ─ org2 │ ├ ─ ─ repob │ │ └ ─ ─ chartmuseum - 0.4.0. TGZCopy the code

To keep the Chartmuseum hierarchy consistent with our existing container images, we set a depth of 2 to map the organization to our namespace and the repository to our repository, which is a flat surface that can push any version of Chart.

Based on this part of relation mapping, we synchronously map the relation of Chartmuseum through callback transformation, as shown in the following table. With the RAM authentication strategy of Ali Cloud, we can easily manage the authorization of different sub-accounts, different namespaces and warehouses.

A mirror service enterprise edition ├ ─ ─ namespace │ ├ ─ ─ Chart warehouse A │ │ └ ─ ─ nginx - ingress - 0.9.3. TGZ ├ ─ ─ namespace B │ ├ ─ ─ Chart warehouse B │ │ └ ─ ─ Chartmuseum - 0.4.0. TGZCopy the code

User-defined network ACLs

In line with the container mirroring service provided in Enterprise Edition, our access portal to Helm Chart’s hosting capabilities also provides the ability to customize network ACLs. You can specify different VPCS and Internet IP addresses to access different enterprise edition instances.

Hands-on practice

Container Mirroring Service Enterprise edition supports secure hosting of Chart V2. Open the Charts component on the Enterprise Edition Instance Overview page. After the component status changes to running, you can start hosting Chart type repository.

Figure 3: Container Mirroring Services Enterprise Edition Overview interface

Install and configure the client

Download the required Helm Chart version from the official.

# decompressionTar - ZXVF helm - v2.14.2 - Linux - amd64. TGZMove to the specified position
mv linux-amd64/helm /usr/local/bin/helmCopy the code

When using the Helm Chart hosting function, ensure that the client is V2 of the latest version. You can check the Helm Version -c. V2.14.2 is recommended.

Note that git is pre-installed
helm plugin install https://github.com/AliyunContainerService/helm-acr
# initialization
# 1. If you are currently on a container service cluster node, you already have tiller initialized by default, just initialize the client. You can use the skip-refresh command to avoid accessing the Google Chart source:
helm init --client-only --skip-refresh
# 2. If you are currently on a self-built Kubernetes cluster node and want to avoid accessing the Google Chart source, you can use the following command:
helm init --skip-refreshCopy the code

Configure the local warehouse mapping

You need to specify a local repository name that maps to a Chart repository in a namespace on the line.

export HELM_REPO_USERNAME='< Account number in enterprise Edition Instance Access Credentials >';
export HELM_REPO_PASSWORD='< Password in enterprise instance access credentials >'; Helm repo add < store name > acr:// Cr.aliyuncs.com/ < namespace >/<Chart repository > --username${HELM_REPO_USERNAME} --password ${HELM_REPO_PASSWORD}Copy the code

Push Chart

After simply configuring the access credentials of the enterprise edition instance and enabling network access control, the terminal can push Chart to Chart warehouse.

Create a Chart file locallyHelm create <Chart name ># push Chart directoryHelm Push <Chart name > < local warehouse name ># or push the Chart compression packageHelm Push <Chart name >-<Chart version >.tgz < local warehouse name >Copy the code

You can view the size information for these versions and easily manage them in the Enterprise edition console. Click on help documentation for more details.

Figure 4: Enterprise Edition Chart version list interface

In the future

Ali Cloud container Image Service (ACR) is one of the largest public cloud image service platforms in China, supporting tens of thousands of developers, image pulling at one billion levels, escorting every application image of developers. Container Image Services Enterprise Edition (ACR EE) is a newly launched secure hosting platform for enterprise customers. It supports asset management of container image and Helm Chart cloud native applications, and provides enterprise instance exclusive deployment, customized network access control, and P2P large-scale image distribution. In the future, we will continue to improve and optimize the hosting capability of Helm Chart and provide enterprise-level functions such as customized access domain name and server BYOK storage encryption.

Xie Yuling (Yuqi)

The original link

This article is the original content of the cloud habitat community, shall not be reproduced without permission.

Officially opened | ali cloud image service level 1 billion officially supported Helm Charts, cloud native delivery speed up again!