Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Expand
titleTable of Content

Table of Contents
maxLevel3

Introduction

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)

...

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.

Solution Overview

The diagram above provides a high level overview of the DAC solution.

...

Multimedia
namedac_overview_rdk_tech_summit_2024_1080p.mp4

reference Architecture

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

APP SDK

A DAC SDK is created to make it easier for app developers to build oci, dac compliant containerized applications. The SDK is public, fully open source and uses standard Yocto 3.1 Dunfel Poky cross-compilation / build environment. It does NOT require you as an App developer to have any SoC or OEM specific SW/SDK for being able to compile and package your AppContainer, it is SOC/OEM agnostic. The SDK allows developers to cross compile their application sources, automatically add appropriate dependent libraries in AppContainer and produce oci, dobby, dac compliant AppContainer image. This binary oci AppContainer image can then be uploaded to an OCI registry for sharing with possible consumers/distribution platforms. As App developer you can test and run your AppContainer on all RDK6.1 RDK-M Video Accelerators (when publishing the App to RDK-M VA DAC cloud instance)

...

For information on how to really make DAC app and use DAC SDK we refer to HOWTO to build your native App with DAC SDK and publish to RDK-M DAC cloud

OCI container registry

OCI container registry: is a standard Cloud Native component that allows storage and exchange of AppContainers in the standardized oci image format. see oci "Image Format Specification" by Open Container Initiative.

...

The OCI registry is the binary App exchange point between App developer and consuming parties/operators for distribution of the App on their target platforms.

DAC Cloud reference

To run the oci compliant AppContainer on set of devices in production, an associated secure distribution solution/system must be in place.
This distribution solution is responsibility of the operator and not of the app developer. 
It is typically also a distribution system / instance per operator/environment because: 

...

That is what the reference DAC cloud system is doing. Once bundle for particular app_id/platform/compatible version is created, it will be available in cache of ASCS (Appstore Caching service) (which can serve as the origin for further caching on a CDN). If you request bundle for particular app_id/platform/compatibleversion towards ASCS and if it is not available in its cache it will automatically trigger real time creation of associated bundle in a flow managed by ASBS (appstore bundle service). ASBS will fetch appropriate metadata from ASMS and give instructions with right input parameters to respectively bundle-generator-service and bundle-cryptor-service via RabbitMQ to generate and secure the bundle and cache on ASCS. 

STB / CPE

The core components in any RDK software image to run the Appscontainer on CPE are "Dobby" and "crun". Dobby is OCI Container manager aka container engine comparable to known desktop container engines dockerd and podman but then focused on embedded device, written in C++ and designed to have minimal footprint and performance impact.
Crun is an opensource container runtime alternative to "runc" equivalent but written in C, has smaller footprint but is also well supported by the industry (is for example default container runtime used by podman)
Dobby exposes API and 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.
When requested to start a new container, crun will process the associated container configuration (run config.json) and apply the associated container policies/settings.
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 Dobby ProcessContainer backend.

...

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.


Background and Terminology

What are Containers?

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.

...

Image source: https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/

Why use containers in RDK?

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.

Open Container Initiative (OCI)

From the Open Container Initiative (OCI) website (https://opencontainers.org/):

...

draw.io Diagram
bordertrue
diagramNameOCI
simpleViewerfalse
width600
linksauto
tbstyletop
lboxtrue
diagramWidth951
revision1

OCI Runtimes

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:

Crun

  • Repo: https://github.com/containers/crun
  • Crun is an alternative implementation of an OCI runtime, this time written in C and optimised for performance and a low memory footprint. It is developed and supported by RedHat and is currently in use by Podman in Fedora, and will be available in RHEL 8.3.
  • This is the runtime supported by Dobby and will be used as the default runtime across RDK.

Runc

  • Repo: https://github.com/opencontainers/runc/
  • Runc is the reference implementation of an OCI runtime and is developed directly by the OCI group. This is the runtime used by Docker, Kubernetes and others. However, being written in Go, it is less suitable for embedded STB environments due to a relatively large footprint.
  • Not officially supported in RDK


Getting Started for App Developers

Refer to the the documentation here HOWTO to build your native App with DAC SDK and publish to RDK-M DAC cloud 

...