Improve this page

Microservices in production Permalink to " Microservices in production"

Microservices are a specific kind of JHipster applications. Please refer to our main Using JHipster in production documentation for more information on doing a production build, optimizing it and securing it.

Microservices monitoring Permalink to "Microservices monitoring"

If using JHipster Registry, 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:

  • ELK to collect the logs of your microservices
  • Prometheus to collect the metrics of your microservices
  • Zipkin to trace HTTP requests throughout your services

Using Docker Compose to develop and deploy Permalink to "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 Permalink to "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 Permalink to "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:

Deploy to Heroku

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.