As an alternative to the JHipster Registry you can choose to use Consul, a datacenter management solution from Hashicorp. Compared to Eureka it has a number of advantages:
- It is easier to operate in a multi-node cluster than Eureka.
- It favors consistency over availability so changes in the state of your cluster are propagated more quickly.
- Consul service discovery can simply interoperate with existing applications through its DNS interface or HTTP API.
To get started with developing applications that rely on a Consul registry, you can start a Consul instance in a docker container:
docker-compose -f src/main/docker/consul.yml upto start a Consul server in
devmode. Consul will then be available on port
8500of your Docker host, so if it runs on your machine it should be at http://127.0.0.1:8500/.
You can also use the Docker Compose subgenerator to generate a docker configuration for several consul-enabled applications.
Application configuration with Consul
If you have chosen the Consul option when generating your JHipster microservice or gateway app, they will be automatically configured to retrieve their configuration from Consul’s Key/Value store.
The Key/Value (K/V) store can be modified using either its UI available at http://localhost:8500/v1/kv/ or its REST API. However changes made this way are temporary and will be lost on Consul server/cluster shutdown. So, in order to help you interact easily with the Key/Value store and manage your configuration as simple YAML files, the JHipster Team has developed a small tool: the consul-config-loader. The consul-config-loader is automatically configured when starting Consul from the
consul.yml docker-compose file but it can also be run as a standalone tool.
It can be run in two modes:
- a dev mode, where YAML files from the
central-server-configdirectory are automatically loaded into Consul. Moreover any change to this directory will be immediately synchronized with Consul.
- a prod mode, that uses Git2Consul to setup the YAML files contained in a Git repository as a configuration source for the Key/Value store.
Note that as with the JHipster Registry, your configuration files will need to be named
appname-profile.yml where appname and profile correspond to the application’s name and profile of the service that you want to configure. For example, adding properties in a
consulapp-prod.yml file will set those properties only for the application named
consulapp started with a
prod profile. Moreover, properties defined in
application.yml will be set for all your applications.