This topic describes the background information and working mechanism of custom containers. This topic also describes the usage limits on custom containers and the requirements on 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 development and delivery efficiency, Function Compute allows developers to use custom containers as the runtime environments of functions. You can use container images as deliverables for functions. Custom containers 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 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 uploading and pulling code.
  • 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).
  • HTTP can be used to interact with Function Compute.
  • Images that do not require interaction can be run.

Working mechanism

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 the image by using the specified startup command and the Args parameter.

Custom container functions include functions in web server mode and functions in non-web server mode.

Web server mode

To configure the web server mode, you can leave the webServerMode parameter empty or set it to true. In web server mode, 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 from 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 functionbuhuo1containercustom1
  • HTTP functionnuhuo2customcintainer2

Non-web server mode

To configure the non-web server mode, you can set the webServerMode parameter to false. In non-web server mode, an HTTP server does not need to be defined in the deliverables of a container image. After the container image is started, it must run and exit within the function timeout period. In non-web server mode, you can trigger functions by using only event triggers but not HTTP triggers. This is because no port is used for interaction. Events are passed into the container in the form of environment variables. The following figure shows how an event function works:

Event functioncustom-container3
Important If you need to use the non-web server mode of a custom container function, Contact Us to add you to the whitelist.

Usage limits

Image size

Container Registry Enterprise Edition (Basic Edition) and Container Registry Personal Edition of GPU-based instances support up to 10 GB of uncompressed images. Container Registry Enterprise Edition (Basic Edition) and Container Registry Personal Edition of elastic instances support up to 3 GB of uncompressed images. Container Registry Enterprise Edition (Standard Edition) and Container Registry Enterprise Edition (Advanced Edition) of all instances support up to 10 GB of uncompressed images.

Image startup acceleration

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

Image repository

The images of Container Registry Enterprise Edition and Personal Edition instances can be pulled. 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 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 for the writable layer in a container

After the data in the read-only layer is excluded, data that is generated by a container cannot exceed 512 MB.
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 shared storage services, such as Object Storage Service or Tablestore.

Image architecture

Function Compute supports only the AMD64 image architecture. You must specify the image compilation platform as Linux AMD64 if you use a device that runs the ARM architecture, such as a Mac computer equipped with Apple chips, when you build images. Sample command: docker build --platform linux/amd64 -t $IMAGE_NAME .
Note After the build operation, you can run the docker inspect command to perform checks. If the returned content contains "Architecture" : "amd64", the image is built correctly.

Configuration requirements on an HTTP server

The following requirements apply only to custom container functions in web server mode:
  • 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.XX.XX: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

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.

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:

  • Use a virtual private cloud (VPC) image endpoint in the same region as Function Compute to reduce image pull latency and improve stability.
  • To minimize the sizes 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 reduce cold starts and costs. For more information, see Specify the instance concurrency.
  • After the function is created or updated, use the image startup acceleration feature that is enabled by default in Function Compute to reduce the cold start time for images. 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 overview.

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-seconds.

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

References