Central Deployer Pattern
Kubes can be use as either an app-centric or ops-centric tool.
- app-centric: Each app repo has it’s own
.kubessettings files. This is useful if your applications are very differently setup.
- ops-centric: Each app repo has pretty much the same
.kubessettings files. This is useful if your applications are very similarly set up.
With an ops-centric approach, you use the same
.kubes settings files for the app repos you want to use. For example:
You then also have a
You can simply copy the
.kubes folder into the app repo folder or even add the
repo/.kubes as a submodule.
You’ll end up with something like this:
Then to deploy different app level settings.
App-Level Specific Settings
You can override all the different settings at the app-level when KUBES_APP is set.
cd app1 KUBES_APP=app1 kubes deploy
And for app2:
cd app2 KUBES_APP=app2 kubes deploy
config/app.rb with app-level settings like so:
.kubes/config/env/app1/base.rb .kubes/config/env/app1/dev.rb .kubes/config/env/app1/prod.rb .kubes/config/env/app2/base.rb .kubes/config/env/app2/dev.rb .kubes/config/env/app2/prod.rb
.kubes/variables/dev.rb etc like so:
.kubes/variables/app1/base.rb .kubes/variables/app1/dev.rb .kubes/variables/app1/prod.rb .kubes/variables/app2/base.rb .kubes/variables/app2/dev.rb .kubes/variables/app2/prod.rb
Override resources like so:
.kubes/resources/shared/config_map/app1.yaml .kubes/resources/shared/config_map/app2.yaml .kubes/resources/shared/secret/app1.yaml .kubes/resources/shared/secret/app2.yaml
Also check out: App Overrides Docs.
The central deployer approach is removes duplication of the kubes config files between projects. Leveraging app-level overrides gives provides a great degree of control.
If the settings start to diverge too much, then it probably makes sense to use separate .kubes files in that app specific repo.