Skip to content
Branch: master
Find file History
Permalink
Type Name Latest commit message Commit time
..
Failed to load latest commit information.
images
spring-cloud-gcp-pubsub-bus-config-sample-client Fix maven schema (#1874) Sep 11, 2019
spring-cloud-gcp-pubsub-bus-config-sample-server-github add git:// protocol to sample application properties, documentation (#… Oct 4, 2019
spring-cloud-gcp-pubsub-bus-config-sample-server-local Fix maven schema (#1874) Sep 11, 2019
spring-cloud-gcp-pubsub-bus-config-sample-test Fix maven schema (#1874) Sep 11, 2019
README.adoc add git:// protocol to sample application properties, documentation (#… Oct 4, 2019
pom.xml Fix maven schema (#1874) Sep 11, 2019

README.adoc

Spring Cloud Bus Configuration Management Demo

This code sample demonstrates automated configuration management using Spring Cloud Config, Spring Cloud Bus and GCP Pub/Sub. The sample app consists of a configuration server and a small web application that subscribes to the server to be notified of property changes.

Configuration server runs on port 8888, and can read configuration from a local filesystem (useful for exploring the sample) or from a source control system. When the server discovers (or is notified via /monitor HTTP endpoint) that new configuration is available, it fetches the updated configuration and broadcasts RefreshRemoteApplicationEvent via Spring Cloud Bus.

Under the hood, Spring Cloud Bus uses the Spring Cloud Stream binder for Cloud Pub/Sub to send a message to a topic named springCloudBus. To customize the topic used as a bus, use the spring.cloud.bus.destination property. If changing from the default, make sure that both server and client have the same value!

The client uses the same binder with an anonymous subscription to receive notifications, and provides an HTTP endpoint /message for printing the dynamically updated message value.

You may notice that there are two anonymous subscriptions to the springCloudBus topic when the sample applications are running — one is for the client application, and the other is for the server acting as a client. Technically, every configuration server happens to also be a configuration client, but configuration propagation is suppressed on the server by default. This is why every time configuration is updated, the server will print "Received remote refresh request. Keys refreshed []", indicating that it received the bus notification, but no configuration was updated.

Setup

  1. Configure your GCP project ID and credentials by following these instructions.

    Alternatively, if you have the Google Cloud SDK installed and initialized, and are logged in with application default credentials, Spring will auto-discover those parameters for you.

  2. Make sure that GCP Cloud Pub/Sub API is enabled, either through Google Cloud Console or with the following gcloud command:

    gcloud services enable pubsub.googleapis.com

Demo with local filesystem

Overview

Spring Cloud Config supports retrieving configuration from a local filesystem through a Spring Profile called native. It is already configured in the local server module (application.properties).

bus sample local

Running the demo

  1. Create a temporary directory /tmp/config (as configured by spring.cloud.config.server.native.searchLocations property in configuration server’s application.properties).

    mkdir /tmp/config
  2. In separate terminal windows, start the spring-cloud-gcp-pubsub-bus-config-sample-server-local and spring-cloud-gcp-pubsub-bus-config-sample-client applications:

    cd spring-cloud-gcp-samples/spring-cloud-gcp-pubsub-bus-config-sample
    mvn spring-boot:run -pl spring-cloud-gcp-pubsub-bus-config-sample-server-local
    cd spring-cloud-gcp-samples/spring-cloud-gcp-pubsub-bus-config-sample
    mvn spring-boot:run -pl spring-cloud-gcp-pubsub-bus-config-sample-client
  3. Visit the http://localhost:8080/message client endpoint in a browser; observe the default value of none printed on the page. This happens because there is no configuration available for config server yet.

  4. Write a file named application.properties containing example.message property value:

    echo 'example.message = message from the local filesystem' > /tmp/config/application.properties
  5. In the config server terminal, observe refresh activity such as Refresh for: * message.

    In the config client terminal, observe the refresh-scoped property updating: Received remote refresh request. Keys refreshed [example.message]. The config server terminal will print Received remote refresh request. Keys refreshed [] because while it is subscribed to the bus events, config servers suppress context refresh by default.

  6. Refresh http://localhost:8080/message client endpoint; observe the value now matches the value updated in the file system. The client application log will also reflect the change: Received remote refresh request. Keys refreshed [example.message].

Demo with GitHub

Overview

Keeping configuration in the local file system is simple, but not particularly useful — if the configuration were available on the same file system as the client application, it could just get it without having to maintain a configuration server. A more realistic scenario is keeping configuration under version control.

bus sample github

Running the demo

  1. In the root of a GitHub repository, create a file named application.properties containing the following line:

    example.message = message from GitHub
  2. In configuration server’s application.properties, set the value of spring.cloud.config.server.git.uri property to a valid repository URI (Git protocol for unauthenticated connection; HTTPS or SSH otherwise).

    If you opted for SSH, the keys stored in ~/.ssh should work automatically. If the key registered with GitHub is passphrase protected, set spring.cloud.config.server.git.passphrase property.

    If you opted for HTTPS, set spring.cloud.config.server.git.username and spring.cloud.config.server.git.password properties.

    Caution
    Never commit any passwords or passphrases into source control.
  3. In separate terminal windows, start the spring-cloud-gcp-pubsub-bus-config-sample-server-github and spring-cloud-gcp-pubsub-bus-config-sample-client applications:

    cd spring-cloud-gcp-samples/spring-cloud-gcp-pubsub-bus-config-sample
    mvn spring-boot:run -f spring-cloud-gcp-pubsub-bus-config-sample-server-github
    cd spring-cloud-gcp-samples/spring-cloud-gcp-pubsub-bus-config-sample
    mvn spring-boot:run -f spring-cloud-gcp-pubsub-bus-config-sample-client
  4. Visit http://localhost:8080/message client in a browser; observe the correct value, message from GitHub, printed on the page.

  5. Push an update to configuration stored in GitHub, setting the message to a new value.

  6. Notify the configuration server that new configuration is available. In a deployed server, this would be done automatically through a GitHub webhook.

    curl -X POST http://localhost:8888/monitor -H "X-Github-Event: push" -H "Content-Type: application/json" -d '{"commits": [{"modified": ["application.properties"]}]}'
  7. In the config server terminal, observe refresh activity such as Refresh for: * message.

    The config server terminal will also print Received remote refresh request. Keys refreshed [] because while it is subscribed to the bus events, config servers suppress context refresh by default.

    In the config client terminal, observe the refresh-scoped property updating: Received remote refresh request. Keys refreshed [example.message].

  8. Refresh http://localhost:8080/message client endpoint in a browser again; observe the value was updated.

You can’t perform that action at this time.