Building workflow images using Quarkus CLI

This document describes how to build a SonataFlow container image using the Quarkus CLI.

Prerequisites

A quarkus workflow project is created.

For more information about creating a workflow project, see Creating your first Serverless Workflow Java service.
You have set up your environment according to the advanced environment setup guide and your cluster is ready.
Optionally, GraalVM 22.3.0 is installed. See getting-started/preparing-environment.adoc#proc-additional-options-for-local-environment

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

In a command terminal, navigate to your Quarkus project.
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.
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

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

In a command terminal, navigate to your Quarkus project.

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 SonataFlow 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!