ryo_sakura
2025年1月7日 10時03分
1つのコンテナイメージファイルからコンテナアプリケーションの複製処理をすることは可能でしょうか？
以下例を記載します。
①映像データをクラウドへ送信するというコンテナイメージファイルを用意します。
②gw.iniファイルのファイルを用意します。内容は「cameras=cm1,cm2,cm3」（値はユニーク）。
質問
・②のgw.iniファイルの値ごと（cm1,cm2,cm3ごと）に①のコンテナイメージファイルを複製処理する方法はあるか
・swuファイル1つで以上の複製処理をする方法はあるか、そのときのプロジェクトのディレクトリ構成はどうなるのか
・他に方法はあるか
ご回答いただければ幸いです、よろしくお願いいたします。
==========
製品型番：
Debian/ABOSバージョン：
カーネルバージョン：
3G/LTE モジュール情報 (Debianのみ)：
その他：
==========
コメント
ryo_sakura
太田様
> 「複数処理」というのは具体的にはどのような処理をお考えでしょうか？
→複製処理について具体的には1つのゲートウェイに接続するされるカメラごとに①で作成したコンテナアプリケーションを複製していく処理を考えています。
gw.iniのcameras=cm1,cm2,cm3があるとすると
cm1（1つ目のカメラ）用の①のコンテナアプリケーション、cm2（2つ目のカメラ）用の①のコンテナアプリケーション、...とコンテナアプリケーションを立てることができるか
> また、その時にgw.iniファイルはどのような使い方を想定していますか？
→gw.iniはコンテナアプリケーションで使用する値を記載するファイルとして使用することを想定しています。
分かりにくくて申し訳ございません、よろしくお願いいたします。
at_satoshi.ohta
太田です。
ご説明ありがとうございます。
gw.iniは設定ファイルということですね。
gw.iniの設定値を見て、あるコンテナイメージからカメラの数だけコンテナを生成したいということでお間違いないでしょうか？
その上で、あと何点か教えて頂ければ幸いです。
- １つのコンテナイメージから１つのコンテナを生成し、そのコンテナの中で複数のカメラを管理する方法をとらない理由はありますでしょうか？
カメラごとにコンテナを立てたい動機が気になりました。
- gw.iniの内容はどのタイミングで決まるのでしょうか？
起動時に都度、gw.iniの内容が変化するのか、それともgw.iniはあるArmadilloについては不変の設定なのかなど気になりました。
コンテナ自動起動ファイル（confファイル）を使用できるか、それともコンテナを生成するための独自のシェルスクリプトを作成する必要があるのか考えています。
- カメラを1つ1つ区別して識別する必要がありますでしょうか？
もし必要であれば、udev rules でカメラを一意に識別して/devに固定した名前をつける方が楽かと思います。
質問が多くて申し訳ありません。よろしくお願いいたします。
ryo_sakura
太田様
> gw.iniの設定値を見て、あるコンテナイメージからカメラの数だけコンテナを生成したいということでお間違いないでしょうか？
→その通りですが、複数コンテナを立てるのにconfigファイルがあったら便利だと思った程度の理由なので、複数コンテナを簡単に立てられさえすれば別にiniファイルにこだわりはないです。
> - １つのコンテナイメージから１つのコンテナを生成し、そのコンテナの中で複数のカメラを管理する方法をとらない理由はありますでしょうか？
→1つのコンテナ内で複数のカメラを管理するとなると、1台のカメラで致命的なエラーが起こった際にコンテナが落ち、全部のカメラが稼働しなくなる可能性があるのではないかと考えており、1コンテナ1サービスがベストプラクティスなのではないかと考えております。
他にベストプラクティスはございましたらご教示願いたいです。
> - gw.iniの内容はどのタイミングで決まるのでしょうか？
> 起動時に都度、gw.iniの内容が変化するのか、それともgw.iniはあるArmadilloについては不変の設定なのかなど気になりました。
→gw.iniの内容を決定・変更するタイミングは起動時に都度と、顧客からGWへのカメラ追加の要望が来た場合（この時リモートでGWに接続しgw.iniの内容を変更する）です。
> - カメラを1つ1つ区別して識別する必要がありますでしょうか？
→はい、その通りです。
基本的にこちらが行いたいことは以下の通りです。
・カメラ映像をクラウドに送信するサービス
・ゲートウェイとカメラが一対多である
・1コンテナ1サービスがベストプラクティスだと考えている
内容のご確認お願い致します。
at_satoshi.ohta
太田です。
詳細な情報ありがとうございます。
gw.iniを使用した方法の１つとして以下が考えられると思います。
1. /etc/local.d内に起動時に実行されるシェルスクリプト（ここではgw.startとします）を用意します。
/etc/local.dに配置したシェルスクリプトは起動時に実行されます。
マニュアルのこちらの節をご参照ください。
https://manual.atmark-techno.com/armadillo-iot-g4/armadillo-iotg-g4_pro…
2. gw.startで、gw.initを読み込み、cameras=cm1,cm2,cm3,.. を参照してその数だけコンテナを生成します。
例えば、/var/app/rollback/volmes/gw.iniの内容が以下だとします。
cameras=cm1,cm2,cm3
/etc/local.d/gw.startの内容が以下だとします。
#/bin/sh
# clear environment
podman rm -af
rm -rf /etc/atmark/containers/cm*.conf
# read gw.ini
while read line; do
case $line in
*camera=*)
cameras=${line#*=}
cameras="$(echo $cameras | sed 's/,/ /g')"
;;
esac
done < /var/app/rollback/volumes/gw.ini
# create containers.
for camera in $(printf '%s' "$cameras"); do
conf="/etc/atmark/containers/${camera}.conf"
cp "/etc/atmark/containers/cm.conf.tmpl" "$conf"
# ここでそれぞれのコンテナに必要な固有の設定をconfファイルに追記する
[ -n "$conf" ] && podman_start $camera
donegw.startはgw.iniのcameras=cm1,cm2,cm3を参照して、/etc/atmark/containersディレクトリ内にcm1.conf, cm2.comf, cm3.confを生成します。
これらを生成するテンプレートとして予め、cm.conf.tmplを用意して置きます。
cm1.conf, cm2.comf, cm3.confはコンテナ起動設定ファイルです。
podman_startコマンドを実行すると、コンテナ起動設定ファイルに記述された設定を反映したコンテナが起動します。
コンテナ起動設定ファイルについてはこちらをご参照ください。
https://manual.atmark-techno.com/armadillo-iot-g4/armadillo-iotg-g4_pro…
もし、リモートでコンテナを再起動する場合は、gw.initを書き換えたあと、gw.startを直接実行すれば良いと思います。
また、１つ１つのカメラを識別したいとのことでしたが、こちらはUSBカメラであれば/dev/v4l/by-path以下に例えば次のように識別されます。
この機能を使用するだけで済むのであれば、udev ruleは独自に用意する必要はないかもしれません。
armadillo:~# ls -lstr /dev/v4l/by-path/
total 0
0 lrwxrwxrwx 1 root root 12 Jan 8 19:01 platform-vpu_v4l2-video-index1 -> ../../video1
0 lrwxrwxrwx 1 root root 12 Jan 8 19:01 platform-vpu_v4l2-video-index0 -> ../../video0
0 lrwxrwxrwx 1 root root 12 Jan 8 19:11 platform-xhci-hcd.1.auto-usb-0:1.2:1.0-video-index1 -> ../../video3
0 lrwxrwxrwx 1 root root 12 Jan 8 19:11 platform-xhci-hcd.1.auto-usb-0:1.2:1.0-video-index0 -> ../../video2上記のパスはcm.conf.tmpl内に以下の記述をすることでコンテナに渡されます。
add_hotplugs video4linux
add_hotplugsを使うのであれば、各コンテナに接続された全てのカメラのデバイスファイルが渡されるので、アプリケーション側で使用するカメラを選ぶ必要があるかと思います。
add_hotplugs については以下のURLから「ホットプラグデバイスの追加」の節をご参照頂ければと思います。
https://manual.atmark-techno.com/armadillo-iot-g4/armadillo-iotg-g4_pro…
ご参考になれば幸いです。
どうぞよろしくお願いいたします。
at_satoshi.ohta
ryo_sakura
太田様
ご回答いただきありがとうございます。
コンテナアプリケーションの複製についてイメージが付きやすくなりました。
そのうえで以下質問にお答えいただけると幸いです。
①カメラの不具合等によりアプリケーションがうまく稼働しなくなった場合に自動で再起動をかける方法はございますでしょうか。
②> もし、リモートでコンテナを再起動する場合は、gw.initを書き換えたあと、gw.startを直接実行すれば良いと思います。
→gw.initの書き換えとgw.startの実行はswuファイルでTwin上で実行できるのでしょうか。
以上よろしくお願いいたします。
at_satoshi.ohta
太田です。
> ①カメラの不具合等によりアプリケーションがうまく稼働しなくなった場合に自動で再起動をかける方法はございますでしょうか。
アプリケーションを再起動するのではなく、コンテナ自体を再起動する方法としては以下のように何通りか考えられます。
1. コンテナ起動設定ファイルに記述するコマンドに set_command があります。
set_command はコンテナ起動時に設定したコマンド（あるいはスクリプト）を実行するためのコマンドです。
例えば、コンテナ内にある/vol_app/src/main.shをコンテナ起動時に実行したいとすると、記述例は以下です。
set_command /vol_app/src/main.sh
set_command で指定したコマンドが失敗した場合（exit 0以外で終了した場合）、自動的にコンテナが再起動します。
そのため、カメラのアプリケーションをset_commandで実行すれば自動で再起動します。
2. また、コンテナ起動設定ファイルのコマンドの一つにset_healthcheckというものがあります。
set_healthcheckはコンテナ内の状態を定期的に確認するコマンドです。ただし、コンテナが停止した場合には機能しませんのでご注意ください。
例えば、/vol_app/src/main.sh内のスクリプトを以下のように設定します。
#!/bin/bash sleep 20 touch /healthcheck_failed sleep infinity
コンテナ起動設定ファイルの中身に以下が記述されているとします。
set_command /vol_app/src/main.sh set_healthcheck --interval "5 sec" --action restart test ! -e /healthcheck_failed
set_healthcheckの設定は、5秒ごとに「test ! -e /healthcheck_failed」を実行して、このコマンドが失敗した場合にコンテナを再起動する（--action restart）というものです。
この場合、コンテナが起動して20秒後に/healthcheck_failedが作成されます。その５秒後に「test ! -e /healthcheck_failed」が実行されます。このコマンドは失敗するので、その数秒後にコンテナが再起動されます。
--action には他の文字列も指定できて reboot を指定した場合は Armadillo 自体が再起動します。
マニュアルに記載がありますのでご参照ください。
https://manual.atmark-techno.com/armadillo-iot-g4/armadillo-iotg-g4_pro…
3. あとはABOS Web のRest API を使用する方法も考えられます。
例えば、Armadilloを再起動する場合は「POST "/api/reboot"」があります。
マニュアルをご参照頂ければと思います。
https://manual.atmark-techno.com/armadillo-iot-g4/armadillo-iotg-g4_pro…
> ②> もし、リモートでコンテナを再起動する場合は、gw.initを書き換えたあと、gw.startを直接実行すれば良いと思います。
> →gw.initの書き換えとgw.startの実行はswuファイルでTwin上で実行できるのでしょうか。
Twinから任意のswuファイルを送りswupdateを実行することができます。
swupdateはデフォルトでは処理が終了した後に再起動します。
そのため、descファイルでgw.iniを書き換えた後に再起動され、/etc/local.d/gw.startが実行されて書き換えた後のgw.iniを基にコンテナが生成される流れになります。
descファイルでgw.iniを書き換える場合、以下のコマンドを使用すればよいかと思います。
swdesc_command "rm -rf <Armadillo上のgw.iniのパス>" ★念の為Armadillo上のgw.iniを削除 swdesc_files --dest <Armadillo上のgw.iniのパス> <ATDE上のgw.iniのパス> ★新しいgw.iniをArmadilloのコピー
またはswdesc_commandでsedコマンドなどで直接 Armadillo 上のgw.iniを書き換えてしまう方法も考えられます。
どうぞよろしくお願いいたします。
at_satoshi.ohta
2025年1月7日 10時47分
太田です。
状況把握のために確認させてください。
「複数処理」というのは具体的にはどのような処理をお考えでしょうか？
また、その時にgw.iniファイルはどのような使い方を想定していますか？
どうぞよろしくお願いいたします。