コンテナ内で Buildah を実行するためのガイドライン

コンテナー ランタイムを個別のツール コンポーネントに分離する利点は何でしょうか? 特に、これらのツールは相互に保護するために組み合わせることができます。

多くの人は、コンテナ化された OCI イメージを内部に構築するというアイデアに惹かれています。 Kubernetes または同様のシステム。 イメージを常に収集する CI/CD があるとします。次のようなものになります。 Red Hat OpenShift/Kubernetes は、ビルド中の負荷分散の点で非常に役立ちます。 最近まで、ほとんどの人はコンテナに Docker ソケットへのアクセスを許可し、docker build コマンドの実行を許可するだけでした。 数年前に私たちが見せたこれは非常に安全ではなく、実際、パスワードなしの root または sudo を与えるよりもさらに悪いです。

そのため、人々は常に Buildah をコンテナーで実行しようとします。 要するに、私たちが作成したのは、 例 私たちの意見では、コンテナ内で Buildah を実行するのが最善の方法であり、対応するイメージを次のサイトに投稿しました。 quay.io/buildah。 始めましょう...

調整

これらのイメージは、Buildah リポジトリのフォルダーにある Dockerfile からビルドされます。 画像を構築する.
ここで見ていきます Dockerfile の安定バージョン.

# stable/Dockerfile
#
# Build a Buildah container image from the latest
# stable version of Buildah on the Fedoras Updates System.
# https://bodhi.fedoraproject.org/updates/?search=buildah
# This image can be used to create a secured container
# that runs safely with privileges within the container.
#
FROM fedora:latest

# Don't include container-selinux and remove
# directories used by dnf that are just taking
# up space.
RUN yum -y install buildah fuse-overlayfs --exclude container-selinux; rm -rf /var/cache /var/log/dnf* /var/log/yum.*

# Adjust storage.conf to enable Fuse storage.
RUN sed -i -e 's|^#mount_program|mount_program|g' -e '/additionalimage.*/a "/var/lib/shared",' /etc/containers/storage.conf

ホスト Linux カーネル レベルで実装される OverlayFS の代わりに、コンテナ内のプログラムを使用します。 ヒューズオーバーレイなぜなら、現時点では、Linux 機能を使用して SYS_ADMIN 権限を付与した場合にのみ、OverlayFS をマウントできるからです。 そして、root 権限なしで Buildah コンテナを実行したいと考えています。 ヒューズ オーバーレイは非常に高速に動作し、VFS ストレージ ドライバーよりも優れたパフォーマンスを発揮します。 Fuse を使用する Buildah コンテナーを実行する場合は、/dev/fuse デバイスを指定する必要があることに注意してください。

podman run --device /dev/fuse quay.io/buildahctr ...
RUN mkdir -p /var/lib/shared/overlay-images /var/lib/shared/overlay-layers; touch /var/lib/shared/overlay-images/images.lock; touch /var/lib/shared/overlay-layers/layers.lock

次に、追加のストレージ用のディレクトリを作成します。 コンテナ・保管庫 追加の読み取り専用イメージ ストアを接続するという概念をサポートします。 たとえば、あるマシンにオーバーレイ ストレージ領域を構成し、NFS を使用してこのストレージを別のマシンにマウントし、プル経由でダウンロードせずにそこからイメージを使用できます。 このストレージは、ホストからイメージ ストレージをボリュームとして接続し、コンテナ内で使用できるようにするために必要です。

# Set up environment variables to note that this is
# not starting with user namespace and default to
# isolate the filesystem with chroot.
ENV _BUILDAH_STARTED_IN_USERNS="" BUILDAH_ISOLATION=chroot

最後に、BUILDAH_ISOLATION 環境変数を使用して、デフォルトで chroot 分離で実行するように Buildah コンテナーに指示します。 すでにコンテナ内で作業しているため、ここでは追加の断熱材は必要ありません。 Buildah が独自の名前空間分離コンテナーを作成するには、SYS_ADMIN 権限が必要です。これには、コンテナーの SELinux および SECCOMP ルールを緩和する必要があります。これは、安全なコンテナーから構築するという私たちの好みに反します。

コンテナ内でBuildahを実行する

上で説明した Buildah コンテナー イメージ図を使用すると、そのようなコンテナーの起動方法を柔軟に変更できます。

スピードと安全性

コンピューターのセキュリティは常に、プロセスの速度と、プロセスに適用される保護の程度との間の妥協点です。 このステートメントはコンテナを組み立てるときにも当てはまります。そのため、以下ではそのような妥協点のオプションを検討します。

上で説明したコンテナー イメージは、ストレージを /var/lib/containers に保持します。 したがって、コンテンツをこのフォルダーにマウントする必要があります。これをどのように行うかが、コンテナー イメージの構築速度に大きく影響します。

XNUMXつのオプションを考えてみましょう。

