y.takeuchi
2025年8月29日 14時18分
==========
製品型番：AG9130-C03Z
Debian/ABOSバージョン：
カーネルバージョン：
3G/LTE モジュール情報 (Debianのみ)：
その他：
==========
お世話になっております。
現在、以下のようなリモートアップデートの方式を検討しております。
1. クラウド(WebSocketサーバ)との接続
Armadillo上のコンテナ内でWebSocketクライアントを実装
2. アップデート処理
クラウドからアップデート要求メッセージを受信、
アップデート要求メッセージを契機に、クラウドからアップデートファイルをダウンロード
アップデートコマンドを実行
そこで、下記ブログを参考にしているのですが、
https://armadillo.atmark-techno.com/blog/15349/12602
ブログ内に以下の記述があり、私の構想でいくとコンテナ側がトリガーになることを懸念しております。
>《注意》
> リモートでのソフトウェアアップデートはArmadillo Base OS(ホスト側)がトリガーを出す事を推奨しています。
> コンテナ側をトリガーにした場合、コンテナが停止したりバグ等でトリガーを出せなくなった場合にアップデートが
> できなくなる事が考えられます。
上記を踏まえ、以下の点についてご助言をいただけますと幸いです。
1. コンテナ内でトリガーを持つ構成のリスク
2. このような構成でホスト側にトリガーを持たせる場合の構成、実装例(可能であれば)、注意点等
3. その他、そもそもの構成として見直すべきポイント等
よろしくお願い致します。
コメント
y.takeuchi
マルティナ様
ご返信、ありがとうございます。
構成に関して、概ね妥当とのことで不安が少し払拭できました。
(これから試験的な開発が始まるので、そちらで細かい部分は試行錯誤しようと思います。)
>個人的には、逆に shell の簡単な処理以外をあまり Base OS 側にインストールするとアップデート時の動作確認などが難しいので、
>提供している自動アップデートサービス（定期的に url を叩くと Armadillo Twin) を利用したくない場合はコンテナでの実装がいいと考えています。
自動アップデートサービスやArmadillo Twinは現時点では、利用を考えておらず、できる限り自前で作りたいと思っております。
それから、追加となり恐縮ですが、
コンテナからのSWUpdate実行について、本フォーラムにて質問してもよろしいでしょうか。
確認したい内容としましては、以下の通りです。
・コンテナからSWUpdateを実行する場合、ABOS WebのRest APIを呼び出す理解でおりますが、
他の手段等はあったりするのでしょうか。
よろしくお願い致します。
at_dominique.m…
マルティネです。
> 自動アップデートサービスやArmadillo Twinは現時点では、利用を考えておらず、できる限り自前で作りたいと思っております。
了解しました。
> それから、追加となり恐縮ですが、
> コンテナからのSWUpdate実行について、本フォーラムにて質問してもよろしいでしょうか。
> 確認したい内容としましては、以下の通りです。
> ・コンテナからSWUpdateを実行する場合、ABOS WebのRest APIを呼び出す理解でおりますが、
> 他の手段等はあったりするのでしょうか。
申し訳ございません、ABOS Web の Rest API 以外のコンテナからのアップデート方法を推奨してません。
どうしても ABOS Web を利用したくない場合は ssh 等でホスト側に接続してそこから swupdate を実行できますが、
アップデートの問題を減らすためにできるだけテストされている流れでのアップデートを推奨しています。
よろしくお願いします
at_dominique.m…
2025年8月29日 16時07分
y.takeuchi さん
お世話になっています、
マルティネです。
> そこで、下記ブログを参考にしているのですが、
> https://armadillo.atmark-techno.com/blog/15349/12602
> ブログ内に以下の記述があり、私の構想でいくとコンテナ側がトリガーになることを懸念しております。
> >《注意》
> > リモートでのソフトウェアアップデートはArmadillo Base OS(ホスト側)がトリガーを出す事を推奨しています。
> > コンテナ側をトリガーにした場合、コンテナが停止したりバグ等でトリガーを出せなくなった場合にアップデートが
> > できなくなる事が考えられます。
>
> 上記を踏まえ、以下の点についてご助言をいただけますと幸いです。
> 1. コンテナ内でトリガーを持つ構成のリスク
注意を書いた本人ではないので、どの意図で書かれたのがわかりませんが、単純なレイヤーの数の話で何かの理由で複雑な（機器の動作に必要な処理等も含む）コンテナより、ホスト側で確実に実行される個別のプログラムで実装した方が安全ということでしょうか。
Armadillo Base OS としてコンテナを起動できないことは致命的なので、基本的にコンテナを起動できないことはないと思いますが、万が一 appfs の故障等でコンテナを起動できなかったことがあればリモートアップデートで復帰できるなども含まれているかもしれません。
個人的には、逆に shell の簡単な処理以外をあまり Base OS 側にインストールするとアップデート時の動作確認などが難しいので、
提供している自動アップデートサービス（定期的に url を叩くと Armadillo Twin) を利用したくない場合はコンテナでの実装がいいと考えています。
（松本さん、何か追加したい注意あればお願いします！）
> 2. このような構成でホスト側にトリガーを持たせる場合の構成、実装例(可能であれば)、注意点等
ブログでは定期的に url を叩くだけですが、Armadillo Twin は説明していただいた処理とほぼ同じく、MQTT でクラウドからアップデート通知を受信して swupdate を起動します。
クライエントのソースは https://download.atmark-techno.com/alpine/current/atmark/src/ の armadillo-twin-agent で確認できますが、
1. に書いたようにこう言うプログラムを Armadillo Base OS にインストールすると弊社が提供している Base OS のアップデートを利用できなくなりますので、
あまり推奨できません。
> 3. その他、そもそもの構成として見直すべきポイント等
説明していただいた流れは妥当だと思います。
アップデートファイルのダウンロードは全部ダウンロードしておいてアップデートを起動するか、swupdate プロセスにダウンロードさせるか、ダウンロードしながれ swupdate プロセスにストリームするか等色々やりかたがありますので、そこだけメリットデメリットを検討した方がいいと思います。
よろしくお願いします