RDK Resources
[*RDK Preferred*]
Code Management Facility
RDK Forums
[RDK Conferences]
RDK Support
Archives
Papers & Presentations Archive
Downloadable Application Containers (DAC) is an RDK initiative and co-operation effort between Comcast, Sky, Liberty Global, RDK-M and Consult Red. The work for this is co-ordinated by RDK DAC Special interest Group (RDKDACSIG)
The DAC end goal is to provide a solution that allows app developers to write and package also native (c/c++) Applications in a way that makes the application binary exchangeable and can be run across all RDK boxes without (compile time) modifications.
This group initially focused on RDK-V and that is what this wiki page describes/focuses on, but many of principles/same components are also suitable for RDK-B.
The diagram above provides a high level overview of the DAC solution.
It is divided into 4 functional areas:
This video made by ConsultRed at TechSummit2024 nicely explains bigger picture: dac_overview_rdk_tech_summit_2024_1080p.mp4
Below is a more detailed diagram with technical components inside the RDK6.1 SW on STB and DAC reference cloud
3 functional area's are further discussed in sections below
A DAC SDK has been developed to make it easier for AppDevelopers to develop and build oci, dac ompliant containerized applications. The SDK is public, fully open source and uses standard Yocto 3.1 Dunfel Poky environment. The DAC SDK can run a developer workstation, does not require any proprietary or SoC specific code to be able to build your application. It is available on https://github.com/rdkcentral/meta-dac-sdk The SDK allows developers to write Bitbake recipes that compile their code and produce an OCI compliant AppContainer image. This OCI image can then be uploaded to an OCI registry for sharing the binary AppContainer with possible consumers. Appdeveloper can then also register and publish its application to RDK-M DAC Cloud for Video Accelerator where it will be automatically converted to bundles that allow to be downloaded and run on any RDK6.1 Video Accelerator independent of its SoC beneath.
Fore more information on DAC SDK we refer to HOWTO to build your native App with DAC SDK and publish to RDK-M DAC cloud
To support the STB components, backend/cloud infrastructure has been developed. These components allow operators to create application submission portals where developers can submit their applications and their corresponding metadata. These submitted applications can then be converted from an OCI image to an OCI bundle ready for use on an operator's specific hardware.
The AppStore Metadata Service (ASMS) component provides APIs for both a developer and an STB to use to upload application metadata and search for previously uploaded applications. More documentation on ASMS can be found here: App Store Metadata Service (ASMS)
The BundleGen tool is a command-line tool that runs in the cloud to prepare containers for use on specific platforms. It uses template files created by an operator to ensure that the container is configured appropriately for the specific hardware requirements of an operators STB. This includes but is not limited to graphics libraries, sockets, IPC and network configuration. More detailed documentation for BundleGen can be found here: BundleGen
In later stage DAC cloud µServices for automatically creating bundles and securing them (signing and encryption) have been contributed. For summary overview documentation on that we refer to DAC session at Technology Summit 2023#pane-uid-b13cbeba-87dc-4f0a-9932-5b7e00770663-1 Documentation on DAC security is available to access restricted page DAC Security
DAC provides all the necessary tooling to run containerised applications using OCI containers on an RDK-V STB. The main component of this is Dobby, an embedded-focused OCI container manager. Dobby is used to start, stop and monitor containers running on a STB, using the crun runtime underneath to interface with the kernel and start the containers. Dobby is written in C++ and designed to have minimal footprint and performance impact. The OCIContainer Thunder plugin allows for interfacing with Dobby using a JSON-RPC interface, and Dobby can also be used to run other Thunder plugins in containers using the ProcessContainer backend.
For more information on Dobby, see the detailed documentation here: Dobby
As part of DAC, the RDKShell plugin has been extended to allow starting DAC apps using Dobby, creating a display and attaching it to the containerised app as necessary. RDKShell also integrates with the Packager plugin to provide a full-featured solution for downloading, installing and lifecycle management of DAC apps. For more documentation on the RDKShell and Packager integration see RDKShell and LISA/Packager. See the Getting Started section below for an example of using these components together.
Used heavily in modern cloud software, containers are a standardised way to run the software in a self-contained, isolated and secure environment. Containers contain everything an application needs to run, including code, libraries and other dependencies. This means that there is no need to install specific libraries and dependencies on the host for each application. Unlike more traditional virtual machines, containers are lightweight and fast to create and destroy and don't have the overhead of virtualising an entire operating system. By sharing the OS kernel between containers, running applications inside containers adds very little performance or footprint overhead.
The most popular containerisation solution currently in use is Docker, although there are a number of other solutions such as LXC, Singularity and Podman. LXC containers have been available within RDK for a number of years, using a container generation tool at build time to define and create the container configurations.
Image source: https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/
There are a number of advantages of using containers to run applications in RDK deployments, including:
As part of the DAC initiative, containers are used to reduce the difficulty of developing native applications that can be run on many different RDK-V devices from different operators by creating an isolated environment for each application. This means the app becomes platform agnostic and can be run on devices the develop may not have physical access to.
From the Open Container Initiative (OCI) website (https://opencontainers.org/):
The Open Container Initiative is an open governance structure for the express purpose of creating open industry standards around container formats and runtimes.
Formed in 2015 by Docker and other companies in the container industry and now part of the Linux Foundation, OCI define a number of specifications that allow developers to define containers. These specifications are followed by almost all major containerisation platforms.
OCI define both a runtime specification and an image specification. The Runtime Specification outlines how to run a “filesystem bundle” that is unpacked on disk. The OCI image is used for packaging containers in a platform-agnostic way that can be easily distributed. At a high-level, an OCI implementation would download an OCI Image then unpack that image into an OCI Runtime filesystem bundle. At this point the OCI Runtime Bundle would be run by an OCI Runtime.
An OCI runtime is a CLI tool that allows for spawning and running containers according to the OCI specification. There are two main OCI runtimes in production use:
Refer to the the documentation here HOWTO to build your native App with DAC SDK and publish to RDK-M DAC cloud