Runtime configuration

When you develop an integration with Camel K there are many ways you can provide a configuration resource to the runtime Integration. Since we are dealing with Kubernetes we use Configmap or Secret. The kamel run command is provided with a --config flag that help you setting any configuration resource your Integration need.

The runtime configuration are expected to be encoded in UTF-8 as they are processed by runtime Camel Context and parsed as property files. These resources are materialized as files in a well known path in the Integration Pod. The mount trait will be declared on the Integration. They are also made available on the classpath in order to ease their usage directly from the Route. If you need to provide a non UTF-8 (ie, a binary resource) you may look for --resource flag instead.

the scope of --config global option had different meaning prior Camel K version 1.5. The old global --config has been replaced with --kube-config since Camel K version 1.5.

Runtime configmap configuration

In a Kubernetes world we’re dealing with Configmap containing configuration previously stored in the platform. When you need to materialize a Configmap into a file configuration available at your Integration, you can use the --config 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:

config-configmap-route.groovy
from('timer:configmap')
    .setBody()
        .simple("resource:classpath:my-configmap-key")
    .log('configmap content is: ${body}')

You can see that we’re expecting to use a my-configmap-key file stored somewhere in the classpath. In order to materialize the Configmap will be as easy as running the --config configmap syntax:

kamel run --config configmap:my-cm config-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 configuration

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:

config-secret-route.groovy
from('timer:secret')
    .setBody()
        .simple("resource:classpath:my-secret-key")
    .log('secret content is: ${body}')

You can see that we’re expecting to use a my-secret-key file stored somewhere in the classpath. In order to materialize the Secret will be as easy as running the --config secret syntax:

kamel run --config secret:my-sec config-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.

Configmap/Secret property references

Each Configmap/Secret will be parsed as a property file and you will be able to use those properties inside your Route definition or, more in general, as you would do with any other runtime property. As an example, you can create the following Secret:

my.properties
my.key.1=hello
my.key.2=world
kubectl create secret generic my-secret-properties --from-file=my.properties

In our Integration we can simply refer the properties defined in the Secret as we would do with any other property:

config-secret-property-route.groovy
from('timer:secret')
    .routeId('secret')
    .log('{{my.key.1}} {{my.key.2}}')

We just have to provide the --config we are willing to use:

kamel run --config secret:my-secret-properties config-secret-property-route.groovy

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 --config flag. In order to use it, you can add a /key notation after the Configmap or Secret name (ie, --config configmap:my-cm/my-key).

Let’s see an example with multiple Secret in action. The very same concept can be easily applied to Configmap. We start creating a Secret containing multiple resources:

kubectl create secret generic my-sec-multi --from-literal=my-secret-key="very top secret" --from-literal=my-secret-key-2="even more secret"

In our Integration we plan to use only one of the resources of the Secret:

config-secret-key-route.groovy
from('timer:secret')
    .setBody()
        .simple("resource:classpath:my-secret-key-2")
    .log('secret content is: ${body}')

Let’s use the key filtering:

kamel run --config secret:my-sec-multi/my-secret-key-2 config-secret-key-route.groovy

You may check in the Integration Pod that only the my-secret-key-2 data has been mounted.

Runtime resources

If you’re looking for runtime resources (ie, binary resources) you can look at the runtime resources section.

Back to top