Pass deployment variables to service containers

[mguidon]

USER STORY

1. Some services require environment variables that are set on a deployment level. If so, these variables will be referenced on the image labels and initialized to something reasonable. These variables must be passed to both, computational and dynamic services.
2. Environment variables on the deployment can define/override certain behavior on services upon creation.

USE CASES

User case 1: Image Labels

• license servers, e.g. 27000@license.sim4life.com
  • sim4life
  • sim4life-lite
  • 3rd-party software
  • iSolve comp. service
• STUN/TURN servers, e.g. turn.sim4life.com
• Location of VIP models for sim4life
• Auto-save timeout for sim4life-lite
• location of data (e.g. for storing TI databases)

Use case 2: Creation

• Remove all elevated privileges unless the deployment defines that otherwise (e.g. cap_sys for debugging in vivo)

Use case 3: @colinRawlings

Taken from #3921 (comment)

This would be very helpful for crash reporting in s4l:web. In this use case we have a set of services:

• s4l-core (the backend)
• rt-web (the frontend)
• sym-server (the symbol server)

The sym-server holds the "sensitive" (in the sense that it indirectly exposes the source code) symbol database. When a crash occurs s4l-core's monitor application POST the binary .dmp file for analysis using the symbol database. Following analysis the callstack and metadata should be placed in an AWS SQS queue for later ingestion by the gitlab issue tracker. The sym-server obtains the details for the AWS queue from (3) environment variables.

As a (developer-)user I would like:

• A way to inject the "secret" environment variables for the queue into the service (this seems consistent with the vendor oenvs). This would avoid me having to add them in the code and allow me to replace all of them everywhere if a set of credentials was comprimised without changing the code or deployed version.

• A way to learn to augment the meta-data for each crash with the user info, platform info, ... (this seems consistent with the session oenvs)

Tasks

Preview Give feedback

1. ✨ Is3565/service environs substitution [part 1] (⚠️ devops) #3803
   a:models-library changelog:🎨enhancement +2
   
2. ✨ Vendor secrets and session oenvs (part 3) 🗃️ #3921
   a:database a:director-v2 a:models-library t:enhancement t:maintenance +5
   
3. ✨ Directorv2: adds current product_name in ScheduledData [part 2 of #3565] #3843
   a:director-v2 +1
   
4. ♻️ Renames osparc environments as osparc variables and secrets #4443
   a:webserver t:maintenance +2
   
5. ✨Computational backend: passing labels and envs 🗃️ #4429
   a:dask-service changelog:🎨enhancement +2
   
6. ✨Replace osparc variables in user services image labels (part 1) #4805
   a:director-v2 a:dynamic-sidecar +2
   

[GitHK]

Additional information:

• due to current request to block access to outgoing domains, we need a way to whitelist the content of the env vars for this services. Envoy proxy might be a solution for forwarding requests to DNS domains. See Dynamic forward proxy

[pcrespov]

Related with:

• Can define secrets and expose them as env vars on running services osparc-issues#764
• Auto generate API keys for a jupyter service lifetime #3526

[pcrespov]

NOTES:

• SEE https://git.speag.com/oSparc/osparc-s4l/-/blob/master/s4l-core/docker-compose-meta.yml#L29

[mguidon]

@pcrespov One more thing. It would be very useful to pass the information about whether the user is a tester or not (e.g. TESTER_MODE_ENABLED=1. That would allow me to enable/disable some settings only for testers, such as advanced video codec settings.

[pcrespov]

(⚠️ devops)

• Revert temporary changes done in staging until this PR is in ✨ Vendor secrets and session oenvs (part 3) 🗃️ #3921

[pcrespov]

SEE example in https://git.speag.com/oSparc/osparc-s4l/-/issues/609