Shulou(Shulou.com)06/03 Report--

This week, Helm officially released a blog to guide users to migrate from v2 to v3, which marks the gradual maturity of Helm. As early as June this year, Aliyun officially released China's first Helm Hub mirror station: open Cloud native Tencent App Center-Cloud Native App Hub.

After three months of growth and precipitation, Helm Hub China Mirror Station has synchronized all the contents of Helm Hub in real time, as well as a number of popular third-party Charts Repo, such as GitLab. Up to now, a total of 859 Charts have been launched, and it is still increasing.

In order to encourage and popularize the use of Helm Charts in China, and help domestic developers package and distribute their applications through cloud native methods, so as to better make use of the tide of cloud native, so that their software can play the maximum energy in the cloud era, Aliyun held the first cloud native application development contest, which took 42 days and finally selected 33 Helm Charts to win the most popular award, and one Helm Charts won the judges' choice award. All submitted Chart will be strictly tested and evaluated by the judges.

Judges' Choice Award

✅ award-winning work: etcd-manage

GitHub ID:shiguanghuxian, author of ✅

Etcd-manage is an etcd management tool written in Go with a friendly interface (similar to Ali Cloud background). Managing key is as convenient as managing local files. Simple rights management is supported to distinguish between read-only and read-write permissions.

Comments by ✅ judges

Etcd-manage is a simple etcd management tool that provides a good visual interface with good originality, practicality and close to the native concept of community cloud.

On the other hand, we can see that the author has done a good job in the user experience, providing two options of automatic installation and importing external database for the dependent database, and the documentation is more comprehensive.

Most popular award

After a comprehensive consideration by several judges from a technical and practical point of view, 33 works were awarded the "most popular Award".

Data as of 10:00 on September 2

The words of the contestants

✅ award-winning work: redis-operator

GitHub ID:SataQiu, author of ✅

Cloud origin is the future! It gives me great pleasure to participate in this cloud native application competition. Thank the judges for their patient guidance, which has given me a deeper understanding of cloud native. I hope similar competitions and activities can be held in the future. I am happy to participate!

✅ award-winning work: etcd-manage

GitHub ID:shiguanghuxian, author of ✅

The language expression ability is limited, and it is hoped that App Hub China Station can provide more companies and developers with convenient application publishing and service middleware deployment capabilities. With the popularity of service deployment and development models such as K8s, the application prospect of Helm will certainly be very bright.

This time, I will work overtime to finish the first version of my application 2.0. the goal is to be a practical tool for everyone. I have learned a lot from never knowing Helm to learning packaged applications. I will develop some applications in the future. I also hope to develop some convenient application deployment tools with the help of Helm.

✅ award-winning work: nvidia-gpu-exporter

GitHub ID:wikiios, author of ✅

App Hub needs more practical Helm, and cloud native applications are an irresistible trend!

✅ award-winning work: hugo

GitHub ID:sunny0826, author of ✅

Participating in this cloud native application competition not only gives full play to the usual Helm skills, but also gets a lot of improvement in the communication with other contestants, finds a lot of interesting charts, and benefits a lot. It is hoped that App Hub will continue to evolve, and deploying cloud native applications on K8s clusters will be as convenient as using yum installation on CentOS in the near future!

……

How to make your own Helm Charts

In our daily life, we often deal with a variety of applications on different platforms, such as Taobao, Gaode and Alipay downloaded from Apple's App Store, or Word, Photoshop and Steam installed on PC. For most of these applications on various platforms, users only need to click to install.

However, on the Kubernetes, deploying an application is often not that easy. If you want to deploy an application to the cloud, first prepare the environment it needs and package it into a Docker image. Then put the image in the deployment file (Deployment), configuration service (Service), account (ServiceAccount) and permissions (Role), namespace (Namespace), key information (Secret), persistent storage (PersistentVolumes) and other resources. That is to write a series of interrelated YAML configuration files and deploy them on the Kubernetes cluster.

But even if the developers of the application can store these Docker images in a public repository and provide the YAML resource files needed for deployment to users, users still need to find these resource files themselves and deploy them one by one. If a user wants to modify the default resources provided by the developer, such as using more copies (Replicas) or modifying the service port (Port), he also needs to find out where the resource files should be modified, not to mention how much trouble version changes and maintenance will cause to developers and users. It can be seen that the most primitive Kubernetes application form is not convenient.

Helm and Helm Chart

In such an environment, a series of Kubernetes-based application package management tools came out of nowhere. And our protagonist today, Helm, is one of the most popular choices.

Developers package the resource files required by the application according to Helm Chart format, expose some variable fields (such as which port to expose and how many copies to use) by Templating, and finally store the packaged application package, namely Helm Chart, in a unified warehouse for users to browse and download.

From the user's point of view, the user can install, uninstall and upgrade the application with a simple command. The post-installation status can also be queried through helm list or native kubectl.

