Overview

This topic describes the background information, principles, and limits of a Custom Container runtime in Function Compute. It also describes the requirements for HTTP server configurations.

Background

In the cloud-native era, container images are widely used in software development and deployment. To optimize the developer experience and improve the efficiency of development and delivery, Function Compute provides Custom Container runtimes, allowing developers to use container images as deliverables of functions. Custom Container runtimes provide the following benefits:

Migration can be performed at low cost because it does not require any code modifications or recompilation of binary files. Shared objects (*.so) are used to ensure the consistency between development and production environments.
The separation between code and dependencies is avoided, which simplifies distribution and deployment.
Container images are natively stored in a cache hierarchy. This improves the efficiency of code uploading and pulling.
Standard, replicable third-party libraries can be used to reference, share, build, and store resources, as well as to facilitate code uploading and version management. This creates a comprehensive open source ecosystem for continuous integration and continuous deployment (CI/CD).
HTTP requests can be used to interact with Function Compute.
Images that operate without user interaction can be executed.

Principles

Before Function Compute initializes an instance, it assumes the service role configured for the function, obtains the temporary username and password, and pulls the image. After the image is pulled, Function Compute starts the image by using the specified startup command and the args parameter.

An HTTP server must be included in a container image. Function Compute listens on your HTTP server by using the configured CAPort. The HTTP server takes over all requests to Function Compute, including invocations of both event functions and HTTP functions. Before you develop the interaction logic of a function, you must determine whether the function is an event function or an HTTP function. The following figures show how an event function and an HTTP function work.

Event function
HTTP function

Limits

Image size

Container Registry Personal Edition and the Basic, Standard, and Advanced editions of Container Registry Enterprise Edition support up to 10 GB of uncompressed images.

Image startup acceleration

After a function is created or updated, you must wait until the accelerated image is available before you can invoke the function in the Function Compute console.

Image repository

You can pull images from instances of Container Registry Enterprise Edition and Personal Edition. For more information, see What is Container Registry?

Image access

You can read images from public image repositories across accounts and regions only in Container Registry Personal Edition instances. In Container Registry Enterprise Edition instances, you can read images only from private image repositories in the same region and within the same account.

Read and write permissions on container files

By default, the run-as-user UID of a container is the ID of the root user, which is set to 0. If you specify a user in the Dockerfile, the container image is run by that specified user.

Data size of writable layers in a container

Except for read-only image layers, the size of the data generated by a container is limited to either 512 MB or 10 GB, depending on the disk size configured for the function in the advanced settings. For more information, see Create a function.

Note

Data stored in the writable layers of a container does not persist. When the container is deleted, the data is also deleted. If you want persistent storage, you can mount a File Storage NAS (NAS) or Object Storage Service (OSS) file system to Function Compute. For more information, see Configure a NAS file system and Configure an OSS file system. You can also use other shared storage services, such as Tablestore.

Image architecture

Function Compute supports only the AMD64 image architecture. Therefore, if you use a device running the ARM architecture, such as a Mac computer equipped with Apple chips, you must specify the compilation platform of the image as linux/amd64 when you build the image. The following is a sample command: docker build --platform linux/amd64 -t $IMAGE_NAME .

Note

After the build operation is complete, you can run the docker inspect command to check the architecture. If the output contains "Architecture" : "amd64", the image you built has the correct architecture.

Configuration requirements for an HTTP server

Services that are started in a Custom Container runtime must listen on 0.0.0.0:CAPort or *:CAPort. If you use the 127.0.0.1:CAPort port, a timeout error occurs. The following is a sample error message:
```
{
"ErrorCode":"FunctionNotStarted",
"ErrorMessage":"TheCA'shttpservercannotbestarted:ContainerStartDuration:25000000000.PingCAfaileddueto:dialtcp21.0.XX.XX:9000:getsockopt:connectionrefusedLogs:2019-11-29T09:53:30.859837462ZListeningonport9000"
}
```
The default listening port (CAPort) of a Custom Container runtime is port 9000. If a Custom Container runtime uses this default listening port, the listening port of the HTTP server in the container image must also be port 9000. If the Custom Container runtime uses port 8080 as its listening port, then the listening port of the HTTP server must be port 8080.

You must enable the keep-alive feature for connections and set the request timeout period on the server side to 15 minutes or longer. The following code snippet provides an example:

// In this example, the Express framework for Node.js is used.   
var server = app.listen(PORT, HOST);
server.timeout = 0; // never timeout
server.keepAliveTimeout = 0; // keepalive, never timeout

The HTTP server must complete the startup within 120 seconds.

Common request headers

The common request headers in a Custom Container runtime are the same as those in a custom runtime. For more information, see Common request headers in Function Compute.

Log formats

Logs that are printed to standard output (stdout) in a Custom Container runtime are automatically collected to the specified Logstore in Simple Log Service. For more information, see Configure logging.

A Custom Container runtime uses the same log formats as a custom runtime. For more information, see Function log formats.

Best practices for cold start mitigation

The inherent complexity and larger size of container images, due to their inclusion of necessary runtime environments, typically lead to longer download and unpack times—often referred to as cold starts—compared to simpler code packages. To mitigate cold starts, we recommend that you refer to the following best practices:

Use a Virtual Private Cloud (VPC) image address in the same region as Function Compute to reduce the image pull latency and improve stability.
Minimize the size of your images. You can build custom images based on minimized images such as Alpine or Ubuntu. Retain only necessary dependencies in an image, removing unnecessary documents, data, and files.
Use container images together with provisioned instances. For more information, see Configure provisioned instances and auto scaling rules.
In cases where your function is thread-safe and you have sufficient resources, you can configure instance concurrency to allow an instance to process multiple requests at a time. This approach reduces cold starts and saves costs. For more information, see Configure instance concurrency.
After you create or update a function, the image startup acceleration feature, which is enabled by default in Function Compute, automatically reduces cold start duration. For more information, see Accelerate startup of images for Container Registry Personal Edition and Accelerate image startup for Container Registry Enterprise Edition.

Billing

The billable items for a Custom Container function are the same as those for functions run in other types of runtimes. For more information, see Billing overview.

The image pull duration, which is from the time when the pull is started to the time when the pull is finished, is used as the basis for calculating fees for image resource usage. For example, if it takes 10 seconds to pull images for an instance that has 1 GB of memory, the total resource consumption is 10 GB-seconds.

Container images are cached for a period of time. When cached images are used, there is no image pull fee.