Promoting Integrations across environments

As soon as you have an Integration running in your cluster, you will be challenged to move that Integration to an higher environment. Ie, you can test your Integration in a development environment, and, as soon as you’re happy with the result, you will need to move it into a production environment.

CLI promote command

Camel K has an opinionated way to achieve the promotion goal through the usage of kamel promote command. With this command you will be able to easily move an Integration from one namespace to another without worrying about any low level detail such as resources needed by the Integration. You only need to make sure that both the source operator and the destination operator are using the same container registry and that the destination namespace provides the required Configmaps, Secrets or Kamelets required by the Integration.

use dry run option (-o yaml) and export the result to any separated cluster or Git repository to perform a GitOps strategy.

Let’s see a simple Integration that uses a Configmap to expose some message on an HTTP endpoint. We can start creating such an Integration and testing in a namespace called development:

kubectl create configmap my-cm --from-literal=greeting="hello, I am development!" -n development
PromoteServer.java
import org.apache.camel.builder.RouteBuilder;

public class PromoteServer extends RouteBuilder {
  @Override
  public void configure() throws Exception {
    from("platform-http:/hello?httpMethodRestrict=GET").setBody(simple("resource:classpath:greeting"));
  }
}

Let’s run it:

kamel run --dev -n development PromoteServer.java --config configmap:my-cm [-t service.node-port=true]

Note that you may need to tweak the service trait, depending on the Kubernetes platform and the level of exposure you want to provide. As soon as it is finished, we can test it as well:

curl http://192.168.49.2:32116/hello
hello, I am development!

Now let’s say we’re happy with the testing of our Integration and we’re ready to move it to a production environment. We need to have the destination environment (a Kubernetes namespace) ready with an operator (sharing the same operator source container registry) and any configuration, such as the configmap we have used here. For that scope, let’s create one on the destination namespace:

kubectl create configmap my-cm --from-literal=greeting="hello, I am production!" -n production

Please, note that for security reason, there is a check to make sure that the expected resources such as Configmaps, Secrets and Kamelets are present on the destination. If any is missing, the Integration won’t be moved. We can now "promote" our Integration:

kamel promote promote-server -n development --to production
kamel logs promote-server -n production

Let’s test the promoted Integration:

curl http://192.168.49.2:30764/hello
hello, I am production!

Something nice is that since the Integration is reusing the very same container image, the execution of the new application will be immediate. Also from a release perspective we are guaranteeing the immutability of the Integration as the container used is exactly the same of the one we have tested in development (what we change are just the configurations).

Please notice that the Integration running in test is not altered in any way and will be running until any user will stop it.

Moving traits

this feature is available starting from version 2.5

When you use the promote subcommand, you’re also keeping the status of any configured trait along with the new promoted Integration. The tool is in fact in charge to recover the trait configuration of the source Integration and port it over to the new Integration promoted.

This is particularly nice when you have certain traits which are requiring the scan the source code (for instance, Service trait). In this way, when you promote the new Integration, the traits will be automatically configured to copy any parameter, replicating the very exact behavior between the source and destination environment.

With this approach, you won’t need to worry any longer about any trait which was requiring the source to be attached in order to automatically scan for features.

Back to top