Notes for Environment Variables

Table of Contents

Introduction
Reading Notes
Using Environment Variables in YAML

Introduction

Environment variables are key to configure Infinite Scale. To understand variables in a proper way, some notes are made.

Reading Notes

Service name vs. environment variable name

Environment variable names are always upper case and words are connected with an underscore. They start with the name of the service. If the service name is more than one word and the words are connected with a dash, the dash is replaced by an underscore. This info is useful when you search for environment variables based on the service name.

Example: auth-basic → AUTH_BASIC_XXX

Global scale environment variables

Environment variables starting with OCIS_ are variables that have a global scope. This means, their setting is valid for all services, if not explicitly overwritten by a corresponding service variable.

Multiple environment variables for the same purpose

In the tables describing the environment variables, you may occasionally see two environment variables in the same row configuring the same task. In such a case, the following rule applies:

The first environment variable is used on a global scale. If set, it will be used in all services where applicable.
The second environment variable overwrites the first one, but ONLY for the one particular service.

Taking the webdav service as an example, you want to set the OCIS_URL as a generic value, but for webdav, you want to use a different URL defined with OCIS_PUBLIC_URL.

Default values containing curly brackets

In the table showing the environment variables of a service, the Default Value cell can sometimes contain values with curly brackets like {{.Id.OpaqueId}}. These are valid defaults.

Note on paths for binary vs. container installations

If a service offers path customization like the IDM_LDAPS_CERT (see the IDM documentation), the path set references the environment used. This means:

When using the binary installation, the path is based on the host filesystem.
When using a container installation, the path references a target inside the container.

If you’re using a container and want or need to keep all data persistent, you need to provide host filesystem access to the container, which you can do with mounts or volumes.

Using Environment Variables in YAML

Environment variables can be used in yaml config files. This allows them to be used in config files for Infinite Scale services, which will then be replaced by the actual value of the environment variable at runtime.

Example:

web:
  http:
    addr: ${SOME_HTTP_ADDR}

This makes it possible to use the same config file for different environments, without the need to change the config file itself. Such a setting is especially useful when using docker compose to run Infinite Scale services. It is a common pattern to create an .env file which contains the environment variables to be used with docker compose. Now you can use the same .env file to configure the Infinite Scale services via yaml.