| | この章では、サンプルアプリケーション開発内で扱いきれなかった、Armadillo Base OSでの開発に関わる情報を紹介します。 11.1. SWUpdateを用いてソフトウェアをアップデートするArmadillo Base OSではソフトウェアのアップデート方法としてSWUpdateを利用できます。
SWUpdateについて詳細はArmadillo-IoT ゲートウェイ G4の製品マニュアルの「 Armadilloのソフトウェアをアップデートする」を参照してしてください。 今回の例ではUSBメモリを使用してアップデートしますので、4GB以上のUSBメモリを用意してください。 11.1.1. SWUpdateによる初回アップデートSWUpdateでは、ソフトウェアアップデートを行うためにswuイメージというファイルを使用しますので、まずは開発用PC(本ドキュメントではATDE)でswuイメージを作成します。 出荷時のArmadilloは署名されていないswuイメージでもSWUpdateを行うようになっています。
そのため、まずはじめに自分専用の署名鍵を生成して公開鍵をArmadilloに配置する作業をSWUpdateを用いて行うことで、自分が作成したswuイメージでしかアップデートを行わないArmadilloを作成します。 使用しているArmadilloに、過去に一度でもこの初回アップデート作業を行っている場合は二度同じ作業を行うことはできず、する必要もありません。
mkswu の取得
初めに、そのswuイメージを作成するソフトウェアであるmkswuをインストールします。
mkswuの初期設定
図11.2「mkswuの初期設定を行う」に示すコマンドを実行することで、swuパッケージの署名に用いる鍵や、公開鍵をArmadilloに書き込むためのswuイメージを作成できます。
|
会社や製品が分かるような任意の名称を指定します(今回はabos-guide-sample)。
| |
証明鍵を保護するパスフレーズを2回入力します。
| |
swuイメージ自体を暗号化する場合に「y」を選択します。
| |
アットマークテクノが提供するアップデートイメージをインストールできるようにするかを選びます。例では有効にしています。
| |
ここでArmadilloのrootユーザーのパスワードを設定します。2回入力してください。
| |
atmarkユーザーのパスワードも同様に設定します。2回入力してください。
| |
Armadillo Base OSの定期アップデートの有効/無効を設定します。例では無効にしています。
| |
ABOS Web で使用するパスワードを設定します。
| |
初期化処理の結果生成されたファイルを確認しています。swupdate.aes-keyはswuイメージの暗号化を行うと作成されます。
|
SWUpdateの実行
上記の手順で生成された初回セットアップ用のswuイメージ(initial_setup.swu)をArmadilloに書き込みます。 ATDEにUSBメモリを接続し、作成したswuイメージを配置します。
|
USBメモリがマウントされている場所を確認します。
| |
ファイルをコピーします。
| |
/media/atmark/USBDRIVEをアンマウントします。コマンド終了後にUSBメモリを取り外してください。
|
swuイメージを配置したUSBメモリを動作中のArmadilloに挿入すると、自動的にアップデートが開始され、アップデートが完了すると再起動します。 再起動後にはrootユーザ、atmarkユーザともに、図11.2「mkswuの初期設定を行う」で設定したパスワードでログインできます。 これでこのArmadilloに公開鍵が配置され、手元の秘密鍵で作成されたswuイメージでアップデート可能になりました。 | |
---|
Armadilloに公開鍵を配置した後に対応する鍵や、 mkswu.conf を紛失すると、当該のArmadilloにSWUpdateを行うことができなくなりますのでご注意ください。 |
11.2. 作成したコンテナを他のArmadilloに組み込む「アプリケーションを作成する」では、Armadillo上でコンテナイメージを作成する方法を紹介してきましたが、他のArmadilloなど外部で作成されたコンテナイメージを別なArmadilloに組み込む方法を紹介します。 11.2.1. podman loadでコンテナイメージを組み込む「podmanコンテナのエクスポート」で紹介した通り、 podman images コマンドで表示されるコンテナイメージは podman save コマンドを使用することでファイルとして保存することができました。 このファイルは、 podman load コマンドを使用することで、別なArmadillo上であってもコンテナイメージとしてインポートすることができます。
サンプルアプリケーションのコンテナイメージを使用した実行例を図11.4「コンテナイメージファイルをインポートする」に示します。 コンテナイメージのサイズはそのイメージの内容によって異なりますが、1GBを超えることもよくあります。
OverlayFS上で保存できるファイルサイズでは保存しきれないことがありますので、この方法でコンテナイメージをインポートする際には、イメージファイルは外部のUSBメモリやSDカードに配置しておくことをお勧めします。 |
podmanコンテナイメージの保存先をeMMCに変更します。
| |
/dev/sda1として認識されているUSBメモリ(もしくはSDカード)を/mntにマウントしディレクトリ移動します。
| |
USBメモリ上にサンプルアプリケーション用コンテナイメージをダウンロードします。
| |
podman load コマンドでコンテナイメージをインポートします。
| |
podman images コマンドでインポートできていることを確認します。
|
11.2.2. SWUpdateでコンテナイメージを組み込む「podmanコンテナのエクスポート」で紹介した、 podman save コマンドを用いて生成したコンテナイメージファイルは、SWUpdateによって他のArmadilloに適用することも可能です。
以下ではSWUpdateを用いてサンプルアプリケーションを含むコンテナイメージと、コンテナを自動実行するためのsample_container.confをArmadilloに書き込む手順を紹介します。 SWUpdateについては「SWUpdateを用いてソフトウェアをアップデートする」を参照してください。
以下の手順を実行するためには、予め「SWUpdateによる初回アップデート」の手順を実行してSWUpdateの初回アップデートを実施しておく必要があります。
コンテナインストール用のswuイメージを作成する
導入したいコンテナイメージを含んだswuイメージを作成します。 まず、~/mkswu/abos-dev-guide-descsディレクトリを作成し、その中にArmadilloに組み込みたいコンテナイメージと、自動実行用の.confファイルを配置します。
コンテナの自動実行については「podmanコンテナとアプリケーションの自動実行」を参照してください。
次に、swuイメージ作成に用いるusb_container_sample.descを以下のように作成します。
|
abos-dev-guide-v1.0.0.tarをコンテナイメージとして組み込みます。
| |
sample_container.confをArmadillo内の/etc/atmark/containersに配置します。
|
descファイルの詳細についてはArmadillo-IoT ゲートウェイ G4の製品マニュアルの「 mkswuのdescファイル」を参照してください。
/usr/share/mkswu/examples以下のdescファイルはサンプルですので、そちらも参考にしてください。 swuイメージを作成します。
これでコンテナイメージをインストールし、Armadillo起動時に自動実行するためのswuイメージが完成しました。
USBメモリにswuイメージを書き込む
mkswu実行時に表示された指示に従って、作成したswuイメージと付属のファイル群をUSBメモリに配置します。
ATDEにUSBメモリを接続して以下を実行してください。
|
USBメモリがマウントされている場所を確認します。
| |
ファイル群をコピーします。
| |
/media/atmark/USBDRIVEをアンマウントします。コマンド終了後にUSBメモリを取り外してください。
|
SWUpdateの実行
initial_setupと同様に、ArmadilloにUSBメモリを挿入すると自動的にアップデートが実行され、コンテナイメージの組み込みとコンテナの自動実行設定が行われます。
その後Armadilloが自動的に再起動し、サンプルアプリケーションが自動実行します。 以上で、SWUpdateを用いてArmadilloにコンテナイメージと自動実行用のconfファイルの配置ができました。
他にもSWUpdateを用いて出来ることは多々ありますので、詳細はArmadillo-IoT ゲートウェイ G4の製品マニュアルの「 Armadilloのソフトウェアをアップデートする」を参照してください。
11.3. Device Treeを変更しハードウェアを拡張するArmadilloの拡張インターフェースに外部デバイスを接続する際には、対象のピンの機能やパラメータを変更しなければならない場合があります。
具体的には、Armadilloの各ピンの機能やパラメータを記述しているファイルであるDevice Tree Sourceを編集・ビルドし、Armadilloに書き込み、起動時にロードする必要があります。 以下では、Device Treeについての説明と、開発時及び製造・運用時それぞれの場合においてArmadilloにDevice Treeを書き込む手順について紹介します。
具体的なDevice Treeの記述方法については触れませんが、アットマークテクノが提供するDevice Tree作成ツールを紹介します。 Device Treeとは、ハードウェア情報を記述したデータ構造体であり、前述のハードウェア拡張時のパラメータを指定するものです。 Device Treeに対応しているメリットの1つは、ハードウェアの変更に対するソフトウェアの変更が容易になることです。
例えば、Armadillo-IoT ゲートウェイ G4ではCON11(拡張インターフェース1)及び、CON12(拡張インターフェース2)に接続する拡張基板を作成した場合、主にC言語で記述されたLinuxカーネルのソースコードを変更する必要はなく、やりたいことをより直感的に記述できるDTS(Device Tree Source)の変更で対応できます。 ただし、Device Treeは「データ構造体」であるため、ハードウェアの制御方法などの「処理」を記述することはできない点に注意してください。
Device Treeには、CPUアーキテクチャ、RAMの容量、各種デバイスのベースアドレスや割り込み番号などのハードウェア構成情報のみが記述されます。 Device Treeのより詳細な情報については、Linuxカーネルのソースコードに含まれているドキュメント(Documentation/devicetree/ )、devicetree.orgで公開されている「Device Tree Specification」を参照してください。 11.3.2. Device TreeをカスタマイズするDTSファイルを編集し、コンパイルすることでDTB(Device Tree Blob)ファイルが生成されます。
このDTBファイルをArmadilloに書き込むことで、カスタマイズしたDevice TreeでArmadilloを起動することができます。 もちろんエディタでDTSファイルを編集することも可能ですが、アットマークテクノが提供しているat-dtwebというマウス操作でDTS及びDTBを生成できるアプリケーションを使用するのが手軽でおすすめです。 at-dtwebを使用したDevice Treeのカスタマイズ方法については、Armadillo-IoT ゲートウェイ G4の製品マニュアルの「Device Treeをカスタマイズする」を参照してください。 Device Treeはその特性上、記述内容に誤りがあるとうまく接続デバイスが動作しない場合や、最悪Armadilloが起動すらしない場合があります。
最初から正しく動作するDTBファイルを作成できるとは限りませんので、開発中はArmadilloの起動に使用するDTBファイルを何度も書き換えなければならない場合があります。
そのようなシステム開発中におけるDTBファイルの書き換え方法の一例について紹介します。
生成したDTBファイルをArmadilloに転送
at-dtwebなどで生成したDTBファイルをArmadilloに転送します。
転送方法についてはUSBメモリを使用してして転送したり、図6.29「ATDEからArmadilloへファイルを送信」で紹介しているようにウェブサーバ経由で転送したりするなど、お好きな方法で転送してください。
DTBファイルの書き込み
転送したDTBファイルを所定のディレクトリ(/boot)にarmadillo.dtbというファイル名で書き込むことで、Armadilloの起動時にそのDTBファイルを使用できるようになります。
/boot/armadillo.dtbは最初から存在しますが、これは上書きしてしまって問題ありません。 図11.9「DTBファイルの配置」に示すコマンドを実行して、作成したDTBファイル(以下の例ではarmadillo_iotg_g4-at-dtweb.dtb)を/boot/armadillo.dtbに上書きします。
上記手順でDTBファイルを書き込んだ後にArmadilloを再起動することで、次回以降は作成したDTBを使用して起動します。
11.3.3.1. 作成したDTBファイルに差し替えて期待した動作をしなかった場合ここまでの手順を実行して、作成したDTBファイルを使用して起動する際に、DTSの記述に誤りがあり期待した動作をしない場合があります。
誤ったDTBファイルに書き換えた場合のArmadilloの挙動として、以下の3つのパターンが考えられます。 -
正常に起動するが、拡張したいデバイスや今まで動いていたデバイスを認識しない
-
Armadilloが正常に起動せず、Armadillo Base OSのロールバック機能が作動する
-
Armadilloは起動しているが、シリアルコンソールに何も表示されず、何も入力できない
上記のそれぞれのパターンについて対処法を紹介します。
正常に起動するが、拡張したいデバイスや今まで動いていたデバイスを認識しない場合
新規にDTSファイルに追加した記述が誤っている、既存の記述を削除や上書きしてしまったなど、作成したDTSファイルの記述に問題がある可能性が高いです。
そのような場合は再度at-dtwebなどでDTSファイルを修正し、新たに生成したDTBファイルをArmadilloに転送する手順からやり直してください。
Armadilloが正常に起動せず、Armadillo Base OSのロールバック機能が作動する場合
書き込んだDTBファイルが壊れている、DTSファイル内の起動に関わる重要な箇所に誤りがあるなどの可能性が高いです。 Armadillo Base OSは何らかの原因によってルートファイルシステムが破損し正常に起動できない場合に、前のバージョンに戻して再起動するロールバック機能が自動で働きます。
これによって起動したArmadilloは作成したDTBファイルを書き込む前の状態に戻っているので起動できるはずです。 Armadillo Base OSのロールバック機能の詳細については、Armadillo-IoT ゲートウェイ G4の製品マニュアルの「 Armadillo Base OSの操作」内の「ロールバック状態の確認」を参照してください。 ロールバック機能が働いたかどうかは起動ログでも確認できますが、以下のコマンドで確認できます。 [armadillo /]# abos-ctrl status
Currently booted on /dev/mmcblk2p1
WARNING: Currently running on non-latest version (expected /dev/mmcblk2p2 installed on Mon Apr 4 15:39:42 JST 2022)
rollback-status: rolled back |
rollback-status が rolled back となっているため、ロールバック機能が働いて起動したことがわかります。
|
このような場合は再度at-dtwebなどでDTSファイルを修正し、新たに生成したDTBファイルをArmadilloに転送する手順までをやり直してください。
修正したDTBファイルをArmadilloへ転送後、今起動していない方のルートファイルシステムに修正後のDTBファイルを配置します。 [armadillo /]# ls armadillo_iotg_g4-at-dtweb.dtb
armadillo_iotg_g4-at-dtweb.dtb
[armadillo /]# abos-ctrl mount-old && mount -o remount,rw /target
[armadillo /]# cp armadillo_iotg_g4-at-dtweb.dtb /target/boot/armadillo.dtb |
起動していない方のルートファイルシステムを/targetに読み書き可能モードでマウントします。
| |
armadillo_iotg_g4-at-dtweb.dtbを起動していない方のルートファイルシステムの/boot/armadillo.dtbに上書き保存します。
|
その後、以下のコマンドを実行し、現在起動していない方のルートファイルシステムを用いて起動します。 [armadillo /]# abos-ctrl rollback
[armadillo /]# reboot 修正したDTBが誤りがなければ正常に起動します。
誤りが解消されなければ再度ロールバックしますので、再度同様の手順で復旧するまでDTBを修正してください。
Armadilloは起動しているが、シリアルコンソールに何も表示されず、何も入力できない場合
DTB内のシリアルコンソールを設定する記述に誤りがあり、起動こそしていても何も入出力できない状態になっている可能性が高いです。 この場合は一度Armadilloの電源を投入し直し、U-bootの環境変数を変更することで、Armadillo-IoT ゲートウェイ G4の標準のDTBで起動するように設定します。 電源投入後、U-bootにて以下のコマンドを実行します。 U-Boot 2020.04-at6 (Mar 25 2022 - 08:09:26 +0000)
:(省略)
Hit any key to stop autoboot: 0
u-boot=> setenv fdt_file boot/armadillo_iot_g4.dtb
u-boot=> boot |
ここでカウントダウンが0になる前に何かキー入力をすることでプロンプトに入ります。
| |
Armadillo-IoT ゲートウェイ G4の標準のDTB(armadillo_iot_g4.dtb)で起動するよう環境変数を設定します。
| |
起動します。
|
起動後、再度at-dtwebなどでDTSファイルを修正し、新たに生成したDTBファイルをArmadilloに転送する手順からやり直してください。 次回以降の起動は、また/boot/armadillo.dtbを使用して起動するようになっています。
「開発中のDTBファイルの書き換え」で紹介した方法はあくまでも開発中に何度も書き換える際にのみ推奨している手順です。
最終的に期待した動作をするDTBファイルが完成し、それをArmadilloに書き込む際には前述の手順は非推奨です。
最終的に確定したDTBファイルをArmadilloに書き込む際には、Armadillo Base OSにて提供されているSWUpdateを使用してください。
SWUpdateについては、「SWUpdateを用いてソフトウェアをアップデートする」を参照してください。 11.3.4.2. DTBファイルアップデート用のswuイメージを作成する
作成したDTBファイル配置用のswuイメージを作成する
まず、適当な作業用ディレクトリ(以下の例では~/mkswu/update-dtb-descs)を作成し、その中に作成したDTBファイルをarmadillo.dtbにリネームして配置します。
DTBファイルへのパスは適宜読み替えてください。
また、今回のswuイメージを作成時に使用するスクリプトファイルもあわせて配置します。
次に、swuイメージ作成に用いるusb_dtb_sample.descを以下のように作成します。
|
componentを指定します。今回はrootfsの変更を行うのでextra_osを指定しています。
| |
バージョンを指定します。今後さらにアップデートする際にはこの数値を上げます。
| |
/bootにarmadillo.dtbを配置します。
| |
Armadilloに書き込んだ/boot/armadillo.dtbが今後のOSアップデートによって削除されないように設定します。詳しくは、Armadillo-IoT ゲートウェイ G4の製品マニュアルの「 swupdate_preserve_files について」を参照してください。
|
descファイルの詳細についてはArmadillo-IoT ゲートウェイ G4の製品マニュアルの「 mkswuのdescファイル」を参照してください。
/usr/share/mkswu/examples以下のdescファイルはサンプルですので、そちらも参考にしてください。 swuイメージを作成します。
これでDTBファイルをArmadilloの所定のディレクトリに配置するswuイメージが完成しました。
USBメモリにswuイメージを書き込む
mkswu実行時に表示された指示に従って、作成したswuイメージをUSBメモリに配置します。
ATDEにUSBメモリを接続して以下を実行してください。
|
USBメモリがマウントされている場所を確認します。
| |
swuイメージをUSBメモリへコピーします。
| |
USBメモリをアンマウントします。コマンド終了後にUSBメモリを取り外してください。
|
SWUpdateの実行
initial_setupと同様に、ArmadilloにUSBメモリを挿入すると自動的にアップデートが実行され、コンテナイメージの組み込みとコンテナの自動実行設定が行われます。 自動的に再起動するので、再度Armadilloにログインし、DTBファイルが書き換わって起動していることをご確認ください。 以上で、作成したDTBファイルをSWUpdateを用いてArmadilloに配置することができました。
Armadillo Base OSでは基本的にユーザーアプリケーションはコンテナ内に格納されます。
場合によっては機能毎にコンテナを複数使用したり、コンテナ内からホストであるArmadillo Base OS側のリソースへのアクセスやコマンド実行をしたりしたい場合などがあります。
この章では、上記のような場合にArmadillo Base OS上でコンテナをどう構築するのが良いかを例を示しつつ紹介します。 11.4.1. 複数コンテナで処理を行いコンテナ間でデータを共有するここでは、以下のような処理を行うシステムについて考えます。 -
Armadilloに接続したセンサからデータを読み出す
-
読み出したデータをローカルに保存
-
保存したデータをArmadilloに接続したPCで表示できるようにする
このシステムは、1つのコンテナに全ての処理を任せても実現可能ですが、役割毎にコンテナを分けることで以下のようなメリットを得ることができるためおすすめです。 -
不具合が発生した場合にコンテナ毎に切り分けや修正がしやすい
-
アップデート時にアップデートするコンテナ以外への影響が少ない
-
再利用性が高い
-
開発時に分業化しやすい
役割毎にコンテナを分けたシステムの構成図を図11.14「センサから読み取ったデータをPCに出力するシステム構成図」に示します。
なお、図中でグレーアウトしている箇所は使用しない部分、枠が2つ重なっている箇所は二面化されている部分です。 図11.14「センサから読み取ったデータをPCに出力するシステム構成図」に示したシステムにおける各コンテナは以下のような処理を行います。
Container1
-
定期的に/var/app/volumes以下のデータベースからデータを取得する
-
Armadilloに接続しているPCでそのデータを見られるようにする
Container2
-
定期的に外部のセンサからデータを取得する
-
センサから読み取った値を/var/app/volumes以下にデータベースとして配置する
実装のポイントや注意点は以下の通りです。 11.4.2. 複数コンテナ間でデータを共有し、クラウドにアップロードするここでは、以下のような処理を行うシステムについて考えます。 -
Armadilloに接続したセンサからデータを読み出す
-
読み出したデータをローカルに保存
-
読み出したデータをクラウドにアップロードする
このシステムに関しても、役割毎にコンテナを分けることで「複数コンテナで処理を行いコンテナ間でデータを共有する」と同様のメリットを得ることができるためおすすめです。 役割毎にコンテナを分けたシステムの構成図を図11.15「センサからデータを読み取りクラウドに出力するシステム構成図」に示します。
なお、図中でグレーアウトしている箇所は使用しない部分、枠が2つ重なっている箇所は二面化されている部分です。 図11.15「センサからデータを読み取りクラウドに出力するシステム構成図」に示したシステムにおける各コンテナは以下のような処理を行います。
Container1
-
/var/app/rollback/volumes以下に配置したクラウド認証情報を読み出してクラウドに接続する
-
定期的に/var/app/volumes以下のデータベースからデータを取得する
-
外部のクラウドにデータをアップロードする
Container2
-
定期的に外部のセンサからデータを取得する
-
センサから読み取った値を/var/app/volumes以下にデータベースとして配置する
実装のポイントや注意点は以下の通りです。 ここでは、以下のような処理を行うシステムについて考えます。 -
Armadilloに接続した2つのセンサからデータを読み出す
-
読み出したデータをArmadillo内部のデータベースに保存
-
データベース内のデータをArmadilloに接続したPCで表示できるようにする
基本的には、「複数コンテナで処理を行いコンテナ間でデータを共有する」で紹介したシステムと同一ですが、入力となるセンサが2つに増えています。 この場合、各センサとのインターフェースの差異にもよりますが、先に挙げたメリットのひとつである再利用性を活かして、センサからデータを取得するコンテナを増やすだけで容易に対応することができます。 ただし、コンテナを増やす場合には考慮すべき問題があります。 1つ目は、Armadilloの容量です。
当然ではありますが、コンテナが増えれば増えるほどArmadilloのeMMCの容量を消費します。
コンテナを必要以上に構築するとArmadilloの容量が足りなくなる恐れがあります。
特に、コンテナのベースイメージが異なる場合は容量を大量に消費するので、複数のコンテナを使用する場合はベースイメージを統一するとコンテナのサイズを抑えることができます。 2つ目は処理速度の低下です。
コンテナを分ければ分けるほど、コンテナ1つで全ての処理を行なった際に比べてシステム全体としての処理速度は低下します。
完成したシステムで動作確認を十分に行い、システム全体における動作速度に問題がないことを確認した上で運用してください。
場合によってはセンサ1つに対してコンテナ1つでなく、全てのセンサに対してコンテナを1つにまとめるなど、コンテナを分ける粒度を荒くして動作速度の改善を考えるべきです。 処理毎にコンテナを分けたシステムの構成図を図11.16「複数のセンサからデータを読み取るシステム構成図」に示します。
なお、図中でグレーアウトしている箇所は使用しない部分、枠が2つ重なっている箇所は二面化されている部分です。 図11.15「センサからデータを読み取りクラウドに出力するシステム構成図」に示したシステムにおける各コンテナは以下のような処理を行います。
Container1
-
定期的に/var/app/volumes以下のデータベースからデータを取得する
-
Armadilloに接続しているPCでそのデータを見られるようにする
Container2
-
定期的に外部のセンサ1からデータを取得する
-
センサから読み取った値を/var/app/volumes以下にデータベースとして配置する
Container3
-
定期的に外部のセンサ2からデータを取得する
-
センサから読み取った値を/var/app/volumes以下にデータベースとして配置する
実装のポイントや注意点は、「複数コンテナで処理を行いコンテナ間でデータを共有する」に挙げたものに加えて以下が挙げられます。 -
インターフェースの違いなどにもよりますが、Container2とContainer3はほとんど同じものを使い回すことができます
-
各コンテナのベースイメージを統一することでコンテナのサイズを抑えることができます
ホスト(Arnadillo Base OS)のコマンドは、コンテナ内から直接実行することはできません。
しかし、実現したいシステムによってはコンテナ内からホストコマンドを実行したいことがあります。 コンテナ内からホストコマンドを実行する方法を以下の2つのパターンに分けて紹介します。 -
ボタン押下や、USB挿抜などのイベントをトリガにホストコマンドを実行する場合
-
コンテナ内から任意のタイミングでホストコマンドを実行する場合
11.4.4.1. イベントをトリガにホストコマンドを実行するArmadillo Base OSが特定のイベントを検知した際にホストコマンドを実行するように設定できます。
そのため、厳密に言うとコンテナ内からホストコマンドを実行することにはなりませんが、コンテナ内のアプリケーションが動作中でもホストコマンドが実行されます。 トリガとするイベントによって設定方法が異なります。
以下ではudevを用いてデバイスの挿抜を検知してホストコマンドを実行するパターンと、buttondを用いてユーザースイッチや外付けのキーボード等の入力を検知してホストコマンドを実行するパターンの2パターンについて説明します。
udevを用いてUSBメモリの挿入を検知しmountコマンドを実行する
udevは、Linuxカーネル用のデバイス管理ツールです。
デバイスが接続もしくは接続解除された時にカーネルはueventをudevに通知します。
この時udevは予め設定しておいたルールに従って、受け取ったueventに対応した処理を行います。 udevを活用することでデバイスの挿抜をトリガに任意のホストコマンドを実行できますので、コンテナ内で何かを設定する必要はありません。 以下ではUSBメモリの挿抜時にmountコマンドを実行し、/mntディレクトリにマウントする例を紹介します。 まず、/etc/udev/rules.d/に、99-usb-automount.rulesというファイルを作成して、以下のように内容を編集します。 [armadillo ~/]# cat /etc/udev/rules.d/99-usb-automount.rules
ACTION=="add", KERNEL=="sd*", SUBSYSTEM=="block", ENV{ID_FS_USAGE}=="filesystem", RUN+="/bin/mount /dev/%k /mnt" その後、以下のコマンドを実行してudevルールの再読込みを行います。 [armadillo ~/]# udevadm control -R 以上で設定完了ですので、動作確認をしてみます。 [armadillo ~/]# mount | grep /mnt
[armadillo ~/]#
[84250.573893] usb 1-1: new high-speed USB device number 8 using xhci-hcd
[84250.732277] usb-storage 1-1:1.0: USB Mass Storage device detected
: (省略)
[84252.013348] sda: sda1
[84252.020039] sd 0:0:0:0: [sda] Attached SCSI removable disk
[84252.214274] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null)
[armadillo ~/]# mount | grep /mnt
/dev/sda1 on /mnt type ext4 (rw,relatime) |
/mntディレクトリに何もマウントされていないことを確認します。
| |
ここでUSBメモリを挿入します。
| |
USBメモリが/mntディレクトリに自動的にマウントされていることを確認します。
|
動作確認後、persist_fileコマンドを実行して設定したudevルールを永続化します。
-p オプションでアップデートで保存するための /etc/swupdate_preserve_files にも記載します。 swupdate_preserve_files については Armadillo-IoT ゲートウェイ G4 の製品マニュアルの「 swupdate_preserve_files について」を参照してください。
[armadillo ~/]# persist_file -p /etc/udev/rules.d/99-usb-automount.rules 上記手順ではmountを例に紹介しましたが、他のコマンドやシェルスクリプトの実行なども可能です。
buttondを用いてユーザースイッチの押下を検知してホストコマンドを実行する
Armadillo Base OSには、ユーザースイッチや外付けのキーボードなどの入力をイベントとして検知し、予め定義したルールによってそのイベントに対応させた処理を実行できるbuttondという仕組みがあります。 buttondについての詳細は、Armadillo-IoT ゲートウェイ G4の製品マニュアルの「 Armadillo Base OSの操作」内の「ボタンやキーを扱う」を参照してしてください。 以下では、buttondを用いてユーザースイッチを5秒以上長押しするとrebootコマンドを実行する例を紹介します。 まず、/etc/atmark/buttond.confを以下のように作成して、persist_fileコマンドで永続化します。
また、buttondサービスを再起動させます。 [armadillo ~/]# vi /etc/atmark/buttond.conf
BUTTOND_ARGS="$BUTTOND_ARGS -l prog1 -t 5000 -a 'reboot'"
[armadillo ~/]# persist_file /etc/atmark/buttond.conf
[armadillo ~/]# rc-service buttond restart |
/etc/atmark/buttond.confを作成・編集します。
| |
persist_fileコマンドで永続化します。
| |
buttondサービスを再起動させます。
|
その後、Armadillo-IoT ゲートウェイ G4のユーザースイッチ(SW1)を5秒長押しして再起動することを確認してください。 上記手順ではrebootを例に紹介しましたが、他のコマンドやシェルスクリプトの実行なども可能です。
11.4.4.2. 任意のタイミングでホストコマンドを使用する「イベントをトリガにホストコマンドを実行する」で紹介した方法は、デバイスの挿抜やスイッチの押下などのイベントをトリガとしてホストコマンドを実行するものでした。 イベントをトリガとせずに任意のタイミングでホストコマンドを実行したい場合は、コンテナからホストに対してsshで接続して実行します。
Armadillo Base OS側の準備1
まず、sshサーバとなるArmadillo Base OS側の設定を行います。
以下のコマンドを実行して、sshサーバを自動的に起動するよう設定し、sshdサービスを再起動します。 [armadillo ~/]# rc-update add sshd
* service sshd added to runlevel default
[armadillo ~/]# persist_file /etc/runlevels/default/sshd
[armadillo ~/]# rc-service sshd restart
コンテナの準備
以下では説明の為にat-debian-imageをベースとしたコンテナを作成します。
予め「サンプルコンテナをビルド」の手順に従って、at-debian-imageのDockerfileからイメージを生成しておく必要があります。 [armadillo ~/]# podman run -it --name=ssh_sample \
localhost/at-debian-image:latest /bin/bash
[container /]# コンテナ内で以下のコマンドを実行してsshの準備をします。 [container /]# apt install -y openssh-client
[container /]# ssh-keygen -t rsa -N "" -f /root/.ssh/id_rsa
[container /]# ls /root/.ssh/id_rsa*
/root/.ssh/id_rsa /root/.ssh/id_rsa.pub
[container /]# <Ctrl+P> <Ctrl+Q>
[armadillo ~/]# |
openssh-clientをコンテナ内にインストールします。
| |
公開鍵認証のための認証鍵を生成します。
| |
公開鍵・秘密鍵が生成されていることを確認します。
| |
コンテナから抜けます。
|
Armadillo Base OS側の準備2
sshサーバであるArmadillo Base OSの方に、先程コンテナ内で生成した公開鍵を登録します。 [armadillo ~/]# mkdir /root/.ssh
[armadillo ~/]# chmod 600 /root/.ssh
[armadillo ~/]# podman exec -it ssh_sample /bin/cat /root/.ssh/id_rsa.pub >> /root/.ssh/authorized_keys
sshでコンテナ内からホストコマンドを実行
再度コンテナ側に戻り、ssh経由でホストコマンドであるrebootを実行してみます。
コンテナからArmadillo Base OSへはIPアドレス10.88.0.1でアクセスできます。 [armadillo ~/]# podman attach ssh_sample
[container /]# ssh root@10.88.0.1 reboot
: (省略) 初回ssh時に、「Are you sure you want to continue connecting (yes/no/[fingerprint])?」と表示される場合があります。
手動実行であればyを選択すれば問題ありませんが、シェルスクリプトなど非手動実行の場合はssh実行時に -o StrictHostKeyChecking=no オプションを指定すると上記質問を回避できます。 上記手順ではrebootを例に紹介しましたが、他のコマンドやシェルスクリプトの実行なども可能です。
Armadillo-IoT ゲートウェイ G4 で採用している i.MX 8M Plus には、機械学習に特化した演算処理
ユニットである NPU (Neural Processor Unit) が搭載されています。
機械学習と聞くと、何でもできるといったイメージが先行してしまいがちですが、そうとも言い切れません。
機械学習を使うためには解決しなければならない課題も多く、
これから開発しようとしている製品やサービスに機械学習という手法がマッチするかどうかは、
それらの課題をよく考慮した上で決定する必要があります。
この章では、機械学習と NPU を採用する前に考慮するべき点、および機械学習以外の方法について説明します。 機械学習は主に以下に挙げる 4 つの範囲で活用できます。 表11.1 機械学習の活用範囲 分野 | 具体例 |
---|
画像・映像データの処理 | 不良品検知
顔認識
文字認識 | テキストデータの処理 | チャットボット
多言語への翻訳
文章要約 | 音声データの処理 | 音声認識 | 数値データの処理 | EC サイトのレコメンド機能 |
Armadillo-IoT ゲートウェイ G4 でこれらのことを実現したい場合は、
NPU を活用した機械学習は選択肢の一つとなります。
これら以外のことを実現したいのであれば、機械学習以外の方法を検討することも必要かもしれません。 NPU は学習済みデータを使って推論を行うことに特化した演算処理ユニットです。このため、
学習自体には適していません。学習は別途 PC やクラウドサービスなどを使って行う必要があります。
また、NPU は INT8 で量子化された学習データで推論が高速になるように設計されており、
INT8 ではない学習データは CPU で演算が行われるため処理速度は落ちてしまいます。 NPU は以下のツールキットから利用できます。 -
TensorFlow Lite
-
ONNX Runtime
-
ArmNN
これらは、アットマークテクノが提供しているコンテナ at-debian-image であれば、
apt コマンドでインストールすることができます。
プログラミング言語としては Python が広く使われています。 11.5.3. 機械学習と NPU を使うことの課題機械学習を用いると従来のアルゴリズムではできなかったことができるようになる反面、
5章仕様を検討・決定する でも言及していますが、以下のような課題を考える必要があります。 -
学習用に大量のデータを用意する必要がある。
-
期待したような認識率がでない場合は、いろいろとパラメータを変えて試行錯誤する必要がある。
-
確率的な処理があるために自動テストが難しい。
-
なぜそういう結果になったのかという理由がブラックボックス化されてしまっている。
-
長期運用しているとトレンドの変化などで入力の傾向が変化する。
-
精度が100%となることはない。
機械学習を活用しなくても、例えば画像処理や音声処理などであれば以下のようなライブラリがあります。
これらのライブラリでも十分にサービスを提供できるのであれば、採用を検討してもよいかもしれません。 -
OpenCV
-
PIL (Python Image Library)
-
Julius (音声認識エンジン)
この内、OpenCV と Julius はアットマークテクノが提供しているコンテナ at-debian-image であれば、
apt コマンドでインストールできます。
PIL は pip コマンドでインストールできます。 ここでは、前章で機械学習以外の方法として紹介した音声認識エンジンである Julius のデモ実行手順を説明します。
細かい設定などの詳細な情報については Julius の 公式サイト
のマニュアル等を参照してください。 なお、音声認識のデモであるため Armadillo-IoT ゲートウェイ G4 本体に USBマイク等の
音声入力デバイスを接続しておく必要があります。 準備として、「サンプルコンテナをビルド」 に示した手順通りにコンテナイメージを作成してください。 コンテナを起動してコンテナ内に入ります。 Julius をインストールします。 Julius の 公式サイト から
音声認識パッケージをダウンロードします。
音声認識パッケージパッケージには、音声認識に必要な音響モデルが含まれており、
「ディクテーションキット」、「話し言葉モデルキット」、「講演音声モデルキット」の3つがあります。
ここではディクテーションキットを使用します。他のキットに関する詳細は公式サイトを参照してください。 julius コマンドで音声認識を実行します。
<<< please speak >>> と表示された後に、マイクに向かって発話すると、認識された文章が表示されます。 本章では、Armadillo-IoT ゲートウェイ G4 各製品のネットワーク構成や Podman のネットワーク概要等について説明したうえで、具体的なネットワーク構成を挙げ、その設定方法を記載しています。
さらに、量産製造時に一括してネットワークの設定を行う方法や、運用を開始した後の設定変更の方法についても案内しています。 なお、ネットワーク設定方法を記載していますが、必ずしも記載の通り設定する必要はありません。ご利用の環境・システム構成にあわせて適宜読み替えてください。 11.6.1. Armadillo-IoT ゲートウェイ G4 のネットワーク概要ここでは、Armadillo-IoT ゲートウェイ G4 のネットワークに関して記載します。 Armadillo-IoT ゲートウェイ G4 は以下の通信規格に対応しています。
利用可能な種別・通信規格と Linux から使用するネットワークデバイスの対応を以下に示します。 表11.2 種別・通信規格とネットワークデバイス 種別・通信規格 | ネットワークデバイス | 備考 |
---|
有線LAN(Ethernet) | eth0
| 有線 LAN インターフェース 1 | 有線LAN(Ethernet) | eth1
| 有線 LAN インターフェース 2 [] | モバイル通信(3G/LTE) | ttyCommModem
| LTEモデルのみ搭載 [] |
Armadillo-IoT ゲートウェイ G4 では、通常の Linux システムと同様、ネットワークインターフェースの設定は NetworkManager を使用します。
NetworkManager はデフォルトで eth0 と eth1 が自動で up し、DHCP でネットワーク設定を取得するようになっています。 NetworkManager はすべてのネットワーク設定をコネクションとして管理します。
コネクションには「どのようにネットワークへ接続するか」、「どのようにネットワークを作成するか」を記述し、 /etc/NetworkManager/system-connections/ に保存します。
また、1つのデバイスに対して複数のコネクション設定を保存することは可能ですが、1つのデバイスに対して有効化できるコネクションは1つのみです。 NetworkManager は、従来の /etc/network/interfaces を使った設定方法もサポートしていますが、本書では nmcli と nmtui を用いた方法を中心に紹介します。
nmcli
nmcli は NetworkManager を操作するためのコマンドラインツールです。
図11.27「nmcli のコマンド書式」に nmcli の書式を示します。このことから、 nmcli は「オブジェクト (OBJECT) というものが存在し、
それぞれのオブジェクトに対してコマンド (COMMAND) を実行する。」という書式でコマンドを入力することがわかります。
また、オブジェクトそれぞれに help が用意されていることもここから読み取れます。
なお、基本的な使い方については、Armadillo-IoT ゲートウェイ G4の製品マニュアルの「ネットワーク」を参照してください。
nmtui
nmtui は NetworkManager を操作するためのユーザーフレンドリーなツールです。
NetworkManager を操作するための画面がテキストユーザーインターフェースで表示されるため、一つずつコマンドを入力する必要がなく、現在の設定項目を確認しながら設定することができます。
ただし、nmtui で設定できる項目には限りがあるため、設定する内容によっては nmcli を使用する必要があります。
11.6.2. podman のネットワークの仕組みArmadillo Base OS では ユーザーアプリケーションを「podman コンテナ」内で動作させますが、
ネットワークの設定は基本的に Armadillo Base OS (ホストOS) の設定に帰結します。
ここでは、 podman のネットワークの仕組みについて説明します。 なお、本項のコマンド実行結果や構成図については Armadillo-IoT ゲートウェイ G4 LTE モデルの内容を記載しており、
記述中の ppp0 は LTE モデルにのみ存在するネットワークインターフェースです。 11.6.2.1. podman のネットワークモードpodman のネットワークモードはブリッジモードがデフォルトです。
その他のモードに指定する場合は、コンテナ作成時に --net オプションを付けることで指定することができます。
例として、podman run 実行時に --net=host を指定すると、host モードになります。 下記でブリッジモードと host モードの2つについて説明します。
その他のモードについては、Podman のドキュメントを参照してください。
ブリッジモード
前述の通り、ブリッジモードがデフォルトとなります。
仮想ブリッジ podman0 がコンテナとホスト OS のネットワークインターフェースを繋ぐ役割を担い、コンテナは veth を経由して仮想ブリッジに接続します。
コンテナから外部に接続する場合は、仮想ブリッジで IPマスカレードが行われます。
そのため、ホスト OS 側で複数のネットワークインターフェースを持っていたとしても、コンテナ内のネットワークインターフェースは eth0(veth) となります。 ネットワークの設定が基本的に Armadillo Base OS の設定に帰結するのはこの仕組みによるものです。 実際にコンテナを podman run コマンドで作成し、ホスト OS 側のネットワークインターフェースを確認すると、 podman0 と veth が作成されています。
コンテナ内のネットワークインターフェースはこのようになります。
host モード
コンテナ作成時に --net=host オプションをつけると host モードになり、
ホスト OS のネットワークインターフェースをそのままコンテナに渡すことができます。
コンテナを podman run コマンドで作成した時に表示されるログを見ると、ブリッジモードとは異なり、ホスト OS 側に podman0 と veth は存在しません。
コンテナ内のネットワークインターフェースは以下の通り、ホスト OS と同じ内容になります。
host モードは、コンテナからホスト OS のネットワークインターフェースの設定を行いたい場合に適しています。
コンテナをブリッジモードにすると veth が作られますが、この veth のアドレスがコンテナ自身のアドレスとなります。
同じネットワークのコンテナ (接続されている仮想ブリッジが同じことを指します) の間では、このアドレスを用いて通信を行うことができます。
コンテナ間の通信については、コンテナ名でも行うことができます。 なお、ユーザー定義のネットワークの設定を行うことにより、固有の IP アドレスを設定することができます。
設定方法の詳細は Armadillo-IoT ゲートウェイ G4の製品マニュアルの「ネットワークを扱う」を参照してください。 11.6.2.3. ネットワーク関連の Capabilityコンテナを作成する際には、コンテナ内のアプリケーションの動作内容に応じて、ネットワーク関連の権限を渡すことが必要となります。
開発時は --privileged を設定し全ての権限を渡すことが有用ですが、運用時はセキュリティの都合上、最低限の Capability とすることを推奨します。
ネットワークに関連する代表的な Capability を以下に記載します。 表11.3 ネットワークに関連する代表的な Capability Capability | |
---|
NET_ADMIN | ネットワークスタックを操作する場合に指定 | NET_RAW | RAW と PACKET sockets を利用する場合に指定 | NET_BIND_SERVICE | 特権ポート(1024以下)でリッスンする場合に指定。ただし、コンテナにrootユーザーでloginする場合は考慮不要。 |
ここでは、具体的なネットワーク構成を挙げ、その設定方法を紹介します。
なお、必ずしも記載の通り設定する必要はありません。
ご利用の環境・システム構成にあわせて適宜読み替えてください。
また、Armadillo-IoT ゲートウェイ G4 のネットワーク設定が何も行われていない場合を想定して記載しています。 ハードウェア接続方法等については、Armadillo-IoT ゲートウェイ G4の製品マニュアルの「接続方法」を参照してください。 11.6.3.1. 各 Ethernet ポートを ローカルネットワーク に接続し 3G/LTE は WAN に接続する以下の通り、各 Ethernet ポートそれぞれを別セグメントのローカルネットワークに接続し、
3G/LTE で WAN に接続します。
このとき、 3G/LTE 接続に使用する SIM は固定 IP アドレスが割り当てられるなど WAN 側から接続できるものを想定し、外部からの攻撃を防ぐためファイアーウォールを設定します。 eth0 側のネットワークで シーケンサなどの機器を制御、eth1 側のネットワークは工場内LANに接続しそのデータを集約し、
3G/LTE 経由で Armadillo-IoT ゲートウェイ G4 のコンテナに ssh 接続し、診断を行う場合などに利用できる構成です。 表11.4 ネットワークのアドレス情報 ノード名 | ネットワークデバイス | IPアドレス | ネットワークアドレス |
---|
Armadillo | eth0
| 192.168.10.10 | 192.168.10.0/24 | eth1
| 192.168.20.20 | 192.168.20.0/24 | ttyCommModem
| xxx.xxx.xxx.xxx | xxx.xxx.xxx.xxx | Router1 | - | 192.168.10.1 | 192.168.10.0/24 | Server1 | - | 192.168.30.1 | 192.168.30.0/24 | Router2 | - | 192.168.20.1 | 192.168.20.0/24 | PLC1 | - | 192.168.40.1 | 192.168.40.0/24 | PLC2 | - | 192.168.40.2 | 192.168.40.0/24 |
設定手順
上記のネットワークを構築する際のネットワーク設定手順は以下のようになります。全てコンソール上で実行します。
有線 LAN インターフェースの設定については nmcli と nmtui のそれぞれの手順を記載しています。使いやすい方を選択して設定を行ってください。 なお、Armadillo-IoT ゲートウェイ G4 は overlayfs を採用しているため、シャットダウンや再起動でシステムを OFF すると作成したファイルが消えてしまいます。
それにより nmcli コマンド等で指定した設定も消えてしまうため、各設定の最後には設定の永続化を行っています。 また、全ての設定はホスト OS 側で実施します。
有線 LAN インターフェースの設定
下記にコマンドを記載します。表11.5「有線 LAN インターフェース の設定情報(nmcli)」 に記載する内容に置き換えて 有線 LAN インターフェース 1(eth0)、2(eth1) それぞれを設定してください。 表11.5 有線 LAN インターフェース の設定情報(nmcli) | eth0 | eth1 |
---|
interface name | eth0 | eth1 | connection name | ethernet-eth0 | ethernet-eth1 | address | "192.168.10.10/24" | "192.168.20.20/24" | route | "192.168.30.0/24 192.168.10.1" | "192.168.40.0/24 192.168.20.1" |
|
有線 LAN インターフェースのコネクションを作成します。
| |
有線 LAN インターフェースのコネクションに固定 IP アドレスを設定します。
| |
有線 LAN インターフェースのコネクションに経路情報を追加します。
| |
有線 LAN インターフェースのコネクションのデフォルトゲートウェイを無効化します。
| |
修正を反映させるため、有線 LAN インターフェースのコネクションを無効化します。
| |
有線 LAN インターフェースのコネクションを有効化します。
|
下記の通り、nmtui を実行して設定を行います。入力する内容は 表11.6「有線 LAN インターフェース の設定情報(nmtui)」 に記載する内容に置き換えて 有線 LAN インターフェース 1(eth0)、2(eth1) それぞれを設定してください。 表11.6 有線 LAN インターフェース の設定情報(nmtui) | eth0 | eth1 |
---|
Profile name | ethernet-eth0 | ethernet-eth1 | Device | eth0 | eth1 | Addresses | 192.168.10.10/24 | 192.168.20.20/24 | Destination/Prefix | 192.168.30.0/24 | 192.168.40.0/24 | Next Hop | 192.168.10.1 | 192.168.20.1 |
nmtui を起動します。
Edit a connection を選択します。
<Add> を選択します。
コネクション種別の選択画面が表示されるので Ethernet を選択します。
Profile name Ethernet と Device を入力します。
IPv4 CONFIGURATION を <Manual> に変更し、Show を選択します。
入力画面が表示されるので、 Addresses と Routing を入力します。
Routing については、 <Edit…> 選択後に表示される画面の <Add…> を選択すると入力画面が表示されるので、項目入力後 <OK> を選択してください。
デフォルトゲートウェイを無効化するため、 <Never use this network for default route> にチェックを入れます。
カーソルを合わせ、スペースキーを押すと、チェックが入ります。
全ての設定入力後、 <OK> を選択し設定を保存してください。 次に、ネットワーク設定を反映させるために一度コネクションを Deactivate します。
コネクション選択画面で <Back> を選択し、 Activate a connection を選択してください。 現在 Active になっているコネクションには、コネクション名の横に *(アスタリスク) がついています。
もし *(アスタリスク) がついていない場合は、Deactivate 作業はスキップし、Activate を行ってください。
対象のコネクションにカーソルを合わせ、 <Deactivate> を選択すると、 *(アスタリスク) が消えます。
Deactivate 後、再び対象のコネクションにカーソルを合わせ、 <Activate> を選択すると、ネットワーク設定が反映され、
コネクション名の横に *(アスタリスク) が表示されます。
有線 LAN インターフェース設定の永続化
|
有線 LAN インターフェース 1(eth0) のコネクション設定ファイルを永続化します。
| |
有線 LAN インターフェース 2(eth1) のコネクション設定ファイルを永続化します。
|
3G/LTE(ttyCommModem) の接続設定
|
3G/LTE(ttyCommModem) のコネクションを作成します。
| |
3G/LTE(ttyCommModem) のコネクション設定ファイルを永続化します。
|
ファイアーウォールの設定
3G/LTE(ttyCommModem) のファイアーウォールを設定します。
今回は、外部から 50000 番ポートにアクセスされた場合のみ通信を許可するよう設定します。
また、 ICMP プロトコルと DNS( 53 番ポート) も許可しています。 ここでは、iptables を用いて設定を行っています。IPv6 の場合は、以下の手順の iptables の箇所を ip6tables に置き換えて実行してください。
|
3G/LTE のネットワークデバイス ppp0 について、50000 番ポートのパケットを許可するよう設定します。
| |
3G/LTE のネットワークデバイス ppp0 について、 DNS ( 53 番ポート) を許可します。
| |
3G/LTE のネットワークデバイス ppp0 について、 ICMP プロトコルを許可します。なお、 IPv6 の場合は icmp を icmpv6 に置き換えてください。
| |
3G/LTE のネットワークデバイス ppp0 について、全てのパケットを破棄するよう設定します。
|
iptables の設定は overlayfs に関係なくシャットダウンや再起動でシステム OFF すると消えてしまうため、以下の手順で設定を永続化します。
|
iptables の設定をファイルに書き出します。コマンドを実行すると、 /etc/iptables/rules-save に保存されます。
| |
書き出したファイルを永続化し、-p オプションで OS アップデートの際にもファイルが削除されないように設定します。
| |
iptables サービスを有効にします。これにより、Armadillo-IoT ゲートウェイ G4 が起動時に iptables が自動起動します。
| |
iptables サービスの自動起動設定を永続化し、-p オプションで OS アップデートの際にも設定が保持されるように設定します。
|
| |
---|
ipv6 を使う予定がない場合は完全に無効化できます。IPv4 にフィルターが必要と判断した場合には必ず IPv6 に同様なフィルターを設定するか、IPv6 を無効化してください。
|
設定確認
ネットワークデバイスの状態確認
設定したネットワークデバイスの状態が connected になっていることを確認します。
IP アドレス設定確認
ルーティングテーブルの確認
ファイアーウォールの確認
コンテナ作成例
ここでは、ホスト OS の 50000 番ポートへのアクセスでコンテナの 22 番ポートに接続することができるコンテナの作成手順を紹介します。
コンテナ内での IP アドレスの設定等は必要ありません。 なお、本項では podman_start を使用してコンテナを作成・起動する方法を記載しています。
「podmanコンテナとアプリケーションの自動実行」 で述べている通り、Armadillo Base OS では /etc/containers/ 以下の .conf ファイルを参照し、
記述されている内容に従ってコンテナを作成します。 以下に、 IPv4 と IPv6 それぞれの .conf ファイル作成例を記載します。
また、作成した .conf ファイルについても永続化の設定が必要なため、あわせて記載しています。
|
コンテナの22番ポートをホストの50000番ポートに割り当てます。
| |
自動起動を無効にしています。自動起動させたい場合は、この行を削除してください。
| |
設定ファイル my_container.conf ファイルを永続化します。
|
|
--ipv6 オプションを指定してユーザー定義のネットワークを作成します。
| |
コンテナの22番ポートをホストの50000番ポートに割り当てます。
| |
作成したユーザー定義のネットワーク名を指定します。
| |
自動起動を無効にしています。自動起動させたい場合は、この行を削除してください。
| |
設定ファイル my_net.conf を永続化します。
| |
設定ファイル my_container.conf を永続化します。
|
コンテナの起動方法はそれぞれ下記の通りです。
|
コンテナを起動します。
|
|
コンテナ起動前にユーザー定義のネットワークを作成します。
なお、my_net.conf 設定後はArmadillo-IoT ゲートウェイ G4 起動時に自動的にネットワーク my_net が作成されます。
| |
コンテナを起動します。
|
また、下記のコマンドでコンテナ内に入ることができます。
量産製造時に一括してネットワーク設定を行う場合の方法を紹介します。
以下のいずれの場合であっても、 「クローンインストールディスクを用いてイメージ書き込みを行なう」 に示す通り、クローンインストールディスクを用いてネットワーク設定を行います。 11.6.4.1. 全ての機器が同一の設定内容の場合設定する 3G/LTE の接続情報が同一の場合など、全ての機器で同一のネットワーク設定となる場合は、
8章量産用インストールディスクの作成 の手順に従って作成したクローンインストールディスクを用いることで一括して設定を行うことができます。 11.6.4.2. 機器ごとに設定内容が異なる場合機器ごとに異なる固定 IP アドレスを設定する場合など、各機器でネットワーク設定が異なる場合は、
「インストール時に任意の処理を行なう」 に示す通り、インストール時に任意の処理を行うようにすることで異なる設定を行うことができます。 異なる固定 IP アドレスを設定する場合の手順については、 「個体ごとに異なる固定IPアドレスを設定する」 に記載しています。
また、インストール時に実行する処理の内容を変えることで、固定 IP アドレス以外にも様々なネットワーク設定を柔軟に行うことができます。 ここでは、運用開始後にネットワークの設定を変更する場合の方法について記述します。 運用中の機器に対してネットワークの設定の変更は SWUpdate で実施します。 SWUpdate の詳細は Armadillo-IoT ゲートウェイ G4 の製品マニュアルの「Armadilloのソフトウェアをアップデートする」を参照してください。 11.6.5.1. SWUpdate でネットワーク設定を変更するSWUpdate は swu というイメージ形式のファイルを用いてアップデートを実行します。 以下は 有線 LAN インターフェース(eth0) の ネットワーク設定を変更する場合の手順を例に説明します。
このパターンでは、 swu イメージにコネクションファイルを含める形となります。 swu ファイル作成に必要となるツール mkswu については、Armadillo-IoT ゲートウェイ G4 の製品マニュアルの「Armadilloのソフトウェアをアップデートする」を参照してください。
なお、 「SWUpdateによる初回アップデート」 に示す mkswu を用いた初回アップデート作業が完了していることを前提としています。
swu イメージの作成
swu イメージの作成は、 ATDE 上で実施します。 ATDE 上にコネクションファイルをコピーし、パーミッションを 600 に設定します。
|
コネクションファイルをコピーします。コピー元のパスは適宜読み替えてください。
| |
コネクションファイルのパーミッションを 600 に設定します。
|
swu イメージ作成に用いる network-setting.desc ファイルを以下の通り作成します。
|
ethernet-eth0.nmconnection を Armadillo-IoT ゲートウェイ G4 の /etc/NetworkManager/system-connections/ に配置します。
|
mkswu を実行して swu イメージを作成します。
|
初回アップデート作業時に指定した鍵のパスワードを入力してください。
|
swu イメージのインストール
swu イメージの Armadillo-IoT ゲートウェイ G4 への転送方法ですが、既にネットワークに接続されている場合はリモートアップデートで実施、ネットワーク接続していない機器に対し設定を行う場合は USBメモリを用いて実施するなど、
それぞれの環境に応じて選択してください。 インストール方法については、Armadillo-IoT ゲートウェイ G4 の製品マニュアルの「Armadilloのソフトウェアをアップデートする」を参照してください。
| |
| | | |
| |