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.
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 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"
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)
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:
- http://dsyerconfigserver.cfapps.io/customers/cloud
- http://dsyercustomers.cfapps.io/env
- http://dsyerstores.cfapps.io/env
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
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.