Armadilloフォーラム

ファイルの保存先について

takamura.eiji

2025年9月9日 15時29分

==========
製品型番:AG9130-C03D0
Debian/ABOSバージョン:v3.22.1-at.2
=========

ファイルの保存先について質問させてください。

コンテナアプリで使用するファイルになりますが、
以下の条件でも問題なくファイルが保存され続ける適切なディレクトリはどこになりますでしょうか?

・コンテナ自体のソフトウェアアップデート
・Armadillo Base OS のソフトウェアアップデート
・ユーザーデータ一括削除

また、そのディレクトリにファイルを配置する際の
persist_file -p/-P オプション付与等についてもご教示頂けると助かります。

コメント

at_satoshi.ohta

2025年9月9日 16時04分

太田です。

コンテナで使用するソースコードは /var/app/rollback/volumes に配置してください。
取得したデータは /var/app/volumes に配置してください。
これらのディレクトリであれば、persist_file は行わなくても永続的に保存されます。

> ・コンテナ自体のソフトウェアアップデート
こちらは基本的にはユーザーご自身がコンテナアプリケーションを作成してメンテナンスする形になるかと思います。
コンテナイメージ自体はアットマークテクノが提供するアップデートによる影響はありません。
アップデートのために SWU イメージを作成すると思いますが、desc ファイルの書き方は例えば、ABOSDE のサンプルプロジェクト内の desc ファイルが参考になるかと思います。

> ・Armadillo Base OS のソフトウェアアップデート
ABOS のソフトウェアアップデートは rootfs をアップデートします。
/var/app/rollback/volumes や /var/app/volumes はアップデートされません。

