Howto

11.1. ゲートウェイアプリケーションを開発する

11.1.1. VSCode を用いた開発の流れ

ゲートウェイアプリケーションを開発する場合の流れは以下のようになります。

図11.1 ゲートウェイアプリケーション開発の流れ

11.1.2. ATDE 上でのセットアップ

ここでは、開発開始時の ATDE 上でのセットアップ手順について説明します。 ATDE をお使いでない場合は、先に「ATDEのセットアップ」を参照して ATDE のセットアップを完了してください。

11.1.2.1. ソフトウェアのアップデート

ATDE のバージョン v20230123 以上には、VSCode がインストール済みのため新規にインストールする必要はありませんが、使用する前には最新版へのアップデートを行ってください。

[ATDE ~]$ sudo apt update
[ATDE ~]$ sudo apt upgrade

図11.2 ソフトウェアをアップデートする

VSCode を起動するには code コマンドを実行します。

[ATDE ~]$ code

図11.3 VSCode を起動する


	VSCode を起動すると、日本語化エクステンションのインストールを提案してくることがあります。その時に表示されるダイアログに従ってインストールを行うと VSCode を日本語化できます。

11.1.2.2. VSCode に開発用エクステンションをインストールする

VSCode 上でアプリケーションを開発するためのエクステンションをインストールします。

エクステンションはマーケットプレイスからインストールすることができます。 VSCode を起動し、左サイドバーのエクステンションを選択して、検索フォームに「abos」と入力してください。

図11.4 VSCode に開発用エクステンションをインストールする

表示された「Armadillo Base OS Development Environment」の「Install」ボタンを押すとインストールは完了します。

11.1.2.3. プロジェクトの作成

VSCode の左ペインの [A6E] から [GW New Project] を実行し、表示されるディレクトリ選択画面からプロジェクトを保存するディレクトリを選択してください。実行するためには右に表示されている三角形ボタンを押してください。保存先を選択すると、プロジェクト名を入力するダイアログが表示されるので、任意のプロジェクト名を入力してエンターキーを押してください。ここでは、ホームディレクトリ直下に my_project として保存しています。

図11.5 プロジェクトを作成する

図11.6 プロジェクト名を入力する

11.1.2.4. 初期設定

初期設定では主に Armadillo と SSH で接続するための秘密鍵と公開鍵の生成を行います。 mkswu を用いて Armadillo の初期設定用の SWU イメージを作成するため、事前に「SWUイメージの作成」を参照して SWU の初期設定を行ってください。作成したプロジェクトディレクトリへ移動して VSCode を起動してください。

[ATDE ~]$ cd my_project
[ATDE ~/my_project]$ code ./

図11.7 初期設定を行う

VSCode の左ペインの [my_project] から [Generate development swu] を選択します。選択すると、 VSCode の下部に以下のようなターミナルが表示されます。

図11.8 VSCode のターミナル

このターミナル上で以下のように入力してください。

 *  Executing task: ./scripts/setup_armadillo.sh

Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again:
Your identification has been saved in config/ssh/id_rsa
Your public key has been saved in config/ssh/id_rsa.pub
:(省略)

 *  Terminal will be reused by tasks, press any key to close it.

図11.9 SSH 用の鍵を生成する

	パスフレーズを設定します。設定しない場合は何も入力せず Enter を押します。
	ここで何か任意のキーを押すとターミナルが閉じます。

Armadillo の初期設定を行う scripts/setup_armadillo.swu が作成されたことを確認してください。

11.1.2.5. `ssh_config` の編集

ATDE 上で操作するためにゲートウェイアプリケーションのディレクトリに入っている config/ssh_config ファイルを編集して IP アドレスを書き換えてください。

[ATDE ~/my_project]$ code config/ssh_config
Host Armadillo
    Hostname 0.0.0.0 
    User root
    Port 22
    IdentityFile config/ssh/id_rsa

図11.10 ssh_config を編集する

Armadillo の IP アドレスに置き換えてください。

11.1.2.6. タスク一覧

ゲートウェイアプリケーションプロジェクトでは現在以下のタスクが実行可能です。実行するためには VSCode の左ペインの [my_project] から選択します。

図11.11 タスク一覧

App run on Armadillo
ゲートウェイアプリケーションを実行します。
App stop on Armadillo
ゲートウェイアプリケーションを停止します。
Generate release swu
リリース用の SWU を作成します。
Gererate development swu
初期設定用の SWU を作成します。「初期設定」で使用したタスクになります。
Get device certificate file from Armadillo
デバイス証明書を取得します。

11.1.3. Armadillo 上でのセットアップ

11.1.3.1. 初期設定用 SWU イメージの書き込み

ここでは、開発開始時の Armadillo 上でのセットアップ手順について説明します。「SWUイメージの作成」で作成した SWU の初期設定用の SWU イメージのインストールがまだの場合は先に実行してください。その後、「初期設定」で作成した scripts/setup_armadillo.swu を「イメージのインストール」を参照して Armadillo へインストールしてください。 Armadillo にパスフレーズを設定した場合は、アプリケーションを Armadillo へ転送する時にパスフレーズの入力を求められることがあります。

11.1.4. ゲートウェイアプリケーション開発

ゲートウェイアプリケーションではゲートウェイコンテナを利用します。ゲートウェイコンテナについての詳細は「ゲートウェイコンテナとは」をご参照ください。

11.1.4.1. ゲートウェイアプリケーションの設定ファイルの編集

ゲートウェイアプリケーションの設定ファイルは app/config ディレクトリに配置されています。設定ファイルの詳細については「設定ファイルの編集」をご参照ください。

11.1.4.2. ゲートウェイアプリケーションの開始

ゲートウェイアプリケーションのメインファイルは app/src/main.py です。 VSCode の左ペインの [my_project] から [App run on Armadillo] を実行すると、変更内容を反映したゲートウェイアプリケーションが起動します。

VSCode のターミナルに以下のメッセージが表示されることがあります。これが表示された場合は yes と入力して下さい。

Are you sure you want to continue connecting (yes/no/[fingerprint])?

図11.12 実行時に表示されるメッセージ

11.1.4.3. ゲートウェイアプリケーションの停止

VSCode の左ペインの [my_project] から [App stop on Armadillo] を選択すると、ゲートウェイアプリケーションが停止します。

11.1.4.4. ゲートウェイアプリケーションが使用するデバイス証明書の取得

VSCode の左ペインの [my_project] から [Get device certificate file from Armadillo] を実行すると、ゲートウェイアプリケーションが使用するデバイス証明書を取得することができます。取得したデバイス証明書は app/device/cert ディレクトリに保存されます。


	このタスクは、「Azure IoT Hub と Azure IoT Hub Device Provisioning Service の設定を行う」のデバイス証明書を取得する箇所で使用します。

11.1.5. ゲートウェイアプリケーションの拡張例

メインファイルを変更することで独自のアプリケーションを開始することも可能です。ゲートウェイアプリケーションの拡張例のファイルは app/example ディレクトリに配置してあります。実行する場合は app/example ディレクトリのファイル一式を app/src ディレクトリにコピーしてください。拡張例のゲートウェイアプリケーションでは以下の動作を実行します。

5秒毎に Count_value のカウントアップ
Count_value が 100 に達すると 0 クリア

Count_value がカウントアップしていく様子はログファイルで確認できます。ゲートウェイアプリケーションのログについての詳細は「ログ内容確認」をご参照ください。

2023-01-26 11:05:35,115 <INFO> : {'data': {'Count_value': 0, 'timestamp': 1674698730}}
2023-01-26 11:05:45,150 <INFO> : {'data': {'Count_value': 1, 'timestamp': 1674698735}}
2023-01-26 11:05:45,165 <INFO> : {'data': {'Count_value': 2, 'timestamp': 1674698740}}
2023-01-26 11:05:45,175 <INFO> : {'data': {'Count_value': 3, 'timestamp': 1674698745}}
2023-01-26 11:05:55,202 <INFO> : {'data': {'Count_value': 4, 'timestamp': 1674698750}}
2023-01-26 11:05:55,215 <INFO> : {'data': {'Count_value': 5, 'timestamp': 1674698755}}
2023-01-26 11:06:05,242 <INFO> : {'data': {'Count_value': 6, 'timestamp': 1674698760}}
2023-01-26 11:06:05,255 <INFO> : {'data': {'Count_value': 7, 'timestamp': 1674698765}}
2023-01-26 11:06:15,282 <INFO> : {'data': {'Count_value': 8, 'timestamp': 1674698770}}
2023-01-26 11:06:15,295 <INFO> : {'data': {'Count_value': 9, 'timestamp': 1674698775}}
2023-01-26 11:06:25,323 <INFO> : {'data': {'Count_value': 10, 'timestamp': 1674698780}}
2023-01-26 11:06:25,335 <INFO> : {'data': {'Count_value': 11, 'timestamp': 1674698785}}
2023-01-26 11:06:35,362 <INFO> : {'data': {'Count_value': 12, 'timestamp': 1674698790}}

図11.13 ログファイルの Count_value の出力例

ゲートウェイアプリケーションの拡張についての詳細は「ゲートウェイコンテナを拡張する」をご参照ください。

11.1.6. リリース版のビルド

ここでは完成したゲートウェイアプリケーションをリリース版としてビルドする場合の手順について説明します。

VSCode の左ペインの [my_project] から [Generate release swu] を実行すると、リリース版の SWU イメージが作成されます。

作成した SWU イメージは scripts/ ディレクトリ下に release_gw-app.swu というファイル名で保存されます。

11.1.7. 製品への書き込み

リリース版のゲートウェイアプリケーションを含んだ SWU イメージを Armadillo に展開します。事前に「SWUイメージの作成」を参照して SWU の初期設定を行ってください。

VSCode の左ペインの [my_project] から [Generate release swu] を実行すると、 SWU イメージが作成されます。リリース版のビルドで生成した SWU イメージを「イメージのインストール」を参照して Armadillo へインストールすると、 Armadillo 起動時にアプリケーションも自動起動します。

11.2. CUI アプリケーションを開発する

ここではシェルスクリプトおよび Python を使った CUI アプリケーションの開発方法を紹介します。開発手順としてはシェルスクリプトと Python で同じであるため、シェルスクリプトの場合の例で説明します。

11.2.1. CUI アプリケーション開発の流れ

Armadillo 向けに CUI アプリケーションを開発する場合の流れは以下のようになります。

図11.14 CUI アプリケーション開発の流れ

11.2.2. ATDE 上でのセットアップ

11.2.2.1. ソフトウェアのアップデート

ATDE のバージョン v20230123 以上には、 VSCode がインストール済みのため新規にインストールする必要はありませんが、使用する前には最新版へのアップデートを行ってください。

[ATDE ~]$ sudo apt update
[ATDE ~]$ sudo apt upgrade

図11.15 ソフトウェアをアップデートする

VSCode を起動するには code コマンドを実行します。

[ATDE ~]$ code

図11.16 VSCode を起動する


	VSCode を起動すると、日本語化エクステンションのインストールを提案してくることがあります。その時に表示されるダイアログに従ってインストールを行うと VSCode を日本語化できます。

11.2.2.2. VSCode に開発用エクステンションをインストールする

VSCode 上でアプリケーションを開発するためのエクステンションをインストールします。

図11.17 VSCode に開発用エクステンションをインストールする

表示された「Armadillo Base OS Development Environment」の「Install」ボタンを押すとインストールは完了します。

11.2.2.3. プロジェクトの作成

VSCode の左ペインの [A6E] から [Shell New Project] を実行し、表示されるディレクトリ選択画面からプロジェクトを保存するディレクトリを選択してください。実行するためには右に表示されている三角形ボタンを押してください。 Python の場合は [Python New Project] を実行してください。保存先を選択すると、プロジェクト名を入力するダイアログが表示されるので、任意のプロジェクト名を入力してエンターキーを押してください。ここでは、ホームディレクトリ直下に my_project として保存しています。

図11.18 プロジェクトを作成する

図11.19 プロジェクト名を入力する

11.2.2.4. 初期設定

初期設定では主に Armadillo と SSH で接続するための秘密鍵と公開鍵の生成を行います。作成したプロジェクトディレクトリへ移動して VSCode を起動してください。

[ATDE ~]$ cd my_project
[ATDE ~/my_project]$ code ./

図11.20 初期設定を行う

VSCode の左ペインの [my_project] から [Setup environment] を実行します。

図11.21 VSCode で初期設定を行う

選択すると、 VSCode の下部に以下のようなターミナルが表示されます。

図11.22 VSCode のターミナル

このターミナル上で以下のように入力してください。

 *  Executing task: ./scripts/setup_env.sh

Generating public/private ed25519 key pair.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/atmark/.ssh/id_ed25519_vscode
:(省略)

 *  Terminal will be reused by tasks, press any key to close it.

図11.23 SSH 用の鍵を生成する

	パスフレーズを設定します。設定しない場合は何も入力せず Enter を押します。
	1 でパスフレーズを設定した場合は、確認のため再度入力してください。
	ここで何か任意のキーを押すとターミナルが閉じます。

パスフレーズを設定した場合は、アプリケーションを Armadillo へ転送する時にパスフレーズの入力を求められることがあります。


	ssh の鍵は `$HOME/.ssh/id_ed25519_vscode` (と `id_ed25519_vscode.pub` ) に保存されていますので、プロジェクトをバックアップする時は `$HOME/.ssh` も保存してください。

11.2.2.5. アプリケーション実行用コンテナイメージの作成

Armadillo 上でアプリケーションを実行するためのコンテナイメージを作成します。ここで作成したコンテナイメージは SWU イメージを使用して Armadillo へインストールするため、事前に「SWUイメージの作成」を参照して SWU の初期設定を行ってください。

コンテナイメージの作成および SWU イメージの作成も VSCode で行います。 VSCode の左ペインの [my_project] から [Generate development swu] を実行します。

図11.24 VSCode でコンテナイメージの作成を行う

コンテナイメージの作成にはしばらく時間がかかります。 VSCode のターミナルに以下のように表示されるとコンテナイメージの作成は完了です。

localhost/shell_armv7_app_image:latest はすでに存在しますが、リビルドしますか？（app の更新だけの場合には不要です）[y/N] 
コンテナイメージを ./swu/shell_armv7_app_image.tar に保存しました。
./swu/shell_app.desc のバージョンを 1 から 2 に変更しました。
./swu/dev.swu を作成しました。
次は Armadillo に ./swu/dev.swu をインストールしてください。
 *  Terminal will be reused by tasks, press any key to close it.

図11.25 コンテナイメージの作成完了

Dockerfile やパッケージリストを変更した場合のみにコンテナを再作成してください。

作成した SWU イメージは my_project/swu ディレクトリ下に dev.swu というファイル名で保存されています。

11.2.3. Armadillo 上でのセットアップ

11.2.3.1. アプリケーション実行用コンテナイメージのインストール

「アプリケーション実行用コンテナイメージの作成」で作成した dev.swu を「イメージのインストール」を参照して Armadillo へインストールしてください。

インストール後に自動で Armadillo が再起動します。

11.2.4. アプリケーション開発

11.2.4.1. VSCode の起動

ここでは、実際に Armadillo 上でサンプルアプリケーションを起動する場合の手順を説明します。プロジェクトディレクトリへ移動し VSCode を起動します。

[ATDE ~]$ code ./my_project

図11.26 VSCode で my_project を起動する

11.2.4.2. ディレクトリ構成

プロジェクトにいくつかのディレクトリがあります。

app: アプリケーションのソースです。Armadillo では /var/app/rollback/volumes/shell_app または python_app にそのままコピーされます。
config: 開発モードのための設定ファイルです。「ssh_config の準備」を参照してください。
container: スクリプトを実行するコンテナの設定ファイルです。 packages.txt に記載されているパッケージがインストールされます。 Dockerfile を直接編集することも可能です。
scripts: VSCode のコマンドに使われているスクリプト類です。編集された場合はサポート対象外となります。
swu: mkswu のためのテンプレートとコンテナのコンフィグファイルがあります。 shell_app または python_app のディレクトリの内容はそのまま SWU に組み込まれます。その中の etc/atmark/containers/shell_app.conf または python_app.conf に使われているボリュームやデバイス等が記載されていますので必要な場合に編集してください。

デフォルトのコンテナコンフィグでは app の src/main.sh または Python の場合に src/main.py を実行しますので、リネームが必要な場合にコンテナのコンフィグも修正してください。

このサンプルアプリケーションは、CPU と SOC の温度を /vol_data/log/temp.txt に出力し、アプリケーション LED を点滅させます。

11.2.4.3. `ssh_config` の準備

プロジェクトディレクトリに入っている config/ssh_config ファイルを編集して IP アドレスを書き換えてください。

[ATDE ~/my_project]$ code config/ssh_config
Host Armadillo
    Hostname 0.0.0.0 
    User root
    IdentityFile ${HOME}/.ssh/id_ed25519_vscode
    UserKnownHostsFile config/ssh_known_hosts
    StrictHostKeyChecking accept-new

図11.27 ssh_config を編集する

Armadillo の IP アドレスに置き換えてください。

11.2.4.4. アプリケーションの実行

VSCode の左ペインの [my_project] から [App run on Armadillo] を実行すると、アプリケーションが Armadillo へ転送されて起動します。

図11.28 Armadillo 上でアプリケーションを実行する

VSCode のターミナルに以下のメッセージが表示されることがあります。これが表示された場合は yes と入力して下さい。

Are you sure you want to continue connecting (yes/no/[fingerprint])?

図11.29 実行時に表示されるメッセージ

アプリケーションを終了するには VSCode の左ペインの [my_project] から [App stop on Armadillo] を実行してください。

図11.30 アプリケーションを終了する

11.2.5. リリース版のビルド

ここでは完成したアプリケーションをリリース版としてビルドする場合の手順について説明します。

VSCode の左ペインの [my_project] から [Generate release swu] を実行すると、リリース版のアプリケーションを含んだ SWU イメージが作成されます。事前に「SWUイメージの作成」を参照して SWU の初期設定を行ってください。

図11.31 リリース版をビルドする

11.2.6. 製品への書き込み

作成した SWU イメージは my_project/swu ディレクトリ下に release.swu というファイル名で保存されています。

この SWU イメージを「イメージのインストール」を参照して Armadillo へインストールすると、 Armadillo 起動時にアプリケーションも自動起動します。

11.3. ゲートウェイコンテナを動かす

Armadillo-IoT ゲートウェイ A6E にはゲートウェイコンテナがプリインストールされています。本章は、ゲートウェイコンテナを動かす方法について記載しています。

ゲートウェイコンテナは「ゲートウェイコンテナとは」に記載している通り、各インターフェースから取得するデータの設定や、接続するクラウドの情報を設定するだけで、コンテナ内で動作するアプリケーションを修正することなく、クラウドにデータを送信することができます。

11.3.1. ゲートウェイコンテナ利用の流れ

以下では、必要機器の接続やネットワークの設定は完了しているものとして説明を進めます。一連の流れは下記の通りです。

ゲートウェイコンテナでは AWS IoT Core と Azure IoT への接続をサポートしています。それぞれについて、データの可視化までを行うことが出来る環境を構築するためのテンプレートを提供しています。

ゲートウェイコンテナ起動確認
接続先のクラウド環境を構築 (クラウドにデータを送信する場合)
1. AWS IoT Core
2. Azure IoT Hub
コンフィグ設定
1. インターフェース設定
2. 接続先クラウド設定
コンテナ起動・実行
コンテナ終了

11.3.2. ゲートウェイコンテナ起動確認

ゲートウェイコンテナは、デフォルトで Armadillo-IoT ゲートウェイ A6E に電源を入れると自動的に起動する設定となっています。 Armadillo が起動し、ゲートウェイコンテナが起動・実行されると、アプリケーション LED が点滅します。

11.3.3. 接続先のクラウド環境を構築 (AWS)

AWS では、 AWS IoT Core と Amazon CloudWatch を組み合わせてデータの可視化を行います。本項では、 AWS 上で実施する設定を記載します。

手順中で使用するファイルは、Armadillo-IoT ゲートウェイ A6E ゲートウェイコンテナから「Armadillo-IoT ゲートウェイ A6E クラウド設定データ」ファイル (a6e-gw-container-cloudsetting-[VERSION].zip) から予めダウンロードしておきます。

11.3.3.1. AWS アカウントを作成する

AWS アカウントの作成方法については、AWS 公式サイトの AWS アカウント作成の流れ https://aws.amazon.com/jp/register-flow/ を参照してください。

11.3.3.2. IAM ユーザーを作成する

AWS IAM (Identity and Access Management) は、AWS リソースへのアクセスを安全に管理するためのウェブサービスです。IAM により、誰を認証(サインイン)し、誰にリソースの使用を承認する(アクセス許可を持たせる)かを管理することができます。

IAM へ移動し、「アクセス管理」→「ポリシー」を開き、「ポリシー作成」をクリックします。
「JSON」を選択し、「Armadillo-IoT ゲートウェイ A6E クラウド設定データ」ファイル (a6e-gw-container-cloudsetting-[VERSION].zip) AWS フォルダ内の a6e_aws_iam_policy.json のファイルの内容を貼り付け、「次のステップ：タグ」をクリックします。
何も選択せずに、「次のステップ：確認」をクリックします。
ポリシー名を入力し、「ポリシーの作成」をクリックします。ここでは、ポリシー名を "policy_for_A6E" としています。
IAM から、「アクセス管理」→「ユーザー」を開き、「ユーザーを追加」をクリックします。
下記の通り入力、選択し、「次へ」をクリックします。
- ユーザー名を入力する
- 「AWS マネジメントコンソールへのユーザーアクセスを提供する - オプション」を選択する
- コンソールパスワードは「自動生成されたパスワード」を選択する
- 「ユーザーは次回のサインイン時に新しいパスワードを作成する必要があります (推奨)。」にチェックを入れる
「ポリシーを直接アタッチする」をクリックし、先ほど作成したポリシーを選択して、「次へ」をクリックします。
表示される内容を確認し、「ユーザーの作成」をクリックします。
「.csv ファイルをダウンロード」をクリックし、"<ユーザー名>_credentials.csv" をダウンロードして、「ユーザーリストに戻る」をクリックします。

11.3.3.3. アクセスキーを作成する

作成したユーザーをユーザーリストの中から選択します。
ユーザー情報画面の「セキュリティ認証情報」-「アクセスキーを作成」をクリックします。
「AWS の外部で実行されるアプリケーション」を選択し、「次へ」をクリックします。
「アクセスキーを作成」をクリックします。
「.csv ファイルをダウンロード」をクリックし、"<ユーザー名>_accessKeys.csv" をダウンロードして、「完了」をクリックします。

11.3.3.4. Armadillo-IoT ゲートウェイ A6E のシリアル番号を取得する

AWS IoT Core に登録する Thing 名は Armadillo のシリアル番号を使用します。環境設定時、パラメータに指定する必要があるため、下記のコマンドを実行しシリアル番号を取得します。

armadillo:~# hexdump -v -s 0xa0 -n 8 -e '/4 "%08X"' /sys/bus/nvmem/devices/imx-ocotp0/nvmem | cut -c 5-
00CD11112222

この場合、00CD11112222 がシリアル番号になります

11.3.3.5. AWS IoT Core と Amazon CloudWatch の設定を行う

AWS IoT Core に送信したデータを Amazon CloudWatch のダッシュボード上で可視化します。ここでは、CloudFormation を用いて AWS IoT Core と Amazon CloudWatch の設定を行います。

CloudFormation へ移動し、「スタックの作成」→「新しいリソースを使用(標準)」をクリックします。
「テンプレートファイルのアップロード」で「Armadillo-IoT ゲートウェイ A6E クラウド設定データ」ファイル (a6e-gw-container-cloudsetting-[VERSION].zip) AWS フォルダ内の a6e_aws_cfn_template.yml を選択し、「次へ」をクリックします。
スタック名を入力します。また、「Armadillo-IoT ゲートウェイ A6E のシリアル番号を取得する」で取得したシリアル番号をパラメータに指定し、「次へ」をクリックします。
そのまま「次へ」をクリックします。
チェックボックスを選択し、「スタックの作成」をクリックします。
作成したスタックのステータスが"CREATE_COMPLETE" になったら作成完了です。

11.3.3.6. 設定に必要となるパラメータを取得する

「接続先のクラウド情報の設定」で設定するパラメータを取得します。

AWS IoT Core エンドポイント
1. IoT Core へ移動し、サイドバー下部にある設定をクリックします。
2. IoT Core エンドポイントが表示されます。
アカウント ID
1. AWS コンソール画面右上の ▼ をクリックします。
2. 下記画像の丸で囲んだマークをクリックすると、コピーすることができます。

11.3.4. 接続先のクラウド環境を構築 (Azure)

Azure の場合は、 Azure IoT Hub にデータを送信します。本項では、 Azure portal 上で実施する設定を記載します。

手順中で使用するファイルは、Armadillo-IoT ゲートウェイ A6E ゲートウェイコンテナから「Armadillo-IoT ゲートウェイ A6E クラウド設定データ」ファイル (a6e-gw-container-cloudsetting-[VERSION].zip) にアップロードしています。

11.3.4.1. Microsoft アカウントを作成する

Microsoft アカウントの作成については、Microsoft 公式ページ https://account.microsoft.com/ を参照してください。なお、サブスクリプションの設定も必要となります。

11.3.4.2. リソースグループを作成する

リソースグループの作成を行います。

Azure portal から [リソースグループ] を開き、[作成] を選択します。
サブスクリプションとリージョンを選択し、リソースグループ名を入力の後、[確認および作成] を選択します。

11.3.4.3. Azure IoT Hub と Azure IoT Hub Device Provisioning Service の設定を行う

ここでは、データの送信先となる Azure IoT Hub と、デバイスプロビジョニングのヘルパーサービスである Azure IoT Hub Device Provisioning Service (以降、DPS と記載) の設定を行います。

以下の手順はアットマークテクノが提供する設定ファイルを用いて設定を行っていますが、 Azure portal で作成した Azure IoT Hub / DPS に接続することも可能です。 DPS の個別登録機能を用いてデバイスプロビジョニングを行うため、以下のドキュメントを参考に DPS の設定を行ってください。 https://learn.microsoft.com/ja-jp/azure/iot-dps/quick-create-simulated-device-x509?tabs=windows&pivots=programming-language-ansi-c#create-a-device-enrollment

なお、上記手順中でアップロードするプライマリ証明書は、Armadillo 上の /var/app/volumes/gw_container/device/cert/device_cert.pem を使用してください。


	「Armadillo-IoT ゲートウェイ A6E クラウド設定データ」v2.1.0 から、DPS のデバイスプロビジョニング方法が個別登録に変更となりました。 v2.0.0 以前を使用してクラウド環境を構築および Azure portal で作成した DPS にグループ登録で設定を行った場合は、再度環境の構築および設定を行ってください。

Azure portal https://account.microsoft.com/ にサインインします。
Cloud Shell アイコンを選択し、 Azure Cloud Shell を起動します。
[Bash] を選択します。
ストレージアカウントの設定を行います。サブスクリプションを選択し、ストレージの作成をクリックすると自動的にストレージアカウントが作成されます。

Cloud Shell が起動したら、以下のコマンドで Armadillo-IoT ゲートウェイ A6E クラウド設定データをダウンロードします。

[Azure: ~]$ wget https://armadillo.atmark-techno.com/files/downloads/armadillo-iot-a6e/container/a6e-gw-container-cloudsetting-[VERSION].zip
[Azure: ~]$ unzip a6e-gw-container-cloudsetting-[VERSION].zip -d a6e-gw-container-cloud-setting
[Azure: ~]$ cd a6e-gw-container-cloud-setting/Azure

図11.32 Armadillo-IoT ゲートウェイ A6E クラウド設定データをダウンロードする

Cloud Shell 上でエディタを開き、コンフィグファイルを編集します。
```
[Azure: ~]$ code a6e_azure_create_hubdps.conf
# Common Config
resourceGroup="" 
certificateFilePath="./device_cert.pem"

# IoT Hub Config
iotHubName="" 
skuName="S1"
skuUnit=1
partitionCount=4

# DPS Config
provisioningServiceName="" 
```
図11.33 コンフィグファイルを編集する
リソースグループを指定します

作成する Azure IoT Hub 名を入力します

作成する DPS 名を入力します
```
# Common Config
resourceGroup="armadillo"
certificateFilePath="./device_cert.pem"

# IoT Hub Config
iotHubName="armadillo-iothub"
skuName="S1"
skuUnit=1
partitionCount=4

# DPS Config
provisioningServiceName="armadillo-dps"
```
図11.34 コンフィグファイル設定例
Azure IoT Hub 名、 DPS 名はそれぞれグローバルで一意である必要があります。既に使用されている名称を指定した場合、エラーとなります。
コンフィグファイルの編集が終了したら、[保存] を行い、 [エディターを閉じる] を選択し、エディタを終了します。

DPS に登録する証明書を Cloud Shell にアップロードします。

証明書ファイルは Armadillo 上の /var/app/volumes/gw_container/device/cert/device_cert.pem を使用します。


	ゲートウェイアプリケーションのプロジェクト v1.1.0 以降を使用すると、 VSCode のタスクを使用してデバイス証明書を取得することができます。手順詳細は「ゲートウェイアプリケーションが使用するデバイス証明書の取得」をご確認ください。

開発 PC にコピーした後、Cloud Shell の以下のアイコンを選択し、アップロードを行います。

images/a6e-azure-cloud-shell-fileupload.png

アップロード完了後、スクリプトと同階層に証明書ファイルをコピーします。

[Azure: ~]$ cp /home/<ユーザー名>/device_cert.pem .

設定スクリプトを実行し、 Azure IoT Hub と DPS の設定を行います。

[Azure: ~]$ chmod +x a6e_azure_create_hubdps.sh
[Azure: ~]$ ./a6e_azure_create_hubdps.sh
Starting to create IoT Hub.
:（省略）
Starting to create DPS.
{
:（省略）
  "name": "xxxxx",
  "properties": {
:（省略）
    "idScope": "0ne12345678", 
:（省略）
  },
:（省略）
}
:（省略）
Starting to link between IoT Hub and DPS.
:（省略）
Starting to create enrollment.
:（省略）
Completed!

図11.35 Azure IoT Hub と DPS の設定を実行する

環境設定時に使用するため、控えておきます

11.3.5. 設定ファイルの編集

利用したい内容に合わせて、設定ファイルを編集します。設定内容はコンテナ起動時の内容が適用されるため、一度コンテナを終了させます。

[armadillo ~]# podman stop a6e-gw-container
a6e-gw-container

図11.36 ゲートウェイコンテナを終了する

本マニュアルに記載しているゲートウェイコンテナの設定ファイルの内容は、最新バージョンの内容となります。

ご利用のゲートウェイコンテナのバージョンが最新ではない場合、ゲートウェイコンテナを最新のバージョンにアップデートするか、ゲートウェイコンテナのバージョンに対応した製品マニュアルをご参照ください。

製品マニュアルのバージョンとゲートウェイコンテナのバージョンについては Armadillo-IoT A6E の製品アップデートページをご参照ください。

11.3.5.1. インターフェース設定

インターフェースの動作設定を行います。設定ファイルは /var/app/rollback/volumes/gw_container/config/sensing_mgr.conf です。

[DEFAULT]
; cloud_config=true or false
cloud_config=false
; send_cloud=true or false
send_cloud=false
; cache=true or false
cache=false
; send_interval[sec]
send_interval=10
; data_send_oneshot=true or false
data_send_oneshot=false
; wait_container_stop[sec]
wait_container_stop=0

[LOG]
file=true
stream=true

[CPU_temp]
; type=polling or none
type=polling
; polling_interval[sec]
polling_interval=1

[DI1]
; type=polling or edge
type=
; interval[sec]
interval=
; edge_type=falling or rising or both
edge_type=

[DI2]
; type=polling or edge
type=
; interval[sec]
interval=
; edge_type=falling or rising or both
edge_type=

[DO1]
; output_state=high or low
output_state=
; output_time[sec]
output_time=
; output_delay_time[sec]
output_delay_time=

[DO2]
; output_state=high or low
output_state=
; output_time[sec]
output_time=
; output_delay_time[sec]
output_delay_time=

[RS485_Data1]
;[RS485_Data1] ~ [RS485_Data4]
method=none
baudrate=
data_size=
; parity=none or odd or even
parity=
; stop=1 or 2
stop=
device_id=
func_code=
register_addr=
register_count=
; endian=little or big
endian=
; interval[sec]
interval=
; data_offset is option
data_offset=
; data_multiply is option
data_multiply=
; data_devider is option
data_devider=

図11.37 /var/app/rollback/volumes/gw_container/config/sensing_mgr.conf のフォーマット

全体動作設定

全体的な動作設定を行います。設定ファイル中の以下の箇所が該当します。

[DEFAULT]
; cloud_config=true or false
cloud_config=false
; send_cloud=true or false
send_cloud=false
; cache=true or false
cache=false
; send_interval[sec]
send_interval=10
; data_send_oneshot=true or false
data_send_oneshot=false
; wait_container_stop[sec]
wait_container_stop=0

表11.1 [DEFAULT] 設定可能パラメータ

項目	概要	設定値	内容
cloud_config	クラウドからの設定変更を許容するか	true	許容する
cloud_config	クラウドからの設定変更を許容するか	(デフォルト)false	無視する
send_cloud	クラウドにデータを送信するか	true	送信する
send_cloud	クラウドにデータを送信するか	(デフォルト)false	送信しない
cache	キャッシュ実施可否	true	キャッシュを実施する。ネットワーク状態の異常などによりクラウドへデーターを送信できない場合、キャッシュに計測データ―を一時保存し、ネットワーク復旧後にクラウドへ送信します。
cache	キャッシュ実施可否	(デフォルト)false	キャッシュを実施しない
send_interval	データ送信間隔[sec]	1～10	この値に従って、クラウドへデータを送信する
data_send_oneshot	データ取得後コンテナを終了させるか	true	1回データを取得し、コンテナを終了します。コンテナ終了通知をトリガに間欠動作を行う( 「状態遷移トリガにコンテナ終了通知を利用する」 )場合は、この設定にする必要があります。
data_send_oneshot	データ取得後コンテナを終了させるか	(デフォルト)false	コンテナの実行を継続する (設定したインターバルでデータを取得する)
wait_container_stop	コンテナ終了までの待ち時間[sec]	0～60	data_send_oneshot が true の場合、クラウドへのデータ送信後、設定した時間 wait してからコンテナを終了する ^[a]
^[a]現時点では 0 を設定してください

クラウドへのデータ送信は send_interval で指定した間隔毎に行います。値の取得間隔は、後述の通り各項目毎に指定することができます。値を取得するタイミングとクラウドへのデータ送信のタイミングを近くするためには、値の取得間隔より send_interval を短くするか、同じにすることを推奨します。

ログ出力

取得したデータのログをログファイルに保存したり、コンソールに出力することが可能です。設定ファイル中の以下の箇所が該当します。

[LOG]
file=true
stream=true

表11.2 [LOG] 設定可能パラメータ

項目	概要	設定値	内容
FILE_LOG	ログファイルに出力するか	(デフォルト)true	出力する
FILE_LOG	ログファイルに出力するか	false	出力しない
STREAM_LOG	コンソールに出力するか	(デフォルト)true	出力する
STREAM_LOG	コンソールに出力するか	false	出力しない

CPU_temp

CPU 温度読み出しに関する設定を行います。設定ファイル中の以下の箇所が該当します。

