SCF supports developers to deploy container images as functions. Currently, two types of image functions are supported:
WebServer Image Function: The mirror needs to include an Http Server and listen on port 9000. After the instance is pulled up, the event body is imported into the instance in the form of an HTTP request.
Job Image Function: The mirror does not need to include an Http Server and does not expose any ports. After the instance is pulled up, a specific command will be executed according to the CMD and EntryPoint specified by the user (for example, a simple date command, or a specific code logic can be specified to run). After execution, the instance will be automatically released. The event body is injected into the instance in the form of an environment variable.
This document introduces the background information, working principle, function development, function log printing, cold start optimization, billing description, and usage limits of the Job Image Function.
Background
After the WebServer image was launched, the environment dependency issues at runtime were better resolved. This feature also provided users with greater freedom to customize. On the other hand, we found that the restriction that the WebServer image function must include an Http Server within the image brought considerable migration transformation costs for cloud native users to use the image function. For this reason, we introduced a brand-new Job Image Function type. Users do not need to make any modifications to existing images and can quickly migrate to SCF. Users can fully enjoy the convenience brought by being free from Kubernetes cluster management, security maintenance, and resource fault diagnosis. The needs such as auto scaling and availability are sunk to the computing platform, further releasing cloud computing capabilities.
How It Works
At present, only event functions support Job Image.
During the initialization phase of the cloud function instance, a temporary username and password from the mirror repository are obtained as access credentials to pull the image. Currently, the call request is responded to asynchronously. That is, after receiving the call request, completing the image pull, and successfully launching the instance, the instance scheduling result (200 OK) will be returned immediately. Then, a specific process will be asynchronously executed according to the startup command Command and parameters Args you defined. Finally, after the lifecycle of this process ends, the instance will be automatically destroyed.
The event body will be injected into the instance via an ambient command. The entire invocation process is shown below:
Function Development Based on Job Image Deployment
Function Input Parameter
SCF_CUSTOM_CONTAINER_EVENT: EVENT body, json type. After receiving a request, it is directly injected into the instance via an environment variable.
SCF_CUSTOM_CONTAINER_EVENT={"key1":"test value 1","key2":"test value 2"}
Job Image functions do not expose any ports after being pulled up, so it is unable to directly pass through HTTP requests to the instance.
The maximum length limit for a single command line parameter or environment variable of a Job Image function is 128KB. The total size limit for all environment variables is 2MB. Your event body size must follow this limit.
Built-In Other Environment Variables
Custom Image scenarios have made adjustments to environment variables within the container compared with code package-based deployment. You can refer to them as needed.
Environment Variable Key
Specific Value or Value Source
TENCENTCLOUD_RUNENV
SCF
USER_CODE_ROOT
/var/user/
USER
qcloud
SCF_FUNCTIONNAME
Function Name
SCF_FUNCTIONVERSION
Function Version
TENCENTCLOUD_REGION
Region
TENCENTCLOUD_APPID
Account APPID
TENCENTCLOUD_UIN
Account UIN
Function Calling Method
You can call directly on the console or using API, and also support calling with a trigger.
Function Log Printing
SCF will non-invasively collect standard output logs such as stdout and stderr generated within the container and report them to the log module. After you invoke the function, you can view the log aggregation display effect via the console.
Cold Start Optimization
The mirror, due to the addition of file layers such as the basic environment and system dependencies, has extra file download and image decompression time compared with the fully built-in nature of code package-based deployment. To further reduce the cold start time, it is recommended to use the following policies.
Optimizing Image Volume
Create a mirror repository and a function in the same region. When the function triggers image pull, perform the pull through the VPC network to obtain faster and more stable image pull efficiency.
Image creation follows the principle of minimization, containing only the necessary basic environment and run dependencies while removing unnecessary files.
Enable Image Acceleration
By enabling the image acceleration switch, the function platform uses an internal acceleration mechanism to pre-cache images nearby. When invoking a function instance, it directly loads and decompresses from the cache, eliminating the time for image file download. This can achieve an average 5-fold enhancement in start-up speed.
Operation Steps
1. Log in to Serverless Console, and click Function Service in the left sidebar.
2. In the Function Service list, select the image function name to be configured.
3. In the Function Management page, select Function Code, and click Edit on the right of the image configuration to enter edit mode.
4. Click
on the right of Image Acceleration to enable Image Acceleration Mode. As shown below:
5. Click Save to complete the configuration.
Must-Knows
The feature is currently in the open beta free trial period. Each account is limited to enabling up to 5 function accelerations in a single region.
Using Preset Concurrency
Image deployment combined with the provisioned concurrency feature pre-launches function instances to achieve the best experience in reducing cold startup. For details, see Provisioned Concurrency.
Billing Instructions
The billable items for deploying functions using images are exactly the same as those for deploying with code packages. For billing details, see Pay-As-You-Go (Postpaid).
Use Limits
Image Size
Currently, only images (before decompression) smaller than 1GB are supported. If you have special requirements, you can submit a ticket to apply. It is recommended that you select the appropriate execution memory for the function instance based on the image size.
Image Size (X)
Execution Memory (Y)
X < 256MB
256MB < Y < 512MB
256MB < X < 512MB
512MB < Y < 1GB
512MB < X < 1GB
Y>1GB
Access the Mirror Repository
Only supports Tencent Cloud TCR Enterprise Edition and personal edition. For more details, see Tencent Container Registry.
Personal Edition image repository details of the container image service can be found in TCR Individual Getting Started.
Read images from the private image repository in the same region (Region) only.
File Read and Write Permissions Within the Container
When outputting files, the rootfs file system is writable.
Avoid using files with access or execution limitations of other users.
The writable layer storage space within the container is limited to 512M.
Building Image: Client CPU Architecture Limit
SCF currently runs based on the X86 architecture, so it does not currently support images built on the ARM platform. A typical ARM platform is a PC equipped with an M1 chip on an Apple Mac.
Building Image: Client Restrictions
Meet one of them.
Docker image manifest V2, schema 2 (use Docker version 1.10 or later)
Open Container Initiative (OCI) Specifications (v1.0.0 or higher)
