How do I set Pivotal Cloud Foundry environment variables for different environments in one manifest file?

Question

In Pivotal Cloud Foundry is there a way to have one Manifest.yml that has different environment variables for different environments. For instance we have a development/test/production environment. In system I want to have an environment variable "service=development.pcf.domain.com" and in test it should be "service=test.pcf.domain.com".

I would like to maintain one file and have all the environment variables in one manifest rather than have to remember which manifest file to pass for each environment.

In other words I dont want to have to have 3 files:

manifest_development.yml
-env: url=development.pcf.domain.com
manifest_test.yml
-env: url=test.pcf.domain.com
manifest_production.yml
-env: url=production.pcf.domain.com

I would rather have 1 file that defines all the environment variables and the correct one should be picked based on the environment the app is deployed on:

manifest.yml:
env-development: 
-url=development.pcf.domain.com
env-test: 
-url=test.pcf.domain.com
env-production: 
-url=production.pcf.domain.com

Answer 1

Have a look on "Multiple Manifests with Inheritance" part from https://docs.cloudfoundry.org/devguide/deploy-apps/manifest.html#multi-manifests, e.g.

---
inherit: base-manifest.yml
...

If possible is better to have all dependent services presented to the application via CF services/cups and the application obtaining environment dependent configuration by parsing VCAP_SERVICES environment variables avoiding per environment application configuration files.

Answer 2

The way I done this in the past is to leverage the flexibility of the pipelines.

I have used Jenkins, and Concourse.

Technically, you should only be deploying to development environment. All subsequent deployments should be done by a pipeline.

What I would do is, have a generic manifest file (generic-manifest.yml), with placeholders in it. I would create a copy of the file (manifest-local.yml). And that one would be used only for development environment.

In my pipeline, using some shell scripting, I generate the manifest.yml with right environmental details (integration, uat, prod etc).

I would have to maintain only one file - generic-manifest.yml. And as a rule, every-time I make changes to it, I would recreate the local manifest file.

Eventually, you can have pipeline for you development environment, in which case you will no longer need local manifest file.

I would take a step farther and say, everytime I have to develop a new microservice, I would first develop a shell class, it test class, and the next would be to develop a pipeline for that microsevice. That way, I no longer have to worry about pushing my microservice to cloud foundry.

First time you do it, it will be some work. But once you get into the habit, it becomes seamless.

Give it a try.

Answer 3

What i found was some clever chap already had spring_active_profiles set wirh env specific settings so i just had to create application-system.properties and use spring profiles