This document describes how to create, package, and release a Custom Runtime cloud function to respond to the triggered event. You will learn the development process and operating mechanism of Custom Runtime.
Directions
Before creating a Custom Runtime cloud function, you need to create a runtime boot file bootstrap and function file.
Creating a bootstrap file
Bootstrap is a runtime entry bootloader. When Custom Runtime loads a function, it retrieves the file named “bootstrap” and executes the file to start Custom Runtime, which allows developers to develop runtime functions using any programming language and version. Bootstrap must:
Have the execute permission.
Be able to run in the SCF system environment (CentOS 7.6).
You can refer to the following sample code to create a bootstrap file in a command line terminal. Bash is used as an example in this document.
#! /bin/bash
set -euo pipefail
# Initialization - Load the function file.
source ./"$(echo $_HANDLER | cut -d. -f1).sh"
# After the initialization is completed, access the runtime API to report the readiness.
curl -d " " -X POST -s "http://$SCF_RUNTIME_API:$SCF_RUNTIME_API_PORT/runtime/init/ready"
### Start the loop that listens to events, handles events, and pushes event handling results.
whiletrue
do
HEADERS="$(mktemp)"
# Gets event data through long polling
EVENT_DATA=$(curl -sS -LD "$HEADERS" -X GET -s "http://$SCF_RUNTIME_API:$SCF_RUNTIME_API_PORT/runtime/invocation/next")
curl -X POST -s "http://$SCF_RUNTIME_API:$SCF_RUNTIME_API_PORT/runtime/invocation/response" -d "$RESPONSE"
done
Sample description
In the preceding sample, Custom Runtime has two phases, the initialization and invocation phases. Initialization is executed only once during the cold start of a function instance. After the initialization, the invocation loop starts, which listens to events, invokes functions for handling, and pushes the handling results.
Initialization phase
For more information, see Initializing function.
After the initialization, you need to proactively invoke the runtime API to report the readiness to SCF. The sample code is as follows:
# After the initialization is completed, access the runtime API to report the readiness.
curl -d " " -X POST -s "http://$SCF_RUNTIME_API:$SCF_RUNTIME_API_PORT/runtime/init/ready"
Because Custom Runtime is implemented with a custom programming language and version, a standard protocol is needed for the communication between Custom Runtime and SCF. In the current sample, SCF provides runtime APIs and built-in environment variables to Custom Runtime over HTTP. For more information, see Environment Variables.
SCF_RUNTIME_API: Runtime API address
SCF_RUNTIME_API_PORT: Runtime API port
Initialization logs and exceptions
For more information, see Logs and exceptions.
1.1 After initialization, the invocation loop starts. A function is invoked to listen to events. The sample code is as follows:
# Gets event data through long polling
EVENT_DATA=$(curl -sS -LD "$HEADERS" -X GET -s "http://$SCF_RUNTIME_API:$SCF_RUNTIME_API_PORT/runtime/invocation/next")
During the long-polling of events, do not set timeout of the GET method. Access the runtime event acquisition API (/runtime/invocation/next) to wait for event delivery. If you access this API repeatedly within an invocation, the same event data will be returned. The response body is event_data. The response header includes:
Request_Id: Request ID, identifying the request that triggers function invocation.
Memory_Limit_In_Mb: Function memory limit, in MB.
Time_Limit_In_Ms: Function timeout limit, in milliseconds.
1.2 Based on the environment variables, response header information, and event information, construct parameters of the function and start function invocation for event handling. The sample code is as follows:
1.3 Access the runtime invocation response API to push the function handling result. The first invocation success will be considered as the final event status, which will be locked by SCF. The pushed result cannot be changed. The sample code is as follows:
# Pushes the function handling result
curl -X POST -s "http://$SCF_RUNTIME_API:$SCF_RUNTIME_API_PORT/runtime/invocation/response" -d "$RESPONSE"
If an error occurs during function invocation, access the runtime invocation error API to push the error message, which ends the current invocation. The first invocation result will be considered as the final event status, which will be locked by SCF. The pushed result cannot be changed. The sample code is as follows:
# Push the function handling error.
curl -X POST -s "http://$SCF_RUNTIME_API:$SCF_RUNTIME_API_PORT/runtime/invocation/error" -d "parse event error"
Invocation logs and exception
For more information, see Logs and exceptions.
Creating a function file
Note
The function file contains the implementation of function logic. The execution method and parameters can be implemented by Custom Runtime.
Create index.sh in the command line terminal.
functionmain_handler(){
EVENT_DATA=$1
echo"$EVENT_DATA"1>&2;
RESPONSE="Echoing request: '$EVENT_DATA'"
echo$RESPONSE
}
Releasing a Function
1. After the bootstrap file and function file are successfully created, the directory structure is as follows:
├ bootstrap
└ index.sh
2. Run the following command to grant execute permission on the bootstrap file:
Note
Windows does not support the chmod 755 command. Therefore, you need to run the command in Linux or macOS.
$ chmod755 index.sh bootstrap
3. Create and publish functions by using Serverless Cloud Framework. Or, run the following command to generate a ZIP package and then create and publish functions through the SDK or SCF console.
$ zip demo.zip index.sh bootstrap
adding: index.sh (deflated 23%)
adding: bootstrap (deflated 46%)
Using Serverless Cloud Framework to create and publish a function
As events is set to apigw in the serverless.yml file, an API gateway is created together with the function. The cloud function can be accessed over this API gateway. If a message similar to the following is returned, the access is successful.
Initialization timeout period. Custom Runtime adds a configuration of initialization timeout period. The initialization period starts from the boot-time of bootstrap and ends when the runtime API is reported ready. When the initialization period exceeds the timeout period, the execution ends and an initialization timeout error is returned.
"Timeout":3
Invocation timeout period. This parameter configures the timeout period of function invocation. The invocation period starts from the event delivery time and ends upon the time when the function pushes the handling result to the runtime API. When the invocation period exceeds the timeout period, the execution ends and an invocation timeout error is returned.
Yes
No
Was this page helpful?