アップデート機能の要件
Armadillo Base OS のアップデート機能は以下の要件を実現しています。
製品機能の維持:
- 耐障害性の確保 (突然の電源断、瞬断、ネットワーク断によってデバイスはブリックにならない)
- アップデート中でも製品機能を利用可能 (アップデートで特別なモードに入らない)で、アップデートを再試行ができる。外部からデバイス状態をできる限り観測可能
アップデート処理のガード:
- バージョンのダウングレードの防止
- ハードウェア種別の事前チェック
差分アップデート:
- ソフトウェアをできるだけ小さくするために差分アップデートに対応
- テキスト差分、バイナリ差分に対応
その他:
- ソフトウェアの署名、暗号化、圧縮
- btrfs を利用することでファイルシステムの書き換えが頻繁に発生する状況でもロバストに開発が可能
モジュールと管理情報
以下のモジュールがアップデート処理に重要な役割をもっています。
- SWUpdate
- SWU イメージの署名確認、解釈、ファイルの解凍、復号や、データ化け確認、イメージの書き込みなどアップデートの実処理を行います
- 実処理の前処理 (pre install)、後処理 (post inst) にスクリプトを実行します
- SWUpdate 用のスクリプト
- 前処理 (pre install)、後処理 (post inst) で Armadillo Base OS 独自の処理を実行します
- armadillo-twin-agent
- アップデート処理の状態管理、Armadillo Twin と連携します
- ブートローダー
- 起動失敗時に待機状態 (suspended) のArmadillo Base OS から起動します。この仕様はアップデート直後だけでなく通常時も有効です
アップデート処理に密接に関係する起動処理を含めて以下の情報があります。
| 情報 | 起動時の責務 | アップデート中の責務 |
|---|---|---|
| eMMC EXT_CSD (PARTITION_CONFIG) | boot partition 0/1のどちらが有効か判断するために利用される | なし。アップデート処理が終わった後で boot partition 0/1 が切り替えられる |
| GPT メタデータ | パーティションテーブル | なし。基本的に変更されない |
| uboot environment variables | Linux+rootfs パーティションの A/B どちらが有効か判断するために利用される | アップデート処理が終わった後で A/B が切り替えられる |
| btrfs (user application 用のファイルシステム) | コンテナデータを保管するファイルシステム | RO スナップショットを利用して、現Application をバックアップする |
| user application コンテナ | ユーザーアプリケーションを起動する | 書き込み対象 (コンテナ単位)。 すべてをアップデートも、コンテナレイヤーを利用して差分アップデートも可能 |
アップデートの処理フロー
Armadillo Base OS をアップデートした際の大まかなアップデートフローは以下のとおりです。アプリケーション(コンテナ)のアップデートを実行した場合も基本的には同じフローです。大きな違いは、Armadillo Base OS のアップデートを実行した場合には、デバイスは再起動の必要があるので一時的にデバイスが切断されますが、アプリケーション(コンテナ)のアップデートを実行した場合には、デバイスの再起動は発生しません。
- デバイスローカルにファイル展開する
- 署名を確認する
- ヘッダを解釈する
- pre install スクリプトを実行する
- 解凍してチェックサムを確認する
- イメージを書き込む
- post install スクリプトを実行し、A/Bの切り替えなどをおこなう
- 必要であれば再起動する
- もし起動に３回失敗したら A/B の切り替えを戻して前システムで起動する
製品機能の維持
ソフトウェアアップデート中もデバイスのソフトウェアが持つ機能をほぼ利用することができます。AV機能やネットワーク機能はそのまま利用できます。ソフトウェアアップデート処理は裏で動いています。そのため若干CPUとフラッシュへの書き込みにリソースを割くことになります。
Armadillo Base OS をアップデートした後は基本的に再起動が必要です。新しい OS が起動中には問題が発生して起動ができない場合もあります。その場合には、デバイス側はリカバリーモードで起動してサービスへの再接続を試み、サービス側はデバイスが再接続されることを待ち、結果的にエラーログを出力することになります。ユーザーアプリケーションをアップデートするときには再起動は発生しません。
A/Bアップデート (アップデートの2面化)
Armadillo Base OS のアーキテクチャでは、OSやブートローダー、アプリケーションなどフラッシュメモリのコンテンツを二重化して２つのパーティションに配置します。アップデートを行うときには、動作中のバンクには変更を加えず、通常動作をしながらスタンバイバンクをアップデートします。そのため、たとえ電源断、ネットワーク切断、ソフトウェアの問題による中断があっても動作中のバンクには影響ありません。アップデートが完了するとスタンバイしているバンクへと切り替えます。つまり、アップデートを繰り返すと交互にバンクを切り替えることになります。
リカバリー (ロールバック)動作
動作が不安定なソフトウェアを書いてしまい、システムが起動できなくなった際に自動的にアップデート前のシステムにロールバックする機能を提供します。ブートに必要なファイルが存在しない場合、もしくは、３回起動に失敗した場合に、スタンバイバンクからの起動を試みます。主に動作が不安定な開発フェーズを想定しており、セキュリティ上の懸念があれば市場運用で無効にすることができます。
アップデート対象とパーティション
以下の図は Armadillo Base OS 対応製品のパーティションレイアウトのモデルです。
| アップデート対象 | 書き込み単位 | 耐障害性 |
|---|---|---|
| bootloader | パーティション単位 | ２面化 |
| dtb + Linux kernel + rootfs | パーティション単位/ ファイル単位での書き込み | ２面化 |
| ユーザーアプリケーション | ファイル単位での書き込み/バイナリ差分 (podman container で実現) | btrfs のスナップショットによる冗長化 |
パーティションレイアウトは Armadillo の各製品ごとに差分があります。詳しくは各製品の製品マニュアルを参照してください。
ドキュメントダウンロード
起動、アップデートに関連する情報の耐障害性
| 領域 | 耐障害性 |
|---|---|
| GPT メタデータ | ２面化 |
| uboot environment variables | ２面化 |
| btrfs (ユーザーアプリケーション 用のファイルシステム) | meta のみ cow + dup |
| ユーザーアプリケーション用 コンテナ | RO スナップショット |
SWU イメージ
SWU イメージは SWUpdate で利用可能なファイル形式です。書き込むソフトウェアのイメージやソフトウェアアップデートに必要な情報を含ます。以下はSWU イメージのフォーマットです。
header (sw-description) 部に以下の情報を含みます。
- アップデート対象のイメージファイルのハッシュ
- 書き込み先ストレージの情報
- ソフトウェアのバージョン情報
- Boot 環境変数の書き換え情報
- アップデート前後に実行するスクリプトの情報
data 部に以下の情報を含みます。
- 複数のアップデート対象のイメージファイル (zst で圧縮、AES256 による暗号化を選択可能)
- アップデート前後に実行するスクリプト
SWUpdate の仕様については以下を参照してください。
SWUpdate: syntax and tags with the default parser
mkswu
mkswu は Armadillo Base OS 向けにヘッダ情報と SWU イメージを簡単に作ることができる独自ツールです。デバイスの開発環境である ATDE には標準でインストールされており、VSCode のプラグインによって SWU イメージのビルドが簡単にできます。詳しくは以下を参照してください。
開発から運用までのベストプラクティス
アップデート処理のガード
コンポーネントとバージョン
SWU イメージとデバイスにはアップデート対象のコンポーネント名とバージョン番号を含んでいます。コンポーネント名はアップデート対象を識別するために利用され、バージョン番号はダウングレード防止に利用されます。アップデート開始前に SWUpdate はバージョン番号をチェックしてバージョンが上がる場合にのみアップデートが可能になります。セキュリティ対策を無効にするようなダウングレード攻撃の防止のために有効です。開発時に不必要な場合、このガードを無効にすることも可能です。
ハードウェアの識別
SWU イメージとデバイスにはハードウェア種別名とリビジョンを識別するための情報を含んでいます。ハードウェア種別名とリビジョンを含めて１つのハードウェアとして認識されます。ハードウェアの識別が異なる場合にはアップデートは無効になります。
差分アップデート
docker のイメージ レイヤー
docker1 のレイヤーの仕組みを使ってファイル差分のみを抽出することで、ファイルサイズの増加を抑制した SWU イメージをビルドして、アップデートに利用することができます。
- Armadillo Base OS では docker と互換性をもつ podman を利用しています ↩︎