This topic describes the background information, working mechanism, and usage limits of the Custom Container runtime in Function Compute. This topic also describes the requirements on HTTP server configurations.
Background information
In the cloud-native era, container images are widely used in software development and deployment. To optimize developer experience and improve the efficiency of development and delivery, Function Compute provides the Custom Container runtime. Developers can use container images as the deliverables of functions. The Custom Container runtime provides the following benefits:
Migration can be performed at low costs because no code modification or binary file recompilation is required. Shared objects (*.so) are used to ensure the consistency between the development environment and the production environment.
The separation between code and dependencies is avoided, and the steps for distribution and deployment are simplified.
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. The libraries can also be used to upload code and manage versions. This provides a comprehensive open source ecosystem for continuous integration and continuous deployment (CI/CD).
The HTTP protocol can be used to interact with Function Compute.
Images that do not require interaction can be run.
Principles
Before Function Compute initializes the execution instance, it assumes the role of the service to which the function belongs, obtains the temporary username and password, and pulls an image. After the image is pulled, Function Compute starts the image by using the specified startup command and the Args parameter.
Functions in the Custom Container runtime can be in the web server mode or the non-web server mode.
Web server mode
To configure the web server mode, you can leave the webServerMode parameter empty or set it to true. In web server mode, an HTTP server must be included in the deliverables of a container image. Function Compute listens on the HTTP Server that you define by using the configured CAPort. The HTTP Server takes over all requests of Function Compute, including invocations from your 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 functions
HTTP functions
Non-web server mode
To configure the non-web server mode, you must set the webServerMode parameter to false. In non-web server mode, an HTTP server does not need to be defined in the deliverables of a container image. After the container image is started, it must run and exit within the function timeout period. In non-web server mode, you can trigger functions by using only event triggers but not HTTP triggers. This is because no port is used for interaction. Events are passed into the container in the form of environment variables. The following figure shows how the non-web server mode works:
Event functions
The non-web server mode is supported in the following regions: China (Hangzhou), China (Shanghai), China (Beijing), China (Zhangjiakou), China (Shenzhen), China (Hong Kong), Japan (Tokyo), Singapore, US (Virginia), and US (Silicon Valley).
Limits
Image size
A maximum of 10 GB of uncompressed images are supported in Container Registry Personal Edition and Container Registry Enterprise Edition (Basic Edition, Standard Edition, and Advanced Edition).
Image startup acceleration
After a function is created or updated, you must wait until the accelerated image is available before you invoke the function in the Function Compute console.
Image repository
The images of Container Registry Enterprise Edition and Personal Edition instances can be pulled. 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 files in a container
By default, the run-as-user UID of the container is the ID of the root user. In this case, UID=0. If you specify a user in the Dockerfile, the container image is run by the specified user.
Storage limit for a writable layer in a container
Except for read-only image layers, the size of the data generated by the container is limited to 512 MB or 10 GB, which is the same as the disk size in the advanced configurations of the function. For more information, see Create a function.
Data stored in the writable layer of a container is not persistent. If the container is deleted, the data is also deleted. If you need persistent storage, you can mount Apsara File Storage NAS (NAS) or Object Storage Service (OSS) to Function Compute. For more information, see Configure a NAS file system and Configure an OSS file system. You can also use another shared storage service, such as Tablestore.
Image architecture
Function Compute only supports the AMD64 image architecture. Therefore, you must specify the compilation platform of the image as Linux/Amd64 when you build the image if you use an ARM machine, such as a Mac computer equipped with Apple chips. Sample command: docker build --platform linux/amd64 -t $IMAGE_NAME .
After the build operation, you can run the docker inspect command to perform checks. If the output contains "Architecture" : "amd64", the built image is correct.
Configuration requirements on an HTTP server
The following requirements apply only to custom container functions in the web server mode:
Services that are started in a custom container runtime must listen on
0.0.0.0:CAPortor*:CAPort. If you use the127.0.0.1:CAPortport, a request times out, and the following error is returned:{ "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 is port 9000. If a custom container uses the default listening port, the listening port of its HTTP server must be port 9000. If the listening port of the custom container is port 8080, the listening port of its HTTP server must be port 8080.
You must maintain the connection between Function Compute and the HTTP server, and set the request timeout period to 15 minutes or longer. 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 timeoutThe HTTP server must be started within 120 seconds.
Common request header
The common request headers that a custom container can receive are the same as those that a custom runtime can receive. For more information, see Common request headers in Function Compute.
Log format
All logs that are printed to standard output (stdout) in a custom container are automatically collected to the specified Logstore in Log Service. For more information about how to configure the logging feature, see Configure the logging feature.
A custom container uses the same log format as a custom runtime. For more information, see Function log formats.
Best practices for cold start optimization
Compared with code packages, container images rely on the execution environment and require more time to download and unpack. To optimize cold starts, we recommend the following best practices:
Use a VPC image address in the same region as Function Compute to reduce the image pull latency and improve stability.
Minimize the size of images. You can build custom images based on minimized images such as Alpine or Ubuntu. Retain only necessary dependencies in an image and remove non-essential 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 the security of threads are guaranteed and you have abundant resources, you can use an instance to concurrently process multiple requests to reduce cold starts and costs. For more information, see Configure instance concurrency.
After you create or update a function, you can use the image startup acceleration feature, which is automatically enabled in Function Compute to reduce the duration of image startups. For more information, see Accelerate image startup for Container Registry Personal Edition and Accelerate image startup for Container Registry Enterprise Edition.
Billing
The billable items for a custom container are the same as those for other types of runtimes. For more information, see Billing overview.
The image resource usage depends on the image pull duration. This duration is the period from the time when an instance starts to pull the image from the image repository to the time when the image pull is complete. For example, if it takes 10 seconds to pull images from an instance that has 1024 MB of memory, 10 GB-seconds of resources are consumed.
Some container images are cached. Therefore, some cold starts may use cached images, and you are not charged for pulling these images.