Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Next »

1. Introduction

With the i-PRO Camera SDK that supports Container AdamApp, you can run containers with various configurations in the i-PRO camera by describing the app configuration in a Docker compose configuration file. This allows you to create new feature extension software in the form of a Docker container, and if you have already developed a Docker container that runs on another server or device, you can easily run it on the camera by porting it according to this document. This document explains how to create a Container AdamApp with multiple containers using the docker_multi_images sample app included in the SDK as an example.

2. Overview

2.1 Guidelines for choosing app configurations for different users

Please refer here for information on which to choose between the existing AdamApp, Container AdamApp for AzureIoT, and the ext version of Container AdamApp.

For ext format Container AdamApp, the container configuration can be specified in the Docker compose configuration file (docker-compose.yaml). In the docker-compose.yaml file, you can start multiple containers by specifying multiple service names.

Below is a conceptual diagram showing the difference in configuration between the conventional AdamApp and Container AdamApp.

The above is a conceptual diagram of running multiple containers within one extension software (one ext format binary), but since the new X Series cameras allow for multiple apps to be installed, it is also possible to run multiple independent apps simultaneously.

The following are guidelines for selecting the configuration depending on the application.

No.

Use Cases

Configure the app

Conceptual diagram

1

If you want to containerize an app that has already been developed using i-PRO CAMERA SDK

An existing app is simply containerized, creating one app with one container configuration

2

If you want to port an AI app developed for a device other than the i-PRO camera to the i-PRO camera

One app with one container configuration, replacing the AI ​​functions and video acquisition parts of the existing app with the ADAM API

3

If you want to easily port an app that does not have AI functions and has been developed for devices other than the i-PRO camera to the i-PRO camera

One app that consists of two containers: one with management functions for i-PRO cameras and one that runs existing apps.

4

If you want to port an app with multiple container configurations, such as OSS, that has been developed for devices other than the i-PRO camera to the i-PRO camera

A container with management functions for i-PRO cameras and one application with multiple existing container configurations

5

If you want to port two loosely related apps that do not communicate directly between each other and are developed by different companies to an i-PRO camera

Two apps

6

If you have multiple apps that want to use the ADAM API

Two apps

2.2 Configuration for developing apps with multiple containers

The docker_multi_images included in the SDK is a sample app that can be used as a reference if you choose use case 3 or 4 in Chapter 2.1. The docker_multi_images sample app consists of two Docker images.

  • docker_multi_images image
    It exists to start and stop the application from the camera body and to respond to keep-alive messages. In this document, it is called the "main image." Also, the container generated from this image is called the "main container." The sample application only runs an event loop and waits. It is built with i-PRO CAMERA SDK.

  • web image
    This image is based on the lightweight version of nginx published on DockerHub, with only the default configuration file (default.conf) replaced. This document calls it a "subimage." Also, a container generated from this image is called a "subcontainer." It exposes nginx's TCP 80 port to the outside as TCP 8081 port and accepts http requests from external devices. When creating Container AdamApp, it must be built as a Docker image in advance.

If you want to run an existing container on an i-PRO camera, you can add the docker_multi_images image for management from the camera, and the existing container can be run on the camera with minimal changes.

2.3 Porting Considerations

When running an existing container on an i-PRO camera, you need to consider the following three points:

  • Are there enough RAM/ROM/CPU resources?

  • Does it comply with the i-PRO camera security policy?

  • Is there only one container that uses the ADAM API?

These are explained below.

2.3.1 RAM / ROM / CPU resources

Please see here for resources on how the new X-Series cameras can be used to extend the functionality of your applications.

Please make sure the app you are porting can work within these limits.
RAM/CPU limits are enforced by cgroups. If RAM usage exceeds the limit, the app will be killed by the OOM Killer.

2.3.2 About our security policy

For more information on Container AdamApp's security policy, please see here.