[CPU_temp]
; type=polling or none
type=polling
; polling_interval[sec]
polling_interval=1

表11.3 [CPU_temp] 設定可能パラメータ

項目	概要	設定値	内容
type	動作種別	(空欄) or none	CPU 温度取得を行わない
type	動作種別	polling	ポーリング
polling_interval	データ取得間隔[sec]	1～3600	この値に従って、CPU 温度を読み出します

接点入力

接点入力に関する設定を行います。設定ファイル中の以下の箇所が該当します。

[DI1]
; type=polling or edge
type=
; interval[sec]
interval=
; edge_type=falling or rising or both
edge_type=

[DI2]
; type=polling or edge
type=
; interval[sec]
interval=
; edge_type=falling or rising or both
edge_type=

表11.4 [DI1,DI2] 設定可能パラメータ

項目	概要	設定値	内容
type	動作種別	(空欄) or none	接点入力状態取得を行わない
		polling	ポーリング
		edge	エッジ検出。データ取得間隔に設定した周期で値を取得し、前回取得時から指定方向に値が変化した場合、クラウドへデータ―を送信します。
interval	データ取得間隔[sec]	1～3600	この値に従って、値を読み出します
edge_type	エッジ検出設定	falling	立ち下がりエッジ
		rising	立ち上がりエッジ
		both	両方

接点出力

接点出力に関する設定を行います。設定ファイル中の以下の箇所が該当します。表11.1「[DEFAULT] 設定可能パラメータ」において、クラウドと通信しない場合はゲートウェイコンテナ起動後に設定した内容を出力します。クラウドと通信する場合は、「クラウドからのデバイス制御」がトリガとなり、出力を開始します。

[DO1]
; output_state=high or low
output_state=
; output_time[sec]
output_time=
; output_delay_time[sec]
output_delay_time=

[DO2]
; output_state=high or low
output_state=
; output_time[sec]
output_time=
; output_delay_time[sec]
output_delay_time=

表11.5 [DO1,DO2] 設定可能パラメータ

項目	概要	設定値	内容
output_state	出力状態	high	High 出力。クラウドからの設定内容更新が有効の場合に、クラウドからの設定変更が可能です。
		low	Low 出力。クラウドからの設定内容更新が有効の場合に、クラウドからの設定変更が可能です。
		disable	「電源を安全に切るタイミングを通知する」で接点出力を使用する場合など、ゲートウェイコンテナで接点出力を使用しないときに設定します。また、この値に設定すると、クラウドからの設定変更・動作指示は無視されます。
		指定なし	ゲートウェイコンテナで接点出力の初期状態を設定しないときに使用します。接点出力を設定しないため、ゲートウェイコンテナ起動時の出力状態になります。クラウドからの設定内容更新が有効の場合に、クラウドからの設定変更が可能です。
output_time	出力時間[sec]	1～3600	出力コマンド実行後に output_state で指定したレベルを出力する時間。 0 を指定すると出力値を固定します。
output_delay_time	出力遅延時間[sec]	0～3600	出力コマンド実行後、指定した時間遅延して出力します。

設定と DO の出力タイミングの関連を図11.38「DO の出力タイミング」に示します。

図11.38 DO の出力タイミング

(1) ゲートウェイコンテナはクラウドからの要求を取り込みます

(2) クラウドからの要求を取り込んでから output_delay_time 経過後、出力を切り替えます

(3) output_time 経過後出力を戻します

RS485

RS485 に関する設定を行います。設定ファイル中の以下の箇所が該当します。なお、RS485_Data1 から RS485_Data4 まで、4個のデータについて設定することができます。デフォルトでは RS485_Data1 のみファイルに記載されているため、RS485_Data2, RS485_Data3, RS485_Data4 については適宜コピーして記載してください。

[RS485_Data1]
;[RS485_Data1] ~ [RS485_Data4]
method=none
baudrate=
data_size=
; parity=none or odd or even
parity=
; stop=1 or 2
stop=
device_id=
func_code=
register_addr=
register_count=
; endian=little or big
endian=
; interval[sec]
interval=
; data_offset is option
data_offset=
; data_multiply is option
data_multiply=
; data_devider is option
data_devider=

表11.6 [RS485_Data1, RS485_Data2, RS485_Data3, RS485_Data4] 設定可能パラメータ

項目	概要	設定値	内容
method	通信種別	none	RS485を利用しない
method	通信種別	rtu	Modbus-RTU
data_size	データサイズ	8
baudrate	ボーレート	1200～38400[bps]	通信速度を指定します
parity	パリティビット	none	None
		odd	Odd
		even	Even
stop	ストップビット	1	1
stop	ストップビット	2	2
device_id	Modbusスレーブ機器のデバイスID	0x01 〜 0xF7
func_code	ファンクションコード	0x03 or 0x04
register_addr	レジスタアドレス	機器依存	値を読み出すレジスタのアドレスを指定
register_count	読み出しレジスタ数	1 or 2	一度に読み出すレジスタ数を指定
endian	エンディアン設定	little	リトルエンディアン
endian	エンディアン設定	big	ビッグエンディアン
interval	データ取得間隔[sec]	1～3600	この値に従って、値を読み出します
data_offset	読み出し値に加算する値	任意の値(整数値)	指定は任意です。読み出したレジスタ値に加算する値を指定します
data_multiply	読み出し値と乗算する値	任意の値(整数値)	指定は任意です。読み出したレジスタ値と乗算する値を指定します
data_devider	読み出し値と除算する値	任意の値(整数値)	指定は任意です。読み出したレジスタ値と除算する値を指定します

11.3.5.2. 接続先のクラウド情報の設定

クラウドと連携する場合、接続先のクラウドの情報を入力する必要があります。設定ファイルは /var/app/rollback/volumes/gw_container/config/cloud_agent.conf です。

[CLOUD]
SERVICE = ;AWS or AZURE

[LOG]
FILE_LOG = true
STREAM_LOG = true

[AWS]
AWS_IOT_HOST =
AWS_IOT_REGION =
AWS_IOT_ACCOUNTID =
AWS_IOT_ENDPOINT =
AWS_IOT_CERT_FILE = /cert/device/device_cert.pem
AWS_IOT_POLICY_FILE = /config/aws_iot_policy.json
AWS_IOT_SHADOW_ENDPOINT =
AWS_IOT_CA_FILE = /cert/ca/AmazonRootCA1.pem
AWS_IOT_PKCS11_PATH = /usr/lib/plug-and-trust/libsss_pkcs11.so
AWS_IOT_KEY_LABEL = sss:100100F0
AWS_ACCESS_KEY =
AWS_SECRET_KEY =
AWS_IOT_PORT = 443
AWS_IOT_PIN =

[AZURE]
AZURE_IOT_DEVICE_DPS_ENDPOINT = global.azure-devices-provisioning.net
AZURE_IOT_DEVICE_DPS_ID_SCOPE =
AZURE_IOT_KEY_FILE = /cert/device/key.pem
AZURE_IOT_CERT_FILE = /cert/device/device_cert.pem

図11.39 /var/app/rollback/volumes/gw_container/config/cloud_agent.conf のフォーマット

接続先のクラウドサービス種別
ゲートウェイコンテナが接続するクラウドサービスの種別を指定します。設定ファイル中の以下の箇所が該当します。
```
[CLOUD]
SERVICE = ;AWS or AZURE
```
表11.7 [CLOUD] 設定可能パラメータ
項目概要設定値内容
SERVICE
接続先クラウドサービスを指定
AWS
AWS IoT Core に接続
Azure
Azure IoT に接続

ログ出力

クラウドとの接続状態や送受信したデータのログをログファイルに保存したり、コンソールに出力することが可能です。設定ファイル中の以下の箇所が該当します。

[LOG]
FILE_LOG = true
STREAM_LOG = true

表11.8 [CLOUD] 設定可能パラメータ

項目	概要	設定値	内容
FILE_LOG	ログファイルに出力するか	(デフォルト)true	出力する
FILE_LOG	ログファイルに出力するか	false	出力しない
STREAM_LOG	コンソールに出力するか	(デフォルト)true	出力する
STREAM_LOG	コンソールに出力するか	false	出力しない

AWS

ここでは、 AWS に接続する場合の設定内容を記載します。設定ファイル中の以下の箇所が該当します。

[AWS]
AWS_IOT_HOST =
AWS_IOT_REGION =
AWS_IOT_ACCOUNTID =
AWS_IOT_ENDPOINT =
AWS_IOT_CERT_FILE = /cert/device/device_cert.pem
AWS_IOT_POLICY_FILE = /config/aws_iot_policy.json
AWS_IOT_SHADOW_ENDPOINT =
AWS_IOT_CA_FILE = /cert/ca/AmazonRootCA1.pem
AWS_IOT_PKCS11_PATH = /usr/lib/plug-and-trust/libsss_pkcs11.so
AWS_IOT_KEY_LABEL = sss:100100F0
AWS_ACCESS_KEY =
AWS_SECRET_KEY =
AWS_IOT_PORT = 443
AWS_IOT_PIN =

表11.9 [AWS] 設定可能パラメータ

