The JHipster Registry

Overview

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.

Summary

Installation
Service discovery with Eureka
Application configuration with Spring Cloud Config
Administration dashboards
Securing the JHipster Registry

Installation

Spring profiles

The JHipster Registry uses the usual JHipster dev and prod Spring profiles, as well as the standard native and gitprofiles from Spring Cloud Config.

As a result:

Using the dev profile will run the JHipster Registry with the dev and the native profiles. The native profile will load the Spring Cloud configuration from the filesystem, looking for the central-config directory, which is relative to the running directory.
Using the prod profile will run the JHipster Registry with the prod and the git profiles. The git profile 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.yml file, or by reconfiguring the spring.cloud.config.server.git.uri Spring property.

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.

Building from source

The JHipster Registry can be cloned/forked/downloaded directly from jhipster/jhipster-registry, and we recommend you use the same version tag as the one you use for your JHipster generator. As the JHipster Registry is also a JHipster-generated application, you can run it like any other JHipster application:

run it with ./mvnw in development, it will use by default the dev profile and it will be available at http://127.0.0.1:8761/.
use ./mvnw -Pprod package to package it in production, and generate the usual JHipster executable WAR file. You can then run the WAR file using the dev or prod Spring profile, for example: ./jhipster-registry-3.0.0.war --spring.profiles.active=prod

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.

Using Docker

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:

run docker-compose -f src/main/docker/jhipster-registry.yml up to start the JHipster Registry. It will be available on port 8761 of 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.

Service discovery with Eureka

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

Application configuration with Spring Cloud Config

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:

A native configuration, which is used by default in development (using the JHipster dev profile), and which uses the local filesystem.
A Git configuration, which is used by default in production (using the JHipster prod profile), 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.

Administration dashboards

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 @Timed annotation)
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.

Securing the JHipster Registry

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-*.yml files, or add a SECURITY_USER_PASSWORD environment 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.