Using JHipster in production Permalink to " Using JHipster in production"
JHipster generates a fully production-ready, optimized and secured application. This section describes the more important options - if you are in hurry, run a normal production build, but don’t forget to read the security section!
Building a production package Permalink to "Building a production package"
Testing a production build Permalink to "Testing a production build"
This allows to test a production build from Maven, without building a real package.
To use JHipster in “production” mode, use the pre-configured prod
profile. With Maven, please run:
./mvnw -Pprod
When using Gradle, please run:
./gradlew -Pprod
This profile will compile, test and package your application with all productions settings.
If you want more information on the available profiles, please go the section titled “Development and Production profiles”.
Building an executable JAR / WAR file Permalink to "Building an executable JAR / WAR file"
With Maven Permalink to "With Maven"
-
To package the application as a “production” JAR, please type:
./mvnw -Pprod clean verify
This will generate a file
target/jhipster-0.0.1-SNAPSHOT.jar
(if your application is called “jhipster”). -
To package the application as a “production” WAR:
- Modify the
pom.xml
to change the application packaging towar
like:
- <packaging>jar</packaging> + <packaging>war</packaging>
- Modify the
pom.xml
to change the scope ofspring-boot-starter-undertow
dependency toprovided
like:
<id>prod</id> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-undertow</artifactId> + <scope>provided</scope> </dependency> </dependencies>
- To generate an executable
war
along the originalwar
, type command:
./mvnw -Pprod clean verify
-
This will generate these files (if your application is called “jhipster”):
target/jhipster-0.0.1-SNAPSHOT.war
target/jhipster-0.0.1-SNAPSHOT.war.original
- Modify the
Please note that when building a JAR or WAR file with the prod
profile, the generated archive will not include the dev
assets.
With Gradle Permalink to "With Gradle"
To package the application as a “production” JAR, please type:
./gradlew -Pprod clean bootJar
This will generate a file build/libs/jhipster-0.0.1-SNAPSHOT.jar
(if your application is called “jhipster”).
To package the application as a “production” WAR, please type:
./gradlew -Pprod -Pwar clean bootWar
Running in production Permalink to "Running in production"
Executing the JAR file without an application server Permalink to "Executing the JAR file without an application server"
Instead of deploying to an application server, many people find it easier to have a single executable JAR file.
With the JAR file generated in the previous step, you can run it in “production” mode by typing (on Mac OS X or Linux):
./jhipster-0.0.1-SNAPSHOT.jar
If you are on Windows, use:
java -jar jhipster-0.0.1-SNAPSHOT.jar
Please note that this JAR file uses the profile we selected when building it. As it was built using the prod
file in the previous section, it will therefore run with the prod
profile.
Running the application in a Docker container Permalink to "Running the application in a Docker container"
JHipster has first-class support for Docker: it bundles your executable JAR file in a Docker image, and run it inside Docker.
To learn how to package your application with Docker, please read our Docker Compose documentation.
Run as a service Permalink to "Run as a service"
It is also possible to run the Jar as a Linux service, and you may want to force in your pom.xml
file before packaging. To do it, add the following property inside <configuration>
of spring-boot-maven-plugin
plugin.
<embeddedLaunchScriptProperties>
<mode>service</mode>
</embeddedLaunchScriptProperties>
Next, setup your init.d with:
ln -s jhipster-0.0.1-SNAPSHOT.jar /etc/init.d/jhipster
Secure your application with:
chown jhuser:jhuser jhipster-0.0.1-SNAPSHOT.jar
sudo chattr +i your-app.jar
Considering jhuser
a non-root OS account that will run the application, then the application can be run this way:
service jhipster start|stop|restart
There are many other options that you can find in Spring Boot documentation, including more security steps and Windows service.
Performance optimizations Permalink to "Performance optimizations"
Cache tuning Permalink to "Cache tuning"
If you selected a cache provider when generating your application, it has been automatically configured for you by JHipster.
However, the default cache values are quite low, so the application can run on modest hardware, and as those values should be tuned depending on your application’s specific business requirements.
Please read:
- The JHipster “using cache” documentation to learn more about the caching provider you have selected, and how it can be tuned
- The last section on monitoring, so you can fine-tune your cache according to your application’s real-world usage
HTTP/2 support Permalink to "HTTP/2 support"
JHipster supports HTTP/2 using the jhipster.http.version
property, which is configured in the application-prod.yml
file.
To enable HTTP/2, you need to:
- Set
jhipster.http.version: V_2_0
- Configure HTTPS (see this documentation’s security section), as browsers force to use HTTPS with HTTP/2
GZipping Permalink to "GZipping"
Within an executable JAR file, which uses the prod
profile, JHipster configures GZip compression on your Web resources.
By default, compression will work on all static resources (HTML, CSS, JavaScript) and on all REST requests. You can have more information on this configuration by looking at the server.compression.*
keys in the Spring Boot application properties, configured in the application-prod.yml
file.
Please note that GZipping is done by the application server, so this section only applies if you use the “executable JAR” option described above. If you run your application in an external application server, you will need to configure it separately.
Cache headers Permalink to "Cache headers"
With the prod
profile, JHipster configures a Servlet filter that puts specific HTTP cache headers on your static resources (JavaScript, CSS, fonts…) so they are cached by browsers and proxies.
Generating an optimized JavaScript application with Webpack Permalink to "Generating an optimized JavaScript application with Webpack"
This step is automatically triggered when you build your project with the prod
profile. If you want to run it without launching a Maven build, please run:
npm run build
This will use Webpack to process all your static resources (CSS, TypeScript, HTML, JavaScript, images…) in order to generate an optimized client-side application.
During this process, Webpack will compile the TypeScript code into JavaScript code, and will also generate source maps, so the client-side application can still be debugged.
Those optimized assets will be generated in target/classes/static
for Maven or build/resources/main/static
for Gradle, and will be included in your final production JAR.
This code will be served when you run the application with the prod
profile.
Security Permalink to "Security"
Securing the default user and admin accounts Permalink to "Securing the default user and admin accounts"
JHipster comes with some default users generated for you. In production, you should change those default passwords!
Please follow our security documentation to learn how to change those passwords, and secure your application.
HTTPS support Permalink to "HTTPS support"
HTTPS can be configured directly in your JHipster application, or using a specific front-end proxy.
HTTPS configuration with JHipster Permalink to "HTTPS configuration with JHipster"
HTTPS is configured using Spring Security’s standard server.ssl
configuration keys in your application-prod.yml
file.
To enable SSL, generate a certificate using:
keytool -genkey -alias <your-application> -storetype PKCS12 -keyalg RSA -keysize 2048 -keystore keystore.p12 -validity 3650
You can also use Let’s Encrypt using this tutorial.
Then, modify the server.ssl
properties so your application-prod.yml
configuration looks like:
server:
port: 443
ssl:
key-store: keystore.p12
key-store-password: <your-password>
keyStoreType: PKCS12
keyAlias: <your-application>
ciphers: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
enabled-protocols: TLSv1.2
The ciphers suite enforce the security by deactivating some old and deprecated SSL ciphers, this list was tested against SSL Labs
Once server.ssl.ciphers
property is enabled JHipster will force the order on Undertow with this property (true by default) : jhipster.http.useUndertowUserCipherSuitesOrder
The enabled-protocols
deactivate old SSL protocols.
Then, the final touch for achieving the perfect forward secrecy. Add the following flag at the JVM startup :
-Djdk.tls.ephemeralDHKeySize=2048
For testing your configuration you can go to SSL Labs.
If everything is OK, you will get A+
HTTPS configuration with a front-end proxy Permalink to "HTTPS configuration with a front-end proxy"
There are many solutions to setup a front-end HTTPS proxy in front of a JHipster application.
One of the most common solution would be to use the Apache HTTP server, you can set it up with Let’s Encrypt:
- Install Apache and Let’s Encrypt:
apt-get install -y apache2 python-certbot-apache
- Configure Let’s Encrypt:
certbot --apache -d <your-domain.com> --agree-tos -m <your-email> --redirect
- Configure auto-renewal of SSL certificates: add
10 3 * * * /usr/bin/certbot renew --quiet
in your crontab
Custom Context Path Permalink to "Custom Context Path"
You can specify a context path for your Spring Boot backend by passing in a server.servlet.context-path
parameter and value:
java -jar jhipster.jar --server.servlet.context-path=/jhipster/
Or, you can add this configuration to application.yml
:
---
server:
servlet:
context-path: /jhipster/
For frontend bundlers, the context path is a build-time configuration.
Angular frontends can be configured using:
angular.json
:projects -> * your project name -> architect -> build -> options -> baseHref : '/jhipster/'
ng build --base-href '/jhipster/'
- Use APP_BASE_HREF
For Webpack-based frontends, you can configure using:
- Webpack configuration file:
new HtmlWebpackPlugin({ ... base: '/jhipster/' })
Others modifications may be necessary, like configuring your development server and adjusting iframes in pages like swagger-ui.
Please note that using a relative base path like ./
is possible, but you must adjust other configurations to be compatible with it.
Monitoring Permalink to "Monitoring"
JHipster comes with full monitoring support from Micrometer.
In development, Metrics data will be available through JMX: launch your JConsole and you will be able to access it
In production, your application expose its metrics data on an endpoint that a Prometheus server can scrape at regular intervals, depending on what you have configured.