Helm released this week, the official blog, guide the user to migrate from v2 to v3, which marks Helm matured. As early as June of this year, Ali cloud officially released the first domestic Helm Hub China Mirror Station: Open Cloud native application center - Cloud Native App Hub .
After three months of growth and precipitation, Helm Hub China mirror sites now real-time synchronization of the full amount of all content Helm Hub, but also a selection of synchronization such as GitLab and other popular third-party Charts Repo, as of today, have a total on the line 859 Charts, and is constantly increasing.
In order to encourage and popularize Helm Charts domestic use, and help domestic developers through cloud native way to package and distribute their own applications to better means of wave cloud native, to make their software to play the greatest energy in the cloud era, Ali cloud cloud hosted the first native application development contest, after 42 days, the final selection of 33 Helm Charts obtain choice Award, a Helm Charts obtain jury's choice Award. All submissions Chart will go through rigorous testing and evaluation of judges.
Jury's Choice Award
✅ winners: etcd-the Manage
✅ ID of GitHub: shiguanghuxian
etcd the Manage-Go is a work written etcd management tool, with a friendly interface (similar to Ali cloud background), key management as easy as managing the local file. Rights Management supports simple distinction between read-only and read-write permissions.
✅ Jury Comments
etcd-manage is a simple etcd management tool that provides a nice visual interface, originality good, practical, close to the original concept of community cloud.
On the other hand, can be seen on the user experience to do also in place for the dependent database provides automatic installation and import external databases both options, the document also wrote more comprehensive.
Choice Award
After comprehensive consideration of several judges from the technical point of view and practical point of view, there are 33 works final harvest "the most popular award."
Data As at 10:00 on September 2
The words of the contestants
✅ winners: Redis-operator
✅ of GitHub ID: SataQiu
Native cloud is the future! Very pleased to participate in this contest cloud native applications, thanks to the patience guidance of the judges, so I gained a deep native understanding of the cloud, but also hope to organize similar competitions and activities, I am very happy to participate!
✅ winners: ETCD-the Manage
✅ ID of GitHub: shiguanghuxian
limited language skills, hoping to App Hub China Station provides convenient application release and deployment capabilities of middleware services for more companies and developers, such services as K8s Helm popular prospect of deployment and development patterns will certainly be very good.
The first entry overtime to get their own application version 2.0, the goal is to make everyone a utility that never knew Helm to learn packaged applications, learned a lot, the future will develop some applications, the other hoping to develop some means of Helm convenient application deployment tool.
✅ winners: NVIDIA-GPU-Exporter
✅ ID of GitHub: wikiios
App Hub need more practical Helm, cloud-native applications is an irresistible trend!
✅ winners: Hugo
✅ ID of GitHub: sunny0826
To participate in this contest cloud native applications, not only makes the usual master Helm to display their skills while gaining a lot to enhance exchanges with other contestants, find a lot of interesting charts, benefited. App Hub hope continue to develop in the near future on K8s cloud cluster deployment native applications can be like using yum install on CentOS convenient!
......
How to make your own Helm Charts
We usually will often deal with in their daily lives on a different platform with a variety of applications, such as downloaded from Apple's App Store in Taobao, High German, Alipay and other applications, or installed on the PC side of the Word, Photoshop , Steam. These applications on various platforms, for users, most of them only need to click the installation can be used.
However, in the cloud (Kubernetes), the deployment of an application is often not so simple. If you want to deploy an application to the cloud, you must first prepare the environment it needs, Docker packaged into a mirror. And then deploy the image on the file (Deployment), configure the service (Service), required for the application of account (ServiceAccount) and authority (Role), namespace (Namespace), key information (Secret), durable storage ( PersistentVolumes) and other resources. Is preparing a series of YAML configuration files related to each other, they will be deployed on Kubernetes cluster.
But even if the application developer can put these Docker image stored in public warehouses, and deploy the required resources YAML file to the user, the user still needs its own resources to find these files and put them one by one to deploy. If the user wants to modify the default resources provided by the developer, such as using more copies (Replicas) or modify the service port (Port), he needs to check it yourself should modify the areas in which these resource files, not to mention the version changes how much trouble and maintenance will give developers and users caused. Seen most primitive Kubernetes application form is not convenient.
Helm 与 Helm Chart
In this environment, there is a series of application-based Kubernetes package management tool turned out. And today's hero Helm, which is one of the most popular choice.
Helm Chart developer in accordance with the format required by the application resource file will wrap up by the template of (Templating) the way some variable fields (such as exposure to which port we mentioned before, how many copies) exposed to the user, Finally, the packaged application package, that is, Helm Chart, centralized repository for users to browse downloaded in a unified repository.
From the user perspective, users need only a simple command line to complete the application installation, uninstallation and upgrade. For state after installation, can also helm list be queried or native kubectl.
$ helm install redis stable/redis
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
redis-master-0 1/1 Running 0 63s
redis-slave-0-0 1/1 Running 0 63s
redis-slave-1-0 1/1 Running 0 13s
$ helm delete redisCreative Helm Chart
So standing on the developer's point of view, we should be how to create a Helm application package it?
Ready to work
First, we need to prepare for the deployment of a mirror. This image can be a Java program, a Python script, or even an empty linux Mirror ran a few commands.
Here we use a simple basis of golang. The service by reading the environment variable USERNAME to get the name defined by the user, and then listen on port 80. For any HTTP request and returns Hello ${USERNAME}. For example, if you set USERNAME=world(default scene), the service will return Hello world.
Then we use the mirror to package. Firstly Golang code is compiled, then the compiled programs based on the alpine mirror, to reduce the volume of the mirror.
After Docker build a good image, we upload the image to the warehouse, such as Docker Hub or mirrored Ali cloud container warehouse. After the preparatory work done, we can begin to create the Helm Chart.
He began writing
Run helm create my-hello-world, get a blank chart helm automatically generated. The chart in the name my-hello-world. It should be noted, Chart inside my-hello-world needs and generate the name of the folder the same name Chart. If you modify my-hello-world, you need to do the same changes. Now, we see Chart folder directory as follows:
my-hello-world
├── charts
├── Chart.yaml
├── templates
│ ├── deployment.yaml
│ ├── _helpers.tpl
│ ├── ingress.yaml
│ ├── NOTES.txt
│ └── service.yaml
└── values.yaml
In Chart.yaml file in the root directory, declares the basic information about the current Chart's name, version, etc. This information will be placed in the warehouse after the Chart for users to browse and search. For example, we can put into the Description Chart "My first hello world helm chart" . There are now two versions in Chart.yaml in related fields, indicating which version is the version of the Chart, which is our version of the application package; and appVersion specified application version is actually used inside.
In the templates folder and storing the YAML files needed to use various types of application deployment, such as Deployment and Service. In our current application, we just need a deployment, and some applications may contain different components, requiring multiple deployments, then we can put deploymentA, deploymentB and other templates in the folder. Similarly, if we need to configure serviceaccount, secret, volumes, etc., you can also add the appropriate configuration files inside.
apiVersion: apps/v1beta2
kind: Deployment
metadata:
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.pullPolicy }}
env:
- name: USERNAME
value: {{ .Values.Username }}
......
Helm Chart for packaged applications, not only will integrate Deployment and Service as well as other resources. We see deployment.yaml and service.yaml files are placed in the templates / folder, compared to Kubernetes native configuration, a lot more can be used to render the injection field. For example, in deployment.yaml of spec.replicas using that .Values.replicaCount instead of a static value Kubernetes itself. This application is used to control the number on Kubernetes should run a copy of the field, you can have different values in different application deployment environment, and this value is injected by the Values offer.
replicaCount: 1
image:
repository: somefive/hello-world
pullPolicy: IfNotPresent
nameOverride: ""
fullnameOverride: ""
service:
type: ClusterIP
port: 80
......
Username: AppHub
In the root directory we see a values.yaml file that provides default parameters are applied during installation. In default Values , we see replicaCount: 1 Note Only one copy of the application by default deployment status.
In order to use the mirror to deploy our applications, we see deployment.yaml in in spec.template.spec.containers years, image and imagePullPolicy have used Values values.
Wherein the image field consists of .Values.image.repository and .Chart.AppVersion consisting of. See here, students should know that we need to change the field: one is located within values.yaml the image.repositoryother is located in the Chart.yaml AppVersion. We need them with us to deploy applications docker mirror match up. Here we values.yaml in the image.repository set to somefive/hello-worldput Chart.yaml in the AppVersionset 1.0.0 can be.
Similarly, we can see within service.yaml we want to deploy the service, which also values.yaml in the main configuration. The service will be generated by default port 80 exposed to the interior Kubernetes cluster. We do not need this part to be modified.
Since the hello-world service deployment will be read from the environment variable USERNAME environment variables, we will join this configuration 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 is loaded from values.yaml the Username field, so appropriate, we also add values.yaml in Username: AppHub. Now, our application will read the Username from values.yaml put it in the environment variable mirrored started.
Check package
After preparing our application, we can use Helm lint to make a rough check of Chart There is no grammatical errors anything. If there is no problem, we can use the command helm package for our folders Chart packaged, after packing we can get a my-hello-world-0.1.0.tgz application package. This is the application we've done a.
$ helm lint --strict my-hello-world
1 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 it just do a good job application package, and then look at the state run by kubectl the pod. We can pod port mapping to the local port by the port-forward command, this time we will be able to access the deployed applications by visiting localhost up.
$ helm install my-hello-world-chart-test my-hello-world-0.1.0.tgz
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
my-hello-world-chart-test-65d6c7b4b6-ptk4x-0 1/1 Running 0 4m3s
$ kubectl port-forward my-hello-world-chart-test-65d6c7b4b6-ptk4x 8080:80
$ curl localhost:8080
Hello AppHubArgument overloading
Some students may be wondering, though the information we application developers to configurable exposure of values.yaml in, how do you want to modify the user application using it? The answer is simple, users only need to set parameters to set the parameters you want to cover during the install.
Application developers in Chart configuration values in just provides a default installation parameters, the user can also specify your own configuration at installation time. Similarly, if a user can use alternative install upgrade command to achieve change in the original configuration of the deployed applications.
$ 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.yamlModify message
We note that after installing the Chart command operation, the output screen will appear:
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:80
Here is a comment by the Chart of the templates/NOTES.txt offer. We note that in the original NOTES, written "app={{ template "my-hello-world.name" . }},release={{ .Release.Name }}" configuration and written in our deployment.yaml not the same. We can change it "app.kubernetes.io/name={{ template "my-hello-world.name" . }},app.kubernetes.io/instance={{ .Release.Name }}", will values.yaml is version updated to 0.1.1. Then repackage Chart (run helm package). After getting the new my-hello-world-0.1.1.tgz, upgrade existing Chart (run helm upgrade my-hello-world-chart-test2 my-hello-world-0.1.1.tgz --set Username="New Chart"), you can see NOTES update after the the.
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:80Application Sharing
So how to complete the application and make other people share it? Helm official launch of the ChartMuseum provides a method for constructing Chart warehouse, with which you can create your own Chart warehouse. However, self-maintaining a warehouse in itself no small cost, but also for the user if every developer is their own warehouse, he needs to have the required application to join their corresponding warehouse to retrieve the list, is not conducive to the spread of applications and sharing.
Open Cloud native application centers Cloud Native App Hub, synchronize the various applications, while also providing channels for developers to upload applications.
In our native open cloud application center, the application from the two channels. On the one hand, we regularly synchronize Chart resources from a number of well-known foreign Helm warehouse, in the process of synchronization, the mirrored interior part of Docker Chart will be used to synchronize the replacement (for example gcr.io or quay.io mirror image), the convenience of users access uses; on the other hand, we Helm as the official library on accepting developers to submit their applications in the form of Pull Request. Applications submitted successfully synchronized to the cloud native application center in the short term, and other official application shows together for other users.
I hope you participate, so open cloud application center richer native, benefit more people!
About the author :
Yin of Tsinghua University and Carnegie Mellon University computer science graduate student at Ali cloud platform container internship, primarily involved in container services ACK cloudy cloud technology and native application development.
Fanger Wei code scanning to add a small assistant, with 8000 native cloud enthusiasts discuss technology trends, advanced combat!
Into the group cipher: Company - Position - City