Choosing the Right Container Image for WeChat Cloud Hosting: A Focus on Alpine

WeChat Cloud Hosting uses the currently mainstream container platform Docker and container orchestration technology Kubernetes (abbreviated as K8S) to manage your projects. Using WeChat Cloud Hosting requires mastering Docker, but you do not need to master the use of K8S. WeChat Cloud Hosting completely takes over the operation and maintenance configuration of K8S, so you do not need to worry about how K8S and container services are configured and interact with each other. You only need to operate the simple operation panel provided by WeChat Cloud Hosting to easily deploy services, greatly reducing the threshold for using container technology. When you use clients under the WeChat ecosystem (mini-programs, public accounts) to send requests to backend services deployed on WeChat Cloud Hosting, they will automatically pass through the WeChat access layer (intranet) and carry authoritative user information verified by WeChat. Non-WeChat ecosystem clients (ordinary WEB pages, APPs) sending requests to backend services deployed on WeChat Cloud Hosting will pass through the public gateway layer of WeChat Cloud Hosting (shared by all users, maintained by the WeChat Cloud Hosting team), and will be forwarded to the corresponding user service based on the domain name. WeChat Cloud Hosting provides a default public domain name and can also connect to your own registered custom domain name.

In the official templates provided by WeChat Cloud Hosting (PHP, Python, NodeJS, Golang, Java, .NET), only Java does not use the Alpine image. For specific code, see this link.

Choosing the Right Container Image for WeChat Cloud Hosting: A Focus on Alpine

Before the rise of containers, Alpine was an unknown player, perhaps because people were not very concerned about the size of the operating system itself. After all, everyone only cares about business data and documents, and the size of programs, library files, and the system itself can usually be ignored.

After container technology swept the entire software industry, people noticed a problem: container images are too large, wasting disk space, and the time to pull images is very long. Therefore, people began to seek smaller images suitable for containers. For well-known distributions (such as Ubuntu, Debian, Fedora), the image size can only be controlled below 100M by deleting certain tools (such as ifconfig and netstat). In contrast, Alpine requires no deletions, with an image size of only 5M.

Another advantage of the Alpine image is the very fast execution speed of the package management tool, providing a very smooth software installation experience. Admittedly, on traditional virtual machines, software package installation speed is not a major concern since the same package only needs to be installed once. Containers are different; you may periodically build new images or temporarily install certain debugging tools in running containers. If the installation speed of software packages is slow, it will quickly wear down our patience.

The Alpine operating system is a lightweight Linux distribution focused on security. Unlike typical Linux distributions, Alpine uses musl libc and BusyBox to reduce the system’s size and runtime resource consumption, while being much more feature-rich than BusyBox. While maintaining its slim profile, Alpine also provides its own package management tool, apk, which can be queried for package information via this link, and various software can be queried and installed directly using the apk command.

The Alpine Docker image inherits these advantages from the Alpine Linux distribution. Compared to other Docker images, its size is very small, only about 5MB (Ubuntu series images are close to 200MB), and it has a very friendly package management mechanism. The official image comes from the docker-alpine project.

When creating Docker images, use multi-stage builds for different stages of command files, ultimately copying them to BusyBox or Alpine for execution. The benefits of this approach are twofold:

  1. Keeping the image minimal; BusyBox and Alpine are the smallest operating system images.

  2. Having various Linux tools available; BusyBox itself is a collection of Linux tools.

  3. It is recommended to use Alpine and other official packages for build stages. The main reason is that this image is slightly larger than BusyBox but smaller than other system images. Some may ask why not use BusyBox; the reason is that BusyBox lacks a package management tool, which brings a lot of inconvenience. This is also the main difference between BusyBox and Alpine.

Now let’s take a look at the Alpine image situation for .NET and Java:

Currently, there is no official stable OpenJDK 11 build for Alpine Java, although AdoptOpenJDK has official support for Alpine for Java 11: this link.

Alpine was added in response to customer requests for a more secure container distribution. Since .NET Core 2.0, .NET has had an official stable .NET build for Alpine, providing very good support for Alpine because it contains fewer software packages, and due to its reduced surface area, it seems to have a more limited CVE exposure: this link.

Related articles:

Leave a Comment

×