Background: Akri chose the term "broker" because one use case Akri initially envisioned was deploying Pods that acted as protocol translation gateways. For example, Akri could discover USB cameras and automatically deploy a broker to each camera that advertizes the camera as an IP camera that could be accessed outside the Node.
capacity
that can be set in a Configuration to limit the number of Nodes that can utilize a device at once). Each broker is provisioned with device connection information and other metadata as environment variables. These environment variables come from two sources: a Configuration's brokerProperties
and the properties
of a Device
discovered by a Discovery Handler. The former is where an operator can specify environment variables that will be set in brokers that utilize any device discovered via the Configuration. The latter is specific to one device and usually contains connection information such as an RTSP URL for an ONVIF camera or a devnode for a USB device. Also, while brokerProperties
can be unique to a scenario, the properties
environment variable keys are consistent to a Discovery Handler with values changing based on device. All the environment variables from these two sources are displayed in an Instance that represents a discovered device, making it a good reference for what environment variables the broker should expect. The image below expresses how a broker Pod's environment variables come from the two aforementioned sources.Device.properties
). The following table contains the environment variables specified by each of Akri's currently supported Discovery Handlers, and the expected content of the environment variables.DEBUG_ECHO_DESCRIPTION
foo
, bar
ONVIF_DEVICE_SERVICE_URL
http://10.123.456.789:1000/onvif/device_service
ONVIF_DEVICE_IP_ADDRESS
10.123.456.789
ONVIF_DEVICE_MAC_ADDRESS
48:0f:cf:4e:1b:3d
, 480fcf4e1b3d
OPCUA_DISCOVERY_URL
10.123.456.789:1000/Some/Path/
UDEV_DEVNODE
/dev/video1
, /dev/snd/pcmC1D0p
, /dev/dri/card0
<Discovery Handler name>.configuration.createInstanceServices=false
and <Discovery Handler name>.configuration.createConfigurationService=false
when installing Akri's Helm chart.<Discovery Handler name>.configuration.brokerPod.image.repository
and <Discovery Handler name>.configuration.brokerPod.image.tag
. For example, say you created a broker that connects to a USB camera and advertises it as an IP camera. You want to deploy it to all USB cameras on your cluster's nodes using Akri, so you deploy Akri with a Configuration that uses the udev Discovery Handler and set the image of your broker (say ghcr.io/brokers/camera-broker:v0.0.1
), like so:Note: See the cluster setup steps for information on how to set the crictl configuration variableAKRI_HELM_CRICTL_CONFIGURATION
nginx:stable-alpine
ghcr.io/project-akri/akri/onvif-video-broker:latest
ghcr.io/project-akri/akri/opcua-monitoring-broker:latest
ghcr.io/project-akri/akri/udev-video-broker:latest
brokerProperties
. For example, take the scenario of brokers being deployed to USB cameras discovered by Akri. You may wish to give the brokers extra information about the image format and resolution the cameras support. The brokers then can look up these variables to know how to properly utilize their camera. These brokerProperties
could be set in a Configuration during a Helm installation as follows: