This application can be used to test Spring Cloud Config service connectivity by deploying it to a Cloud Foundry platform that has the Spring Cloud Services tile installed.
The demo application includes a deployment manifest that makes it simple to deploy the application.
Required
- Access to a foundation with Pivotal Application Service 2.6 or better installed
- and Pivotal Application Service account credentials
- e.g., an account on PCFOne should suffice
- and Pivotal Application Service account credentials
- Targeted foundation should have the Spring Cloud Services service tile installed and the service enabled in the
cf marketplace - The spring-cloud-services CF plugin installed
git clone https://github.com/pacphi/scs-sample.git
cd scs-sample
../gradlew assembleIf you're using PCFOne to demo, then
cf api api.run.pcfone.io
cf login --ssoFollow the link and authenticate via Workspace One. Use the token returned as your password.
Target an organization and space.
cf target -o {org} -s {space}Deploy
cf push --no-startBe aware that you may have to change the application name. You can override the one supplied in the manifest by adding a name, like so
cf push my-stuff --no-startIf you choose to do this, then make sure you replace all occurrences of
stuffbelow with the name you specified.
Create a Spring Cloud Config service instance and seed with initial configuration
cf create-service p.config-server standard mycs
cf config-server-add-credhub-secret mycs \
stuff/blue/master/stuff '{ "clouds": [ "Alibaba", "Digital Ocean", "Oracle" ], "languages": [ "Java", "Clojure", "PHP", "Rust" ] }'Note we are adding a secret stuff/blue/master/stuff which acts as a name space for key-value pairs in JSON. The name space consists of a spring.application.name, a profile activated in spring.profiles.active, a label, usually specifying a Git repository branch, and a secret name, usually the value of the prefix in a @ConfigurationProperties annotated model class (which defaults to the simple name of the class if no prefix attribute specified in the annotation). See Stuff.java.
Bind service instance to application, set the active profiles, trust certs, then startup the application
cf bind-service stuff mycs
cf set-env stuff SPRING_PROFILES_ACTIVE cloud,credhub,blue
cf set-env stuff TRUST_CERTS api.run.pcfone.io
cf start stuffIf you have curl, then
curl -k https://stuff.apps.pcfone.ioBetter yet, with httpie
http https://stuff.apps.pcfone.io
Edit the secret. In this case, we are removing then re-adding the secret above, but with a different JSON payload.
cf config-server-remove-credhub-secret mycs stuff/blue/master/stuff
cf config-server-add-credhub-secret mycs \
stuff/blue/master/stuff '{ "clouds": [ "AWS", "Azure", "GCP" ], "languages": [ "Javascript", "Go", "Kotlin", "Python" ] }'
cf restage stuffNote we'll take down time while we do this. We'll explore how to update configuration in a zero-down time fashion later on.
http https://stuff.apps.pcfone.iocf unbind-service stuff mycs
cf delete-service -f mycs
cf delete -r -f stuffLet's create a shared Spring Cloud Config Server service instance.
cf create-service p.config-server standard sccsLet's start with pushing a blue-version of the application, stamp it blue, add a secret to the service instance, bind it to the application and start the application.
cf push stuff-blue --random-route --no-start
cf set-env stuff-blue VERSION blue
cf set-env stuff-blue SPRING_PROFILES_ACTIVE cloud,credhub,blue
cf set-env stuff-blue TRUST_CERTS api.run.pcfone.io
cf bind-service stuff-blue sccs
cf config-server-add-credhub-secret sccs \
stuff/blue/master/stuff '{ "clouds": [ "Alibaba", "Digital Ocean", "Oracle" ], "languages": [ "Java", "Clojure", "PHP", "Rust" ] }'
cf start stuff-blueNext, we will map a shared host name stuff onto the same domain as the blue-version of the application as this will be the host name we will want users to visit to interact with the application.
BLUE_DOMAIN=$(cf app stuff-blue | grep routes | awk {'print $2'} | cut -d'.' -f 2,3,4,5,6)
echo $BLUE_DOMAIN
cf map-route stuff-blue $BLUE_DOMAIN --hostname stuffLet's test that the result of transacting the shared host name and domain matches what we expect in stuff-blue.json.
http https://stuff.apps.pcfone.ioLet's pretend that we've made an update to the implementation and/or the configuration and we want to roll-out the update without disruption. We'll push a green-version of the application, stamp it green, reuse the sccs service instance, add a secret, bind the service instance to the application and start the application.
cf push stuff-green --random-route --no-start
cf set-env stuff-green VERSION green
cf set-env stuff-green SPRING_PROFILES_ACTIVE cloud,credhub,green
cf set-env stuff-green TRUST_CERTS api.run.pcfone.io
cf config-server-add-credhub-secret sccs \
stuff/green/master/stuff '{ "clouds": [ "AWS", "Azure", "GCP" ], "languages": [ "Javascript", "Go", "Kotlin", "Python" ] }'
cf bind-service stuff-green sccs
cf start stuff-greenNext, let's map the aforementioned shared host name on the green-version of the application. When we do this, both applications will take on traffic at the shared host name and domain. Requests will be serviced in a random fashion from each versioned application.
GREEN_DOMAIN=$(cf app stuff-green | grep routes | awk {'print $2'} | cut -d'.' -f 2,3,4,5,6)
echo $GREEN_DOMAIN
cf map-route stuff-green $GREEN_DOMAIN --hostname stuffTo complete the cut over to the green-version of the application (and configuration) we will unmap the shared host name from the blue-version of the application (and configuration).
cf unmap-route stuff-blue $BLUE_DOMAIN --hostname stuffLet's test that the result of transacting the shared host name and domain matches what we expect in stuff-green.json.
http https://stuff.apps.pcfone.ioAt this point the blue-version of the application will no longer take on new requests at the shared host name and domain. You may decide to tear it down or roll back if there are noted issues with the green-version of the application (and configuration). Rolling back is as simple as re-mapping the shared host name to the blue-version of the application with the cf map-route command above. Then you could cf unmap-route the green-version of the application. Tearing down the blue-version is accomplished with:
cf unbind-service stuff-blue sccs
cf delete -r -f stuff-blueNote: if you don't want to allow direct public access to either the blue or green versions of the application you could swap --random-route with --no-route. However, the method we use above to obtain the domain would have to change. (But then you should already know the domain, shouldn't you, for the target foundation in your operating environment?)