uesugi
2024年1月15日 12時30分
お世話になっております。
現在コンテナのアップデートするために、SWUファイルによるバージョンアップを試しています。
そこで何点か質問があります。
①初期バージョンのコンテナ(バージョンアップ前)に対してもコンテナswuを作成し、swupdateでインストールする必要がありますでしょうか？
②コンテナと紐づくコンテナ自動起動設定ファイル(/etc/atmark/containers/*.conf)がないとswupdateができない仕様(ロード後に削除される)でしょうか？
③コンテナのswu作成時にコンテナのTagの付け方に関するルールはありますでしょうか？
バージョンアップ時も同じコンテナTag(イメージ名とlatest)を指定しても問題ないでしょうか？
④swupdate後に「前のバージョンのコンテナ」と「アップデートしたコンテナ」はどういうファイル形式で保存されますでしょうか？
確認方法があれば、押してください。(podman iamges等)
※「/etc/sw-version」にバージョンが書かれることは確認しました。
以上、よろしくお願いいたします。
コメント
at_dominique.m…
2024年1月16日 10時59分
マルティネです。
> SWUファイル作成時に指定する「*.desc」の「swdesc_option version」についてですが、
>「swdesc_option version」の作成ルールを教えていただけませんでしょうか？
desc ファイルに記載されているバージョンを管理するツールがあるか、ということですね？
複雑な操作はできませんが、mkswu --update-version で簡単なバージョン更新はできます。
> また、数字を減らした場合(4→3など)は、アップデートは行わない認識で問題ないでしょうか？
バージョンは「semantic versioning」だと考えてください： https://semver.org/lang/ja/
数字の数と関係なく、linux 6.1 が linux 5.10.205 より新しいと同じく、バージョンの数字を削除すると「マイナー」な方が削除されますので、関係ありません。
mkswu にバージョンを比べるデバグツールが便利になりそうなので今後に追加すると思いますが、ひとまず mkswu が受け取ったバージョンであれば以下の簡易関数で比較できます：
atmark@atde9:~$ version_cmp() { ( . /usr/share/mkswu/scripts/versions.sh ; version_higher "$1" "$2" && echo "$2 > $1" || echo "$1 > $2"; ); }
atmark@atde9:~$ version_cmp 2 1
2 > 1
atmark@atde9:~$ version_cmp 1.1 2
2 > 1.1
atmark@atde9:~$ version_cmp 1.1-3 1.2
1.2 > 1.1-3（ちなみに、「x.y.z-t」のフォーマットの場合は t のプレリリース部分にも . を使えて、そちらに数の制限がないので 1.2.3-1.2.3.4.5.6 等のバージョンも認識されていますが、長ければ長いほど間違いやすいのであまりおすすめしません）
> swuファイルを実行した時の戻り値は成功・失敗それぞれどのような値となるのでしょうか？
swupdate でインストールする際の swupdate の exit code の話ですね？
そこも分かりにくくなっていて申し訳ないですが、再起動を実行するために無理やりに swupdate プロセスを kill していますので簡単に確認できません。
内部実装依存に近い判断ですみませんが、現在の仕様では以下の順番で判断できます：
- swupdate コマンドが成功した場合は POST_UPDATE=container で再起動を行わなかった場合の成功です。
- アップデート後に /tmp/.swupdate_waiting ファイルが存在する場合は POST_UPDATE=wait でアップデートが成功したので、再起動待ちです。
- アップデート後に /tmp/.swupdate_rebooting ファイルが存在する場合はアップデートが成功して、再起動中です。この場合は再起動の途中なので、停止されているところで処理はできません（LTE等でネットワークが落ちますし、本プロセスもいつ停止されるかが分からない）ので、ユーザーへのメッセージはここではなく停止シーケンスで行ってください。
また、その段階で書込みが成功しましたが、厳密ではアップデートが再起動するまでのプロセスなので再起動した後に動作テストなどを行ってから成功とみなすべきです。
- それ以外の失敗は失敗で、再起動されません。
よろしくお願いします。
at_dominique.m…
2024年1月15日 13時21分
uesugiさん
お世話になっています、
マルティネです。
> ①初期バージョンのコンテナ(バージョンアップ前)に対してもコンテナswuを作成し、swupdateでインストールする必要がありますでしょうか？
最初の設定は手動（abos-ctrl podman-storage か podman-rw での永続化）でも swupdate でアップデートできます。その armadillo でインストールディスクを生成した場合でも大丈夫です。
（swupdate のコンテナアップデートの仕組みは abos-ctrl podman-storage --disk でも対応してますが、二重化されないためコンテナの停止時間が長くなりますし、運用としては故障の恐れがありますので設定が完了した後に abos-ctrl podman-storage --tmpfs に戻ることを強く推奨しています）
> ②コンテナと紐づくコンテナ自動起動設定ファイル(/etc/atmark/containers/*.conf)がないとswupdateができない仕様(ロード後に削除される)でしょうか？
使ってはいけないことはないですが、アップデートした後の古いイメージの管理としては使った方たいいと考えています。
具体的に：
* コンフィグの有無に関わらず、swupdate をインストールする際にタグのないイメージが削除されます（podman image prune コマンド、podman image list で として表示されているイメージが削除されます）
* /etc/atmark/containers/*.conf ファイルがない場合にコンテナのタグが削除されません。
なので、ずっと同じタグを上書きする場合はコンフィグがなくても、prune のステップで想定どおりに古いイメージだけが削除されます
* /etc/atmark/containers/*.conf がある場合は、podman image list のタグからコンフィグに載ってないタグが削除されます（複数のタグは可能なので、タグがなくなった場合だけイメージが削除されます）
例えば、Armadillo IoT A6E のデフォルトにある a6e-gw-container にコンテナイメージのタグにもバージョンが記載されていますので、a6e-gw-container:v2.4.1 をインストールした際にコンフィグにもそのタグを使うようにして、その前のイメージが削除できるようになりました。
（また、podman-storage --disk の場合は二重化されないためどのイメージを削除していいかの判断はできませんので、そのタグ削除もされません。）
ちなみに、自動起動は無効化できますので、イメージ管理だけが目的でしたら /etc/atmark/containers/*.conf に「set_image myimage:version」と「set_autostart no」の2行のファイルだけが記載されているファイルで管理できます。
> ③コンテナのswu作成時にコンテナのTagの付け方に関するルールはありますでしょうか？
> バージョンアップ時も同じコンテナTag(イメージ名とlatest)を指定しても問題ないでしょうか？
latest で起動させても問題ないと考えています。
ツールについては podman save を行う前に podman tag でタグを設定することになります。
> ④swupdate後に「前のバージョンのコンテナ」と「アップデートしたコンテナ」はどういうファイル形式で保存されますでしょうか？
> 確認方法があれば、押してください。(podman images等)
podman のコンテナイメージは /var/lib/containers/storage_readonly に保存されています（ファイル形式との説明はちょっと難しいですが、「レイヤー」で別けられたディレクトリ構造でデーターが展開されている状態です）
swupdate でアップデートをインストールする際に /var/lib/containers/storage_readonly を btrfs subvolume snapshot で複製してから、一時的に書込み可能にして podman load でイメージを書込みます。
/etc/containers/storage.conf の設定で podman image list 等のコマンドで普通にそのディレクトリのイメージを表示することはできますが、アップデート前のイメージは通常マウントされてませんので、rollback して確認するか abos-ctrl mount-old※ で /target/var/lib/containers/storage_readonly をマウントさせて「podman --storage-opt additionalimagestore=/target/var/lib/containers/storage_readonly image list」でアップデート前のイメージを表示することはできます。
※ 申し訳ございません、最新の ABOS では abos-ctrl mount-old を実行する際に「is_mountpointd: not found」エラーが表示されますが、動作に影響ありませんので無視していただければ幸いです。今月末のアップデートで修正します。
アップデート前のイメージを扱うコマンドは用意してませんので、image list / history / inspect 程度のコマンドで確認する程度のことしかできません。
また、abos-ctrl mount-old の情報は次のアップデートが行えばアップデート開始時点でなくなりますので、解析用のコマンドだけです。
また何か疑問に思える点があれば聞いてください。
よろしくお願いします。