Building workflow images using Quarkus CLI

This document describes how to build a OpenShift Serverless Logic container image using the Quarkus CLI.

Prerequisites

Quarkus provides a few extensions to build container images, such as Jib, docker, s2i, and buildpacks. For more information about the Quarkus extensions, see the Quarkus documentation.

Building the workflow application

Procedure

  1. In a command terminal, navigate to your Quarkus project.

  2. To build your workflow application on Quarkus, set the quarkus.container-image.build property value to true and run the following command:

    Build your workflow application
    quarkus build -Dquarkus.container-image.build=true

    The previous command builds your image with name: {system_username}/{project_artifactId}:{project_version}.

    Optionally, you can set the following properties to specify the image:

    • quarkus.container-image.registry: To define the registry address of the image, such as quay.io. When using OpenShift use the provided registry.

    • quarkus.container-image.group: To define the registry namespace of the image. For example, context/namespace or in case of Kubernetes or OpenShift namespace/project.

    • quarkus.container-image.name: To override the image name. By default, this property uses artifact ID.

    Build your workflow application with specific image information
    quarkus build -Dquarkus.container-image.build=true \
    -Dquarkus.container-image.group=kogito \
    -Dquarkus.container-image.name=serverless-workflow-greeting-quarkus \
    -Dquarkus.container-image.tag=1.0 \
    -Dquarkus.container-image.registry=quay.io

    The added Jib extension caches the target/lib directory. Based on the size of your project, Jib speeds up the rebuilds.

  3. You can also push your workflow application to the defined registry. You need to set the quarkus.container-image.push property value to true (default value is false).

    Example of pushing the built workflow application to a registry
    quarkus build -Dquarkus.container-image.build=true \
    -Dquarkus.container-image.group=sonataflow \
    -Dquarkus.container-image.name=serverless-workflow-greeting-quarkus \
    -Dquarkus.container-image.tag=1.0 \
    -Dquarkus.container-image.registry=quay.io \
    -Dquarkus.container-image.push=true

    The previous command results in the following container image pushed to quay.io:

    quay.io/sonataflow/serverless-workflow-greeting-quarkus:1.0

  4. Alternatively, you can create an Apache Maven profile to build the container image, which can be triggered by setting the target profile.

    Example Apache Maven profile
    <profile>
  <id>build-container</id>
  <properties>
    <quarkus.container-image.build>true</quarkus.container-image.build>
    <quarkus.container-image.group>kogito</quarkus.container-image.group>
    <quarkus.container-image.name>serverless-workflow-greeting-quarkus</quarkus.container-image.name>
    <quarkus.container-image.tag>1.0</quarkus.container-image.tag>
    <quarkus.container-image.registry>quay.io</quarkus.container-image.registry>
    <quarkus.container-image.push>true</quarkus.container-image.push>
  </properties>
</profile>

    You can activate the created Apache Maven profile using Quarkus CLI:

    Activate the Apache Maven profile
     quarkus build -- -Pbuild-container

Building the workflow application using a native image

When it comes to workflows, a small startup footprint is expected, which can be better when using the native builds to build a workflow application.

Procedure

  1. In a command terminal, navigate to your Quarkus project.

  2. To build a native image, pass the --native flag using Quarkus CLI:

    Example of building a native image
    quarkus build --native -Dquarkus.container-image.build=true \
    -Dquarkus.container-image.group=kogito \
    -Dquarkus.container-image.name=serverless-workflow-greeting-quarkus \
    -Dquarkus.container-image.tag=1.0-native \
    -Dquarkus.container-image.registry=quay.io

    The previous command results in the following container image:

    quay.io/kogito/serverless-workflow-greeting-quarkus:1.0-native

    In case GraalVM is not installed, you can set the -Dquarkus.native.container-build=true system property, which creates a Linux executable.
    Configure Docker to use the in-cluster (Remote) Docker daemon

    When you are building Container Images using a remote Docker Daemon, i.e. Minikube, you need to use the following system property instead of -Dquarkus.native.container-build=true

    System property to use a remote Docker Daemon
    -Dquarkus.native.remote-container-build=true

    For more information about native builds, see Building a native executable.

Once you have the container image of you OpenShift Serverless Logic application, you can proceed to deployments or start testing it locally.

Additional resources

Found an issue?

If you find an issue or any misleading information, please feel free to report it here. We really appreciate it!