Overview

How it works

When Function Compute initializes an instance, it assumes the service role configured for the function, retrieves a temporary username and password, and pulls the container image. After the image is pulled, Function Compute starts the container using the specified startup command and arguments.

Your container image must include an HTTP server. Function Compute communicates with your container through the HTTP server on the configured CAPort. The HTTP server handles all incoming requests—both event functions and HTTP functions use this same mechanism, but their interaction patterns differ.

• Event function — Function Compute wraps the event payload in an HTTP request and sends it to your HTTP server.

  

• HTTP function — HTTP requests from clients are forwarded directly to your HTTP server.

  

Limitations

Reduce cold starts

Container images are larger than standard code packages, so they typically take longer to pull and unpack. To reduce cold start latency:

• Use a Virtual Private Cloud (VPC) image address in the same region as your Function Compute function to reduce pull latency.

• Minimize image size. Build from a minimal base image such as Alpine or Ubuntu, and remove unnecessary files, documents, and dependencies.

• Use image startup acceleration, which is enabled by default and automatically reduces cold start duration after each function create or update. See Accelerate startup of images for Container Registry Personal Edition and Accelerate image startup for Container Registry Enterprise Edition.

• Configure provisioned instances to keep instances warm. See Configure provisioned instances and auto scaling rules.

• If your function is thread-safe and resources allow, configure instance concurrency so a single instance handles multiple requests simultaneously. See Configure instance concurrency.

HTTP server requirements

Your container's HTTP server must meet the following requirements.

Listening address

Listen on 0.0.0.0:CAPort or *:CAPort. Do not use 127.0.0.1:CAPort—the function will fail to start with the following error:

{
  "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"
}

The default CAPort is 9000. The HTTP server's listening port must match the CAPort configured for the function. For example, if CAPort is set to 8080, the HTTP server must also listen on port 8080.

Keep-alive and timeout

Enable keep-alive and set the server-side request timeout to 15 minutes or longer:

// Example using the Express framework for Node.js
var server = app.listen(PORT, HOST);
server.timeout = 0;          // never timeout
server.keepAliveTimeout = 0; // keep-alive, never timeout

Startup time

The HTTP server must complete startup within 120 seconds.

Common request headers

The common request headers for Custom Container runtime are the same as for custom runtime. See Common request headers in Function Compute.

Log formats

Logs written to standard output (stdout) are automatically collected to the configured Logstore in Simple Log Service. The log format is the same as for custom runtime. See Configure logging and Function log formats.

Billing

Custom Container functions are billed the same way as functions in other runtime types. See Billing overview.

Image pull duration—from when the pull starts to when it completes—counts toward image resource usage. For example, pulling an image for an instance with 1 GB of memory that takes 10 seconds results in 10 GB-seconds of resource consumption. Container images are cached for a period of time. When cached images are used, there is no image pull fee.

Next steps

• Handlers

• Event handlers

• HTTP handlers

• Create a Custom Container function

• Lifecycle hooks for function instances