1オプション。 最大限のセキュリティが必要な場合は、コンテナごとにコンテナ/イメージ用の独自のフォルダを作成し、それをボリュームマウント経由でコンテナに接続できます。 さらに、コンテキスト ディレクトリをコンテナ自体の /build フォルダーに配置します。

# mkdir /var/lib/containers1
# podman run -v ./build:/build:z -v /var/lib/containers1:/var/lib/containers:Z quay.io/buildah/stable
buildah  -t image1 bud /build
# podman run -v /var/lib/containers1:/var/lib/containers:Z quay.io/buildah/stable buildah  push  image1 registry.company.com/myuser
# rm -rf /var/lib/containers1

セキュリティ。 このようなコンテナーで実行される Buildah には、最大限のセキュリティが備わっています: 機能を使用する root 権限は与えられず、SECOMP および SELinux のすべての制限が適用されます。このようなコンテナーは、—uidmap 0 のようなオプションを追加することで、ユーザー名前空間を分離して実行することもできます。 100000:10000。

パフォーマンス ただし、コンテナー レジストリのイメージは毎回ホストにコピーされ、キャッシュはまったく機能しないため、ここでのパフォーマンスは最小限です。 作業が完了すると、Buildah コンテナはイメージをレジストリに送信し、ホスト上のコンテンツを破棄する必要があります。 次回コンテナ イメージを構築するときは、その時点ではホストには何も残っていないため、レジストリから再度ダウンロードする必要があります。

2オプション。 Docker レベルのパフォーマンスが必要な場合は、ホスト コンテナー/ストレージをコンテナーに直接マウントできます。

# podman run -v ./build:/build:z -v /var/lib/containers:/var/lib/containers --security-opt label:disabled quay.io/buildah/stable buildah  -t image2 bud /build
# podman run -v /var/lib/containers:/var/lib/containers --security-opt label:disabled  quay.io/buildah/stable buildah push image2 registry.company.com/myuser

セキュリティ。 これは、コンテナがホスト上のストレージを変更できるようになり、潜在的に Podman または CRI-O に悪意のあるイメージをフィードする可能性があるため、コンテナを構築する最も安全性の低い方法です。 さらに、Buildah コンテナー内のプロセスがホスト上のストレージと対話できるように、SELinux 分離を無効にする必要があります。 コンテナーは残りのセキュリティ機能によってロックダウンされており、ホスト上で単純にコンテナーを実行できないため、このオプションは Docker ソケットよりも優れていることに注意してください。

パフォーマンス ここではキャッシュが完全に使用されているため、最大値になります。 Podman または CRI-O が必要なイメージをホストに既にダウンロードしている場合、コンテナ内の Buildah プロセスはそれを再度ダウンロードする必要はなく、このイメージに基づく後続のビルドでも必要なものをキャッシュから取得できます。 。

3オプション。 この方法の本質は、コンテナ イメージ用の共通フォルダーを使用して、複数のイメージを XNUMX つのプロジェクトに結合することです。

# mkdir /var/lib/project3
# podman run --security-opt label_level=s0:C100, C200 -v ./build:/build:z 
-v /var/lib/project3:/var/lib/containers:Z quay.io/buildah/stable buildah  -t image3 bud /build
# podman run --security-opt label_level=s0:C100, C200 
-v /var/lib/project3:/var/lib/containers quay.io/buildah/stable buildah push image3  registry.company.com/myuser

この例では、実行間でプロジェクト フォルダー (/var/lib/project3) を削除しないため、プロジェクト内の後続のすべてのビルドはキャッシュの恩恵を受けます。

セキュリティ。 オプション 1 と 2 の中間のもの。一方で、コンテナはホスト上のコンテンツにアクセスできないため、Podman/CRI-O イメージ ストレージに悪意のあるものを滑り込ませることはできません。 一方、設計の一部として、コンテナは他のコンテナの組み立てを妨げる可能性があります。

パフォーマンス ここでは、Podman/CRI-O を使用して既にダウンロードされたイメージを使用できないため、ホスト レベルで共有キャッシュを使用する場合よりも状況が悪くなります。 ただし、Buildah がイメージをダウンロードすると、そのイメージはプロジェクト内のその後のビルドで使用できます。

追加のストレージ

У コンテナ/ストレージ 追加ストア (追加ストア) というすばらしい機能があります。これにより、コンテナーの起動および構築時に、コンテナー エンジンは読み取り専用オーバーレイ モードで外部イメージ ストアを使用できます。 基本的に、XNUMX つ以上の読み取り専用ストレージを storage.conf ファイルに追加すると、コンテナーの起動時にコンテナー エンジンがストレージ内で目的のイメージを検索できるようになります。 さらに、これらのストレージのいずれにもイメージが見つからない場合にのみ、レジストリからイメージをダウンロードします。 コンテナ エンジンは書き込み可能なストレージにのみ書き込むことができます...

