Runtime configuration
When you develop an integration with Camel-K there are many ways you can provide a configuration resource to the runtime Integration. The most familiar way is to handle local file, but since we are dealing with Kubernetes you may need also to 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 ÙTF-8 resources as they are processed by runtime Camel Context and tried to be parsed as property files. These resources are materialized as files in a well known path in the Ìntegration Pod. 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 file configuration
The most classic way to provide a configuration is probably to have a file where you have certain text data stored. In this case you can use the --config file:/path/to/file flag that will copy that file and made available at classpath level.
the file bodyfrom('timer:config-file')
.setBody()
.simple("resource:classpath:resources-data.txt")
.log('resource file content is: ${body}')We are referring to the file expected to be copied somewhere in the classpath, with the same name as the source file. In order to use it, we’ll execute the following --config file flag command:
kamel run --config file:resources-data.txt config-file-route.groovy --dev
You can provide more than one single config at once by just adding the flag repeatedly (ie, --config file:file1.txt ---config file:file2.txt …).
Runtime configmap configuration
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 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:
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 --dev
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:
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 --dev
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.key.1=hello
my.key.2=worldkubectl 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’d do with any other property:
from('timer:secret')
.routeId('secret')
.log('{{my.key.1}} {{my.key.2}}')We have to just provide the --config we are willing to use:
kamel run --config secret:my-secret-properties config-secret-property-route.groovy --dev
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:
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 --dev
You may check in the Integration Pod that only the my-secret-key-2 file has been mounted.
Runtime resources
If you’re looking for runtime resources (ie, binary resources) you can look at the runtime resources section.