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 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 custom container runtimes. 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 an 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.
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. This HTTP server takes over all requests from Function Compute, including the invocation requests for 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
Limits
Image size
Container Registry Personal Edition supports up to 10 GB of uncompressed images.
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 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 on 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 want to persistently store the data, you can mount an Apsara File Storage NAS (NAS) file system or an Object Storage Service (OSS) bucket on 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 Linux/Amd64 as the compilation platform of an image when you build the image on an ARM machine, such as a Mac computer that uses Apple chips. Sample command: docker build --platform linux/amd64 -t $IMAGE_NAME .
After the image is built, you can run the docker inspect command to check the image. If the output contains "Architecture" : "amd64", the built image is valid.
Requirements for HTTP server configurations
The following requirements apply only to custom container functions in 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 headers
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 of 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 Simple Log Service. For more information, 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 for download and decompression. 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.
If the security of threads is ensured and you have sufficient resources, you can use an instance to concurrently process multiple requests to reduce cold starts and costs.
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 the pull is started to the time when the pull is finished. For example, if it takes 10 seconds to pull an image from an instance that has 1,024 MB of memory, 10 GB of resources are consumed per second.
Container images are cached for a period of time. Therefore, some cold starts may use cached images. In this case, no image pull fee occurs.