Kyma – Local Lambda Development and Github CI/CD

In this blog we are going to look at two concepts relating to developing lambda (also known as serverless) functions in Kyma.  Generally, lambda functions are developed within the Kyma UI, providing a convenient way to quickly implement extensions. In some cases, however, it is preferred to use a local environment for development.  With the use of a local development environment, this then raises the question of how to deploy the functions.  To answer this question, you can use CI/CD tools, for example Github actions, to automate the generation of a deployment.yaml and apply it to the Kyma cluster. To demonstrate this, I’ve created an example project that can be found at

https://github.com/jcawley5/kyma-local-dev

which includes basic instructions on how to run it within the readme of the repo.

It’s important to note that today Kyma is relying on Kubeless to provide support for the serverless feature.  This will eventually change as the project migrates to Knative serving.  With this in mind, I’ve attempted to set the project so it could easily be adapted to this change.

In this blog I’ll outline the contents of the project structure and cover some of the commands that can be ran.  Please note, that the intention of the repo is to provide an example and is in no way covering all the bases of deployment.  To run the complete example, it will be necessary for you to fork the repo into your own github account.  The reason being, a secret needs to exist within the project that contains a base64 encoded kubeconfig.  This is needed for the Github action to deploy the functions to the cluster.  If you are only interested in running it locally you can just clone the repo.  Building the deployment.yamls is also supported locally.

The Project Structure

Folder: /github/workflows

The folder, github/workflows, contains the github action defined in the main.yml.  The first few lines of the file define when the action will be ran, in this case any pushes to the lambdas folder on the master branch.  If this is true, the action will spin up a VM, which will check the code out and determine a listing of files_added and files_modified, saved as json files, performed in the step Get changed files. There is also a files_deleted list that could be used depending on your use case.  With this complete, the next few steps install nodejs, lints the function definitions, and then generates deployment.yamls for each function that has been added or modified.  Finally, the deployments are deployed to the cluster and saved into an archive.  If you are new to Github actions, you can edit this file within the Github site to display the marketplace where each action, denoted by the uses property, can be further investigated as well as access the general documentation.

Folder: /build

The deployment yamls are generated within the Github action by running the command npm run deploymentByDirChanges. This command refers to a script defined in the package.json of the project root that calls the function by the same name defined within the build/build.js. Depending on the results of the step, Get changed files, we can determine which lambda functions need a deployment.yaml generated.  You will also find a templates directory, with a number of parameterized templates that are used in the generation of the yaml files.  The values populated into the yamls are derived from each lambda definition, which are found in the lamdbas directory.

Folder: /lambdas

Each folder in the lamdba directory represents a lambda definition.  Within each of these folders you will find the .env which defines the environment variables used by the lambda, app.js, which is the lambda function code and also the related package.json that defines it’s dependencies. The package.json is also used to define the function name and the location of the lambda code designated by the value of the main property.  It also contains an object buildParameters which are used to define some of the parameters used when building the yaml files. For example, the function namespace and if an API should be enabled for the function.

Folder: /localdev

This folder contains the supporting Kubeless files to allow the functions to be ran locally.  No modifications were made on these files.

Folder: /

Within the root of the project you will find the runlocal.js file, which enables the functions to be ran locally.  The file will first load the environment variables defined for the lambdas and then reference the contents of the relating Kubeless files found in the localdev.  Within the file you will also find an example on how any service bindings could be used during local testing.

Running the project 

Clone the project and then run npm install at the project’s root and within each lambda folder.

The lambda examplefn can be ran locally by running the runlocal.js at the project root with the parameters MOD_NAME and FUNC_HANDLER, which are environment variables defined in /localdev/kubeless.js, for example

MOD_NAME=../kyma-local-dev/lambdas/examplefn/app FUNC_HANDLER=main node runlocal.js

Which will make the function available at

http://localhost:8080/

MOD_NAME specifies the location of the lambda code and FUNC_HANDLER specifies the name of the function to be ran.

The examplefn2 is setup to reference a service binding to the CC OCC Commerce Webservices v2 of SAP Commerce Cloud.  This would need to be altered to work correctly in your environment.  You can find more information regarding this in the readme of the repo as well as in the runlocal.js.

Building the examplefn function locally can be done by running

FUNCTIONDIR=examplefn npm run deploymentYaml

which will generate the file deployment_examplefn.yaml in the build/deployment folder, that contains the function deployment and an unauthenticated API deployment.

As mentioned in the beginning of the blog you will find all of the commands to run the project within the readme of the repo as well as the instructions to setting up the deployment via the github action.  Please feel free to offer any suggestions or submit any pull requests you have.