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.
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.
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.
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
spring.cloud.config.urimust point to
- In the
eureka.client.serviceUrl.defaultZonemust point to
- In the
- 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
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.