Container Development Kit (CDK)

The Container Development Kit (CDK) is a set of commands within the BubbleRAN CLI that allow you to take an xApp you have already developed and tested (e.g., one of the xApps from the xApp Training labs) and turn it into a container image and package it into a CompositionModel that can be deployed and managed declaratively through the Network CRD.

In short, the CDK is the bridges the development of an xApp (running it by hand on bare-metal against a RIC, as in xApp Training) to the managed deployment of it (running it as a managed Element inside the cluster, alongside the RAN and the Near-RT RIC).

The CDK also packages applications that are not xApps, such as an AI inference service that UEs reach over the 5G network. brc cdk app builds, pushes and deploys them as edge-apps, as described in Lab 3.

Why use it

During xApp developing you compile an xApp and run it directly on the bare-metal host (e.g., in the control-plane node), pointing it at a Near-RT RIC IP (requiring to update the xApp configuration every time the network is re-deployed). That is fine for development, but it is not ideal for benchamrking an xApp and evaluating its performance for a given use-case:

• The binary/scripts and their dependencies are not packaged or versioned
• Nothing restarts the xApp if it dies, and it is not part of the network's lifecycle
• It cannot be deployed on a different cluster with a single manifest

The CDK solves this by packaging the xApp into an image and emitting a CompositionModel (the same kind of packaging used for all elements within MX-PDK) so your xApp becomes just another Element in a Network.

How it works

The CDK takes you from xApp code to a running, RIC-connected Element in three steps:

1. Build & push the image — brc cdk image build onboards your xApp on the CDK base image. brc cdk image push uploads it to the cluster-local registry (zot).
2. Install the model — brc cdk model install packages a Helm chart, pushes it to zot, and creates the CompositionModel in the cluster.
3. Deploy via the Network — reference the model from a Network's edge: section; Athena deploys your xApp as an Element wired to the Near-RT RIC.

The cluster-local registry

On a BubbleRAN MX-PDK cluster the CDK does not push to BubbleRAN's public registry. The platform runs a private OCI registry (zot) reachable in-cluster at registry.<cluster>.local:5000. Both your xApp image and the CompositionModel chart live there:

Artifact	Reference
xApp image	registry.<cluster>.local:5000/telco-fabric/<org>/xapps:latest
CompositionModel chart	oci://registry.<cluster>.local:5000/telco-fabric/models/<org>

<org> is your cluster/customer name (taken from the current kubeconfig context), and the credentials are read automatically from the bubbleran-hub secret created by brc login. You do not need to log in to anything by hand.

Where to run the CDK

It is strongly recommended to run brc cdk on the control-plane node of your cluster (e.g. over SSH).

What gets discovered and onboarded by the CDK

An xApp's entry point is simply the file you run to start the xApp: the Python script you would launch with python3 my-xapp.py, or the C source that compiles into the xApp executable. It is the file that initialises the SDK (xapp_sdk.init(...)) and holds the xApp's main loop. In xApp Training, lab5.py and lab5.c are entry points, i.e. they are exactly what you execute to run the xApp.

brc cdk runs from your xapp_sdk directory, scans it for these entry points, and turns each one into a "deployment-mode" of the generated CompositionModel, i.e., one xApp file becomes one selectable xApp you can deploy in a Network. It detects:

• Python entry points — top-level .py files under src/dev/python3/ or src/usr/python3/ that call init(...) on the SDK module they imported. The alias does not matter: import xapp_sdk as ric then ric.init(sys.argv) is detected, and so is xapp_usr_sdk. The mode is named after the file (ran-slicing.py → mode ran-slicing).
• C entry points — the targets listed in the LIST_XAPP variable of src/dev/c/CMakeLists.txt or src/usr/c/CMakeLists.txt. Their compiled binaries must already exist under the matching build/ path: the CDK packages, it does not compile. A declared target you have not built is skipped with a warning.

Modes discovered in a usr/ tree are prefixed usr- so that the two SDKs, which reuse file names for different APIs, cannot collide: src/usr/c/ran-slicing.c becomes the mode usr-ran-slicing.