$helm install redis stable/redis$ kubectl get podsNAME READY STATUS RESTARTS AGEredis-master-0 1 Running 0 63sredis-slave-0-0 1 63sredis-slave-1 1 Running 0 63sredis-slave-1-0 1 63sredis-slave-1 1 Running 0 13s$ helm delete redis Creative Helm Chart

So from the developer's point of view, how should we create a Helm application package?

Preparatory work

First of all, we need an image ready for deployment. This image can be a Java program, a Python script, or even an empty linux image to run a few commands.

Here we use a simple golang-based. The service gets the user-defined name by reading the environment variable USERNAME, and then listens on port 80. For any HTTP request, return Hello ${USERNAME}. For example, if you set USERNAME=world (the default scenario), the service will return Hello world.

Then we use to package the image. First compile the Golang code, and then put the compiled program in an alpine-based image to reduce the size of the image.

After Docker builds the image, we upload the image to the repository, such as Docker Hub or Ali Cloud container image repository. After the preparatory work is done, we can start to create Helm Chart. >

Start to create

Run helm create my-hello-world and you will get an empty chart automatically generated by helm. The name in this chart is my-hello-world. It is important to note that the my-hello-world name in Chart needs to be the same as the generated Chart folder name. If you modify the my-hello-world, you need to make consistent changes. Now, we see that the folder directory for Chart is as follows:

My-hello-world ├── charts ├── Chart.yaml ├── templates │ ├── deployment.yaml │ ├── _ helpers.tpl │ ├── ingress.yaml │ ├── NOTES.txt │ └── service.yaml └── values.yaml

In the Chart.yaml file under the root directory, declare the name, version and other basic information of the current Chart, which will be available for users to browse and retrieve after the Chart is put into the warehouse. For example, we can change the Description of Chart to "My first hello world helm chart". There are two version-related fields in Chart.yaml, where version indicates the version of Chart, that is, the version of our application package, and appVersion indicates the actual internal application version.

YAML files, such as Deployment and Service, are stored in the templates folder for all kinds of application deployment. In our current application, we only need one deployment, and some applications may contain different components and require multiple deployments, so we can place deploymentA, deploymentB and so on under the templates folder. Similarly, if we need to configure serviceaccount, secret, volumes, etc., we can also add the corresponding configuration file to it.

ApiVersion: apps/v1beta2kind: Deploymentmetadata: name: {{template "my-hello-world.fullname". }} labels: {{include "my-hello-world.labels". | indent 4}} spec: replicas: {{.Values.replicaCount}} selector: matchLabels: app.kubernetes.io/name: {{include "my-hello-world.name". }} app.kubernetes.io/instance: {{.Release.Name}} template: metadata: labels: app.kubernetes.io/name: {{include "my-hello-world.name". } app.kubernetes.io/instance: {{.Release.Name}} spec: containers:-name: {{.Chart.Name}} image: "{{.Values.image.repository}: {{.Chart.AppVersion}}" imagePullPolicy: {{.Values.image.pullP olicy}} env:-name: USERNAME value: {{.Values.Username}}.

Helm Chart's packaging of applications is not just about integrating Deployment with Service and other resources. We see that the deployment.yaml and service.yaml files are placed in the templates/ folder, with many more injectable fields for rendering than the native Kubernetes configuration. For example, in the spec.replicas of deployment.yaml, you use the static value of .Values.replicaCount instead of the Kubernetes itself. This field, which controls how many running copies the application should have on Kubernetes, can have different values in different application deployment environments, and this value is provided by the injected Values.

ReplicaCount: 1image: repository: somefive/hello-world pullPolicy: IfNotPresentnameOverride: "" fullnameOverride: "" service: type: ClusterIP port: 80.Username: AppHub

In the root directory, we see a values.yaml file that provides the default parameters for the application at installation time. In the default Values, we see that replicaCount: 1 indicates that the application has only one copy in the default deployment state.

In order to use the image we want to deploy the application, we see that in deployment.yaml, in spec.template.spec.containers, both image and imagePullPolicy use the values in Values.

Where the image field consists of .Values.image.repository and .Chart.AppVersion. When you see this, you should know the fields we need to change: one is image.repository in values.yaml, and the other is AppVersion in Chart.yaml. We match them to the docker images that we need to deploy the application. Here we set the image.repository in values.yaml to somefive/hello-world and the AppVersion in Chart.yaml to 1.0.0.

Similarly, we can look at the services we want to deploy in service.yaml, and the main configuration is also in values.yaml. The default generated service exposes port 80 to the Kubernetes cluster. We don't need to modify this part for the time being.

Since the deployed hello-world service reads the USERNAME environment variable from the environment variable, we add this configuration to the deployment.yaml.

-name: {{.Chart.Name}} image: "{{.Values.image.repository}: {{.Chart.AppVersion}}" imagePullPolicy: {{.Values.image.pullPolicy}} env:-name: USERNAME value: {{.Values.Username}}

Now our deployment.yaml template loads the Username field from values.yaml, so we also add Username: AppHub to values.yaml accordingly. Now, our application will read the Username from values.yaml and put it in the mirrored environment variable to start.

Check packing

After preparing our application, we can use Helm lint to roughly check whether there are any grammatical errors in the created Chart. If there is no problem, we can use the helm package command to package our Chart folder, and after packaging we can get a my-hello-world-0.1.0.tgz application package. This is the application we have completed.

$helm lint-strict my-hello-world1 chart (s) linted, 0 chart (s) failed [INFO] Chart.yaml: icon is recommended$ helm package my-hello-world

We can use the helm install command to try to install the application package we just made, and then use kubectl to check the status of running pod. We can map the port of the pod to the local port through the port-forward command, and then we can access the deployed application by accessing localhost.

$helm install my-hello-world-chart-test my-hello-world-0.1.0.tgz$ kubectl get podsNAME READY STATUS RESTARTS AGEmy-hello-world-chart-test-65d6c7b4b6-ptk4x-0 1ax 1 Running 0 4m3s $kubectl port-forward my-hello-world-chart-test-65d6c7b4b6-ptk4x 8080 kubectl port-forward my-hello-world-chart-test-65d6c7b4b6-ptk4x 80$ curl localhost:8080Hello AppHub parameter overload

Some students may be confused, although we application developers expose configurable information in the values.yaml, what should users do if they want to modify the application? The answer is simple: users only need to use the set parameter to set the parameters they want to override when install.

Application developers only provide default installation parameters in the values configuration of Chart, and users can also specify their own configuration during installation. Similarly, if the user can replace install with the upgrade command, the configuration can be changed based on the previously deployed application.

$helm install my-app my-hello-world-0.1.0.tgz-- set Username= "Cloud Native" $helm install my-super-app my-hello-world-0.1.0.tgz-f my-values.yaml$ helm upgrade my-super-app my-hello-world-0.1.0.tgz-f my-new-values.yaml modification prompt

We notice that after the installation Chart instruction runs, the output of the screen appears:

NOTES:1. Get the application URL by running these commands: export POD_NAME=$ (kubectl get pods-l "app=my-hello-world,release=my-hello-world-chart-test2"-o jsonpath= "{.items [0] .metadata.name}") echo "Visit http://127.0.0.1:8080 to use your application" kubectl port-forward $POD_NAME 8080

The comments here are provided by templates/NOTES.txt in Chart. We noticed that the "app= {{template" my-hello-world.name ".}}, release= {{.Release.Name}}" written in the original NOTES is quite different from the configuration written in our deployment.yaml. We can change it to "app.kubernetes.io/name= {{template" my-hello-world.name ".}}, app.kubernetes.io/instance= {{.Release.Name}}" and update the version in values.yaml to 0.1.1. Then repackage Chart (run helm package). After you get the new my-hello-world-0.1.1.tgz, upgrade the original Chart (run helm upgrade my-hello-world-chart-test2 my-hello-world-0.1.1.tgz-- set Username= "New Chart"), and you can see the updated NOTES.

NOTES:1. Get the application URL by running these commands: export POD_NAME=$ (kubectl get pods-l "app.kubernetes.io/name=my-hello-world,app.kubernetes.io/instance=my-hello-world-chart-test2"-o jsonpath= "{.items [0] .metadata.name}") echo "Visit http://127.0.0.1:8080 to use your application" kubectl port-forward $POD_NAME 8080 export POD_NAME=$ App sharing

So how do you share the finished application with others? ChartMuseum, officially launched by Helm, provides a way to build Chart repositories, which you can use to create your own Chart repositories. However, it is expensive to maintain a warehouse on its own, and for users, if each developer is his own warehouse, he needs to add the corresponding warehouse of the required applications to his own search list, which is not conducive to the dissemination and sharing of applications.

Open cloud native Tencent App Center Cloud Native App Hub not only synchronizes all kinds of applications, but also provides a channel for developers to upload applications.

In our open cloud native Tencent App Center, applications come from two channels. On the one hand, we regularly synchronize Chart resources from some well-known foreign Helm repositories, and in the process of synchronization, we synchronously replace some Docker images used internally in Chart (such as gcr.io or quay.io images) to facilitate access by domestic users; on the other hand, like the Helm official library, we accept developers to submit their applications through Pull Request. Successful applications will be synchronized to the cloud native Tencent App Center in a short time and displayed together with other official apps for other users.

I hope you can participate together to make the original Tencent App Center of Open Cloud richer and benefit more people!

Brief introduction of the author:

Yin Da, a graduate student majoring in computer science at Tsinghua University and Carnegie Mellon University, internship in Aliyun Container platform Department, mainly involved in ACK container service cloud technology and cloud native application development.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.