上にスクロールして、イメージ quay.io/buildah/stable の構築に使用する Dockerfile を見ると、次のような行があります。

# Adjust storage.conf to enable Fuse storage.
RUN sed -i -e 's|^#mount_program|mount_program|g' -e '/additionalimage.*/a "/var/lib/shared",' /etc/containers/storage.conf
RUN mkdir -p /var/lib/shared/overlay-images /var/lib/shared/overlay-layers; touch /var/lib/shared/overlay-images/images.lock; touch /var/lib/shared/overlay-layers/layers.lock

最初の行では、コンテナー イメージ内の /etc/containers/storage.conf を変更し、ストレージ ドライバーに /var/lib/shared フォルダー内の「Additionalimagestores」を使用するように指示します。 次の行では、共有フォルダーを作成し、コンテナー/ストレージからの悪用がないよう、いくつかのロック ファイルを追加します。 基本的には、単に空のコンテナー イメージ ストアを作成しているだけです。

このフォルダーより上位のレベルにコンテナー/ストレージをマウントすると、Buildah はイメージを使用できるようになります。

ここで、前述のオプション 2 に戻りましょう。この場合、Buildah コンテナはホスト上のコンテナ/ストアに対して読み書きでき、それに応じて、Podman/CRI-O レベルでのイメージのキャッシュにより最大のパフォーマンスが得られますが、最小限のセキュリティが提供されます。ストレージに直接書き込むことができるためです。 ここでストレージを追加して、両方のメリットを最大限に活用しましょう。

# mkdir /var/lib/containers4
# podman run -v ./build:/build:z -v /var/lib/containers/storage:/var/lib/shared:ro -v  /var/lib/containers4:/var/lib/containers:Z  quay.io/buildah/stable 
 buildah  -t image4 bud /build
# podman run -v /var/lib/containers/storage:/var/lib/shared:ro  
-v >/var/lib/containers4:/var/lib/containers:Z quay.io/buildah/stable buildah push image4  registry.company.com/myuser
# rm -rf /var/lib/continers4

ホストの /var/lib/containers/storage は、コンテナ内の /var/lib/shared に読み取り専用モードでマウントされることに注意してください。 したがって、コンテナ内で動作する Buildah は、Podman/CRI-O を使用して以前にダウンロードされたイメージを使用できます (こんにちは、スピード) が、書き込みできるのは独自のストレージ (こんにちは、セキュリティ) のみです。 また、これはコンテナーの SELinux 分離を無効にせずに行われることにも注意してください。

重要なニュアンス

いかなる状況でも、基盤となるリポジトリからイメージを削除しないでください。 そうしないと、Buildah コンテナがクラッシュする可能性があります。

利点はこれだけではありません

追加ストレージの可能性は上記のシナリオに限定されません。 たとえば、すべてのコンテナー イメージを共有ネットワーク ストレージに配置し、すべての Buildah コンテナーにそのイメージへのアクセスを許可できます。 CI/CD システムがコンテナー イメージを構築するために定期的に使用する数百のイメージがあるとします。 これらすべてのイメージを 3 つのストレージ ホストに集中させ、優先ネットワーク ストレージ ツール (NFS、Gluster、Ceph、ISCSI、SXNUMX...) を使用して、このストレージへの一般的なアクセスをすべての Buildah または Kubernetes ノードに開きます。

これで、このネットワーク ストレージを /var/lib/shared の Buildah コンテナにマウントするだけで十分です。Buildah コンテナはプル経由でイメージをダウンロードする必要がなくなりました。 したがって、事前設定フェーズを放棄し、すぐにコンテナーをロールアウトする準備が整います。

そしてもちろん、これをライブ Kubernetes システムまたはコンテナ インフラストラクチャ内で使用して、イメージをプル ダウンロードすることなくどこでもコンテナを起動して実行できます。 さらに、コンテナー レジストリは、更新されたイメージをアップロードするプッシュ リクエストを受信すると、このイメージを共有ネットワーク ストレージに自動的に送信し、そこですべてのノードが即座に利用できるようになります。

コンテナー イメージのサイズは数ギガバイトに達する場合があります。 追加ストレージの機能により、ノード間でのそのようなイメージのクローン作成を回避し、コンテナーをほぼ瞬時に起動できるようになります。

さらに、現在、コンテナーの構築をさらに高速化するオーバーレイ ボリューム マウントと呼ばれる新機能の開発に取り組んでいます。

まとめ

Kubernetes/CRI-O、Podman、さらには Docker のコンテナ内で Buildah を実行することは、実行可能かつ簡単で、docker.socket を使用するよりもはるかに安全です。 イメージの操作の柔軟性が大幅に向上したため、さまざまな方法でイメージを実行して、セキュリティとパフォーマンスのバランスを最適化できるようになりました。

追加ストレージの機能を使用すると、ノードへのイメージのダウンロードを高速化したり、完全に不要にしたりすることができます。

出所： habr.com