Microservices in production

Microservices monitoring

Please refer to our JHipster Registry documentation for learning which runtime dashboards are available, and how to use them.

Our monitoring documentation is also very important, to learn specific information on using:

The JHipster Console to use ELK with your microservices architecture
Zipkin to trace HTTP requests throughout your services
Elastalert to get alerted when an issue occurs

When using the Docker-Compose sub-generator, you will be asked if you want to add monitoring to your infrastructure. This option will add the JHipster Console to your docker-compose.yml file. Once started, it will be available on http://localhost:5601 and start to gather your applications’ logs and metrics.

For gateways and microservices applications, additional features are provided to help you effectively monitor a microservices cluster. For example logs are enriched with each application’s name, host, port and Eureka/Consul ServiceId so that you can trace from which service instance they are originating from. The JHipster Console also comes with default dashboards that give you an overview of all your services metrics.

Using Docker Compose to develop and deploy

Working on a microservices architecture means you will need several different services and databases working together, and in that context Docker Compose is a great tool to manage your development, testing and production environments.

A specific section on microservices is included in our Docker Compose documentation, and we highly recommend that you get familiar with it when working on a microservices architecture.

As Docker Swarm uses the same API as Docker Machine, deploying your microservices architecture in the cloud is exactly the same as deploying it on your local machine. Follow our Docker Compose documentation to learn more about using Docker Compose with JHipster.

Going to production with Cloud Foundry

The Cloud Foundry sub-generator works the same with a microservices architecture, the main difference is that you have more applications to deploy:

Use the Cloud Foundry sub-generator to deploy first the JHipster Registry (which is a normal JHipster application).
Note the URL on which your JHipster Registry is deployed. Your applications must all point to that URL:
- In the bootstrap-prod.yml file, the spring.cloud.config.uri must point to http(s)://<your_jhipster_registry_url>/config/
- In the application-prod.yml file, the eureka.client.serviceUrl.defaultZone must point to http(s)://<your_jhipster_registry_url>/eureka/
Deploy your gateway(s) and microservices
Scale your applications as usual with Cloud Foundry

One important point to remember is that the JHipster Registry isn’t secured by default, and that the microservices are not supposed to be accessible from the outside world, as users are supposed to use the gateway(s) to access your application.

Two solutions are available to solve this issue:

Secure your Cloud Foundry using specific routes.
Keep everything public, but use HTTPS everywhere, and secure your JHipster Registry using Spring Security’s basic authentication support

Going to production with Heroku

The Heroku sub-generator works nearly the same with a microservices architecture, the main difference is that you have more applications to deploy:

Deploy a JHipster Registry directly with one click:

Please follow the Heroku sub-generator documentation in order to understand how to secure your JHipster Registry.

Note the URL on which your JHipster Registry is deployed. Your applications must all point to that URL in their application-prod.yml file. Change that configuration to be:

eureka:
    instance:
        hostname: https://admin:[password]@[appname].herokuapp.com
        prefer-ip-address: false

You can now deploy and scale the gateway(s) and microservices. The Heroku sub-generator will ask you a new question, to know the URL of your JHipster Registry: this will allow your applications to fetch their configuration on the Spring Cloud Config server.