Skip to Content
Technical Articles

Writing Function-as-a-Service [6]: values.yaml

This blog is part of a series of tutorials explaining how to write serverless functions using the Functions-as-a-Service offering in SAP Cloud Platform Extension Factory, serverless runtime
Nice.

Quicklinks:
Quick Guide

In the previous tutorial we learned how to extract secret sensitive values from the code into some property files
We defined secret and config maps to store the sensitive values
Nice.
But when the time has come to move from silly prototypes to productive projects, then we want… no: YOU want (because I continue with silly examples) to upload your project to GIT (or similar) and you don’t want to upload files with passwords etc

FaaS has a solution for it: it supports values-files
Nice.

How does it work?
We extract the sensitive info from the “secret”-file into a values-file
That values-file is not uploaded to GIT
The “secret”-file (which is uploaded to GIT) contains placeholder instead of passwords
During deployment, the placeholders are replaced by the values from the values-file
That’s all.
Nice.

Now we only need to go through a silly example to learn how to do it
Nice.

Note that this tutorial is only possible for local development, such that it is a

Prerequisite

to go through the 2 local tutorials, to learn about xfsrt-cli and faas-sdk

Another prerequisite is the usual blabla that you have to be familiar, etc, so please don’t ask me “What is FaaS”, and instead go through some of my tutorials

Although this tutorial is based on the previous one, you can skip that silly top-secret-blog and use your own project, as long as it has any secrets and configs

Create Project

Sorry for the wrong wording:
we don’t create a project, we download the project which we created in previous blog, from Extension Center to our local file system
We go to Extension Center, open our project and press the “download” button

And extract the project to a location of our boring choice.
The boring choice, like in my example: C:\topsecret
The project looks like this:

Create values file

Correct wording.
But not good.
In fact, we don’t create that file:
We let the faas-sdk generate it

On command line, we jump into the project folder, then execute the following command:

faas-sdk init-values -y ./_tmp/mydeployvalues.yaml

The syntax:
faas-sdk init-values –deploy-values <yourFilePath>

Note:
We can use abbreviation -y

Note:
File extension (currently) must be .yaml

The command will generate the .yaml file with the given name in the specified folder.
If you don’t specify a folder, then a folder with name “deploy” will be generated.

In our example, the result looks like this:

In our case, we get a warning.
Reason: for a config map, we used a file extension which is unknown to the parser.
It was skipped, but that doesn’t matter for us. it doesn’t contain sensitive information, so we don’t need to extract the content into the values-file

What has happened?
The init-values command parses the faas.json file and collects all secrets and configs which are declared there (also registered services).
In addition, all files which are found are listed as keys with the file-content as values
All is pulled out of the project and pushed into one values-file

In our example, it looks like this:

We can see the silly names which we had chosen in the previous blog for secret names and file names.
We can see that the file content has been copied into this file, along with file names and secret names

Replace the values

The title of this chapter could also be replaced by:
“Extract the values”
Or
“Move the sensitive content from all files of secrets and config maps to the new values-file”

Anyways, the next step is to fill the generated values-file with the sensitive information

In our case, it is already there.
But if you start a project from scratch – in future – you might create the secrets with placeholders instead of passwords

OK, in our example, we now have to delete all passwords etc from our secrets and configs

We open hiddensecret.json, delete the values for “username” and “password” and replace them with anything silly that comes into our mind

Similar with file addressconfig.json

That’s it

Deploy

This title is correct and good
But before we deploy….
Wrong: nothing needs to be done before deployment
But when we deploy, we have to tell the deployer where to find the values
Because the deployer will replace the silly placeholders with the serious values.
So we have to add the -y flag to the deploy command (or –deploy-values)
As such, in our example, the deploy command looks like this:

xfsrt-cli faas project deploy -y ./_tmp/mydeployvalues.yaml

The syntax:
xfsrt-cli faas project deploy –deploy-values <yourFilePath>

After deployment we call the function and check the log to verify if the values really have been replaced

Looks as expected.
Isn’t it a nice feature? Our placeholders are replaced with the real values during deployment

If you don’t believe it and if you think it was just an illusion or a coincidence… try it with different values in the values-file

Summary

We’ve learned how to move sensitive information out of the secrets into a values file
Reason: secrets are part of the dev project and need to be uploaded to GIT
The values-file mechanism helps to keep sensitive information out of GIT
The FaaS SDK supports with generation of the values-file
The XFRST-CLI allows to deploy with values-files parameter
The Extension Center does (currently) not offer any support here
Nice.

Quick Guide

Project: remove the passwords (etc) from secrets (etc), replace with placeholder
Laptop: generate values-file with command (run in project root):
faas-sdk init-values -y ./mypath/mydeployvalues.yaml
FaaS: deploy the project with configured values-file
xfsrt-cli faas project deploy -y ./mypath/mydeployvalues.yaml

Be the first to leave a comment
You must be Logged on to comment or reply to a post.