By default every xApp in the tree is packaged, which in a fresh SDK checkout means all of its examples as well. Pass --xapp <mode> (repeatable, or comma-separated) to image build and the model commands to package only your own.

Around each entry point it also bundles whatever it needs to run: auto-detected third-party pip packages (from your imports), shared libraries from lib/, and model/data files (.keras, .onnx, .pkl, .csv, …).

Mode names use hyphens

A deployment-mode is named after the entry point with _ replaced by -, because the name ends up in a Kubernetes object name. The CDK stages each xApp in the image under its mode name, so xapp_oran_moni.py becomes the mode xapp-oran-moni and is installed as xapp-oran-moni.py, which is what the manager launches. Naming your own entry points with hyphens keeps the file and the mode identical, which is easier to follow.

CDK command cheatsheet

Command	What it does
brc cdk image build	Build a derived xApp image on the CDK base image (--cuda for GPU/AI base, --xapp to select which xApps).
brc cdk image push	Push the image to the cluster-local registry as telco-fabric/<org>/xapps:latest.
brc cdk image run <image>	Run the image transiently (--rm) to check it starts and finds its dependencies.
brc cdk image shell <image>	Open an interactive shell inside the image; changes are discarded on exit.
brc cdk image patch <image>	Open an interactive shell, then commit whatever you installed/changed into a new image on exit (--target to name it, --push to push).
brc cdk model build	Render the CompositionModel (and its base ConfigMap) to YAML — inspect without deploying (--xapp to select which xApps).
brc cdk model install	Package the chart, push it to zot, and create/upgrade the CompositionModel in the cluster.
brc cdk model patch	Re-roll the installed model with the latest pushed image (alias of install after an image push).
brc cdk app build	Build an edge-app image from the Dockerfile named in the app spec (app.yaml).
brc cdk app push	Push the edge-app image to the cluster-local registry as telco-fabric/<org>/<app-name>:latest.
brc cdk app render	Render the edge-app Deployment and Service to YAML without applying them.
brc cdk app deploy	Deploy the edge-app into trirematics as a detached Helm release (--wait=false to return immediately).
brc cdk app status [name]	Show where a detached edge-app runs, whether it is ready, and the Service it is reached on.
brc cdk app logs [name]	Print the logs of a detached edge-app (--tail, -F to follow).
brc cdk app delete [name]	Remove a detached edge-app and everything its release created.
brc cdk app model build	Render the CompositionModel that runs the edge-app as a managed Element, without installing it.
brc cdk app model install	Install or update that CompositionModel; reference it from a Network's edge: section.
brc cdk app model delete	Remove the edge-app's CompositionModel once no Network uses it.

The xApp and edge-app commands share the same registry and end in the same place, an Element of a Network. Only the edge-app path can also run outside any Network:

The CompositionModel the CDK produces contains one deployment-mode per xApp, each with the xapp role, the e42ap port (36422/sctp) used to reach the Near-RT RIC, and an Athena manager sidecar that renders the xApp's runtime config and connects it to the RIC declared in the same Network.

CDK training labs

The two labs that follow continue directly from xApp Training — Lab 5 (KPM+RC xApp for RAN Slicing):

1. Lab 1 — Packaging an xApp into a CompositionModel: take the RAN-slicing xApp you ran on bare-metal and turn it into an image + a CompositionModel published to the cluster-local registry.
2. Lab 2 — Deploying your xApp through the Network CRD: add that CompositionModel to a Network so Athena runs your xApp as a managed Element, wired to the RIC — the productionized version of Lab 5.

The third lab does not depend on the first two:

3. Lab 3: Deploying your AI-enabled application as an edge-app: containerize an AI inference web service, push it to the cluster-local registry, run it at the edge either detached or as a managed Element of a Network, and reach it from a UE.
4. Lab 4 (experimental): Streaming a CARLA camera over 5G to an edge-app: builds on Lab 3. A soft UE carries the camera of a vehicle driving in the CARLA simulator and streams it over the 5G network to the YOLO edge-app.