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 cooperation effort between Comcast, Sky, Liberty Global, RDK-M and Consult Red. The work for this is co-ordinated by RDK DAC Special interest 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 , the solution described on this wiki page describes/focuses on, is focused on RDK-V but many of the principles/same components are also suitable for RDK-B.
...
For information on how to really make DAC app and use DAC SDK we refer to to HOWTO to build your native App with DAC SDK and publish to RDK-M DAC cloud, cloudpublish and run on VA#useDACSDKandbuildyourfirstnativeDACapp
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.
...
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.
The core components in any RDK software image to run the Appscontainer on CPE are "Dobby" and "crun". Dobby is an 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. For more information on Dobby, see following wiki Dobby and for crun see the crun code repo.
Before being able to run the Appcontainer successfully on RDK CPE, other pieces are needed as well.
Some pieces may be operator-specific such as the UI to discover, store and run the apps but also not all operators will be using RDKshell as Appmanager and some will use alternative component to LISA for installation of apps. Also some may have system to distribute, store the apps onto the device without UI/user involved.
Operator device software must meet DAC contract for binary compatibility. That means following firebolt native abtraction Following firebolt native abstraction interfaces need to be in place: Rialto for audio, video & DRM and libGLESv2.so.2, libEGL.so.1, libwayland-egl.so.1 and libessos.so for Graphics. Also a Firebolt Server json-rpc server (which is "ripple" in RDK 6.1 reference environment) that supports current and upcoming Firebolt api version must be in place and pass certification tests (currently version 1.0 but we are working on and aim at 2.0 eg Lifecycle2 is required for native apps)
The RDK Video Accelerators running their RDK6.1 software image are the reference environment for RDK. They use the components as shown in the reference architecture diagram (VideoAccelerator UI, RDKshell with RialtoServermanager support, LISA, OCIcontainer rdkservice, OMI, ripple, westeros, dobby, crun. The Video Accelerator Resident App includes basic UI for working with DACapps. That UI allows you to browse and install DAC apps from the Appcatalog offered by ASMS in the DAC cloud instance setup for VA's. For demo video and more information on how to use that UI see video1 and video2.
That VA UI code uses LISA API to get list of all installed apps at boot and obviously to install or uninstall for installing/uninstalling specific app.
For installation of an a specific App, UI will request appropriate bundle_url for this ask for a particular app_id/app_version/HWplatform/compatibleFWversion combination to the the bundl_url to ASMS in DAC cloud and pass this bundle_url to LISA along with the install request for install. LISA will do download of that bundle_url (https pointing to bundle tarball on That URL will be https url pointing towards ASCS in DAC cloud with path towards actual (signed/encrypted) bundle tarball there. LISA will do the HTTPS request for that bundle tarbal. In regular case that bundle tarbal will be available in cache of ASCS or CDN in front will return that tarbal and hence when LISA does the HTTPS request for that bundle tarbal, ASCS will be returned immediately with HTTP 200 OK when it is available in cache. In case that bundle is not available in the cache yet (is the case when the bundle for that combination was not already pre-generated or requested by 1 other stb of same model), the ASCS will trigger ASBS in DAC cloud to automatically on the fly create the bundle for that combination on the fly (near Just in Time, eg 1-5 seconds order) and populate in the ASCS for download by LISA. In such "not in cache" case ASBS will return 202 iso 200 to LISA to indicate the delay near Just in Time generation and few seconds of patience. LISA has built-in, tunable by config, retry mechanism in case of such 202 so that it will also download the bundle in case of such near Just in time generation.
When successfully downloading the tarball LISA will unpack it in the appropriate directory locations it created for it, also create a separate persistent storage location for that app and add the app_id / version to its local database.
For more information on LISA we refer to LISA wiki https://wiki.rdkcentral.com/display/ASP/LISA
When the user wants to run one of the installed apps, the VA UI interfaces with requests RDKshell, as the Appmanager, requesting it to start this app of type dac.native with as input the path to the unpacked associated bundle created as stored by LISA.
RDKshell will create westeros wayland server instance/display socket for the app, based on metadata create RialtoServer instance for the app or not and further delegate startContainer((when needed), when Firebolt app interact with Firebolt Server (ripple) to get session_id for this app (is like security token, app needs when later connecting to Firebolt Server) and further delegate startContainer(bundle_path, westerosSocket) to OCIContainer thunder plugin which will in case of signed/encrypted container trigger the OMI component to verify signature and decrypt config.jwt in the crypted bundle and decrypt, verify and mount the rootfs of the Appcontainer rootfs using dm-verity & dm-crypt so it is ready to be consumed. Then the startContainer request is further delegated to Dobby which uses crun to execute it.
They will setup the container according to the associated run config.json. Associated , including bind mount mounts from STB host rootfs to Appcontainer rootfs of appropriate wayland and rialto server socket will occur, as well as bind mounts of SoC specific Gfx library deps tree which (that provide libGLESv2.so.2 and libEGL.so. 1 )
When the dac.native app is a firebolt App, the specific Firebolt connection url for to useURL with session_id as security token, will be passed ( through the chain of RDKshell, OCI Container, dobby/crun ) and become be available to the App as an environment variable inside the AppContainer.
-----
For more information on Dobby, see following wiki Dobby and for crun see the crun code repo.
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.
Container. The app can then learn its value and use it when setting up connection with Firebolt Server.
Referring to the documentation HOWTO build App with DAC SDK, cloudpublish and run on VA
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 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 but for use within monolithic STB software image, not for device agnostic building and downloading separately from monolithic image what DAC is achieving.
Image source: https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/
...
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.
draw.io Diagram | ||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
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
...