> ・ユーザーデータ一括削除
こちらは abos-web の「設定管理」>「ユーザー設定とユーザーデータの削除」による削除、または abos-ctrl reset-default コマンドによる削除のことでしょうか?
そうであれば、デフォルトでは、/var/log と /var/app/volumes/* やネットワーク関連のファイルなどが削除されます。
/var/app/rollback/volumes 内のファイルは削除されることはありません。

どうぞよろしくお願いいたします。

太田さん
回答ありがとうございます。
> > ・ユーザーデータ一括削除
> こちらは abos-web の「設定管理」>「ユーザー設定とユーザーデータの削除」による削除、または abos-ctrl reset-default コマンドによる削除のことでしょうか?

ユーザーデータ一括削除は REST API の「ユーザー設定とユーザーデータの削除」となります(JC-STAR対応のため)。
https://manual.atmark-techno.com/armadillo-iot-a9e/armadillo-iotg-a9e_p…

それと質問が説明不足で失礼しました。改めて質問させて頂きます。

再度の確認で恐縮ですが、各操作時の認識は以下の通りです。
※ファイルがどうなるかという観点です。

・コンテナアプリ(SWU)のアップデート
 /var/app/rollback/volumes/<アプリ名>/ 以下が新しいコンテナアプリにより上書きされる

・Armadillo Base OS のアップデート
 ホスト OS 側の必要なファイルが更新される

・ユーザーデータ一括削除
 /var/log や /var/app/volumes/* が削除される(ネットワーク設定なども削除されるのも認識しています)

あるコンテナアプリで扱う「ファイル」ですが、上記のいずれの処理を実施しても残したいです。
/var/app/rollback/volumes/<アプリ名>/, /var/app/volumes 配下は削除される認識です。

そのため該当ファイルを以下のいずれかの場所に保存する必要があると考えておりました。
・/var/app/rollback/volumes 直下
・ホスト OS 側のどこか(persist_file で保存)

上記の条件を満たす適切なディレクトリは /var/app/rollback/volumes 直下という認識でよろしかったでしょうか?

at_satoshi.ohta

2025年9月9日 18時54分

太田です。

アップデート中においても取得したデータを書き込こむことができて、ユーザーデータ一括削除の対象外のディレクトリはあるかというご質問と理解しました。

そういう意味では、結論としては申し訳ありませんが、その両方を満たすディレクトリは用意できていないと考えています。

/var/app/rollback/volumes は起動中の面(A面)と起動していないアップデート先の面(B面)がありますが、SWUpdate を実行するとアップデート開始から再起動するまでにA面に書き込まれたファイルはB面に反映されないはずですので、そういう意味では /var/app/rollback/volumes 直下は適切ではありません。
アップデート時にも書き込みを行うのであれば、/var/app/volumes に書き込みを行う必要があります。
ユーザーによる取得データは /var/app/volumes に格納することを推奨しています。

JC-STAR ★1では、ユーザーデータの削除は 【★1 適合基準 S1.1-15】に対応するかと思います。
S1.1-15 では「IoT 製品利用中に取得した情報資産(個人情報含む)」や「ユーザ設定値、認証値」も削除する必要があります。
したがって、JC-STAR ★1対応ということであれば、 /var/app/volumes に取得したユーザーデータを配置して、ユーザーデータ一括削除機能で削除される挙動は適切かと思いますが、どうでしょうか?

どうしても両方を満たす必要があるのであれば、普段は /var/app/volumes をしておいて REST API の「ユーザー設定とユーザーデータの削除」をする前に、/var/app/rollback/volumes にユーザーデータをコピーする処理を入れるなどの簡単な対応しか現状思いつきませんでした。

お力になれず申し訳ありません。

どうぞよろしくお願いいたします。

実現したいのは、以下の3つどれを実行しても削除されずに内容を維持でき、
かつ、コンテナからアクセス可能なファイルを用意したいことです。

・コンテナ自体のソフトウェアアップデート
・Armadillo Base OS のソフトウェアアップデート
・ユーザーデータ一括削除

例えば、こんな対処だと如何でしょうか?

・維持・保持され続けて欲しいファイルとして
 「/home/atmark/test」を用意(ディレクトリなどは仮です)

  ★→ コンテナ自体のソフトウェアアップデートで削除されないディレクトリ
  ★→ ユーザーデータ一括削除の対象外のディレクトリ

・「persist_file -P /home/atmark/test」とすることで、/etc/swupdate_preserve_filesに
 このパスが追記される

  ★→ 以降、何度ABOSアップデートをしても、このファイルは維持される

・app.confで「/home/atmark」をadd_volumesする

  ★→ コンテナから「test」ファイルが参照可能になる

お忙しいところ恐縮ですが、何卒よろしくお願い致します。

at_satoshi.ohta

2025年9月10日 10時38分

太田です。

/home/atmark ディレクトリも rootfs の一部なので /var/app/rollback/volumes と同様にアップデート中にファイルに書き込まれた内容は B 面に反映されないはずです。
そのことを考慮する必要がないのであれば、/home/atmark ではなく、persist_file コマンドを使用せずにファイルを永続的に保存できる /var/app/rollback/volumes に、ソースコードとは別にデータ用のディレクトリを用意するなどの対処で問題ないかと思います。
例えば、
/var/app/rollback/volumes/my_project <- ソースコードを含むアップデート用のディレクトリ
/var/app/rollback/volumes/my_project_data <- データ用のディレクトリ

app.conf で両方を add_volumes するといった具合です。
/var/app/rollback/volumes であれば 、Armadillo Base OS のソフトウェアアップデートの対象でもユーザーデータ一括削除の対象でもありません。

/var/app/rollback/volumes はコンテナ自体のソフトウェアアップデートで削除されないディレクトリであるかどうかということですが、
コンテナ自体のソフトウェアアップデート用のdesc ファイルはそのコンテナアプリーケーションの開発者が作成するため、/var/app/rollback/volumes に配置したユーザーデータをアップデートの対象外にするように開発者が desc ファイルを記述すればよいです。
上記の例でいえば、/var/app/rollback/volumes/my_project_data をアップデート対象外とするように desc ファイルを記述するということです。

ご回答になっていますでしょうか?

どうぞよろしくお願いいたします。

太田さん
回答ありがとうございます。

ご提案ありがとうございます。幾つか質問がございます。
my_project というプロジェクトを作成したとします。

/var/app/rollback/volumes/my_project

相談しているファイルの保存先ディレクトリを以下としたとします。

/var/app/rollback/volumes/my_project_data

具体的にどのように my_project の desc ファイルを作成すればよいのでしょうか?

また
/var/app/rollback/volumes/my_project_data は事前に作成しておけばよろしいでしょうか?

# mkdir -p /var/app/rollback/volumes/my_project_data
# chmod 777 /var/app/rollback/volumes/my_project_data

at_satoshi.ohta

2025年9月11日 11時49分

太田です。

SWU イメージはアップデートのために使用するものなので、
/var/app/rollback/volumes/my_project_data
をコンテナのアップデートで更新しないのであれば、desc ファイルで書かずに、コンテナ起動設定ファイルである conf ファイルに書くのはどうでしょうか?
例えば、/etc/atmark/containers/my_project.conf に

mkdir -p /var/app/rollback/volumes/my_project_data                       
chmod 777 /var/app/rollback/volumes/my_project_data                      
add_volumes /var/app/rollback/volumes/my_project_data:/my_project_data   

と書けば、コンテナ起動時に /var/app/rollback/volumes/my_project_data がなければ生成されます。

どうぞよろしくお願いいたします。

at_dominique.m…

2025年9月11日 11時55分

よこからすみません、
マルティネです。

mkdir を実行しても問題はありませんが、
ボリュームディレクトリまたは /tmp, /run, /dev/shm での add_volumes でディレクトリが存在しない場合に自動的に生成されますので、
mkdir は不要です。
(root:root / 0755 になりますので、違うアクセス権限が必要でしたら add_volumes 後に chownまたはchmod できます)