Self Managed Build Integrations
Camel K operator is traditionally in charge to perform a build from a Camel DSL source. The resulting Integration depends directly on an IntegrationKit, which is a reusable custom resource backing the final container image that your application will run. The only runtime the operator can build is Camel Quarkus (via Camel K Runtime project).
However Camel K can run any runtime available in Apache Camel. This is possible only when the Camel application was previously built and packaged into a container image externally. Mind that 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. As there is no creation of an IntegrationKit, this is also known as 'kit-less' Integration.
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.
Camel Runtime version discovery
Every Camel application requires a CamelCatalog object to know how to perform certain runtime configuration. When you run a self managed build Integrations there is no easy way to automatically discover for which runtime your application was built. In this case, we suggest you to specify the camel.runtime-version trait in order to improve the compatibility between the operator configuration and the specific runtime you’re running. If no runtime version is specified, then, as default, the operator will use the one specified in the IntegrationPlatform.
Trait configuration
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 self managed build Integrations. There is also no possible way to auto-tune certain traits that require the presence of the source. In this case, you should instead provide a trait configuration with the values that are required by your Integration (for example, Knative, Service and other deployment traits).