応用編

poweroffコマンドを実行してシャットダウンモードに遷移した場合、電源の切断・接続のみでアクティブモードに遷移が可能です。 poweroffコマンドの実行例を次に示します。

[armadillo ~]# poweroff
[  OK  ] Stopped target Timers.
[  OK  ] Stopped Daily man-db regeneration.
[  OK  ] Stopped Daily rotation of log files.

※省略

[39578.876586] usb usb1: USB disconnect, device number 1
[39578.882754] ci_hdrc ci_hdrc.0: USB bus 1 deregistered
[39578.888133] reboot: Power down

aiot-alarm-poweroffコマンドを実行することで、シャットダウンモードに遷移後、 RTCのアラーム割り込みをトリガで起床（アクティブモードに遷移）することができます。 なお、RTC を起床要因に使って間欠動作させる場合は、 「RTC を使用する」 を参考に、必ず RTC の日時設定を行ってください。

	RTC 未設定によるエラーが発生した場合、シャットダウンモードへの遷移は行われません。

[armadillo ~]# aiot-alarm-poweroff +[現在時刻からの経過秒数]

シャットダウンモードに遷移し、300秒後にアラーム割り込みを発生させるには、次のようにコマンドを実行します。

[armadillo ~]# aiot-alarm-poweroff +300
aiot-alarm-poweroff: alarm_timer +300 second

現在時刻からの経過秒数は180秒以上を指定する必要があります。

aiot-set-wake-triggerコマンドの書式と設定可能なパラメータを以下に示します。

[armadillo ~]# aiot-set-wake-trigger [TRIGGER] [enabled|disabled]

コンソール(/dev/ttymxc2)から入力があった場合にスリープモードから起床するには、次に示すコマンドを実行します。

[armadillo ~]# aiot-set-wake-trigger uart3 enabled
aiot-set-wake-trigger: uart3 enabled

[armadillo ~]# aiot-sleep
aiot-sleep: Power Management suspend-to-ram
[ 1767.050404] PM: suspend entry (deep)
[ 1767.054019] PM: Syncing filesystems ...
[ 1767.236546] fec 2188000.ethernet eth0: Link is Up - 100Mbps/Full -
flow control rx/tx
[ 1767.428714] done.
[ 1767.431262] Freezing user space processes ... (elapsed 0.001 seconds) done.
[ 1767.439582] OOM killer disabled.
[ 1767.442834] Freezing remaining freezable tasks ... (elapsed 0.001
seconds) done.
[ 1767.451485] Suspending console(s) (use no_console_suspend to debug)

※ コンソールに入力

[ 1767.567686] OOM killer enabled.
[ 1767.570875] Restarting tasks ... done.
[ 1767.606048] PM: suspend exit
aiot-sleep: change mode CPU Idle

RTCアラーム割り込みでの起床を行う場合、パラメーター設定が異なります。 なお、RTC を起床要因に使って間欠動作させる場合は、 「RTC を使用する」 を参考に、必ず RTC の日時設定を行ってください。

[armadillo ~]# aiot-set-wake-trigger rtc [enabled|disabled] <現在時刻からの経過秒数>

現在時刻からの経過秒数 は60秒以上を指定する必要があります。

300秒後にRTCアラーム割り込みを発生させ、スリープモードから起床させるコマンド実行例を以下に示します。

[armadillo ~]# aiot-set-wake-trigger rtc enabled +300
aiot-set-wake-trigger: rtc enabled
aiot-set-wake-trigger: alarm_timer +300 second

[armadillo ~]# aiot-sleep
aiot-sleep: Power Management suspend-to-ram
[ 1767.050404] PM: suspend entry (deep)
[ 1767.054019] PM: Syncing filesystems ...
[ 1767.236546] fec 2188000.ethernet eth0: Link is Up - 100Mbps/Full -
flow control rx/tx
[ 1767.428714] done.
[ 1767.431262] Freezing user space processes ... (elapsed 0.001 seconds) done.
[ 1767.439582] OOM killer disabled.
[ 1767.442834] Freezing remaining freezable tasks ... (elapsed 0.001
seconds) done.
[ 1767.451485] Suspending console(s) (use no_console_suspend to debug)

※ 約300秒待つ

[ 1767.567686] OOM killer enabled.
[ 1767.570875] Restarting tasks ... done.
[ 1767.606048] PM: suspend exit
aiot-sleep: change mode CPU Idle

	アラーム割り込みは分単位(毎分00秒)で発生します。そのため、300秒(5分)を指定した場合、実際に割り込みが発生するまでの時間は5分00秒〜5分59秒の間となります。

すべての起床要因をクリアするには次に示すコマンドを実行します。ユーザースイッチによる起床設定は無効化できません。

[armadillo ~]# aiot-set-wake-trigger all disabled
aiot-set-wake-trigger: clear_all disabled

/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 を作成しました。

ここでは、「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 imx-boot_armadillo_x2 

# 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-x2-[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 を作成しました。

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 

	/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"

イメージからコンテナを作成するためには、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 ~]#

"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> で出力を確認してください。

コンテナを作成するためのイメージは、イメージ一覧を表示する podman images コマンドで確認できます。

[armadillo ~]# podman images
REPOSITORY                TAG     IMAGE ID      CREATED      SIZE
docker.io/library/alpine  latest  9c74a18b2325  2 weeks ago  4.09 MB

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

[armadillo ~]# podman images --help

作成済みコンテナ一覧を表示するためには 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

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

[armadillo ~]# podman ps --help

作成済みのコンテナを起動するためには 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

-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

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

[armadillo ~]# podman start --help

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

[armadillo ~]# podman stop my_container
my_container

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

[armadillo ~]# podman stop --help

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

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

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

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

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

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

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

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

[armadillo ~]# podman rm --help

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

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

[armadillo ~]# 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 図6.27 Read-Onlyのイメージを削除する実行例

