15 Starting from 0 to Create Cloud Native Applications Morida #

云原生应用是一种以云计算为基础，具有高度弹性、可扩展、高可用性的应用程序。本篇文章将向您介绍如何从零开始创建云原生应用。

为了创建云原生应用，首先需要确保您拥有一个适合部署应用的云计算平台。常见的云计算平台包括亚马逊 AWS、微软 Azure 和谷歌 Cloud Platform。选择一个适合您需求的平台，并在上面创建一个虚拟机或容器，并安装所需的操作系统和运行时环境。

接下来，您需要选择一种适合云原生应用开发的技术栈。常见的云原生开发技术包括容器技术（如 Docker 和 Kubernetes）、微服务架构和无服务器计算。根据您的需求和技术背景，选择适合您的技术栈。

在进行应用开发之前，需要进行应用架构设计。云原生应用应该采用松耦合、水平扩展、容错和自恢复的设计原则。确保您的应用可以在集群中水平扩展，并采用容错技术以保证应用的高可用性。

应用开发阶段需要使用相应的开发工具和编程语言。根据您的技术栈选择合适的开发工具，如 IntelliJ IDEA 或 Visual Studio。同时，根据您的编程语言选择相应的开发语言，如 Java、Go、Python 等。

在应用开发完成后，需要进行部署和运维。根据您的技术栈选择相应的部署工具，如 Docker、Kubernetes 等。确保您的应用可以自动水平扩展和自动恢复，并监控应用的运行状况。

最后，在部署应用之前，确保进行充分的测试，并进行负载测试和容量规划。这样可以确保您的应用可以在不同的负载和条件下正常运行。

通过以上步骤，您可以从零开始创作云原生应用。请记住，云原生应用的开发和运维是一个持续的过程，您需要不断学习和探索新的技术和最佳实践，以确保您的应用始终处于最佳状态。

1. What is a Cloud-Native Application? #

First, let’s think about a question: what is a cloud-native application?

In our daily lives, we interact with various applications. Sometimes we use Taobao for shopping on mobile devices, use Amap for navigation, edit documents with Word on PCs, or edit photos with Photoshop. Most of these applications on different platforms can be used by simply clicking install. So what does an application look like on the cloud, or specifically, on Kubernetes, which is our cloud platform today?

Imagine, what do we need to do to deploy an application on the cloud?

First, we need to prepare the environment it requires, package it into a Docker image, and put this image into a deployment. We need to deploy resources such as accounts, permissions, namespaces, secret information, and persistent storage for the service and application. In short, these resources are Kubernetes resources, and they need to be configured on the Kubernetes platform using a bunch of YAML files.

Although the developers of the application can store these images in a public repository and provide users with the yaml resource files required for deployment, 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 replicas or modifying service ports, they need to figure out where to make the corresponding modifications in these resource files. Moreover, version updates and maintenance can also be troublesome for both developers and users. Therefore, it can be seen that the original form of Kubernetes applications is not very convenient.

2. Helm and Helm Chart #

What is Helm? #

Our protagonist today, Helm, was born in such an environment. Developers install Helm Charts in a format that packages all the resource files required by the application. Using a templating method, some variable fields, such as the port to expose and the number of replicas to use, are exposed to users. Finally, the packaged application, which is what we call a Helm Chart, is centrally stored in a unified repository for users to browse and download.

For users, a simple Helm command can be used to install, uninstall, and upgrade applications. After installation, we can use kubectl to view the running status of the pods. It is worth noting that the command we used is for Helm v3, which differs from the more mature Helm v2. We recommend using this latest v3 version for learning and exploring.

How to create a Helm application #

From a developer’s perspective, how should we create a Helm application? First, we need an image to deploy, which can be a Java program, a Python script, or even an empty Linux image in which we run a few commands.

Write a Golang program #

As shown in the above graph, here we use Golang to write a very simple Hello World HTTP server and package it using Docker. A Golang program typically looks like this, including reading the pod and username parameters from the environment variables, extracting an HTTP server on the specified port, and returning the corresponding response.

Build the Docker image #

The Dockerfile used for packaging is shown in this graph. Here, we first compile the Golang code and then put the compiled program into an image at 03:53 to reduce the size. The two environment variables mentioned earlier are only set for the port in this file. The username will be reported to the user as an application parameter in the future, so we don’t set it here. After building the Docker image, we upload it to a repository such as Docker Helm or Alibaba Cloud Container Registry.

Create a blank application #

