応用編

イメージからコンテナを作成するためには、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.22 Read-Onlyのイメージを削除する実行例

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

実行中のコンテナに接続し、コンテナ内で指定したコマンドを実行するには 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_start をインストールすればそちらも --remote で使えます。

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

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 があります。このオプションを利用すると、コンテナに与えるべき最小の権限を洗い出す必要が無いため、開発時に有用です。

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

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

add_hotplugs [デバイスタイプ]

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

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

例: add_hotplugs input

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

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

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

手動かまたは別の手段で操作するコンテナがある場合、Armadillo の起動時に自動起動しないようにします。

その場合、 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.37 at-debian-image のコンテナイメージをインストールする SWU ファイルを作成する

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

Armadillo-640 コンテナ から 「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-640 コンテナ から 「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>

コンテナ内から、X Window System を起動し画面表示を行う例を示します。 ここではアットマークテクノが提供するイメージからコンテナを作成します。 このイメージに関しては 「アットマークテクノが提供するイメージを使う」 を参照してください。

[armadillo ~]# vi /etc/atmark/containers/x_example.conf
set_image at-debian-image
set_command sleep infinity
add_devices /dev/tty7 
add_devices /dev/fb0 
add_devices /dev/input 
add_volumes /run/udev:/run/udev:ro 
add_args --cap-add=SYS_ADMIN 
[armadillo ~]# podman start x_example
Starting 'x_example'
26847e21bd519f99466af32fdf0d809e2216d3e8ddf05c185e5428fe46e6a09b

次に、以下のように X Window System を起動します。 オプションである vt に設定する値は、コンテナ作成時に渡した tty の数字にします。

[armadillo ~]# podman exec -ti x_example bash
[container ~]# apt install xorg
[container ~]# X vt7 -retro

