Configuration Management Strategies
When building pipelines, there are many possible strategies for structuring your configuration in source control. No single method can cover all situations. After reading this document, we hope you feel equipped to select an approach.
Single Repository for Each Foundation
This is the simplest thing that could possibly work. It's the default assumed in all our examples, unless we've articulated a specific reason to choose a different approach. It entails using a single git repository for each foundation.
Tracking foundation changes are simple, getting started is easy, duplicating foundations is simply a matter of cloning a repository, and configuration files are not difficult to understand.
This is the strategy used throughout the Install Ops Man How to Guide and the Upgrading an Existing Ops Manager How to Guide. This is also the strategy implicit in our Pivotal Application Service reference pipeline.
The Pivotal Application Service reference pipeline is an example pipeline that can be used as a reference for your own foundation. Let's examine an example configuration repository that uses the "Single Repository for each Foundation" pattern:
1 2 3 4 5 6 7 8 9 10 11 12 13
Notice that there is only one subdirectory
and that all other files are at the repositories base directory.
This minimizes parameter mapping in the platform-automation tasks.
For example, in the
step in the reference pipeline:
1 2 3 4 5 6
we map the interpolated config files
to the expected input named
env of the
interpolated-creds is the output of a
whose input is a single foundation repo.
configure-director task's default
ENV parameter is
it automatically uses the
env.yml file in our configuration repo.
We do not need to explicitly name the
ENV parameter for the task.
This also works for
For reference, here is the
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40
Multiple Foundations with one Repository
Multiple foundations may use a single git configuration source but have different variables loaded from a foundation specific vars file, credhub, git repository, etc. This approach is very similar to the Single Repository for Each Foundation described above, except that variables are loaded in from external sources.
The variable source may be loaded in a number of ways. For example, it may be loaded from a separate foundation specific git repository, a foundation specific subdirectory in the configuration source, or even a foundation specific vars file found in the base git configuration.
This strategy can reduce the number of overall configuration files and configuration repositories in play, and can reduce foundation drift (as the basic configuration is being pulled from a single master source). However, configuration management and secrets handling can quickly become more challenging.
As our How To Guides expand, we will explore this strategy further. Stay tuned for more.