Example Environment Layout - ocd-scm/ocd-meta GitHub Wiki

The demos show only a single react app. In practice, real systems will have multiple apps and many shared secrets. Here is an overview of how each of our environments is laid out:

.
|____envvars <-- one env var per application naming its version. these are updated via slackbot
|____ocd-post-apply-hook <-- slack announces update in progress then decrypts all secrets. 
|____secrets <-- all secrets are in this folder
| |____ocd-pre-apply-hook <-- md5 `oc get secrets` see gist link below. 
| |____xxx.yaml.secret <-- one encrypted yaml per secret
| |____yyy.yaml.secret
| |____zzz.yaml.secret
| |____helmfile.yaml <-- installs a release per secret
| |____ocd-post-apply-hook <--  if md5 `oc get secrets` has changed `oc rollout latest dc/*`
|____appone
| |____helmfile.yaml
| ____apptwo
| |____helmfile.yaml
| ____appthree
| |____helmfile.yaml
|____ocd-pre-apply-hook <- notifies slack channel of new app versions

Note: we are using git-secret and decrypting them with ocd-decrypt-secrets.sh but you can choose to use the helm secrets plugin of you so wish.

The logic behind the md5 hashing of oc get secrets is shown in this gist. The command oc get secrets outputs the age of each secret in either seconds, minutes, hours or days. If the md5 hash has changed the apps are bounced by rolling out the current deployment. Occasionally it will compute a false positive when the secrets haven't been refreshed recently due to secret having a mini-birthday. Secrets less than a minute old have a birthday every second so are highly likely to trigger a bounce. When all your secrets are more than a day old false positives will have a much lower probability.

In reality, each application folder has more content. For example, we have GPG encrypted the TLS keys and certs within each folder. We also have an ocd-post-apply-hook script in each folder that does a cowsay that the app has been updated to make scrolling through the logs faster when debugging.