SCF allows you to deploy container images as functions. This document describes the background, principles, development, log printing, cold start optimization, billing, and use limits of image deployment functions.
SCF is a FaaS service based on the cloud native architecture from the very beginning of design. After adding support for deploying container images as functions at the runtime layer, its entire service form has evolved towards a containerized ecosystem. On the one hand, it solves the environment dependency problem in function runtime and gives you more freedom to customize. On the other hand, this service form enables you to cross the technical thresholds, such as Kubernetes cluster management, security maintenance, and troubleshooting, and sinks auto scaling, availability, and other needs to the computing platform, further unleashing the capabilities of cloud computing.
Before developing specific function logic, you need to determine the function type. SCF provides event-triggered functions and HTTP-triggered functions.
During function instance initialization, SCF gets the temporary username and password as the access credentials to pull the image. After successfully pulling the image, SCF starts the HTTP server defined by you based on the defined
Command bootstrap command,
Args parameter, and port (which is fixed at 9000). Finally, the HTTP server receives all entry requests of SCF, including those from your event and HTTP-triggered function invocations.
How a function works is as shown below:
For a function deployed based on an image, you need to build an HTTP server and configure it as follows:
If the above step is not completed, health check may time out, and the following error may be reported:
The request timed out in 30000ms.Please confirm your http server have enabled listening on port 9000.
event: POST request body (HTTP body)
The request body contains the event data. For its structure, please see Trigger Event Message Structure Summary.
context: request header (HTTP header)
X-Scf-Request-Idto get the current request ID.
The input parameters are as detailed below:Note
- Both event and HTTP-triggered functions should contain common headers.
- The common request headers are generated by SCF, which mainly contain permissions and basic function information.
|X-Scf-Request-Id||Current request ID|
|X-Scf-Memory||Maximum memory that can be used during function instance execution|
|X-Scf-Timeout||Timeout period for function execution|
|X-Scf-Appid||`Appid` of function owner|
|X-Scf-Uin||`Uin` of function owner|
|X-Scf-Session-Token||Temporary `SESSION TOKEN`|
|X-Scf-Secret-Id||Temporary `SECRET ID`|
|X-Scf-Secret-Key||Temporary `SECRET KEY`|
|X-Scf-Trigger-Src||Timer (if a timer trigger is used)|
Environment variables built in the container in custom image-based deployment are different from those in code package-based deployment. You can import them as needed.
|Environment Variable Key||Specific Value or Value Source|
/event-invoketo receive function invocation requests.
SCF collects standard output logs such as
stderr generated in the container in a non-intrusive manner and reports them to the log module. After invoking a function, you can view the aggregated logs in the console.
As file layers such as basic environment and system dependency are added to the image, compared with code package-based function deployment where files are completely built-in, image-based function deployment requires extra file download and image decompression time. To further reduce the cold start time, we recommend you use the following practices:
The billable items of image-based functions are the same as those of code package-based functions. For more information on billing, please see Billing Mode.
Currently, only images below 1 GiB in size are supported. We recommend you select an appropriate function instance execution memory based on the image size.
|Image Size (X)||Execution Memory (Y)|
|X < 256 MB||256 MB < Y < 512 MB|
|256 MB < X < 512 MB||512 MB < Y < 1 GiB|
|512 MB < X < 1 GiB||Y > 1 GiB|
/tmpis readable and writable by default. We recommend you select
/tmpwhen outputting a file.
Currently, SCF functions run on the x86 architecture, so images built on the ARM platform (such as Apple Mac with M1 chip) are not supported.
The client should meet one of the following requirements: