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