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.

Environment Variables

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 tasks 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

Keep in mind that if the SSH session is open and variables are changed in the platform, the ENV vars will **not** be automatically reloaded in your SSH session.

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 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.

variables-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.