Skip to content

5. Build your own xApp Dev Environment⚓︎

In certain use cases, the developer will need a more flexible approach than the xApp Dev environment. For example:

  • Edit the xApp Helm Chart
  • Add another Docker image to the xApp
  • Add certain files or packages to the xApp Core

In such cases, deploying the xApp Dev Environment will not be sufficient, as you don’t have such options. However, in this case you can create your own xApp Core Docker image, including any additional files you need to it, as well as edit the default xApp Helm Chart to create one specific to your xApp, including any additional Docker images. You can then enable the Developer Mode on your own xApp to have the same options as in the xApp Dev Environment.

In the following subsection, we assume that you are on the dRAX host machine, so the Docker image built will already be present on the dRAX machine, as well as the helm chart.

5.1 Clone the xApp Framework Git repository⚓︎

To do so, you can first clone the xApp Framework GitHub repository:

git clone https://github.com/accelleran/xapp-framework-package.git

NOTE: You will need to contact Accelleran and provide a GitHub username so that we can grant you access to this repository.

5.2 Edit and build your xApp Core Docker image⚓︎

This repository contains the xApp Library, as well as an example on how to build your own xApp located in the example folder. To build your own xApp Core Docker image, we provide the default Dockerfile. There are two Dockerfiles:

  • Dockerfile - Used to generate the production version of the xApp
  • Dockerfile.dev - Used to generate the Development Environment version of your xApp

You can, therefore, edit the Dockerfile.dev according to you own needs and initiate a build by issuing the following command:

cd xapp-framework-package/example

sudo docker build -t my-xapp:0.1.0 --build-arg username=<GITHUB_USERNAME> --build-arg token=<GITHUB_TOKEN> -f Dockerfile.dev .

Here:

  • my-xapp: This is the name of your xApp Docker image, which we will need to also provide to the Helm Chart
  • 0.1.0: This is the version of the Docker image. We follow the semver versioning, so we also advise you to do the same
  • <GITHUB_USERNAME>: Replace this with the GitHub username that has access to the xApp Framework GitHub repository
  • <GITHUB_TOKEN>: This is the security token of your GitHub account

5.3 Prepare the xApp Helm Chart⚓︎

Once the Docker image is built, we need to prepare the xApp Helm Chart. The default xApp helm Chart is available in the example folder of the xApp Framework Git repository. Therefore, go to the following folder:

cd example/helm_chart/xapp

We need to edit the values.yaml file to point the xApp Helm Chart to use our previously built xApp Core Docker image. In our case the <app-name> is my-xapp, <xapp-version> is 0.1.0. Therefore, edit the values.yaml accordingly:

...

image:
 repository: <xapp-name>
 tag: "<xapp-version>"

...

You are of course free to now edit the xApp Helm Chart in any way you see fit, for example adding another Docker image to it, which we explain in the section How to add another microservice helm chart to the xApp.

5.4 Deploy your xApp in Developer Mode⚓︎

You can now deploy your xApp in Developer Mode, which will grant you the same options as the xApp Dev Environment. Your xApp will be deployed as a sandbox environment, which you can access, further develop and debug, start or stop the xApp, etc.

To do so, run the following command on the dRAX host machine:

helm install <xapp-name> /path/to/xAppHelmChartFolder --set developerMode.enabled=true --set-string global.kubeIp=<drax-host-ip>

NOTE: You can give the deployment any generic name you want by changing the <xapp-name>. When deploying from the command line, using helm install, we also have to supply the dRAX Host IP as the global.kubeIp parameter in helm.

From this point on, you can use any of the development workflows as described in the Development Workflows section.

5.5 (Optional) Mount a host folder inside your xApp⚓︎

The xApp Helm Chart also has an optional feature, which is to mount a folder from the dRAX host machine inside the xApp Core container. This can be useful:

  • The files located in that mounted folder will be shared between the host and xApp Core
  • When the xApp is deleted, the files in the mounted folder will still be present on the host machine
  • Provides an easy way to share files from the host to inside the xApp Core

To enable such a folder, edit the helm install command used during the deployment of the xApp as follows:

helm install <xapp-name> /path/to/xAppHelmChartFolder --set developerMode.enabled=true --set developerMode.hostPath=/path/to/shared/folder/on/host  --set-string global.kubeIp=<drax-host-ip>

NOTE: The developerMode.hostPath uses the absolute path to a folder on the host machine. This folder will be mounted by default to the following folder inside the xApp Core container:

/home/xapp/xapp_core/dev.

You can, for example, mount the whole example folder from the xApp Framework git repository, making the python files automatically saved on the host machine. This way even if you delete the xApp, your code will be preserved. Also, if you deploy another xApp, you can mount the same folder into it, getting your code into the second xApp automatically.

Back to top