Special porting considerations are discussed.

  • Containers cannot be run with root privileges. The app runs in the camera with user privileges of uid 1000, gid 1000.

  • The container is mounted read only.
    You cannot write to the container. If an existing app is writing to the container, it will need to write to a tmpfs for temporary data, or to a separate mounted volume for persistent data.

  • Options that relax security, such as --previledged, cannot be used.

  • Images cannot be pulled from an external container registry directly from within the camera. The required images must be pulled and built on the development PC and included in the ext file.

2.3.3 Restrictions on using ADAM API

If Container AdamApp contains multiple containers, the ADAM API can only be used from the main container, not from subcontainers.

If you want to use camera functions, we recommend implementing them in the main image, and if you want to run general-purpose functions that are not camera-dependent directly on the camera, we recommend implementing them in the sub-image. Data sharing between the main image and sub-image will be explained in Chapter 3.4.

3. Development Procedure

3.1 Create a project

Preparing the project directory

Copy iPRO_CAMERA_SDK/src/adamapp/docker_multi_images included in the SDK sample app and rename it to any name. It is recommended to use lowercase for all directory names to make it easier to understand if the directory name matches the image name of the main image.

Convert the string "docker_multi_images" contained in container/docker-compose.yaml to the name of the main image in one go.

There is no need to change the main image binary (multiImages). If you want to change it, you will also need to edit Configuration.txt and Makefile.

App information description

Open configuration.txt and edit the following items.

  • App Version Name
    This is the version information displayed on the camera browser management screen. It is easy to understand if you match it with the tag name of the main image.

  • App Name
    This will be the app name displayed on the camera browser management screen. It can be written in any language.

  • Resource Related Information
    Describes the ROM/RAM/CPU usage (declared value) used by the app. This is used to check whether the total of the values ​​declared by other apps at the time of installation exceeds the limit. If the total of the declared values ​​of all apps exceeds the limit, the app will fail to install.

  • License related information
    Please specify the FUNC ID assigned by i-PRO.

3.2 Preparing the sub-image (the image to be ported)

If you want to port an existing container image, create it as a subimage.

The SDK build script does not build sub-images, so developers must prepare the images themselves in advance.

Build a sub-image using a separate Dockerfile or Docker Compose. Specify arm64 as the architecture (platform) when building.

The following explains how to prepare the nginx image included in docker_multi_images as an example.

  • The docker_multi_images/web directory contains the files required for the nginx image.

  • Navigate to the web directory.

    cd [iPRO_CAMERA_SDK directory]/src/Aadamapp/[app directory]/web

  • Build the docker image.

    docker build -t web:0.0.1-arm64v8 .

  • Verify that the Docker image is built and exists in your development environment.

    docker images

    Example output

    $ docker images
    REPOSITORY                TAG                         IMAGE ID       CREATED         SIZE
    web                       0.0.1-arm64v8               78a72756f85e   16 hours ago    16.6MB

3.3 Editing docker-compose.yaml

Write information about the sub-image in docker-compose.yaml.
For information on how to write docker-compose.yaml, please see here etc.

The docker-compose.yaml you edit here will be executed in the camera when the app starts. You cannot use the build command in the file.

  • Add the sub-image information to the child level of the services key. This is already written in the sample app, so we will explain the contents here.

  • The complete description of the web service is as follows:

    image-20240909-101606.png

  • images:
    Here you specify the image name and tag created in 3.2. If the image specified here does not exist, the app build script will fail.

  • networks:
    If you want containers to communicate with each other, they must specify the same network.

  • restart:
    Specifies how to recover when the container is terminated. In the case of ext format Docker, the main container is monitored by the camera firmware without using Docker mechanisms, so specifying "no" will restart it appropriately. On the other hand, subcontainers are not monitored by the camera firmware, so set it according to the actual operation.

  • ports:
    If the sub-image exposes a port that can be connected from outside, describe it in the format of [camera side]:[container side].

  • volumes:
    Describes volumes and bind mounts.
    Only volumes defined in this docker-compose.yaml can be specified for volume. In addition, volume names defined here must also be separately listed in the volumes: section at the top of the yaml file.
    There are restrictions on directory paths that can be bind mounted.

  • tmpfs:
    Security policies prevent writing to containers, so if there are directories under /var where apps temporarily store data, specify them here.
    In the case of nginx, it writes to /var/cache/nginx and /var/run, so these are specified as tmpfs.

  • Required parameters
    The following parameters must be added to satisfy the security policy of the i-RPO camera. Please copy and paste as is.

        read_only: true
        user:
          1000:1000
        cap_drop:
          - "net_raw"
        security_opt:
          - "label=type:ipro-container.process"
          - "no-new-privileges"
        labels:
          com.i-pro.app-type: "ext"
          com.i-pro.device-category: "CV5x-A"
          com.i-pro.device-vendor: "i-PRO"
  • Listing root-level volumes
    Enter the volume name in the volumes: section under the root of the yaml file.

    image-20240801-032019.png

