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.
Levels
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.
Platform provided variables
DeltaBlue.Cloud provides a series of default variables.
- appRoot: The absolute path to the directory which contains all build & application code. (typically this is
/opt/approot) - currentRoot: The absolute path to the active application build directory (typically this is
/opt/approot/current), if applicable. - docRoot: The relative path to the web document root (typically this is
/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
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.
Application variables
The variables set at application level will be available in every stack item.
Typical examples:
- Database credentials
- Third party connection keys
- Application name
- Log level
- …
StackItem variables
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:
- PHP Max Execution Time
- Upload directory
- Slow pool enabled
- Number of retries
- …
Changing & Applying variables
Modifying variables takes 2 steps:
- Save: When saving variables, they become available for actions in scenarios, but they do not get deployed to your environment/application or stack item, so they can not yet be used by the application itself.
- Apply: Applying a variable will cause that variable to be (re)deployed, so that it can be used by the application. Bear in mind that if you write variables to your application using a scenario, you will have to re-run that scenario to rewrite your configuration with the new values.
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.
Access to variables
Via SSH
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
In your application
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.
In scenarios
Variables can be used as static values in scenarios and actions. This can be useful to generate a settings file or helpful during CI/CD workflows in your setup, build & deploy scenarios or any other actions 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.