grails prod run-app
21 Deployment
Version: 6.2.3-SNAPSHOT
Table of Contents
21 Deployment
Grails applications can be deployed in a number of ways, each of which has its pros and cons.
21.1 Standalone
"grails run-app"
You should be very familiar with this approach by now, since it is the most common method of running an application during the development phase. An embedded Tomcat server is launched that loads the web application from the development sources, thus allowing it to pick up any changes to application files.
You can run the application in the production environment using:
You can run the app using the bootRun
Gradle task. The next command uses the Gradle Wrapper.
./gradlew bootRun
You can specify an environment supplying grails.env
system property.
./gradlew -Dgrails.env=prod bootRun
Runnable WAR or JAR file
Another way to deploy in Grails 3.0 or above is to use the new support for runnable JAR or WAR files. To create runnable archives, run grails package
:
grails package
Alternatively, you could use the assemble
Gradle task.
./gradlew assemble
You can then run either the WAR file or the JAR using your Java installation:
java -Dgrails.env=prod -jar build/libs/mywar-0.1.war (or .jar)
A TAR/ZIP distribution
Note: TAR/ZIP distribution assembly has been removed from Grails 3.1. |
"./gradlew bootRun"
You should be very familiar with this approach by now, since it is the most common method of running an application during the development phase. An embedded Tomcat server is launched that loads the web application from the development sources, thus allowing it to pick up any changes to application files.
You can run the application in the production environment using:
./gradlew bootRun -Dgrails.env=prod
You can run the app using the bootRun
Gradle task. The next command uses the Gradle Wrapper.
./gradlew bootRun
You can specify an environment supplying grails.env
system property.
./gradlew -Dgrails.env=prod bootRun
Runnable WAR or JAR file
Another way to deploy in Grails 3.0 or above is to use the new support for runnable JAR or WAR files. To create runnable archives, run grails package
:
grails package
Alternatively, you could use the assemble
Gradle task.
./gradlew assemble
You can then run either the WAR file or the JAR using your Java installation:
java -Dgrails.env=prod -jar build/libs/mywar-0.1.war (or .jar)
A TAR/ZIP distribution
Note: TAR/ZIP distribution assembly has been removed from Grails 3.1. |
21.2 Container Deployment (e.g. Tomcat)
Grails apps can be deployed to a Servlet Container or Application Server.
WAR file
A common approach to Grails application deployment in production is to deploy to an existing Servlet container via a WAR file. Containers allow multiple applications to be deployed on the same port with different paths.
Creating a WAR file is as simple as executing the war command:
grails war
This will produce a WAR file that can be deployed to a container, in the build/libs
directory.
Note that by default Grails will include an embeddable version of Tomcat inside the WAR file so that it is runnable (see the previous section), this can cause problems if you deploy to a different version of Tomcat. If you don’t intend to use the embedded container then you should either remove the Tomcat dependencies or change the scope to testImplementation
prior to deploying to your production container in build.gradle
:
testImplementation "org.springframework.boot:spring-boot-starter-tomcat"
Application servers
The Grails framework requires that runtime containers support Servlet 3.0 and above. By default, Grails framework applications are bundled with an embeddable Tomcat and testing is primarily done with Tomcat. Any servlet container meeting the minimum requirements should be able to run Grails framework applications, but some workarounds may be required for container-specific bugs or configurations.
21.3 Deployment Configuration Tasks
Setting up HTTPS and SSL certificates for standalone deployment
To configure an SSL certificate and to listen on an HTTPS port instead of HTTP, add properties like these to application.yml
:
server:
port: 8443 # The port to listen on
ssl:
enabled: true # Activate HTTPS mode on the server port
key-store: <the-location-of-your-keystore> # e.g. /etc/tomcat7/keystore/tomcat.keystore
key-store-password: <your-key-store-password> # e.g. changeit
key-alias: <your-key-alias> # e.g. tomcat
key-password: <usually-the-same-as-your-key-store-password>
These settings control the embedded Tomcat container for a production deployment. Alternatively, the properties can be specified on the command-line. Example: -Dserver.ssl.enabled=true -Dserver.ssl.key-store=/path/to/keystore
.
Configuration of both an HTTP and HTTPS connector via application properties is not supported. If you want to have both, then you’ll need to configure one of them programmatically. (More information on how to do this can be found in the how-to guide below.) |
There are other relevant settings. Further reference: