Camel Runtimes (aka "sourceless" Integrations)

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. Mind that, when you run an Integration with this option, the operator will create a synthetic IntegrationKit.

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.

Certain Camel K operational aspect may be driven by traits. When you’re building the application outside the operator, some of those traits may not be executed as they are executed during the building phase that we are skipping when running sourceless Integrations. Here we provided a list of those traits that may not work when building the application outside the Camel K operator.