How to use the Serverless Manager module?

Owned by DevPortal Editor (Unlicensed)
Last updated: 03/10/22 by Onesait Platform
5 min read

Available since version 3.2.0

Introduction

In this guide we will explain how to use the Serverless platform module, in order to deploy functions similar to the functionality of microservices.

We recommend taking a look at this guide to understand the different concepts involved in this functionality.

Concepts

We have integrated into the platform a new module that allows the development of components in the form of Functions, using a serverless architecture. This module is based on the Open Source project fn project.

Following the scheme proposed by fn, we distinguish two concepts to be taken into account: applications and functions.

Applications encompass a set of functions, and each platform user can create as many applications as needed. These applications will have a working Git repository associated with them, where the code of all the functions that belong to these applications will reside.

Likewise, within each application, N functions can be created. For practical purposes, a function will be a code project (Java/Maven, Python, ...) with a structure that we will detail later. Each function will be responsible for executing a specific functionality.

Applications

List

If you go within the Development menu to My Serverless Applications or Serverless Application Management (depending on the role you have), you will see a list where all your created applications will be shown.

For each function, the table will show data such as: owner, Git repository, number of functions in the application...

Creation

To create a new application, click on the '+' icon in the list.

When creating a new application, you will be asked for the Git credentials (GitHub or GitLab), and you will be asked if you want to create a new project associated with that application. If not, you will also have to specify the URL of the existing Git repository.

This Git repository, created or already existing, will be the working repository where you will develop the functions of the application.

NOTE: Soon we will incorporate a functionality that will allow us to create applications with several archetypes as an example on which to start developing the functions.

Update

In the application modification screen, accessible from the list through the pencil icon, you can only modify the information related to the name and the Git configuration.

Deletion

The application can be deleted both from the list and from the edit and view pages.

The only thing to bear in mind is that, even if the application and its functions are deleted, the Git repository will not be deleted.

View

From the view page, you can see both the general information of the application and the list of its functions.

General information:

Here you will find the information related to Git, as well as the environment variables defined in the application.

These environment variables will be accessible from each and every function of the application. However, they can be overwritten at function level.

List of functions:

In the second tab of the view, you can see a list of functions with relevant data such as: function version, allocated memory, name, relative path within the Git project, invocation endpoints...

In addition, from this list, you can create, edit, delete and deploy functions.

Functions

Creation

From the application view we can create new functions.

When creating a function we will only be asked for the name of the function and the relative path within the Git repository. At the time of creation it is not necessary that the code associated with the function exists within the repository, but it will have to exist when deploying it.

Code structure of a function:

The structure of the function will be given by the programming language to be used. It could be a Maven project, Java, Go, Python... Here is a list of the supported languages.

Whatever the language, it will be necessary to include in the root directory of the function a file 'func.yaml' with the necessary information for the compilation, deployment and execution of the function.

Next is an example of a structure with a maven function and a python function.

To complete the func.yaml file, we recommend to see this document where each property is explained.

Func.yaml of a Java function:

schema_version: 20180708 name: ontology version: 0.0.26 runtime: java11 build_image: fnproject/fn-java-fdk-build:jdk11-1.0.124 run_image: fnproject/fn-java-fdk:jre11-1.0.124 cmd: com.minsait.onesait.OntologyCalculationFn::handleRequest config: API_KEY: 26104876616f40908e3643ed1f6357d1 GRAYLOG_HOST: log-centralizer GRAYLOG_PORT: "12201" triggers: - name: endpoint type: http source: /calculate

 

Func.yaml of a Python function:

schema_version: 20180708 name: pythonfn version: 0.0.1 runtime: python entrypoint: /python/bin/fdk /function/func.py handler memory: 256 config: API_KEY: 26104876616f40908e3643ed1f6357d1 triggers: - name: endpoint type: http source: /pythonfn

 

Below is a zip file with 3 examples of functions.

Update

In the update screen of a function, you will be able to update both the name of your function and the relative path within the repository.

Remove

You can delete a function (but not the repository code) from the list of functions of an application, or from the modification screen.

Deployment

When you have your function ready, you can deploy it from the rocket icon in the list of functions.

This may take up to 1 minute. Once the deployment is finished, the page will be reloaded and you will see how the version of the deployed function is increased (it will be reflected in the func.yaml of the repository with a commit).

HTTP Invocation

Once the function is deployed, you can invoke it via HTTP to execute and test it. There are two types of invocable endpoints: auto-generated and HTTP triggers.

The first ones are automatically generated by the fn manager, and the second ones are defined from the func.yaml

Auto-generated always take the form of /fn/invoke/{UUID} and will always be POST requests.

Triggers can be invoked with the GET or POST verb, depending on whether your function needs to receive a payload or not.