Armadilloフォーラム

アットマークテクノの古賀です。

ahirataさん：
>ありがとうございます。
>一部不明点がありますので、追加で質問します。

以下に回答します。
なお、「コンテナイメージ」と「コンテナ」の関係については、たとえば次のページが参考になるかと思います：

　Docker のコンテナとイメージの違い
　https://circleci.com/ja/blog/docker-image-vs-container/#docker-%E3%81%A…

ここでは Docker について説明されていますが、podman でも同じです。

>ただ、
>>・コンテナ起動設定ファイルを配置して自動起動されるようにしたコンテナは、自動起動時に podman_start コマンドによってコンテナイメージから作り直される。
>とも記載してあります。
>
>・これは、podman_startコマンドによってコンテナイメージが作り直されると、更新内容が失われるという意味でしょうか？

podman_startによって「更新内容が失われる」というのは、その通りです 。ただし、作り直されるのはコンテナイメージではなく、コンテナです。
上で紹介したページで説明されているように、同じコンテナイメージから複数のコンテナを生成できます。
生成されたコンテナの中で、コンテナイメージに存在していなかったファイルを作ったり、既に存在していたファイルの内容を書き換えることができます。
しかし、そのコンテナを削除して、コンテナイメージから同じ名前でコンテナを作ると、（古い）コンテナで作っていたファイルは存在せず、書き換えたファイルの内容は、元に戻っています。
これが、更新内容が失われる、という意味です。

>・コンテナは、上記(1)～(4)を実行した後は"Exit"の状態になっているので、再び"running"の状態にするためには、
>podman_startを実行する必要があると思っていましたが、podman_startを実行してはいけないということでしょうか？

running の状態でコンテナに加えた変更を無くして構わない場合（つまり、コンテナイメージと同じ内容に戻して構わない場合）は、ABOS の podman_start コマンドを使えばよいです。
ABOS では、この使い方を推奨しています。コンテナを、起動のたびにコンテナイメージから作り直すことにより、「まっさらな」状態に戻せるからです。
これにより、コンテナ動作中に不正なパッケージをコンテナ内にインストールされるなど、悪意のある操作を行われても、再起動で元に戻ります。

このような運用の仕方は、クラウド界隈で「イミュータブル・インフラストラクチャ（Immutable Infrastructure）」と呼ばれるやり方です：
　https://news.mynavi.jp/techplus/article/zerocontena-4/
PC で言えば「揮発性シンクライアント」にも通じる考え方だと思います：
　https://www.yellowhouse.jp/volatile-thinclient/

>>(1) podman（コンテナエンジン）のデータ書き込み記憶域を、tmps からストレージ（eMMC）に切り替える。
>>(2) アプリケーションのインストールなど、コンテナのルートファイルシステムに対する変更操作を行う。（※コンテナ内での操作）
>>(3) podman commit コマンドを使い、更新内容をコンテナイメージに書き込む。
>>(4) podman のデータ書き込み記憶域を、tmpfs に戻す。
…
>・上記(1)～(4)を実行した後、再び"running"の状態にするためには、podman_startではなくて、どのコマンドを実行すれば
>よいのでしょうか？

(1) と (2) を行った後、ABOS のコマンドの podman_start ではなく、podman のコマンドの podman start を実行すれば、Exit の状態になったコマンドを running にでき、(2) で行っていた変更は失われません。（※'_' で繋がった podman_start は、ABOS の独自コマンドです。）
たとえば、python アプリケーションのコンテナを作っていて、コンテナ内の python スクリプトのファイル内容を編集・動作確認、という作業を行っている場合には、そうする方が便利かも知れません。
しかし、アプリケーションの作成が終わった時点で、(3) と (4) を行い、以後は、必要な変更が入ったコンテナイメージから、毎回新たにコンテナを作って動かす運用にする、という運用を推奨しています、ということなのです。

いかがでしょうか？