Custom container images let you deploy functions as container images in Function Compute, enabling low-cost migration, layered caching, and CI/CD integration.
Benefits
Function Compute supports custom container images as function deliverables:
-
Low-cost migration without code changes or binary recompilation. Shared object files (*.so) keep development and production environments consistent.
-
Simplify distribution and deployment by packaging code and dependencies together.
-
Improve code upload and pull efficiency through layered caching.
-
Leverage open-source CI/CD tooling for standardized building, sharing, and versioning of third-party libraries and code.
-
Interact with Function Compute over HTTP.
-
Run non-interactive images.
How it works
Before Function Compute initializes an instance, it assumes the function's service role and obtains a temporary username and password to pull the image. After the image is pulled, it starts the container with the specified Command and Args.
The container image must include an HTTP server. Function Compute listens to your custom HTTP server on the configured `CAPort`. This server handles all requests to Function Compute, including API and HTTP invocations. Functions can be invoked in two ways:
-
Invoke a function by an API call
-
Invoke a function by an HTTP request
Limits
Image size limit
For ACR Personal Edition or Enterprise Edition (Basic, Standard, or Premium), the maximum uncompressed image size is 10 GB for CPU instances and 15 GB for GPU-accelerated instances.
Image repository
Function Compute supports images from Container Registry Personal Edition and Enterprise Edition repositories.
ACR Economy Edition does not support image acceleration and is not compatible with Function Compute. Use images from ACR Personal Edition or Enterprise Edition (Basic, Standard, or Premium) instances.
Image access
Only public images in ACR Personal Edition can be accessed across accounts within the same region. All other images are restricted to private repositories within the same account and region.
File read and write permissions in containers
Containers run as root (UID=0) by default. If a user is specified in the Dockerfile, the container runs as that user.
Writable layer storage limit for containers
The container writable layer is limited to 512 MB or 10 GB, depending on the disk size in the function's advanced configuration. Create a function.
Writable layer data is not persistent and is deleted when the container is destroyed. For persistent storage, mount a NAS file system or OSS bucket in Function Compute. Configure a NAS file system. Configure Object Storage Service. Other shared storage services such as Tablestore are also supported.
Image architecture limit
Currently, Function Compute supports only AMD64 images. On ARM-based machines (such as Macs with Apple chips), specify the build platform as `linux/amd64`. An example command: docker build --platform linux/amd64 -t $IMAGE_NAME ..
Run docker inspect to verify. If the output includes "Architecture" : "amd64", the image is correct.
HTTP server requirements
These requirements apply to custom container functions with a web server:
-
The HTTP server must listen on
0.0.0.0:CAPortor*:CAPort. If the service listens on127.0.0.1:CAPort, requests time out and the following error occurs:{ "ErrorCode":"FunctionNotStarted", "ErrorMessage":"TheCA'shttpservercannotbestarted:ContainerStartDuration:25000000000.PingCAfaileddueto:dialtcp21.0.XX.XX:9000:getsockopt:connectionrefusedLogs:2019-11-29T09:53:30.859837462ZListeningonport9000" }The listener port defaults to 9000 and is configured by the `CAPort` property. Your HTTP server must listen on the same port.
-
The server must support `Connection: Keep-Alive` with a request timeout of 15 minutes or longer:
// For example, when using Express in Node.js. var server = app.listen(PORT, HOST); server.timeout = 0; // never timeout server.keepAliveTimeout = 0; // keepalive, never timeout -
The HTTP server must start within 120 seconds.
Common request headers
Custom container images use the same request headers as custom runtimes. Common request headers in Function Compute.
Log format
All stdout logs from custom container images are automatically collected by the Simple Log Service project you specify. Configure the logging feature.
Custom container images use the same log format as custom runtimes. Function log format.
Cold start optimization
Container images take longer to download and decompress than code packages. To reduce cold start latency:
-
Use a VPC image address in the same region as Function Compute to reduce pull latency and improve stability.
-
Minimize image size. Use a minimal base image such as Alpine or Ubuntu, and include only necessary dependencies.
-
Use provisioned instances to keep containers warm. Configure a minimum instance count elasticity policy.
-
For thread-safe functions, enable single-instance concurrency to reduce cold starts and costs if your resources allow. Create a web function.
Billing
Custom container images follow the same billing model as other runtimes. Billing overview.
Image pull time counts toward resource usage, calculated from the start to the end of the pull. For example, a 1,024 MB instance that takes 10 seconds to pull an image incurs 10 GB-seconds.
Images are cached for a period of time, so pull fees do not apply to every cold start.