Writing Function-as-a-Service : 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 Serverless Runtime
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
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
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
Now we only need to go through a silly example to learn how to do it
Note that this tutorial is only possible for local development, such that it is a
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
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
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
faas-sdk init-values –deploy-values <yourFilePath>
We can use abbreviation -y
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”
“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
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
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
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
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