Running WSO2 Integrator: SI with Docker and Kubernetes¶

This tutorial has two independent halves: running the WSO2 Integrator: SI in Docker, and running it in Kubernetes via the Siddhi Kubernetes operator. Follow either half, or both.

Running the WSO2 Integrator: SI with Docker¶

This section shows you how to run WSO2 Integrator: SI in Docker. This involves installing Docker, running the WSO2 Integrator: SI in Docker and then deploying and running a Siddhi application in the Docker environment.

Before you begin:

The system requirements are as follows:
- 3 GHz Dual-core Xeon/Opteron (or latest)
- 8 GB RAM
- 10 GB free disk space
Install Docker by following the instructions provided in here.

Save the following Siddhi application as a .siddhi file in a preferred location in your machine.

@App:name('MySimpleApp')
@App:description('Receive events via HTTP transport and view the output on the console')
@source(type = 'http', receiver.url='http://0.0.0.0:8006/productionStream', basic.auth.enabled='false',
   @map(type='json'))
define stream SweetProductionStream (name string, amount double);
@sink(type='log')
define stream TransformedProductionStream (nameInUpperCase string, amount double);
-- Simple Siddhi query to transform the name to upper case.
from SweetProductionStream
select str:upper(name) as nameInUpperCase, amount
insert into TransformedProductionStream;

Note the following about this Siddhi application.

The Siddhi application operates in Docker. Therefore, the HTTP source configured in it uses a receiver URL where the host number is 0.0.0.0.
The 8006 port of the receiver URL is the same HTTP port that you previously exposed via Docker.

Starting the WSO2 Integrator: SI in Docker¶

In this scenario, you are downloading and installing the WSO2 Integrator: SI via Docker.

WSO2 provides open source Docker images to run WSO2 Integrator: SI on Docker Hub. You can view these images at Docker Hub - WSO2.

To run the WSO2 Integrator: SI from the open source image, follow the steps below:

To pull the required WSO2 Integrator: SI distribution with updates from the Docker image, issue the following command.

docker pull wso2/streaming-integrator:<SI_VERSION>
Expose the required ports via docker when running the docker container. In this scenario, you need to expose the following ports:
- The 9443 port where the WSO2 Integrator: SI server is run.
- The 8006 HTTP port from which Siddhi application you are deploying in this scenario receives messages.
To expose these ports, issue the following command.
```
docker run -p 9443:9443 -p 8006:8006 \
  -v <local-absolute-siddhi-file-path>/MySimpleApp.siddhi:/apps/MySimpleApp.siddhi \
  wso2/streaming-integrator:<SI_VERSION> \
  -Dapps=/apps/MySimpleApp.siddhi
```
Info

In the above command, you are mounting the location where you have saved the MySimpleApp.siddhi file so that the WSO2 Integrator: SI can locate it and run it when it starts in Docker. Therefore, replace <local-absolute-siddhi-file-path> with the path in which you saved the Siddhi application in your machine.
If you did not mount the MySimpleApp.siddhi file when starting the container, deploy it through the WSO2 Integrator: SI REST API:
```
curl -X POST -k https://localhost:9443/siddhi-apps \
  --header "Content-Type: text/plain" \
  -u admin:admin \
  --data-binary @MySimpleApp.siddhi
```
The -k flag disables TLS verification (WSO2 Integrator: SI ships with a self-signed certificate by default). The server responds with HTTP 201, and the Siddhi application is deployed within seconds. The following log appears in the console in which you started the WSO2 Integrator: SI in Docker:
```
INFO {org.wso2.carbon.streaming.integrator.core.internal.StreamProcessorService} - Siddhi App MySimpleApp deployed successfully
```

Now the WSO2 Integrator: SI has started in the Docker environment.

Trying-out the Siddhi application¶

To try out the MySimpleApp Siddhi application you deployed in Docker, issue the following CURL command.

curl -X POST -d "{\"event\": {\"name\":\"sugar\",\"amount\": 20.5}}"  http://0.0.0.0:8006/productionStream --header "Content-Type:application/json"

The following output appears in the console in which you started the WSO2 Integrator: SI in Docker.

HTTP Response

Running the WSO2 Integrator: SI with Kubernetes¶

In this section, you get to start and run the WSO2 Integrator: SI in a Kubernetes cluster in 5 minutes.

Before you begin:

Create a Kubernetes cluster. In this quick start guide, you can do this via Minikube as follows.
1. Install Minikube and start a cluster by following the Minikube Documentation.
2. Enable ingress on Minikube by issuing the following command.
  minikube addons enable ingress
Make sure that you have admin privileges to install the Siddhi operator.

Installing the Siddhi Operator for the WSO2 Integrator: SI¶

To install the Siddhi Operator, follow the procedure below:

To install the Siddhi Kubernetes operator for WSO2 Integrator: SI issue the following commands:

kubectl apply -f https://github.com/siddhi-io/siddhi-operator/releases/download/v0.2.2/00-prereqs.yaml

kubectl apply -f https://github.com/siddhi-io/siddhi-operator/releases/download/v0.2.2/01-siddhi-operator.yaml
To verify whether the Siddhi operator is successfully installed, issue the following command.

kubectl get deployment

If the installation is successful, the following deployments should be running in the Kubernetes cluster.

Deploying Siddhi applications in Kubernetes¶

You can deploy multiple Siddhi applications in one or more selected containers via Kubernetes. In this example, let's deploy just one Siddhi application in one container for the ease of understanding how to run the WSO2 Integrator: SI in a Kubernetes cluster.