3.4 独自の機能を実装する

3.4.1 コンテナ間の通信やデータ共有

メインイメージ・サブイメージ間や、コンテナとカメラ間でデータをやり取りするには以下の方法があります。

  • volumeを使用する。
    docker-compose.yamlに記載することでvolumeをコンテナ間で共有することができますのでこの中でデータをやり取りできます。ただしこの領域はFlashROM上となり、寿命に影響がありますので大量なデータのやり取りには向きません。

  • 共有が許可されているtmpfsを使用する。
    ADAM_GetTmpDirPath() APIで取得できる領域はtmpfs上にあり、一時的なデータ保存用として利用できます。
    サブコンテナからこの領域にアクセスするためには、docker-compose.yamlのサブイメージの記述内のvolumes: に以下を追加します。

          - type: bind
            target: "/dev/shm/Adamapp"
            source: "/dev/shm/Adamapp"
            read_only: false
            consistency: default

    ただし、サブコンテナからはADAM_GetTmpDirPath()を呼ぶことができませんので、別途volumeを使う方法などでメインコンテナからパスを通知する必要があります。

  • HTTP経由で取得する。
    Dockerでは各コンテナに仮想のIPアドレスが割り当てられるため、こちらを利用して、カメラ外と同様にWebAPIを呼ぶことができます。また、docker-compose.yamlのhostnameキーでドメイン名を指定すると、この名前で通信を行うこともできます。
    メインコンテナでは、ADAMの仕組みとして、sendDataToAdamApplication WEB APIを使用して通信を行うことができます。この仕組みはカメラ本体がメインコンテナにデータを仲介する方法ですので、あて先はカメラ本体のIPアドレスとなります。
    また、同様にカメラのCGIを利用してカメラ本体の設定値などを取得することができます。

コンテナ内から仮想環境上のカメラ本体のIPアドレスはコンテナ内から/etc/hostsを参照し、一番最後のエントリの最下位バイトを1にしたものとなります。

WebAPIでアクセスする際、カメラのユーザー名・パスワードの指定が必要です。

3.4.2 サンプルアプリの実装例

docker_multi_imagesサンプルアプリではコンテナ間ネットワークのDNS機能を使用し、メインコンテナからコンテナ名でサブコンテナへhttpリクエストを出すサンプルコードを実装しています。
${SDK_DIR}/adamapp/docker_multi_images/main.cpp の response_by_html関数内で以下の様にcurlでリクエストを行うsystem関数を呼び出しています。 ここで “web” はdocker-compose.yamlに記載されているサービス名となります。

	char cmd[256];

	snprintf( cmd, 256, "curl http://web/index.html > /tmp/local/index.html");
	if( system(cmd) != 0 ) {
		ADAM_DEBUG_PRINT(ADAM_LV_ERR, "system error (%s)\n", cmd);
	}

カメラブラウザの「ソフトウェア管理画面」に表示された、「Dockerマルチイメージ」アプリの「設定画面へ」ボタンを押下することで、このコードが呼び出され、webコンテナのindex.htmlの内容をそのままブラウザに表示します。

3.5 アプリのビルド

開発環境構築については下記を参照ください。

開発環境構築(Install development environment編) - Technology Partner - Confluence (atlassian.net)

アプリ開発方法やビルドについては下記を参照ください。

開発方法(how develop編) - Technology Partner - Confluence (atlassian.net)

 

  • No labels