In some scenarios (e.g. some Docker deployments) it is preferable to use the environment to emulate profiles.
Instead of creating a profile properties file, the environment can be used to change which modules are enabled. For every application parameter, an environment variable can be set; use all caps and replace punctuation with underscores.
E.g. "IAM_MODULES=loginapp" in the environment can be used to override the "iam.modules" parameter from the instance.properties file.
Creating Profiles
A profile is a .properties file in the profiles/ directory that overrides some of the application parameters defined in instance.properties.
To create a new profile named "external", a new file named external.properties must be created. The contents of a profile configuration file is similar to instance.properties.
For example:
instances/auth/profiles/external.properties
# The external profile only launches Loginapp iam.modules = loginapp
instances/auth/profiles/internal.properties
# The internal profile only launches Adminapp and the service container applications iam.modules = adminapp, service-container
Having created these files, we can say that the instance "auth" now has two different launch profiles. Profiles are primarily applied when launching Airlock IAM. You will note that many CLI commands do not include an option where a profile can be specified.
If a profile exposed to the internet, for example a Loginapp, does not require access to some secrets, consider using a separate sensitive value store.
For integration and test environments, Configuration environments can be used to limit the exposure of production secrets.