The JHipster Registry
The JHipster Registry is a runtime application, provided by the JHipster team. Like the JHipster generator, it is an Open Source, Apache 2-licensed application, and its source code is available on GitHub under the JHipster organization at jhipster/jhipster-registry.
The JHipster Registry has three main purposes:
- It is a an Eureka server, that serves as a discovery server for applications. This is how JHipster handles routing, load balancing and scalability for all applications.
- It is a Spring Cloud Config server, that provide runtime configuration to all applications.
- It is an administration server, with dashboards to monitor and manage applications.
All those features are packaged into one convenient application with a modern Angular-based user interface.
- Service discovery with Eureka
- Application configuration with Spring Cloud Config
- Administration dashboards
- Securing the JHipster Registry
The JHipster Registry uses the usual JHipster
prod Spring profiles, as well as the standard
gitprofiles from Spring Cloud Config.
As a result:
- Using the
devprofile will run the JHipster Registry with the
nativeprofile will load the Spring Cloud configuration from the filesystem, looking for the
central-configdirectory, which is relative to the running directory.
- Using the
prodprofile will run the JHipster Registry with the
gitprofile will load the Spring Cloud configuration from a Git repository, which is by default https://github.com/jhipster/jhipster-registry-sample-config. In a real-world usage, this repository should be changed, either by reconfiguring it in the
src/main/resources/config/bootstrap-prod.ymlfile, or by reconfiguring the
Once the JHipster Registry is running, you can check its configuration in the
Configuration > Cloud Config menu. Please note that if you can’t log in, it might be because the JWT signature key is not correctly set up, which is a sign that your configuration isn’t good.
Using the pre-packaged WAR file
The JHipster Registry is available as an executable WAR file on our Releases page.
Download the WAR file, and run it as a usual JHipster application, using the profile you want to use (see the previous section about profiles). For example:
./jhipster-registry-3.0.1.war --spring.profiles.active=prod --spring.cloud.config.server.git.uri=https://github.com/jhipster/jhipster-registry-sample-config
Building from source
The JHipster Registry can be cloned/forked/downloaded directly from jhipster/jhipster-registry. As the JHipster Registry is also a JHipster-generated application, you can run it like any other JHipster application:
- run it in development with
./mvnw(for the Java server) and
yarn start(for managing the front-end), it will use by default the
devprofile and it will be available at http://127.0.0.1:8761/.
./mvnw -Pprod packageto package it in production, and generate the usual JHipster executable WAR file. You can then run the WAR file using the
prodSpring profile, for example:
Please note that to use the
native profile, you need to have a
central-config directory with your configuration, so if you run
./jhipster-registry-3.0.0.war --spring.profiles.active=dev, you need to have that directory set up.
If you’d rather run the JHipster Registry from a Docker image, it is available an Docker Hub at jhipster/jhipster-registry. This image is already pre-configured in the Docker configuration that is provided with each microservice application:
docker-compose -f src/main/docker/jhipster-registry.yml upto start the JHipster Registry. It will be available on port
8761of your Docker host, so if it runs on your machine it should be at http://127.0.0.1:8761/.
Please read our Docker Compose documentation for more information on using the JHipster Registry with Docker Compose.
Running in the cloud
It’s very easy to host a JHipster Registry instance in the cloud. This is mandatory in production, but this can also be useful in development (there is no need to run it on your laptop).
Please read the “microservices in production” documentation to learn how to deploy the JHipster Registry to Cloud Foundry or to Heroku.
The JHipster Registry is a Netflix Eureka server, that provides service discovery for all applications.
- This is very useful for microservices architectures: this is how the gateways know which microservices are available, and which instances are up
- For all applications, including monoliths, this is how the Hazelcast distributed cache can automatically scale, see the Hazelcast cache documentation
The JHipster Registry is a Spring Config Server: when applications are launched they will first connect to the JHipster Registry to get their configuration. This is true for both gateways and microservices.
This configuration is a Spring Boot configuration, like the one found in the JHipster
application-*.yml files, but it is stored in a central server, so it is easier to manage.
On startup, your gateways and microservices app will query the Registry’s config server and overwrite their local properties with the ones defined there.
Two kinds of configurations sources are available:
nativeconfiguration, which is used by default in development (using the JHipster
devprofile), and which uses the local filesystem.
Gitconfiguration, which is used by default in production (using the JHipster
prodprofile), and which stores the configuration in a Git server. This allows to tag, branch or rollback configurations using the usual Git tools, which are very powerful in this use-case.
To manage your centralized configuration you just need to add
appname-profile.yml files in your configuration source where appname and profile correspond to the application’s name and current profile of the service that you want to configure.
For example, adding properties in a
gateway-prod.yml file will set those properties only for the application named gateway started with a prod profile. Moreover, properties defined in
application[-dev|prod].yml will be set for all your applications.
As the Gateway routes are configured using Spring Boot, they can also be managed using the Spring Config Server, for example you could map application
app1-v1 to the
/app1 URL in your
v1 branch, and map application
app1-v2 to the
/app1 URL in your
v2 branch. This is a good way of upgrading microservices without any downtime for end-users.
The JHipster Registry provides administration dashboards, which are used for all application types. As soon as an application registers on the Eureka server, it will become available in the dashboards.
In order to access sensitive information from the applications, the JHipster Registry will use a JWT token (this is why the JHipster Registry only works for applications using JWT). The JWT key used to sign the request should be the same for the applications and the JHipster Registry: as by default the JHipster Registry configures applications through Spring Cloud Config, this should work out-of-the-box, as it will send the same key to all applications.
The metrics dashboard
The metrics dashboard uses Dropwizard metrics to give a detailed view of the application performance.
It gives metrics on:
- the JVM
- HTTP requests
- methods used in Spring Beans (using the
- database connection pool
By clicking on the eye next to the JVM thread metrics, you will get a stacktrace of the running application, which is very useful to find out blocked threads.
The health dashboard
The health dashboard uses Spring Boot Actuator’s health endpoint to give health information on various parts of the application. Many health checks are provided out-of-the-box by Spring Boot Actuator, and it’s also very easy to add application-specific health checks.
The configuration dashboard
The configuration dashboard uses Spring Boot Actuator’s configuration endpoint to give a full view of the Spring configuration of the current application.
The logs dashboard
The logs dashboard allows to manage at runtime the Logback configuration of the running application. Changing the log level of a Java package is as simple as clicking on a button, which is very convenient both in development and in production.
The JHipster Registry is secured by default. You can login using the usual “admin/admin” login and password that are used in normal JHipster applications.
Applications also connect to the JHipster Registry using that same “admin” user, but use HTTP Basic authentication. So if your microservices cannot access the registry, and you see some “401 authentication error” messages, it is because you have misconfigured those applications.
In order to secure your JHipster Registry:
- You must change the default “admin” password. This password is set using the standard Spring Boot property
security.user.password, so you can use the usual Spring Boot mechanisms to modify it: you could modify the project’s
application-*.ymlfiles, or add a
SECURITY_USER_PASSWORDenvironment variable. The Docker Compose sub-generator uses the environment variable method.
- As your applications will connect to the registry using HTTP, it is very important to secure that connection channel. There are many ways to do it, and the easiest one is probably to use HTTPS.