Site specific secrets and configuration

The recommendation is to store common configuration inline in the application specification and break out configuration and secrets into the Avassa built-in secrets manager, Strongbox.

Unique configuration per site

Create one specific vault per site to manage the specifics of that site, and let the application specification reference that.

As an example, let’s assume you have three sites:

• new-york
• london
• stockholm Create three vaults that are distributed to one site each, the naming convention in the example is config-<site-name>. For the New York site:

supctl create strongbox vaults <<EOF
name: config-new-york
distribute:
  sites:
    - new-york
EOF

Then create a secret in this vault:

supctl create strongbox vaults config-new-york secrets <<EOF
name: credentials
allow-image-access:
  - "*"
data:
  username: theuser
EOF

Now in your application specification you use the ${SYS_SITE} variable that will resolve to the site’s name on deployment

name: my-app
services:
  - name: my-svc
    variables:
      - name: username
        value-from-vault-secret:
          vault: config-${SYS_SITE}
          secret: credentials
          key: username

When deployed to the New York site, the username variable will be read from the credentials secret in the config-new-york vault.

The above technique can also be used for volume mounts and DNS.

Grouping site configuration

To have groups of sites receive the same configuration, create site labels for the sites. In this example we have region=europe and region=us on the sites.

Create two vaults:

• config-europe
• config-us

In the application spec, refer to these vaults:

application

name: my-app
services:
  - name: my-svc
    variables:
      - name: username
        value-from-vault-secret:
          vault: config-${SYS_SITE_LABELS[region]}
          secret: credentials
          key: username

Controlling configuration using site labels

note

Service replicas is just an example, please see the reference documentation for all places variables can be used.

In certain cases you may need a different number of replicas of a serivice, depending on the site.

A simple way of accomplishing this is to create a site label, e.g.

name: my-site
labels:
  popcorn-replicas: "2"
...

In the application specification we can now reference this label

name: popcorn-controller
version: "1.0"
services:
  - name: popcorn-controller-service
    mode: replicated
    replicas: ${SYS_SITE_LABELS[popcorn-replicas]}