実行中のコンテナに接続し、コンテナ内で指定したコマンドを実行するには 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
[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

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

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

[container ~]# exit

podman exec コマンドから抜けても、コンテナがまだ実行中です。コンテナを停止したい場合は podman stop sleep_container か podman kill sleep_container で停止して podman rm sleep_container でそのコンテナを削除してください。

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

[armadillo ~]# podman exec --help

複数のコンテナを実行している環境で、それらのコンテナ間で通信を行う方法を示します。 これにより、例えば 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'
5e645f5e40fc096ad0bea323a00bebebbda4bd825a5e8d12103f752d8868692e

コンテナに割り当てられた 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

これらの 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

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

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

[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  localhost/podman-pause:4.3.1-1683096588               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

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

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

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

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

.conf ファイルで使用できる各種パラメータについては、「コンテナ起動設定ファイルを作成する」を参照してください。

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

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

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

[armadillo ~]# cat /etc/atmark/containers/nginx.conf
set_image docker.io/library/nginx:alpine
add_ports 80:80
set_ip 192.168.100.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

コンテナと同じく、 /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 で設定することができます。

.conf ファイルで使用できる各種パラメータについては、「コンテナ起動設定ファイルを作成する」を参照してください。

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

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

	コンテナの設定によって podman の socket へのパスが自動設定されない場合もあります。 podman --remote でエラーが発生した場合に CONTAINER_HOST=unix:/path/to/podman.sock で socket へのパスを設定してください。

Armadillo のホスト側の udev rules からコンテナを起動する場合は podman_start 等を直接実行すると udev の子プロセス管理によってコンテナが停止されますので、その場合はサービスを有効にし、 podman_start --create <container> コマンドまたは set_autostart create　の設定でコンテナを生成した上 podman --remote start <container> で起動してください。

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

起動時にコンテナを起動するにはイメージを eMMC に書き込む必要があります。 開発が終わって運用の場合は 「イメージを SWUpdate で転送する」 でコンテナのイメージを転送します。この場合は読み取り専用の app パーティションのサブボリュームに展開します。

開発の時に以下の abos-ctrl podman-rw か abos-ctrl podman-storage --disk のコマンドを使って直接にイメージを編集することができます。

	ここで紹介する内容はコンテナのイメージの管理の説明です。データベース等のコンテナから書き込みが必要な場合には 「コンテナの変更を保存する」 にあるボリュームの説明を参照してください。

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

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 
List of 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? ([C]opy (default), [N]othing, [D]elete)
copy 
Create a snapshot of '/mnt/boot_1/containers_storage' in '/mnt/new_storage'
Getting image source signatures
Copying blob 8ec3165d6e61 done
Copying config 4a49b68e7c done
Writing manifest to image destination
Storing signatures
Delete subvolume (no-commit): '/mnt/new_storage'
Merging 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

	podman が壊れやすいので、デフォルトの「abos-ctrl podman-storage --tmpfs」で運用することを推奨しますが、tmpfs の容量が小さくてイメージの操作には向いてません。 開発時には「abos-ctrl podman-storage --disk」の状態で作業を行い、運用時には「abos-ctrl podman-storage --tmpfs」に戻してください。 戻る際に「copy」を選択肢する場合は一時的なストレージをそのまま使いつづけますので、すべての変更が残ります。

	SWUpdate でアップデートをインストールする際には、/var/lib/containers/storage_readonly ディレクトリの不要になったイメージを自動的に削除します。 自動起動させる予定がなくても、「コンテナ起動設定ファイルを作成する」 を参考にして、 /etc/atmark/containers/*.conf を使ってください。 set_autostart no を設定することで自動実行されません。

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

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

VSCode 上で ABOSDE(Armadillo Base OS Development Environment) から、 Armadillo のコンテナイメージを全て削除する SWU イメージを作成することができます。

VSCode の左ペインの [COMMON PROJECT COMMAND] から [Generate Container Clear Swu] を実行すると、SWU イメージが作成されます。 SWU イメージは ~/mkswu/container_clear.swu に保存されます。

この SWU イメージを 「SWU イメージのインストール」 を参照して Armadillo へインストールしてください。

図6.38 Armadillo 上のコンテナイメージを削除する

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

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

[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

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/platform-xhci-hcd.1.auto-usb-0:1.1:1.0-video-index1" "/dev/video3"

コンテナパスに「:」を含むようなパスは設定できません。

add_volumes [ホストパス]:[コンテナパス]:[オプション]

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

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

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

オプションは 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 図6.41 ボリュームを shared でサブマウントを共有する例 マウントを行うコンテナに shared の設定とマウント権限 (SYS_ADMIN) を与えます。 マウントを使うコンテナに slave だけを設定すれば一方にしか共有されません。 USB デバイスをマウントします。 マウントされたことを確認します。

add_hotplugs [デバイスタイプ]

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

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

例: add_hotplugs input

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

表6.5「add_hotplugsオプションに指定できる主要な文字列」に示した文字列の他にも、/proc/devicesの数字から始まる行に記載されている文字列を指定することができます。 図6.42「/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
: (省略)

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

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

例: add_hotplugs input video4linux sd

add_armadillo_env

アットマークテクノが設定した個体識別情報をコンテナの環境変数として追加することができます。

例: add_armadillo_env

add_armadillo_env を設定することで追加されるコンテナの環境変数について、表6.6「add_armadillo_envで追加される環境変数」に示します。

表6.6「add_armadillo_envで追加される環境変数」に示した環境変数をコンテナ上で確認する場合、図6.43「add_armadillo_envで設定した環境変数の確認方法」に示すコマンドを実行してください。ここでは、個体番号の環境変数を例に示します。

[container ~]# echo $AT_SERIAL_NUMBER
00C900010001

お客様が独自の環境変数をコンテナに追加する場合は図5.6「個体番号の環境変数をconfファイルに追記」を参考にconfファイルを編集してください。

set_pod [ポッド名]

「podでコンテナのネットワークネームスペースを共有する」で作成した pod の名前を入れてコンテナを pod 内で起動します。

例: set_pod mypod

set_network [ネットワーク名]

この設定に「networkの作成」で作成したネットワーク以外に none と host の特殊な設定も選べます。

none の場合、コンテナに localhost しかないネームスペースに入ります。

host の場合はOSのネームスペースをそのまま使います。

例: set_network mynetwork

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_init no

コンテナのメインプロセスが PID 1 で起動していますが、その場合のデフォルトの信号の扱いが変わります: SIGTERM などのデフォルトハンドラが無効です。

そのため、init 以外のコマンドを set_command で設定する場合は podman-init のプロセスを PID 1 として立ち上げて、設定したコマンドをその子プロセスとして起動します。

例: set_init no

set_autostart no または set_autostart create

Armadillo の起動時にコンテナを自動起動しないように設定できます。

create を指定した場合はコンテナは生成されており、podman start <name> で起動させることができます。

no を指定した場合は podman_start <name> で起動させることができます。

	コンフィグに記載していないイメージはアップデートの際に削除されますので、そういったイメージに対して設定してください。

set_command [コマンド]

コンテナを起動するときのコマンド。設定されなかった場合、コンテナイメージのデフォルトを使います。

例: set_command /bin/sh -c "echo bad example"

add_args [引数]

ここまでで説明した設定項目以外の設定を行いたい場合は、この設定で podman run に直接引数を渡すことができます。

例：add_args --cap-add=SYS_TTY_CONFIG --env=XDG_RUNTIME_DIR=/run/xdg_home

「VSCode を使用して Armadillo のセットアップを行う」を参照して、 Armadillo のセットアッププロジェクトを作成しておいてください。

VSCode の左ペインの [my_project] から [Generate at-debian-image container setup swu] を実行してください。

図6.44 at-debian-image のコンテナイメージをインストールする SWU ファイルを作成する

作成した SWU ファイルは container_setup/at-debian-image/at-debian-image.swu に保存されています。 この SWU イメージを 「SWU イメージのインストール」 を参照して Armadillo へインストールしてください。

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

[armadillo ~]# tar xzf at-debian-image-dockerfile-[VERSION].tar.gz
[armadillo ~]# cd at-debian-image-dockerfile-[VERSION]
[armadillo ~]# abos-ctrl podman-storage --disk
[armadillo ~]# podman build -t at-debian-image:latest .
:
: (省略)
:
[armadillo ~]# podman images
REPOSITORY                 TAG         IMAGE ID      CREATED             SIZE
localhost/at-debian-image  latest      c8e8d2d55456  About a minute ago  233 MB
docker.io/library/debian   bullseye    723b4a01cd2a  18 hours ago        123 MB

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

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

[armadillo ~]# podman load -i at-debian-image-[VERSION].tar
:
: (省略)
:
[armadillo ~]# podman images
REPOSITORY                 TAG         IMAGE ID      CREATED       SIZE
localhost/at-debian-image  [VERSION]   93a4ec873ac5  17 hours ago  233 MB
localhost/at-debian-image  latest      93a4ec873ac5  17 hours ago  233 MB

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

基本的にコンテナの 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

コンテナ内の 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

	podman はデフォルトで 10.88.0.0/16 を使います。 他に使用しているIPアドレスと被った場合等はコンテナに別のIPアドレスを設定してください。

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

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

コンテナを作成する際に、上記で作成したネットワークと設定したい IP アドレスを渡すことで、 コンテナの IP アドレスを固定することができます。 以下の例では、IPアドレスを 192.168.1.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.168.1.10
[armadillo ~]# podman_start network_example
Starting 'network_example'
3ea8c9031bf833228908bd73d8929b1d543b189b436c218e0634e0d39409e100

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

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

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

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

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

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

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

ここでは、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

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

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

作成したユーザで 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

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

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

ここでは、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

コンテナ内にユーザアカウントを作成し、このユーザで 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: （パスワードを入力）

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

[container ~]# smbd

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

ここでは、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

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

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

コンテナ内で動作するアプリケーションからソフトウェアウォッチドックタイマーを扱うためには、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

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

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

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

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

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

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

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

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

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 

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

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

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

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

ここでは、データの送信先となる 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 にグループ登録で設定を行った場合は、再度環境の構築および設定を行ってください。

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

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

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

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

	以下では可視化の手順を記載していますが、実際にデバイスから届いているデータを確認する場合は、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 を例に記載します。

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

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

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

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

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

Rest API は ABOS Web のパスワードと Rest API 用のトークンで認証されます。

また、接続可能なネットワークにも制限をかけております。初期状態では、同一サブネットからのアクセスのみ許容しています。 同一サブネット外の IP アドレスからアクセスしたい場合は設定が必要です。 設定方法は 「ABOS Web へのアクセス」 を参照してください。

各リクエストは以下のどちらかの Authorization ヘッダーで認証されます：

また、トークンには権限も設定できます。Admin で生成されたトークンはすべてのインターフェースにアクセスできますが、 一部のインターフェースしか使用しない場合はそのインターフェースに必要な権限だけを持つトークンを生成してください。

トークンの管理は ABOS Web の「設定管理」ページで行えます:

図6.85 設定管理の Rest API トークン一覧表示

各 Rest API の使用例を説明します。使用例では以下を前提としています。：

[ATDE ~]$ alias curl_rest='curl -k -H "$AUTH" -w "\nhttp code: %{http_code}\n" '

	この章で説明する例では、curl のオプションに -k を指定して証明書を無視するようにしています。 もし、証明書を使用したい場合は以下のように設定してください。 [ATDE ~]$ openssl s_client -showcerts -connect armadillo.local:58080 </dev/null 2>/dev/null | openssl x509 -outform PEM > abosweb.pem [ATDE ~]$ CERT="$PWD/abosweb.pem" [ATDE ~]$ alias curl_rest='curl -H "$AUTH" --cacert "$CERT" -w "\nhttp code: %{http_code}\n" '

インターフェースの一部にはパラメータを取るものがあります。パラメータがある場合は json (Content-Type を application/json に設定する）と form（デフォルトの application/x-www-form-urlencoded でのパラメータ）のどちらでも使用可能です。

インターフェースの出力がある場合は json object で出力されます。 今後のバージョンアップで json object のキーが増える可能性があるため、 出力された値を処理する場合はその点に留意してください。

エラーの場合は json object の「error」キーに文字列のエラーが記載されています。 http のステータスコードも 50x になります。

エラーの例：

[ATDE ~]$ curl_rest -X DELETE https://armadillo.local:58080/api/tokens/3b2d830d-2f64-4e76-9e59-316da82eefc4
{"error":"No such token"}
http code: 500

トークン管理のためのインターフェースは以下のとおりです：

[ATDE ~]$ curl_rest https://armadillo.local:58080/api/swu/status
{"rollback_ok":true,"last_update_timestamp":1703208559,"last_update_versions":{"custom":[null,"54"],"extra_os.custom":["53","54"]}}
http code: 200

nmcli は NetworkManager を操作するためのコマンドラインツールです。 図6.86「nmcli のコマンド書式」に nmcli の書式を示します。このことから、 nmcli は「オブジェクト (OBJECT) というものが存在し、 それぞれのオブジェクトに対してコマンド (COMMAND) を実行する。」という書式でコマンドを入力することがわかります。 また、オブジェクトそれぞれに help が用意されていることもここから読み取れます。

nmcli [ OPTIONS ] OBJECT { COMMAND | help }

登録されているコネクションの一覧表示するには、図6.87「コネクションの一覧表示」に示すコマンドを実行します。 ^[7]

[armadillo ~]# nmcli connection
NAME                UUID                                  TYPE      DEVICE
Wired connection 1  xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx  ethernet  eth0

表示された NAME については、以降 [ID] として利用することができます。

コネクションを有効化するには、図6.88「コネクションの有効化」に示すコマンドを実行します。

[armadillo ~]# nmcli connection up [ID]

コネクションを無効化するには、図6.89「コネクションの無効化」に示すコマンドを実行します。

[armadillo ~]# nmcli connection down [ID]

コネクションを作成するには、図6.90「コネクションの作成」に示すコマンドを実行します。

[armadillo ~]# nmcli connection add con-name [ID] type [type] ifname [interface name]

[ID] にはコネクションの名前(任意)、[type] には ethernet、wifi といった接続タイプ、 [interfacename] にはインターフェース名(デバイス)を入力します。 これにより /etc/NetworkManager/system-connections/ に[ID]の名前でコネクション ファイルが作成されます。このファイルを vi などで編集し、コネクションを修正する ことも可能です。

Armadillo-IoT ゲートウェイ A6E を再起動したときにコネクションファイルが消えてしまわないように、 persist_file コマンドで永続化する必要があります。 persist_file コマンドに関する詳細は 「persist_file について」 を参照してください。

[armadillo ~]# persist_file /etc/NetworkManager/system-connections/<コネクションファイル名>

別の Armadillo-IoT ゲートウェイ A6E からコネクションファイルをコピーした場合は、コネクションファイルの パーミッションを 600 に設定してください。 600 に設定後、 nmcli c reload コマンドでコネクションファイルを再読込します。 [armadillo ~]# chmod 600 /etc/NetworkManager/system-connections/<コネクションファイル名> [armadillo ~]# persist_file /etc/NetworkManager/system-connections/<コネクションファイル名> [armadillo ~]# nmcli c reload swu イメージを使用してコネクションファイルのアップデートを行う場合は、 swu イメージに含めるコネクションファイルのパーミッションを 600 に設定してから、 swu イメージを作成してください。 アップデート実行時には swu イメージ作成時のパーミッションが維持されるため、 上記のコマンド実行手順は不要です。 swu イメージに関しては 「SWU イメージのインストール」 を参考にしてください。

コネクションを削除するには、図6.92「コネクションの削除」に示すコマンドを実行します。

[armadillo ~]# nmcli connection delete [ID]

これにより /etc/NetworkManager/system-connections/ のコネクションファイルも同時に削除されます。 コネクションの作成と同様に persist_file コマンドで永続化する必要があります。

[armadillo ~]# persist_file -d /etc/NetworkManager/system-connections/<コネクションファイル名>

表6.18「固定 IP アドレス設定例」の内容に設定する例を、 図6.94「固定 IP アドレス設定」に示します。

[armadillo ~]# nmcli connection modify [ID] \
ipv4.method manual ipv4.addresses 192.0.2.10/24 ipv4.gateway 192.0.2.1

DHCP に設定する例を、図6.95「DHCP の設定」に示します。

[armadillo ~]# nmcli connection modify [ID] ipv4.method auto

	-ipv4.addresses のように、プロパティ名の先頭に "-" を付けることで設 定したプロパティを削除することができます。反対に "+" を付けることで プロパティを追加することができます。

DNS サーバーを指定する例を、図6.96「DNS サーバーの指定」に示します。

[armadillo ~]# nmcli connection modify [ID] ipv4.dns 192.0.2.1

有効化されているコネクションを修正した場合、かならず修正したコネクションを再度有効化してください。

[armadillo ~]# nmcli connection down [ID]
[armadillo ~]# nmcli connection up [ID]

デバイスの一覧(デバイス名、タイプ、状態、有効なコネクション)を確認するには、図6.98「デバイスの一覧表示」に示すコマンドを実行します。

[armadillo ~]# nmcli device
DEVICE  TYPE      STATE        CONNECTION
eth0    ethernet  connected    Wired connection 1
lo      loopback  unmanaged    --

デバイスを接続するには、図6.99「デバイスの接続」に示すコマンドを実行します。

[armadillo ~]# nmcli device connect [ifname]

	デバイスを接続するには、接続しようとしているデバイスの有効なコネクションが必要です。 "Error: neither a valid connection nor device given" というメッセージが表示された場合には、 nmcli connection などで有効なコネクションが存在するかを確認してください。

デバイスを切断するには、図6.100「デバイスの切断」に示すコマンドを実行します。

[armadillo ~]# nmcli device disconnect [ifname]

LTEデータ通信を利用するには、通信事業者との契約が必要です。契約時に通信事業者から貸与されたnanoSIM(UIMカード)とAPN情報を準備します。

	Armadillo-IoT ゲートウェイ A6E Cat.1 及び Cat.M1 モデルでの動作検証済み nanoSIM (料金プラン)に関しては、 Armadillo サイトの「Armadillo-IoTゲートウェイ 動作確認済みSIM一覧」を確認ください。 Armadillo-IoTゲートウェイ 動作確認済みSIM一覧

	Armadillo-IoT ゲートウェイ A6E の電源が切断されていることを確認してから nanoSIM(UIMカード)を取り付けてください。

	本製品は、nanoSIMスロットを搭載しています。 標準/microSIMサイズのSIMカードをnanoSIMサイズにカットしたもの、サイズの異なるものを使用すると、nanoSIMスロットが故障する原因となります。 これらを使用し本製品が故障した場合は、保証期間内であっても保証適用外となります。

nanoSIM(UIMカード)の切り欠きを挿入方向に向け、刻印面を上にして挿入してください。挿入位置などは、図3.14「Armadillo-IoT ゲートウェイ A6Eの接続例」 を参照してください。

APNの設定を行うには、表6.19「APN 設定情報」に示す情報が必要です。モデル毎の文字長を超える設定はできませんので、SIM の料金プランを選択する際にはご注意ください。特に Cat.1 モデル (ELS31-J) の最大パスワード文字数が短いのでご注意ください。

Cat.1 モデル搭載の LTE モデム ELS31-J は、USB インターフェースで Armadillo のプロセッサと接続しています。USB インターフェースは USB CDC ACM、USB CDC Ethernet として動作します。

この USB CDC Ethernet によって LTE モジュールと Armadillo Base OS の間で LAN を構成します。

それぞれの IP アドレスの割り当てを、図6.102「Cat.1 モデル (ELS31-J) LTE ネットワーク構成」 に示します。Armadillo Base OS 側の IP アドレスを 24 ビットマスクのアドレス空間で示しているのは、 LTE モジュール内部で動作している DHCP サーバーがIPアドレスを提供するためです。

図6.102 Cat.1 モデル (ELS31-J) LTE ネットワーク構成

Cat.1 モデル搭載の LTE モデム ELS31-J は、デフォルトでファイアーウォールが有効となっており、外部からのアクセスが出来ないようになっております。

ELS31-J のファイアーウォール設定を変更したい場合、設定ファイル(/etc/atmark/els31.conf)を作成します。

設定ファイルの記載例として、サンプルファイル(/etc/atmark/els31.conf.example)がありますので、こちらをリネームまたはコピーしてご利用ください。

ファイアーウォールを有効にする場合は図6.103「ELS31-J ファイアーウォールを有効にする」 に示すとおり FIREWALL="enable" に設定します。

#!/bin/sh

FIREWALL="enable"

無効にする場合は図6.104「ELS31-J ファイアーウォールを無効にする」に示すとおり FIREWALL="disable" に設定します。

#!/bin/sh

FIREWALL="disable"

編集後、図6.105「ELS31-J ファイアーウォール設定の永続化」に示す設定ファイルの永続化を実施した後に Armadillo の再起動を行うことで ELS31-J のファイアーウォールの有効・無効を変更できます。

[armadillo ~]# persist_file /etc/atmark/els31.conf

ファイアーウォール設定を変更する必要がない場合は、図6.106「ELS31-J ファイアーウォール設定ファイルの削除」に示すとおり設定ファイル (/etc/atmark/els31.conf) を削除するか、図6.107「ELS31-J ファイアーウォール設定を行わない場合の設定ファイル」に示すとおり設定ファイル(/etc/atmark/els31.conf) の FIREWALL の行を # でコメントアウトしてください。

[armadillo ~]# persist_file -d /etc/atmark/els31.conf

#!/bin/sh

#FIREWALL="enable"

Cat.M1 モデル搭載の LTE モデム EMS31-J 起動時に設定する内容を、設定ファイル(/etc/atmark/ems31-boot.conf)に記載します。

設定ファイルの記載例として、サンプルファイル(/etc/atmark/ems31-boot.conf.example)がありますので、こちらをリネームまたはコピーしてご利用ください。

/etc/atmark/ems31-boot.conf に設定できる内容を表6.20「ems31-boot.conf の設定内容」に示します。

ems31-boot.conf のフォーマットは以下の通りです。

PSM (Power Save Mode) の設定値を表6.21「psm の tau と act-time に設定可能な値」に示します。disable にしない場合、tau (Periodic TAU cycle (T3412)) は act_time (Active time (T3324)) より大きい値にする必要があります。

eDRX (extended Discontinuous Reception) の設定値を表6.22「edrx の pcl と ptw に設定可能な値」に示します。disable にしない場合、pcl (Paging Cycle Length) は ptw (Paging Time Window eDRX) より大きい値にする必要があります。

表6.23「APN情報設定例」の内容に設定する例を図6.108「LTEのコネクションの作成」に示します。

ネットワークデバイス [wwan] は、表6.24「通信モジュールのネットワークデバイス」 を参照ください。

[armadillo ~]# nmcli connection add type gsm ifname [wwan] apn [apn] user [user] password [password]
Connection 'gsm-[wwan]' (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx) successfully added.

コネクション設定を永続化するには、以下のコマンドを入力してください。設定を永続化すると、Armadillo 起動時に自動的にデータ接続を行うようになります。

同一インタフェースへの設定が複数存在する場合、 gsm-[wwan]-1.nmconnection など後ろに数値が付与されますので、図6.108「LTEのコネクションの作成」 入力時のメッセージで生成されたファイル名を確認した上で永続化を実施ください。

[armadillo ~]# persist_file /etc/NetworkManager/system-connections/gsm-[wwan].nmconnection

マルチキャリア SIM などを使用する際、MCC (Mobile Country Code) と MNC (Mobile Network Code) を指定してコネクションを作成すると LTE ネットワークに接続できることがあります。指定する場合は 図6.110「MCC/MNC を指定した LTE コネクションの作成」 に示すコマンドを実行してください。

[mccmnc] には 44010 などの数字を入力してください。実際に設定する値に関しては、ご契約の通信事業者へお問い合わせください。

Cat.1 モデルに搭載の LTE モデム ELS31-J はドコモ網のみに接続可能ですので、この設定は不要です。

[armadillo ~]# nmcli connection add type gsm ifname [wwan] apn [apn] user [user] password [password] gsm.network-id [mccmnc]

LTEのコネクションの認証方式は、デフォルトで CHAP に設定されています。PAP認証を有効にしたコネクションを作成する場合は図6.111「PAP認証を有効にしたLTEコネクションの作成」 に示すコマンドを実行してください。

[armadillo ~]# nmcli connection add type gsm ifname [wwan] apn [apn] user [user] password [password] ppp.refuse-eap true ppp.refuse-chap true ppp.refuse-mschap true ppp.refuse-mschapv2 true ppp.refuse-pap false

	すでにLTEコネクションを作成済みの場合はコネクション設定を削除した後に、図6.111「PAP認証を有効にしたLTEコネクションの作成」を実施してください。

LTEコネクションの作成直後や設定変更後に再起動をせずにコネクションを確立するには、図6.112「LTEのコネクション確立」に示すコマンドを実行します。

[armadillo ~]# nmcli connection up gsm-[wwan]
Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/x)

ご利用になるサービスとの通信を検証する、ICMP に対応しているアドレス (8.8.8.8など) と PING 通信を行うなどの方法で LTE の接続を確認してください。

[armadillo ~]# ping -c 3 8.8.8.8 -I [network device]

[network device] には、表6.17「ネットワークとネットワークデバイス」を参照し、ご使用の製品モデルで使用しているLTEのネットワークデバイスを指定してください。

LTEコネクションを切断するには、図6.114「LTEコネクションを切断する」に示すコマンドを実行します。 LTEコネクションを切断する前に、LTE 再接続サービスを停止しないと再接続処理が実行される為、事前に停止します。

[armadillo ~]# rc-service connection-recover stop 
connection-recover| * Stopping connection-recover ... [ ok ]
[armadillo ~]# nmcli connection down gsm-[wwan] 

LTE 再接続サービスは、LTE のデータ接続の状態を定期的に監視し、切断を検出した場合に再接続を行うサービスです。

Cat.1 モデルは初期状態でこのサービスが有効になっております。

	Cat.M1 モデルでは、LTE モデムの省電力動作のため、初期状態では LTE 再接続サービスを無効にしております。有効にする手順は、図6.121「LTE 再接続サービスを有効にする」を参照ください。LTE 再接続サービスを有効にした場合、定期的に ping 導通確認を実施するため、スリープ状態の LTE モデムが都度起床する、サスペンド状態の LTE モデムですと ping 導通が確認できないなど、制約が発生しますので、その辺りを考慮された上でのご利用をお願いします。

	閉塞 LTE 網を使用する料金プランをご契約で本サービスをご利用になられる際の注意点。 コネクション状態確認時 PING 送付先の初期値は 8.8.8.8 ですが、この IP アドレスに対して ping 導通ができない場合、 ping 導通可能な IP アドレスを指定する必要があります。

SIM カードが挿入されており、NetworkManager に有効な LTE コネクションの設定がされているとき、初期設定では 120 秒に一度コネクションの状態を監視します。オプションで SIM カードの認識ができないときに Armadillo の再起動を実施することも可能です。

コネクションが無効になっている場合、切断状態と判定しコネクションを有効にします。

コネクションが有効になっている場合、特定の宛先に PING を実行します。PING がエラーになったとき切断状態と判定し、コネクションの無効化・有効化を行うことで再接続を実施します。

コネクションの無効化・有効化による再接続を実施しても PING がエラーになる場合、電波のオン・オフまたは LTE モジュールの電源をオン・オフを実施して再接続を実施します。どちらを実施するかは設定ファイルの WWAN_FORCE_RESTART_COUNT に依存します。

WWAN_FORCE_RESTART_COUNT が初期値の 10 である場合、1 から 9 回目は電波のオン・オフを実施し、10 回目はLTE モジュールの電源オン・オフを実施します。それ以降も NG が続く場合、同じく 10 回に一度 LTE モジュールの電源オン・オフを実施します。

Cat.1 モデルの場合、工場出荷状態で本サービスは有効化されており、システム起動時にサービスが自動的に開始されます。PING を実行する宛先は、初期設定では "8.8.8.8" です。

atmark-wwan-utils のバージョンが 1.5.0-r0 以降の場合は、設定ファイルは /etc/atmark/connection-recover.conf を使用します。

設定ファイルの記載例として、サンプルファイル(/etc/atmark/connection-recover.conf.example)がありますので、こちらをリネームまたはコピーしてご利用ください。

atmark-wwan-utils 1.5.0-r0 以降、旧設定ファイル Cat.1 モデル:/etc/atmark/connection-recover/gsm-ttyACM0_connection-recover.conf、Cat.M1 モデル:/etc/atmark/connection-recover/gsm-ttyMux0_connection-recover.conf が存在する場合、/etc/atmark/connection-recover.conf よりも優先して設定ファイルとして使用します。 旧設定ファイルが不要である場合は、図6.115「再接続サービス 旧設定ファイルの削除」に示すとおりに削除してご利用ください。 [armadillo ~]# persist_file -d /etc/atmark/connection-recover/<設定ファイル名> 図6.115 再接続サービス 旧設定ファイルの削除

設定ファイルの概要を表6.25「再接続サービス設定パラメーター」に示します。必要に応じて設定値を変更してください。

設定ファイルが存在しない場合は初期値で動作します。

設定ファイル変更後、変更内容を永続化するには図6.116「LTE 再接続サービスの設定値を永続化する」に示すコマンドを実行してください。

[armadillo ~]# persist_file /etc/atmark/connection-recover.conf

LTE再接続サービスの状態を確認するには、図6.117「LTE 再接続サービスの状態を確認する」に示すコマンドを実行してください。

[armadillo ~]# rc-status | grep connection-recover
 connection-recover                                    [  started 00:43:02 (0) ]

LTE再接続サービスを停止するには、図6.118「LTE 再接続サービスを停止する」に示すコマンドを実行してください。

[armadillo ~]# rc-service connection-recover stop
connection-recover| * Stopping connection-recover ... [ ok ]

LTE再接続サービスを開始するには、図6.119「LTE 再接続サービスを開始する」に示すコマンドを実行してください。

[armadillo ~]# rc-service connection-recover start
connection-recover| * Starting connection-recover ... [ ok ]

独自に接続状態を確認するサービスを実装されるなどの理由で標準のLTE再接続サービスが不要な場合、図6.120「LTE 再接続サービスを無効にする」に示す手順で再接続サービスを永続的に無効にできます。

[armadillo ~]# rc-service connection-recover stop 
connection-recover| * Stopping connection-recover ... [ ok ]
[armadillo ~]# rc-update del connection-recover default 
service connection-recover removed from runlevel default
[armadillo ~]# persist_file -rv /etc/runlevels/default/connection-recover 

LTE再接続サービスを無効化した後、再度有効にする場合、図6.121「LTE 再接続サービスを有効にする」に示す手順を実行してください。

[armadillo ~]# rc-update add connection-recover default 
service connection-recover added to runlevel default
[armadillo ~]# rc-service connection-recover start 
connection-recover| * Starting connection-recover ... [ ok ]
[armadillo ~]# persist_file -rv /etc/runlevels/default/connection-recover 

ここでは ModemManager と mmcli について説明します。

Armadillo-IoT ゲートウェイ A6E にはネットワークを管理する NetworkManager とは別に、モデムを管理する ModemManager がインストールされています。 ModemManager はモバイルブロードバンドデバイス(LTEモジュールなど)の操作および、接続状況の管理などを行います。

ModemManager のコマンドラインツールである mmcli を使用することで、LTE通信の電波強度やSIMカードの情報(電話番号やIMEIなど)を取得することが可能です。mmcli の詳しい使いかたについては man mmcli を参照してください。

ModemManager はモデムデバイスに応じたプラグインを選択して動作します。Cat.M1 モデルでは、cinterion-ems31 という名称のプラグインで動作しています。

認識されているモデムの一覧を取得するには、図6.122「認識されているモデムの一覧を取得する」に示すコマンドを実行します。

[armadillo:~]# mmcli -L
    /org/freedesktop/ModemManager1/Modem/0 [Cinterion] EMS31-J

モデムの情報を取得するには、図6.123「モデムの情報を取得する」に示すコマンドを実行します。

armadillo:~# mmcli -m 0
  --------------------------------
  General  |                 path: /org/freedesktop/ModemManager[number1]/Modem/[number2]
           |            device id: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
  --------------------------------
  Hardware |         manufacturer: Cinterion
           |                model: EMS31-J
           |    firmware revision: XXXXXXXXXXXXXXXXXXXX
           |            supported: lte
           |              current: lte
           |         equipment id: XXXXXXXXXXXXXXX
: (省略)

	モデムの情報を取得するには、SIM カードが取り付けられている必要があります。正しく SIM カードが取り付けられていることを確認してください。

SIM の情報を取得するには、図6.124「SIMの情報を取得する」に示すコマンドを実行します。

[armadillo ~]# mmcli -m 0
: (省略)
SIM      |     primary sim path: /org/freedesktop/ModemManager1/SIM/[number] # [number] を次のコマンドで使用
: (省略)

[armadillo ~]# mmcli -i [number]
  -------------------------------
  General    |              path: /org/freedesktop/ModemManager1/SIM/0
  -------------------------------
  Properties |            active: yes
             |              imsi: XXXXXXXXXXXXXXX
             |             iccid: XXXXXXXXXXXXXXXXXXX
             |       operator id: XXXXX
             |     operator name: XXXXXXXXXXX

回線情報を取得するには、図6.125「回線情報を取得する」に示すコマンドを実行します。

[armadillo ~]# mmcli -m 0
: (省略)
  Bearer   |                paths: /org/freedesktop/ModemManager1/Bearer/[number] # [number] を次のコマンドで使用
: (省略)

[armadillo ~]# mmcli -b [number]
  ------------------------------------
  General            |           path: /org/freedesktop/ModemManager1/Bearer/[bearer number]
                     |           type: default
  ------------------------------------
  Status             |      connected: yes
                     |      suspended: XX
                     |    multiplexed: XX
                     |     ip timeout: XX
  ------------------------------------
  Properties         |            apn: XXXXXXXXXXX
                     |        ip type: XXXXX

無線LANアクセスポイントに接続するためには、次のようにコマンドを実行してコネクションを作成します。

[armadillo ~]# nmcli device wifi connect [essid] password [passphrase]

作成されたコネクションの ID は nmcli connection コマンドで確認できます。

[armadillo ~]# nmcli connection
NAME                UUID                                  TYPE      DEVICE
atmark-4f           e051a1df-6bd7-4bcf-9c71-461af666316d  wifi      wlan0
Wired connection 1  f147b8e8-4a17-312d-a094-8c9403007f6a  ethernet  --

NetworkManagerの仕様により、無線LANの接続にはランダムなMACアドレスが使用されます。搭載されている無線LANモジュール固有のMACアドレスを使用したい場合は、以下の例のようにNetworkManagerの設定を変更し、再起動を行ってください。 [armadillo ~]# echo "[device-mac-randomization]" > /etc/NetworkManager/conf.d/no-random-mac.conf [armadillo ~]# echo "wifi.scan-rand-mac-address=no" >> /etc/NetworkManager/conf.d/no-random-mac.conf [armadillo ~]# echo "[connection-mac-randomization]" >> /etc/NetworkManager/conf.d/no-random-mac.conf [armadillo ~]# echo "wifi.cloned-mac-address=permanent" >> /etc/NetworkManager/conf.d/no-random-mac.conf [armadillo ~]# persist_file /etc/NetworkManager/conf.d/no-random-mac.conf

無線LANで正常に通信が可能か確認します。

同じネットワーク内にある通信機器とPING通信を行います。以下の例では、通信機器が「192.0.2.20」というIPアドレスを持っていると想定しています。

[armadillo ~]# ping 192.0.2.20

	無線LAN以外のコネクションが有効化されている場合、ネットワーク通信に無線LANが使用されない場合があります。 確実に無線LANの接続確認をする場合は、事前に無線LAN以外のコネクションを無効化してください。

NetworkManager を使用し bridge インターフェース (br0) を追加します。同時に AP の IP アドレスも設定します。ここでは 192.0.2.1 を設定しています。

[armadillo ~]# nmcli con add type bridge ifname br0
[armadillo ~]# nmcli con mod bridge-br0 ipv4.method manual ipv4.address "192.0.2.1/24"
[armadillo ~]# nmcli con up bridge-br0
[armadillo ~]# persist_file /etc/NetworkManager/system-connections/bridge-br0.nmconnection 

また、NetworkManager のデフォルト状態では定期的に wlan0 のスキャンを行っています。スキャン中は AP の性能が低下するため wlan0 を NetworkManager の管理から外します。

[armadillo ~]# vi /etc/NetworkManager/conf.d/90_disable_wlan0.conf
[device_wlan0]
match-device=interface-name:wlan0
managed=0

[armadillo ~]# persist_file /etc/NetworkManager/conf.d/90_disable_wlan0.conf
[armadillo ~]# nmcli d set wlan0 managed no 

hostapd の設定ファイルの雛形として用意してある /etc/hostapd/hostapd.conf.example をコピーして使用します。

[armadillo ~]# cp /etc/hostapd/hostapd.conf.example /etc/hostapd/hostapd.conf
[armadillo ~]# vi /etc/hostapd/hostapd.conf
hw_mode=a 
channel=44 
ssid=myap 
wpa_passphrase=myap_pass 
interface=wlan0 
bridge=br0
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP
rsn_pairwise=CCMP
driver=nl80211
country_code=JP
ctrl_interface=/var/run/hostapd
ctrl_interface_group=0
disassoc_low_ack=1
preamble=1
wmm_enabled=1
macaddr_acl=0
auth_algs=1
ignore_broadcast_ssid=0
wpa=2
ieee80211ac=1
ieee80211ax=1
ieee80211n=1
ieee80211d=1
ieee80211h=1
logger_syslog=-1
logger_syslog_level=2
logger_stdout=-1
logger_stdout_level=2

[armadillo ~]# persist_file /etc/hostapd/hostapd.conf 
[armadillo ~]# rc-service hostapd start 
[armadillo ~]# rc-update add hostapd 
[armadillo ~]# persist_file /etc/runlevels/default/hostapd 

dnsmasq の設定ファイルを以下の内容で作成し /etc/dnsmasq.d/ 下に配置します。ファイル名は任意ですが、拡張子は .conf としてください。ここでは dhcp.conf としています。

[armadillo ~]# vi /etc/dnsmasq.d/dhcp.conf
interface=br0
bind-dynamic
dhcp-range=192.0.2.10, 192.0.1.2, 24h 

[armadillo ~]# persist_file /etc/dnsmasq.d/dhcp.conf 
[armadillo ~]# rc-service dnsmasq restart 

hostapd と dnsmasq の起動完了後、子機から hostapd.conf で設定した SSID とパスフレーズで接続できます。

予め、使用している 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 

atmark-thermal-profiler が出力するログ(thermal_profile.csv)はCSVファイルなので、各種表計算ソフトでインポートしてグラフ化することが可能です。 これにより Armadillo 動作中の温度の変化が可視化され、得られる情報が見やすくなります。

図6.157「Armadillo-IoT ゲートウェイ G4で取得した温度のグラフ」は Armadillo-IoT ゲートウェイ G4上で一定期間 atmark-thermal-profiler を実行して取得した thermal_profile.csv を Google スプレッドシートでグラフ化したものです。 例のために、途中で stress-ng コマンドを実行して CPU に負荷を与えた後、 stress-ng コマンドを停止して CPU と SoC の温度が下がるのを待った際のデータです。

図6.157 Armadillo-IoT ゲートウェイ G4で取得した温度のグラフ

グラフの縦軸は温度(℃)で、横軸は時間です。青い線は CPU の温度、赤い線は SoC の温度を表しています。 このグラフと、「サーマルシャットダウン温度の確認」で得たサーマルシャットダウン温度を見比べると、 CPU に負荷をかけた際であっても SoC の温度は 60℃ 前後ほどまでしか上がらず、 この条件で動く Armadillo が温度的にどれほど余裕を持っているかをひと目で確認できます。

atmark-thermal-profiler は、時間毎の温度だけでなく CPU 使用率と CPU 使用率の高いプロセスについても取得して記録します。 CPU 使用率については thermal_profile.csv の CPU_1〜CPU_5 列と、 USE_1〜USE_5 列を参照してください。 各列について詳しくは表6.26「thermal_profile.csvの各列の説明」にまとまっています。

一般的に CPU 使用率が高くなると、 CPU 周辺の温度も高くなります。 そのため、測定した温度が高い場合は、 CPU 使用率の高いプロセスに注目して、 CPU を無駄に使用している意図しない処理が行なわれていないかなどを確認することをおすすめします。

	CON6(入出力インターフェース)の接点出力ピンは、ゲートウェイコンテナアプリケーションも使用しており、接点出力1を本機能に割り当てると、ゲートウェイコンテナアプリケーションでは、そのピンを使用できなくなります。本機能に接点出力1を割り当てる場合は、ゲートウェイコンテナアプリケーションで接点出力1を使わないように設定してください。 接点出力に対するゲートウェイコンテナアプリケーションの設定は、「ゲートウェイコンテナの設定ファイル」 を参照してください。ゲートウェイコンテナアプリケーションで接点出力1を使用する場合、本機能には CON8(拡張インターフェース)のピンを割り当ててください。

「DTS overlays によるカスタマイズ」 を参考にして /boot/overlays.txt に armadillo-iotg-a6e-stdwn-ind-do1.dtbo を追加してください。

「DTS overlays によるカスタマイズ」 を参考にして /boot/overlays.txt に armadillo-iotg-a6e-stdwn-ind-con8-pin7.dtbo を追加してください。