This topic describes custom container runtime, including its background, limits, operation, HTTP server configuration, log format, cold start optimization, and billing.

Background

In the cloud-native age, container images have become a standard tool for software deployment and development. Custom container runtime offers developers a simpler experience and makes development and delivery more efficient. Developers can deliver their functions as container images and interact over HTTP with Function Compute. Custom container runtime simplifies the following scenarios:
  • You can perform low-cost migrations and maintain consistency between development and production environments without modifying code or recompiling binary and shared objects (*.so).
  • Compressed images can be up to 1 GB in size, allowing you to package code and dependencies together for easier distribution and deployment.
  • Container images are natively stored in a cache hierarchy, which improves the efficiency of uploading and pulling code.
  • Standard, replicable third-party libraries are available for referencing, sharing, building, code uploading, storage, and version management. This offers a rich open-source ecosystem for continuous integration (CI) and continuous delivery (CD).

How it works

Custom container runtime operates on the same basic principles as custom runtime. Before it initializes an instance, Function Compute assumes the service role of the function to obtain a temporary user name and password and pull the image. After the image is pulled, Function Compute starts your HTTP server with the specified startup command (Command) and parameters (Args). The server listens on your configured listening port, such as CAPort. The server interacts with Function Compute and processes requests by using function logic. Function Compute forwards event calls and HTTP calls to the server to trigger functions.principle

HTTP server configuration

  • Configure the HTTP server to listen on all local IP addresses (0.0.0.0) and the specified port. Read and use the FC_SERVER_PORT environment variable to set the port. The default value is 9000.
  • Configure connection keep-alive on the HTTP server.
  • Set the request timeout to 15 minutes or greater.
  • Ensure that the HTTP server can start up within 25 seconds.

Function log format

Custom container runtime uses the same log format as custom runtime. For more information, see Log format.

Best practices for cold start optimization

The basic environment for container images brings a larger download than a code package, and the downloaded content takes longer to decompress. We recommend the following best practices to improve the cold start experience:

  • To ensure sufficient bandwidth and stability for internal network transmissions, you can use the registry-vpc.Endpoint address for container images. An example address is registry-vpc.cn-hangzhou.aliyuncs.com/fc-demo/helloworld:v1beta1.
  • For optimal latency and stability when images are pulled, we recommend that you use a VPC endpoint in the same region as Alibaba Cloud Container Registry (ACR) and Function Compute.
  • To minimize images, you can include only necessary dependencies and code in your images. Unnecessary documents, data, or other files may cause delays.
  • You can use container images with reserved instances. For more information, see Reserved instances.

Billing rules

Custom container runtime uses the same billing items as other runtime services. For more information, see Billing. The run time item under image resource usage is the period from when the repository initiates the image pull to when the pull is finished. For example, if an instance with 1,024 MB of memory takes 10 seconds to pull an image, the resource usage for this pull is 10 MBCU-second. Container images are cached for some time. A cold start does not necessarily incur image pull fees.

Limits

  • Image size:
    • If the memory to run a function is less than 1 GB, the size of the image before decompression cannot exceed 256 MB.
    • If the memory to run a function is 1 GB or greater, the size of the image before decompression cannot exceed 1,024 MB.
  • Image repository: Only default instance images in Container Registry are supported.
  • Image access: You can read images only from private image repositories in the same region and under the same account.
  • Read and write permissions of files in containers: The UID of run-as-user is randomly selected from the range of 10000 to 10999. The /tmp directory in containers is writable by default. Read and write permissions for other directories are controlled by the image file system. If a running UID does not have read and write access to a file, you can modify the permissions of the UID in Dockerfile.
  • The writable layer of a container is 512 MB. The data generated by a container cannot exceed this size.
    Note The data stored in the writable layer of a container does not persist. When the container is deleted, this data is also deleted. If persistent storage is required, you can use Function Compute to mount an Apsara File Storage NAS file system. For more information, see Configure NAS. You can also use other shared storage services, such as Object Storage Service or Tablestore.