The spring-cloud-samples can be run as a demo locally by just cloning the individual projects and running them. This project can be used to manage updating and deploying the sample apps to cloudfoundry.

Running Locally

Pre-requisites: Maven (3) and Java (1.7). To run the Customers UI you also need the Spring Boot CLI. Clone the repository and initialize submodules:

$ git clone https://github.com/spring-cloud-samples/scripts
$ cd scripts
$ ./build.sh

(You can add `-DskipTests' if you like, or just use `./mvnw' directly, once the submodules are initialized. If you are starting from scratch, the build'' module needs to be installed first, followed by the starters''.)

You also nee Mongodb and RabbitMQ and Redis. If you don’t have those, and you do have Docker, you can run them in Docker (via docker-compose):

$ docker-compose up
...
<mongo starts up>
<rabbit starts up>
<redis starts up>

the containers for the server processes write their data locally in ./data_*. Those files will be owned by root, so watch out when it comes to remove them.

NOTE: Docker version 1.5 and Compose version 1.1.0 are confirmed to work. The latest versions have not been tested and may have problems.

Docker on a mac

Docker on a mac requires boot2docker. Because docker is running in a virtual machine, The ip addresses of mongo, rabbit and redis are not 127.0.0.1. You can use virtualbox port forwarding to address this issue with the following commands (from here):

# vm must be powered off
VBoxManage modifyvm "boot2docker-vm" --natpf1 "tcp-port27017,tcp,,27017,,27017"
VBoxManage modifyvm "boot2docker-vm" --natpf1 "tcp-port6379,tcp,,6379,,6379"
VBoxManage modifyvm "boot2docker-vm" --natpf1 "tcp-port15672,tcp,,15672,,15672"
VBoxManage modifyvm "boot2docker-vm" --natpf1 "tcp-port5672,tcp,,5672,,5672"

Docker alternative on a mac

If you prefer not to use docker-compose you can install mongo, rabbit and redis:

brew install mongodb rabbitmq redis

To run the apps (each in a different terminal)

$ rabbitmq-server
$ mongod --config /usr/local/etc/mongod.conf
$ redis-server /usr/local/etc/redis.conf

Run the apps:

$ ./run.sh

You can kill the processes using ./kill.sh, and both scripts know how to operate on individual apps or subsets, e.g. (the default):

$ ./run.sh configserver eureka customers stores

To run the UI with the maps, get the Spring Boot CLI, and install the platform CLI plugin, e.g. with GVM:

$ gvm install springboot 1.2.0.RC1
$ gvm use springboot 1.2.0.RC1

and finally install the Spring Cloud plugin:

$ spring install org.springframework.cloud:spring-cloud-cli:1.0.0.BUILD-SNAPSHOT

Then run the app

$ (cd customers-stores/customers-ui; spring run app.groovy)

Running on Cloud Foundry

Pre-requisites:

  • Maven (3)

  • Java (1.8)

  • the cf CLI

  • Cloud Foundry with Java buildpack version 2.5 or greater (for Java 1.8 support)

Clone the repository and initialize submodules:

$ git clone https://github.com/spring-cloud-samples/scripts
$ cd scripts
$ ./build.sh
$ ./services_deploy.sh
$ ./demo_deploy.sh

The result should be a bunch of apps running in the default space for your default org, with names prefixed by your local userid, e.g.

$ cf apps
...
dsyerconfigserver      started  1/1  512M  1G    dsyerconfigserver.cfapps.io
dsyereureka            started  1/1  512M  1G    dsyereureka.cfapps.io
dsyercustomers         started  1/1  512M  1G    dsyercustomers.cfapps.io
dsyerstores            started  1/1  512M  1G    dsyerstores.cfappps.io
...

The configserver and eureka apps will have been registered as user provided services, and bound to the other apps:

$ cf services
...
name                 service        plan  bound apps
dsyerconfigserver   user-provided        dsyercustomers, dsyereureka, dsyerstores
dsyereureka         user-provided        dsyerconfigserver, dsyercustomers, dsyerstores
...

You can check that it is all working by pinging the eureka app endpoints and seeing the other apps registered. E.g. visit http://dsyereureka.cfapps.io/eureka/apps in a browser. Other useful links for diagnosis and investigating what’s going on:

The stores app comes pre-populated with a Mongo database full of Starbucks locations. The customers app is empty to start (and uses an in-memory database) so you have to POST some data into it, e.g.

$ curl -i -H "Content-Type: application/json" http://dsyercustomers.cfapps.io/customers -d @customers-stores/rest-microservices-customers/src/test/resources/customers.json

Then when you visit the customers app at http://dsyercustomers.cfapps.io/customers you should see a customer (Ollie) and a link to nearby stores. If the stores app did not register with eureka, or if you stop the the stores app intentionally (cf stop …​), then the stores link will be missing in the customers app (simple example of a circuit breaker).

Sometimes it is also useful to undeploy the services (and unbind them from apps etc.), and redeploy them:

$ ./services_undeploy.sh
$ ./services_deploy.sh
$ ./demo_deploy.sh

It should all work on Pivotal Web Services, by default, or on any Cloudfoundry instance (e.g. PCF or a local single VM instance) if you set the DOMAIN environment variable to the DNS domain that the service is running in.

To run on bosh-lite

Deploy mongodb using https://github.com/cloudfoundry-community/cf-services-contrib-release

export DOMAIN=10.244.0.34.xip.io
export PLATFORM_HOME=/Users/sgibb/workspace/spring/spring-cloud-samples #where all spring-cloud-samples are checked out
export MONGO_URI=mongodb://192.168.50.1/stores #mongo running on host #TODO install mongo as a service

Build documentation

You can easily create the documentation for a particular release train using the release_train.sh script. You can run it in an interactive mode - then you’ll get prompted for all entries, or you can provide the values of the name of the release train together with the names and versions of modules. You can run ./release_train -h for more information.