There are a variety of ways to install Spring Cloud CLI, and you can find all of them here.
The easiest way, however, is to use Homebrew (requires a Mac environment).
Using Homebrew simply execute these few commands:
$ brew tap pivotal/tap
$ brew install springboot
This installs the Spring Boot CLI. After that, you need to install the Spring Cloud CLI plugin like this:
$ spring install org.springframework.cloud:spring-cloud-cli:2.1.0.RELEASE
To check the installed Spring Boot CLI version and the available Spring Cloud services you can start up locally, run the following commands:
$ spring version # print the version of the Spring Boot CLI
$ spring cloud --list # print the available services you can start with Spring Cloud CLI
To bring up a service via the CLI, you can type:
$ spring cloud eureka # bring up a Eureka service registry locally.
For more information see the Spring Cloud CLI documentation.
Many of the services of this project use Spring Cloud Sleuth](https://spring.io/projects/spring-cloud-sleuth) with an integration with Zipkin to write trace logs in order to trace requests analyce latencies.
Trace logs generated by a service are sent to a Zipkin server instance expected to be running (by default) on http://localhost:9411/zipkin. The easiest way to run a Zipkin server is to use Docker:
docker run -p 9411:9411 --name zipkinServer openzipkin/zipkin
... or ...
./scripts/startZipkin.sh
This will pull and start a Zipkin server container and once it is started you can access its UI using the link http://localhost:9411/zipkin.
As services will be making requests and logging traces, you will see them in the Zipkin UI. This allows you not only to see which requests are being sent and received but also how long they took and if they were successful or not.
Note, that Spring Cloud Sleuth and Zipkin also work for message-based communication, e.g. using RabbitMQ. See the Spring Cloud Sleuth](https://cloud.spring.io/spring-cloud-static/spring-cloud-sleuth/2.1.3.RELEASE/single/spring-cloud-sleuth.html#_sleuth_with_zipkin_over_rabbitmq_or_kafka) documentation for details.
docker run -d --hostname my-rabbit --name rabbitBroker -p 15672:15672 -p 5672:5672 rabbitmq:3-management
... or ...
./scripts/startRabbit.sh
Once started you can access its UI using http://localhost:15672/#/.
Username: guest, password: guest.
Required startup order (ideally):
- Zipkin server
- RabbitMQ
- service-registry
- config-server instances
- services (i.e. service-registry clients)
For 1. - 3. the order does not really matter. They can be started in any order and will find one another. Services need to be started last, as they will require configuration for startup coming from the config-server.
This project was created with Spring Cloud Config Server using the following dependencies:
- Config Server
- Zipkin Client
- Eureka Discovery Client
- Spring Boot Actuator
- Cloud Bus (Adds
spring-cloud-bus
) - Spring for RabbitMQ (adds
spring-boot-starter-amqp
, andspring-cloud-stream-binder-rabbit
for Spring Cloud Bus)
Project config-server
is a Spring Boot application that acts as a central configuration server.
It uses Spring Cloud Config Server to serve configurations that are stored in a GitHub repository.
- Has its own configurations (not loaded from github)
- Uses Zipkin / Sleuth to report tracing information.
- Is a Eureka client, i.e. registers itself with service registry.
- Services find / lookup config-server via Eureka.
- Allows more than one config-server instances to run and be addressed by one logical service name.
- config-server (and all its potential instances) need to start before any service that reads configuration is started. (See this Spring Cloud Config issue.)
- Configs are loaded using the following URL pattern
/{name}/{profile}/{label}
where- name: service ID
- profile: active spring profile
- label: usually
master
but can be any git tag, commit ID or branch name. - see Spring Cloud Config and Locating Remote Configuration Resources
- Uses Spring Cloud Bus, RabbitMQ and Spring Cloud Config Monitor to expose an
/monitor
endpoint which can be registered as a GitHub WebHook. Every time the configuration changes in GitHub, GitHub sends an event to the/monitor
endpoint. The controller behind the/monitor
endpoint fires a refresh event via the Spring Cloud Bus (using RabbitMQ as the signalling layer), BUT: only to the service instances that are affected by the change in GitHub (based on Eureka service registry). Services refresh automatically with changes in the configurations being pushed to GitHub! - Exposes http://localhost:1111/actuator/bus-refresh endpoint, to refresh all services on the bus at once. See also: http://localhost:1111/actuator/bus-env where you could post key-value pairs to add to every service's environment. See also addressing of individual service instance.
- Use http://smee.io to forward WebHook events to localhost.
Update files, push to GitHub, then refresh services that need updated configs.
Actuator endpoints:
- For debugging:
/actuator/env
and/actuator/health
- For Refreshing:
/actuator/refresh
- POST only. Send empty POST request. Receive list of changed properties (delta) after refresh.
This project was created with Spring Cloud Config Server using the following dependencies:
- Eureka Server
- Config Client
- Zipkin Client
- Spring Boot Actuator
- Currently does not use configs from config-server but brings its own.
- Startup is independent from config-server
This project was created with Spring Cloud Config Server using the following dependencies:
- Spring Reactive Web
- Rest Repositories
- Cloud Bus (Adds
spring-cloud-bus
) - Spring for RabbitMQ (adds
spring-boot-starter-amqp
, andspring-cloud-stream-binder-rabbit
for Spring Cloud Bus) - Spring Data JPA
- H2 Database
- Config Client
- Zipkin Client
- Eureka Discovery Client
- Spring Boot Actuator
- RSocket
This project was created with Spring Cloud Config Server using the following dependencies:
- Eureka Discovery Client
- Zipkin Client
- Spring Boot Starter Web
- Spring Boot Actuator
Additionally references WebJars to provide static UI content.
- Protocol: RSocket | FAQ | Motivation | Github Repos
- Gateway: Spring Cloud Gateway
- Configs: Spring Cloud Config Server in combination with Git | Spring Cloud Bus
- Testing: Spring Cloud Contract
- Development: Spring Cloud CLI
- Tracing: Spring Cloud Sleuth / Zipkin | Tutorial | Baeldung Tutorial | Video
- Pipelines: Cloud Pipelines | Why the migration
- Data Access: Spring Data
- REST Docs: Spring REST Docs
- Secure Password Storage: Spring Vault | Vault | Vault Docker Image
- Beginner's guide to Spring Cloud | Github Repo
- Building Micro-Services with Spring Cloud (great video) | GitHub Repository
- Reactive Databases
- Aeron Protocol | Blog Post
- RSocket and Spring Cloud Gateway | Older Presentation
- Spring Cloud Gateway RSocket Sample
- Living on the Edge: Spring Cloud Gateway (Interesting approach to exposing the Gateway as a Service (broker)!)
- Spring Tips: Spring Cloud Gateway
- Distributed Reactive Streams with RSocket, Reactor, and Spring (great video)
- Netifi | Docs | Netifi Broker vs. Spring Cloud Gateway | Youtube Channel | Motivation | Spring Demo Repo
- Understanding Reactive Types
- Reactive Streams
- Project Reactor
- RxJava
- Spring Boot CLI Installation
- Distributed Tracing with Zipkin
- Open Tracing Initiative
- Spring Cloud Bus | Baeldung Tutorial
- RSocket Support in Spring 5.2 (the basis for Spring Boot RSocket support)
- RSocket Support in Spring Boot 2.2
- RSocket Support in Spring Security
- 101 Reactive Gems
- Notes on Reactive Programming (Part 1) - The Reactive Landscape | Notes on Reactive Programming (Part 2) - Writing Some Code