1. Intro — tl;dr
Google Cloud App Engine has new "Flexible Platform" in beta.
The new platform allows more "flexible" deployments, meaning you can use Java 8 and ship webapps with their own networking abilities.
Because Ratpack is just a set of Java libraries, it’s very easy to deploy a Ratpack application to the new Flexible Platform.
Because Ratpack applications are simple Java SE applications, this post can also be applied to general Java 8 Applications being deployed to GAE.
This post is also available in pdf format
The Google App Engine docs for Java use Maven in their examples.
There’s no need to use Maven or the Maven plugin to manage your GAE apps.
Instead I recommend you use the
gcloud CLI tool.
You can download the tool here.
The CLI tool is a set of Python scripts with shell scripts that know how to execute your commands.
3. Creating a new project
At the time of writing there is no easy way to create new GAE apps from the CLI tool. You need to create new project from web console (CLI access only available via the Alpha API — which requires whitelisted access).
After creating your project invoke via
|This command will make your configuration the same across all terminals in space and time. You can reconfigure the settings but you cannot have two terminals open with settings for two different GAE projects.|
4. Preparing your Ratpack application
The Ratpack Gradle plugin applies the
application plugin which also applies the
The distribution plugin provides the
distZip tasks that will package your entire application as a tar or zip file.
$ ./gradlew clean distTar -i
We can use this because the base Docker image has
bash so allows us to execute script.
The start scripts generated by the application plugin make use of both
bash so it’s worth checking that your target environment support these.
Here is the
app.yaml file that we will use for our application:
runtime: custom (1) vm: true (1) manual_scaling: (2) instances: 1
|1||Directives to use the new beta flexible platform offering|
|2||Start the app on one instance, [autoscale options available]|
If you’re curious about what GAE will look for in your
app.yaml file feel free to check app yaml docs.
In addition to the
app.yaml file you’ll also need a
Dockerfile to instruct the "custom vm" how to invoke your application.
FROM gcr.io/google_appengine/openjdk8 ADD build/distributions/ratpack-appengine-java.tar / (1) ENV JAVA_OPTS='-Dratpack.port=8080 -Djava.security.egd=file:/dev/./urandom' (2) ENTRYPOINT ["/ratpack-appengine-java/bin/ratpack-appengine-java"]
|1||By default traffic will be served out of port
|2||We set the entrypoint to the start script generated from the Gradle application plugin.|
Here is the
Dockerfile for the Groovy version of the application, note the only change is the name of the artifact and start script.
FROM gcr.io/google_appengine/openjdk8 ADD build/distributions/ratpack-appengine-groovy.tar / ENV JAVA_OPTS='-Dratpack.port=8080 -Djava.security.egd=file:/dev/./urandom' ENTRYPOINT ["/ratpack-appengine-groovy/bin/ratpack-appengine-groovy"]
|Thanks to John Engelman — of the Gradle Shadow plugin — for the pro tip, add tar automatically decompresses the tar file|
5. Deploying to Google Cloud App Engine
Once you have
gcloud installed and the application prepared via
Dockerfile, you can proceed with deployment by invoking:
gcloud preview app deploy
Once the application is deployed you’ll see the following message in your stdout:
You can read logs from the command line by running: $ gcloud app logs read To view your application in the web browser run: $ gcloud app browse
6. Giving it a spin
Because our application is built to the TodoBackend spec we can check to ensure that our application passes the spec.
GAE will create 2 instances of your application and load balance between them.
Because we were using an in-memory DB (h2) we needed to manually reduce the number of instances to 1 to ensure a consistent experience.
Had we used an external experience to persist Todos we could easily use
n number of instances to handle incoming requests.
Be warned — using
gcloud will kill your network’s performance. While using the
gcloud CLI tool to deploy my applications I was not able to use my network access for anything else.