First, let's design a simple Siddhi application that consumes events via HTTP to detect power surges. It filters events for a specific device type (i.e., dryers) and that also report a value greater than 600 for power.

    @App:name("PowerSurgeDetection")
    @App:description("App consumes events from HTTP as a JSON message of { 'deviceType': 'dryer', 'power': 6000 } format and inserts the events into DevicePowerStream, and alerts the user if the power level is greater than or equal to 600W by printing a message in the log.")
    /*
        Input: deviceType string and powerConsuption int(Watt)
        Output: Alert user from printing a log, if there is a power surge in the dryer. In other words, notify when power is greater than or equal to 600W.
    */


    @source(
      type='http',
      receiver.url='${RECEIVER_URL}',
      basic.auth.enabled='false',
      @map(type='json')
    )

    define stream DevicePowerStream(deviceType string, power int);

    @sink(type='log', prefix='LOGGER')
    define stream PowerSurgeAlertStream(deviceType string, power int);

    @info(name='surge-detector')
    from DevicePowerStream[deviceType == 'dryer' and power >= 600]
    select deviceType, power
    insert into PowerSurgeAlertStream;

The above Siddhi application needs to be deployed via a YAML file. Copy the following into a file named siddhi-process.yaml. It contains: the Siddhi application (under spec.apps), a container section that sets the RECEIVER_URL environment variable referenced by the Siddhi app's HTTP source, and a runner section with authorization configuration.

apiVersion: siddhi.io/v1alpha2
kind: SiddhiProcess
metadata:
  name: streaming-integrator
spec:
  apps:
    - script: |
        @App:name("PowerSurgeDetection")
        @App:description("App consumes events from HTTP as a JSON message of { 'deviceType': 'dryer', 'power': 6000 } format and inserts the events into DevicePowerStream, and alerts the user if the power level is greater than or equal to 600W by printing a message in the log.")
        /*
            Input: deviceType string and powerConsuption int(Watt)
            Output: Alert user from printing a log, if there is a power surge in the dryer. In other words, notify when power is greater than or equal to 600W.
        */

        @source(
          type='http',
          receiver.url='${RECEIVER_URL}',
          basic.auth.enabled='false',
          @map(type='json')
        )
        define stream DevicePowerStream(deviceType string, power int);
        @sink(type='log', prefix='LOGGER')
        define stream PowerSurgeAlertStream(deviceType string, power int);
        @info(name='surge-detector')
        from DevicePowerStream[deviceType == 'dryer' and power >= 600]
        select deviceType, power
        insert into PowerSurgeAlertStream;
  container:
    env:
      -
        name: RECEIVER_URL
        value: "http://0.0.0.0:8080/checkPower"
      -
        name: BASIC_AUTH_ENABLED
        value: "false"

  runner: |
    auth.configs:
      type: 'local'        # Type of the IdP client used
      userManager:
        adminRole: admin   # Admin role which is granted all permissions
        userStore:         # User store
          users:
          -
            user:
              username: root
              password: YWRtaW4=
              roles: 1
          roles:
          -
            role:
              id: 1
              displayName: root
      restAPIAuthConfigs:
        exclude:
          - /simulation/*
          - /stores/*

Security notice

The above runner configuration uses a default credential (YWRtaW4=, base64 for admin) for demonstration purposes. In production deployments, replace this with a strong credential and manage it via a Kubernetes Secret rather than embedding it inline in the SiddhiProcess manifest.

The container.env block specifies that Siddhi applications running within the container should receive events at the http://0.0.0.0:8080/checkPower URL (substituted into ${RECEIVER_URL} at runtime) and that basic authentication is not enabled for them.

Save the file as siddhi-process.yaml in a preferred location.
To apply the configurations in this YAML file to the Kubernetes cluster, issue the following command.

kubectl apply -f <PATH_to_siddhi-process.yaml>

Info

This file overrules the configurations in the <SI_HOME>/conf/server/deployment.yaml file.

Invoking the Siddhi application¶

To invoke the PowerSurgeDetection Siddhi application that you deployed in the Kubernetes cluster, follow the steps below.

First, get the external IP of minikube by issuing the following command.

minikube ip

Add the IP it returns to the /etc/hosts file in your machine.

Issue the following CURL command to invoke the PowerSurgeDetection Siddhi application.

curl -X POST \
  http://siddhi/streaming-integrator-0/checkPower \
    -H 'Accept: */*' \
    -H 'Content-Type: application/json' \
    -H 'Host: siddhi' \
    -d '{
        "deviceType": "dryer",
        "power": 600
        }'

To monitor the associated logs for the above siddhi application, get a list of the available pods by issuing the following command.

kubectl get pods

This returns the list of pods as shown in the example below.

NAME                                        READY    STATUS    RESTARTS    AGE
streaming-integrator-0-b4dcf85-npgj7         1/1     Running      0        165m
siddhi-operator-5f9fcb7679-n4zpj             1/1     Running      0        173m

To monitor the logs for the required pod, issue the following command. In this example, the pod to be monitored is streaming-integrator-0-b4dcf85-npgj7.

kubectl logs streaming-integrator-0-b4dcf85-npgj7

This prints the WSO2 Integrator: SI log for the specified pod. For the PowerSurgeDetection Siddhi application, a log entry similar to the following appears each time a matching event is posted to /checkPower:
```
INFO {io.siddhi.core.stream.output.sink.LogSink} - LOGGER : PowerSurgeAlertStream : Event{timestamp=1776619443836, data=[dryer, 600], isExpired=false}
```

Edit this page

Last update: May 14, 2026