4.4.1. Podman - コンテナ仮想化ソフトウェアとは
コンテナとはホスト OS 上に展開される仮想的なユーザ空間や、その仮想化技術のことです。
一般的な仮想化では仮想環境内に OS （ゲストOS）が搭載されていますが、
コンテナによる仮想化では、OS をコンテナ内に搭載しない（ゲストOSが無い）という特徴があります。
これにより、一般的な仮想化のように、
-
異なる個体のハードウェアでも同一の環境を簡単に再現できる（再現性と移植性）
-
セキュリティリスクを低減できる
といった恩恵がありながら、これに加えて、
-
軽量である
-
アプリケーションの起動が素早い
-
環境を手軽に構築・削除できる
といったメリットもあります。
Podman はこのようなコンテナを管理するためのソフトウェアです。
Podman は同じコンテナ管理ソフトウェアとしてよく知られている Docker とコマンドインターフェースの互換性がある一方で、
Dockerよりもコンテナ間の独立性が高いなどのセキュリティ的な長所があります。
ABOS では Podman を採用しており、ユーザーアプリケーションはコンテナ内で実行されることを想定しています。
そのため、Podman は ABOS を搭載した Armadillo における根幹の機能であり、
Armadillo を使って機器を開発したり、アプリケーションを開発・運用したりする上で、
Podman やコンテナに関する理解が非常に重要となります。
ここでは、Podman やコンテナに慣れる・上手に活用できるようになる目的で、Podman の使用方法や動作について説明します。
![[ティップ]](images/tip.png) | |
|---|
以下で紹介する Podman のコマンドの多くは、 --help オプションを付けることでより詳細な情報を確認することができます。
|
4.4.2.1. コンテナイメージをダウンロードする
コンテナを作成するためには、その元となるイメージ（コンテナイメージ）が必要です。
まずは、例として、Alpine Linux のコンテナイメージを Docker Hub からダウンロードしてきます。
コンテナイメージのダウンロードは podman pull [source] コマンドでできます。
これはインターネット上のレジストリ（Docker Hubなど）にある指定したイメージ（ source ）をローカルにダウンロードするコマンドです。
先ほどダウンロードしたイメージが本当にダウンロードできたかどうかを podman images コマンドで確認します。
これは、ローカルにあるイメージ一覧を表示するコマンドです。
先ほどダウンロードしたイメージがあることを確認できます。
4.4.2.3. イメージからコンテナを作成して起動する
Podman や Docker に詳しい方は podman run コマンドでコンテナの作成＆起動ができることをご存知かもしれませんが、
ABOS では podman_start コマンドを積極的に使用してください。
このコマンドはアットマークテクノが用意したコマンドで、
「コンテナ起動設定ファイルを作成する」 で紹介するコンテナの自動起動などでも使用します。
ここでは、簡単な例として "ls /" コマンドを実行するコンテナを podman_start コマンドで作成します。
まず、podman_start コマンドを使用するためには、
コンテナについての設定（コンテナイメージの指定・実行するコマンド・デバイスへのアクセス権限など）を記述したコンフィグファイルを指定の場所に指定のファイル名であらかじめ用意しておきます。
デフォルトでは指定の場所は /etc/atmark/containers/ ディレクトリになります。
ファイル名は"コンテナの名前としたい文字列"に .conf を末尾に付加した文字列になります。
ここでは、my_container というコンテナの名前でコンフィグファイルを作成します。
|
set_image に元となるコンテナイメージを指定します。ここでは、先ほどダウンロードしたばかりの docker.io/alpine イメージを指定しています。
|
|
set_command に、実行するコマンドを指定します。ここでは、簡単な例として "ls /" コマンドを指定しています。
|
コンフィグファイルに記述できる設定内容や、より詳細な説明については 「コンテナ起動設定ファイルを作成する」 を参照してください。
コンフィグファイルを作成したら、いよいよ podman_start コマンドでコンテナの作成＆起動を行います。
後ろの引数にコンテナの名前（コンフィグファイル名の .conf を除いた部分）を指定してください。
"ls /" を実行するだけの "my_container" という名前のコンテナが作成＆起動しました。
コンテナが作成されると同時に "ls /" が実行され、その結果がログに残ります。（後述のコマンドで確認できます）
ここでは簡単な例のために podman_start コマンドを手動で呼び出しましたが、
コンフィグファイルが /etc/atmark/containers/ に置かれていると、Armadillo 起動時に podman_start コマンドでそのコンフィグファイルからコンテナが自動的に作成＆起動します。
自動起動が不要な場合にはコンフィグファイルに set_autostart no を記述してください。
コンテナ内のログは podman logs コマンドで確認できます。
ここでは、簡単な例として "ls /" コマンドを実行するコンテナを起動したため、
そのコマンド結果が表示されることを確認できるはずです。
ここで表示されているのは、コンテナ内部の "/" ディレクトリ内のディレクトリ・ファイル一覧です。
| |
|---|
podman_start でコンテナが正しく起動できない場合は podman_start -v my_container で podman run のコマンドを確認し、 podman logs my_container で出力を確認してください。
|
作成したコンテナの一覧は podman ps -a コマンドで確認できます。
"ls /"が正常終了したため、STATUSが「Exited (0)」になっていることが確認できます。
また、コンテナ名やコンテナ ID を確認することもできます。-a オプションを付けない場合は、動作中のコンテナのみ表示されます。
実行中のコンテナに入り、コンテナ内で CLI 操作するには podman exec コマンドを実行します。
podman exec コマンドでコンテナ内部のシェルを起動すると、コンテナ内部で CLI 操作できるようになります。
ここでは、sleep infinity コマンドを実行して待ち続けるだけのコンテナを作成し、そのコンテナに対して podman exec コマンドでシェルを起動する例を示します。
まずは、先ほどまで使用していた /etc/atmark/containers/my_container.conf を書き換えます。
podman_start コマンドでコンテナを作成＆起動し、その後コンテナ内で sh を実行しています。
sh を実行すると、コンテナ内のプロンプトが表示されコンテナ内部で CLI 操作できるようになります。
上記ではコンテナ内で、 ps コマンドを実行しています。コンテナ作成時に実行した sleep infinity と podman exec で実行した
sh がプロセスとして存在していることが確認できます。
コンテナ内のシェルから抜ける時は exit コマンドを実行します。
exit コマンドで抜けても sleep infinity は終了していないため、コンテナはまだ実行中です。
podman stop コマンドで動作中のコンテナを停止します。
作成済みのコンテナを再度起動するためには podman start コマンドを実行します。
podman_start コマンドとは違い、podman と start の間はスペースであることに注意してください。
作成済みコンテナの削除は podman rm コマンドで行います。
--force オプション無しの場合はあらかじめコンテナを停止しておく必要があります。
最後の podman ps -a コマンドの出力結果から、コンテナが削除されていることが確認できます。
コンテナイメージの削除には podman rmi コマンドを実行します。
イメージを削除するためには、そのイメージから作成したコンテナをあらかじめ削除しておく必要があります。
podman rmi コマンドではイメージの名前か ID を指定する必要があるため、podman images コマンドで確認します。
最後の podman images コマンドの出力結果から、コンテナが削除されていることが確認できます。
| |
|---|
podman images で R/O が true として表示される（Read-Only）コンテナイメージについては、 podman rmi を実行するとエラーとなります。
Read-Only のコンテナイメージについては abos-ctrl podman-rw rmi をご使用ください。 abos-ctrl podman-rw については 「コンテナイメージを eMMC に保存する」 を参照してください。
|
ここまでは、 podman pull でダウンロードしてきたコンテナイメージを元にコンテナを作成してきましたが、
コンテナイメージを元にして新たにカスタマイズしたコンテナイメージを作成することもできます。
これには、どのようにカスタマイズするかを記述した Dockerfile と podman build コマンドを使います。
まずは Dockerfile を用意します
|
FROM に元となるコンテナイメージを指定します。指定したコンテナイメージは自動的にダウンロードされるため、あらかじめダウンロードしておく必要はありません。
|
|
RUN に、コンテナイメージ作成時に実行するコマンドを指定します。ここでは、簡単な例として Python3 をインストールしています。
|
Dockerfile からコンテナイメージを作成します
|
カレントディレクトリにある Dockerfile から my_image という名前でコンテナイメージを作成します。
|
podman images で、たった今作成したコンテナイメージと、 FROM で指定したことで自動的にダウンロードされたコンテナイメージがあることを確認できます。
4.4.2.12. コンテナをコンテナイメージとして保存する
ここまでは、コンテナイメージからコンテナを作成してきました。
一方で、コンテナからコンテナイメージを作成することもできます。
コンテナはコンテナイメージから一方向的に作成されるため、コンテナに対する変更内容はコンテナが停止してしまうと失なわれてしまいます。
ですが、コンテナからコンテナイメージを作成することで、コンテナが停止してもコンテナに対する変更内容を残しておくことができます。
言い換えれば、コンテナをコンテナイメージとして保存できます。
これには、 podman commit コマンドを使用します。
|
コンテナ my_container を hoge_image という名前のコンテナイメージとして保存します。
|
podman commitで保存する度に、変更が行なわれた差分が保存されます。
繰り返し差分を保存すると、イメージサイズが大きくなってしまいます。
ストレージ容量が不足する場合は、元となるコンテナイメージから作り直してください。
4.4.2.13. コンフィグファイルとコンテナイメージを永続化する
ここまでで、コンテナイメージのダウンロード・作成（ podman pull, podman build ）とコンフィグファイルの作成を行いました。
ですが、 podman pull や podman build で用意したコンテナイメージや、作成・変更したコンフィグファイルはデフォルト状態ではメモリ上にしか保存されません。これは、Armadillo Base OS の意図した仕様です。
そのため、このまま Armadillo を終了すると、これらのデータは消えてしまいます。
Armadillo を終了してもデータが消えないようにするためには、
コンフィグファイルは persist_file コマンドで保存し、
コンテナイメージは abos-ctrl podman-storage コマンドで保存します。
（ここではチュートリアルのために簡単な内容のみ記載しています。コンテナイメージを eMMC に保存するためのより本格的な内容については 「コンテナイメージを eMMC に保存する」 を参照してください。）
まず、コンフィグファイルは次の persist_file コマンドで保存します。
次に、コンテナイメージは次の abos-ctrl podman-storage コマンドで保存します。
|
abos-ctrl podman-storage をオプション無しで実行します。
|
|
書き込み可能ストレージにイメージがある場合に対応を聞かれます。今回はコピー（C）します。
|
|
コピーされたイメージを確認します。イメージが読み取り専用（R/O, Read only）になっていることが確認できます。
|
4.4.2.14. 開発時に有用な—privilegedオプション
コンテナに、全権限と全てのデバイスへのアクセスを許可するオプション --privileged があります。このオプションを利用すると、コンテナに与えるべき最小の権限を洗い出す必要が無いため、開発時に有用です。
コンフィグファイルに以下の行を追加してください。
add_args --privileged
実運用の際、このオプションを利用することはセキュリティー上問題がある為、開発時にのみご利用ください。コンテナに必要な最低限の権限を与えることをおすすめします。
Podman やコンテナについてのより詳細な使用方法については 「コンテナについて」 を参照してください。
Partition number (1-4): 1 
First sector (16-806911, default 16): 
Using default value 16
Last sector or +size{,K,M,G,T} (16-806911, default 806911): +100M 
Command (m for help): n
Partition type
p primary partition (1-4)
e extended
p
Partition number (1-4): 2 
First sector (204816-806911, default 204816):
Using default value 204816
Last sector or +size{,K,M,G,T} (204816-806911, default 806911):
Using default value 806911
Command (m for help): w 
The partition table has been altered.
Calling ioctl() to re-read partition table
fdisk: WARNING: rereading partition table failed, kernel still uses old table: Invalid argument
[armadillo ~]# fdisk /dev/{sd-dev}p1
The number of cylinders for this disk is set to 12608.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
(e.g., DOS FDISK, OS/2 FDISK)
Command (m for help): p 
Disk /dev/mmcblk2p1: 394 MB, 413138944 bytes, 806912 sectors
12608 cylinders, 4 heads, 16 sectors/track
Units: sectors of 1 * 512 = 512 bytes
Device Boot StartCHS EndCHS StartLBA EndLBA Sectors Size Id Type
/dev/mmcblk2p1p1 0,1,1 1023,3,16 16 204815 204800 100M 83 Linux
/dev/mmcblk2p1p2 1023,3,16 1023,3,16 204816 806911 602096 293M 83 Linux