Despliegue en Heroku

To complete this guide, you need:

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 se puede utilizar de diferentes maneras para ejecutar una aplicación Quarkus:

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.

La guía asume que tienes la CLI de Heroku instalada.

Esta guía tomará como entrada una aplicación desarrollada en la guía de inicio.

Asegúrate de tener a mano la aplicación de inicio, o clona el repositorio Git: git clone https://github.com/quarkusio/quarkus-quickstarts.git o descargue un archivo. La solución se encuentra en el directorio getting-started.

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.

Además, asegúrate de que tu CLI de Heroku está funcionando:

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.

Se necesitan dos archivos adicionales en el directorio raíz de su aplicación:

Quarkus necesita JDK 11, así que lo especificamos primero:

Vamos a desplegar una aplicación web por lo que necesitamos configurar el tipo web en el Heroku Procfile así:

Su aplicación ya debería poder ejecutarse a través de heroku local web.

Vamos a crear una aplicación en tu cuenta y a desplegar ese repositorio en ella:

La aplicación tendrá un nombre generado y el terminal debería mostrarlo. heroku open abre su navegador por defecto para acceder a su nueva aplicación.

Para acceder al endpoint REST mediante curl, ejecute:

Por supuesto, también puedes utilizar la CLI de Heroku para conectar este repositorio a tu cuenta de GitHub, pero esto está fuera del alcance de esta guía.

La ventaja de subir un contenedor completo es que tenemos un control total sobre su contenido y podemos incluso elegir desplegar un contenedor con un ejecutable nativo que se ejecute en GraalVM.

En primer lugar, inicie sesión en el registro de contenedores de Heroku:

Necesitamos añadir una extensión a nuestro proyecto para construir imágenes de contenedores a través del plugin de Quarkus Maven:

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:

Con Docker instalado, ahora puedes empujar la imagen y liberarla:

Puede y debe comprobar los registros para ver si su aplicación se está ejecutando desde el contenedor:

The initial push is rather big, as all layers of the image need to be transferred. The following pushes will be smaller.

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:

Después, suba y publique de nuevo: