This topic describes custom container runtime, including its background, concepts, HTTP server configurations, log formats, cold start optimization, billing, and limits.

Background information

In the cloud native era, container images have become a standard tool for software deployment and development. Function Compute provides a custom container runtime to improve developer experience and the development and delivery efficiency. Developers can deliver their functions as container images and interact with Function Compute over HTTP. The custom container runtime simplifies the following scenarios:
  • You can perform cost-efficient migration 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. This allows you to package code and dependencies together for easier distribution and deployment.
  • Container images are natively stored in a cache hierarchy. This improves the efficiency of uploading and pulling code.
  • Standard, replicable third-party libraries can be used for referencing, sharing, building, code uploading, storage, and version management. This offers a comprehensive open source ecosystem for CI/CD.

How it works

Custom container runtime operates on the same basic principles as custom runtime. Before Function Compute initializes an instance, Function Compute assumes the service role of the function to obtain a temporary username and password and pull the image. After the image is pulled, Function Compute starts your HTTP server by using the specified startup command (Command), parameters (Args), and CAPort (port 9000 by default). Then, the HTTP server takes over all requests from Function Compute, including the invocations of event and HTTP functions.

Before you develop the 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 functioneventfunction
  • HTTP functionhttpfunction

HTTP server configurations

  • Services started in a custom container runtime must listen on the 0.0.0.0:CAPort or *:CAPort port. If you use the 127.0.0.1:CAPort port, the request times out and the following error is returned:
    {
      "ErrorCode":"FunctionNotStarted",
      "ErrorMessage":"The CA's http server cannot be started:ContainerStartDuration:25000000000. Ping CA failed due to: dial tcp 21.0.5.7:9000: getsockopt: connection refused Logs : 2019-11-29T09:53:30.859837462Z Listening on port 9000"
    }

    The default CAPort used by custom container runtime is 9000. If a custom container runtime uses the default CAPort, the HTTP server on which the custom container runtime is deployed must listen on the default CAPort, which is 9000. If a custom container runtime uses port 8080 as the listener port, the HTTP server on which the custom container runtime is deployed must listen on port 8080.

  • Set Connection to Keep-Alive and the request timeout period to 15 minutes or longer. The following code provides an example on how to set Connection and the request timeout period:
    // The express framework for Node.js is used in the example.   
    
    var server = app.listen(PORT, HOST);
    server.timeout = 0; // never timeout
    server.keepAliveTimeout = 0; // keepalive, never timeout
  • The HTTP server must start up within 30 seconds.

Function log formats (Optional)

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

Best practices for cold start optimization

Compared with code packages, the basic environment for container images takes additional time to download and decompress data. To improve the cold start experience, we recommend the following best practices:

  • 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. Example: registry-vpc.cn-hangzhou.aliyuncs.com/fc-demo/helloworld:v1beta1.
  • To minimize the size of images, you can build custom images based on minimized images such as Alpine or Ubuntu. You can include only necessary dependencies in the image and exclude unnecessary documents, data, and files.
  • You can use container images together with reserved instances. For more information, see Overview.
  • When resources are sufficient and threads are secure, you can use an instance to concurrently process multiple requests to avoid unnecessary cold starts and reduce costs.

Billing method

The billable items of custom container runtime are the same as those of other runtime services. For more information, see Billing. The execution duration of an image resource is the period from the time when the instance starts to pull the image from the repository to the time when the image is pulled. For example, if an instance configured with 1,024 MB of memory takes 10 seconds to pull an image, the resource usage for this pull is 10 GB-s. Container images are cached for a specific period. Therefore, a cold start does not necessarily incur image pull fees.

Limits

  • Image size
    • If the memory used to run a function is less than 1 GB, the size of the image before decompression cannot exceed 256 MB.
    • If the memory used to run a function is 1 GB or greater, the size of the image before decompression cannot exceed 1,024 MB.
  • Image repository

    Only the image repositories of Container Registry Default Instance Edition 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 on container files

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

  • Storage space of the writable layers of a container
    The data that is generated by the writable layers of a container cannot exceed 512 MB.
    Note The data stored in the writable layer of a container does not persist. When the container is deleted, this data is also deleted. To persist data in the writable layer of a container, you can use Function Compute to mount an Apsara File Storage NAS file system. For more information, see Configure a NAS file system. You can also use other storage services to persist data, such as Object Storage Service or Tablestore.