Overview

Background information

Working mechanism

The working mechanism of a custom container is the same as that of a custom runtime. Before Function Compute initializes a runtime instance for a function, Function Compute assumes the service role of the function to obtain a temporary username and password to pull an image. After the image is pulled, Function Compute starts an 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 function
• HTTP function

Configuration requirements on an HTTP server

• Services that are started in a custom container must listen on 0.0.0.0:CAPort or *:CAPort. If you configure the services to listen on 127.0.0.1:CAPort, 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 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. The following sample code provides a configuration 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 timeout

• The HTTP server must complete the startup within 120 seconds.

Common request headers in Function Compute

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.

Function log formats

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:

• During image pulling, we recommend that you use a virtual private cloud (VPC) endpoint in the same region as Function Compute, such as registry-vpc.cn-hangzhou.aliyuncs.com/fc-demo/helloworld:v1beta1. This method provides the lowest latency and highest stability.
• To minimize the size of images, you can build custom images based on minimized images such as Alpine or Ubuntu. You can retain only necessary dependencies in an image and remove non-essential documents, data, and files.
• You can use container images together with provisioned instances. For more information, see Configure provisioned instances and auto scaling rules.
• In cases where your function is thread-safe and you have abundant resources, you can use an instance to concurrently process multiple requests to avoid unnecessary cold starts and reduce costs.
• After a function is created or updated, Function Compute enables the image startup acceleration feature by default. 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.

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 an instance configured with 1,024 MB of memory spends 10 seconds pulling an image, the resource usage for this pull is 10 GB-s.

Some container images are cached. Therefore, some cold starts may use cached images and you will not be charged for pulling these images.

Limits

• Image startup acceleration

  After a function is created or updated, you must wait until the accelerated image is available before you call a function in the Function Compute console.

• Image repository

  You can pull images from the image repositories of Container Registry Enterprise Edition and Personal Edition. For more information, see What is Container Registry?.

  If you want to use a container image in Container Registry Enterprise Edition to create a function, submit a ticket or join the DingTalk group for Function Compute to contact the Function Compute technical support to activate related services.

• Image access

  You can read images from public image repositories across accounts and regions only in Container Registry Personal Edition. In Container Registry Enterprise Edition, 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 UID of run-as-user is that of the root user. If you specify a user in Dockerfile, the specified user runs the container image.

• Storage limit of the writable layer in a container
  Data that is generated by a container cannot exceed 512 MB, excluding data in the read-only layer.

  Note 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 store this data, you can integrate Function Compute with Apsara File Storage NAS. For more information, see Configure a NAS file system. You can also use other storage services to store your data, such as Object Storage Service (OSS) or Tablestore.