Implantando na Heroku

Para concluir este guia, você precisa:

Heroku is a platform as a service (PaaS) that enables developers to build, run, and operate applications entirely in the cloud. It supports several languages like Java, Ruby, Node.js, Scala, Clojure, Python, PHP, and Go. In addition, it offers a container registry that can be used to deploy prebuilt container images.

Heroku can be used in different ways to run a Quarkus application:

All three approaches need to be aware of the port that Heroku assigns to it to handle traffic. Luckily, there’s a dynamic configuration property for it.

This guide will take as input a simple application created with the Quarkus tooling:

Para usuários do Windows:

This command will create a new REST application in the getting-started-with-heroku directory.

Let’s make this application a Git repository:

Heroku can react on changes in your repository, run CI and redeploy your application when your code changes. Therefore, we start with a valid repository already.

Also, make sure your Heroku CLI is working:

Heroku picks a random port and assigns it to the container that is eventually running your Quarkus application. That port is available as an environment variable under $PORT. The easiest way to make Quarkus in all deployment scenarios aware of it is using the following configuration:

This reads as: "Listen on $PORT if this is a defined variable, otherwise listen on 8080 as usual." Run the following to add this to your application.properties:

The first variant uses the Quarkus Maven build to create the quarkus-app application structure containing the runnable "fast-jar" as well as all libraries needed inside Heroku’s build infrastructure and then deploying that result, the other one uses a local build process to create an optimized container.

For the first variant, two additional files are needed in your application’s root directory:

Quarkus needs JDK 17, so we specify that first:

We will deploy a web application so we need to configure the type web in the Heroku Procfile like this:

Your application should already be runnable via heroku local web from the repository root directory. You need to have run mvn package before to create the runnable jar for this to succeed.

Now let’s create an application in your account and deploy that repository to it:

This will create a remote repository in your Heroku account, and it should have also added a heroku remote url to your local repository which you can view using git remote -v:

Now you can push your application to Heroku and open it in your browser.

The application will have a generated URL and the terminal should output that. heroku open hello opens your default browser to access your new application using the '/hello' context. That page should output the text 'hello'.

To access the REST endpoint via curl, get the app URL from the heroku info command:

Of course, you can use the Heroku CLI to connect this repo to your GitHub account, too, but this is out of scope for this guide.

The advantage of pushing a whole container is that we are in complete control over its content and maybe even choose to deploy a container with a native executable running on GraalVM.

First, login to Heroku’s container registry:

We need to add an extension to our project to add the capability to build container images:

Then, let’s commit this change:

The image we are going to build needs to be named accordingly to work with Heroku’s registry and deployment. We get the generated name via heroku info and pass it on to the (local) build:

You can now push the image and release it.

You can and should check the logs to see if your application is now indeed running from the container:

The biggest advantage we take when deploying our app as a container is to deploy a container with the natively compiled application. Why? Because Heroku will stop or sleep the application when there’s no incoming traffic. A native application will wake up much faster from its sleep.

The process is pretty much the same. We opt in to compiling a native image inside a local container, so that we don’t have to deal with installing GraalVM locally:

After that, push and release again using Docker or Podman (see above) and check the logs.