Runtime resources
When you develop an integration with Camel K there are many ways you can provide a resource to the runtime Integration. Since we are dealing with Kubernetes we use Configmap or Secret. The kamel run command is provided with a --resource flag that help you setting any resource your Integration may need.
The runtime resources are expected to be any resource type (text or binary content). These resources are materialized as files in the Integration Pod. The mount trait will be declared on the Integration. The destination path can be either a default location or any path specified by the user. Only default resource directory is available within the Integration classpath.
you’ll find --resource is very similar to the --config run flag. The main difference is that a resource can have a binary content and it won’t be parsed by the Camel Context. |
Runtime configmap resource
In a Kubernetes world we’re dealing with Configmap that are containing configuration previously stored in the platform. When you need to materialize a Configmap into a file resource available at your Integration, you can use the --resource configmap syntax.
As an example, let’s create a Configmap named my-cm containing certain information. You can alternatively use any Configmap you’ve already stored in your cluster:
kubectl create configmap my-cm --from-literal=my-configmap-key="configmap content"
We want to use the materialized file in an integration:
from('file:/etc/camel/resources/my-cm/?fileName=my-configmap-key&noop=true&idempotent=false')
.log('resource file content is: ${body}')You can see that we’re expecting to use a my-configmap-key file stored in the default resource location (/etc/camel/resources/). In order to materialize the Configmap will be as easy as running the --resource configmap syntax:
kamel run --resource configmap:my-cm resource-configmap-route.groovy
As soon as the Integration starts, the Camel K operator will take care to mount a volume with the Configmap 's content.
you can provide a Configmap which is not yet available on the cluster. The Integration won’t start until the resource will be made available. |
Runtime secret resource
We can apply the very same concept seen in the previous section for the Kubernetes Secret 's.
As an example, let’s create a Secret named my-sec containing certain information. You can alternatively use any Secret you’ve already stored in your cluster:
kubectl create secret generic my-sec --from-literal=my-secret-key="very top secret"
We want to use the materialized secret file in an integration:
from('file:/etc/camel/resources/my-sec/?fileName=my-secret-key&noop=true&idempotent=false')
.log('resource file content is: ${body}')You can see that we’re expecting to use a my-secret-key file stored in the default resource location (/etc/camel/resources/). In order to materialize the Secret will be as easy as running the --resource secret syntax:
kamel run --resource secret:my-sec resource-secret-route.groovy
As soon as the Integration starts, the Camel K operator will take care to mount a volume with the Secret 's content.
you can provide a Secret which is not yet available on the cluster. The Integration won’t start until the resource will be made available. |
Resource destination path
When you are programming an Integration you may find yourself in the situation to specify where exactly a resource has to be mounted. For such purpose you can specify the location where a file is expected with the --resource @path syntax.
As an example, let’s create a Configmap named my-cm containing certain information. You can alternatively use any Configmap you’ve already stored in your cluster:
kubectl create configmap my-cm-files --from-literal=input.txt="configmap input.txt content"
Let’s see an example where your integration expect a text file to be consumed under a specific filesystem location:
from('file:/tmp/inputs/?fileName=input.txt&noop=true&idempotent=false')
.log('resource file content is: ${body}')When running the Integration, you can specify where to mount the resource content (either a File, Configmap or Secret) with the @path syntax:
kamel run --resource configmap:my-cm-files@/tmp/inputs resource-file-location-route.groovy
You may check in the Integration Pod and verify that the file was mounted in the tmp/inputs/input.txt destination.
Configmap/Secret key filtering
When you deal with Configmap or Secret, you may want to limit the quantity of information to recover from such resources. Both Configmap and Secret can hold more than one resource in the same unit. For this reason you will find a key filtering feature available in the --resource flag. In order to use it, you can add a /key notation after the Configmap or Secret name (ie, --resource configmap:my-cm/my-key).
Let’s see an example with multiple Configmap in action. The very same concept can be easily applied to Secret. We start creating a Configmap containing multiple resources:
kubectl create configmap my-cm-multi --from-literal=my-configmap-key="configmap content" --from-literal=my-configmap-key-2="another content"
In our Integration we plan to use only one of the resources of the Secret:
from('file:/tmp/app/data/?fileName=test.txt&noop=true&idempotent=false')
.log('resource file content is: ${body} consumed from ${header.CamelFileName}')Let’s use the key filtering. Also notice that we’re combining with the @path syntax to declare where to mount the file:
kamel run --resource configmap:my-cm-multi/my-configmap-key-2@/tmp/app/data/test.txt resource-configmap-key-location-route.groovy
You may check in the Integration Pod that only the test.txt file has been mounted under /tmp/app/data directory containing the information you had in my-configmap-key-2.
Runtime config
If you’re looking for runtime configuration you can look at the runtime configuration section.