Changing environment variables across multiple YAML file

[anubhabMajumdar]

Expected Behaviour

I have a unique problem, I couldn’t find anything online specific to this.
I am using environment variables to provide db-name and collection-name for mongoDB. I have multiple stack.yml files which injects db-name to multiple functions. This works great.
Now, here is the problem - let’s say I want to switch the DB from dev to test. One way is to manually change the stack.yml files, but that is not feasible as the project grows. I wish there is some central config file from which the stack.yml could read the db values, but I am not sure YAML supports it. Also, I though about creating something in kubernetes like secrets and let the function read it, but again, I am not sure that’s exactly what we want. It seems a hassle to change such variables deployed in Kubernetes every time.
Do you have some suggestion about this? Specifically:

• Is there some faas-cli commands that can be used for this scenario?
• If not, can some feature be added to address this?
• Is there some other workaround someone may suggest?

Your Environment

• FaaS-CLI version:

    CLI:
       commit:  dcddef2ae92880f50444103963408451abe82cc4
       version: 0.7.5

• We are using faas-netes.

[rgee0]

Following up on our conversation on Slack. Please investigate whether using an environment_file will help. Further info in the docs: https://docs.openfaas.com/reference/yaml/#function-environmental-variables.
I just tried this:

├── envFile.yml  
└── test
    ├── build
    ├── template
    ├── test
    └── test.yml

Contents of test.yml:

  environment_file:
      - ../envFile.yml

Contents of envFile.yml:

---
environment:
  test: testVal

Deploy it:

$ faas up -f test.yml

Exec into resulting container:

$ env
test=testVal
HOSTNAME=0fa7ec392dee
fprocess=./handler
SHLVL=1
HOME=/home/app
TERM=xterm
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
PWD=/home/app

[rgee0]

Derek add label: support

[anubhabMajumdar]

Thanks! I will discuss this with team members and get back to you.

[rgee0]

@anubhabMajumdar Can we assume that since there is no update this is no longer an issue and so can be closed?

[anubhabMajumdar]

Yes. Thank you. This worked out for our project.