項目	概要	設定値・設定例	取得方法
AWS_IOT_HOST	IoT Core REST API エンドポイント(リージョンに準ずる)	(例) iot.ap-northeast-1.amazonaws.com	AWS IoT Core - コントロールプレーンエンドポイント [https://docs.aws.amazon.com/ja_jp/general/latest/gr/iot-core.html] から取得
AWS_IOT_REGION	リージョン	(例) ap-northeast-1	AWS リージョンエンドポイント[https://docs.aws.amazon.com/ja_jp/general/latest/gr/rande.html] から取得
AWS_IOT_ACCOUNTID	アカウントID	(例) 111111111111	AWS マネジメントコンソール上から取得(参考:「設定に必要となるパラメータを取得する」)
AWS_IOT_ENDPOINT	AWS IoT Core エンドポイント(リージョンに準ずる)	(例) https://iot.ap-northeast-1.amazonaws.com	AWS IoT Core - コントロールプレーンエンドポイント [https://docs.aws.amazon.com/ja_jp/general/latest/gr/iot-core.html] から取得
AWS_IOT_CERT_FILE	デバイス証明書ファイルパス	(デフォルト)/cert/device/device_cert.pem ^[a]	変更不要
AWS_IOT_POLICY_FILE	AWS IoT Core ポリシーテンプレートファイルパス	(デフォルト)/config/aws_iot_policy.json	変更不要
AWS_IOT_SHADOW_ENDPOINT	AWS IoT Core エンドポイント	(例)xxxxxxxxx-ats.iot.ap-northeast-1.amazonaws.com	AWS IoT Core [設定] - [デバイスデータエンドポイント] から取得 (参考:「設定に必要となるパラメータを取得する」)
AWS_IOT_CA_FILE	AWS IoT Core ルートCAファイルパス	(デフォルト)/cert/ca/AmazonRootCA1.pem ^[a]	変更不要
AWS_IOT_PKCS11_PATH	PKCS#11 ライブラリパス	(デフォルト)/usr/lib/plug-and-trust/libsss_pkcs11.so	変更不要
AWS_IOT_KEY_LABEL	利用する秘密鍵のラベル	(デフォルト)sss:100100F0	変更不要
AWS_ACCESS_KEY	アクセスキー	(例)AAAAAAAAAXXXXXXX	「アクセスキーを作成する」でダウンロードしたIAM ユーザーアクセスキー情報
AWS_SECRET_KEY	シークレットキー	(例)sssssssddddddtttttttttt	「アクセスキーを作成する」でダウンロードしたIAM ユーザーアクセスキー情報
AWS_IOT_PORT	MQTT 接続ポート	(デフォルト)443	変更不要
AWS_IOT_PIN	PIN	-	指定不要
^[a]ゲートウェイコンテナバージョン 2.1.1 でパスを変更しました


	上記パラメータのうち、以下のパラメータはAWS IoT Core へのデバイス登録完了後クリアされます。デバイスを AWS IoT Core から削除した場合など再度デバイス登録を行いたい場合は、再度設定してください。 AWS_IOT_ACCOUNTID AWS_ACCESS_KEY AWS_SECRET_KEY

Azure

ここでは、 Azure に接続する場合の設定内容を記載します。設定ファイル中の以下の箇所が該当します。

[AZURE]
AZURE_IOT_DEVICE_DPS_ENDPOINT = global.azure-devices-provisioning.net
AZURE_IOT_DEVICE_DPS_ID_SCOPE =
AZURE_IOT_KEY_FILE = /cert/device/key.pem
AZURE_IOT_CERT_FILE = /cert/device/device_cert.pem

表11.10 [AZURE] 設定可能パラメータ

項目	概要	設定値・設定例	取得方法
AZURE_IOT_DEVICE_DPS_ENDPOINT	DPS エンドポイント	(デフォルト)global.azure-devices-provisioning.net	変更不要
AZURE_IOT_DEVICE_DPS_ID_SCOPE	Azure IoT Central ID スコープ	(例)0ne12345678	図11.35「Azure IoT Hub と DPS の設定を実行する」で表示された内容を使用
AZURE_IOT_KEY_FILE	デバイスリファレンスキーファイルパス	(デフォルト)/cert/device/key.pem ^[a]	変更不要
AZURE_IOT_CERT_FILE	デバイス証明書ファイルパス	(デフォルト)/cert/device/device_cert.pem ^[a]	変更不要
^[a]ゲートウェイコンテナバージョン 2.1.1 でパスを変更しました。

11.3.6. コンテナ起動・実行

設定ファイルの修正が完了したら、コンテナを起動します。コンテナが起動すると、設定に従ってコンテナ内のアプリケーションが実行される仕組みとなっています。

[armadillo ~]# podman_start a6e-gw-container
Starting 'a6e-gw-container'
a3b719c355de677f733fa8208686c29424be24e57662d3972bc4131ab7d145ad

表11.1「[DEFAULT] 設定可能パラメータ」でクラウドにデータを送信する設定を行った場合は、クラウド接続後、アプリケーションLEDの状態が点滅から点灯に変化します。

11.3.6.1. Armadillo からクラウドに送信するデータ

Armadillo からクラウドに送信するデータは以下の通りです。

デバイス情報
表11.11 デバイス情報データ一覧
項目概要
DevInfo_SerialNumber
シリアル番号
DevInfo_LAN_MAC_Addr
LAN MAC アドレス
DevInfo_ABOS_Ver
Armadillo Base OS バージョン
DevInfo_Container_Ver
コンテナイメージバージョン
CPU 温度
表11.12 CPU 温度データ一覧
項目概要
CPU_temp
CPU 温度
接点入力
表11.13 接点入力データ一覧
項目概要
DI1_polling
DI1 のポーリング結果
DI2_polling
DI2 のポーリング結果
DI1_edge
DI1 のエッジ検出結果
DI2_edge
DI2 のエッジ検出結果
接点出力
クラウドに送信するデータはありません。
RS485
表11.14 RS485データ一覧
項目概要
RS485_Data1
RS485_Data1 の読み出し値
RS485_Data2
RS485_Data2 の読み出し値
RS485_Data3
RS485_Data3 の読み出し値
RS485_Data4
RS485_Data4 の読み出し値
ユーザースイッチ
表11.15 ユーザースイッチ関連データ一覧
項目概要
sw_state
ユーザースイッチの状態

クラウドにデータが届いているかどうかは、次項の方法で確認することができます。

11.3.6.2. AWS 上でのデータ確認

Amazon CloudWatch ダッシュボードで、データが届いているかの確認を行う事ができます。

CloudWatch に移動し、「ダッシュボード」を選択します。
「AWS IoT Core と Amazon CloudWatch の設定を行う」で CloudWatch ダッシュボードが作成されています。ダッシュボード名は armadillo_iot_a6e_<シリアル番号> です。
ダッシュボード名をクリックすると、下記のような画面が表示されます。
- 接点入力
- RS485
- CPU温度
- ユーザースイッチ

また、実際にデバイスから届いているデータを確認する場合は、 AWS IoT Core の Device Shadow で確認を行います。

AWS IoT Core に移動し、「管理」→「すべてのデバイス」→「モノ」を選択します。
デバイスの名前は「Armadillo-IoT ゲートウェイ A6E のシリアル番号を取得する」で取得したシリアル番号で登録されています。
「Device Shadow」の「Classic Shadow」を選択します。
下記の通り、 Armadillo から送信されてきたデータを確認することができます。

11.3.6.3. Azure 上でのデータ確認

以下では可視化の手順を記載していますが、実際にデバイスから届いているデータを確認する場合は、Azure IoT Explorer を用いて確認することが可能です。詳細はこちらのドキュメント https://docs.microsoft.com/ja-jp/azure/iot-pnp/howto-use-iot-explorer をご参照ください。

Azure IoT Hub に登録されるデバイス ID は、デバイス認証に使用している証明書の CN となります。以下のコマンドで確認することが可能です。

[armadillo ~]# openssl x509 -noout -subject -in /var/app/volumes/gw_container/device/cert/device_cert.pem | grep subject | awk '{print $NF}'

可視化の方法は様々ありますが、本書では一例として、Power BI を使用して Azure IoT Hub に送信したデータの可視化を行う方法を記載します。

以下の手順では、「Armadillo からクラウドに送信するデータ」のうち CPU_temp を例に記載します。

こちらのページで https://powerbi.microsoft.com/ja-jp/ Power BI アカウントを作成します。なお、 Pro アカウントでの登録が必要となります。
PowerBI にログインし、グループワークスペースを作成します。
Azure IoT Hub にコンシューマーグループを追加します。 Azure portal から [IoT Hub] を開き、「Azure IoT Hub と Azure IoT Hub Device Provisioning Service の設定を行う」で作成した IoT Hub を選択します。 [組み込みのエンドポイント] を選択し、[コンシューマーグループ] の下のテキストボックスに、新しいコンシューマーグループの名前を入力、保存します。

Azure IoT Hub のデータを Power BI のデータセットにルーティングする Azure Stream Analytics ジョブを作成します。

Azure portal から [Stream Analytics ジョブ] を開き、 [Stream Analytics ジョブ] 概要ページで [作成] を選択します。

images/a6e-azure-streamanalytics-create.png

[基本] タブに、表11.16「Azure Stream Analytics ジョブ設定値」の情報を入力し、 [確認と作成] を選択した後、 [作成] を選択して Stream Analytics ジョブを作成します。

images/a6e-azure-streamanalytics-create-setting.png

表11.16 Azure Stream Analytics ジョブ設定値

項目	設定値
サブスクリプション	IoT Hub のサブスクリプション
リソースグループ	IoT Hub のサブスクリプション
名前	ジョブの名前(任意)
リージョン	IoT Hub のリージョン

Stream Analytics ジョブに入力を追加します。

作成した Stream Analytics ジョブを開きます。

images/a6e-azure-streamanalytics-list.png

[ジョブトポロジ] - [入力] から [ストリーム入力の追加] を選択し、ドロップダウンリスト内の [IoT Hub] を選択します。

images/a6e-azure-streamanalytics-input.png

表11.17「Azure Stream Analytics ジョブ入力設定値」の情報を入力し、それ以外の内容はデフォルトのまま [保存] を選択します。

images/a6e-azure-streamanalytics-input-setting.png

表11.17 Azure Stream Analytics ジョブ入力設定値

項目	設定値
入力のエイリアス	一意の名前を入力
サブスクリプションから IoT Hub を選択する	選択
サブスクリプション	IoT Hub 用のサブスクリプション
IoT Hub	使用する IoT Hub
コンシューマーグループ	作成したコンシューマーグループを選択
共有アクセスポリシー名	iothubowner

Stream Analytics ジョブに出力を追加します。なお、複数の値を PowerBI で可視化する場合は、値の数分の出力設定が必要になります。
[ジョブトポロジ] - [出力] から [追加] を選択し、ドロップダウンリスト内の [Power BI] を選択します。
[認証モード] で「ユーザートークン」を選択、[接続を承認する] の [承認] を選択し、Power BI アカウントにサインインします。
作成したグループワークスペースの ID を [グループワークスペース] に入力します。グループワークスペースの ID は、グループワークスペースの URL から取得することができます。 [データセット名] と [テーブル名] は任意の値を指定してください。ここではそれぞれ cputemp を指定しています。情報登録完了後、 [保存] を選択します。

Stream Analytics ジョブのクエリを構成します。

[ジョブトポロジ] の [クエリ] を選択します。

images/a6e-azure-streamanalytics-query.png

赤枠内にクエリを指定します。入力完了後、[クエリの保存] を選択してください。フォーマットは下記の通りです。 <パラメータ名> には、「Armadillo からクラウドに送信するデータ」の「項目」を指定してください。

SELECT
    <パラメータ名>,
    DATEADD(hour, 9, System.Timestamp) AS time,
    IoTHub.ConnectionDeviceId AS DeviceID
INTO
    [<ジョブ出力エイリアス名>]
FROM
    [<ジョブ入力エイリアス名>] timestamp by dateadd(second, epoch, '1970-01-01T00:00:00Z')
WHERE <パラメータ名> IS NOT NULL

これに従い、CPU_temp の場合は以下の通りとなります。

SELECT
    CPU_temp,
    DATEADD(hour, 9, System.Timestamp) AS time,
    IoTHub.ConnectionDeviceId AS DeviceID
INTO
    [cputemp]
FROM
    [<ジョブ入力エイリアス名>] timestamp by dateadd(second, epoch, '1970-01-01T00:00:00Z')
WHERE CPU_temp IS NOT NULL

なお、複数の出力がある場合は、クエリ入力欄に下記の通り複数のクエリを列挙してください。INTO 句で指定するパラメータ(データセット名)が異なることに注意してください。

SELECT
    CPU_temp,
    DATEADD(hour, 9, System.Timestamp) AS time,
    IoTHub.ConnectionDeviceId AS DeviceID
INTO
    [cputemp]
FROM
    [<ジョブ入力エイリアス名>] timestamp by dateadd(second, epoch, '1970-01-01T00:00:00Z')
WHERE CPU_temp IS NOT NULL

SELECT
    DI1_polling,
    DATEADD(hour, 9, System.Timestamp) AS time,
    IoTHub.ConnectionDeviceId AS DeviceID
INTO
    [di1polling]
FROM
    [<ジョブ入力エイリアス名>] timestamp by dateadd(second, epoch, '1970-01-01T00:00:00Z')
WHERE DI1_polling IS NOT NULL

Stream Analytics ジョブを実行します。
[概要] 画面で [開始] を選択します。
[ジョブの開始] 画面の [ジョブ出力の開始時刻] で [現在] が選択されていることを確認し、 [開始] を選択します。ジョブが正常に開始されると、[概要] 画面の [状態] が [実行中] に変わります。
ゲートウェイコンテナを停止している場合、下記のコマンドを実行しゲートウェイコンテナを開始します。
```
[armadillo ~]# podman_start a6e-gw-container
Starting 'a6e-gw-container'
a3b719c355de677f733fa8208686c29424be24e57662d3972bc4131ab7d145ad
```
PowerBI アカウントにサインインし、使用したワークスペースを右側のメニューから選択すると、 Stream Analytics ジョブ出力で指定した名称のデータセットが作成されています。
データセットの [レポートの作成] を選択します。
[視覚化] で [折れ線グラフ] を選択、X軸に EventEnqueuedUtcTime 、 Y軸に CPU_temp を指定することにより、グラフ化を行うことが出来ます。各設定を行った後、 [保存] すると、レポートが作成されます。
複数のデータセットが存在している場合は、それぞれについてレポートの作成を行います。なお、各レポートを一括して表示したい場合はダッシュボード機能を選択してください。手順についてはこちらのドキュメント https://learn.microsoft.com/ja-jp/power-bi/create-reports/service-dashboard-create を参照してください。

11.3.7. クラウドからの操作

11.3.7.1. クラウドからのデータ設定

各インターフェースの設定については、「インターフェース設定」に記載している通り Armadillo 上の設定ファイルで行いますが、クラウドから設定値を変更することも可能です。

なお、クラウドからデータ設定を行うためには、表11.1「[DEFAULT] 設定可能パラメータ」の cloud_config を true に設定する必要があります。

設定を変更できる項目は以下の通りです。

接点入力設定
接点出力設定
RS485 レジスタ読み出し

下記の手順でデータを設定します。

AWS
AWS IoT Core の Device Shadow を更新して設定を行います。
1. AWS IoT Core に移動し、「管理」→「すべてのデバイス」→「モノ」を選択します。
2. デバイスの名前は「Armadillo-IoT ゲートウェイ A6E のシリアル番号を取得する」で取得したシリアル番号で登録されています。
3. 「Device Shadow」の「Classic Shadow」を選択します。
4. Device Shadow ドキュメントの「編集」を選択します。
5. 入力画面が表示されるため、設定データを入力し「更新」をクリックします。
Azure
Azure IoT Hub のデバイスツインを更新して設定を行います。
1. Azure portal から [IoT Hub] を開き、「Azure IoT Hub と Azure IoT Hub Device Provisioning Service の設定を行う」で作成した IoT Hub を選択します。[デバイス] を選択し、一覧の中から該当するデバイスID を選択します。
2. [デバイスツイン] を選択します。
3. デバイスツイン編集画面が表示されるため、設定データを入力し「保存」をクリックします。

各機能それぞれ、下記の通りのフォーマットとなっています。

接点入力設定

表11.18 接点入力設定値

項目	概要	設定値	内容
type	動作種別	(空欄) or none	接点入力状態取得を行わない
		polling	ポーリング
		edge	エッジ検出
edge_type	エッジ検出設定	falling	立ち下がりエッジ
		rising	立ち上がりエッジ
		both	両方
interval	データ取得間隔[sec]	1～3600	この値に従って、値を読み出します

AWS

フォーマットは下記の通りです。

{
  "state": {
    "desired": {
    "<制御ポート>_config": { 
        "type" : <polling or edge>,
        "edge_type" : <falling or rising or both>,
        "interval" : <読み出し間隔>
      }
    }
  }
}

制御ポートは DI1, DI2 のいずれかを指定してください

{
  "state": {
    "desired": {
    "DI1_config": {
        "type" : "polling",
        "edge_type" : falling,
        "interval" : 5
      }
    }
  }
}

図11.40 接点入力制御シャドウ設定例

Azure

フォーマットは下記の通りです。デバイスツインの "desired" プロパティに設定します。

{
  "properties": {
    "desired": {
    "<制御ポート>_config": { 
        "type" : <polling or edge>,
        "edge_type" : <falling or rising or both>,
        "interval" : <読み出し間隔>
      },
      :
    }
  }
}

制御ポートは DI1, DI2 のいずれかを指定してください

{
  "properties": {
    "desired": {
    "DI1_config": {
        "type" : "polling",
        "edge_type" : falling,
        "interval" : 5
      },

図11.41 接点入力制御デバイスツイン設定例

接点出力設定

クラウドから設定内容を受信したタイミングで接点出力動作を停止し、設定内容を更新します。

表11.19 接点出力設定値

項目	概要	設定値	内容
output_state	出力状態	high	High
output_state	出力状態	low	Low
output_time	出力時間[sec]	1～3600	出力コマンド実行後に output_state で指定したレベルを出力する時間。 0 を指定すると出力値を固定します。
output_delay_time	出力遅延時間[sec]	0～3600	出力コマンド実行後、指定した時間遅延して出力します。

AWS

フォーマットは下記の通りです。

{
  "state": {
    "desired": {
    "<制御ポート>_config": { 
        "output_state" : <high or low>,
        "output_time" : <出力時間>,
        "output_delay_time" : <出力遅延時間>
      }
    }
  }
}

制御ポートは DO1, DO2 のいずれかを指定してください

{
  "state": {
    "desired": {
    "DO1_config": {
        "output_state" : "high",
        "output_time" : 10,
        "output_delay_time" : 10
      }
    }
  }
}

図11.42 接点出力制御シャドウ設定例

Azure

フォーマットは下記の通りです。デバイスツインの "desired" プロパティに設定します。

{
  "properties": {
    "desired": {
    "<制御ポート>_config": { 
        "output_state" : <high or low>,
        "output_time" : <出力時間>,
        "output_delay_time" : <出力遅延時間>
      },
      :
    }
  }
}

制御ポートは DO1, DO2 のいずれかを指定してください

{
  "properties": {
    "desired": {
      "DO1_config": {
        "output_state" : "high",
        "output_time" : 10,
        "output_delay_time" : 10
      },

図11.43 接点出力制御デバイスツイン設定例

RS485 レジスタ読み出し

表11.20 RS485レジスタ読み出し設定値

項目	概要	設定値	内容
method	通信種別	none	RS485を利用しない
method	通信種別	rtu	Modbus-RTU
data_size	データサイズ	8
baudrate	ボーレート	1200～38400[bps]	通信速度を指定します
parity	パリティビット	none	None
		odd	Odd
		even	Even
stop	ストップビット	1	1
stop	ストップビット	2	2
device_id	Modbusスレーブ機器のデバイスID	0x01 〜 0xF7
func_code	ファンクションコード	0x03 or 0x04
register_addr	レジスタアドレス	機器依存	値を読み出すレジスタのアドレスを指定
register_count	読み出しレジスタ数	1 or 2	一度に読み出すレジスタ数を指定
endian	エンディアン設定	little	リトルエンディアン
endian	エンディアン設定	big	ビッグエンディアン
interval	データ取得間隔[sec]	1～3600	この値に従って、値を読み出します
data_offset	読み出し値に加算する値	任意の値(整数値)	指定は任意です。読み出したレジスタ値に加算する値を指定します
data_multiply	読み出し値と乗算する値	任意の値(整数値)	指定は任意です。読み出したレジスタ値と乗算する値を指定します
data_devider	読み出し値と除算する値	任意の値(整数値)	指定は任意です。読み出したレジスタ値と除算する値を指定します

AWS

フォーマットは下記の通りです。

{
  "state": {
    "desired": {
      "RS485_Data<1～4>_config": { 
        "method" : <種別>,
        "baudrate" : <ボーレート>,
        "data_size": <データサイズ>,
        "parity" : <パリティ>,
        "stop" : <ストップビット>,
        "device_id" : <デバイス ID>,
        "func_code" : <ファンクションコード>,
        "register_addr" : <レジスタアドレス>,
        "register_count" : <読み出すレジスタ数>,
        "endian" : <エンディアン種別>,
        "interval" : <読み出し間隔>,
        "data_offset" : <データに加算する値>,
        "data_multiply" : <データに乗算する値>,
        "data_devider" : <データと除算する値>
      }
    }
  }
}

1～4 のいずれかを指定してください

{
  "state": {
    "desired": {
      "RS485_Data1_config": {
        "baudrate" : 9600,
        "parity" : "none",
        "stop" : 1,
        "device_id" : "01",
        "func_code" : "03",
        "register_addr" : "0000",
        "register_count" : 2,
        "endian" : "big",
        "interval" : 30,
        "data_offset" : 0,
        "data_multiply" : 0,
        "data_devider" : 0
      }
    }
  }
}

図11.44 RS485レジスタ読み出しシャドウ設定例

Azure

フォーマットは下記の通りです。デバイスツインの "desired" プロパティに設定します。

{
  "properties": {
    "desired": {
      "RS485_Data<1～4>_config": { 
        "method" : <種別>,
        "baudrate" : <ボーレート>,
        "data_size": <データサイズ>,
        "parity" : <パリティ>,
        "stop" : <ストップビット>,
        "device_id" : <デバイス ID>,
        "func_code" : <ファンクションコード>,
        "register_addr" : <レジスタアドレス>,
        "register_count" : <読み出すレジスタ数>,
        "endian" : <エンディアン種別>,
        "interval" : <読み出し間隔>,
        "data_offset" : <データに加算する値>,
        "data_multiply" : <データに乗算する値>,
        "data_devider" : <データと除算する値>
      },
      :
    }
  }
}

1～4 のいずれかを指定してください

{
  "properties": {
    "desired": {
      "RS485_Data1_config": {
        "baudrate" : 9600,
        "parity" : "none",
        "stop" : 1,
        "device_id" : "01",
        "func_code" : "03",
        "register_addr" : "0000",
        "register_count" : 2,
        "endian" : "big",
        "interval" : 30,
        "data_offset" : 0,
        "data_multiply" : 0,
        "data_devider" : 0
      },

図11.45 RS485レジスタ読み出しデバイスツイン設定例

11.3.7.2. クラウドからのデバイス制御

以下について、クラウドからデバイスの動きを制御することができます。

接点出力制御
- 接点出力開始/終了の制御
RS485 レジスタ書き込み
- 接続したデバイスのレジスタへの書き込み
LED 点灯制御
- アプリケーション LED の点灯 on/off 制御を行います

以下の手順で実行します。

AWS
AWS IoT Core のデバイスシャドウを更新し、制御を行います。更新方法については「クラウドからのデータ設定」と同じです。
Azure
Azure IoT Hub のダイレクトメソッドを更新して設定を行います。
1. Azure portal から [IoT Hub] を開き、「Azure IoT Hub と Azure IoT Hub Device Provisioning Service の設定を行う」で作成した IoT Hub を選択します。[デバイス] を選択し、一覧の中から該当するデバイスID を選択します。
2. [ダイレクトメソッド] を選択します。
3. ダイレクトメソッド集画面が表示されるため、メソッド名とペイロードを入力し、「メソッドの呼び出し」をクリックします。

各機能それぞれ、下記の通りのフォーマットとなっています。

接点出力制御

表11.21 接点出力制御設定値

項目	概要	設定値	内容
action	制御状態	start	出力開始。ゲートウェイコンテナ起動後に接点出力の設定内容を更新した場合は、一度接点出力制御で出力動作を停止してください。その後、出力開始することで更新内容を適用して動作を開始します。
action	制御状態	stop	接点出力動作を停止します。出力状態については、受信したタイミングの出力状態で固定します。

AWS

フォーマットは下記の通りです。

{
  "state": {
    "desired": {
    "<制御ポート>_command": { 
        "action" : <start or stop>
      }
    }
  }
}

制御ポートは DO1, DO2 のいずれかを指定してください

{
  "state": {
    "desired": {
    "DO1_command": {
        "action" : "start"
      }
    }
  }
}

図11.46 接点出力制御シャドウ設定例

Azure
メソッド名とペイロードのフォーマットは下記の通りです。
- メソッド名
```
<制御ポート>_command 
```
制御ポートは DO1, DO2 のいずれかを指定してください
- ペイロード
```
{"action" : <start or stop> }
```
各パラメータの設定例は下記の通りです。
- メソッド名
```
DO1_command
```
- ペイロード
```
{"action" : "start"}
```

RS485 レジスタ書き込み

表11.22 RS485 レジスタ書き込みシャドウ設定値

項目	概要	設定値	内容
method	通信種別	rtu	Modbus-RTU
data_size	データサイズ	8
baudrate	ボーレート	1200～38400[bps]	通信速度を指定します
parity	パリティビット	none	None
		odd	Odd
		even	Even
stop	ストップビット	1	1
stop	ストップビット	2	2
device_id	Modbusスレーブ機器のデバイスID	0x01 〜 0xF7
func_code	ファンクションコード	0x03 or 0x04
register_addr	レジスタアドレス	機器依存	値を読み出すレジスタのアドレスを指定
write_byte	レジスタに書き込む値	1

AWS

フォーマットは下記の通りです。

{
  "state": {
    "desired": {
      "RS485_command": {
        "method" : <種別>,
        "baudrate" : <ボーレート>,
        "data_size": <データサイズ>,
        "parity" : <パリティ>,
        "stop" : <ストップビット>,
        "device_id" : <デバイス ID>,
        "func_code" : <ファンクションコード>,
        "register_addr" : <レジスタアドレス>,
        "write_byte": <書き込む値>
      }
    }
  }
}

{
  "state": {
    "desired": {
      "RS485_command": {
        "method" : "rtu",
        "baudrate" : 19200,
        "data_size": 8,
        "parity" : "none",
        "stop" : 1,
        "device_id" : 1,
        "func_code" : 5,
        "register_addr" : 3,
        "write_byte": 1
      }
    }
  }
}

図11.47 RS485 レジスタ書き込みシャドウ設定例

Azure

メソッド名とペイロードのフォーマットは下記の通りです。

メソッド名

RS485_command

ペイロード

{
  "method" : <種別>,
  "baudrate" : <ボーレート>,
  "data_size": <データサイズ>,
  "parity" : <パリティ>,
  "stop" : <ストップビット>,
  "device_id" : <デバイス ID>,
  "func_code" : <ファンクションコード>,
  "register_addr" : <レジスタアドレス>,
  "write_byte": <書き込む値>
}

各パラメータの設定例は下記の通りです。

メソッド名

RS485_command

ペイロード

{
  "method" : "rtu",
  "baudrate" : 19200,
  "data_size": 8,
  "parity" : "none",
  "stop" : 1,
  "device_id" : 1,
  "func_code" : 5,
  "register_addr" : 3,
  "write_byte": 1
}

LED
表11.23 LED 点灯制御設定値
項目概要設定値内容
state
点灯状態
on
点灯
off
消灯
- AWS
  フォーマットは下記の通りです。
```
{
  "state": {
    "desired": {
    "led_command": {
        "state" : <on or off>
      }
    }
  }
}
```
  { "state": { "desired": { "led_command": { "state" : "off" } } } }
  図11.48 LED 点灯制御シャドウ設定例
- Azure
  メソッド名とペイロードのフォーマットは下記の通りです。
  - メソッド名
```
led_command
```
  - ペイロード
```
{"state" : <on or off>}
```
  各パラメータの設定例は下記の通りです。
  - メソッド名
```
led_command
```
  - ペイロード
```
{"state" : "off"}
```

11.3.8. コンテナの終了

podman_start で起動したゲートウェイコンテナを終了させる場合は、以下のコマンドを実行してください。

[armadillo ~]# podman stop a6e-gw-container

11.3.9. ログ内容確認

「設定ファイルの編集」でログファイルにログを出力する設定にした場合、インターフェース部とクラウド部にわかれて、それぞれ以下のファイルに出力されます。

インターフェース部
- /var/app/volumes/gw_container/device/log/sensing_mgr.log
クラウド部
- /var/app/volumes/gw_container/device/log/cloud_agent.log

ログファイルは自動的にローテートされるように設定されています。ローテートされると、各ファイルの末尾に番号が付与されます。なお、ファイル数が10を超えた場合は古いファイルから削除されます。

また、ログファイルの内容はテキストデータであり、以下のようなフォーマットになっています。

出力日時 ログレベル : メッセージ

図11.49 ログファイルのフォーマット

11.3.10. ゲートウェイコンテナの構成

ゲートウェイコンテナは下記の通り構成されています。コンテナ内外関わらず、誤ってファイルを削除した場合はインストールディスクで初期化を行ってください。

起動スクリプト

コンテナ起動時、下記のスクリプトを実行します。

/usr/bin/gw-app.sh

ゲートウェイコンテナアプリケーション

ゲートウェイコンテナアプリケーションは下記に配置されています。

/usr/lib/python3.10/site-packages/atgateway/

ボリュームマウント

以下のパスをコンテナ内でマウントしています。

ホストパス	コンテナパス	概要
/var/app/rollback/volumes/gw_container/cert	/cert/ca	デバイス認証関連ファイル
/var/app/rollback/volumes/gw_container/config	/config	ゲートウェイコンテナコンフィグファイル
/var/app/rollback/volumes/gw_container/src	/root/gw_container	ゲートウェイコンテナ main 関数
/var/app/volumes/gw_container/device/cert	/cert/device	デバイス証明書関連ファイル
/var/app/volumes/gw_container/device/log	/log	ゲートウェイコンテナログ

11.4. ゲートウェイコンテナを拡張する

ゲートウェイコンテナのアプリケーションは Python で記述されており、起動スクリプトから実行されます。

アプリケーションを拡張したい場合は /var/app/rollback/volumes/gw_container/src/customize/ に main.py を配置すると、自動的にそちらが実行されるようになります。ゲートウェイコンテナアプリケーションのソースコードは以下にアップロードしているため、適宜参照してご利用ください。

また、 Armadilloサイトの Howto やブログでも、手順を記載した記事を公開しています。

11.5. アプリケーションコンテナを作成、実行する

11.5.1. Podman - コンテナ仮想化ソフトウェア

11.5.1.1. Podman - コンテナ仮想化ソフトウェアとは

コンテナとはホスト OS 上に展開される仮想的なユーザ空間のことです。コンテナを使用することで複数の Armadillo-IoT ゲートウェイ A6E でも同一の環境がすぐに再現できます。ゲスト OS を必要としない仮想化であるため、アプリケーションの起動が素早いという特徴があります。

Podman とはこのようなコンテナを管理するためのソフトウェアであり、使用方法はコンテナ管理ソフトウェアの 1 つである Docker と互換性があります。

11.5.2. コンテナを操作する

この章では、コンテナ仮想化ソフトウェアの 1 つである Podman の基本的な使い方について説明します。 Armadillo-IoT ゲートウェイ A6E で実行させたいアプリケーションとその実行環境自体を 1 つの Podman イメージとして扱うことで、複数の Armadillo-IoT ゲートウェイ A6E がある場合でも、全てのボード上で同一の環境を再現させることが可能となります。

この章全体を通して、イメージの公開・共有サービスである Docker Hub から取得した、Alpine Linux のイメージを使って説明します。

11.5.2.1. イメージからコンテナを作成する

イメージからコンテナを作成するためには、podman_start コマンドを実行します。 podman や docker にすでに詳しいかたは podman run コマンドでも実行できますが、ここでは「コンテナの運用」で紹介するコンテナの自動起動の準備も重ねて podman_start を使います。イメージは Docker Hub から自動的に取得されます。ここでは、簡単な例として "ls /" コマンドを実行するコンテナを作成します。

[armadillo ~]# vi /etc/atmark/containers/my_container.conf 
set_image docker.io/alpine
set_command ls /
[armadillo ~]# podman pull docker.io/alpine 
Trying to pull docker.io/library/alpine:latest...
Getting image source signatures
:（省略）
Writing manifest to image destination
Storing signatures
a6215f271958c760a2975a6765016044115dbae4b90f414eba3a448a6a26b4f6
[armadillo ~]# podman_start my_container 
Starting 'my_container'
b141e899b5ef7c9ec5434bda8f6a83d3e6bfc94f74bfb5dcef2a22041c71fdbf
[armadillo ~]# podman logs my_container 
bin
dev
:（省略）
usr
var
[armadillo ~]#

図11.50 コンテナを作成する実行例

	コンテナのコンフィグを作成します。このファイルでは、コンテナのイメージやコマンド、デバイスへのアクセス権限を設定します。詳しい設定の説明には「コンテナの自動起動」を参照ください。
	コンテナのイメージを取得します。イメージが Armadillo に置いてない場合は「Error: docker.io/alpine: image not known」の様なエラーで失敗します。
	コンテナを起動します。これは Armadillo 起動時に自動的に起動されるコンテナと同じものになります。自動起動が不要な場合には `set_autostart no` で無効化できます。
	`podman logs` コマンドで出力を確認します。 "ls /" を実行するだけの "my_container" という名前のコンテナが作成されました。コンテナが作成されると同時に "ls /" が実行され、その結果がログに残ります。ここで表示されているのは、コンテナ内部の "/" ディレクトリのフォルダの一覧です。

コンフィグファイルの直接な変更と podman pull によるコンテナの取得はデフォルト状態ではメモリ上でしか保存されません。ファイルは persist_file で必ず保存し、コンテナイメージは abos-ctrl podman-storage --disk で podman のストレージを eMMC に切り替えるか abos-ctrl podman-rw で一時的に eMMC に保存してください。運用中の Armadillo には直接に変更をせず、 swupdate でアップデートしてください。コンフィグファイルを保存して、 set_autostart no を設定しない場合は自動起動します。


	`podman_start` でコンテナが正しく起動できない場合は `podman_start -v <my_container>` で `podman run` のコマンドを確認し、 `podman logs <my_container>` で出力を確認してください。

11.5.2.2. コンテナ一覧を表示する

作成済みコンテナ一覧を表示するためには podman ps コマンドを実行します。

[armadillo ~]# podman ps -a
CONTAINER ID  IMAGE                            COMMAND    CREATED         STATUS                    PORTS    NAMES
d6de5881b5fb  docker.io/library/alpine:latest  ls /       12 minutes ago  Exited (0) 11 minutes ago          my_container

図11.51 コンテナ一覧の表示実行例

一覧表示により、コンテナ名やコンテナ ID を確認することができます。-a オプションを付けない場合は、動作中のコンテナのみ表示されます。 podman ps コマンドの詳細は --help オプションで確認できます。

[armadillo ~]# podman ps --help

図11.52 podman ps --help の実行例

11.5.2.3. コンテナを起動する

作成済みのコンテナを起動するためには podman start コマンドを実行します。

[armadillo ~]# podman start my_container
podman start my_container
[ 3119.081068] IPv6: ADDRCONF(NETDEV_CHANGE): vethe172e161: link becomes ready
[ 3119.088214] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 3119.094812] cni-podman0: port 1(vethe172e161) entered blocking state
[ 3119.101231] cni-podman0: port 1(vethe172e161) entered disabled state
[ 3119.107745] device vethe172e161 entered promiscuous mode
[ 3119.113185] cni-podman0: port 1(vethe172e161) entered blocking state
[ 3119.119546] cni-podman0: port 1(vethe172e161) entered forwarding state
my_container
[ 3119.620731] cni-podman0: port 1(vethe172e161) entered disabled state
[ 3119.627696] device vethe172e161 left promiscuous mode
[ 3119.632762] cni-podman0: port 1(vethe172e161) entered disabled state

図11.53 コンテナを起動する実行例

-a オプションを与えると、コンテナ内で実行されたアプリケーションの出力を確認できます。

[armadillo ~]# podman start -a my_container
[ 3150.303962] IPv6: ADDRCONF(NETDEV_CHANGE): vetha9ef8f8e: link becomes ready
[ 3150.311106] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 3150.317703] cni-podman0: port 1(vetha9ef8f8e) entered blocking state
[ 3150.324139] cni-podman0: port 1(vetha9ef8f8e) entered disabled state
[ 3150.330687] device vetha9ef8f8e entered promiscuous mode
[ 3150.336085] cni-podman0: port 1(vetha9ef8f8e) entered blocking state
[ 3150.342443] cni-podman0: port 1(vetha9ef8f8e) entered forwarding state
bin    etc    lib    mnt    proc   run    srv    tmp    var
dev    home   media  opt    root   sbin   sys    usr
[ 3150.804164] cni-podman0: port 1(vetha9ef8f8e) entered disabled state
[ 3150.811249] device vetha9ef8f8e left promiscuous mode
[ 3150.816349] cni-podman0: port 1(vetha9ef8f8e) entered disabled state

図11.54 コンテナを起動する実行例(a オプション付与)

ここで起動している my_container は、起動時に "ls /" を実行するようになっているので、その結果が出力されます。 podman start コマンドの詳細は --help オプションで確認できます。

[armadillo ~]# podman start --help

図11.55 podman start --help 実行例

11.5.2.4. コンテナを停止する

動作中のコンテナを停止するためには podman stop コマンドを実行します。

[armadillo ~]# podman stop my_container
my_container

図11.56 コンテナを停止する実行例

podman stop コマンドの詳細は --help オプションで確認できます。

[armadillo ~]# podman stop --help

図11.57 podman stop --help 実行例

11.5.2.5. コンテナの変更を保存する

コンテナに対して変更が行われた状態で、そのままコンテナを停止してしまうと変更が失なわれてしまいます。

変更を保存するには二つの方法があります。

podman commit コマンドで保存する。
```
[armadillo ~]# podman commit my_container image_name:latest
Getting image source signatures
Copying blob f4ff586c6680 skipped: already exists
Copying blob 3ae0874b0177 skipped: already exists
Copying blob ea59ffe27343 done
Copying config 9ca3c55246 done
Writing manifest to image destination
Storing signatures
9ca3c55246eaac267a71731bad6bfe4b0124afcdd2b80c4f730c46aae17a88f3
```
図11.58 my_containerを保存する例
podman commitで保存する度に、変更が行なわれた差分が保存されます。繰り返し差分を保存すると、イメージサイズが大きくなってしまいます。ストレージ容量が不足する場合は、ベースとなるOSのイメージから作り直してください。

ボリュームを使用する。

podman_start の add_volumes コマンドでコンテナに Armadillo Base OS のディレクトリをコンテナで使うことができます。保存するデータの性質によって、保存先を選択してください。 . /var/app/volumes/myvolume: アップデートした場合はコピーされません。ログやデータベースなど、アプリケーションが作成し続けるようなデータの保存に向いています。 . myvolume か /var/app/rollback/volumes/myvolume: アップデートの際にコピーしてアップデートを行うので、アップデート中でも安全に使いつづけます。アプリケーションと一緒にアップデートするようなデータの保存に向いています。

コンテナを前のバージョンに戻した場合(ロールバック)、/var/app/rollback/volumes/ のデータの前のバージョンに戻ります。

その為、アプリケーションのバージョンに依存するようなデータは /var/app/rollback/volumes/ に入れることを推奨します。

mkswu の swdesc_files (--extra-os 無し）と podman_start` の add_volumes では、相対パスはそのディレクトリをベースにします。 /var/app/rollback/volumes/myvolume は myvolume で簡潔に指定できます。

Copy-on-Write (CoW) について。

この二つの volumes ディレクトリは btrfs と呼ばれるファイルシステムに保存されています。 btrfs ではデータは Copy on Write（CoW）を使ってデータ完全性を保証しますが、その保証にはコストがあります。

数百 MB のファイルに小さな変更を頻繁に行う場合 CoW を無効化することを推奨します。 CoW を無効化されたファイルにチェックサムが入らなくなりますので、極端な場合以外に残してください。

[armadillo ~]# cd /var/app/volumes/
[armadillo /var/app/volumes]# mkdir database
[armadillo /var/app/volumes]# chattr +C database 
[armadillo /var/app/volumes]# echo example data > database/example
[armadillo /var/app/volumes]# lsattr database/ 
---------------C---- database/example

図11.59 chattr によって copy-on-write を無効化する例

	`chattr +C` でディレクトリに NoCow を設定します。これから作成されるファイルが NoCow で作成されます。すでに存在していたファイルに影響ないのでご注意ください。
	`lsattr` 確認します。リストの C の字があればファイルが「no cow」です。

11.5.2.6. コンテナの自動作成やアップデート

podman run, podman commitでコンテナを作成できますが、定期的にアップデートをする際にはコンテナの作成やアップデートを自動化できると便利です。

これを実現するために、Dockerfileとpodman buildを使います。この手順はArmadilloで実行可能です。

イメージを docker.io のイメージから作りなおします

[armadillo ~/podman-build]# cat Dockerfile
FROM docker.io/arm32v7/alpine:latest

# update & install dependencies (example: usbutils)
RUN apk upgrade && apk add usbutils && rm -f /var/cache/apk/*

# copy our application and set it to run on start
COPY my_application /my_application
ENTRYPOINT /my_application

[armadillo ~/podman-build]# podman build -t my_image:1 -t my_image:latest .
STEP 1: FROM docker.io/arm32v7/alpine:latest
STEP 2: RUN apk upgrade && apk add usbutils && rm -f /var/cache/apk/*
--> 234bf79175e
STEP 3: COPY my_application /my_application
--> 05ab31bb278
STEP 4: ENTRYPOINT /my_application
STEP 5: COMMIT my_image:latest
--> 590e3ba6d55
Successfully tagged localhost/my_image:1
Successfully tagged localhost/my_image:latest
590e3ba6d55f3e29bdef158d7283e9c4f7515567b2d3f978cfab2510dc02376b

[armadillo ~/podman-build]# podman save my_image:latest -o my_image_1.tar

図11.60 podman buildの実行例

イメージを前のバージョンからアップデートします

[armadillo ~/podman-build-update]# cat Dockerfile
FROM localhost/my_image:latest

# update OS packages
RUN apk upgrade --no-cache

# update application
COPY my_application /my_application
[armadillo ~/podman-build-update]# podman build -t my_image:2 -t my_image:latest .
STEP 1: FROM localhost/my_image:latest
STEP 2: RUN apk upgrade --no-cache
--> cf1dc0d7296
STEP 3: COPY my_application /my_application
STEP 4: COMMIT my_image:latest
--> 9e9d9366072
Successfully tagged localhost/my_image:2
Successfully tagged localhost/my_image:latest
9e9d9366072751007b2e70544d76c46b95a7a5a02df658ef0fa3f7dcccf8850a

[armadillo ~/podman-build-update]# podman save -o my_image_2.tar my_image:2

図11.61 podman buildでのアップデートの実行例

この場合、 podman_partial_image コマンドを使って、差分だけをインストールすることもできます。

[armadillo ~/podman-build-update]# podman_partial_image -b my_image:1 \
        -o my_image_2_partial.tar my_image:2

[armadillo ~/podman-build-update]# ls -lh
-rw-r--r-- 1 root root   88 Dec 21 15:24 Dockerfile
-rw-r--r-- 1 root root 9.4M Dec 21 15:26 my_image_1.tar
-rw-r--r-- 1 root root 9.4M Dec 21 15:26 my_image_2.tar
-rw-r--r-- 1 root root  51K Dec 21 15:26 my_image_2_partial.tar

作成した .tar アーカイブは「mkswu の desc ファイル」の swdesc_embed_container と swdesc_usb_container で使えます。

11.5.2.7. コンテナを削除する

作成済みコンテナを削除する場合は podman rm コマンドを実行します。

[armadillo ~]# podman rm my_container
d6de5881b5fb973227b84d1d74abf269ac3183aad7e18b7a9d85208632641d94
[armadillo ~]# podman ps -a
CONTAINER ID  IMAGE                            COMMAND    CREATED         STATUS                    PORTS    NAMES

図11.62 コンテナを削除する実行例

podman ps コマンドの出力結果より、コンテナが削除されていることが確認できます。 podman rm コマンドの詳細は --help オプションで確認できます。

[armadillo ~]# podman rm --help

図11.63 $ podman rm --help 実行例

11.5.2.8. イメージを削除する

podmanのイメージを削除するには podman rmi コマンドを実行します。イメージを削除するためには、そのイメージから作成したコンテナを先に削除しておく必要があります。 podman rmi コマンドにはイメージ ID を指定する必要があるため、podman images コマンドで確認します。

[armadillo ~]# podman rm my_container
[armadillo ~]# podman images
REPOSITORY                TAG        IMAGE ID      CREATED      SIZE
docker.io/library/alpine  latest     02480aeb44d7  2 weeks ago  5.62 MB
[armadillo ~]# podman rmi 02480aeb44d7
Untagged: docker.io/library/alpine:latest
Deleted: 02480aeb44d78f1a44b8791af7edf7d6e1b18707397a1dfb3ff4f21c5ce4a44f
[armadillo ~]# podman images
REPOSITORY                TAG        IMAGE ID      CREATED      SIZE

図11.64 イメージを削除する実行例

podman images コマンドの出力結果より、コンテナが削除されていることが確認できます。 podman rmi コマンドの詳細は --help オプションで確認できます。

[armadillo ~]# podman rmi --help

図11.65 podman rmi --help 実行例

SWU で転送されたイメージは podman images で Read-Only として表示されますので、 podman rmi を実行するとエラーとなります。その場合は abos-ctrl podman-rw rmi をご使用ください。 abos-ctrl podman-rw については「イメージを eMMC に保存する方法」を参照してください。

[armadillo ~]# podman images
REPOSITORY                TAG        IMAGE ID      CREATED      SIZE       R/O
docker.io/library/alpine  latest     02480aeb44d7  2 weeks ago  5.62 MB    true
[armadillo ~]# podman rmi docker.io/alpine
Error: cannot remove read-only image "02480aeb44d78f1a44b8791af7edf7d6e1b18707397a1dfb3ff4f21c5ce4a44f"
[armadillo ~]# abos-ctrl podman-rw rmi docker.io/alpine
Untagged: docker.io/library/alpine:latest
Deleted: 02480aeb44d78f1a44b8791af7edf7d6e1b18707397a1dfb3ff4f21c5ce4a44f
[armadillo ~]# podman images
REPOSITORY                TAG        IMAGE ID      CREATED      SIZE

図11.66 Read-Onlyのイメージを削除する実行例

11.5.2.9. コンテナとコンテナに関連するデータを削除する

abos-ctrl container-clear を使用すると、コンテナ、コンテナイメージ、コンテナに関するデータを削除することができます。


	全てのコンテナとコンテナイメージ、コンテナに関するデータが削除されるため、充分に注意して使用してください。

abos-ctrl container-clear は以下の通り動作します。

以下のファイル、ディレクトリ配下のファイルを削除
- /var/app/rollback/volumes/
- /var/app/volumes/
- /etc/atmark/containers/*.conf
以下のファイルで container を含む行を削除
- /etc/sw-versions
- /etc/swupdate.watch

[armadillo ~]# abos-ctrl container-clear
This command will remove all containers and related data.
 - The following file and directories will be removed:
   - /var/app/rollback/volumes/
   - /var/app/volumes/
   - /etc/atmark/containers/*.conf
 - Lines containing the word "container" will be deleted from the following files:
   - /etc/sw-versions
   - /etc/swupdate.watch
Continue? [y/N]
y
Remove all container data succeeded

図11.67 abos-ctrl container-clear 実行例

11.5.2.10. 実行中のコンテナに接続する

実行中のコンテナに接続し、コンテナ内で指定したコマンドを実行するには podman exec コマンドを実行します。 podman exec コマンドでコンテナ内部のシェルを起動すると、コンテナ内部を操作できるようになります。ここでは、sleep infinity コマンドを実行して待ち続けるだけのコンテナを作成し、そのコンテナに対して podman exec コマンドでシェルを起動する例を示します。

[armadillo ~]# vi /etc/atmark/containers/sleep_container.conf
set_image docker.io/alpine
set_command sleep infinity
add_args --init
[armadillo ~]# podman_start sleep_container
Starting 'test'
f62e7a666d7156d261905c8406c72fc271534fa29e69771c76f4f6660a2da41a
[armadillo ~]# podman exec -it sleep_container sh
[container ~]# ps
PID   USER     TIME  COMMAND
    1 root      0:00 /run/podman-init -- sleep infinity
    2 root      0:00 sleep infinity
    3 root      0:00 sh
    4 root      0:00 ps

図11.68 コンテナ内部のシェルを起動する実行例

podman_start コマンドでコンテナを作成し、その後作成したコンテナ内で sh を実行しています。 sh を実行すると、コンテナ内のプロンプトが表示されコンテナ内部を操作できるようになります。上記ではコンテナ内で、ps コマンドを実行しています。コンテナ作成時に実行した sleep と podman exec で実行した sh がプロセスとして存在していることが確認できます。

コンテナ内のシェルから抜ける時は exit コマンドを実行します。

[container ~]# exit

図11.69 コンテナ内部のシェルから抜ける実行例

podman exec コマンドから抜けても、コンテナがまだ実行中です。コンテナを停止したい場合は podman stop sleep_container か podman kill sleep_container で停止して podman rm sleep_container でそのコンテナを削除してください。 podman exec コマンドの詳細は --help オプションで確認できます。

[armadillo ~]# podman exec --help

図11.70 podman exec --help 実行例

11.5.2.11. コンテナ間で通信をする

複数のコンテナを実行している環境で、それらのコンテナ間で通信を行う方法を示します。これにより、例えば SQL サーバを実行しているコンテナに対し別のコンテナから接続するといった使い方ができます。

コンテナには作成した時点でローカル IP アドレスが割り当てられるので、コンテナの名前かその IP アドレスで通信を行うことができます。

準備として、2 つのコンテナを作成します。

[armadillo ~]# vi /etc/atmark/containers/my_container_1.conf
set_image docker.io/alpine
set_command sleep infinity
[armadillo ~]# vi /etc/atmark/containers/my_container_2.conf
set_image docker.io/alpine
set_command sleep infinity
[armadillo ~]# podman_start my_container_1 my_container_2
Starting 'my_container_1'
cbe0802f4e2d2fec88f4e300dabeba3b48865359dc02cbd99375b1b38c2c28eb
Starting 'my_container_2'

図11.71 コンテナを作成する実行例

コンテナに割り当てられた IP アドレスを確認するには podman inspect コマンドを実行します。

[armadillo ~]# podman inspect --format='{{.NetworkSettings.IPAddress}}' my_container_1
10.88.0.108
[armadillo ~]# podman inspect --format='{{.NetworkSettings.IPAddress}}' my_container_2
10.88.0.109

図11.72 コンテナの IP アドレスを確認する実行例

これらの IP アドレスを使って、一方のコンテナからもう一方のコンテナへ対し ping コマンドで疎通確認を行うことができます。

[armadillo ~]# podman exec -it my_container_1 sh
[container ~]# ping -c 2 my_container_2
PING my_container_2 (10.88.0.109): 56 data bytes
64 bytes from 10.88.0.109: seq=0 ttl=42 time=0.144 ms
64 bytes from 10.88.0.109: seq=1 ttl=42 time=0.210 ms
--- my_container_2 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0.144/0.177/0.210 ms
[container ~]# ping -c 2 10.88.0.109
PING 10.88.0.109 (10.88.0.109): 56 data bytes
64 bytes from 10.88.0.109: seq=0 ttl=42 time=0.140 ms
64 bytes from 10.88.0.109: seq=1 ttl=42 time=0.138 ms
--- 10.88.0.109 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0.138/0.139/0.140 ms

図11.73 ping コマンドによるコンテナ間の疎通確認実行例

このように、my_container_1(10.88.0.108) から my_container_2(10.88.0.109) への通信が確認できます。

11.5.2.12. 開発時に有用な—privilegedオプション

コンテナに、全権限と全てのデバイスへのアクセスを許可するオプション --privileged があります。このオプションを利用すると、コンテナに与えるべき最小の権限を洗い出す必要が無いため、開発時に有用です。

実運用の際、このオプションを利用することはセキュリティー上問題がある為、開発時にのみご利用ください。コンテナに必要な最低限の権限を与えることをおすすめします。

11.5.3. アットマークテクノが提供するイメージを使う

アットマークテクノは、動作確認環境として使用できる Debian ベースのイメージを提供しています。ここでは、Docker ファイルからイメージをビルドする方法と、すでにビルド済みのイメージを使う方法の 2 つについて説明します。

11.5.3.1. Docker ファイルからイメージをビルドする

Armadillo-IoT ゲートウェイ A6E Debian コンテナから「Debian [VERSION] サンプル Dockerfile」ファイル (at-debian-image-dockerfile-armv7-[VERSION].tar.gz) をダウンロードします。その後 podman build コマンドを実行します。

[armadillo ~]# tar xzf at-debian-image-dockerfile-armv7-[VERSION].tar.gz
[armadillo ~]# cd at-debian-image-dockerfile-armv7-[VERSION]
[armadillo ~]# abos-ctrl podman-storage --disk
[armadillo ~]# podman build -t at-debian-image-armv7:latest .
:
: (省略)
:
[armadillo ~]# podman images
REPOSITORY                       TAG         IMAGE ID      CREATED        SIZE
localhost/at-debian-image-armv7  latest      9df263360ab3  2 minutes ago  123 MB
docker.io/arm32v7/debian         bullseye    971ca2764db3  10 days ago    105 MB

図11.74 Docker ファイルによるイメージのビルドの実行例

podman images コマンドにより at-debian-image-armv7 がビルドされたことが確認できます。 docker.io/arm32v7/debian イメージはベースとなっている Debian イメージです。

11.5.3.2. ビルド済みのイメージを使用する

Armadillo-IoT ゲートウェイ A6E Debian コンテナから「Debian [VERSION] サンプルコンテナイメージ」ファイル (at-debian-image-armv7-[VERSION].tar) をダウンロードします。その後 podman load コマンドを実行します。

[armadillo ~]# abos-ctrl podman-storage --disk
[armadillo ~]# podman load -i at-debian-image-armv7-[VERSION].tar
:
: (省略)
:
[armadillo ~]# podman images
REPOSITORY                       TAG         IMAGE ID      CREATED       SIZE
localhost/at-debian-image-armv7  latest      a947a7449be5  5 days ago   123 MB
localhost/at-debian-image-armv7  [VERSION]   a947a7449be5  5 days ago   123 MB

図11.75 ビルド済みイメージを load する実行例

podman images コマンドにより at-debian-image-armv7 がビルドされたことが確認できます。

11.5.3.3. ビルドしたイメージを使用してコンテナを作成する

[armadillo ~]# vi /etc/atmark/containers/at-debian-image-armv7.conf
set_image localhost/at-debian-image-armv7:latest
set_command sleep infinity
[armadillo ~]# podman_start at-debian-image-armv7
Starting 'at-debian-image-armv7'
d74e2efaf8a06a7f75ba636e6c224b2300f164075aace4914cefa169f1219497

図11.76 at-debian-image-armv7 を使用するコンテナの作成例

11.5.4. 入出力デバイスを扱う

この章では、コンテナ内で動作するアプリケーションから GPIO や I2C などの入出力デバイスを扱う方法について示します。基本的に、コンテナ内のアプリケーションからホスト OS 側のデバイスへアクセスすることはできません。このため、コンテナ内のアプリケーションからデバイスを扱うためには、コンテナ作成時に扱いたいデバイスを指定する必要があります。ここで示す方法は、扱いたいデバイスに関するデバイスツリーファイルが適切に設定されていることを前提としています。デバイスツリーファイルを設定していない場合は、適切に設定してください。

11.5.4.1. GPIO を扱う

コンテナ内で動作するアプリケーションから GPIO を扱うためには、Podman のイメージからコンテナを作成する際にホスト OS 側のデバイスファイル /dev/gpiochipN を渡す必要があります。以下は、/dev/gpiochip2 を渡して alpine イメージからコンテナを作成する例です。 /dev/gpiochipN を渡すと、GPION+1 を操作することができます。

[armadillo ~]# vi /etc/atmark/containers/gpio_example
set_image docker.io/alpine
set_command sleep infinity
add_devices /dev/gpiochip2
[armadillo ~]# podman_start gpio_example
Starting 'gpio_example'
956a0fecc48d5ea1210069910f7bb48b9e90b2dadb12895064d9776dae0360b5

図11.77 GPIO を扱うためのコンテナ作成例

コンテナ内に入ってコマンドで GPIO を操作する例を以下に示します。この例では GPIO3_IO21 を操作しています。

[armadillo ~]# podman exec -it gpio_example sh
[container ~]# apk upgrade
[container ~]# apk add libgpiod
[container ~]# gpioget gpiochip2 21 
0 
[container ~]# gpioset gpiochip2 21=1

図11.78 コンテナ内からコマンドで GPIO を操作する例

	GPIO 番号 21 の値を取得します。
	取得した値を表示します。
	GPIO 番号 21 に 1(High) を設定します。

他にも、gpiodetect コマンドで認識している gpiochip をリスト表示できます。以下の例では、コンテナを作成する際に渡した /dev/gpiochip2 が認識されていることが確認できます。

[container ~]# gpiodetect
gpiochip2 [30220000.gpio] (32 lines)

図11.79 gpiodetect コマンドの実行

gpioinfo コマンドでは、指定した gpiochip の詳細な情報を表示することができます。

[container ~]# gpioinfo gpiochip2
gpiochip2 - 32 lines:
        line   0:      unnamed          "?"  output  active-high [used]
        line   1:      unnamed       unused   input  active-High
        line   2:      unnamed       unused   input  active-high
        line   3:      unnamed       unused   input  active-high
        line   4:      unnamed       unused   input  active-high
        line   5:      unnamed       unused   input  active-high
        line   6:      unnamed       unused   input  active-high
        line   7:      unnamed       unused   input  active-high
        line   8:      unnamed       unused   input  active-high
        line   9:      unnamed       unused   input  active-high
        line  10:      unnamed       unused   input  active-high
        line  11:      unnamed       unused   input  active-high
        line  12:      unnamed       unused   input  active-high
        line  13:      unnamed       unused   input  active-high
        line  14:      unnamed       unused   input  active-high
        line  15:      unnamed       unused   input  active-high
        line  16:      unnamed       unused   input  active-high
        line  17:      unnamed       unused   input  active-high
        line  18:      unnamed       unused   input  active-high
        line  19:      unnamed       unused   input  active-high
        line  20:      unnamed       unused   input  active-high
        line  21:      unnamed       unused   input  active-high
        line  22:      unnamed       unused   input  active-high
        line  23:      unnamed       unused   input  active-high
        line  24:      unnamed       unused   input  active-high
        line  25:      unnamed       unused   input  active-high
        line  26:      unnamed       unused   input  active-high
        line  27:      unnamed       unused   input  active-high
        line  28:      unnamed       unused   input  active-high
        line  29:      unnamed       unused   input  active-high
        line  30:      unnamed       unused   input  active-high
        line  31:      unnamed       unused   input  active-high

図11.80 gpioinfo コマンドの実行

C 言語プログラムから操作する場合は、GPIO 操作ライブラリである libgpiod を使用することができます。

11.5.4.2. I2C を扱う

コンテナ内で動作するアプリケーションから I2C を扱うためには、Podman のイメージからコンテナを作成する際にホスト OS 側のデバイスファイル /dev/i2c-N を渡す必要があります。以下は、/dev/i2c-1 を渡して alpine イメージからコンテナを作成する例です。

[armadillo ~]# vi /etc/atmark/containers/i2c_example.conf
set_image docker.io/alpine
set_command sleep infinity
add_devices /dev/i2c-1
[armadillo ~]# podman_start i2c_example
Starting 'i2c_example'
efa1eb129c1f036a709755f0d53b21a0f2a39307ecae32b24aac98c0b6567bf0

図11.81 I2C を扱うためのコンテナ作成例

コンテナ内に入り、i2c-tools に含まれる i2cdetect コマンドを使ってスレーブアドレスを確認することができます。

[armadillo ~]# podman exec -it i2c_example sh
[container ~]# apk upgrade
[container ~]# apk add i2c-tools
[container ~]# i2cdetect -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- UU -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- UU -- -- --
50: UU -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- 68 -- -- -- -- -- -- --
70: -- -- 72 -- -- -- -- --

図11.82 i2cdetect コマンドによる確認例

11.5.4.3. シリアルインターフェースを扱う

コンテナ内で動作するアプリケーションから RS-232C や RS-485 などのシリアル通信を行うためには、 Podman のイメージからコンテナを作成する際にホスト OS 側のデバイスファイル /dev/ttymxcN を渡す必要があります。以下は、/dev/ttymxc0 を渡して alpine イメージからコンテナを作成する例です。

[armadillo ~]# vi /etc/atmark/containers/serial_example.conf
set_image docker.io/alpine
set_command sleep infinity
add_devices /dev/ttymxc0
[armadillo ~]# podman_start serial_example
Starting 'serial_example'
3999f09d51253371cacffd68967c90fdd5250770888a82f59d7810b54fcc873e

図11.83 シリアルインターフェースを扱うためのコンテナ作成例

コンテナ内に入り、setserial コマンドを使って現在の設定を確認することができます。

[armadillo ~]# podman exec -it serial_example sh
[container ~]# setserial -a /dev/ttymxc0
/dev/ttymxc0, Line 0, UART: undefined, Port: 0x0000, IRQ: 29
        Baud_base: 5000000, close_delay: 50, divisor: 0
        closing_wait: 3000
        Flags: spd_normal

図11.84 setserial コマンドによるシリアルインターフェイス設定の確認例

11.5.4.4. USB を扱う

コンテナ内で動作するアプリケーションから USB 接続のデバイスを扱うための方法について示します。

USB シリアルデバイスを扱う

USB シリアルデバイスをコンテナ内から扱う場合には、Podman のイメージからコンテナを作成する際にホスト OS 側の /dev/ttyUSBN を渡す必要があります。以下は、 /dev/ttyUSB0 を渡して alpine イメージからコンテナを作成する例です。

[armadillo ~]# podman run -itd --name=usb_example --device=/dev/ttyUSB0 docker.io/alpine /bin/sh

図11.85 USB シリアルデバイスを扱うためのコンテナ作成例

コンテナ内に入り、setserial コマンドを使って現在の設定を確認することができます。

[armadillo ~]# podman exec -it usb_example /bin/sh
[container ~]# setserial -a /dev/ttyUSB0
/dev/ttyUSB0, Line 0, UART: unknown, Port: 0x0000, IRQ: 0
        Baud_base: 24000000, close_delay: 0, divisor: 0
        closing_wait: infinite
        Flags: spd_normal

図11.86 setserial コマンドによるUSBシリアルデバイス設定の確認例

USB カメラを扱う

USB カメラをコンテナ内から扱う場合には、Podman のイメージからコンテナを作成する際にホスト OS 側の /dev/videoN を渡す必要があります。以下は、 /dev/video3 を渡して alpine イメージからコンテナを作成する例です。

[armadillo ~]# vi /etc/atmark/containers/usbcam_example.conf
set_image docker.io/alpine
set_command sleep infinity
add_devices /dev/video3
[armadillo ~]# podman_start usbcam_example
Starting 'usbcam_example'
ffe06090b45826cc0b1c7710e9e850ba9521d36b70de4288d0dfe1fe91a35632
[armadillo ~]# podman exec -it usbcam_example sh
[container ~]# ls /dev/video3
/dev/video3

図11.87 USB カメラを扱うためのコンテナ作成例

GStreamer などのマルチメディアフレームワークと組み合わせることで、USB カメラからの映像のキャプチャが可能となります。

USB メモリを扱う

ここでは、USB メモリを扱う方法について 2 つの例を示します。

ホスト OS 側でマウントした USB メモリをコンテナから扱う

あらかじめホスト OS 側でマウントしてある USB メモリをコンテナから扱う場合には、Podman のイメージからコンテナを作成する際にホスト OS 側で USB メモリをマウントしてるディレクトリを渡す必要があります。

[armadillo ~]# mount -t vfat /dev/sda1 /mnt
[armadillo ~]# echo test >> /mnt/sample.txt
[armadillo ~]# ls /mnt
sample.txt

図11.88 USB メモリをホスト OS 側でマウントする例

上記の例では、USB メモリを /mnt にマウントしました。以下は、 /mnt を渡して alpine イメージからコンテナを作成する例です。

[armadillo ~]# vi /etc/atmark/containers/usbmem_example.conf
set_image docker.io/alpine
set_command sleep infinity
add_volumes /mnt
[armadillo ~]# podman_start usbmem_example
Starting 'usbmem_example'
ef77d4bfd5b04f3b8b5ddcb5bfac321304fa64219a4b88c3130e45e5a14e1b3e

図11.89 ホスト OS 側でマウント済みの USB メモリを扱うためのコンテナ作成例

ホスト OS 側の /mnt ディレクトリをコンテナ内の /mnt にマウントしています。これにより、コンテナ内からも /mnt ディレクトリを通して USB メモリを扱うことができます。

[armadillo ~]# podman exec -it usbmem_example sh
[container ~]# ls /mnt
sample.txt
[container ~]# cat /mnt/sample.txt
test

図11.90 USB メモリに保存されているデータの確認例

USB メモリをコンテナ内からマウントする

USB メモリをコンテナ内からマウントして扱う場合には、Podman のイメージからコンテナを作成する際にホスト OS 側の /dev ディレクトリを渡すと同時に、適切な権限も渡す必要があります。以下は、 /dev を渡して alpine イメージからコンテナを作成する例です。権限として SYS_ADMIN を渡しています。

[armadillo ~]# vi /etc/atmark/containers/usbmem_example.conf
set_image docker.io/alpine
set_command sleep infinity
add_args --cap-add=SYS_ADMIN
add_devices /dev/sda1
[armadillo ~]# podman_start usbmem_example
Starting 'usbmem_example'
387a2256530e9b35b5361ca681a99fba8f46d78b6a6cb8ecd60096246b9198a8

図11.91 USB メモリをマウントするためのコンテナ作成例

コンテナ内に入り、mount コマンドで USB メモリを /mnt にマウントし、保存されているデータを確認することができます。

[armadillo ~]# podman exec -it usbmem_example sh
[container ~]# mount /dev/sda1 /mnt
[container ~]# ls /mnt
sample.txt
[container ~]# cat /mnt/sample.txt
test

図11.92 コンテナ内から USB メモリをマウントする例

11.5.4.5. RTC を扱う

コンテナ内から RTC を扱うためには、Podman のイメージからコンテナを作成する際にホスト OS 側のデバイスファイル /dev/rtcN を渡すと同時に、RTC への時刻の設定を行うための権限も渡す必要があります。以下は、/dev/rtc0 を渡して alpine イメージからコンテナを作成する例です。権限として SYS_TIME も渡しています。

[armadillo ~]# vi /etc/atmark/containers/rtc_example.conf
set_image docker.io/alpine
set_command sleep infinity
add_args --cap-add=SYS_TIME
add_devices /dev/rtc0
[armadillo ~]# podman_start rtc_example
Starting 'rtc_example'
025209e0d96f43c2911239a8397b7002c3eaab057e031d8abb765df5707d75bd

図11.93 RTC を扱うためのコンテナ作成例

コンテナ内に入り、hwclock コマンドで RTC の時刻表示と設定ができます。

[armadillo ~]# podman exec -it rtc_example sh
[container ~]# hwclock 
Thu Feb 18 05:14:37 2021  0.000000 seconds
[container ~]# date --set "2021-04-01 09:00:00" 
Thu Apr  1 09:00:00 UTC 2021
[container ~]# hwclock --systohc 
[container ~]# hwclock 
Thu Apr  1 09:00:28 2021  0.000000 seconds

図11.94 hwclock コマンドによるRTCの時刻表示と設定例

	RTC に設定されている現在時刻を表示します。
	システム時刻を 2021 年 4 月 1 日 9 時 0 分 0 秒に設定します。
	システム時刻を RTC に反映させます。
	RTC に設定されている時刻が変更されていることを確認します。

11.5.4.6. 音声出力を行う

Armadillo-IoT ゲートウェイ A6E に接続したスピーカーなどの音声出力デバイスへコンテナ内から音声を出力するためには、 Podman のイメージからコンテナを作成する際にホスト OS 側のデバイスファイル /dev/snd を渡す必要があります。以下は、/dev/snd を渡して debian イメージからコンテナを作成する例です。

[armadillo ~]# vi /etc/atmark/containers/snd_example.conf
set_image localhost/at-debian-image-armv7
set_command sleep infinity
add_devices /dev/snd
[armadillo ~]# podman_start snd_example
Starting 'snd_example'
b921856b504e9f0a3de2532485d7bd9adb1ff63c2e10bfdaccd1153fd36a3c1d

図11.95 音声出力を行うためのコンテナ作成例

コンテナ内に入り、alsa-utils などのソフトウェアで音声出力を行えます。

[armadillo ~]# podman exec -it snd_example /bin/bash
[container ~]# apt update && apt upgrade
[container ~]# apt install alsa-utils 
[container ~]# /etc/init.d/alsa-utils start 
[container ~]# aplay -D hw:N,M [ファイル名]

図11.96 alsa-utils による音声出力を行う例

	alsa-utils をインストールします。
	alsa-utils を起動します。
	指定したファイル名の音声ファイルを再生します。

aplay の引数にある、M は音声を出力したい CARD 番号、N はデバイス番号を表しています。 CARD 番号とデバイス番号は、aplay コマンドに -l オプションを与えることで確認できます。

11.5.4.7. ユーザースイッチのイベントを取得する

Armadillo-IoT ゲートウェイ A6E にはユーザースイッチが実装されています。これらのスイッチのプッシュ/リリースイベントを取得するためには、 Podman のイメージからコンテナを作成する際にホスト OS 側の /dev/input ディレクトリを渡す必要があります。以下は、/dev/input を渡して alpine イメージからコンテナを作成する例です。ここで渡された /dev/input ディレクトリはコンテナ内の /dev/input にマウントされます。

[armadillo ~]# vi /etc/atmark/containers/sw_example.conf
set_image docker.io/alpine
set_command sleep infinity
add_devices /dev/input
[armadillo ~]# podman_start sw_example
Starting 'sw_example'
c0cd8b801883266197a3c20552b0e8b6c7dd473bb0b24e05bf3ecdb581c822b9

図11.97 ユーザースイッチのイベントを取得するためのコンテナ作成例

コンテナ内に入り、evtest コマンドでイベントを確認できます。

[armadillo ~]# podman exec -it sw_example sh
[container ~]# apk upgrade
[container ~]# apk add evtest
[container ~]# evtest /dev/input/event1
Input driver version is 1.0.1
Input device ID: bus 0x19 vendor 0x1 product 0x1 version 0x100
Input device name: "gpio-keys"
Supported events:
  Event type 0 (EV_SYN)
  Event type 1 (EV_KEY)
    Event code 28 (KEY_ENTER)
Properties:
Testing ... (interrupt to exit)
Event: time 1612849227.554456, type 1 (EV_KEY), code 28 (KEY_ENTER), value 1  
Event: time 1612849227.554456, -------------- SYN_REPORT ------------
Event: time 1612849229.894444, type 1 (EV_KEY), code 28 (KEY_ENTER), value 0  
Event: time 1612849229.894444, -------------- SYN_REPORT ------------

図11.98 evtest コマンドによる確認例

	SW1のボタンプッシュイベントを検出したときの表示
	SW1のボタンリリースイベントを検出したときの表示

11.5.4.8. LED を扱う

Armadillo-IoT ゲートウェイ A6E には LED が実装されています。これらの LED を扱うためには、 Podman のイメージからコンテナを作成する際にホスト OS 側の /sys ディレクトリを渡す必要があります。以下は、/sys を渡して alpine イメージからコンテナを作成する例です。ここで渡された /sys ディレクトリはコンテナ内の /sys にマウントされます。

[armadillo ~]# vi /etc/atmark/containers/led_example.conf
set_image docker.io/alpine
set_command sleep infinity
add_volumes /sys
[armadillo ~]# podman_start led_example
Starting 'led_example'
c770f76d7714f4cceb1229be2240382bded236c2c51bb6b866bc0098c2cb987a

図11.99 LED を扱うためのコンテナ作成例

コンテナ内に入り、brightness ファイルに値を書き込むことで LED の点灯/消灯を行うことができます。 0 を書き込むと消灯、0 以外の値 (1〜255) を書き込むと点灯します。

[armadillo ~]# podman exec -it led_example sh
[container ~]# echo 0 > /sys/class/leds/app/brightness
[container ~]# echo 1 > /sys/class/leds/app/brightness

図11.100 LED の点灯/消灯の実行例

11.5.5. 近距離通信を行う

この章では、コンテナ内から近距離通信デバイスを扱う方法について示します。

11.5.5.1. Bluetooth を扱う

コンテナ内から Bluetooth を扱うには、コンテナ作成時にホストネットワークを使用するために、 NET_ADMIN の権限を渡す必要があります。図11.101「Bluetooth を扱うコンテナの作成例」に、alpine イメージから Bluetooth を扱うコンテナを作成する例を示します。

[armadillo ~]# vi /etc/atmark/containers/bt_example.conf
set_image docker.io/alpine
set_command sleep infinity
set_network host
add_args --cap-add=NET_ADMIN
[armadillo ~]# podman_start bt_example
Starting 'bt_example'
45fe1eb6b25529f0c84cd4b97ca1aef8451785fc9a87a67d54873c1ed45b70a4

図11.101 Bluetooth を扱うコンテナの作成例

コンテナ内で必要なソフトウェアをインストールして、Bluetooth を起動します。

[armadillo ~]# podman exec -it bt_example sh
[container ~]# apk upgrade
[container ~]# apk add bluez
[container ~]# dbus-daemon --system
[container ~]# /usr/lib/bluetooth/bluetoothd &

図11.102 Bluetooth を起動する実行例

これにより、bluetoothctl で Bluetooth 機器のスキャンやペアリングなどが行えるようになります。以下に、bluetoothctl コマンドで周辺機器をスキャンしてペアリングを行う例を示します。

[container ~]# bluetoothctl
Agent registerd
[..CHG..] Controller XX:XX:XX:XX:XX:XX Pairable: yes
[bluetooth]# power on 
Changing power on succeeded
[..CHG..] Controller XX:XX:XX:XX:XX:XX Powered: yes
[bluetooth]# scan on 
Discovery started
[..CHG..] Controller XX:XX:XX:XX:XX:XX Discovering: yes
[..NEW..] Device AA:AA:AA:AA:AA:AA AA-AA-AA-AA-AA-AA
[..NEW..] Device BB:BB:BB:BB:BB:BB BB-BB-BB-BB-BB-BB
[..NEW..] Device CC:CC:CC:CC:CC:CC CC-CC-CC-CC-CC-CC
[..NEW..] Device DD:DD:DD:DD:DD:DD DD-DD-DD-DD-DD-DD
[..NEW..] Device EE:EE:EE:EE:EE:EE EE-EE-EE-EE-EE-EE
[bluetooth]# pair AA:AA:AA:AA:AA:AA 
[bluetooth]# exit 
[container ~]#

図11.103 bluetoothctl コマンドによるスキャンとペアリングの例

	コントローラを起動します。
	周辺機器をスキャンします。
	ペアリングしたい機器の MAC アドレスを指定してペアリングします。
	exit で bluetoothctl のプロンプトを終了します。

11.5.5.2. Wi-SUN デバイスを扱う

ここでは、Wi-SUN デバイスが UART で接続されている場合の例を示します。この場合、コンテナ内で動作するアプリケーションから Wi-SUN デバイスで通信を行うためには、 Podman のイメージからコンテナを作成する際にホスト OS 側のデバイスファイル /dev/ttymxcN のうち、 Wi-SUN と対応するものを渡す必要があります。以下は、/dev/ttymxc0 を渡して alpine イメージからコンテナを作成する例です。

[armadillo ~]# vi /etc/atmark/containers/wisun_example.conf
set_image docker.io/alpine
set_command sleep infinity
add_devices /dev/ttymxc0
[armadillo ~]# podman_start wisun_example
Starting 'wisun_example'
ef9a5a2f7eee4236cb28c1fbf5090a6f0db9d6dfe7f3a34573867e0833dd3122
[armadillo ~]# podman exec -it wisun_example sh
[container ~]# ls /dev/ttymxc0
/dev/ttymxc0

図11.104 Wi-SUN デバイスを扱うためのコンテナ作成例

コンテナ内から、/dev/ttymxc0 を使って Wi-SUN データの送受信ができるようになります。

11.5.5.3. EnOcean デバイスを扱う

ここでは、EnOcean デバイスが UART で接続されている場合の例を示します。この場合、コンテナ内で動作するアプリケーションから EnOcean デバイスで通信を行うためには、 Podman のイメージからコンテナを作成する際にホスト OS 側のデバイスファイル /dev/ttymxcN のうち、 EnOcean と対応するものを渡す必要があります。以下は、/dev/ttymxc0 を渡して alpine イメージからコンテナを作成する例です。

[armadillo ~]# vi /etc/atmark/containers/enocean_example.conf
set_image docker.io/alpine
set_command sleep infinity
add_devices /dev/ttymxc0
[armadillo ~]# podman_start enocean_example
Starting 'enocean_example'
a808b491a100f9078d8c72a7b36966d9182614f3657fe054fb8d7f87b0d4b31c
[armadillo ~]# podman exec -it enocean_example sh
[container ~]# ls /dev/ttymxc0
/dev/ttymxc0

図11.105 EnOcean デバイスを扱うためのコンテナ作成例

コンテナ内から、/dev/ttymxc0 を使って EnOcean データの送受信ができるようになります。

11.5.6. ネットワークを扱う

この章では、コンテナ内のネットワークを扱う方法について示します。

11.5.6.1. コンテナの IP アドレスを確認する

基本的にコンテナの IP アドレスは Podman イメージからコンテナを作成したときに自動的に割り振られます。コンテナに割り振られている IP アドレスはホスト OS 側からは podman inspect コマンドを用いて、以下のように確認することができます。

[armadillo ~]# vi /etc/atmark/containers/net_example.conf
set_image docker.io/alpine
set_command sleep infinity
[armadillo ~]# podman_start net_example
Starting 'net_example'
48ae479af65445674323567c17c5418dd4624292351e061bd2bd8a0add4cf150
[armadillo ~]# podman inspect --format '{{ .NetworkSettings.IPAddress }}' net_example
10.88.0.17

図11.106 コンテナの IP アドレス確認例

コンテナ内の ip コマンドを用いて確認することもできます。

[armadillo ~]# podman exec net_example ip addr show eth0
3: eth0@if8: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet 10.88.0.17/16 brd 10.88.255.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::40e5:98ff:feec:4b17/64 scope link
       valid_lft forever preferred_lft forever

図11.107 ip コマンドを用いたコンテナの IP アドレス確認例

11.5.6.2. コンテナに固定 IP アドレスを設定する

podman はデフォルトで 10.88.0.0/16 を使います。

他に使用しているIPアドレスと被った場合等はコンテナに別のIPアドレスを設定してください。

コンテナに固定 IP アドレスを設定するためには、最初にユーザ定義のネットワークを作成する必要があります。以下に 192.0.2.0/24 にユーザ定義のネットワークを作成する例を示します。

[armadillo ~]# vi /etc/atmark/containers/my_network.conf
set_type network
set_subnet 192.0.2.0/24
[armadillo ~]# podman_start my_network
Creating network 'my_network'
my_network

図11.108 ユーザ定義のネットワーク作成例

コンテナを作成する際に、上記で作成したネットワークと設定したい IP アドレスを渡すことで、コンテナの IP アドレスを固定することができます。以下の例では、IPアドレスを 192.0.2.10 に固定します。

[armadillo ~]# vi /etc/atmark/containers/network_example.conf
set_image docker.io/alpine
set_command sleep infinity
set_network my_network
set_ip 192.0.2.10
[armadillo ~]# podman_start network_example
Starting 'network_example'
3ea8c9031bf833228908bd73d8929b1d543b189b436c218e0634e0d39409e100

図11.109 IP アドレス固定のコンテナ作成例

コンテナの IP アドレスが、192.0.2.10 に設定されていることが確認できます。

[armadillo ~]# podman inspect --format '{{ .NetworkSettings.Networks.my_network.IPAddress }}' network_example
192.0.2.10

図11.110 コンテナの IP アドレス確認例

11.5.7. サーバを構築する

この章では、コンテナ内で様々なサーバを構築する方法について示します。この章で取り上げているサーバは alpine の apk コマンドでインストールすることが可能です。

11.5.7.1. HTTP サーバを構築する

ここでは、HTTP サーバとして Apache と lighttpd の 2 種類を使用する場合について説明します。

Apache を使用する

alpine イメージからコンテナを作成し、そのコンテナ内に Apache をインストールします。コンテナ作成の際に、ホスト OS の 8080 番ポートをコンテナ内の 80 番ポートに転送する指定を行っています。

[armadillo ~]# vi /etc/atmark/containers/apache_example.conf
set_image docker.io/alpine
set_command sleep infinity
add_ports 8080:80
[armadillo ~]# podman_start apache_example
Starting 'apache_example'
ea0a1ed9c2fe170a6db02e480300467510f4e844900efb35c7a24cc1a8653af2
[armadillo ~]# podman exec -it apache_example sh
[container ~]# apk upgrade && apk add apache2
[container ~]# httpd
AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 10.88.0.2. Set the 'ServerName' directive globally to suppress this message

図11.111 コンテナに Apache をインストールする例

他の PC などの Web ブラウザから、ホスト OS の IP アドレスの 8080 番ポートに接続すると、動作確認用ページが表示されます。デフォルトでは、/var/www/localhost/htdocs ディレクトリにファイルを置くことで Web ブラウザから閲覧できます。 Apache の詳細な設定は、/etc/apache2 ディレクトリにある設定ファイルを編集することで変更可能です。

lighttpd を使用する

alpine イメージからコンテナを作成し、そのコンテナ内に lighttpd をインストールします。コンテナ作成の際に、ホスト OS の 8080 番ポートをコンテナ内の 80 番ポートに転送する指定を行っています。

[armadillo ~]# vi /etc/atmark/containers/lighttpd_example.conf
set_image docker.io/alpine
set_command sleep infinity
add_ports 8080:80
[armadillo ~]# podman_start lighttpd_example
Starting 'lighttpd_example'
fd7ea338d09c5e8962654ed54bba17fb6a9ed4fca1b344e350bbf8f943d2f12b
[armadillo ~]# podman exec -it lighttpd_example sh
[container ~]# apk upgrade && apk add lighttpd
[container ~]# echo "<html><body>It works!</body></html>" > /var/www/localhost/htdocs/index.html
[container ~]# lighttpd -f /etc/lighttpd/lighttpd.conf

図11.112 コンテナに lighttpd をインストールする例

lighttpd はデフォルトでは動作確認用ページが用意されていないため、上記の手順では簡単なページを /var/www/localhost/htdocs ディレクトリの下に配置しています。他の PC などの Web ブラウザから、ホスト OS の IP アドレスの 8080 番ポートに接続すると表示されます。 lighttpd の詳細な設定は、/etc/lighttpd ディレクトリにある設定ファイルを編集することで変更可能です。

11.5.7.2. FTP サーバを構築する

ここでは、FTP サーバとして vsftp を使用する場合について説明します。 alpine イメージからコンテナを作成し、そのコンテナ内に vsftpd をインストールします。コンテナ作成の際に、FTP 通信で使用するポートについてホスト OS 側からコンテナ内のポートに転送する指定と、コンテナ内の環境変数として PASV_ADDRESS にホスト OS 側の IP アドレスの指定を行っています。

[armadillo ~]# vi /etc/atmark/containers/ftp_example.conf
set_image docker.io/alpine
set_command sleep infinity
add_ports 21:21 21100-21110:21100-21110
add_args --env=PASV_ADDRESS=<ホストの IP アドレス>
[armadillo ~]# podman_start ftp_example
Starting 'ftp_example'
efcf1ba752c2db9ae1a33ac11af3be71d95ac7b737ce9734730ebca602e57796
[armadillo ~]# podman exec -it ftp_example sh
[container ~]# apk upgrade && apk add vsftpd

図11.113 コンテナに vsftpd をインストールする例

コンテナ内にユーザアカウントを作成し、このユーザで ftp ログインできるようにします。

[container ~]# adduser atmark
Changing password for atmark
New password: （パスワードを入力）
Retype password: （パスワードを入力）
passwd: password for atmark changed by root

図11.114 ユーザを追加する例

作成したユーザで ftp ログインできるように、vsftpd の設定ファイルを編集します。

[container ~]# sed -i -e 's/anonymous_enable=YES/#anonymous_enable=YES/g' /etc/vsftpd/vsftpd.conf
[container ~]# sed -i -e 's/#local_enable=YES/local_enable=YES/g' /etc/vsftpd/vsftpd.conf
[container ~]# sed -i -e 's/#write_enable=YES/write_enable=YES/g' /etc/vsftpd/vsftpd.conf
[container ~]# echo "pasv_enable=YES" >> /etc/vsftpd/vsftpd.conf
[container ~]# echo "pasv_min_port=21100" >> /etc/vsftpd/vsftpd.conf
[container ~]# echo "pasv_max_port=21110" >> /etc/vsftpd/vsftpd.conf
[container ~]# echo "pasv_address=$PASV_ADDRESS" >> /etc/vsftpd/vsftpd.conf

図11.115 設定ファイルの編集例

編集した設定ファイルを指定して vftpd を起動することにより、ftp 接続可能となります。 ftp ログイン時のアカウントは前述の手順で作成したものを使用します。

[container ~]# vsftpd /etc/vsftpd/vsftpd.conf

図11.116 vsftpd の起動例

11.5.7.3. Samba サーバを構築する

ここでは、Samba サーバの構築方法について説明します。 alpine イメージからコンテナを作成し、そのコンテナ内に samba をインストールします。コンテナ作成の際に、samba で使用するポートについてホスト OS 側からコンテナ内のポートに転送する指定を行っています。

[armadillo ~]# vi /etc/atmark/containers/smb_example.conf
set_image docker.io/alpine
set_command sleep infinity
add_ports 139:139 445:445
[armadillo ~]# podman_start smb_example
Starting 'smb_example'
6d81c01fe27b5a92ee6ea69de2f9a8dbb569d420c2f5f630ece1966c81824a1f
[armadillo ~]# podman exec -it smb_example sh
[container ~]# apk upgrade && apk add samba

図11.117 コンテナに samba をインストールする例

コンテナ内にユーザアカウントを作成し、このユーザで samba にログインできるようにします。

[container ~]# adduser atmark
Changing password for atmark
New password: （パスワードを入力）
Retype password: （パスワードを入力）
passwd: password for atmark changed by root
[container ~]# pdbedit -a atmark
new password: （パスワードを入力）
retype new password: （パスワードを入力）

図11.118 ユーザを追加する例

samba を起動すると、前述の手順で作成したユーザアカウントで他の PC などからログインすることができます。

[container ~]# smbd

図11.119 samba の起動例

共有するディレクトリの指定などの詳細設定は /etc/samba/smb.conf ファイルを編集することで変更可能です。

11.5.7.4. SQL サーバを構築する

ここでは、RDMS として sqlite を使用する場合について説明します。 alpine イメージからコンテナを作成し、そのコンテナ内に sqlite をインストールします。

[armadillo ~]# vi /etc/atmark/containers/sqlite_example.conf
set_image docker.io/alpine
set_command sleep infinity
add_volumes /var/app/volumes/sqlite_db:/db
[armadillo ~]# podman_start sqlite_example
Starting 'sqlite_example'
114c5f1dbb7e81293dcb8fbe0c600b861626375b14cfe4023761acaa84fdcad1
[armadillo ~]# podman exec -it sqlite_example sh
[container ~]# apk upgrade && apk add sqlite

図11.120 コンテナに sqlite をインストールする例

コンテナ内に入り、sqlite3 コマンドを実行すると sqlite のプロンプトが表示されデータベースの操作ができるようになります。

[container ~]# sqlite3 /db/mydb.sqlite
SQLite version 3.34.1 2021-01-20 14:10:07
Enter ".help" for usage hints.
sqlite>

図11.121 sqlite の実行例

11.5.8. 異常検知

この章では、コンテナ内で動作しているアプリケーションに何らかの異常が発生し停止してしまった際に、ソフトウェアウォッチドックタイマーを使って、システムを再起動する方法について示します。

11.5.8.1. ソフトウェアウォッチドッグタイマーを扱う

コンテナ内で動作するアプリケーションからソフトウェアウォッチドックタイマーを扱うためには、Podman のイメージからコンテナを作成する際にホスト OS 側のデバイスファイル /dev/watchdogN を渡す必要があります。以下は、/dev/watchdog0 を渡して alpine イメージからコンテナを作成する例です。

[armadillo ~]# vi /etc/atmark/containers/watchdog_example.conf
set_image docker.io/alpine
set_command sleep infinity
add_devices /dev/watchdog0
[armadillo ~]# podman_start watchdog_example
Starting 'watchdog_example'
a5d329cca49d60423ce4155d72a119b8049a03dbd1d0277817a253e96dce7bc7

図11.122 ソフトフェアウォッチドッグタイマーを使うためのコンテナ作成例

ソフトウェアウォッチドックタイマーは、プログラム内からデバイスファイル /dev/watchdog0 を open した時点で起動します。コンテナ内に入ってソフトウェアウォッチドックタイマーを echo コマンドで起動する例を以下に示します。

[armadillo ~]# podman exec -it watchdog_example sh
[container ~]# echo > /dev/watchdog0

図11.123 コンテナ内からソフトウェアウォッチドッグタイマーを起動する実行例

ソフトウェアウォッチドックタイマーを起動した後、/dev/watchdog0 に任意の文字を書き込むことでソフトウェアウォッチドッグタイマーをリセットすることができます。 60 秒間任意の文字の書き込みがない場合は、システムが再起動します。

[armadillo ~]# podman exec -it watchdog_example sh
[container ~]# echo a > /dev/watchdog0

図11.124 ソフトウェアウォッチドッグタイマーをリセットする実行例

ソフトウェアウォッチドックタイマーを停止したい場合は、/dev/watchdog0 に V を書き込みます。

[armadillo ~]# podman exec -it watchdog_example sh
[container ~]# echo V > /dev/watchdog0

図11.125 ソフトウェアウォッチドッグタイマーを停止する実行例

11.6. コンテナの運用

11.6.1. コンテナの自動起動

Armadillo Base OSでは、/etc/atmark/containers/*.confファイルに指定されているコンテナがブート時に自動的に起動します。 nginx.confの記載例を以下に示します。

[armadillo ~]# cat /etc/atmark/containers/nginx.conf
set_image docker.io/library/nginx:alpine
set_readonly no
add_ports 80:80

図11.126 コンテナを自動起動するための設定例

.conf ファイルは以下のパラメータを設定できます。

コンテナイメージの選択： set_image [イメージ名]
イメージの名前を設定できます。
例: set_image docker.io/debian:latest, set_image localhost/myimage
イメージをrootfsとして扱う場合に --rootfs オプションで指定できます。
例: set_image --rootfs /var/app/volumes/debian
ポート転送： add_ports [ホストポート]:[コンテナポート]
設定したポートで外部からコンテナへのアクセスが可能となります。
デフォルトはTCPで、UDPも /udp を付けて使えます。スペースで分けて複数のポートを設定することができます。
以下の例では、ポート80、443(web)、UDPの69(tftp)にアクセスすることができ、コンテナのポート22(ssh)にはポート2222からアクセスすることができます。
例: add_ports 80:80 443:443 2222:22 69:69/udp
pod を使う場合、このオプションはpodの設定にしないと有効になりませんのでご注意ください。
デバイスファイル作成： add_devices [ホストパス]:[コンテナパス]
コンテナでデバイスを作成して、使用可能となります。
コンテナパスを設定しない場合はホストと同じパスを使います。
複数のデバイスを作成したい場合はスペースで分けて設定してください。
例: add_devices /dev/galcore /dev/v4l/by-id/usb-046d_HD_Pro_Webcam_C920_78DA8CAF-video-index0:/dev/video3
ホストパスに「:」を含む場合は add_device "[ホストパス]" "[コンテナパス]" で追加できます。
例: add_device "/dev/v4l/by-path/XXXXX" "/dev/video3"
コンテナパスに「:」を含むようなパスは設定できません。

ボリュームマウント： add_volumes [ホストパス]:[コンテナパス]:[オプション]

指定するパスをコンテナ内でマウントして、データの保存や共有することができます。

ホストパスは以下のどちらかを指定してください。

/var/app/rollback/volumes/<folder> か <folder>:
アップデートの際に新しくコピー（snapshot）した場合、コピー先のみ変更しますので、アップデート中でもこのデータを使うことができます。途中で電源が落ちた場合でも、このデータに影響はありません。
SWUpdateでアップデートするデータに向いています。
/var/app/volumes/<folder>: appパーティションに書きます。
アップデートの際にコピーされませんので、アップデート中の新たな変更は更新されたコンテナ内のアプリケーションで見れます。
ログやデータベースに向いています。
/tmp/<folder>: 複数のコンテナでメモリファイルシステムを共有したい場合に使ってください。
/opt/firmware: コンテナ内のアプリケーションを動作させるために必要なファームウェアライブラリーのパス。

コンテナパスを設定しない場合はホストパスと同じパスを使います。

オプションは podman run の --volume のオプションになりますので、 ro (read-only), nodev, nosuid, noexec, shared, slave 等を設定できます。

例：add_volumes /var/app/volumes/database:/database: ロールバックされないデータを/databaseで保存します。

例: add_volumes assets:/assets:ro,nodev,nosuid /opt/firmware: アプリケーションのデータを/assetsで読み取り、/opt/firmwareのファームウェアを使えます。

「:」はホスト側のパスとコンテナのパスを別ける意味があるため、ファイル名やデバイス名に「:」を使うことはできません。

複数のコンテナでマウントコマンドを実行することがあれば、shared のフラグで起動後のマウントを共有することができます。

[armadillo ~]# cat /etc/atmark/containers/mounter.conf
set_image docker.io/alpine
add_args -ti
add_volumes /tmp/mnt:/mnt:shared 
add_args --cap-add SYS_ADMIN
add_device /dev/sda1
[armadillo ~]# cat /etc/atmark/containers/client.conf
set_image docker.io/alpine
add_volumes /tmp/mnt:/mnt:slave 
add_args -ti
[armadillo ~]# podman exec mounter mount /dev/sda1 /mnt 
[armadillo ~]# podman exec client ls /mnt 
file_on_usb

図11.127 ボリュームを shared でサブマウントを共有する例

	マウントを行うコンテナに `shared` の設定とマウント権限 (`SYS_ADMIN`) を与えます。
	マウントを使うコンテナに `slave` だけを設定すれば一方にしか共有されません。
	USB デバイスをマウントします。
	マウントされたことを確認します。

ホットプラグデバイスの追加： add_hotplugs [デバイスタイプ]

コンテナ起動後に挿抜を行なっても認識される(ホットプラグ)デバイスを設定できます。

通常、コンテナ内からデバイスを扱うためには、あらかじめ Armadillo 本体に当該のデバイスを接続した状態で、コンテナを起動する必要がありますが、 add_hotplugs を使用することでホットプラグに対応できます。

例: add_hotplugs input

add_hotplugs に指定できる主要な文字列とデバイスファイルの対応について、表11.24「add_hotplugsオプションに指定できる主要な文字列」に示します。

表11.24 add_hotplugsオプションに指定できる主要な文字列

文字列	引数の説明	対象のデバイスファイル
input	マウスやキーボードなどの入力デバイス	/dev/input/mouse0, /dev/input/event0 など
video4linux	USB カメラなどの video4linux デバイスファイル	/dev/video0 など
sd	USB メモリなどの SCSI ディスクデバイスファイル	/dev/sda1 など

表11.24「add_hotplugsオプションに指定できる主要な文字列」に示した文字列の他にも、/proc/devicesの数字から始まる行に記載されている文字列を指定することができます。図11.128「/proc/devicesの内容例」に示す状態の場合、デバイスタイプを示す文字列としては、各行の先頭の数字を除いた mem や pty などを指定できることがわかります。

[armadillo ~]# cat /proc/devices
Character devices:
  1 mem
  2 pty
  3 ttyp
  4 /dev/vc/0
  4 tty
  4 ttyS
  5 /dev/tty
  5 /dev/console
  5 /dev/ptmx
  7 vcs
 10 misc
 13 input
 29 fb
 81 video4linux
: (省略)

図11.128 /proc/devicesの内容例

デバイスタイプと実際のデバイスファイルの対応については、カーネルドキュメント: devices.txt(Github) を参照してください。

複数のデバイスタイプを指定したい場合はスペースで分けて設定してください。

例: add_hotplugs input video4linux sd

pod の選択： set_pod [ポッド名]
「podの作成」で作成した pod の名前を入れてコンテナを pod 内で起動します。
例: set_pod mypod
ネットワークの選択： set_network [ネットワーク名]
この設定に「networkの作成」で作成したネットワーク以外に none と host の特殊な設定も選べます。
none の場合、コンテナに localhost しかないネームスペースに入ります。
host の場合はOSのネームスペースをそのまま使います。
例: set_network mynetwork
IP アドレスの設定： set_ip [アドレス]
コンテナの IP アドレスを設定することができます。
例: set_ip 10.88.0.100
コンテナ間の接続が目的であれば、podを使ってlocalhostかpodの名前でアクセスすることができます。
読み取り専用設定： set_readonly yes
コンテナ内からのファイルシステムへの書き込み許可を設定します。
デフォルトで書き込み可能となっています。
コンテナ内からのファイルシステムへの書き込みを禁止することで、 tmpfs として使うメモリの消費を明示的に抑えることができますが、アプリケーションによっては読み込み専用のファイルシステムでは動作しない可能性もあります。
イメージの自動ダウンロード設定： set_pull [設定]
この設定を missing にすると、イメージが見つからない場合にイメージを自動的にダウンロードします。
always にすると、イメージがすでにダウンロード済みでも起動前に必ず更新の確認を取ります。
デフォルトでは never で、イメージが見つからない場合にエラーを表示します。
例：set_pull missing か set_pull always
コンテナのリスタート設定： set_restart [設定]
コンテナが停止した時にリスタートさせます。
podman kill か podman stop で停止する場合、この設定と関係なくリスタートしません。
デフォルトで on-failure になっています。
例: set_restart always か set_restart no
自動起動の無効化： set_autostart no
手動かまたは別の手段で操作するコンテナがある場合、Armadillo の起動時に自動起動しないようにします。
その場合、 podman_start <name> で起動させることができます。
コンフィグに記載していないイメージはアップデートの際に削除されますので、そういったイメージに対して設定してください。
実行コマンドの設定： set_command [コマンド]
コンテナを起動するときのコマンド。設定されなかった場合、コンテナイメージのデフォルトを使います。
例: set_command /bin/sh -c "echo bad example"
podman run に引数を渡す設定： add_args [引数]
ここまでで説明した設定項目以外の設定を行いたい場合は、この設定で podman run に直接引数を渡すことができます。
例：add_args --cap-add=SYS_TTY_CONFIG --env=XDG_RUNTIME_DIR=/run/xdg_home

11.6.2. podの作成

podman_start で pod 機能を使うことができます。

pod を使うことで、複数のコンテナが同じネットワークネームスペースを共有することができます。同じ pod の中のコンテナが IP の場合 localhost で、 unix socket の場合 abstract path で相互に接続することができます。

[armadillo ~]# cat /etc/atmark/containers/mypod.conf
set_type pod
add_ports 80:80
set_infra_imager k8s.gcr.io/pause:3.5

[armadillo ~]# cat /etc/atmark/containers/nginx.conf
set_image docker.io/library/nginx:alpine
set_readonly no
set_pod mypod

[armadillo ~]# podman ps
CONTAINER ID  IMAGE                           COMMAND               CREATED      STATUS          PORTS               NAMES
0cdb0597b610  k8s.gcr.io/pause:3.5                                  2 hours ago  Up 2 hours ago  0.0.0.0:80->80/tcp  5ba7d996f673-infra
3292e5e714a2  docker.io/library/nginx:alpine  nginx -g daemon o...  2 hours ago  Up 2 hours ago  0.0.0.0:80->80/tcp  nginx

図11.129 podを使うコンテナを自動起動するための設定例

コンテナと同じく、 /etc/atmark/containers/[NAME].conf ファイルを作って、 set_type pod を設定することで pod を作成します。

pod を使う時にコンテナの設定ファイルに set_pod [NAME] の設定を追加します。

ネットワークネームスペースは pod を作成するときに必要なため、 ports, network と ip の設定は pod のコンフィグファイルに入れなければなりません。

ネットワーク設定の他に、 infra_image のオプションで pod のイメージも固める事ができます。この設定は set_type network の後しか使えませんので、set_type はファイルの最初のところに使ってください

必要であれば、他の podman pod create のオプションを add_args で設定することができます。

pod を使う時に podman が特殊な「infra container」も起動します（例の場合、 k8s.gcr.io/pause:3.5 を起動させました）

コンフィグレーションに pod を入れるアップデートの際に自動的に podman pull でイメージをダウンロードしますが、インターネットを使わせたくないアップデートがあれば swdesc_embed_container か swdesc_usb_container で入れてください。その場合、 infra_image の設定も使ってください。

11.6.3. networkの作成

podman_start で podman の network も作成ことができます。

デフォルトの 10.88.0.0/16 が使えない場合、あるいはコンテナ同士で接続できないようにしたい場合は使ってください。

[armadillo ~]# cat /etc/atmark/containers/mynetwork.conf
set_type network
set_subnet 192.0.2.0/24

[armadillo ~]# cat /etc/atmark/containers/nginx.conf
set_image docker.io/library/nginx:alpine
add_ports 80:80
set_ip 192.0.2.10
set_network mynetwork

[armadillo ~]# podman ps
CONTAINER ID  IMAGE                           COMMAND               CREATED      STATUS          PORTS               NAMES
3292e5e714a2  docker.io/library/nginx:alpine  nginx -g daemon o...  2 hours ago  Up 2 hours ago  0.0.0.0:80->80/tcp  nginx

図11.130 networkを使うコンテナを自動起動するための設定例

コンテナと同じく、 /etc/atmark/containers/[NAME].conf ファイルを作って、 set_type network を設定することで network を作成します。

そのネットワークを使う時にコンテナの設定ファイルに set_network [NAME] の設定をいれます。

ネットワークのサブネットは set_subnet [SUBNET] で設定します。この設定は set_type network の後しか使えませんので、set_type はファイルの最初のところに使ってください

他の podman network create のオプションが必要であれば、 add_args で設定することができます。

11.6.4. コンテナからのコンテナ管理

podman では REST API による管理アクセスも可能です。

自分のコンテナから他のコンテナの管理が必要な場合に、ホストの podman サービスを有効にして、コンテナに /run/podman をボリュームマウントすれば podman --remote で管理できます。

podman_start をインストールすればそちらも --remote で使えます。

このオプションは Armadillo のホスト側の udev rules からコンテナを扱う時にも必要です。

11.6.5. コンテナの配布


	コンテナの作成は「アプリケーションコンテナを作成、実行する」を参考にしてください。

コンテナのイメージを配布する方法は大きく分けて二つあります：

インターネット上のリポジトリ（dockerhub等）で登録してそこから配布する
SWUpdateのアップデートイメージを配布する

Podmanのイメージをインストールする時に、一時データを大量に保存する必要があります。

swuイメージ内で組み込む時は3倍、pullやUSBドライブで分けてインストールすると転送するデータ量の2倍の空き容量がappパーティションに必要です。

アップデート時にアップデート前のコンテナが使われているのでご注意ください。

11.6.5.1. リモートリポジトリにコンテナを送信する方法

イメージをリモートリポジトリに送信する：

[armadillo ~]# podman image push <localimage> docker://<registry>/<remoteimage>:<tag>

set_pull always を設定しないかぎり、SWUpdateでダウンロードの命令を送らないとアップデートを行いません。

（mkswuについては「Armadilloのソフトウェアをアップデートする」を参考にしてください）

[ATDE ~/mkswu]$ cp /usr/share/mkswu/examples/pull_container_nginx.desc .
[ATDE ~/mkswu]$ cp -r /usr/share/mkswu/examples/nginx_start .
[ATDE ~/mkswu]$ cat pull_container_nginx.desc
swdesc_option version=1

swdesc_pull_container "docker.io/nginx:alpine"
swdesc_files --extra-os nginx_start
[ATDE ~/mkswu]$ mkswu pull_container_nginx.desc
Enter pass phrase for /home/atmark/mkswu/swupdate.key:
pull_container_nginx.swu を作成しました。

11.6.5.2. イメージを eMMC に保存する方法

Armadillo Base OS のデフォルトでは、Podman のデータは tmpfs に保存されます。

起動時にイメージを起動するにはイメージを eMMC に書き込む必要があります。想定の使い方では、以下の「イメージを SWUpdate で転送する方法」でコンテナのイメージを送信する場合には、 /var/lib/containers/storage_readonly の app パーティションのサブボリュームに展開します。

開発の時に、abos-ctrl podman-storage --disk を設定すると別の /var/log/containers/storage が作成されますが、SWUpdate で転送するイメージはそのまま readonly の方に書き込みます。

abos-ctrl podman-rw

abos-ctrl podman-rw を使えば、read-only になっているイメージを扱う事ができます。

[armadillo ~]# podman images
REPOSITORY                 TAG         IMAGE ID      CREATED            SIZE        R/O
[armadillo ~]# mount /dev/sda1 /mnt
[armadillo ~]# abos-ctrl podman-rw load -i /mnt/at-debian-image.tar
Getting image source signatures
Copying blob 63c098a71e7b done
Copying blob 837e73dd4d20 done
Copying blob a25086e65f63 done
Copying config b5a30f8581 done
Writing manifest to image destination
Storing signatures
Loaded image(s): localhost/at-debian-image:latest
[armadillo ~]# podman image list
REPOSITORY                 TAG         IMAGE ID      CREATED      SIZE        R/O
localhost/at-debian-image  latest      b5a30f8581cc  2 hours ago  233 MB      true

図11.131 abos-ctrl podman-rw の実行例

abos-ctrl podman-storage

abos-ctrl podman-storage はメモリとディスクの切り替えの他に、読み書きストレージから読み取り専用ストレージへのコピーもできます。

[armadillo ~]# podman pull docker.io/alpine 
Trying to pull docker.io/library/alpine:latest...
Getting image source signatures
Copying blob f97344484467 done
Copying config 3d81c46cd8 done
Writing manifest to image destination
Storing signatures
3d81c46cd8756ddb6db9ec36fa06a6fb71c287fb265232ba516739dc67a5f07d
[armadillo ~]# abos-ctrl podman-storage 
There are images configured on development storage:
REPOSITORY                TAG         IMAGE ID      CREATED     SIZE
docker.io/library/alpine  latest      3d81c46cd875  3 days ago  5.56 MB

What should we do? ([N]othing (default), [C]opy, [R]emove)
copy 
Create a snapshot of '/mnt/boot_0/containers_storage' in '/mnt/new_storage'
Getting image source signatures
Copying blob 5b7df235d876 done
Copying config 3d81c46cd8 done
Writing manifest to image destination
Storing signatures
Delete subvolume (no-commit): '/mnt/new_storage'
Copying development images to readonly storage succeeded
Feel free to adjust the result with abos-ctrl podman-rw commands

Now freeing up original data...
Podman is in tmpfs mode 
[armadillo ~]# podman image list 
REPOSITORY                TAG         IMAGE ID      CREATED     SIZE        R/O
docker.io/library/alpine  latest      3d81c46cd875  3 days ago  5.56 MB     true

図11.132 abos-ctrl podman-storage のイメージコピー例

	イメージを書き込み可能ストレージに取得します。
	`abos-ctrl podman-storage` をオプション無しで実行します。
	書き込み可能ストレージにイメージがある場合に対応を聞かれます。今回はコピー（copy)します。
	`abos-ctrl podman-storage` にオプションを指定しなかったので、ストレージが tmpfs のままになります。すでに `--disk` で切り替えた場合にディスクのままでも可能です。
	コピーの確認します。イメージが読み取り専用（R/O, Read only）になりました。

SWUpdate でアップデートをインストールする際には、/var/lib/containers/storage_readonly ディレクトリの不要になったイメージを自動的に削除します。

自動起動させる予定がなくても、「コンテナの自動起動」を参考にして、 /etc/atmark/containers/*.conf を使ってください。 set_autostart no を設定することで自動実行されません。

11.6.5.3. イメージを SWUpdate で転送する方法

イメージをファイルに保存する：

[armadillo ~]# podman image save -o <myimage>.tar <localimage>

ファイルをSWUpdateのイメージに入れる。

二つのやり方があります：

swuイメージ内に組み込む

[ATDE ~/mkswu]$ cp /usr/share/mkswu/examples/embed_container_nginx.desc .
[ATDE ~/mkswu]$ cp -r /usr/share/mkswu/examples/nginx_start .
[ATDE ~/mkswu]$ cat embed_container_nginx.desc
swdesc_option version=1

swdesc_embed_container "nginx_alpine.tar"
swdesc_files --extra-os nginx_start
[ATDE ~/mkswu]$ podman pull --arch arm --variant v7 docker.io/nginx:alpine
[ATDE ~/mkswu]$ podman run --rm docker.io/nginx:alpine uname -m
armv7l
[ATDE ~/mkswu]$ podman save docker.io/nginx:alpine > nginx_alpine.tar
[ATDE ~/mkswu]$ mkswu embed_container_nginx.desc
Enter pass phrase for /home/atmark/mkswu/swupdate.key:
embed_container_nginx.swu を作成しました

USBドライブに保存する

[ATDE ~/mkswu]$ cp /usr/share/mkswu/examples/usb_container_nginx.desc .
[ATDE ~/mkswu]$ cp -r /usr/share/mkswu/examples/nginx_start .
[ATDE ~/mkswu]$ cat usb_container_nginx.desc
swdesc_option version=1

swdesc_usb_container "nginx_alpine.tar"
swdesc_files --extra-os nginx_start
[ATDE ~/mkswu]$ podman pull --arch arm --variant v7 docker.io/nginx:alpine
[ATDE ~/mkswu]$ podman run --rm docker.io/nginx:alpine uname -m
armv7l
[ATDE ~/mkswu]$ podman save docker.io/nginx:alpine > nginx_alpine.tar
[ATDE ~/mkswu]$ mkswu -o usb_container_nginx.swu usb_container_nginx.desc
Enter pass phrase for /home/atmark/mkswu/swupdate.key:
以下のファイルをUSBメモリにコピーしてください：
'/home/atmark/mkswu/usb_container_nginx.swu'
'/home/atmark/mkswu/nginx_alpine.tar'
'/home/atmark/mkswu/.usb_container_nginx/nginx_alpine.tar.sig'

usb_container_nginx.swu を作成しました。

11.7. Armadilloのソフトウェアをビルドする

ここでは、Armadillo-IoT ゲートウェイ A6E で使用するソフトウェアのビルド方法を説明します。

11.7.1. ブートローダーをビルドする

ここでは、ATDE 上で Armadillo-IoT ゲートウェイ A6E 向けのブートローダーイメージをビルドする方法を説明します。

ソースコードの取得
Armadillo-IoT ゲートウェイ A6E ブートローダーから「ブートローダーソース」ファイル (u-boot-[VERSION].tar.gz) を図11.133「ブートローダーのソースコードをダウンロードする」に示す手順でダウンロードします。
```
[ATDE ~]$ wget https://download.atmark-techno.com/armadillo-iot-a6e/bootloader/u-boot-[VERSION].tar.gz
[ATDE ~]$ tar xf u-boot-[VERSION].tar.gz
[ATDE ~]$ cd u-boot-[VERSION]
```
図11.133 ブートローダーのソースコードをダウンロードする

デフォルトコンフィギュレーションの適用

図11.134「デフォルトコンフィギュレーションの適用」に示すコマンドを実行します。

[ATDE ~/u-boot-[VERSION]]$ make ARCH=arm armadillo-iotg-a6e_defconfig
  HOSTCC  scripts/basic/fixdep
  HOSTCC  scripts/kconfig/conf.o
  YACC    scripts/kconfig/zconf.tab.c
  LEX     scripts/kconfig/zconf.lex.c
  HOSTCC  scripts/kconfig/zconf.tab.o
  HOSTLD  scripts/kconfig/conf
#
# configuration written to .config
#

図11.134 デフォルトコンフィギュレーションの適用

ビルド

ブートローダーのビルドを実行するには、図11.135「ブートローダーのビルド」に示すコマンドを実行します。

[ATDE ~/u-boot-[VERSION]]$ make CROSS_COMPILE=arm-linux-gnueabihf-
:
: (省略)
:
  SHIPPED dts/dt.dtb
  FDTGREP dts/dt-spl.dtb
  CAT     u-boot-dtb.bin
  CFGS    u-boot-dtb.cfgout
  MKIMAGE u-boot-dtb.imx
  OBJCOPY u-boot.srec
  COPY    u-boot.bin
  SYM     u-boot.sym
  COPY    u-boot.dtb
  CFGCHK  u-boot.cfg

図11.135 ブートローダーのビルド

インストール
ビルドしたブートローダーは、以下に示すどちらかの方法でインストールしてください。
- swupdate でインストールする
  mkswu の初期化を行った後に提供されているスクリプトを使ってSWUイメージを作成してください。
  [ATDE ~/u-boot-[VERSION]]$ echo 'swdesc_boot u-boot-dtb.imx' > boot.desc [ATDE ~/u-boot-[VERSION]]$ mkswu boot.desc boot.swu を作成しました。
  図11.136 ブートローダーを SWU でインストールする方法
  作成された boot.swu のインストールについては「イメージのインストール」を参照ください。
- 「ブートディスクの作成」でインストールする
  手順を参考にして、ビルドされた u-boot-dtb.imx を使ってください。

11.7.2. Linux カーネルをビルドする

ここでは、Armadillo-IoT ゲートウェイ A6E 向けのLinuxカーネルイメージをビルドする方法を説明します。

Armadillo-IoT ゲートウェイ A6Eでは、基本的にはLinuxカーネルイメージをビルドする必要はありません。「Alpine Linux ルートファイルシステムをビルドする」の手順を実施することで、標準のLinuxカーネルイメージがルートファイルシステムに組み込まれます。

標準のLinuxカーネルイメージは、アットマークテクノが提供する linux-at というAlpine Linux用のパッケージに含まれています。

カスタマイズしたLinuxカーネルイメージを利用する場合は、以下に示す手順を参照してください。

ソースコードの取得
Armadillo-IoT ゲートウェイ A6E Linuxカーネルから「Linuxカーネル」ファイル (linux-at-a6-[VERSION].tar) をダウンロードして、図11.137「Linux カーネルソースコードの展開」に示すコマンドを実行して展開します。
```
[ATDE ~]$ tar xf linux-at-a6-[VERSION].tar
[ATDE ~]$ tar xf linux-at-a6-[VERSION]/linux-[VERSION].tar.gz
[ATDE ~]$ cd linux-[VERSION]
```
図11.137 Linux カーネルソースコードの展開
デフォルトコンフィギュレーションの適用
図11.138「Linux カーネルデフォルトコンフィギュレーションの適用」に示すコマンドを実行します。
```
[ATDE ~/linux-[VERSION]]$ make ARCH=arm armadillo-iotg-a6e_defconfig
```
図11.138 Linux カーネルデフォルトコンフィギュレーションの適用

Linux カーネルコンフィギュレーションの変更

コンフィギュレーションの変更を行わない場合はこの手順は不要です。変更する際は、図11.139「Linux カーネルコンフィギュレーションの変更」に示すコマンドを実行します。

[ATDE ~]$ make ARCH=arm menuconfig

図11.139 Linux カーネルコンフィギュレーションの変更

コマンドを実行するとカーネルコンフィギュレーション設定画面が表示されます。カーネルコンフィギュレーションを変更後、"Exit"を選択して「Do you wish to save your new kernel configuration? (Press <ESC><ESC> to continue kernel configuration.)」で "Yes" を選択し、カーネルコンフィギュレーションを確定します。

 .config - Linux/arm 5.10.145 Kernel Configuration
 ─────────────────────────────────────────────
  ┌──────────  Linux/arm 5.10.145 Kernel Configuration   ──────────┐
  │  Arrow keys navigate the menu.  <Enter> selects submenus ---> (or empty submenus   │
  │  ----).  Highlighted letters are hotkeys.  Pressing <Y> includes, <N> excludes, <M>│
  │  modularizes features.  Press <Esc><Esc> to exit, <?> for Help, </> for Search.    │
  │  Legend: [*] built-in  [ ] excluded  <M> module  < > module capable                │
  │ ┌───────────────────────────────────────┐ │
  │ │         General setup  --->                                                  │ │
  │ │         System Type  --->                                                    │ │
  │ │         Bus support  --->                                                    │ │
  │ │         Kernel Features  --->                                                │ │
  │ │         Boot options  --->                                                   │ │
  │ │         CPU Power Management  --->                                           │ │
  │ │         Floating point emulation  --->                                       │ │
  │ │         Power management options  --->                                       │ │
  │ │         Firmware Drivers  --->                                               │ │
  │ │     [ ] ARM Accelerated Cryptographic Algorithms  ----                       │ │
  │ │         General architecture-dependent options  --->                         │ │
  │ │     [*] Enable loadable module support  --->                                 │ │
  │ │     [*] Enable the block layer  --->                                         │ │
  │ │         IO Schedulers  --->                                                  │ │
  │ │         Executable file formats  --->                                        │ │
  │ │         Memory Management options  --->                                      │ │
  │ │     [*] Networking support  --->                                             │ │
  │ │         Device Drivers  --->                                                 │ │
  │ │         File systems  --->                                                   │ │
  │ │         Security options  --->                                               │ │
  │ │     -*- Cryptographic API  --->                                              │ │
  │ │         Library routines  --->                                               │ │
  │ │         Kernel hacking  --->                                                 │ │
  │ │                                                                              │ │
  │ └───────────────────────────────────────┘ │
  ├──────────────────────────────────────────┤
  │              <Select>    < Exit >    < Help >    < Save >    < Load >              │
  └──────────────────────────────────────────┘

図11.140 Linux カーネルコンフィギュレーション設定画面


	Linux Kernel Configuration メニューで"/"キーを押下すると、カーネルコンフィギュレーションの検索を行うことができます。カーネルコンフィギュレーションのシンボル名(の一部)を入力して"Ok"を選択すると、部分一致するシンボル名を持つカーネルコンフィギュレーションの情報が一覧されます。

ビルド
Linux カーネルをビルドするには、図11.141「Linux カーネルのビルド」に示すコマンドを実行します。
```
[ATDE ~/linux-[VERSION]]$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- LOADADDR=0x82000000 uImage
[ATDE ~/linux-[VERSION]]$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf-
```
図11.141 Linux カーネルのビルド

インストール

ビルドしたカーネルは、以下に示すどちらかの方法でインストールしてください。

swupdate でインストールする

mkswu の初期化を行った後に提供されているスクリプトを使ってSWUイメージを作成してください。

[ATDE ~/linux-[VERSION]]$ /usr/share/mkswu/examples/kernel_update_plain.install.sh ~/mkswu/kernel.desc
Installing kernel in /home/atmark/mkswu/kerneltest ...
'arch/arm/boot/uImage' -> '/home/atmark/mkswu/kernel/uImage'
'arch/arm/boot/dts/armadillo-610-at-dtweb.dtb' -> '/home/atmark/mkswu/kernel/armadillo-610-at-dtweb.dtb'
: (省略)
  INSTALL arch/arm/crypto/chacha-neon.ko
  INSTALL arch/arm/crypto/curve25519-neon.ko
: (省略)
  DEPMOD  [VERSION]
Updated /home/atmark/mkswu/kernel.desc version from [PREV_VERSION] to [VERSION]
Done installing kernel, run `mkswu "/home/atmark/mkswu/kernel.desc"` next.
[ATDE ~/linux-[VERSION]]$ mkswu ~/mkswu/kernel.desc
/home/atmark/mkswu/kernel.swu を作成しました

図11.142 Linux カーネルを SWU でインストールする方法

作成された kernel.swu のインストールについては「イメージのインストール」を参照ください。

この kernel.swu をインストールする際は /etc/swupdate_preserve_files の更新例の様に /boot と /lib/modules を維持するように追加します。カーネルをインストールした後に Armadillo Base OS を更新しても、この kernel.swu のカーネルが維持されます。

標準のカーネルに戻りたいか、以下の図11.143「Linux カーネルを build_rootfs でインストールする方法」で Armadillo Base OS の更新のカーネルを使用したい場合は /etc/swupdate_preserve_files から /boot と /lib/modules の行を削除してください。

build_rootfs で新しいルートファイルシステムをビルドする

build_rootfs を展開した後に以下のコマンドでインストールしてください。

[ATDE ~/linux-[VERSION]]$ BROOTFS=$HOME/build-rootfs-[VERSION] 
[ATDE ~/linux-[VERSION]]$ sed -i -e '/^linux-at/d' "$BROOTFS/a6e/packages" 
[ATDE ~/linux-[VERSION]]$ cp -v arch/arm/boot/uImage "$BROOTFS/a6e/resources/boot/"
'arch/arm/boot/uImage' -> '/home/atmark/build-rootfs-v3.17-at.3/a6e/resources/boot/uImage'
[ATDE ~/linux-[VERSION]]$ cp -v arch/arm/boot/dts/armadillo*.{dtb,dtbo} "$BROOTFS/a6e/resources/boot/"
'arch/arm/boot/dts/armadillo-610-at-dtweb.dtb' -> '/home/atmark/build-rootfs-v3.17-at.3/a6e/resources/boot/armadillo-610-at-dtweb.dtb'
: (省略)
[ATDE ~/linux-[VERSION]]$ rm -rfv "$BROOTFS/a6e/resources/lib/modules" 
[ATDE ~/linux-[VERSION]]$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- INSTALL_MOD_PATH="$BROOTFS/a6e/resources" -j5 modules_install
  INSTALL arch/arm/crypto/chacha-neon.ko
  INSTALL arch/arm/crypto/curve25519-neon.ko
: (省略)
  DEPMOD  [VERSION]

図11.143 Linux カーネルを build_rootfs でインストールする方法

	`build_rootfs` のディレクトリ名を設定します。これによって、長いディレクトリ名を何度も入力する必要が無くなります。
	アットマークテクノが提供するカーネルをインストールしない様に、 `linux-at-a6@atmark` と記載された行を削除します。
	別のカーネルをすでにインストールしている場合は、新しいモジュールをインストールする前に古いモジュールを削除する必要があります。

11.7.3. Alpine Linux ルートファイルシステムをビルドする

ここでは、build-rootfs を使って、 Alpine Linux ルートファイルシステムを構築する方法を説明します。

build-rootfs は、ATDE 上で Armadillo-IoT ゲートウェイ A6E 用の Alpine Linux ルートファイルシステムを構築することができるツールです。

ルートファイルシステムのビルドに必要な Podman のインストール
次のコマンドを実行します。
```
[ATDE ~]$ sudo apt install podman btrfs-progs xxhash
```
build-rootfs の入手
Armadillo-IoT ゲートウェイ A6E 開発用ツールから「Alpine Linuxルートファイルシステムビルドツール」ファイル (build-rootfs-[VERSION].tar.gz) を次のようにダウンロードします。
```
[ATDE ~/]$ wget https://download.atmark-techno.com/armadillo-iot-a6e/tool/build-rootfs-latest.tar.gz
[ATDE ~/]$ tar xf build-rootfs-latest.tar.gz
[ATDE ~/]$ cd build-rootfs-[VERSION]
```

Alpine Linux ルートファイルシステムの変更

a6eディレクトリ以下のファイルを変更することで、ルートファイルシステムをカスタマイズすることができます。

commonとa6e ディレクトリ直下にあるfixupやpackagesなどの同名ファイルは、それぞれのファイルを連結して利用されます。パッケージの削除などを行う場合は、commonディレクトリ以下のファイルも確認してください。

commonとa6e内のサブディレクトリにある同名ファイルは、a6eのファイルが利用されます。

build-rootfsに含まれるファイルの説明は次の通りです。

表11.25 build-rootfsのファイル説明

ファイル	説明
a6e/resources/*	配置したファイルやディレクトリは、そのままルートファイルシステム直下にコピーされます。ファイルを追加する場合は、このディレクトリに入れてください。
a6e/packages	このファイルに記載されているパッケージはルートファイルシステムにインストールされます。パッケージを追加する場合はこのファイルに追加してください。
a6e/fixup	このファイルに記載されているコマンドはパッケージのインストールが完了した後に実行されます。
a6e/image_firstboot/*	配置したファイルやディレクトリは、「ブートディスクの作成」や「初期化インストールディスクの作成」の手順のようにブートディスクイメージを作成する際、そのままルートファイルシステム直下にコピーされます。
a6e/image_installer/*	配置したファイルやディレクトリは、「初期化インストールディスクの作成」の手順のようにインストールディスクイメージを作成する際、そのままインストーラーにコピーされます。ルートファイルシステムに影響はありません。
a6e/image_common/*	配置したファイルやディレクトリは、ブートディスクイメージおよびインストールディスクイメージを作成する際、ルートファイルシステム、インストーラにそれぞれコピーされます。

利用可能なパッケージは以下のページで検索することができます。

Alpine Linuxルートファイルシステムを起動している Armadilloでも検索することができます。

[armadillo ~]# apk update
[armadillo ~]# apk search ruby
ruby-test-unit-rr-1.0.5-r0
ruby-rmagick-5.1.0-r0
ruby-public_suffix-5.0.0-r0
:
: (省略)
:
ruby-mustache-1.1.1-r5
ruby-nokogiri-1.13.10-r0

ビルド

次のコマンドを実行します。

パッケージをインターネット上から取得するため回線速度に依存しますが、ビルドには数分かかります。

[ATDE ~/build-rootfs-[VERSION]]$ sudo ./build_rootfs.sh -b a6e
use default(outdir=/home/atmark/git/build-rootfs)
use default(output=baseos-6e-ATVERSION.tar.zst)
:
: (略)
:
> Creating rootfs archive
-rw-r--r--    1 root     root     231700480 Oct 11 07:18 rootfs.tar
ERROR: No such package: .make-alpine-make-rootfs
============================================
footprint[byte]  tarball[byte]  packages
      229904000       74942331  alpine-base coreutils chrony ...(省略)
============================================
done.


	リリース時にバージョンに日付を含めたくないときは --release を引数に追加してください。


	インターネットに接続できない環境か、テスト済みのソフトウェアのみをインストールしたい場合は Armadillo-IoT ゲートウェイ G4 開発用ツールからキャッシュアーカイブもダウンロードして、 `build_rootfs.sh --cache baseos-x2-[VERSION].cache.tar` で使ってください。

任意のパス、ファイル名で結果を出力することもできます。

[ATDE ~/build-rootfs-[VERSION]]$ ./build_rootfs.sh -b a6e ~/alpine.tar.zst
:
: (略)
:
[ATDE ~/build-rootfs-[VERSION]]$ ls ~/alpine.tar.zst
~/alpine.tar.zst

インストール
ビルドしたルートファイルシステムは、以下に示すどちらかの方法でインストールしてください。
- swupdate でインストールする
  mkswu の初期化を行った後に提供されているスクリプトを使ってSWUイメージを作成してください。
```
[ATDE ~/build-rootfs-[VERSION]]$ vi OS_update.desc
swdesc_tar --version base_os [VERSION] \
    --preserve-attributes baseos-6e-[VERSION].tar.zst
[ATDE ~/build-rootfs-[VERSION]]$ mkswu OS_update.desc
OS_update.swu を作成しました。
```
  作成された OS_update.swu のインストールについては「イメージのインストール」を参照ください。
- 「ブートディスクの作成」でインストールする
  手順を実行すると、ビルドされた baseos-6e-[VERSION].tar.zst が自動的に利用されます。

11.8. SDブートの活用

本章では、microSD カードから直接起動(以降「SDブート」と表記します)する手順を示します。 SD ブートを活用すると、microSD カードを取り替えることでシステムイメージを変更することができます。本章に示す手順を実行するためには、容量が 8Gbyte 以上の microSD カードを必要とします。


	SD ブートを行った場合、ブートローダーの設定は microSDカードに保存されます。


	WLAN 搭載モデルでは、SD コントローラ(uSDHC2) を WLAN/BT コンボモジュールが使用するため SD ブートができません。

11.8.1. ブートディスクの作成

ブートディスクイメージのビルドします
「Alpine Linux ルートファイルシステムをビルドする」で説明されているソースツリー alpine/build-rootfs にあるスクリプト build_image と「ブートローダーをビルドする」でビルドした u-boot-dtb.imx を利用します。

[ATDE ~/build-rootfs-[VERSION]]$ sudo ./build_image.sh --board a6e \
          --boot ~/u-boot-[VERSION]/u-boot-dtb.imx
: (省略)
[ATDE ~/build-rootfs-[VERSION]]$ ls baseos-6e*img
baseos-6e-[VERSION].img

ATDE に microSD カードを接続します。詳しくは「取り外し可能デバイスの使用」を参考にしてください。

microSD カードのデバイス名を確認します

[ATDE ~]$ ls /dev/sd?
/dev/sda  /dev/sdb
[ATDE ~]$ sudo fdisk -l /dev/sdb
Disk /dev/sdb: 7.22 GiB, 7751073792 bytes, 15138816 sectors
Disk model: SD/MMC
: (省略)

microSD カードがマウントされている場合、アンマウントします。

[ATDE ~]$ mount
: (省略)
/dev/sdb1 on /media/52E6-5897 type ext2 (rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0077,codepage=cp437,iocharset=utf8,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks)
[ATDE ~]$ sudo umount /dev/sdb1

図11.144 自動マウントされたmicroSDカードのアンマウント

ブートディスクイメージの書き込み
```
[ATDE ~]$ sudo dd if=~/build-rootfs-[VERSION]/baseos-6e-[VERSION].img \
                  of=/dev/sdb bs=1M oflag=direct status=progress
```
microSDカードの性能にもよりますが、書き込みには5分程度かかります。

microSDカードのパーティション構成は次のようになっています。

表11.26 microSDカードのパーティション構成

パーティション	オフセット	サイズ	説明
-	0	10MiB	ブートローダー
1	10MiB	300MiB	A/B アップデートのA面パーティション
2	310MiB	300MiB	A/B アップデートのB面パーティション
3	610MiB	50MiB	ログ用パーティション
4	660MiB	200MiB	ファームウェア
5	860MiB	残り	アプリケーション用パーティション

gdiskで確認すると次のようになります。

[ATDE ~]$ sudo gdisk -l /dev/sdb
GPT fdisk (gdisk) version 1.0.6

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sdb: 60506112 sectors, 28.9 GiB
Model: VMware Virtual I
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): 44B816AC-8E38-4B71-8A96-308F503238E3
Partition table holds up to 128 entries
Main partition table begins at sector 20448 and ends at sector 20479
First usable sector is 20480, last usable sector is 60485632
Partitions will be aligned on 2048-sector boundaries
Total free space is 0 sectors (0 bytes)

Number  Start (sector)    End (sector)  Size       Code  Name
   1           20480          634879   300.0 MiB   8300  rootfs_0
   2          634880         1249279   300.0 MiB   8300  rootfs_1
   3         1249280         1351679   50.0 MiB    8300  logs
   4         1351680         1761279   200.0 MiB   8300  firm
   5         1761280        60485632   28.0 GiB    8300  app

11.8.2. SDブートの実行

「ブートディスクの作成」で作成したブートディスクから起動する方法を説明します。

Armadillo-IoT ゲートウェイ A6Eに電源を投入する前に、ブートディスクをCON1(SD インターフェース)に挿入します。また、SW2 を起動デバイスは microSD 側設定します。SW2 に関しては、図15.23「スイッチの状態と起動デバイス」を参照ください。

電源を投入します。

U-Boot 2020.04 (Oct 25 2022 - 10:37:29 +0900)

CPU:   i.MX6ULL rev1.1 at 396 MHz
Model: Atmark Techno Armadillo-IoT Gateway A6E Board
DRAM:  512 MiB
PMIC: PFUZE3000 DEV_ID=0x30 REV_ID=0x11
MMC:   FSL_SDHC: 0, FSL_SDHC: 1
Loading Environment from MMC... *** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
Saving Environment to MMC... Writing to redundant MMC(1)... OK
switch to partitions #0, OK
mmc1 is current device
flash target is MMC:1
Net:
Warning: ethernet@2188000 using MAC address from ROM
eth0: ethernet@2188000
Fastboot: Normal
Normal Boot
Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc1 is current device
11660400 bytes read in 524 ms (21.2 MiB/s)
Booting from mmc ...
38603 bytes read in 22 ms (1.7 MiB/s)
Loading fdt boot/armadillo.dtb
## Booting kernel from Legacy Image at 80800000 ...

...中略...

Welcome to Alpine Linux 3.16
Kernel 5.10.149-1-at on an armv7l (/dev/ttymxc2)

armadillo login:

11.8.3. ゲートウェイコンテナのインストール

「ブートディスクの作成」で作成したブートディスクには、ゲートウェイコンテナが含まれていません。必要な場合は、ゲートウェイコンテナの SWU イメージを作成してインストールする必要があります。

「SWUイメージの作成」記載の手順で、最初の書き込み用の SWU イメージ initial_setup.swu を作成します。
ゲートウェイコンテナの SWU イメージを作成
1. Armadillo-IoT ゲートウェイ A6E ゲートウェイコンテナから「SWU イメージ作成アーカイブ」ファイル (a6e-gw-container-[version].tar.gz) を図11.145「ゲートウェイコンテナ SWU イメージアーカイブをダウンロードし、 SWU イメージを作成する」に示す手順でダウンロードし、 SWU イメージを作成します。
  [ATDE ~]$ wget https://armadillo.atmark-techno.com/files/downloads/armadillo-iot-a6e/container/a6e-gw-container-[version].tar.gz [ATDE ~]$ mkdir a6e-gw-container-swu [ATDE ~]$ tar xf a6e-gw-container-[version].tar.gz -C a6e-gw-container-swu [ATDE ~]$ cd a6e-gw-container-swu [ATDE ~]$ mkswu a6e-gw-container.desc Enter pass phrase for /home/atmark/mkswu/swupdate.key: 以下のファイルをUSBメモリにコピーしてください： '/path/to/a6e-gw-container.swu' '/path/to/a6e-gw-container-image-[version].tar' '/path/to/.a6e-gw-container/a6e-gw-container-image-[version].tar.sig'
  図11.145 ゲートウェイコンテナ SWU イメージアーカイブをダウンロードし、 SWU イメージを作成する
  ゲートウェイコンテナ SWU イメージアーカイブをダウンロードします
  
  mkswu コマンドで SWU イメージを作成します
SWU イメージのインストール
「イメージのインストール」の手順に従い、最初の書き込み用の SWU イメージと、ゲートウェイコンテナ SWU イメージをインストールします。なお、必ず最初の書き込み用の SWU イメージを先にインストールするよう注意してください。

11.9. Armadilloのソフトウェアの初期化

microSD カードを使用し、Armadillo Base OS の初期化を行えます。


	初期化を行っても、ファームウェアパーティション(mmcblk0p4)は変更されません。

11.9.1. インストールディスクの作成

インストールディスクは二つの種類があります：

初期化インストールディスク。Armadillo-IoT ゲートウェイ A6E インストールディスクイメージにある標準のイメージです。
開発が完了した Armadillo-IoT ゲートウェイ A6E をクローンするためのインストールディスク。

11.9.1.1. 初期化インストールディスクの作成

512 MB 以上の microSD カードを用意してください。
標準のインストールディスクイメージを使用する場合は、 Armadillo-IoT ゲートウェイ A6E インストールディスクイメージから「Armadillo Base OS」をダウンロードしてください。
「Armadilloのソフトウェアをビルドする」でビルドしたイメージを使用してインストールディスクを作成したい場合は、以下のコマンドを実行して、インストールディスクイメージを作成してください。
```
[ATDE ~/build-rootfs-[VERSION]]$ sudo ./build_image.sh --board a6e
: (省略)
[ATDE ~/build-rootfs-[VERSION]]$ ls baseos-6e*img
baseos-6e-[VERSION].img
[ATDE ~/build-rootfs-[VERSION]]$ sudo ./build_image.sh --board a6e \
        --boot ~/u-boot-[VERSION]/u-boot-dtb.imx \
        --installer ./baseos-6e-[VERSION].img
```
コマンドの実行が完了すると、baseos-6e-[VERSION]-installer.img というファイルが作成されていますので、こちらを使用してください。
ATDE に microSD カードを接続します。詳しくは「取り外し可能デバイスの使用」を参考にしてください。

microSD カードのデバイス名を確認します

[ATDE ~]$ ls /dev/sd?
/dev/sda  /dev/sdb
[ATDE ~]$ sudo fdisk -l /dev/sdb
Disk /dev/sdb: 7.22 GiB, 7751073792 bytes, 15138816 sectors
Disk model: SD/MMC
: (省略)

microSD カードがマウントされている場合、アンマウントします。

[ATDE ~]$ mount
: (省略)
/dev/sdb1 on /media/52E6-5897 type ext2 (rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0077,codepage=cp437,iocharset=utf8,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks)
[ATDE ~]$ sudo umount /dev/sdb1

ダウンロードしたファイルを展開し、imgファイルをmicroSDカードに書き込んでください。
Linux PCの場合、以下のようにmicroSDカードに書き込むことができます。
```
[ATDE ~]$ unzip baseos-6e-installer-[VERSION].zip
[ATDE ~]$ sudo dd if=baseos-6e-installer-[VERSION].img \
                  of=/dev/sdb bs=1M oflag=direct status=progress
```
また、Windowsの場合、エクスプローラー等でZipファイルからimgファイルを取り出し、「Win32 Disk Imager」などを使用してmicroSDカードに書き込むことができます。

11.9.1.2. 開発が完了した Armadillo をクローンするインストールディスクの作成

microSD カードを用意してください。
初期化インストールディスクをベースとしますので、「初期化インストールディスクの作成」でビルドしたSDカードを使用できますが、用意されていなければ次のステップで自動的にダウンロードされます。

abos-ctrl make-installer を実行してください

[armadillo ~]# abos-ctrl make-installer
It looks like your SD card does not contain an installer image
Download base SD card image from https://armadillo.atmark-techno.com (~200MB) ? [y/N]
WARNING: it will overwrite your sd card!!
y
Downloading installer image
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  167M  100  167M    0     0   104M      0  0:00:01  0:00:01 --:--:--  104M
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100    70  100    70    0     0   1441      0 --:--:-- --:--:-- --:--:--  1458
Writing baseos-6e-installer-3.15.4-at.6.img to SD card (442M)
439353344 bytes (439 MB, 419 MiB) copied, 134 s, 3.3 MB/s
421+0 records in
421+0 records out
441450496 bytes (441 MB, 421 MiB) copied, 134.685 s, 3.3 MB/s
Verifying written image is correct
436207616 bytes (436 MB, 416 MiB) copied, 46 s, 9.5 MB/s
421+0 records in
421+0 records out
441450496 bytes (441 MB, 421 MiB) copied, 46.8462 s, 9.4 MB/s
Checking and growing installer main partition
GPT data structures destroyed! You may now partition the disk using fdisk or
other utilities.
Setting name!
partNum is 0
The operation has completed successfully.
e2fsck 1.46.4 (18-Aug-2021)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
rootfs_0: 2822/102400 files (0.5% non-contiguous), 352391/409600 blocks
(1/1) Installing e2fsprogs-extra (1.46.4-r0)
Executing busybox-1.34.1-r5.trigger
OK: 202 MiB in 197 packages
resize2fs 1.46.4 (18-Aug-2021)
Resizing the filesystem on /dev/mmcblk1p1 to 15547884 (1k) blocks.
The filesystem on /dev/mmcblk1p1 is now 15547884 (1k) blocks long.

Currently booted on /dev/mmcblk0p1
Copying boot image
Copying rootfs
301989888 bytes (302 MB, 288 MiB) copied, 10 s, 30.1 MB/s
300+0 records in
300+0 records out
314572800 bytes (315 MB, 300 MiB) copied, 10.3915 s, 30.3 MB/s
Copying /opt/firmware filesystem
Copying appfs
At subvol app/snapshots/volumes
At subvol app/snapshots/boot_volumes
At subvol app/snapshots/boot_containers_storage
Cleaning up and syncing changes to disk...
Installer updated successfully!

11.9.2. インストールディスクを使用する

SW2(起動デバイス設定スイッチ)を ON にし、起動デバイスを microSD に設定します。
microSD カードを CON1 に挿入します。
電源を投入すると、1分程度でeMMCのソフトウェアの初期化が完了します。
完了すると電源が切れます(SYS(システムLED)が消灯、コンソールに reboot: Power down が表示)。
電源を取り外し、続いて SW2 を OFF に設定し、microSD カードを外してください。
10秒以上待ってから再び電源を入れると、初回起動時と同じ状態になります。

11.10. Armadilloのソフトウェアをアップデートする

Armadillo-IoT ゲートウェイ A6Eでは、開発・製造・運用それぞれに適した複数のソフトウェアアップデート方法を用意しています。本章では、それぞれのソフトウェアアップデート方法について説明します。

ソフトウェアアップデートを実現するソフトウェアの概要や仕様、用語については 14章ソフトウェア仕様 を参照してください。

11.10.1. SWUイメージとは

Armadillo Base OS ではソフトウェアアップデートのためにOS やコンテナ等を格納するためにSWUというイメージ形式を使います。

SWUイメージは swupdate (https://sbabic.github.io/swupdate/swupdate.html) によってArmadillo Base OS上で検証とインストールが実行されます。SWUイメージをArmadilloに転送するための方法は、用途や状況に合わせて様々な方法を用意しています。例えば、USBメモリから読み取る、ウェブサーバーからダウンロードする、hawkBitというWebアプリケーションを使うなどです。

11.10.2. SWUイメージの作成

SWUイメージの作成には、mkswu というツールを使います。

mkswu に含まれる mkswu を実行すると、アップデート対象やバージョン等の情報を記載した .desc ファイルに含まれる命令を順次実行してイメージを作り上げます。

詳しくは「mkswu の desc ファイル」を参考にしてください。

mkswu の取得

[ATDE ~]$ sudo apt update && sudo apt install mkswu

インストール済みの場合は、以下のコマンドを実行し最新版への更新を行ってください。

[ATDE ~]$ sudo apt update && sudo apt upgrade

git のバージョンからアップデートする場合、 mkswu --import で以前使っていたコンフィグをロードしてください。

[ATDE ~/swupdate-mkimage]$ mkswu --import
コンフィグファイルを更新しました：/home/atmark/swupdate-mkimage/mkswu.conf
/home/atmark/swupdate-mkimage/mkswu.conf のコンフィグファイルとその鍵を
/home/atmark/mkswu にコピーします。
mkdir: ディレクトリ '/home/atmark/mkswu' を作成しました
'/home/atmark/swupdate-mkimage/swupdate.key' -> '/home/atmark/mkswu/swupdate.key'
'/home/atmark/swupdate-mkimage/swupdate.pem' -> '/home/atmark/mkswu/swupdate.pem'
/home/atmark/swupdate-mkimage/mkswu.conf のコンフィグファイルを
/home/atmark/mkswu/mkswu.conf にコピーしました。
mkswu でイメージ作成を試してから前のディレクトリを消してください。

最初に行う設定

mkswu --init を実行して鍵や最初の書き込み用のイメージを生成します。作成する鍵は、swuパッケージを署名するために使用します。

過去に本手順を行っている場合、再度初回アップデート作業を行う必要はありません。再度アップデートを行う際には、Armadilloに配置した公開鍵に対応する秘密鍵でアップデートを行いますので、「mkswu の desc ファイル」を参考にしてください。

[ATDE ~]$ mkswu --init
mkdir: ディレクトリ '/home/atmark/mkswu' を作成しました
コンフィグファイルを更新しました：/home/atmark/mkswu/mkswu.conf
証明書のCommon nameを入力してください: [COMMON_NAME] 
証明書の鍵のパスワードを入力ください（4-1024文字）
証明書の鍵のパスワード（確認）:
Generating an EC private key
writing new private key to '/home/atmark/mkswu/swupdate.key'
 -----
アップデートイメージを暗号化しますか？ (N/y) 
アットマークテクノが作成したイメージをインストール可能にしますか？ (Y/n) 
rootパスワード: 
rootパスワード（確認）:
atmarkユーザのパスワード（空の場合はアカウントをロックします）: 
atmarkユーザのパスワード（確認）:
BaseOSイメージのarmadillo.atmark-techno.comサーバーからの自動アップデートを行いますか？ (y/N) 
/home/atmark/mkswu/initial_setup.swu を作成しました。

"/home/atmark/mkswu/initial_setup.swu" をそのまま使うことができますが、
モジュールを追加してイメージを再構築する場合は次のコマンドで作成してください：
  mkswu "/home/atmark/mkswu/initial_setup.desc" [他の.descファイル]

インストール後は、このディレクトリを削除しないように注意してください。
鍵を失うと新たなアップデートはデバイスの /etc/swupdate.pem
を修正しないとインストールできなくなります。

[ATDE ~]$ ls ~/mkswu
initial_setup.desc  initial_setup.swu  mkswu.conf
swupdate.aes-key    swupdate.key       swupdate.pem

	COMMON_NAME には証明鍵の「common name」として会社や製品が分かるような任意の名称を入力してください。
	証明鍵を保護するパスフレーズを2回入力します。
	swuイメージ自体を暗号化する場合に「y」を入力します。詳細は「SWUpdate と暗号化について」を参考にしてください。
	アットマークテクノのアップデートをインストールしない場合は「n」を入力します。
	rootのパスワードを2回入力します。
	atmarkユーザーのパスワードを2回入力します。何も入力しない場合はユーザーをロックします。
	自動アップデートを無効のままで進みます。ここで「y」を入れると、定期的にアットマークテクノのサーバーからアップデートの有無を確認し、自動的にインストールします。
	作成したファイルを確認します。「swupdate.aes-key」は暗号化の場合にのみ作成されます。

このイメージは初回インストール用の署名鍵を使って、作成した鍵とユーザーのパスワードを設定します。

インストール後にコンフィグの mkswu.conf と鍵の　swupdate.* をなくさないようにしてください。

このイメージに他の変更も入れれます。他の /usr/share/mkswu/examples/ ディレクトリにある.descファイルや「mkswu の desc ファイル」を参考にして、以下の例のように同じswuにいくつかの.descを組み込めます。

例えば、opensshを有効にします。

[ATDE ~/mkswu]$ cp -rv /usr/share/mkswu/examples/enable_sshd* .
: (省略)
'/usr/share/mkswu/examples/enable_sshd/root/.ssh/authorized_keys'
    -> './enable_sshd/root/.ssh/authorized_keys'
'/usr/share/mkswu/examples/enable_sshd.desc' -> './enable_sshd.desc'
[ATDE ~/mkswu]$ cp ~/.ssh/id_rsa.pub \
                 enable_sshd/root/.ssh/authorized_keys
[ATDE ~/mkswu]$ mkswu initial_setup.desc enable_sshd.desc
enable_sshd.desc を組み込みました。
initial_setup.swu を作成しました。

イメージのインストール
「イメージのインストール」を参考に、作成したイメージをインストールしてください。
次回以降のアップデート
次回以降のアップデートは作成した証明鍵を使用してArmadillo-IoT ゲートウェイA6E のSWUイメージを作成します。
.desc ファイルの内容は /usr/share/mkswu/examples/ のディレクトリや「mkswu の desc ファイル」を参考にしてください。

11.10.3. イメージのインストール

イメージをインストールする方法として以下に示すような方法があります。もし、作成した SWU イメージのインストールに失敗する場合は、「swupdate がエラーする場合の対処」をご覧ください。

USBメモリまたはSDカードからの自動インストール

Armadillo-IoT ゲートウェイ A6EにUSBメモリを接続すると自動的にアップデートが始まります。アップデート終了後にArmadillo-IoT ゲートウェイ A6Eは自動で再起動します。

USBメモリやSDカードをvfatもしくはext4形式でフォーマットし、作成した.swuのファイルをディレクトリを作らずに配置してください。

ATDE上でUSBメモリ/microSDカードのパーティションを作成・フォーマットする方法

https://armadillo.atmark-techno.com/howto/atde-partition-howto

[ATDE ~/mkswu]$ df -h
Filesystem           Size  Used Avail Use% Mounted on
: (省略)
/dev/sda1        15G  5.6G  9.1G  39% /media/USBDRIVE 
[ATDE ~/mkswu]$ cp initial_setup.swu /media/USBDRIVE/ 
[ATDE ~/mkswu]$ umount /media/USBDRIVE

	USBメモリがマウントされている場所を確認します。
	ファイルをコピーします。
	/media/USBDRIVEをアンマウントします。コマンド終了後にUSBメモリを取り外してください。

エラーの場合、/var/log/messageに保存されます。例えば、コンソールで証明の間違ったイメージのエラーを表示します：

[armadillo ~]# tail /var/log/messages
Nov 19 10:48:42 user.notice swupdate-auto-update: Mounting sda0 on /mnt
Nov 19 10:48:42 user.notice swupdate-auto-update: Trying update /mnt/initial_setup.swu
Nov 19 10:48:42 user.info swupdate: START Software Update started !
Nov 19 10:48:42 user.err swupdate: FAILURE ERROR : Signature verification failed 
Nov 19 10:48:42 user.err swupdate: FAILURE ERROR : Compatible SW not found
Nov 19 10:48:42 user.err swupdate: FATAL_FAILURE Image invalid or corrupted. Not installing ...

証明が間違ったメッセージ。

外部記憶装置からイメージのインストール（手動）

USBメモリやmicroSDカード等の外部記憶装置のルートディレクトリ以外にswuイメージを保存して、イメージのインストールを行います。ルートディレクトリに保存すると自動アップデートが行われますので、/var/log/messagesを確認してください。

以下は外部記憶装置が/dev/mmcblk1p1(microSDカード）として認識された場合に、イメージのインストールを行う例です。

[armadillo ~]# mount /dev/mmcblk1p1 /mnt
[armadillo ~]# swupdate -i /mnt/swu/initial_setup.swu
SWUpdate v5f2d8be-dirty

Licensed under GPLv2. See source distribution for detailed copyright notices.

[INFO ] : SWUPDATE running :  [main] : Running on AGX4500 Revision at1
[INFO ] : SWUPDATE started :  Software Update started !
[INFO ] : SWUPDATE running :  [read_lines_notify] : No base os update: copying current os over
[INFO ] : SWUPDATE running :  [read_lines_notify] : Removing unused containers
[INFO ] : SWUPDATE running :  [read_lines_notify] : swupdate triggering reboot!
Killed

ウェブサーバーからイメージのインストール（手動）
swuイメージをウェブサーバーにアップロードして、イメージのインストールを行います。以下は、http://server/initial_setup.swu のイメージをインストールする例です。

[armadillo ~]# swupdate -d '-u http://server/initial_setup.swu'
SWUpdate v5f2d8be-dirty

Licensed under GPLv2. See source distribution for detailed copyright notices.

[INFO ] : SWUPDATE running :  [main] : Running on AGX4500 Revision at1
[INFO ] : SWUPDATE running :  [channel_get_file] : Total download size is 25 kB.
[INFO ] : SWUPDATE started :  Software Update started !
[INFO ] : SWUPDATE running :  [read_lines_notify] : No base os update: copying current os over
[INFO ] : SWUPDATE running :  [read_lines_notify] : Removing unused containers
[INFO ] : SWUPDATE running :  [read_lines_notify] : swupdate triggering reboot!
Killed

ウェブサーバーからの定期的な自動インストール

swupdate-urlを有効にしたら、定期的にチェックしてインストールします。以下はサービスの有効化とタイミングの設定の例です。

[armadillo ~]# rc-update add swupdate-url 
[armadillo ~]# persist_file /etc/runlevels/default/swupdate-url 
[armadillo ~]#
    echo https://download.atmark-techno.com/armadillo-iot-a6e/image/baseos-6e-latest.swu \
                        > /etc/swupdate.watch 
[armadillo ~]# echo 'schedule="0 tomorrow"' > /etc/conf.d/swupdate-url
[armadillo ~]# echo 'rdelay="21600"' >> /etc/conf.d/swupdate-url 
[armadillo ~]# persist_file /etc/swupdate.watch /etc/conf.d/swupdate-url

	swupdate-urlサービスを有効します。
	サービスの有効化を保存します。
	イメージのURLを登録します。一行ごとにイメージのURLを設定することができ、複数行にイメージのURLを設定することができます。
	チェックやインストールのスケジュールを設定します。
	変更した設定ファイルを保存します。

USBメモリからのアップデートと同様に、ログは/var/log/messagesに保存されます。


	initial_setupのイメージを作成の際に `/usr/share/mkswu/examples/enable_swupdate_url.desc` を入れると有効にすることができます。

hawkBit を使用した自動インストール
hawkBit で Armadillo-IoT ゲートウェイ A6E を複数台管理してアップデートすることができます。「hawkBitサーバーから複数のArmadilloに配信する」を参考にしてください。

11.10.4. swupdate がエラーする場合の対処

SWU イメージのインストール動作は、「SWUイメージとは」で述べたように swupdate が実行します。mkswu で作成した SWU イメージの内容が適切でなかったり、あるいは、ストレージの空き容量が不足していたりするなど、いくつかの理由で swupdate のインストール動作が失敗することがあります。インストールに失敗すると、swupdate は /var/log/messages にエラーメッセージのログを残しますので、エラーメッセージを見ると、エラーの内容・原因が分かります。

エラーの原因ごとに、エラーメッセージとエラーの内容および対処方法を記した FAQ ページ (https://armadillo.atmark-techno.com/faq/swupdate-troubleshooting-abos) を公開しています。 SWU イメージのインストールに失敗して対処法が分からないときは、この FAQ ページをご覧ください。

11.10.5. hawkBitサーバーから複数のArmadilloに配信する

hawkBitサーバーを利用することで複数のArmadillo のソフトウェアをまとめてアップデートすることができます。

手順は次のとおりです。

コンテナ環境の準備
Dockerを利用すると簡単にサーバーを準備できます。 Dockerの準備については https://docs.docker.com/get-docker/ を参照してください。
Dockerの準備ができたら、要件に合わせてコンテナの設定を行います。
- ATDE の場合
  - apt update && apt install mkswu で最新のバージョンを確認してください。
  - ポート転送も必要です。一番シンプルな、プロキシを使用しない場合は 8080、 TLSを使う場合は 443 を転送してください。
    vmware を使う場合は vmware の NAT モードのネットワークを使用している仮想マシン上で Web サーバを構成するページを参考にしてください。
  - ホストPCのIPアドレスを控えておいてください。
- ATDE以外の場合
  - Armadillo-IoT ゲートウェイ A6E 開発用ツールから「Hawkbit docker-composeコンテナ」をダウンロードして展開してください。この場合、以下に /usr/share/mkswu/hawkbit-compose を使う際に展開先のディレクトリとして扱ってください。
  - dockerがアクセスできるホストネームやアドレスを控えておいてください。

hawkBitサーバーの準備

/usr/share/mkswu/hawkbit-compose/setup_container.sh を実行して、質問に答えてください。

以下に簡単な（TLSを有効にしない）テスト用の場合と、 TLSを有効にした場合の例を示します。

setup_container.sh を一度実行した場合はデータのディレクトリにある setup_container.sh のリンクを実行して、ユーザーの追加等のオプション変更を行うこともできます。詳細は`--help` を参考にしてください。

[ATDE ~]$ /usr/share/mkswu/hawkbit-compose/setup_container.sh
docker-compose の設定ファイルと hawkBit のデータをどこに保存しますか？ [/home/atmark/hawkbit-compose] 
setup_container.sh へのリンクを /home/atmark/hawkbit-compose に作ります。
docker サービスに接続できませんでした。sudo でもう一度試します。
[sudo] atmark のパスワード: 
OK!
Hawkbit admin user name [admin] 
admin ユーザーのパスワード:  
パスワードを再入力してください:
追加の管理人アカウントのユーザーネーム（空にすると追加しません） 
hawkBit の「device」ユーザーを登録しますか？（自動登録用） [Y/n]  
device ユーザーのパスワード:
パスワードを再入力してください:
hawkBit の「mkswu」ユーザーを登録しますか？（swuのアップロード用） [Y/n] 
ユーザーにロールアウトの権限を与えますか？（インストール要求を出すこと） [Y/n] 
mkswu ユーザーのパスワード:
パスワードを再入力してください:
Setup TLS reverse proxy? [y/N] 

コンテナの設定が完了しました。docker-compose コマンドでコンテナの管理が可能です。
/home/atmark/hawkbit-compose/setup_container.sh を再び実行すると設定の変更が可能です。
hawkBit コンテナを起動しますか？ [Y/n] 
Creating network "hawkbit-compose_default" with the default driver
Pulling mysql (mysql:5.7)...
: (省略)
Creating hawkbit-compose_hawkbit_1 ... done
Creating hawkbit-compose_mysql_1   ... done

図11.146 hawkBit コンテナのTLSなしの場合（テスト用）の実行例

	コンテナのコンフィグレーションとデータベースの場所を設定します。
	dockerの設定によってsudoが必要な場合もあります。
	admin ユーザーのユーザー名を入力します。
	admin ユーザーのパスワードを二回入力します。
	追加のユーザーが必要な場合に追加できます。
	`examples/hawkbit_register.desc` で armadillo を登録する場合に作っておいてください。詳細は「SWU で hawkBit を登録する」を参考にしてください。
	`hawkbit_push_update` でアップデートを CLI で扱う場合は、「Y」を入力してください。詳細は「hawkBit のアップデート管理を CLI で行う」を参照してください。
	`hawkbit_push_update` でアップデートを実行する場合は、「Y」を入力してください。
	ここでは http でテストのコンテナを作成するので、「N」のままで進みます。
	コンテナを起動します。初期化が終わったら <IP>:8080 でアクセス可能になります。

[ATDE ~]$ /usr/share/mkswu/hawkbit-compose/setup_container.sh
docker-compose の設定ファイルと hawkBit のデータをどこに保存しますか？ [/home/atmark/hawkbit-compose]
setup_container.sh へのリンクを /home/atmark/hawkbit-compose に作ります。
docker サービスに接続できませんでした。sudo でもう一度試します。
OK!
Hawkbit admin user name [admin]
admin ユーザーのパスワード:
パスワードを再入力してください:
パスワードが一致しません。
admin ユーザーのパスワード:
パスワードを再入力してください:
追加の管理人アカウントのユーザーネーム（空にすると追加しません）
hawkBit の「device」ユーザーを登録しますか？（自動登録用） [Y/n]
device ユーザーのパスワード:
パスワードを再入力してください:
hawkBit の「mkswu」ユーザーを登録しますか？（swuのアップロード用） [Y/n]
ユーザーにロールアウトの権限を与えますか？（インストール要求を出すこと） [Y/n]
mkswu ユーザーのパスワード:
パスワードを再入力してください:
Setup TLS reverse proxy? [y/N] y 
lighttpd が起動中で、リバースプロキシ設定と競合しています。
lighthttpd サービスを停止しますか？ [Y/n] 
Synchronizing state of lighttpd.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install disable lighttpd
Removed /etc/systemd/system/multi-user.target.wants/lighttpd.service.
リバースプロキシの設定に証明書の domain name が必要です。
この domain はこのままデバイスからアクセスできる名前にしてください。
例えば、https://hawkbit.domain.tld でアクセスしたら hawkbit.domain.tld、
https://10.1.1.1 でしたら 10.1.1.1 にしてください。
証明書の domain name: 10.1.1.1 
証明書の有効期限を指定する必要があります。Let's encryptを使用する場合、
この値は新しい証明書が生成されるまでしか使用されないので、デフォルトの値
のままにしておくことができます。Let's encryptを使用しない場合、
数年ごとに証明書を新しくすることが最も好ましです。
証明書の有効期間は何日間にしますか？ [3650] 
クライアントのTLS認証を設定するためにCAが必要です。
署名CAのファイルパス（空にするとクライアントTLS認証を無効になります） [] 
サーバーが直接インターネットにアクセス可能であれば、Let's Encryptの証明書
を設定することができます。TOSへの同意を意味します。
https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf
certbotコンテナを設定しますか？ [y/N] 

/home/atmark/hawkbit-compose/data/nginx_certs/proxy.crt を /usr/local/share/ca-certificates/ にコピーして、 update-ca-certificates を実行する必要があります。
このbase64でエンコードされたコピーをexamples/hawkbit_register.sh の
SSL_CA_BASE64 に指定する手順が推奨されます。

LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUJlekNDQVNHZ0F3SUJBZ0lVQTByZ0cwcTJF
SFNnampmb0tUZWg3aGlaSVVVd0NnWUlLb1pJemowRUF3SXcKRXpFUk1BOEdBMVVFQXd3SU1UQXVN
UzR4TGpFd0hoY05Nakl3TXpJMU1EVXhOVFU0V2hjTk16SXdNekl5TURVeApOVFU0V2pBVE1SRXdE
d1lEVlFRRERBZ3hNQzR4TGpFdU1UQlpNQk1HQnlxR1NNNDlBZ0VHQ0NxR1NNNDlBd0VICkEwSUFC
SDFFREhBN3NOTlFJUDlTdlhlUnNmWjl2dVVFWkRkMVE2TzViRlV2RTh4UjUwUlBCLzNlajMzd0VI
NEoKYmZqb296bEpXaExlSG5SbGZsaHExVDlKdm5TalV6QlJNQjBHQTFVZERnUVdCQlFBUmYvSkdT
dkVJek5xZ2JMNQpQamY2VGRpSk1EQWZCZ05WSFNNRUdEQVdnQlFBUmYvSkdTdkVJek5xZ2JMNVBq
ZjZUZGlKTURBUEJnTlZIUk1CCkFmOEVCVEFEQVFIL01Bb0dDQ3FHU000OUJBTUNBMGdBTUVVQ0lD
Nis3ZzJlZk1SRXl0RVk5WDhDNC8vUEw1U1kKWUlGZHUxVFZiUEZrSlV0SUFpRUE4bm1VSnVQSFlz
SHg2N2ErZFRwSXZ1QmJUSG1KbWd6dUl3bTJ2RXppRnZRPQotLS0tLUVORCBDRVJUSUZJQ0FURS0t
LS0tCg== 


Let's encryptの設定は後で足したい場合にsetup_container.shを--letsencryptで実行してください。

コンテナの設定が完了しました。docker-compose コマンドでコンテナの管理が可能です。
/home/atmark/hawkbit-compose/setup_container.sh を再び実行すると設定の変更が可能です。
hawkBit コンテナを起動しますか？ [Y/n]

図11.147 hawkBit コンテナのTLSありの場合の実行例

	今回は TLS を有効にするので、「y」を入力します。
	lighttpd サービスが起動している場合に聞かれます。不要なので、停止します。
	証明書の common name を入力してください。ATDE の場合、ポート転送によってホストのIPアドレスで接続しますのでそのアドレスを入力します。 Let’s encrypt を使用する場合には外部からアクセス可能なDNSを入力してください。
	証明書の有効期間を設定します。デフォルトでは10年になっています。 Let’s encryptを使用する場合には使われていません。
	クライアント側では x509 証明書で認証をとることができますが、この例では使用しません。
	Let’s encrypt による証明書を作成できます。 ATDE の場合は外部からのアクセスが難しいので、この例では使用しません。
	自己署名証明書を作成したので、 Armadillo に設置する必要があります。この証明書の取扱いは「SWU で hawkBit を登録する」を参照してください。

hawkBitへのログイン
作成したコンテナによって http://<サーバーのIPアドレス>:8080 か https://<サーバーのアドレス> にアクセスすると、ログイン画面が表示されます。
デフォルトでは次のアカウントでログインできます。
ユーザー
admin
パスワード
admin
ArmadilloをTargetに登録する
左側のメニューから Deployment をクリックして、Deployment の画面に移ります。
"+"をクリックしてTargetを作成します。
作成したターゲットをクリックすると、下のペインに "Security token:<文字列>" と表示されるので、 <文字列>の部分をメモします。
メモした<文字列>をArmadilloの /etc/swupdate.cfg に設定すると Hawkbit への接続認証が通るようになります。
Target Filterを作成する
左側のメニューから"Target Filters"をクリックして、Target Filters の画面に移ります。
"+" をクリックして新規にTarget Filterを作成します。
Filter name とフィルタリング条件を入力して保存します。
Software moduleを作成する
左側のメニューから"Upload"をクリックして、Upload Managementの画面に移ります。
"+" をクリックしてSoftware moduleを作成します。 type には OS/Application、 version には任意の文字列を指定します。
swuパッケージをアップロードしてSoftware moduleに関連付ける
先程作成した Software module を選択して、ハイライトされた状態で、 "Upload File"ボタンをクリックするか、ファイルをドラッグアンドドロップしてアップロードします。
Distributionを作成してSoftware moduleを関連付ける
左側のメニューから"Distribution"をクリックして、Distribuてアップロードしtion Managementの画面に移ります。
"+" をクリックしてDistributionを作成します。 type には OS/OSwithApp/Apps、 version には任意の文字列を指定します。
"Software module"のペインから先程作成した Softwareをドラッグして、作成したDistributionの上にドロップします。

Rolloutを作成してアップデートを開始する

左側のメニューから"Rollout"をクリックして、Rollout Managementの画面に移ります。

"+"をクリックしてRolloutを作成します。

項目	説明
Name	任意の文字列を設定します。
Distribution Set	先程作成したDistributionを選択します。
Custom Target Filter	先程作成したTarget Filterを選択します。
Action Type	アップデート処理をどのように行うかを設定します。・Forced/Soft: 通常のアップデート・Time Forced: 指定した時刻までにアップデートする・Download only: ダウンロードのみ行う
Start Type	Rollout の実行をどのように始めるかを設定します。・Manual: 後で手動で開始する・Auto: Targetからのハートビートで開始する・Scheduled: 決まった時間から開始する

アップデートの状態を確認する
Rollout Managementの画面のDetail Statusで、各Rolloutのアップデートの状態を確認できます。
アップデート中は黄色、アップデートが正常に完了すると緑色になります。

11.10.5.1. hawkBit のアップデート管理を CLI で行う

一つのアップデートを登録するには、hawkBit の Web UI で必要な手順が長いので CLI で行うことで効率よく実行できます。

サーバーの設定の段階では、「mkswu」のユーザーを作成する必要があります。作成していない場合は setup_container.sh --add-user mkswu で作成してください。

hawkbit_push_update の実行例

[ATDE ~/mkswu]$ ls enable_sshd.swu 
enable_sshd.swu

[ATDE ~/mkswu]$ hawkbit_push_update --help
Usage: /usr/bin/hawkbit_push_update [options] file.swu

rollout creation:
  --no-rollout: only upload the file without creating a rollout 
  --new: create new rollout even if there already is an existing one 
  --failed: Apply rollout only to nodes that previously failed update 

post action:
  --start: start rollout immediately after creation 

[ATDE ~/mkswu]$ hawkbit_push_update --start enable_sshd.swu 
Uploaded (or checked) image extra_os.sshd 1 successfully
Created rollout extra_os.sshd 1 successfully
Started extra_os.sshd 1 successfully

	この例ではあらかじめ作成されている enable_sshd.swu を hawkBit に登録します。
	--no-rollout を使う場合に SWU を「distribution」として登録します。デフォルトでは rollout も作成します。テストする際、デバイスがまだ登録されていなければ rollout の段階で失敗します。
	同じ SWU で rollout を二回作成した場合にエラーが出ます。もう一度作成する場合は `--new` を使ってください。
	一度 rollout をスタートして、 Armadillo で失敗した場合には失敗したデバイスだけに対応した rollout を作れます。
	作成した rollout をすぐ実行します。このオプションには追加の権限を許可する必要があります。
	スタートまで行う実行例です。実行結果は Web UI で表示されます。

11.10.5.2. SWU で hawkBit を登録する

デバイスが多い場合は、SWUを一度作って armadillo を自己登録させることができます。

サーバーの設定の段階では、「device」のユーザーを作成する必要があります。作成していない場合は setup_container.sh --add-user device で作成してください。

hawkbit_register.desc で hawkBit の自己登録を行う例

[ATDE ~]$ cd mkswu/

[ATDE ~/mkswu]$ cp /usr/share/mkswu/examples/hawkbit_register.* . 

[ATDE ~/mkswu]$ vi hawkbit_register.sh 
# Script configuration: edit this if required!
# user given here must have CREATE_TARGET,READ_TARGET_SECURITY_TOKEN permissions
HAWKBIT_USER=device
HAWKBIT_PASSWORD="CS=wC,zJmrQeeKT.3" 
HAWKBIT_URL=https://10.1.1.1 
HAWKBIT_TENANT=default
# set custom options for suricatta block or in general in the config
CUSTOM_SWUPDATE_SURICATTA_CFG="" # e.g. "polldelay = 86400;"
CUSTOM_SWUPDATE_CFG=""
# set to non-empty if server certificate is invalid
SSL_NO_CHECK_CERT=
# or set to cafile that must have been updated first
SSL_CAFILE=
# ... or paste here base64 encoded crt content
SSL_CA_BASE64="
LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUJlakNDQVNHZ0F3SUJBZ0lVYTMvYXpNSHZ0
bFFnaFZnZDhIZWhMaEwxNm5Bd0NnWUlLb1pJemowRUF3SXcKRXpFUk1BOEdBMVVFQXd3SU1UQXVN
UzR4TGpFd0hoY05Nakl3TWpFNE1EVTFNakV6V2hjTk16SXdNakUyTURVMQpNakV6V2pBVE1SRXdE
d1lEVlFRRERBZ3hNQzR4TGpFdU1UQlpNQk1HQnlxR1NNNDlBZ0VHQ0NxR1NNNDlBd0VICkEwSUFC
RFJGcnJVV3hHNnBHdWVoejRkRzVqYkVWTm5scHUwYXBHT1c3UVBPYUF4cWp1ZzJWYjk2UHNScWJY
Sk8KbEFDVVo2OStaMHk3clBqeDJHYnhDNms0czFHalV6QlJNQjBHQTFVZERnUVdCQlJtZzhxL2FV
OURRc3EvTGE1TgpaWFdkTHROUmNEQWZCZ05WSFNNRUdEQVdnQlJtZzhxL2FVOURRc3EvTGE1TlpY
V2RMdE5SY0RBUEJnTlZIUk1CCkFmOEVCVEFEQVFIL01Bb0dDQ3FHU000OUJBTUNBMGNBTUVRQ0lB
ZTRCQ0xKREpWZnFTQVdRcVBqNTFmMjJvQkYKRmVBbVlGY2VBMU45dE8rN0FpQXVvUEV1VGFxWjhH
UFYyRUg1UWdOMFRKS05SckJDOEtpNkZWcFlkRUowYWc9PQotLS0tLUVORCBDRVJUSUZJQ0FURS0t
LS0tCg== 
"
# ... or add your own options if required
CURLOPT=-s

: (省略)

[ATDE ~/mkswu]$ cat hawkbit_register.desc 
: (省略)
swdesc_script hawkbit_register.sh --version extra_os.hawkbit 1

[ATDE ~/mkswu]$ mkswu hawkbit_register.desc 
hawkbit_register.swu を作成しました。

[ATDE ~/mkswu]$ mkswu initial_setup.desc hawkbit_register.desc 
hawkbit_register.desc を組み込みました。
initial_setup.swu を作成しました。

	hawkbit_register.sh と .desc ファイルをカレントディレクトリにコピーします。
	hawkbit_register.sh を編集して、設定を記載します。
	hawkBit の設定の時に入力した「device」ユーザーのパスワードを入力します。この例のパスワードは使用しないでください。
	hawkBit サーバーのURLを入力します。
	TLS を使用の場合に、コンテナ作成の時の証明書を base64 で入力します。
	`hawkbit_register.desc` の中身を確認します。`hawkbit_register.sh` を実行するだけです。
	SWU を作成して、initial_setupがすでにインストール済みの Armadillo にインストールできます。
	または、initial_setup.desc と合わせて hawkbit_register を含んだ initial_setup.swu を作成します。

11.10.6. mkswu の desc ファイル

.desc ファイルを編集すると、いくつかのコマンドが使えます。

例

[ATDE ~/mkswu]$ tree /usr/share/mkswu/examples/nginx_start
/usr/share/mkswu/examples/nginx_start
└── etc
    └── atmark
        └── containers
            └── nginx.conf

[ATDE ~/mkswu]$ cat /usr/share/mkswu/examples/usb_container_nginx.desc
swdesc_option version=1

swdesc_usb_container "nginx_alpine.tar" 
swdesc_files --extra-os "nginx_start"

	nginx_alpine.tar ファイルに保存されたコンテナをインストールします。
	nginx_start ディレクトリの中身を転送します。

コマンドは書かれた順番でインストールされます。インストールするかどうかの判断はバージョンで行います:

swdesc_option component=<component>
swdesc_option version=<version>
か
swdesc_xxx --version <component> <version> [options]

<component>は以下のどれかにしてください (デフォルトでは .desc ファイルのファイル名を使います）
1. base_os: rootfs (Armadillo Base OS)を最初から書き込む時に使います。現在のファイルシステムは保存されていない。
  この場合、/etc/swupdate_preserve_filesに載ってるファイルのみをコピーして新しいbase OSを展開します。
  このcomponentがないと現在のrootfsのすべてがコピーされます。
2. extra_os.<文字列>: rootfsの変更を行う時に使います。<文字列> には任意の文字列を指定します。
  rootfsを変更を行う時に使います。 swdesc_* コマンドに --extra-os オプションを追加すると、 component に自動的に extra_os. を足します。
3. <文字列> (コンテナの名前などの任意の文字列）: rootfsの変更がないときに使います。
  このcomponentを使うとrootfsの変更ができませんのでご注意ください。
アップデートを行う際にこのバージョンと現在のバージョンを比べてアップデートの判断を行います。
<component> がまだインストールされてなかった時や <version> が上がる時にインストールします。
デフォルトではダウングレードはできませんが、 --install-if=different オプションを追加することで <version> が変わる際にインストール可能になります。
アップデートの一部をインストールすることもありますので、複数の component で管理し、いくつかの古いバージョンに対応するアップデートも作成可能です。

以下のコマンドから使ってください

swdesc_tar と swdesc_files でファイルを転送します。
```
swdesc_tar [--dest <dest>] <tar_file>
swdesc_files [--dest <dest>] [--basedir <basedir>] \
             <file> [<more files>]
```
swdesc_tar の場合、予め用意されてあるtarアーカイブをこのままデバイスで展開します。
--dest <dest> で展開先を選ぶことができます。デフォルトは / （--extra-os を含め、バージョンの component は base_os か extra_os.* の場合）か /var/app/rollback/volumes/ （それ以外のcomponent）。後者の場合は /var/app/volumes と /var/app/rollback/volumes 以外は書けないので必要な場合に --extra-os を使ってください。
swdesc_files の場合、mkswu がアーカイブを作ってくれますが同じ仕組みです。
--basedir <basedir> でアーカイブ内のパスをどこで切るかを決めます。
- 例えば、swdesc_files --extra-os --basedir /dir /dir/subdir/file ではデバイスに /subdir/file を作成します。
- デフォルトは <file> から設定されます。ディレクトリであればそのまま basedir として使います。それ以外であれば親ディレクトリを使います。
swdesc_command や swdesc_script でコマンドを実行する
```
swdesc_command <command> [<more commands>]
swdesc_script <script>
```
アップデート先の環境でコマンドやスクリプトファイルを走らせます。
バージョンの component は base_os と extra_os 以外の場合、 /var/app/volumes と /var/app/rollback/volumes 以外は変更できないのでご注意ください。
コマンドの実行が失敗した場合、アップデートも失敗します。
swdesc_exec でファイルを配ってコマンドでそのファイルを使う
```
swdesc_exec <file> <command>
```
swdesc_command と同じくコマンドを走らせますが、<file> を先に転送してコマンド内で"$1"として使えます。

swdesc_command_nochroot, swdesc_script_nochroot, swdesc_exec_nochroot で起動中のシステム上でコマンドを実行します。

このコマンドは nochroot なしのバージョンと同じ使い方で、現在起動中のシステムに変更や確認が必要な場合にのみ使用してください。

nochroot コマンドは確認を一切しないため、Armadillo が起動できない状態になる可能性もあります。充分にご注意ください。

例が必要な場合は /usr/share/mkswu/examples/firmware_update.desc を参考にしてください。

swdesc_embed_container, swdesc_usb_container, swdesc_pull_container で予め作成したコンテナを転送します。
```
swdesc_embed_container <container_archive>
swdesc_usb_container <container_archive>
swdesc_pull_container <container_url>
```
例は「コンテナの配布」を参考にしてください。
swdesc_boot で u-boot を更新します。
```
swdesc_boot <boot image>
```
このコマンドだけにバージョンは自動的に設定されます。

コマンドの他には、設定変数もあります。以下の設定は /home/atmark/mkswu/mkswu.conf に設定できます。

DESCRIPTION="<text>": イメージの説明、ログに残ります。
PRIVKEY=<path>, PUBKEY=<path>: 署名鍵と証明書
PRIVKEY_PASS=<val>: 鍵のパスワード（自動用）
openssl のPass Phraseをそのまま使いますので、pass:password, env:var や file:pathname のどれかを使えます。 pass や env の場合他のプロセスに見られる恐れがありますのでfileをおすすめします。
ENCRYPT_KEYFILE=<path>: 暗号化の鍵

以下のオプションも mkswu.conf に設定できますが、.descファイルにも設定可能です。swdesc_option で指定することで、誤った使い方した場合 mkswu の段階でエラーを出力しますので、必要な場合は使用してください。

swdesc_option CONTAINER_CLEAR: インストールされたあるコンテナと /etc/atmark/containers/*.conf をすべて削除します。
このオプションは簡単な初期化と考えてください。通常の運用では、不要になったイメージは自動的に削除されますのでこのオプションを設定する必要はありません。

以下のオプションは Armadillo 上の /etc/atmark/baseos.conf に、例えば MKSWU_POST_ACTION=xxx として設定することができます。

その場合に swu に設定されなければ /etc の設定で実行されますので、アットマークテクノが用意している Base OS のアップデートでも動作の変更は可能です。 swu に特定のオプションが設定された場合は設定されたオプションが優先されますので、一時的な変更も可能です。

swdesc_option POST_ACTION=container: コンテナのみのアップデート後に再起動を行いません。コンテナの中身だけをアップデートする場合、Armadillo-IoT ゲートウェイ A6Eを再起動せずにコンテナだけを再起動させます。
swdesc_option POST_ACTION=poweroff: アップデート後にシャットダウンを行います。
swdesc_option POST_ACTION=wait: アップデート後に自動的に再起動は行われず、次回起動時にアップデートが適用されます。
swdesc_option POST_ACTION=reboot: デフォルトの状態に戻します。アップデートの後に再起動します。
swdesc_option NOTIFY_STARTING_CMD="command", swdesc_option NOTIFY_SUCCESS_CMD="command", swdesc_option NOTIFY_FAIL_CMD="command": アップデートをインストール中、成功した場合と失敗した場合に実行されるコマンドです。
コマンドを実行する事で、アプリケーションやユーザーにアップデートを知らせることができます。
LEDで知らせる例を /usr/share/mkswu/examples/enable_notify_led.desc に用意してあります。

11.10.6.1. 例: sshdを有効にする

/usr/share/mkswu/examples/enable_sshd.desc を参考にします。

descファイルを編集する必要がありませんが自分の公開鍵を指定された場所に配置してください。

[ATDE ~/mkswu]$ cp -r /usr/share/mkswu/examples/enable_sshd* .
[ATDE ~/mkswu]$ cat enable_sshd.desc
swdesc_option component=extra_os.sshd version=1

# add your public key in enable_sshd/root/.ssh/authorized_keys
if [ -z "$SWDESC_TEST" ]; then
    grep -qE '^ssh-' enable_sshd/root/.ssh/authorized_keys \
        || error "Add your keys in enable_sshd/root/.ssh/authorized_keys"
fi
swdesc_files --dest /root enable_sshd/root 

swdesc_command "ssh-keygen -A" \ 
        "rc-update add sshd" 
[ATDE ~/mkswu]$ cp ~/.ssh/id_rsa.pub \
                         enable_sshd/root/.ssh/authorized_keys 
[ATDE ~/mkswu]$ mkswu enable_sshd.desc 
Enter pass phrase for /home/atmark/mkswu/swupdate.key:
enable_sshd.swu を作成しました。

	自分の公開鍵を転送します。デフォルトのオプションなので `enable_sshd/root` ディレクトリの中身をこのまま `/root` に転送されます。
	再起動する度に新しいサーバーの鍵が変わらないように、アップデートの時に一回作成します。
	サービスを有効にします。
	自分の公開鍵を指定された場所に配置します。
	イメージを作成します。パスワードは証明鍵のパスワードです。

11.10.6.2. 例: Armadillo Base OSアップデート

ここでは、「Armadilloのソフトウェアをビルドする」でメインシステム向けのビルドで作成したファイルを使用します。

/usr/share/mkswu/examples/OS_update.desc を参考にします。

[ATDE ~/mkswu]$ cp /usr/share/mkswu/examples/OS_update.desc update-[VERSION].desc
[ATDE ~/mkswu]$ vi update-[VERSION].desc
# uboot image can be generated with atmark imx-boot script
swdesc_uboot u-boot-dtb.imx 

# base OS is a tar that will be extracted on a blank filesystem,
# after copying just a few key config files.
#
# OS updates are only installed if version is greater than previous update
# so if you install your own updates atmark-techno provided Armadillo Base OS
# updates might not get installed
swdesc_tar "baseos-6e-[VERSION].tar.zst" \ 
           --version base_os [VERSION] 
[ATDE ~/mkswu]$ mkswu update-[VERSION].desc 
Enter pass phrase for /home/atmark/mkswu/swupdate.key:
update-[VERSION].swu を作成しました。

	「ブートローダーをビルドする」でビルドしたイメージを使います。
	build-rootfsでビルドしたイメージを使います。
	バージョンが上がるときにしかインストールされませんので、現在の/etc/sw-versionsを確認して適切に設定してください。
	イメージを作成します。パスワードは証明鍵の時のパスワードです。

11.10.6.3. 例: swupdate_preserve_files で Linux カーネル以外の Armadillo-IoT ゲートウェイ A6E 向けのイメージをインストールする方法

Armadillo-IoT ゲートウェイ A6E 向けのアップデートイメージに Linux カーネルが含まれています。

swupdate_preserve_files を使って、以下のコマンドでインストール後に現在のカーネルをコピーして更新させないようにします。

[armadillo ~]# echo 'POST /boot' >> /etc/swupdate_preserve_files
[armadillo ~]# echo 'POST /lib/modules' >> /etc/swupdate_preserve_files 
[armadillo ~]# persist_file /etc/swupdate_preserve_files

	`swupdate_preserve_files` に `/boot` と `/lib/modules` を保存するように追加します。
	変更した設定ファイルを保存します

/usr/share/mkswu/examples/kernel_update*.desc のように update_preserve_files.sh のヘルパーで、パスを自動的に /etc/swupdate_preserve_files に追加することができます。

[ATDE ~/mkswu]$ cat example.desc
swdesc_script "$SCRIPT_DIR/examples/update_preserve_files.sh" -- \ 
        "POST /boot" \
        "POST /lib/modules"

スクリプトの内容確認する場合は /usr/share/mkswu/examples/update_preserve_files.sh を参照してください。

Armadillo Base OS のカーネルを再び使用したい場合は同じスクリプトの --del オプションで行を削除することができます。

[ATDE ~/mkswu]$ cat example.desc
swdesc_script "$SCRIPT_DIR/examples/update_preserve_files.sh" -- \
        --del "POST /boot" "POST /lib/modules"

11.10.7. swupdate_preserve_files について

extra_os のアップデートで rootfs にファイルを配置することができますが、次の OS アップデートの際に削除される可能性があります。

デフォルトでは、 /etc/atmark と、 swupdate 、 sshd やネットワークの設定を保存しますがそれ以外はコピーされてません。

そうでないファイルを更新する際には /etc/swupdate_preserve_files に記載します。「例: swupdate_preserve_files で Linux カーネル以外の Armadillo-IoT ゲートウェイ A6E 向けのイメージをインストールする方法」を参考にしてください。

コピーのタイミングによって、以下のどれかを使用してください：

単にファイルを記載する
この場合、アップデートする前にファイルをコピーします。 baseos のイメージと同じ swu にアップデートしたいファイルを記載していても、このファイルが Armadillo Base OS に含まれないのであれば問題なくアップデートできます。
例: echo "/root/.profile" >> /etc/swupdate_preserve_files
POST のキーワードの後に記載する
この場合、アップデートの最後でコピーします。 Armadillo Base OS に含まれてるファイルであれば、インストール前にコピーしても保存されないのでコピーのタイミングをずらします。
そのコピーが最後に行われるので、同じアップデートでファイルの変更ができません。アップデートを別けて、 baseos のイメージをインストールしてからこのファイルを更新することができます。
例: echo "POST /etc/conf.d/podman-atmark" >> /etc/swupdate_preserve_files

11.10.8. SWU イメージの内容の確認

mkswu --show [file.swu] で SWU イメージの内容を確認することができます。

出力は desc ファイルに似ていますが、そのまま desc ファイルとして利用できませんので確認用としてお使いください。

[ATDE ~/mkswu]$ mkswu --show enable_sshd.swu
enable_sshd.swu

# built with mkswu 4.1

swdesc_files --dest /root enable_sshd/root
  --version extra_os.sshd 1
  (encrypted)

swdesc_command ssh-keygen -A && rc-update add sshd default
  --version extra_os.sshd 1

11.10.9. SWUpdate と暗号化について

mkswu --init の時に暗号化を有効にする場合は AES でファイルを暗号化します。

現在使われてる SWUpdate の暗号化はコマンドやメタデータを含む sw-description ファイルは暗号化されてません。そのため、通信の暗号化（HTTPSで送信するなど）を使うことを推奨します。

11.11. Armadillo Base OS の操作

Armadillo Base OS は Alpine Linux をベースとして作られています。

このセクションでは Armadillo Base OS の機能を紹介します。

11.11.1. アップデート

Armadillo Base OS は SWUpdate によってアップデートすることができます。

アップデートする際には、rootfs ファイルシステムにインストールされたファイルをすべて消して、アップデートの中身と /etc/swupdate_preserve_files に記載されているファイルで新しい rootfs を作ります。

アップデートでファイルを削除してしまった場合に abos-ctrl mount-old で前のシステムを read-only でマウントして、削除されたファイルをコピーすることもできます。

11.11.2. overlayfs と persist_file について

Armadillo BaseOS ではルートファイルシステムに overlayfs を採用しています。

そのため、ファイルを変更した後 Armadillo の電源を切ると変更内容は保持されません。開発中などに rootfs の変更内容を保持するには、変更したファイルに対して persist_file コマンドを使用します。

開発以外の時は安全のため、ソフトウェアアップデートによる更新を実行してください。アップデート手順に関しては「Armadilloのソフトウェアをアップデートする」を参照してください。

rootfs の内容を変更しても、ソフトウェアアップデートを実施した際に変更した内容が保持されない可能性があります。

persist_file コマンドの概要を図11.148「persist_file のヘルプ」に示します。

[armadillo ~]# persist_file -h
Usage: /usr/bin/persist_file [options] file [more files...]

Mode selection:
  (none) single entry copy
  -d, --delete   delete file
  -l, --list     list content of overlay
  -a, --apk      apk mode: pass any argument after that to apk on rootfs
  -R, --revert   revert change: only delete from overlay, making it
                 look like the file was reverted back to original state

Copy options:
  -r, --recurse  recursive copy (note this also removes files!)
  -p, --preserve make the copy persist through baseos upgrade
                 by adding entries to /etc/swupdate_preserve_files
  -P, --preserve-post   same, but copy after upgrade (POST)

Delete options:
  -r, --recurse  recursively delete files

Common options:
  -v, --verbose  verbose mode for all underlying commands

Note this directly manipulates overlayfs lower directories
so might need a reboot to take effect

図11.148 persist_file のヘルプ

ファイルの保存・削除手順例

[armadillo ~]# echo test > test
[armadillo ~]# persist_file -rv /root
'/root/test' -> '/mnt/root/test' 
'/root/.ash_history' -> '/mnt/root/.ash_history'
[armadillo ~]# rm -f test
[armadillo ~]# persist_file -rv /root
removed '/mnt/root/test' 
removed '/mnt/root/.ash_history' 
'/root/.ash_history' -> '/mnt/root/.ash_history'

図11.149 persist_file 保存・削除手順例

	追加・変更したファイルを rootfs へコピーします。
	-r を指定すると、ひとつ前の rm -f コマンドで削除したファイルがrootfsからも削除されますのでご注意ください。
	すでに rootfs に存在するファイルも一度削除してからコピーするため、このようなメッセージが表示されます。

ソフトウェアアップデート後も変更を維持する手順例
```
[armadillo ~]# vi /etc/conf.d/podman-atmark 
[armadillo ~]# persist_file -P /etc/conf.d/podman-atmark 
[armadillo ~]# tail -n 2 /etc/swupdate_preserve_files 
# persist_file 20211216
POST /etc/conf.d/podman-atmark
```
図11.150 persist_file ソフトウェアアップデート後も変更を維持する手順例
何らかのファイルの内容を変更します。

-P オプションを付与して persist_file を実行します。

swupdate_preserve_files に追加されたことを確認します。

変更ファイルの一覧表示例

[armadillo ~]# mkdir dir
[armadillo ~]# persist_file -l
directory          /
directory          /root
opaque directory   /root/dir 
whiteout           /root/test 
regular file       /root/.ash_history
directory          /etc
regular file       /etc/resolv.conf
directory          /var
symbolic link      /var/lock
: (省略)

図11.151 persist_file 変更ファイルの一覧表示例

	rootfs のファイルを見せないディレクトリは `opaque directory` と表示されます。
	削除したファイルは `whiteout` と表示されます。

パッケージをインストールする時はapkコマンドを使用してメモリ上にインストールできますが、 persist_file コマンドで rootfs に直接インストールすることも可能です。

[armadillo ~]# persist_file -a add strace
(1/3) Installing fts (1.2.7-r1)
(2/3) Installing libelf (0.185-r0)
(3/3) Installing strace (5.14-r0)
Executing busybox-1.34.1-r3.trigger
OK: 251 MiB in 188 packages
Install succeeded, but might not work in the running system
Please reboot if installed program does not work 
[armadillo ~]# strace ls
: (省略)
exit_group(0)                           = ?
+++ exited with 0 +++

図11.152 persist_file でのパッケージインストール手順例

この例では Armadillo を再起動せずにインストールしたコマンドを使用できましたが、Armadillo の再起動が必要となるパッケージもありますので、その場合は Armadillo を再起動してください。

11.11.3. ロールバック状態の確認

Armadillo Base OS のルートファイルシステムが壊れて起動できなくなった場合に自動的に前のバージョンで再起動します。

自分で確認する必要がある場合に abos-ctrl status でロールバックされてるかどうかの確認ができます。

必要な場合（例えば、自分のアプリケーションがアップデート直後に問題があった場合）、 abos-ctrl rollback で手動のロールバックも可能です。ロールバックにエラーがなければ、再起動してロールバックを完了します。

なお、/var/at-log/atlog に切り替えの際に必ずログを書きますので、調査の時に使ってください。

[armadillo ~]# cat /var/at-log/atlog
Mar 17 14:51:35 armadillo NOTICE swupdate: Installed update to /dev/mmcblk0p2: \
extra_os.sshd: unset -> 1, extra_os.initial_setup: unset -> 1
Mar 17 16:48:52 armadillo NOTICE swupdate: Installed update to /dev/mmcblk0p1: \
boot: 2020.04-at5 -> 2020.04-at6, base_os: 3.15.0-at.3 -> 3.15.0-at.4
Mar 17 17:42:15 armadillo NOTICE swupdate: Installed update to /dev/mmcblk0p2: \
other_boot: 2020.04-at5 -> 2020.04-at6, container: unset -> 1, extra_os.container: unset -> 1

図11.153 /var/at-log/atlog の内容の例

11.11.4. ボタンやキーを扱う

buttond サービスを使用することで、ボタンやキー入力をトリガーとする処理を簡単に実装できます。

/etc/atmark/buttond.conf に BUTTOND_ARGS を指定することで、動作を指定することができます:

--short <key> --action "command" : 短押しの設定。キーを 1 秒以内に離せば短押しと認識し "command"を実行します。認識する最大時間は --time <time_ms> オプションで変更可能です。
--long <key> --action "command" : 長押しの設定。キーを 5 秒押し続けたタイミングで "command" を実行します。長押しと認識する最低時間は --time <time_ms> オプションで変更可能です。
1 つのキーに対して複数の設定が可能です。長押しの設定が複数ある場合、押したままの状態だと一番長い時間に設定されている "command" を実行します。途中でキーを離した場合は、キーを離した時間に応じた "command" を実行します。(例：buttond --short <key> --action "cmd1" --long <key> --time 2000 --action "cmd2" --long <key> --time 10000 --action "cmd3" <file> を実行した場合、1 秒以内に離すと "cmd1"、2 秒以上 10 秒以内に離すと "cmd2"、10 秒を越えたら "cmd3" を実行します)。
- 短押し設定を複数指定する場合、時間の短い設定を先に指定してください。 0.5秒、1 秒を設定したい場合、1 秒 → 0.5 秒の順番で指定すると 0.5秒が無視されます。
--exit-timeout <time_ms> : 設定した時間の後に buttond を停止します。起動時のみに対応したい場合に使えます。
キーの設定の --exit-after オプション : キーのコマンドを実行した後に buttond を停止します。キーの対応を一回しか実行しないように使えます。

11.11.4.1. SW1 の短押しと長押しの対応

以下にデフォルトを維持したままで SW1 の短押しと長押しにそれぞれの場合にコマンドを実行させます。

[armadillo ~]# vi /etc/atmark/buttond.conf 
BUTTOND_ARGS="$BUTTOND_ARGS --short prog1 --action 'date >> /tmp/shortpress'"
BUTTOND_ARGS="$BUTTOND_ARGS --long prog1 --time 5000 --action 'date >> /tmp/longpress'"
[armadillo ~]# persist_file /etc/atmark/buttond.conf 
[armadillo ~]# rc-service buttond restart 
buttond          | * Stopping button watching daemon ...                                         [ ok ]
buttond          | * Starting button watching daemon ...                                         [ ok ]
[armadillo ~]# cat /tmp/shortpress 
Tue Mar 22 17:16:42 JST 2022
Tue Mar 22 17:16:43 JST 2022
[armadillo ~]# cat /tmp/longpress
Tue Mar 22 17:16:48 JST 2022

図11.154 buttond で SW1 を扱う

	buttond の設定ファイルを編集します。この例では、短押しの場合 /tmp/shotpress に、5 秒以上の長押しの場合 /tmp/longpress に日付を出力します。
	設定ファイルを保存します。
	`buttond` サービスを再起動させます。ここでは再起動後短押しを 2 回、長押しを 1 回行ったとします。
	押された回数を確認します。

11.11.4.2. USB キーボードの対応

USB キーボードや他の入力デバイスにも対応できます。

デバイスを接続してから、 buttond でデバイス名とキーコードを確認します。

[armadillo ~]# buttond -vvv /dev/input/* /dev/input/by-*/* 
Skipping directory /dev/input/by-id
Skipping directory /dev/input/by-path
[78972.042] /dev/input/event2 4 4 458976: non-keyboard event ignored
[78972.042] /dev/input/event2 LEFTCTRL (29) pressed: ignored 
[78972.042] /dev/input/by-id/usb-0566_3029-event-kbd 4 4 458976: non-keyboard event ignored
[78972.042] /dev/input/by-id/usb-0566_3029-event-kbd LEFTCTRL (29) pressed: ignored
[78972.042] /dev/input/by-path/platform-xhci-hcd.1.auto-usb-0:1:1.0-event-kbd 4 4 458976: non-keyboard event ignored
[78972.042] /dev/input/by-path/platform-xhci-hcd.1.auto-usb-0:1:1.0-event-kbd LEFTCTRL (29) pressed: ignored
[78972.130] /dev/input/event2 4 4 458976: non-keyboard event ignored
[78972.130] /dev/input/event2 LEFTCTRL (29) released: ignored
[78972.130] /dev/input/by-id/usb-0566_3029-event-kbd 4 4 458976: non-keyboard event ignored
[78972.130] /dev/input/by-id/usb-0566_3029-event-kbd LEFTCTRL (29) released: ignored
[78972.130] /dev/input/by-path/platform-xhci-hcd.1.auto-usb-0:1:1.0-event-kbd 4 4 458976: non-keyboard event ignored
[78972.130] /dev/input/by-path/platform-xhci-hcd.1.auto-usb-0:1:1.0-event-kbd LEFTCTRL (29) released: ignored

図11.155 buttond で USB キーボードのイベントを確認する

	`buttond` を `-vvv` で冗長出力にして、すべてのデバイスを指定します。
	希望のキーを押すと、`LEFTCTRL` が三つのパスで認識されました。一番安定する `by-id` のパスを控えておきます。

USB デバイスを外すこともありますので、-i (inotify) で管理されてる入力デバイスとして追加します。そうしないとデバイスを外したときにbuttondが停止します。

[armadillo ~]# vi /etc/atmark/buttond.conf
BUTTOND_ARGS="$BUTTOND_ARGS -i /dev/input/by-id/usb-0566_3029-event-kbd"
BUTTOND_ARGS="$BUTTOND_ARGS --short LEFTCTRL --action 'podman_start button_pressed_container'"
[armadillo ~]# persist_file /etc/atmark/buttond.conf
[armadillo ~]# rc-service buttond restart

図11.156 buttond で USB キーボードを扱う

11.11.4.3. Armadillo 起動時にのみボタンに反応する方法

Armadillo 起動時にのみ、例として SW1 の長押しに反応する方法を紹介します。

/etc/local.d/boot_switch.start に稼働期間を指定した buttond を起動させる設定を記載します。

buttond が起動してから 10秒以内に SW1 を一秒以上長押しすると myapp のコンテナの親プロセスに USR1 信号を送ります（アプリケーション側で信号を受信して、デバッグモードなどに切り替える想定です）。 SW1 が Armadillo 起動前に押された場合は、buttond の起動一秒後に実行されます。

[armadillo ~]# vi /etc/local.d/boot_switch.start
#!/bin/sh

buttond /dev/input/by-path/platform-gpio-keys-event \ 
        --exit-timeout 10000 \ 
        --long PROG1 --time 1000 --exit-after \ 
                --action "podman exec myapp kill -USR1 1" & 
[armadillo ~]# chmod +x /etc/local.d/boot_switch.start
[armadillo ~]# persist_file /etc/local.d/boot_switch.start

図11.157 buttond で SW1 を Armadillo 起動時のみ受け付ける設定例

	SW1 の入力を `/dev/input/by-path/platform-gpio-keys-event` ファイルの `PROG1` として認識できます。
	buttond 起動後 10 秒経過すると終了します。
	SW1 を一度検知した後すぐに終了します。
	サービスとして動作させる必要がないため `&` を付けてバックグラウンド起動します。

11.11.5. Armadillo Base OS 側の起動スクリプト

起動時に何かスクリプトを走らせるためにはコンテナとして実行することを推奨します。「コンテナの自動起動」を参照してください。

コンテナで実行不可能な場合に、「local」サービスを使うことができます: /etc/local.d ディレクトリに .start ファイルを置いておくと起動時に実行されて、 .stop ファイルは終了時に実行されます。

[armadillo ~]# vi /etc/local.d/date_test.start 
#!/bin/sh

date > /tmp/boottest
[armadillo ~]# chmod +x /etc/local.d/date_test.start 
[armadillo ~]# persist_file /etc/local.d/date_test.start 
[armadillo ~]# reboot
: (省略)
[armadillo ~]# cat /tmp/boottest 
Tue Mar 22 16:36:12 JST 2022

図11.158 local サービスの実行例

	スクリプトを作ります。
	スクリプトを実行可能にします。
	スクリプトを保存して、再起動します。
	実行されたことを確認します。

11.11.6. u-boot の環境変数の設定

u-boot の環境変数を変更するには /boot/uboot_env.d/ ディレクトリに環境変数が書かれた設定ファイルを配置します。

ファイルの構文は fw_setenv が扱うことができるもので、以下のとおりです：

# で始まる行はコメントと扱われる為、無視されます。また、環境変数への代入を示す = がない場合も無視されます。
[変数]=[値] で変数を設定します。スペースや引用符を含め他の文字は有効ですので、変数の名前と値に不要な文字を入れないように注意してください。
[変数]= で変数を消します。値がない場合に変数が消去されます。

このファイルによるアップデート内容は swupdate でアップデートする際に適用されます。

実行中のシステムに影響がありませんので、設定ファイルを swupdate で転送しない場合はファイル永続化後に fw_setenv -s /boot/uboot_env.d/[ファイル名] で変数を書き込んでください。

swupdate でファイルを転送した場合には、変数はすぐに利用されます。

[armadillo ~]# vi /boot/uboot_env.d/no_prompt 
# bootdelay を -2 に設定することで u-boot のプロンプトを無効化します
bootdelay=-2
[armadillo ~]# persist_file -v /boot/uboot_env.d/no_prompt 
'/boot/uboot_env.d/no_prompt' -> '/mnt/boot/uboot_env.d/no_prompt'
[armadillo ~]# fw_setenv -s /boot/uboot_env.d/no_prompt 
Environment OK, copy 0
[armadillo ~]# fw_printenv | grep bootdelay 
bootdelay=-2

図11.159 uboot_env.d のコンフィグファイルの例

	コンフィグファイルを生成します。
	ファイルを永続化します。
	変数を書き込みます。
	書き込んだ変数を確認します。

mkswu バージョン 4.4 以降が必要です。必要な場合はアップデートしてください。

[ATDE ~]$ sudo apt update && sudo apt upgrade

書き方は、 /usr/share/mkswu/examples/uboot_env.desc を参考にしてください。

「ブートローダーをビルドする」の際に u-boot のデフォルトを変更した場合や、u-boot のプロンプトで「setenv」や「saveenv」を実行しても、 /boot/uboot_env.d/00_defaults によって変更がアップデートの際にリセットされます。

00_defaults のファイルは Base OS の一部で更新されることもありますので、変更を望む場合は別のファイルを作って設定してください。ファイルはアルファベット順で処理されます。 00_defaults にある変数を後のファイルにも設定した場合はそのファイルの値だけが残ります。

11.11.7. Network Time Protocol (NTP, ネットワーク・タイム・プロトコル)

Armadillo Base OS では chronyd を使っています。

デフォルトの設定（使用するサーバーなど）は /etc/chrony/conf.d/ にあり、変更用に /etc/atmark/chrony.conf.d/ のファイルも読み込みます。 /etc/atmark/chrony.conf.d ディレクトリに /etc/chrony/conf.d/ と同じファイル名の設定ファイルを置いておくことで、デフォルトのファイルを読まないようになります。

例えば、 NTP サーバーの設定は servers.conf に記載されてますので、変更する際はに /etc/atmark/chrony.conf.d/servers.conf のファイルに記載します：

[armadillo ~]# vi /etc/atmark/chrony.conf.d/servers.conf 
pool my.ntp.server iburst
[armadillo ~]# persist_file /etc/atmark/chrony.conf.d/servers.conf 
[armadillo ~]# rc-service chronyd restart 
chronyd          | * Stopping chronyd ... [ ok ]
chronyd          | * Starting chronyd ... [ ok ]
armadillo:~# chronyc sources 
MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
^? my.ntp.server                 1   6     3     2    +88ms[  +88ms] +/-  173ms

図11.160 chronyd のコンフィグの変更例

	コンフィグファイルを作ります。
	ファイルを保存します
	chronyd サービスを再起動します。
	chronyc で新しいサーバーが使用されていることを確認します。

11.12. Device Treeをカスタマイズする

at-dtweb を利用して Device Tree をカスタマイズする方法を説明します。at-dtweb では、 Web ブラウザ上のマウス操作で dtbo ファイルおよび desc ファイルを生成することができます。カスタマイズの対象は拡張インターフェース(CON8)です。

11.12.1. at-dtweb のインストール

ATDE9 に at-dtweb パッケージをインストールします。

[ATDE ~]$ sudo apt update
[ATDE ~]$ sudo apt install at-dtweb

インストール済みの場合は、以下のコマンドを実行し最新版への更新を行ってください。

[ATDE ~]$ sudo apt update
[ATDE ~]$ sudo apt upgrade

11.12.2. at-dtweb の起動

at-dtweb の起動開始
at-dtweb の起動を開始するには、デスクトップ左上のアプリケーションの「システムツール」から「at-dtweb」を選択してください。
図11.161 at-dtweb の起動開始

コマンドライン上からでも、at-dtweb コマンドで起動できます。

[ATDE ~]$ at-dtweb

ボードの選択
ボードを選択します。Armadillo-IoT_A6E を選択して、「OK」をクリックします。
図11.162 ボード選択画面
Linux カーネルディレクトリの選択
Linux カーネルディレクトリを選択します。コンフィギュレーション済みの Linux カーネルディレクトリを選択して、「OK」をクリックします。
図11.163 Linux カーネルディレクトリ選択画面
at-dtweb の起動完了
at-dtweb が起動し、次のように画面が表示されます。
図11.164 at-dtweb 起動画面


	Linux カーネルは、事前にコンフィギュレーションされている必要があります。コンフィギュレーションの手順については「Armadilloのソフトウェアをビルドする」を参照してください。

11.12.3. Device Tree をカスタマイズ

11.12.3.1. 機能の選択

機能の選択は、ドラッグ&ドロップで行います。画面左上の「Available features」から有効にしたい機能をドラッグし、画面右側の「Armadillo-IoT Gateway A6E」の白色に変化したピンにドロップします。例として CON８ 8/９ピンを UART１(RXD/TXD) に設定します。


	何も機能が選択されていないピンには GPIO の機能が割り当てられます。

図11.165 UART1(RXD/TXD) のドラッグ

図11.166 CON8 8/9 ピンへのドロップ

11.12.3.2. 信号名の確認

画面右側の「Armadillo-IoT Gateway A6E」にドロップして設定したピンを左クリックすると信号名が表示されます。どのピンがどの信号に対応しているのかを確認することができます。

例として UART1(RXD/TXD) の信号名を確認します。

図11.167 信号名の確認


	再度ピンを左クリックすると機能名の表示に戻ります。

11.12.3.3. プロパティの設定

いくつかの機能にプロパティを設定することができます。画面右側の「Armadillo-IoT Gateway A6E」に選択した機能を左クリックすると、画面左下の「Properties」からプロパティを選択することができます。

例としてCON8 29-32 ピンの ECSPI1 の spi-max-frequency プロパティを設定します。

図11.168 プロパティの設定

設定したプロパティを確定させるには「Apply」をクリックします。

図11.169 プロパティの保存

11.12.3.4. 機能の削除

全ての機能を削除する場合は、画面右上の「Reset configuration」をクリックします。機能ごとに削除する場合は、画面右側の「Armadillo-IoT Gateway A6E」のピンを右クリックして「Remove」をクリックします。

図11.170 全ての機能の削除

images/at-dtweb-remove-configuration.png

図11.171 ECSPI1 の削除

11.12.3.5. dtbo/desc の生成

dtbo ファイルおよび desc ファイルを生成するには、画面右上の「Save」をクリックします。

図11.172 dtbo/desc ファイルの生成

以下の画面ようなメッセージが表示されると、dtbo ファイルおよび desc ファイルの生成は完了です。

図11.173 dtbo/desc の生成完了

ビルドが終了すると、ホームディレクトリ下の mkswu/at-dtweb-Armadillo-IoT_A6E/ ディレクトリに、DTS overlays ファイル(dtboファイル)と desc ファイルが生成されます。 Armadillo-IoT ゲートウェイ A6E 本体に書き込む場合は、mkswu コマンドで desc ファイルから SWU イメージを生成してアップデートしてください。

[ATDE ~]$ ls ~/mkswu/at-dtweb-Armadillo-IoT_A6E/
armadillo-iotg-a6e-at-dtweb.dtbo  update_overlays.sh
at-dtweb.desc                     update_preserve_files.sh
[ATDE ~]$ cd ~/mkswu/at-dtweb-Armadillo-IoT_A6E/
[ATDE ~/mkswu/at-dtweb-Armadillo-IoT_A6E]$ mkswu at-dtweb.desc 
Enter pass phrase for /home/atmark/mkswu/swupdate.key:
at-dtweb.swu を作成しました。

SWU イメージを生成します。

SWU イメージを使ったアップデートの詳細は「Armadilloのソフトウェアをアップデートする」を参照してください。

11.12.4. DTS overlays によるカスタマイズ

Device Treeは「DTS overlay」(dtbo) を使用することでも変更できます。

DTS overlay を使用することで、通常の dts の更新が自動的に入りつづける状態で dts の変更でしかできない設定を行うことができます。

/boot/overlays.txt に fdt_overlays を dtbo 名で設定することで、 u-bootが起動時にその DTS overlay を通常の dtb と結合して起動します。

複数の DTS overlay を使う場合は以下の例のようにスペースで別けたファイル名を記載することができます。

[armadillo ~]# ls /boot/ 
armadillo-iotg-a6e-at-dtweb.dtbo  armadillo-iotg-a6e.dtb  uImage
armadillo-iotg-a6e-ems31.dtbo     armadillo.dtb           uboot_env.d
armadillo-iotg-a6e-lwb5plus.dtbo  overlays.txt

[armadillo ~]# persist_file /boot/armadillo-iotg-a6e-at-dtweb.dtbo 
[  441.860885] EXT4-fs (mmcblk0p1): re-mounted. Opts: (null)

[armadillo ~]# vi /boot/overlays.txt 
fdt_overlays=armadillo-iotg-a6e-ems31.dtbo armadillo-iotg-a6e-at-dtweb.dtbo

[armadillo ~]# persist_file -vp /boot/overlays.txt 
'/boot/overlays.txt' -> '/mnt/boot/overlays.txt'
Added "/boot/overlays.txt" to /etc/swupdate_preserve_files

[armadillo ~]# reboot 
: (省略)
Applying fdt overlay: armadillo-iotg-a6e-ems31.dtbo 
Applying fdt overlay: armadillo-iotg-a6e-at-dtweb.dtbo
: (省略)

図11.174 /boot/overlays.txt の変更例

	at-dtweb で作成した dtbo ファイルを USB メモリや microSD カード等の外部記憶装置を用いて転送し、 /boot/ ディレクトリ下に配置します。
	配置した dtbo ファイルを保存します。
	`/boot/overlays.txt` ファイルに「armadillo-iotg-a6e-at-dtweb.dtbo」を追加します。ファイルが存在しない場合は新規に作成してください。このファイルの詳細については「DTS overlays によるカスタマイズ」を参照してください。
	`/boot/overlays.txt` を保存し、アップデートの場合でも保存します。
	overlay の実行のために再起動します。
	シリアルコンソールの場合に、u-bootによるメッセージを確認できます。

11.12.4.1. 提供している DTS overlay

以下の DTS overlay を用意しています：

armadillo-iotg-a6e-els31.dtbo: LTE Cat.1 モジュール搭載モデルで自動的に使用します。
armadillo-iotg-a6e-ems31.dtbo: LTE Cat.M1 モジュール搭載モデルで自動的に使用します。
armadillo-iotg-a6e-lwb5plus.dtbo: WLAN+BT コンボモジュール搭載モデルで自動的に使用します。
armadillo-iotg-a6e-stdwn-ind-do1.dtbo: /boot/overlays.txt に記載することで使用できます。使用方法は「電源を安全に切るタイミングを通知する」を参照ください。
armadillo-iotg-a6e-stdwn-ind-con8-pin7.dtbo: /boot/overlays.txt に記載することで使用できます。使用方法は「電源を安全に切るタイミングを通知する」を参照ください。

11.13. eMMC のデータリテンション

eMMC は主に NAND Flash メモリから構成されるデバイスです。NAND Flash メモリには書き込みしてから1年から3年程度の長期間データが読み出されないと電荷が抜けてしまう可能性があります。その際、電荷が抜けて正しくデータが読めない場合は、eMMC 内部で ECC (Error Correcting Code) を利用してデータを訂正します。しかし、訂正ができないほどにデータが化けてしまう場合もあります。そのため、一度書いてから長期間利用しない、高温の環境で利用するなどのケースでは、データ保持期間内に電荷の補充が必要になります。電荷の補充にはデータの読み出し処理を実行し、このデータの読み出し処理をデータリテンションと呼びます。

Armadillo-IoT ゲートウェイ A6Eに搭載のeMMCは、eMMC自身にデータリテンション機能が備わっており、A6Eに電源が接続されてeMMCに電源供給されている状態で、eMMC内部でデータリテンション処理が自動実行されます。

11.14. SMS を利用する (Cat.1/Cat.M1 モデル)

Armadillo-IoT ゲートウェイ A6E は、LTE モジュールを使用した SMS の送受信を行うことができます。 SMS の送信、受信した SMS の確認および削除などの操作は ModemManager の mmcli コマンドで行うことができます。

本章では mmcli コマンドでの SMS の使用方法について説明します。

11.14.1. 初期設定

SMS が利用可能な SIM を挿入して Armadillo-IoT ゲートウェイ A6E の電源を入れると、 ModemManager が必要な初期設定を行い、 SMS が利用可能になります。

SMS の受信は自動的に行われます。

図11.175「言語設定」に示すコマンドを実行し、言語設定を行います。

[armadillo ~]# export LANG="ja_JP.UTF-8"

図11.175 言語設定

11.14.2. SMS を送信する

SMS を作成するには、図11.176「SMS の作成」に示すコマンドを実行します。

[armadillo ~]# mmcli -m 0 --messaging-create-sms="number=[送信先電話番号],text='[SMS 本文]'"

図11.176 SMS の作成

SMSの作成に成功すると、以下のようにSMS番号が表示されます。SMS番号は送信時に使用します。

Successfully created new SMS: /org/freedesktop/ModemManager1/SMS/[SMS 番号]

図11.177 SMS 番号の確認

図11.178「SMS の送信」に示すコマンドを実行し、SMS 送信を行います。 [SMS番号] には、 SMS の作成時に表示された番号を指定します。

[armadillo ~]# mmcli -s [SMS 番号] --send

図11.178 SMS の送信

11.14.3. SMS を受信する

SMS を送信可能な端末から Armadillo-IoT ゲートウェイ A6E に SMS を送信すると、 Armadillo-IoT ゲートウェイ A6E は自動的に SMS を受信します。

また、 ELS31-J/EMS31-J の内蔵ストレージに 10 件 SMS を保存した状態で Armadillo-IoT ゲートウェイ A6E に SMS を送信した場合は、Armadillo-IoT ゲートウェイ A6E は受信を行いません。

受信を行うには、 ELS31-J/EMS31-J の内蔵ストレージに保存している SMS を削除するか、他のストレージに移動する必要があります。

11.14.4. SMS 一覧を表示する

図11.179「SMS の一覧表示」のコマンドを実行することで、 SMS 一覧を表示できます。

末尾が "(sent)" となっているものが送信した SMS で "(received)" となっているものが受信した SMS です。

[armadillo ~]# mmcli -m 0 --messaging-list-sms
Found 7 SMS messages:
         /org/freedesktop/ModemManager1/SMS/0 (received)
         /org/freedesktop/ModemManager1/SMS/1 (received)
         /org/freedesktop/ModemManager1/SMS/2 (received)
         /org/freedesktop/ModemManager1/SMS/3 (received)
         /org/freedesktop/ModemManager1/SMS/4 (sent)
         /org/freedesktop/ModemManager1/SMS/5 (received)
         /org/freedesktop/ModemManager1/SMS/6 (sent)

図11.179 SMS の一覧表示

11.14.5. SMS の内容を表示する

SMS の内容を表示するには、図11.180「SMSの内容を表示」に示すコマンドを実行します。

[armadillo ~]# mmcli -s [SMS 番号]
  ----------------------------------
  Content    |              number: XXXXXXXXXXX
             |                text: hello world
  ----------------------------------
  Properties |            PDU type: deliver
             |               state: received
             |             storage: me
             |                smsc: +XXXXXXXXXXXX
             |           timestamp: XXXXXXXXXXXX+XX

図11.180 SMSの内容を表示

受信した SMS は自動的に LTE モジュールの内蔵ストレージに保存されます。Armadillo-IoT ゲートウェイ A6E に搭載されている、 ELS31-J/EMS31-J は、最大 10 件まで SMS を保存することが可能です。

SMS の内容を表示した際の「storage: me」は、 LTE モジュールの内蔵ストレージに SMS が保存されていることを意味しています。

「storage: sm」と表示された場合、 SIM カードのストレージに SMS が保存されています。 SIM カードのストレージに保存できる SMS の件数は SIM カードによって異なります。

ストレージに保存されている SMS は、Armadillo-IoT ゲートウェイ A6E の電源を切断してもデータが保持されます。

11.14.6. SMS を削除する

SMS を削除するには、図11.181「SMSの削除」に示すコマンドを実行します。

[armadillo ~]# mmcli -m 0 --messaging-delete-sms=[SMS 番号]

図11.181 SMSの削除

11.14.7. SMS を他のストレージに移動する

SIM カードのストレージに SMS を移動するには、図11.182「SIM カードのストレージに SMS を移動」に示すコマンドを実行します。

[armadillo ~]# mmcli -s [SMS 番号] --store-in-storage="sm"

図11.182 SIM カードのストレージに SMS を移動

LTE モジュールの内蔵ストレージに SMS を移動するには、図11.183「LTE モジュールの内蔵ストレージに SMS を移動」に示すコマンドを実行します。

[armadillo ~]# mmcli -s [SMS 番号] --store-in-storage="me"

図11.183 LTE モジュールの内蔵ストレージに SMS を移動

11.15. 動作中の Armadillo の温度を測定する

この章では、Armadillo Base OS 搭載製品を組み込んだユーザー製品の熱設計時に役立つ温度プロファイラツールである「atmark-thermal-profiler」について紹介します。

11.15.1. 温度測定の重要性

Armadillo は製品ごとに動作温度範囲が設定されていますが、それらはあくまでも標準筐体に放熱材と共に取り付けて使用した場合の目安であり、実運用時には自作の筐体の使用や放熱の有無などで記載のスペック通りにならない場合があります。また、 Armadillo には CPU または SoC が特定の温度以上になると、自動的にシャットダウンするサーマルシャットダウン機能が搭載されています。そのため、現実的には Armadillo を組み込んだ製品を運用時と同等の環境で動作させつつ、実際に温度を計測して実運用時の CPU 及び SoC 温度がどの程度まで上がるか、サーマルシャットダウンは起こらないかを確かめる必要があります。

Armadillo Base OS 搭載製品では、動作中の Armadillo の各種温度等を取得しCSV形式で出力する atmark-thermal-profiler を利用することができますので、温度測定に役立てることができます。

11.15.2. atmark-thermal-profiler をインストールする

atmark-thermal-profiler は apk パッケージで公開されていますので、apk add コマンドでインストールすることが可能です。

[armadillo ~]# apk upgrade
[armadillo ~]# apk add atmark-thermal-profiler

図11.184 atmark-thermal-profiler をインストールする

atmark-thermal-profiler はデバッグ(開発)用途で温度情報を収集及び解析するツールです。 atmark-thermal-profiler は、他の apk パッケージと同様に persist_file -a コマンドで永続的にインストールしておくことが可能ですが、ログの保存のために Armadillo が起動している間 eMMC への書き込みを続けるので、 Armadillo を組み込んだ製品の運用時に動かしたままにしておくことは推奨しません。

atmark-thermal-profiler を永続的にインストールする場合は、運用時には必ず削除してください。

11.15.3. atmark-thermal-profiler を実行・停止する

図11.185「atmark-thermal-profiler を実行する」に示すコマンドを実行することで、 atmark-thermal-profiler が動作を開始します。

[armadillo ~]# rc-service atmark-thermal-profiler start

図11.185 atmark-thermal-profiler を実行する

図11.186「atmark-thermal-profiler を停止する」に示すコマンドを実行することで、 atmark-thermal-profiler が動作を停止します。

[armadillo ~]# rc-service atmark-thermal-profiler stop

図11.186 atmark-thermal-profiler を停止する

11.15.4. atmark-thermal-profiler が出力するログファイルを確認する

atmark-thermal-profiler は、インストール直後から自動的に温度やCPU負荷率、Load Averageなどの情報を30秒に1度の周期で集め、/var/log/thermal_profile.csvに追記していきます。

[armadillo ~]# head /var/log/thermal_profile.csv
DATE,ONESHOT,CPU_TMEP,SOC_TEMP,LOAD_AVE,CPU_1,CPU_2,CPU_3,CPU_4,CPU_5,USE_1,USE_2,USE_3,USE_4,USE_5
2022-11-30T11:11:05+09:00,0,54,57,0.24,/usr/sbin/rngd -b -p /run/rngd.pid -q -O jitter:buffer_size:4133 -O jitter:refill_thresh:4133 -O jitter:thread_count:1,/usr/sbin/chronyd -f /etc/chrony/chrony.conf,[kworker/1:3H-kb],podman network inspect podman,/usr/sbin/NetworkManager -n,22,2,2,0,0,
: (省略)

図11.187 ログファイルの内容例

thermal_profile.csv の1行目はヘッダ行です。各列についての説明を表11.27「thermal_profile.csvの各列の説明」に記載します。

表11.27 thermal_profile.csvの各列の説明

ヘッダ	説明
DATE	その行のデータ取得日時です。 "年-月-日T時:分:秒+タイムゾーン" の形式で出力されます。
ONESHOT	この列が1の行のデータは、サーマルシャットダウンを含むシャットダウンが実行された時に取得されたことを示します。
CPU_TEMP	計測時点の CPU 温度を示します。単位は℃です。
SOC_TEMP	計測時点の SoC 温度を示します。単位は℃です。製品よっては非対応で、その場合は空白になります。
LOAD_AVE	計測時点から直近1分間のLoad Averageです。
CPU_1	計測時点のCPU使用率1位のプロセスです。
CPU_2	計測時点のCPU使用率2位のプロセスです。
CPU_3	計測時点のCPU使用率3位のプロセスです。
CPU_4	計測時点のCPU使用率4位のプロセスです。
CPU_5	計測時点のCPU使用率5位のプロセスです。
USE_1	計測時点のCPU使用率1位のプロセスのCPU使用率です。
USE_2	計測時点のCPU使用率2位のプロセスのCPU使用率です。
USE_3	計測時点のCPU使用率3位のプロセスのCPU使用率です。
USE_4	計測時点のCPU使用率4位のプロセスのCPU使用率です。
USE_5	計測時点のCPU使用率5位のプロセスのCPU使用率です。

11.15.5. 温度測定結果の分析

atmark-thermal-profiler を使用して得られたログファイルの内容を分析してみます。

11.15.5.1. サーマルシャットダウン温度の確認

予め、使用している Armadillo が何℃でサーマルシャットダウンするか確認しておきます。ここでは、 Armadillo Base OS を搭載している Armadillo-IoT ゲートウェイ G4 を例とします。他の製品では得られる結果が異なる場合があることに注意してください。

[armadillo ~]# cat /sys/class/thermal/thermal_zone0/trip_point_1_temp
105000 
[armadillo ~]# cat /sys/class/thermal/thermal_zone1/trip_point_1_temp
105000

図11.188 サーマルシャットダウン温度の確認(Armadillo-IoT ゲートウェイ G4を例に)

	CPU のサーマルシャットダウン温度です。ミリ℃で表記されているので、105℃でサーマルシャットダウンすることがわかります。
	SoC のサーマルシャットダウン温度です。ミリ℃で表記されているので、105℃でサーマルシャットダウンすることがわかります。

11.15.5.2. 温度測定結果のグラフ化

atmark-thermal-profiler が出力するログ(thermal_profile.csv)はCSVファイルなので、各種表計算ソフトでインポートしてグラフ化することが可能です。これにより Armadillo 動作中の温度の変化が可視化され、得られる情報が見やすくなります。

図11.189「Armadillo-IoT ゲートウェイ G4で取得した温度のグラフ」は Armadillo-IoT ゲートウェイ G4上で一定期間 atmark-thermal-profiler を実行して取得した thermal_profile.csv を Google スプレッドシートでグラフ化したものです。例のために、途中で stress-ng コマンドを実行して CPU に負荷を与えた後、 stress-ng コマンドを停止して CPU と SoC の温度が下がるのを待った際のデータです。

images/abos-images/thermal_profiler_graph.png

図11.189 Armadillo-IoT ゲートウェイ G4で取得した温度のグラフ

グラフの縦軸は温度(℃)で、横軸は時間です。青い線は CPU の温度、赤い線は SoC の温度を表しています。このグラフと、「サーマルシャットダウン温度の確認」で得たサーマルシャットダウン温度を見比べると、 CPU に負荷をかけた際であっても SoC の温度は 60℃ 前後ほどまでしか上がらず、この条件で動く Armadillo が温度的にどれほど余裕を持っているかをひと目で確認できます。

11.15.5.3. CPU使用率の確認

atmark-thermal-profiler は、時間毎の温度だけでなく CPU 使用率と CPU 使用率の高いプロセスについても取得して記録します。 CPU 使用率については thermal_profile.csv の CPU_1〜CPU_5 列と、 USE_1〜USE_5 列を参照してください。各列について詳しくは表11.27「thermal_profile.csvの各列の説明」にまとまっています。

一般的に CPU 使用率が高くなると、 CPU 周辺の温度も高くなります。そのため、測定した温度が高い場合は、 CPU 使用率の高いプロセスに注目して、 CPU を無駄に使用している意図しない処理が行なわれていないかなどを確認することをおすすめします。

11.16. 電源を安全に切るタイミングを通知する

Armadillo Base OS には、シャットダウン中に電源を切っても安全なタイミングで通知する機能があります。通知は GPIO 出力を用いて行います。どの GPIO 出力ピンを使うのかを Device Tree で設定します。Device Tree で通知用に設定された GPIO 出力ピンの出力レベルを変化させる動作は、シャットダウン中に実行される signal_indicator が行います。通知用に設定した GPIO 出力ピンに割り当てた名前を、signal_indicator の設定ファイルに記述することにより、電源を切っても安全なタイミングで、その GPIO 出力ピンの出力が変化します。

以下、signal_indicator の設定手順と、通知用の Device Tree の設定手順を順に述べます。Device Tree の設定は、DTS overlays を使用して行います。


	以下の手順は Armadillo Base OS v3.17.2-at.4 以降に存在します /boot/armadillo-iotg-a6e-stdwn-ind-do1.dtbo または /boot/armadillo-iotg-a6e-stdwn-ind-con8-pin7.dtbo を使用します。v3.17.2-at.4 より前のバージョンをご利用の場合はアップデートしてのご利用をお願いします。

11.16.1. signal_indicator の設定

signal_indicator を設定するには、/etc/conf.d ディレクトリに indicator_signals という名前で、次の内容のテキストファイルを作成してください。

stdwn_led=STDWN_IND

図11.190 /etc/conf.d/indicator_signals の記述内容

図11.191「/etc/conf.d/indicator_signals の永続化」に示すコマンドで /etc/conf.d/indicator_signals の追加を永続化します。

[armadillo ~]# persist_file -vp /etc/conf.d/indicator_signals

図11.191 /etc/conf.d/indicator_signals の永続化

11.16.2. DTS overlays の設定

以下の「CON6(入出力インターフェース)の接点出力 1 を使用する」、「CON8(拡張インターフェース)の7番ピンを使用する」どちらかの設定を行ってください。これ以外のピンを使用する場合はデバイスツリーを記載してビルドする必要があります。

11.16.2.1. CON6(入出力インターフェース)の接点出力 1 を使用する

CON6(入出力インターフェース)の接点出力ピンは、ゲートウェイコンテナアプリケーションも使用しており、接点出力1を本機能に割り当てると、ゲートウェイコンテナアプリケーションでは、そのピンを使用できなくなります。本機能に接点出力1を割り当てる場合は、ゲートウェイコンテナアプリケーションで接点出力1を使わないように設定してください。

接点出力に対するゲートウェイコンテナアプリケーションの設定は、「設定ファイルの編集」を参照してください。ゲートウェイコンテナアプリケーションで接点出力1を使用する場合、本機能には CON8(拡張インターフェース)のピンを割り当ててください。

「DTS overlays によるカスタマイズ」を参考にして /boot/overlays.txt に armadillo-iotg-a6e-stdwn-ind-do1.dtbo を追加してください。

11.16.2.2. CON8(拡張インターフェース)の7番ピンを使用する

「DTS overlays によるカスタマイズ」を参考にして /boot/overlays.txt に armadillo-iotg-a6e-stdwn-ind-con8-pin7.dtbo を追加してください。

11.16.3. 動作確認

ここまで述べた設定を行うと、シャットダウン動作中に通知が行われるようになります。シャットダウン動作の最後の方で、以下のメッセージを出力するのと同じタイミングで通知を行います。つまり、通知用に割り当てた GPIO 出力ピンの出力レベルが、0/Low から 1/High に変わります。シャットダウンが完了して SoC (CPU) への給電がオフすると、出力レベルが 0/Low に戻ります。出力レベルが 0/Low から 1/High に変化した時点以降であれば、Armadillo-IoT A6E の電源を切っても安全です。

indicator_signals        | * Signaling external devices we are shutting down ...

図11.192 indicator_signals のコンソール出力

11.17. WLAN 搭載モデルで量産用インストールディスクを作成する

「CON1(SDインターフェース)」の記載のとおり、WLAN 搭載モデルではインストールディスク以外で SD を使用できません。このため、「Armadillo Base OS 開発ガイド」の「量産用インストールディスクの作成」の章にある「開発したシステムをインストールディスクにする」および「開発が完了した Armadillo をクローンするインストールディスクの作成」で説明している手順で microSD カードを使うことができません。ここでは、microSD カードを使わずにインストールディスクイメージを作成する手順を説明します。以下に説明する手順では、Armadillo に装着した USB メモリに、インストールディスクイメージをファイルとして出力します。出力したイメージファイルは、「初期化インストールディスクの作成」と同じ手順でインストールディスクの作成に使ってください。

11.17.1. 量産用インストールディスクのイメージファイルを USB メモリに書き出す

空き容量が 1GB 以上のフォーマット済み USB メモリを用意してください。
Armadillo-IoT ゲートウェイ A6E インストールディスクイメージをダウンロードして、用意した USB メモリにコピーしてください。
USB メモリにコピーしたインストールディスクイメージのファイル名を、a6e-mp-installer.img に変更してください。このファイル名変更は必須ではなく、手違いが起きるのを防ぐことを意図しています。これから作成する量産用インストールディスクイメージのファイル名を、標準のインストールディスクイメージとは違うものにするための操作です。
「Armadillo Base OS 開発ガイド」の「インストールディスクを作成する準備を行う」に記載している手順を実施してください。
Armadillo に、インストールディスクイメージをコピーした USB メモリを装着してください。
Armadillo に装着した USB メモリをマウントした後、Armadillo で abos-ctrl make-installer コマンドを実行してください。このとき、インストールディスクイメージのファイル名を --output オプションに指定してください。以下は、USB メモリのデバイスが /dev/sda、インストールディスクイメージのファイル名が a6e-mp-installer.img の場合のコマンド例です：
```
[armadillo /]# mount /dev/sda /mnt
[armadillo /]# abos-ctrl make-installer --output /mnt/a6e-pm-installer.img
```
abos-ctrl make-installer コマンドに、--output オプションでディスクイメージのファイル名を指定することで、microSD カードの代わりに、ファイルにインストールディスクイメージを書き込むことができます。書き込む先がイメージファイルである以外は、--output オプションを指定しない場合と違いありません。
abos-ctrl make-installer コマンドの実行が完了したら、USB メモリを umount コマンドでアンマウントするか、または poweroff コマンドで Armadillo を電源オフした後、USB メモリを Armadillo から取り外してください。
abos-ctrl make-installer コマンドの --output オプションで指定したインストールディスクイメージファイルは、標準のインストールディスクイメージと同じように、ATDE で microSD カードに書き込んで使ってください。

abos-ctrl make-installer コマンドは、--output オプションに指定されたファイルが存在しない場合は、必要なサイズを推定してイメージファイルを作成したうえで、標準のインストールディスクイメージを自動的にダウンロードしてベースにします。より大きなサイズのイメージファイルを作成したい場合は、--image-size オプションでファイルサイズを指定できます。


第10章 Web UI によるセットアップ	PDF version	第12章動作ログ

Howto

11.1. ゲートウェイアプリケーションを開発する

11.1.1. VSCode を用いた開発の流れ

11.1.2. ATDE 上でのセットアップ

11.1.2.1. ソフトウェアのアップデート

11.1.2.2. VSCode に開発用エクステンションをインストールする

11.1.2.3. プロジェクトの作成

11.1.2.4. 初期設定

11.1.2.5. ssh_config の編集

11.1.2.6. タスク一覧

11.1.3. Armadillo 上でのセットアップ

11.1.3.1. 初期設定用 SWU イメージの書き込み

11.1.4. ゲートウェイアプリケーション開発

11.1.4.1. ゲートウェイアプリケーションの設定ファイルの編集

11.1.4.2. ゲートウェイアプリケーションの開始

11.1.4.3. ゲートウェイアプリケーションの停止

11.1.4.4. ゲートウェイアプリケーションが使用するデバイス証明書の取得

11.1.5. ゲートウェイアプリケーションの拡張例

11.1.6. リリース版のビルド

11.1.7. 製品への書き込み

11.2. CUI アプリケーションを開発する

11.2.1. CUI アプリケーション開発の流れ

11.2.2. ATDE 上でのセットアップ

11.2.2.1. ソフトウェアのアップデート

11.2.2.2. VSCode に開発用エクステンションをインストールする

11.2.2.3. プロジェクトの作成

11.2.2.4. 初期設定

11.2.2.5. アプリケーション実行用コンテナイメージの作成

11.2.3. Armadillo 上でのセットアップ

11.2.3.1. アプリケーション実行用コンテナイメージのインストール

11.2.4. アプリケーション開発

11.2.4.1. VSCode の起動

11.2.4.2. ディレクトリ構成

11.2.4.3. ssh_config の準備

11.2.4.4. アプリケーションの実行

11.2.5. リリース版のビルド

11.2.6. 製品への書き込み

11.3. ゲートウェイコンテナを動かす

11.3.1. ゲートウェイコンテナ利用の流れ

11.3.2. ゲートウェイコンテナ起動確認

11.3.3. 接続先の クラウド 環境を構築 (AWS)

11.3.3.1. AWS アカウントを作成する

11.3.3.2. IAM ユーザーを作成する

11.3.3.3. アクセスキーを作成する

11.3.3.4. Armadillo-IoT ゲートウェイ A6E のシリアル番号を取得する

11.3.3.5. AWS IoT Core と Amazon CloudWatch の設定を行う

11.3.3.6. 設定に必要となるパラメータを取得する

11.3.4. 接続先の クラウド 環境を構築 (Azure)

11.3.4.1. Microsoft アカウントを作成する

11.3.4.2. リソースグループを作成する

11.3.4.3. Azure IoT Hub と Azure IoT Hub Device Provisioning Service の設定を行う

11.3.5. 設定ファイルの編集

11.3.5.1. インターフェース設定

11.3.5.2. 接続先の クラウド 情報の設定

11.3.6. コンテナ起動・実行

11.3.6.1. Armadillo からクラウドに送信するデータ

11.3.6.2. AWS 上でのデータ確認

11.3.6.3. Azure 上でのデータ確認

11.3.7. クラウドからの操作

11.3.7.1. クラウドからのデータ設定

11.3.7.2. クラウドからのデバイス制御

11.3.8. コンテナの終了

11.3.9. ログ内容確認

11.3.10. ゲートウェイコンテナの構成

11.4. ゲートウェイコンテナを拡張する

11.5. アプリケーションコンテナを作成、実行する

11.5.1. Podman - コンテナ仮想化ソフトウェア

11.5.1.1. Podman - コンテナ仮想化ソフトウェアとは

11.5.2. コンテナを操作する

11.5.2.1. イメージからコンテナを作成する

11.5.2.2. コンテナ一覧を表示する

11.5.2.3. コンテナを起動する

11.5.2.4. コンテナを停止する

11.5.2.5. コンテナの変更を保存する

11.5.2.6. コンテナの自動作成やアップデート

11.5.2.7. コンテナを削除する

11.5.2.8. イメージを削除する

11.5.2.9. コンテナとコンテナに関連するデータを削除する

11.5.2.10. 実行中のコンテナに接続する

11.5.2.11. コンテナ間で通信をする

11.1.2.5. `ssh_config` の編集

11.2.4.3. `ssh_config` の準備

11.3.3. 接続先のクラウド環境を構築 (AWS)

11.3.4. 接続先のクラウド環境を構築 (Azure)

11.3.5.2. 接続先のクラウド情報の設定