第6章 Image Mode for RHEL でのファイルシステムの管理
現在、Image Mode for RHEL では、バックエンドとして OSTree が使用され、ストレージ用に composefs がデフォルトで有効になっています。/opt および /usr/local パスはプレーンディレクトリーであり、/var へのシンボリックリンクではありません。これにより、たとえば /opt に書き込む派生コンテナーイメージにサードパーティーのコンテンツを簡単にインストールできるようになります。
6.1. /sysroot による物理ルートと論理ルート
システムが完全に起動すると、chroot に似た状態になり、オペレーティングシステムは現在実行中のプロセスとその子プロセスの見かけ上のルートディレクトリーを変更します。物理ホストのルートファイルシステムは /sysroot にマウントされます。chroot ファイルシステムはデプロイメントルートと呼ばれます。
残りのファイルシステムパスは、システムブートの最終ターゲットとして使用されるデプロイメントルートの一部です。システムは、ostree=kernel 引数を使用してデプロイメントルートを検索します。
/usr-
このファイルシステムは、すべてのオペレーティングシステムのコンテンツを
/usrに保存し、/binなどのディレクトリーは/usr/binへのシンボリックリンクとして機能します。
composefs が有効になっている /usr は / と変わりません。両方のディレクトリーは同じ不変イメージの一部であるため、bootc システムで完全な UsrMove を実行する必要はありません。
/usr/local-
ベースイメージは、デフォルトのディレクトリーとして
/usr/localに設定されています。 /etc/etcディレクトリーにはデフォルトで変更可能な永続状態が含まれますが、etc.transient configオプションを有効にすることがサポートされています。ディレクトリーが変更可能な永続状態にある場合は、アップグレード全体で 3 方向のマージが実行します。-
新しいデフォルトの
/etcをベースとして使用します -
現在の
/etcと以前の/etcの差分を新しい/etcディレクトリーに適用します。 -
同じデプロイメントのデフォルトの
/usr/etcとは異なる、ローカルで変更されたファイルを/etcに保持します。
-
新しいデフォルトの
ostree-finalize-staged.service は、新しいブートローダーエントリーを作成する前に、シャットダウン時にこれらのタスクを実行します。
これは、Linux システムの多くのコンポーネントが /etc ディレクトリーにデフォルトの設定ファイルを置いて出荷されるために発生します。デフォルトパッケージに含まれていない場合でも、デフォルトではソフトウェアは /etc 内の設定ファイルのみをチェックします。/etc の明確なバージョンを持たない、bootc イメージベースではない更新システムは、インストール時にのみ設定され、インストール後は変更されません。これにより、/etc システムの状態が初期イメージバージョンの影響を受けるようになり、たとえば /etc/sudoers.conf に変更を適用する際に問題が発生し、外部からの介入が必要になる可能性があります。ファイル設定の詳細は、RHEL のブート可能なコンテナーイメージのビルドおよびテスト を参照してください。
/var-
/varディレクトリーの内容はデフォルトで永続的です。ネットワークでもtmpfsでも、/varまたはサブディレクトリーのマウントポイントを永続的にすることもできます。
/var ディレクトリーは 1 つだけです。別個のパーティションでない場合、物理的には /var ディレクトリーは /ostree/deploy/$stateroot/var へのバインドマウントとなり、利用可能なブートローダーエントリーのデプロイメント間で共有されます。
デフォルトでは、/var 内のコンテンツはボリュームとして機能します。つまり、コンテナーイメージのコンテンツは最初のインストール時にコピーされ、その後は更新されません。
/var ディレクトリーと /etc ディレクトリーは異なります。比較的小さな設定ファイルには /etc を使用でき、必要な設定ファイルは、多くの場合 /usr 内のオペレーティングシステムバイナリーにバインドされます。/var ディレクトリーには、システムログ、データベースなどの任意の大きさのデータが含まれており、デフォルトでは、オペレーティングシステムの状態がロールバックされてもロールバックされません。
たとえば、dnf downgrade postgresql などの更新を実行しても、/var/lib/postgres 内の物理データベースには影響しません。同様に、bootc update または bootc rollback を実行しても、このアプリケーションデータには影響しません。
/var を別々にしておくと、新しいオペレーティングシステムの更新を適用する前にステージングをスムーズに実行できるようになります。つまり、更新はダウンロードされて準備完了ですが、再起動時にのみ有効になります。同じことが Docker ボリュームにも当てはまり、アプリケーションコードとそのデータが切り離されます。
アプリケーションに /var/lib/postgresql などの事前に作成されたディレクトリー構造を持たせたい場合に、このケースを使用できます。これには systemd tmpfiles.d を使用します。ユニットで StateDirectory=<directory> を使用することもできます。
- その他のディレクトリー
-
コンテナーイメージ内の
/run、/proc、またはその他の API ファイルシステム内のコンテンツを出荷することはサポートされていません。それ以外にも、/usrや/optなどの他のトップレベルディレクトリーは、コンテナーイメージとともにライフサイクル化されます。 /opt-
composefsを使用するbootcでは、/optディレクトリーは、/usrなどの他の最上位ディレクトリーと同様に読み取り専用になります。
ソフトウェアが /opt/exampleapp 内の独自のディレクトリーに書き込む必要がある場合は、ログファイルなどの操作のために、たとえば /var にリダイレクトするシンボリックリンクを使用するのが一般的なパターンです。
RUN rmdir /opt/exampleapp/logs && ln -sr /var/log/exampleapp /opt/exampleapp/logs
オプションで、これらのマウントを動的に実行するサービスを起動するように systemd ユニットを設定することもできます。以下に例を示します。
BindPaths=/var/log/exampleapp:/opt/exampleapp/logs
- 一時ルートを有効にする
-
デフォルトで完全に一時的な書き込み可能な
rootfsを有効にするには、prepare-root.confで次のオプションを設定します。
[root] transient = true
これにより、ソフトウェアは、永続化する必要のあるコンテンツに対して /var へのシンボリックリンクを使用して、一時的に /opt に書き込むことができます。
