This topic describes the background information, basic principles, environments, configuration requirements, common request headers, and log formats of a custom runtime.

Background information

A custom runtime is a custom runtime environment. In a custom runtime, you can perform the following operations:

  • Customize environments for personalized languages (such as Go, Lua, and Ruby) and minor versions of languages (such as Python 3.7 and Node.js 14) to create your own runtime environments.
  • Migrate existing web applications or traditional web projects to Function Compute with a few clicks.

Basic principles

A custom runtime is essentially an HTTP server. To create a custom runtime, you need to perform the following operations: build an HTTP server and configure a listening port for the server, create a file named bootstrap to store the command that is used to start the server, compress the bootstrap file and your code file into a ZIP package, and then create a custom runtime function by using the ZIP package as the code package.

To cold start the custom runtime, Function Compute calls the bootstrap file by default to start your custom HTTP server. Then, the HTTP server takes over all requests from Function Compute, including the invocations of event and HTTP functions.

Before you develop the logic of a function, you must determine whether the function is an event function or an HTTP function. The following figures show how an event function and an HTTP function work.

  • Event functioneventfunction
  • HTTP functionHTTPFunction

Environments

A custom runtime supports the following languages. You can create a custom runtime in the following languages without installing a third-party interpreter:

  • Python 3.7.4
  • Node.js 10.16.2
  • PHP 7.4.12
  • Ruby 2.7
  • PowerShell 7.1.0
  • OpenJDK 1.8.0 (OpenJDK 1.8.0_232)

For more information about the built-in configurations for these languages, see Dockerfile.

Configuration requirements on the HTTP server

Before you create an HTTP server, make sure that the following requirements are met:

  • Services started in a custom runtime must listen on the 0.0.0.0:CAPort or *:CAPort port. If you use the 127.0.0.1:CAPort port, the request times out and the following error is returned:
    {
      "ErrorCode":"FunctionNotStarted",
      "ErrorMessage":"The CA's http server cannot be started:ContainerStartDuration:25000000000. Ping CA failed due to: dial tcp 21.0.5.7:9000: getsockopt: connection refused Logs : 2019-11-29T09:53:30.859837462Z Listening on port 9000"
    }

    The default listening port (CAPort) of a custom runtime is 9000. If a custom runtime uses the default listening port, the listening port of its HTTP server must be 9000. If the listening port of the custom runtime is 8080, the listening port of its HTTP server must be 8080.

  • If the bootstrap file of the custom runtime stores shell scripts, you must add #!/bin/bash to the file. Otherwise, the following error is returned:
    {
      "ErrorCode":"CAExited",
        "ErrorMessage":"The CA process either cannot be started or exited:ContainerStartDuration:25037266905. CA process cannot be started or exited already: rpc error: code = 106 desc = ContainerStartDuration:25000000000. Ping CA failed due to: dial tcp 21.0.7.2:9000: i/o timeout Logs : 2019-11-29T07:27:50.759658265Z panic: standard_init_linux.go:178: exec user process caused \"exec format error\"     
    }                

    If the bootstrap file is a binary executable file, such as a binary file compiled by using Go or C++, you do not need to add #!/bin/bash.

  • To execute the bootstrap file of a custom runtime, you must have the 777 or 755 permissions. Otherwise, the following error is returned:
    {
      "ErrorCode":"CAFilePermission",
        "ErrorMessage":"The CA process cannot be started due to bootstrap file don't have execute permissions
    }  
    You can use one of the following methods to troubleshoot the error:
    • Run the chmod 777 bootstrap or chmod 755 bootstrap command before you compress files.
    • If you use the Windows operating system, convert the format of the bootstrap file to UNIX.
  • You must set the Connection parameter to Keep-Alive and the request timeout period to 15 minutes or longer. The following code provides an example on how to set Connection and the request timeout period:
    // The express framework for Node.js is used in the example.   
    
    var server = app.listen(PORT, HOST);
    server.timeout = 0; // never timeout
    server.keepAliveTimeout = 0; // keepalive, never timeout
  • The HTTP server must complete the startup within 30 seconds.

Common request headers in Function Compute

The following table describes the request headers that a custom runtime may receive from Function Compute. If you want to access other Alibaba Cloud services, you may use request headers of temporary AccessKey pairs. If you migrate existing applications to Function Compute, the following headers are not involved.

Note
  • Event functions and HTTP functions all contain common request headers.
  • Function Compute automatically generates common request headers. They contain basic information about permissions and functions.
Header Description
x-fc-request-id The ID of the request.
x-fc-access-key-id The temporary AccessKey ID.
x-fc-access-key-secret The temporary AccessKey secret.
x-fc-security-token The temporary security token.
x-fc-function-handler The handler of the function. This value is not required if the custom runtime is a function.
x-fc-function-memory The maximum memory that a function can use.
x-fc-function-initializer The handler of the initializer function. This value is not required if the custom runtime is a function.
x-fc-initialization-timeout The timeout period of the initializer function.
x-fc-region The region of the function.
x-fc-account-id The UID of the function owner.
x-fc-qualifier The service version or alias that is specified when the function is invoked. For more information, see View the version for a function.
x-fc-version-id The version of the function.
x-fc-service-name The name of the Function Compute service to which the function belongs.
x-fc-service-logproject The Log Service project configured for the Function Compute service to which the function belongs.
x-fc-service-logstore The Log Service Logstore configured for the Function Compute service to which the function belongs.
x-fc-control-path The type of the request.

Function log formats

We recommend that you use Log Service when you create a service in Function Compute. Then, all the generated stdout logs are stored in the specified Log Service project. For more information, see Configure Log Service resources and view function execution logs.

If Function Compute invokes a function in a runtime rather than a custom runtime or a custom container runtime, and the request header contains x-fc-log-type" = "Tail", the content that contains x-fc-log-result in the response header is the log generated when the function is executed. The maximum size of a log is 4 KB. You can view the log in function execution results in the Function Compute console. If you want to view the operational logs of a custom runtime in function execution results in the console, you must record the start and end logs of requests in the code.

Item Required Code format
Start of a runtime No
Note The flag for the cold start of the function.
FunctionCompute ${runtime} runtime inited.
Note If you use the Go language, you can specify a custom value for ${runtime}. We recommend that you do not specify an official language name, such as Node.js, Python, or PHP.
Invocation start log Yes FC Invoke Start RequestId: ${RequestId}
Invocation end log Yes FC Invoke End RequestId: ${RequestId}
Initialization start log No
Note This log must be recorded for the initializer function.
FC Initialize Start RequestId: ${RequestId}
Initialization end log No
Note This log must be recorded for the initializer function.
FC Initialize End RequestId: ${RequestId}
In addition to the preceding items, you can also record request IDs to facilitate future troubleshooting. We recommend that you use the $utcdatetime(yyyy-MM-ddTHH:mm:ss.fff) $requestId [$Level] $message format to record request IDs.
Note The API operation to specify the log level varies with languages. For more information, see Log records.

Examples

You can refer to the following topics when you create a custom runtime:
Function type Topic
Event function
HTTP function

References

For more information about the limits of custom runtimes, see Limits on resource usage.