5 minute read
An introduction on the various options to manage variables!
Most applications will require some sort of settings; database or third party connection info, API keys, etc. These can vary, based on the environment or situation in which you run your application. Settings for a production environment are commonly not identical to those of a development environment. As these settings can contain sensitive information, it is advised to keep them out of your codebase ( and certainly out of GIT ). We wrote a short tutorial on how to do this in Java / Spring Boot applications.
To make your life easier, the DeltaBlue Cloud platform provides a simple way to manage variables and even has an export/import option to transfer variables between different environments or applications.
Variables live on four levels: platform, environment, application and stack item. Every level inherits all variables from its parent level and on all levels ( except Platform ), you can overwrite existing variables or add your own.
DeltaBlue.Cloud provides a series of default variables.
/opt/approot
)/opt/approot/current
), if applicable./opt/approot/current
), if applicable.More variables are added, based on how you configure your applications.
Platform variables are available on every environment, application and stack item.
Environment variables are mostly used to inform the applications on which environment they are running.
For example, the PHP Symfony framework provides a SYMFONY_ENV
property that you can set to prod
on all applications in an environment to ensure they all run in production mode.
The variables set at application level will be available in every stack item.
Typical examples:
A stack item represents a “selected technology” in your application. Examples: PHP, MySQL, Python, … but also full Operating systems like: Windows, Ubuntu, …
This is the lowest level of variables.
Typical examples:
Modifying variables takes 2 steps:
In case of name collisions, the values get overridden by the lowest defined variable. So the stack item-level variables override the application-provided variables, which override the environment-level variables, which will override the platform-provided variables.
When logged in via SSH, all the variables set via the platform will be available as system ENV vars.
Show a list of all system ENV vars by using the following command: printenv
You can reload the ENV variables in your SSH session by running the following snippet in your terminal: . /.victhorious/conf/shell/envvars
Each application language will access the system environment variables in a different way. Below you can find some popular application languages and how they use the system environment variables.
Variables can be used as static values in scenarios and tasks. This can be useful to generate a settings file or helpful during CI/CD workflows in your setup, build & deploy scenarios or any other tasks you wish to run via the platform.
When adding new variables there is an option to mark it as sensitive
. That flag will mark the variable to not be readable in the UI. The value of the variable will be masked and can be made visible by explicitly unmasking.