Deploy openYuanrong Service Applications

Deploy openYuanrong Service Applications#

This chapter introduces how to build and deploy service applications developed using openYuanrong function service interfaces. Applications provide services externally through REST API. Here takes a single openYuanrong function developed application as an example, for multi-function applications, each function needs to be deployed separately.

Environment Dependencies#

Your application may contain other dependencies besides runtime, such as:

  • Packages that Python and Java programs depend on for running, dynamic libraries that C++ programs depend on.

  • Environment variables that need to be read in openYuanrong functions.

  • Data files that need to be read in openYuanrong functions, tools used, etc.

openYuanrong functions may run on any node in the cluster, so these dependencies need to exist and remain consistent on each openYuanrong node. Environment variables needed by functions can be set when registering functions and obtained through context. When deploying on a host cluster, it is recommended to pre-install other dependencies on host nodes; when deploying on a K8s cluster, related dependencies can be packaged together with function code or shared over the network.

Build Deployment Package#

When functions are deployed on a K8s cluster, you need to package the compiled code into a zip package, and you can also choose to package dependencies together.

Python is an interpreted language and does not require a compilation process. When packaging, ensure that the source code file where the function’s Handler method implementation is located is in the root directory of the package. For example, if the source code file is named handler.py, use the following packaging command to generate the deployment package demo.zip.

zip -j demo.zip handler.py

C++ functions need to be compiled into binaries first, compilation depends on openYuanrong C++ SDK. When packaging, ensure that the binary file generated by function compilation is in the root directory of the package. For example, if the function binary file is handler, refer to the following packaging command to generate the application code package demo.zip.

ldd ./handler | awk '/=>/ {print $3}' | grep -v '^$' | tr '\n' '\0' | xargs zip -j demo.zip ./handler

Building Java function jar package depends on openYuanrong Java SDK. When function and dependencies are in one jar package, no packaging is needed; when separated into multiple files, place the function jar package in the root directory and package all files into a zip package.

Register Function#

Functions need to be registered to the openYuanrong cluster before they can be called. Use Register Function API to complete function registration. The basic configuration items involved in the API are as follows:

  • name: Function name, fill in according to FaaS function naming rules in the API.

  • runtime: Runtime type used by the function, enumeration values such as Python3.9, keep consistent with your development environment language version.

  • kind: Function type, configure as faas.

  • cpu: CPU resource amount needed for function operation.

  • memory: Memory resource amount needed for service operation.

  • timeout: Timeout time for function processing requests.

  • storageType: Function code package storage type. When deploying on openYuanrong host cluster, it is recommended to configure as local, i.e., stored on host disk; when deploying on openYuanrong K8s cluster, it is recommended to configure as s3, i.e., stored in object storage services supporting S3 protocol such as MinIO.

  • handler: Definition of Handler method in the function.

    • Python language is {source file name}.{Handler method name}, for example python_func.handler.

    • C++ language is {function binary file name}, for example cpp_func.

    • Java language is {package name}.{class name}.{Handler method name}, for example com.xxx.MyApp.myHandler.

  • extendedHandler: Definition of Initializer and PreStop methods in the function, configuration method is the same as Handler method.

  • extendedTimeout: Execution timeout time for Initializer and PreStop methods in the function.

See Function Service Example Project for complete examples.

Invoke Function#

Functions support synchronous invocation through REST API, with streaming (Server-Send Events) or non-streaming responses. Streaming response data will be chunked, generated and returned step by step. Non-streaming responses return all results at once.

Use Invoke Service API to execute function invocation. The main configuration items involved in the API are as follows:

  • Header parameter Accept: Set when using streaming response.

  • Header parameter X-Pool-Label: Resource pool label that function instances are affine to when deploying on K8s cluster.

  • Header parameter X-Instance-Label: Process requests on function instances with this label. You can configure the label when creating function reserved instances.

See Function Service Example Project for complete examples.