Sha256: b7710ad6a534fc55ccae8ff38de3ec40f74c5e6c138c5a0aeab8675f4165f0d4
Contents?: true
Size: 1.32 KB
Versions: 1
Compression:
Stored size: 1.32 KB
Contents
--- title: Central Deployer Pattern nav_text: Central Deployer categories: patterns --- Kubes can be use as either an app-centric or ops-centric tool. * **app-centric**: Each app repo has it's own `.kubes` settings files. This is useful if your applications are very differently setup. * **ops-centric**: Each app repo has pretty much the same `.kubes` settings files. This is useful if your applications are very similarly setup. ## Setup With an ops-centric approach, you use the same `.kubes` settings files for the app repos you want to use. For example: https://github.com/repo/app1 https://github.com/repo/app2 You then also have a https://github.com/repo/.kubes 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: app1/.kubes app2/.kubes Then to deploy different app level settings. {% include config/app-overrides-cheatsheet.md %} Also check out: [App Overrides Docs]({% link _docs/config/app-overrides.md %}). 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.
Version data entries
1 entries across 1 versions & 1 rubygems
Version | Path |
---|---|
kubes-0.8.1 | docs/_docs/patterns/central-deployer.md |