support environment specific resources with environment specific overrides

[jstrachan]

some resources should not be distributed with your app's Kubernetes YAML (or OpenShift Template or Helm chart) and may be maintained separately & out of band in a per environment basis.

For Secrets folks may want to import them from something like Vault or some other file system. But for other things like ConfigMaps, Services (e.g. to point to external services via the Service.externalName) or Ingress/Route folks might want to keep all the different environmental data in the same git repo as the other resources to keep things consistent.

e.g. in Spring / Spring Boot worlds folks often have a profile and based on the profile (dev/test/prod etc) the code loads a different properties file with different configuration inside to point to different external services or use different configuration values etc.

So to replicate something like this - keeping all the environmental configuration in one place - we may want to have a simple mechanism in kedge for keeping track of whats environment specific and have a way to override values (data entries in ConfigMap/Secrets, or provide different resources for Service/Ingress/Route etc.

This just came up in a discussion on fabric8-maven-plugin: https://github.com/fabric8io/fabric8-maven-plugin/pull/1013#issuecomment-322802519 so thought I'd mention it here.

So firstly the top level app.yml file should be the application's yaml that can be used to deploy the app into any environment - we may want a folder that stores the environment specific stuff. e.g. maybe something like

my-project/
  app.yml  # the common app stuff for all envs
  environments/
    resources.yml # common environment specific resources
    dev/  
      resources.yml # overrides for the `dev` environment
    prod/
      resources.yml # overrides for the `prod` environment
    test/
      resources.yml # overrides for the `test` environment

so that the environments/resources.yml can define common resources for all environments if needed (e.g. common ConfigMap entries or default values) - then they can be overridden on a per environment bases. So for the prod environment anything in the environments/prod/resources.yml file overwrites whats in environments/resources.yml - such as to change an env var, entry in a ConfigMap/Secret or replace an Ingress/Route

e.g. folks may use different mechanism to load the data for Secrets from different files on the local file system for the different environments - then folks may have a tool to download Secret data from, say, Vault as part

[kadel]

@jstrachan can you also look at https://github.com/kedgeproject/kedge/issues/164? The idea behind that is that you have common environment specific resources together with your application, but if you want to deploy to the different environment you can use flag to switch environment specific resources. But It doesn't solve the issue how to define env specific resources in some uniform way.

I kind of like you idea of structuring it in separate directories.

[jstrachan]

gonna have a look at that issue.

One challenge is knowing if a resource is part of the app or a resource is part of the environment specific resources; e.g. a Service / ConfigMap / Secret / Ingress/Route could be in either; so putting it into the main app.yml may cause confusion; so I was thinking using separate files in a separate folder was cleanest

[jstrachan]

We should look at generating Service Catalog YAML to describe the environmental resources we need (e.g. a database, a secret, a ConfigMap with some key/value pairs inside etc).

Then the app can be deployed along with its 'service dependencies' which then get provisioned via the Service Catalog.

Though it might be nice to also be able to define the default implementations of those service dependencies (e.g. to have a default development implementation of a service or a dummy configuration / secret)