faas-cli
faas-cli copied to clipboard
Specify an environment file to faas-cli deploy
Expected Behaviour
When a user of openfaas has two or more environments, and environment variables that are specific to each such as
Testing
environment:
db_host: "postgresql.svc.local"
db_port: "5432"
db_name: "defaultdb"
db_ssl_mode: "disable"
Staging
environment:
db_host: "todo-pg11-do-user-2197152-0.b.db.ondigitalocean.com"
db_port: "25060"
db_name: "defaultdb"
db_ssl_mode: "require"
They should have a mechanism to specify one set of environment variables or another.
Current Behaviour
Today we have the ability to add environment_file
to the stack.yml, but it can only contain a static list, which cannot be switched easily.
environment_file:
- staging.yaml
# - prod.yaml
Where the corresponding files contain the data required.
List All Possible Solutions and Workarounds
A workaround could be to use the env-var substitution support:
environment_file:
- ${$OPENFAAS_ENV:-staging}.yaml
Then run:
# Picks "prod.yaml"
OPENFAAS_ENV=prod faas-cli deploy
# Picks "staging.yaml"
OPENFAAS_ENV=prod faas-cli deploy
Which Solution Do You Recommend?
Either the work-around or adding a new flag to faas-cli deploy
of --environment-file
Context
I've seen various commercial users get confused here and end up building esoteric and complex tooling to apply overrides to their configuration files.
I also ran into this whilst working on the OpenFaaS add-on for Everyday Golang.
Env var subst in the stack.yaml has been in since April 2019, https://github.com/openfaas/faas-cli/pull/626
Its also in the docs https://docs.openfaas.com/reference/yaml/#yaml-environment-variable-substitution
Does this "solve" the issue or are there other options? We may need to make this option more obvious to users?
I mentioned env var substitution in my issue and gave an example of how to use it.
A workaround could be to use env-var substitution
(I was the one who added this feature originally: https://github.com/openfaas/faas-cli/commit/61f4670251e1d28658230967b64c40584f1b5b29)
The issue is that I am seeing users come up with complicated bespoke tooling to work around the non-obvious use of environment variable substitution.
In my case, this solution worked good because we had to build an script to build the functions and the script would not work with a single config file structure, we needed the ability to use multiple config files structures on each environment.
In a 'normal' scenario, I guess the en var subst would be the best approach.
@jgsamblas thanks for sharing. Can you explain why this approach wouldn't work for you, using concrete examples?
@alexellis, I'll try it.
Our platform allows you to build and run functions. You build it, upload the code and start using it (we use OpenFaas for this)
But we wanted the flexibility to specify the env vars for each of the functions so not all the functions share all the envs.
For example, if function A uses 3 envs and function B uses 7 envs. we wanted a specific template for A
environment-A-test.yml, environment-A-stg.yml, environment-A-prod.yml
and another one for B
environment-B-test.yml, environment-B-stg.yml, environment-B-prod.yml
Each function will contain its own template.
@alexellis , hi, can you review https://github.com/openfaas/faas-cli/pull/920, it may solve the issue
Hi @alexellis can you review https://github.com/openfaas/faas-cli/pull/921 too.
Thanks for this PR. Having reviewed the options and the demand, we've written up the workaround in more detail and will be advising users to follow that approach
https://www.openfaas.com/blog/custom-environments/