Beyond the standard runtime environments supported by Serverless Cloud Function (SCF), SCF offers a Custom Runtime service to accommodate the implementation of functions in more personalized development languages and versions. By enabling the creation of custom function runtimes, it supports the use of any version of any development language to write functions, and to carry out global operations during function calls, such as loading extension programs, security plugins, monitoring agents, etc. SCF and Custom Runtime communicate via the HTTP protocol to handle event responses.
Custom Runtime Deployment Documentation
Bootstrap: A fixed executable bootstrap program file in Custom Runtime, created by developers as an executable program file with the same name. It is implemented through custom languages and versions, directly processing or initiating other executable files to handle the initialization and invocation of function runtime.
Function Files: Function program files developed and implemented by developers through custom languages and versions.
Runtime-dependent Library Files or Executable Files: Add relevant dependent library files or executable files as needed by the custom language and version runtime.
Published through a deployment package, the file structure is as follows:
Bootstrap (Required)
Function Files (Required)
Runtime-dependent Library Files or Executable Files (Optional)
Due to the size limitations of the deployment package, when the volume of runtime-dependent library files or executable files is large, it is recommended to publish through a combination of deployment package binding layers. The file structure is as follows:
Deployment Package:
Bootstrap (Required)
Function Files (Required)
Layer:
Runtime-dependent Library Files or Executable Files (Optional)
Note
Before deploying the executable files in the above deployment files to SCF, please ensure to set the executable permissions of the files, and then package the deployment files and upload them directly via a zip package or through COS. For instance, when you compile files using the root account in a Linux system, you can use the
chmod -R 777 your_path command to change the file permissions.Custom Runtime Operating Mechanism
Custom Runtime divides the lifecycle of a function into an initialization phase and an invocation phase. The initialization phase is executed only once during the cold start process of an instance, while the invocation phase is the execution process for each event call after the instance is started.
Different programming languages and versions will have different startup and execution times. SCF has added an Initialization Timeout configuration for Custom Runtime, which, along with the Execution Timeout configuration, manages the lifecycle of Custom Runtime.
Function Bootstrapping
SCF first retrieves the executable bootstrap file in the deployment package and performs the following operations based on the retrieval results:
If the bootstrap file is retrievable and executable, the bootstrap program is loaded and executed, entering the function initialization phase.
If the bootstrap file is not retrievable or not executable, it returns that the bootstrap file does not exist, resulting in a startup failure.
Function Initialization
It begins with the execution of the bootstrap program file. Developers can customize personalized operations in the bootstrap as needed, directly processing or calling other executable program files to complete the initialization operation. The following are basic operations recommended to be completed during the initialization phase:
Set the paths and environment variables of the runtime's dependency libraries.
Load library files and extension programs dependent on custom languages and versions. If there are still dependent files that need to be pulled in real-time, they can be downloaded to the
/tmp directory.Parse the function file and execute the global operations or initialization processes (such as initializing SDK client (HTTP client) and creating database connection pool) required before function invocation, so they can be reused during invocation.
Start plugins such as security and monitoring.
Upon completion of the initialization phase, it is necessary to actively call the runtime API and access the initialization ready interface
/runtime/init/ready to notify SCF that the Custom Runtime has completed initialization and entered the ready state. Otherwise, SCF will continue to wait until the configured initialization timeout is reached, at which point it will terminate the Custom Runtime and return an initialization timeout error. If notified repeatedly, the time of the first access will be used as the ready state time node.Logs and Exceptions
SCF will collect all standard outputs during the initialization phase and report them to the logs.
If the function initialization is completed normally within the timeout limit, the logs from the initialization phase will be merged with the logs from the first invocation. If the execution is not completed due to an error within the initialization timeout limit, the execution result will return an initialization timeout error. The program errors and exception logs written to the standard output will be reported to SCF and displayed in the console logs and log queries.
Function invocation
During the function invocation phase, developers need to custom implement the acquisition of events, function invocation, and return of results, and continuously manage this process.
Implement long polling for event acquisition. Developers can use a custom language and version to implement an HTTP CLIENT to access the event acquisition interface of the runtime API
/runtime/invocation/next. The response body contains event data, and repeated access to this interface within a single invocation will return the same event data.Note
Do not set a timeout for the GET method of the HTTP CLIENT.
Construct the parameters for the function invocation based on the required information in the environment variables, response headers, and event information.
Push event information and other parameter data, and invoke the function handler.
Access the runtime API response result interface
/runtime/invocation/response to push the function processing results. The first successful call is the final state of the event, and SCF will lock the status. Once pushed, the result cannot be changed.If an error occurs during the function invocation, push the error information by accessing the runtime API call error interface
/runtime/invocation/error. This will end the current call. The first call is considered the final state of the event, and SCF will lock the status. The result cannot be changed after it has been pushed.Clean up and release resources that are no longer needed after this call is completed.
Logs and Exceptions
SCF will collect all standard outputs during the invocation phase and report them to the logs.
If the Custom Runtime does not fetch the event for a long time after SCF issues it, and it exceeds the function execution timeout limit, SCF will terminate the instance and return a timeout error for waiting to fetch the event.
If the Custom Runtime fetches the event after SCF issues it but does not return the execution result within the function execution timeout limit, SCF will terminate the instance and return an execution timeout error.
Custom Runtime API
Custom Runtime is implemented by developers using custom languages and versions. Communication with SCF, such as event distribution and processing result feedback, needs to be conducted through a standard protocol. Therefore, SCF provides a runtime API to meet the interaction needs during the lifecycle of Custom Runtime.
SCF has the following built-in environment variables:
SCF_RUNTIME_API: The address of the runtime API.
SCF_RUNTIME_API_PORT: The port of the runtime API.
Custom Runtime can access the runtime API through
SCF_RUNTIME_API:SCF_RUNTIME_API_PORT.Path | HTTP Method | Description |
/runtime/init/ready | post | Once the runtime initialization is complete, call the interface to indicate readiness. |
/runtime/invocation/next | get | Retrieve the invocation event. The response headers contain the following information: Request_Id: request ID, identifying the request that triggers function invocation.Memory_limit_in_mb: Memory limit for the function, in MB.Time_Limit_In_Ms: function timeout limit, in milliseconds.The response body contains event data. For the structure, see Summary of Trigger Event Message Structure. |
/runtime/invocation/response | post | Function processing result. After invoking the function handler at runtime, the response from the function is pushed to the invocation response interface. |
/runtime/invocation/error | post | If the function returns an error, it is pushed to the invocation error interface, indicating that this invocation has failed. |