This topic describes the background information, principles, and limits of a Custom Container runtime in Function Compute. This topic 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 developer experience and improve the efficiency of development and delivery, Function Compute provides Custom Container runtimes. Developers can use container images as deliverables of functions. Custom Container runtimes provide 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 development environments and production environments.
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 an execution instance, it assumes the role configured for the function, 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.
An HTTP server must be included in the deliverables of 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 requests made through API calls and HTTP calls. Before you develop the interaction logic of a function, you must confirm whether the function is invoked by using API calls or HTTP requests.
Invocation by API calls
Invocation by HTTP requests
Limits
Image size
A maximum of 10 GB of uncompressed Container Registry Personal Edition images are supported.
Image repository
You can pull images from instances of Alibaba Cloud Container Registry 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 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 a 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 an File Storage NAS (NAS) or Object Storage Service (OSS) file system to your function in 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, 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 check the architecture. 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 timeout error occurs, 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 runtime is port 9000. If a Custom Container runtime uses the default listening port, the listening port of its HTTP server must also be port 9000. If the listening port of a Custom Container runtime is port 8080, the listening port of its HTTP server must also 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. Examples:
// 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 in a Custom Container runtime are the same as those in a custom runtime. For more information, see Common request headers of 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 the logging feature.
Formats of logs of Custom Container runtimes are the same as the log formats of custom runtimes. 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 virtual private cloud (VPC) image address in the same region as Function Compute to reduce the image pull latency and improve stability.
Minimize the sizes of your 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.
If the security of threads is guaranteed and you have sufficient resources, you can use an instance to concurrently process multiple requests to reduce cold starts and costs. For more information, see Configure instance concurrency.
Billing description
The billable items for a Custom Container function are the same as 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 an image by a function instance that is configured with 1,024 MB of memory, 10 GB-seconds of resources are consumed.
Container images are cached within a specific period of time. Therefore, each cold start does not necessarily incur fees for image pulling.