X.Org X Server 1.20.11
X Protocol Version 11, Revision 0
Build Operating System: linux Debian
Current Operating System: Linux 25297ceb226c 5.10.52-1-at #2-Alpine SMP PREEMPT Thu Nov 18 09:10:13 UTC 2021 aarch64
Kernel command line: console=ttymxc1,115200 root=/dev/mmcblk2p1 rootwait ro
Build Date: 13 April 2021  04:07:31PM
xorg-server 2:1.20.11-1 (https://www.debian.org/support)
Current version of pixman: 0.40.0
        Before reporting problems, check http://wiki.x.org
        to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
        (++) from command line, (!!) notice, (II) informational,
        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Sun Nov 21 23:51:18 2021
(==) Using system config directory "/usr/share/X11/xorg.conf.d"

Armadillo-640 に接続しているディスプレイ上に、デスクトップ画面が表示されます。

コンテナ内で動作するアプリケーションからフレームバッファに直接描画するためには、Podman のイメージからコンテナを作成する際にホスト OS 側の デバイスファイル /dev/fbN を渡す必要があります。以下は、/dev/fb0 を渡して alpine イメージからコンテナを作成する例です。

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

コンテナ内に入って、ランダムデータをフレームバッファに描画する例を以下に示します。 これにより、接続しているディスプレイ上の表示が変化します。

[armadillo ~]# podman exec -it fb_example sh
[container ~]# cat /dev/urandom > /dev/fb0
cat: write error: No space left on device

タッチパネルが組み込まれているディスプレイを接続している環境で、 コンテナ内からタッチイベントを取得するためには、Podman のイメージからコンテナを作成する際に ホスト OS 側の /dev/input を渡す必要があります。

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

X Window System などの GUI 環境と組み合わせて使うことで、タッチパネルを利用した GUI アプリケーションの操作が可能となります。

パワーマネジメント機能を使ってサスペンド状態にするには、Podman のイメージからコンテナを作成する際に ホスト OS 側の /sys ディレクトリを渡す必要があります。 以下は、/sys を渡して alpine イメージからコンテナを作成する例です。ここで渡された /sys ディレクトリは コンテナ内の /sys にマウントされます。

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

コンテナ内から、/sys/power/state に次の文字列を書き込むことにより、サスペンド状態にすることができます。

	サスペンド状態を128秒以上継続する場合は、Suspend-to-RAM か +Power-On Suspend+を利用してください。 +Suspend-to-Idle+を利用している状態で128秒経過すると再起動してしまいます。

[armadillo ~]# podman exec -it pm_example sh
[container ~]# echo mem > /sys/power/state

サスペンド状態から起床要因として、利用可能なデバイスを以下に示します。

Armadillo-640のパワーマネジメント機能は、LinuxのSPM(System Power Management)およびDPM(Device Power Management)を利用しています。パワーマネジメント状態を省電力モードに遷移させることにより、Armadillo-640の消費電力を抑えることができます。

パワーマネジメント状態を省電力モードに遷移させると、アプリケーションの実行は一時停止し、Linuxカーネルはサスペンド状態となります。起床要因が発生すると、Linuxカーネルのリジューム処理が行われた後、アプリケーションの実行を再開します。

コンテナ内で動作するアプリケーションからソフトウェアウォッチドックタイマーを扱うためには、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 に任意の文字を書き込むことで ソフトウェアウォッチドッグタイマーをリセットすることができます。 10 秒間任意の文字の書き込みがない場合は、システムが再起動します。

[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

/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-640 向けのアップデートイメージに 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"

一つのアップデートを登録するには、hawkBit の Web UI で必要な手順が長いので CLI で行うことで 効率よく実行できます。

サーバーの設定の段階では、「mkswu」のユーザーを作成する必要があります。 作成していない場合は setup_container.sh --add-user mkswu で作成してください。

[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

デバイスが多い場合は、SWUを一度作って armadillo を自己登録させることができます。

サーバーの設定の段階では、「device」のユーザーを作成する必要があります。 作成していない場合は setup_container.sh --add-user device で作成してください。

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

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

nmcli [ OPTIONS ] OBJECT { COMMAND | help }

登録されているコネクションの一覧を確認するには、次のようにコマンドを実行します。 ^[10]

[armadillo ~]# nmcli connection
NAME                UUID                                  TYPE      DEVICE
Wired connection 1  a6f99120-b4ed-3823-a6f0-0491d4b6101e  ethernet  eth0

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

コネクションを有効化するには、次のようにコマンドを実行します。

[armadillo ~]# nmcli connection up [ID]

コネクションを無効化するには、次のようにコマンドを実行します。

[armadillo ~]# nmcli connection down [ID]

コネクションを作成するには、次のようにコマンドを実行します。

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

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

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

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

別の Armadillo-640 からコネクションファイルをコピーした場合は、コネクションファイルの パーミッションを 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 イメージに関しては 「アップデート機能について」 を参考にしてください。

コネクションを削除するには、次のようにコマンドを実行します。

[armadillo ~]# nmcli connection delete [ID]

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

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

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

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

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

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

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

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

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

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

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

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

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

デバイスを接続するには、次のようにコマンドを実行します。

[armadillo ~]# nmcli device connect [ifname]

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

デバイスを切断するには、次のようにコマンドを実行します。

[armadillo ~]# nmcli device disconnect [ifname]

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

図6.105 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.5「thermal_profile.csvの各列の説明」にまとまっています。

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

i.MX6ULL にはブートモードを決める BOOT_MODE0 と BOOT_MODE1 というピンがあります。 BOOT_MODE0 は GND になっているので必ず 0 になります。BOOT_MODE1 は JP2 に接続されています。 JP2 がショートされていると BOOT_MODE1 は 1 になり Internal Boot モードになります。開放されていると 0 となり、 Boot From Fuses というモードになります。

Internal Bootモードでは、 on-chip boot ROMに書き込まれているコードが実行し、ブート可能なデバイスを検索します。リファレンスマニュアル「8.5 Boot devices (internal boot)」に、i.MX6ULL がブートできるデバイスの一覧が記載されています。Armadillo-640 では、そのうちオンボードeMMC と microSDカードに対応しています。Internal Bootモードでは、GPIO によって eFuseの設定を上書き (override) できるようになっています。つまり eFuse の設定がどうなっていようと、GPIO のピンでブートデバイスを決めることができます。

Boot From Fusesモードでは、単純に言えば GPIO による override が禁止され eFuse に書き込まれた状態でしかブートしません。この機能を有効にすることで、フィールドに出した製品が悪意ある人によって意図していないブートをし、被害が出ることを防ぐことができます。(もちろん、ブート後に root アカウントを乗っ取られるような作りでは、意味がありませんが…)

Internal Bootモードでは、GPIO によって eFuseの設定を上書き (override) できるようになってると紹介しましたが、JP1 はまさにこの機能を使っています。 JP1 は LCD1_DATA05 と LCD1_DATA11 の制御をしていますが、これらのピンはそれぞれ BOOT_CFG1[5] と BOOT_CFG2[3] を override しています。「8.3.2 GPIO boot overrides」の 表「8-3. GPIO override contact assignments」を確認してください。

ややこしい事に、この BOOT_CFG で始まる eFUSE は、リファレンスマニュアルの中では eFuse のアドレスでも表記されています。 BOOT_CFG1 は eFuse のアドレスで言うと 0x450 の下位 8 bit つまり 0x450[7:0] であり、 BOOT_CFG2 は上位 8 bit つまり 0x450[15:8] にあたります。これは「5.1 Boot Fusemap」の表「5-5. SD/eSD Boot Fusemap」または表「5-6. MMC/eMMC Boot Fusemap」を確認することでわかります。

さらにややこしい事に、eFuse を書き込む場合にはこれら全ての値が使えず、On-Chip OTP Controller の bank と word の値が必要になります。これらの値は リファレンスマニュアルの「On-Chip OTP Controller」を参照してください。後で出てきますが Boot From Fuses で使用する BT_FUSE_SEL という eFuse のように GPIO による override ができないものもあります。

Armadillo-640 ではmicroSDカード または eMMC からのブートになるので、ブートデバイスを選択する eFuse BOOT_CFG1[7:4] は、010x または 011x になります。

リファレンスマニュアル「8.5.3.1 Expansion device eFUSE configuration」には、さらに詳しく SD/MMCデバイスの設定について記載されています。テーブル「8-15. USDHC boot eFUSE descriptions」によれば、eFuse の 0x450[7:6] が 01 の場合に SD/MMC デバイスからブートすることを決めています。さらに 0x450[5] が 0 なら SDが、 0x450[5] が 1 なら MMC が選択されます。つまり、4から 7 bit までの間で 5 bit 目だけが MMC か SD かを決めています。 BOOT_CFG1[5] が 0 の場合はコントローラーは SDデバイスが繋がっている前提で、 BOOT_CFG1[5] が 1 の場合は MMCデバイスが繋っている前提で動作します。

i.MX6ULL には、SD/MMC のコントローラーである uSDHC が 2つ搭載されています。 Armadillo-640では、eMMC が uSDHC1に、 microSDカードが uSDHC2 に接続されています。ブート時にどちらのコントローラーからブートするかを決めている eFuse が 0x450[12:11] です。 0x450[12:11] が 00 であれば uSDHC1 つまりオンボード eMMC から、01 であれば uSDHC2 つまり microSDカードからブートします。言い換えると Armadillo-640 でオンボード eMMC からブートしたい場合は、0x450[5] を 1 に、 0x450[12:11] を 00 にします。逆に microSDカードから起動したい場合は 0x450[5] を 0 に、0x450[12:11] を 01 にします。

Boot From Fuses を有効にするには、 eFuse に書き込んだ値が正しいことを i.MX6ULL に教える必要があります。そのための eFuse が BT_FUSE_SEL (0x460[4]) です。BOOT_MODE が 00 、つまり JP2 がオープンで、且つこのビットが 1 であれば Boot From Fuses モードになります。 BOOT_MODE が 00 でも このビットが 0 であれば Boot From Fusesモードにはならず、 SD/MMC マニュファクチャリングモードやシリアルダウンロードモードになってしまいます。SD/MMCマニュファクチャリングモードについては 「8.12 SD/MMC manufacture mode」に、シリアルダウンロードモードについては「8.9 Serial Downloader」に記載されています。

	Armadillo-640 では BOOT_MODE が 00 で、且つ BT_FUSE_SEL が 0 の場合は SD/MMC マニュファクチャリングモードで eMMC から起動します。Internal Boot モードで起動する場合は、JP2 をショートしてください。

オンボード eMMC からだけブートさせたい場合は、ブートデバイスの種類で MMC と、コントローラーで uSDHC1 を選択することで可能です。忘れずに BT_FUSE_SEL を 1 にします。

オンボード eMMC のスペックは、以下の通りです。リファレンスマニュアル 8.5.3 Expansion device および 表「5-6. MMC/eMMC Boot Fusemap」を確認してください。「可変」列が「不」となっている値は、変更しないでください。例えば、オンボード eMMC は 1.8 V に対応していません。 bit 9 の SD Voltage Selection で 1 の 1.8 V では動作しません。

値を見易いように、 BOOT_CFG2 を上にしています。 BOOT_CFG1 と BOOT_CFG2 は、OCOTP_CFG4 にマップされており Bank 0 Word 5 です。つまり 010000000 01100010 の 16 bit (0x4062) を Bank 0 Word 5 に書き込めば良いことが分ります。 BOOT_CFG3 と BOOT_CFG4 はここでは無視します。

BT_FUSE_SEL は Bank 0 Word 6 の 4 bit 目になるので 0x10 を書き込みます。

=> fuse read 0 5
Reading bank 0:

Word 0x00000005: 00000000
=> fuse prog 0 5 0x4060
Programming bank 0 word 0x00000005 to 0x00004060...
Warning: Programming fuses is an irreversible operation!
         This may brick your system.
         Use this command only if you are sure of what you are doing!

Really perform this fuse programming? <y/N>
y
=> fuse read 0 6
Reading bank 0:

Word 0x00000006: 00000000
=> fuse prog -y 0 6 0x10
Programming bank 0 word 0x00000006 to 0x00000010...
=> fuse read 0 6
Reading bank 0:

Word 0x00000006: 00000010

(電源入れなおしても、SDからブートしない)

	fuse prog にオプション -y を付けると 「 Really perform this fuse programming? <y/N> 」と聞かれません。

これで eMMC からしか起動しない Armadillo-640 ができあがりました。

	eMMC からしか起動しないので、あやまって eMMCに書き込まれている U-Boot を消してしまうと、二度と起動しないようになります。注意してください。

	eMMC Fast Boot機能を使う場合や Power Cycle を Enable にする場合は、当該ビットを 1 に変更してください。

同じ要領で、SDからだけしかブートしないようにすることも可能です。しかし eFuse によるブートデバイスの固定は、意図しないブートを防ぐことが目的です。 Armadillo-640 で microSDからのブートに固定することは可能ですが、別の microSDカードを挿入されてしまうと、その別の microSDカードからブートしてしまうので目的を達成できません。理解してお使いください。

書き込んだ eFuse の値を変更されてしまっては、Boot From Fuseモードにしている意味がありません。i.MX6ULLでは eFuse を変更できなくするビットも用意されています。

リファレンスマニュアル「5.3 Fusemap Descriptions Table」を確認してください。

ONOFFピンは、一定時間以上GNDとショートすることで、Armadillo-640の電源をオフまたはオンすることができます。 外部からONOFFピンを制御する場合、電圧の印加はできませんのでオープンドレインなどの出力を接続しGNDとショートする回路を接続してください。

	連続して電源を切り替える場合、確実に動作させるため5秒以上空けてからONOFFピンをGNDとショートしてください。

	電源のオンまたはオフの状況はi.MX6ULLの低消費電力ドメイン(SNVS_LP)で保持されているため、 電源オフの状態で5V電源入力を切ってもしばらくは電源オフであることを保持しています。 そのため、すぐに電源を再入力した場合電源が入らない状態になる可能性があります。 電源オフの状態で5V電源を再入力する場合は、確実に電源を入れるため、5秒以上間隔を空けてから5V電源を入れてください。

	電源のオンまたはオフの状況はRTC_BATピンからのバックアップ電源により保持されるため、 RTC_BATピンにバックアップ電源を入力した状態で5V電源を切ったのち5V電源を再入力しても、 5V電源切断前の電源のオンまたはオフの状況が継続されます。

PWRONピンは、GNDとショートすることで、Armadillo-640の電源を即座にオフすることができます。 外部からPWRONピンを制御する場合、電圧の印加はできませんのでオープンドレインなどの出力を接続しGNDとショートする回路を接続してください。

RTC_BATピンは、i.MX6ULLの低消費電力ドメインにあるSRTC(Secure Real Time Clock)の外部バックアップインターフェースです。 長時間電源が切断されても時刻データを保持させたい場合にご使用ください。

FT232RLを搭載したUSB-シリアル変換アダプタです。シリアルの信号レベルは3.3V CMOSです。

図6.126 USBシリアル変換アダプタの配線

Armadillo-640のCON9の「1、3、5、7、9」または「2、4、6、8、10」ピンに接続して使用することが可能です。

各ピンに対応するUARTコントローラは以下のとおりです。

図6.127 Armadillo-640のシリアル信号線

ご使用の際は、USBシリアル変換アダプタの5ピンコネクタ(青いケーブル側)をArmadillo-640 CON9の1ピンもしくは2ピンに合わせて接続してください。 UART1側で使用した場合、USBシリアル変換アダプタのスイッチで、電源投入時の起動モードを設定することが可能です。 スライドスイッチの状態に対応した起動モードは以下のとおりです。

	USBシリアル変換アダプタは、Armadillo-640の電源を切断した状態で接続してください。 故障の原因となる可能性があります。

	USBシリアル変換アダプタは、試作・開発用の製品です。外観や仕様を予告なく変更する場合がありますので、ご了承ください。

Armadillo-640用のプラスチック製小型ケースです。 Armadillo-640の基板を収めた状態で、DCジャック、シリアルインターフェース(D-Sub9ピン)、 USBインターフェース、LANインターフェースにアクセス可能となっています。

取り外しが可能なパーツにより、CON9(拡張インターフェース)等の機能を外部に取り出すための開口部も用意しています。

	Armadillo-600シリーズ オプションケース(樹脂製)はArmadillo-640ベーシックモデル開発セットに付属しています。 樹脂ケースのみ必要なお客様のためにオプション品として別売りもしています。

	最高使用温度よりも高い温度で保管または使用した場合、樹脂ケースが変形する可能性があります。

Armadillo-640用のアルミ製小型ケースです。 Armadillo-640の基板を収めた状態で、DCジャック、シリアルインターフェース(D-Sub9ピン)、 USBインターフェース、LANインターフェースにアクセス可能となっています。 ケース固定ネジを利用して、ACアダプタ固定用パーツおよびアース線を接続することが可能です。

	金属ケースはオプション品として別売りしています。

ノリタケ伊勢電子製のタッチパネルLCDとフレキシブルフラットケーブル(FFC)のセットです。 Armadillo-640のCON11(LCD拡張インターフェース)に接続して使用することが可能です。

ソフトウェアからの利用方法については、「LCD を使用する」を参照してください。