Overview

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 function
• HTTP function

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.

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.

Examples

References

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