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 git
profiles from Spring Cloud Config.
As a result:
- Using the
dev
profile will run the JHipster Registry with thedev
and thenative
profiles. Thenative
profile will load the Spring Cloud configuration from the filesystem, looking for thecentral-config
directory, which is relative to the running directory. - Using the
prod
profile will run the JHipster Registry with theprod
and thegit
profiles. Thegit
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 thesrc/main/resources/config/bootstrap-prod.yml
file, or by reconfiguring thespring.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.
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) andyarn start
(for managing the front-end), it will use by default thedev
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 thedev
orprod
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 port8761
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 JHipsterdev
profile), and which uses the local filesystem. - A
Git
configuration, which is used by default in production (using the JHipsterprod
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’sapplication-*.yml
files, or add aSECURITY_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.