GNU/Linux >> Linux の 問題 >  >> Linux

Podmanはルートレスオーバーレイのサポートを取得しています

Podmanは、Linuxカーネルバージョン5.13でネイティブオーバーレイファイルシステムを使用できます。これまで、fuse-overlayfsを使用してきました。カーネルは5.11カーネルでルートレスサポートを取得しましたが、バグによりファイルシステムでのSELinuxの使用が妨げられました。このバグは5.13で修正されました。

Fedoraは修正を5.12カーネルにバックポートしているように見えるので、ユーザーはカーネルにアクセスできればそれを使用できるはずです。

なぜ気にする必要があるのですか?

5.11バージョンまで、カーネルはユーザーがユーザー名前空間にいる間に限られた数のファイルシステムタイプをマウントすることを許可していました。それらには、tmpfs、bind mounts、procfs、sysfs、およびfuseが含まれていました。 Podmanは、ユーザー名前空間内でこのヒューズマウントサポートを使用してマウントされたfuse-overlayfsファイルシステムを長年使用していました。

ヒューズオーバーレイは素晴らしかったです。ただし、これはユーザースペースファイルシステムであるため、カーネルのほぼ2倍の作業を行う必要があります。すべての読み取り/書き込みは、ホストカーネルに渡される前にfuse-overlayによって解釈される必要があります。ファイルシステムに負荷をかける重いワークロードの場合、ヒューズオーバーレイのパフォーマンスが低下します。ヒューズオーバーレイがCPUをペギングしているのがわかります。結論として、特にルートレスモードの重い読み取り/書き込みコンテナの場合、ネイティブoverlayfsを使用するとパフォーマンスが向上するはずです。たとえば、podman build . パフォーマンスが大幅に向上するはずです。ボリュームに書き込む場合、fuse-overlayfsはほとんど使用されないため、パフォーマンスに影響はありません。

ヒューズオーバーレイのもう1つの欠点は、/dev/fuseにアクセスする必要があることです。 。制限されたコンテナ内でPodmanとBuildahを実行しようとすると、rootとして実行している場合でも、CAP_SYS_ADMIN特権が奪われます。これにより、ボリュームをマウントできるように、ユーザー名前空間を使用する必要があります。これを機能させるには、ユーザーは/dev/fuseを追加する必要があります コンテナに。ルートレスモードのネイティブオーバーレイができたら( CAP_SYS_ADMIN はありません) )、/dev/fuse 不要になります。

どうすれば使用できますか?

残念ながら、ネイティブオーバーレイは新しいストレージでしか使用できません。つまり、コンテナの既存のストレージをすべて破棄する必要があります。 podman system resetを行う必要があります すでに画像/コンテナがある場合。

これは、マウントプログラムを使用する場合、フラグファイルをストレージディレクトリ$STORAGE/overlay/.has-mount-programに保存するためです。 。ファイルが存在する場合、c/storageはネイティブオーバーレイのサポートを無視します。このようなチェックの理由は、fuse-overlayfsがメタデータを保存する方法に違いがあるためです。これには、非特権ユーザー用の特別なホワイトアウトデバイスの作成を許可しなかった古いカーネル上のホワイトアウトファイルが含まれ、ネイティブオーバーレイが有効になっている場合は機能しません。 。つまり、ファイルを削除するだけで、既存のコンテナに問題が発生します。

podman system reset コマンドはフラグファイルも削除します。その後、基盤となるカーネルでサポートされている場合は、ネイティブオーバーレイが使用されます。

他のディストリビューションに関する限り、このサポートはカーネル5.13がリリースされたときに表示されます。 RHEL / CentOSストリームについては、秋にRHEL8.5リリースの機能をバックポートする予定です。

引き続きfuse-overlayfsを使用/サポートしますか?

ヒューズオーバーレイを引き続き使用し、さらに強化する予定です。このプラットフォームを使用して新機能を試し、カーネルチームと話し合って、それらをネイティブにできるかどうかを確認します。

追加した顕著な機能の1つは、ファイルセキュリティ属性を拡張ファイル属性(xattrs)に格納するためのサポートです。これは、NFSホームディレクトリをサポートするために必要です。 NFSサーバーは、ユーザー名前空間内に複数のUIDを持つコンテナーの使用をブロックします。これにより、NFS homedirsのユーザーが停止します 追加のストレージを設定せずにPodmanを使用することから。ヒューズオーバーレイを使用すると、Podmanによって作成されたすべてのコンテンツを、Podmanを実行しているユーザーが所有するものとしてファイルシステムに保存できます。実行中のコンテナ内では、コンテンツはxattrsに基づいて異なるUID/GIDとして表されます。このモードで実行されているプロセスが異なるUIDでファイルを作成すると、fuse-overlayはUIDの作成をインターセプトし、マウンターUIDでファイルを作成し、異なるUIDをxattrに保存します。

[コンテナを使い始めますか?この無料コースをチェックしてください。コンテナ化されたアプリケーションのデプロイ:技術的な概要。 ]

まとめ

Rootless Podmanコンテナは進化を続け、ますます実用的になっています。重いワークロードの場合、ネイティブoverlayfは、fuse-overlayfsよりもはるかに優れたパフォーマンスエクスペリエンスを提供する必要があります。より良いサポートを提供するために、カーネルもバックポートされています。このすばらしい新機能をどのように使用する予定かをお知らせください。


Linux
  1. ルートレスのPodmanが私の画像をプルできないのはなぜですか?

  2. ルートレスのPodmanコンテナの舞台裏ではどうなりますか?

  3. ユーザーのルートレスPodmanへのアクセスの制御

  1. rootなしのPodmanをroot以外のユーザーとして実行する

  2. ターミナルウィンドウからLinuxでファイルを作成するには?

  3. cp -L 対 cp -H

  1. Podmanルートレスコンテナでのファイルとデバイスの使用

  2. リダイレクトの順序は?

  3. 大きなファイルをサポートする代替のGUIファイルエディタをお探しですか?