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
cfCLI -
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
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.