After completing the preparations, we can now begin the highlight of today, building the Helm Chart. First, we run the helm create command to create a blank application. After running the create command, you can see a series of files and folders appearing in the charts directory.

• The Chart.yaml file contains some basic information about the Helm Chart.
• The templates folder contains various Kubernetes resources required by this application.
• The values.yaml file provides a default parameter configuration.

Chart configuration #

Now let’s take a look at each of them:

In the Chart.yaml file in the root directory, the name, version, and some basic information of the current Chart are declared. This information will be available for users to browse and search after the chart is added to the repository. For example, we can change the description of the chart to “My first hello world helm chart” in this file.

In Chart.yaml, there are two fields related to versions. The version field refers to the version of the chart application package, while the appVersion field refers to the version we internally use, such as the tag we assigned to the Golang program used internally.

Template folder #

In the templates folder, various YAML files are stored for deploying applications, such as the deployment and service files we see.

Our current application only needs one deployment, but some applications may include multiple components. In such cases, multiple YAML files like deploymentA.yaml, deploymentB.yaml, etc. need to be placed in this templates folder. Sometimes we also need to configure the contents of service account secret volumes, which can also be added here.

In the templates folder, the configuration files can be simple Kubernetes.yaml files or template files. For example, in the deployment.yaml file, there are many variables enclosed in {{ }}, such as the variables starting with values or chart. These variables are obtained from the chart.yaml and values.yaml files in the root directory.

As shown in the above image, replicaCount is the number of replicas we want to deploy, and repository specifies the location of the image. We did not set the username environment variable in the Docker image build process, but it is exposed in the values.yaml file in a similar way.

When Helm installs an application, it actually renders the template files in the templates folder and fills in the required variables. Then it uses the rendered kubernetes.yaml file for deployment. In the process of creating this Helm Chart, we don’t need to worry too much about how to render because Helm handles all of these things when installing the application on the client side.

Validation and Packaging #

After preparing the application, we can use the helm lint command to perform a rough check for any syntax errors in the chart we created. If everything is fine, we can use the helm package command to package our chart files. After packaging, we will get a tar package, which is the application package we want to release.

Installation Testing #

We can use the helm install command to try installing the application package we just created. Then we can use kubectl to check the running status of the pods. Similarly, we can use the port-forward command to map the pod port to a local port, so we can access the newly deployed application using localhost.

Parameter Overrides #

Some people might wonder: as application developers, we expose all these configurable information in values.yaml. What if a user wants to modify them while using the application? The answer is quite simple. Users only need to use the set parameter during installation to override the parameters they want to modify.

Similarly, if users write their own my-values.yaml file, they can also set it during the installation to override some existing parameters. If users don’t want to install a new app but want to upgrade the existing app, they just need to replace the helm install command with the helm upgrade command.

Modifying NOTES.txt #

Observant readers may notice that the prompt message after executing the helm install command actually has some issues. Let’s take a look at the deployment.yaml file we wrote earlier. Inside it, we can see that the two labels are actually different. This prompt message is actually in the notes file under the templates folder. So, we just need to modify the corresponding information in this file.

Version Upgrade #

Next, let’s go back to the chart.yaml file and update the version field. Then we can package it again, and we can perform a version upgrade on the previously deployed application.

Application Distribution #

How should we share this completed application with others?

The Helm official solution is to use tools like ChartMuseum. With this tool, everyone can build their own chart repository. However, maintaining a chart repository can be costly. Moreover, for users, if each application developer has their own repository, the user needs to add all these repositories to their search list, which is very inconvenient and not conducive to the propagation and sharing of applications.

3. Open Cloud Native App Hub #

Source of Applications #

Our team recently launched an open Cloud Native App Hub called Cloud Native App Hub. Inside it, we have synchronized various popular applications and also provided a channel for developers to upload their own applications.

Submitting Applications #

In the open Cloud Native App Hub, applications primarily come from two channels:

• On one hand, we regularly synchronize chart resources from well-known Helm repositories abroad, and at the same time, we also replace some Docker images used internally.
• On the other hand, similar to the Helm official repository, we also accept developers to submit their applications through push requests on GitHub.

Interested students can visit our Cloud Native App Hub’s chart repository on GitHub, follow the chart creation process mentioned earlier, create your own chart, and then submit a push request.

Conclusion #

Finally, we welcome everyone to use Helm and Alibaba Cloud for developing cloud-native applications. If you have any questions or would like to have further discussions, you can scan the QR code to join our Kubernetes DingTalk technical group, and explore technology with the experts. That concludes today’s presentation. Thank you all.