Secrets & Configuration

Automatic configuration

For all applications, Coherence provides some automatic configuration into ENV variables. This includes setting the COHERENCE_ENVIRONMENT_DOMAIN to the URL for that environment, and setting the BRANCH_NAME, ENVIRONMENT_NAME and BUILT_AT times.

Based on configured resources, additional configuration such as DB_NAME, DB_PORT, DB_PASSWORD, REDIS_HOST are all configured as needed. These variables are listed on the "Configuration" section of the environment on your Coherence dashboard for each environment. Please note that for backend services on Cloud Run, we configure connections using the Cloud SQL Proxy which supports a socket path to the Cloud SQL instance rather than a network path (which is managed by the proxy sidecar). The Cloud SQL Proxy is used because it provides connection authentication using service accounts, encryption of the connection using short-lived keys managed by Google, and audit logging.

On workspaces, COHERENCE_DEV will be set to "true". This can be very useful to witch between a DB socket connection (used in review & production environments) and a TCP port, used in workspaces (on localhost).

Dev Workspace vs Review/Production Environment Config Example

Use an initializer where needed, and switch RAILS_ENV based on COHERENCE_DEV if you require config changes based on workspace vs review environments (or any other variable set by Coherence).

User-provided configuration

Coherence supports 2 kinds of configuration items: environment variables and configuration files.

Both types are mounted using cloud secrets where possible, managed interfaces such as kubernetes configitems as a second option, and raw values in configuration files (e.g. Key:Value pairs in YAML) as a last resort.

Where provided, a "service" option will scope the configuration to only containers for that service. Without a service, they'll mount to containers for all services.


Did this page help you?