Camel Runtimes

Camel K can run any runtime available in Apache Camel. However, this is possible only when the Camel application was previously built and packaged into a container image. Also, if you run through this option, some of the features offered by the operator may not be available. For example, you won’t be able to discover Camel capabilities because the source is not available to the operator but embedded in the container image.

This option is quite interesting if in general you’re building your applications externally, ie, via a CICD technology, and you want to delegate the operator only the "operational" part, taking care on your own of the building and publishing part.

you may loose more features, such as incremental image and container kit reusability.

Build externally, run via Operator

Let’s see a very simple example in action.

You can have your own Camel application or just create a basic one for the purpose via Camel JBang (camel init test.yaml). Once your development is over, you can test locally via camel run test.yaml and export in the runtime of your choice via camel export test.yaml --runtime ….

The step above is a very quick way to create a basic Camel application in any of the available runtime. Let’s imagine we’ve done this for Camel Main or we have already a Camel application as a Maven project. As the build part is something we want to take care on our own, we create a pipeline to build, containerize and push the container to a registry (see as a reference Camel K Tekton example).

At this stage we do have a container image with our Camel application. We can use the kamel CLI to run our Camel application via kamel run --image docker.io/my-org/my-app:1.0.0 tuning, if it’s the case, with any of the trait or configuration required.

Jvm trait won’t be available when running an application built externally.

If all is good, in a few seconds (there is no build involved) you should have your application up and running and you can monitor and operate with Camel K as usual.