Dockerfiles と Buildpacks を理解するための 7 つの画像、この 2 つをどのように選択すればよいでしょうか?

スクリプト化された Dockerfile と比較して、宣言型のクラウドネイティブビルドパックはいくつかの新しいシナリオをサポートします。

コンテナはどこにでもある

コンテナはほとんどのソフトウェア配信パイプラインに遍在しており、直接目に見えない場合もありますが、舞台裏で存在しています。 Kubernetes、通常の Docker ホスト、サーバーレス関数、または他の多くのオーケストレーションプラットフォームでソフトウェアを実行する場合でも、コンテナーは不変で実行可能なソフトウェア成果物を表します。

アプリケーションのソースコードを実行中のアプリケーションに変換するには、中間のコンテナービルドステージが必要であり、ソフトウェアをコンテナーに変換する非常に一般的な方法は Dockerfile を使用することです。

Dockerファイル

Dockerfile からコンテナを構築するのはスクリプト化されたアプローチであり、Dockerfile に含まれる内容のほとんどは、基本的にソフトウェアの構築や依存関係のインストールなどに必要なコマンドです。これは、Dockerfile の使用方法を学習するための学習曲線が緩やかであり、既存のビルドスクリプトをそれほど労力をかけずに Dockerfile に移植できることも意味します。

しかし、高品質のコンテナイメージを作成するのは簡単ではないことがわかりました。インターネットには、小さくて安全なベストプラクティスイメージを作成するためのガイドが満載です。通常、次の点を中心に展開します。

SIGTERM などのシグナルが適切に処理されることを保証することは、コンテナ契約の一部です。
アプリケーションを root ユーザーとして実行しないでください。
コンテナには不要なツール、シークレット、ビルド成果物を含めないでください。
最も変更が少ないレイヤーを最初など、キャッシュを最適化する順序でレイヤーを追加します。
画像に適切なタグと署名を付けます。

以下は、NodeJS アプリケーションに対してこれらの推奨事項の一部を実装する Dockerfile を示しています。 2 段階のビルドを使用して小さなイメージを作成し、非ルートとして実行し、操作を慎重に順序付けてキャッシュを改善します。

 ノードから: 16.13 .1 - alpine3 .14 AS ビルダー
WORKDIR / usr / src / app
 パッケージ* .json ./ をコピーします。
 npm ci を実行します
tsconfig.json をコピーします。
 コピーsrc src
 実行npm run build
 npm prune を実行— 本番環境
送信元ノード: 16.13 .1 - alpine3 .14
 WORKDIR / usr / src / app
 ユーザーノード
ENV NODE_ENV プロダクション
コピー— from = builder /usr/src/app/node_modules/./node_modules
 コピー— from = builder /usr/src/app/dist/./dist
 エクスポーズ8000
 コマンド[ "node" , "/usr/src/app/dist/main.js" ]

高品質の Dockerfile を作成するにはかなりの労力が必要であり、場合によっては Dockerfile が別のプロジェクトの Dockerfile の単なるコピーになることもあります。これにより Dockerfile が断片化され、複数のコンテナを持つ組織ではすぐに管理不能になる可能性があります。

ビルドパック

ビルドパックは、特定のタイプのほとんどのアプリケーションでは、アプリケーションのソースコードをコンテナーに変換することはほぼ同じであるという考えから生まれました。つまり、このプロセス用に再利用可能なプログラムを設計できるということです。このコンセプトは、Heroku によって開始され、Cloud Foundry、Google App engine、Gitlab、CircleCI などに採用されて以来、10 年以上にわたって開発されてきました。

コミュニティは、セキュリティとベストプラクティスのレベルが異なる各アプリケーションに対して断片化された Dockerfile を使用するのではなく、高品質のコンテナイメージビルドを提供できるように懸命に取り組んでいます。

コンテナイメージを構築するための宣言的なアプローチ

ビルドパックを使用する場合は、ビルドパックがコンテナを構築する方法を理解する必要があります。 Dockerfile を使用してコンテナを構築する方法をスクリプト化するのではなく、コンテナにパッケージ化するものを宣言し、ビルドパックに詳細を判断させることができます。

ビルドパックはいくつかのフェーズを実装しますが、そのうちの 2 つは次のとおりです。

検出: 各ビルドパックは、コンテナビルドに参加できるかどうかを検出します。たとえば、NodeJS アプリケーションの場合、_npm_ ビルドパックは package.json ファイルを探すことがあります。見つかった場合、ビルドパックはビルドに参加して依存関係を提供できることをビルダーに通知します。 Python ビルドパックは requirements.txt ファイルを検索しますが、NodeJS アプリケーションでは見つからないため、ビルドには参加しません。
ビルド: このフェーズでは、ビルドに参加できることを示しているすべてのビルドパックが実行され、ビルドが達成されます。上で述べたように、ビルドパックが何をビルドすべきかを検出する方法を知ることが重要です。つまり、NodeJS アプリケーションの開発者は、プロジェクトに package.json ファイルが含まれていることを確認する必要があります。さらに、特定のバージョンの Node ランタイムやその他の依存関係が必要な場合は、package.json ファイルでそれを明確にする必要があります。次に例を示します。

 {
 「エンジン」 :{
 「ノード」 : 「16.13.1」 、
 "npm" : "8.1.2"
 },
 「依存関係」 : {
 「エクスプレス」 ： 「4.17.2」
 }
 ...
 }

コンテナイメージはさまざまな形式でメタデータを保持し、ビルドパックは多くの場合、環境変数を使用してメタデータ設定を宣言します。以下は、Paketo image-labels ビルドパックを使用して、環境変数を使用してコンテナイメージに標準の org.opencontainers.description ラベルを設定する例です。環境変数の設定は、ビルド設定を宣言するための一般的な形式である project.toml ファイルを介して行われます。

 [[ 建てる。 環境]]
 名前= "BP_OCI_DESCRIPTION"
 value = "https://github.com/MichaelVL/buildpacks からのサンプル NodeJS"

Buildpacks のこの宣言型 API を理解することは、開発者にとって不可欠です。開発者は Dockerfiles を気にする必要はなく、ビルドパックの宣言型 API を知っておく必要があります。

再現可能なビルド、安全な配信チェーン

ビルドパックは、再現可能なビルドを実現することを目指しています。ビルドプロセスは完全に決定論的であり、同じ入力で実行すると同じ出力が生成されます。これにより、どのアプリケーションバイナリまたはソースがコンテナーにパッケージ化されているかを正確に検証し、悪意のあるアプリケーションがコンテナーにパッケージ化されるのからソフトウェア配信チェーンを保護することができます。

Dockerfiles を使用してイメージを構築する場合、まったく同じ入力が提供された場合でも、コンテナイメージ (およびそのハッシュ sha256 ダイジェスト) はイメージが再構築されるたびに変更されます。

再現可能なビルドはソフトウェアアーティファクトサプライチェーンレベル 4 の要件であり、ビルドパックはコンテナーイメージサプライチェーンのセキュリティを向上させる重要なツールです。

再現可能なビルドは、コンテナレイヤーの不要な再構築を回避するための効果的なメカニズムでもあります。

再構築速度とキャッシュの改善

Dockerfile 内の各行は、基本的に最終的なコンテナイメージにレイヤーを追加します。前のレイヤーが変更されない限り、レイヤーはキャッシュされ、再利用されます。先行するレイヤーが変更されると、Docker は再現可能なビルドを適用しないため、後続のすべてのレイヤーが再構築され、変更されます。

ビルドパックでは、各ビルドパックがコンテナイメージにレイヤーを提供します。ビルドパックの入力が変更されない場合、前のレイヤーが変更されたかどうかに関係なく、ビルドパックのレイヤーは変更されません。さらに、ビルドパックを使用すると、他のビルドパックによって生成されたレイヤーに影響を与えずに、個々のレイヤーを置き換えることができます。

コンテナベースイメージを更新する必要がある場合 (たとえば、セキュリティ上の問題のため)、他のアプリケーションレイヤーを再構築せずに、コンテナイメージにそのレイヤーを再インストールできます。 Dockerfile ベースのワークフローを使用してこれを実現するのは困難です。

シングルレイヤーリベースは、コンテナイメージのビルド時間だけでなく、コンテナのデプロイメントにも大きな改善をもたらします。特定のベースイメージを使用する 10 個のサービスがあると想像してください。セキュリティ上の問題によりこのベースイメージを更新する必要がある場合、Dockerfile に対してビルドを行うと、すべてのイメージのすべてのレイヤーが再構築されます。これにはビルド時間がかかり、10 個の新しいイメージ全体がダウンロードされます。ビルドパックのリベースメソッドを使用する場合、新しい共有ベースイメージを取得するだけで済みます。

コンテナは42年も経っているんですか？

ビルドパックを使用してコンテナをビルドすると、予期しないタイムスタンプが発生します。

 $ docker イメージls
 リポジトリタグイメージID 作成サイズ
サンプル- アプリ最新4713 a8f7d9bb 42 年前202 MB

これは再現可能なビルドの副作用です。再現可能なビルドを実現するために、コンテナイメージの違いを引き起こす時間依存データを回避すべく、時間が固定されます。ビルドパックは、古いファイル形式との互換性のために選択された、タイムスタンプの起点が 1980 00:00:01 であるイメージをビルドします。

ビルドパックを使用する際の役割

ビルドパックを使用してコンテナを構築する場合、次の 2 つの役割があります。

アプリケーション開発者: 開発者の焦点はアプリケーション中心である必要があり、コンテナビルドに関連する主な責任は、アプリケーションソース、依存関係のバージョン (NodeJS アプリケーションの場合は package.json など)、およびアプリケーション名やバージョンなどのメタデータを提供することです。コンテナの構築については、組織がキュレートしたビルダー/ビルドパックに完全な制御を委任します。ほとんどの問題をプラットフォームオペレーターに委任するには、開発者はビルダーのバージョンを修正するのではなく、最新のビルダー/ビルドパックを使用する必要があります。
ビルドプラットフォームオペレーター: ビルドプラットフォームオペレーターの責任は、開発者がコンテナのビルドに適用できる、厳選されたビルダーとビルドパックのセットを提供することです。これは主に、Paketo ビルドパックなどのコミュニティビルダーを活用することですが、オペレーターは企業固有の目的のために、独自に設計したビルドパックを追加することもできます。たとえば、会社に関連するメタデータを追加することが考えられます。ビルドプラットフォームオペレーターの主な懸念事項は、コンテナーランタイムイメージ (コンテナーベースイメージ) の更新とセキュリティです。

この関心の分離は、プラットフォームビルドオペレーターがコンテナイメージを制御できるため、複数のコンテナイメージを管理する組織にとって非常に価値があります。たとえば、実行中のイメージでセキュリティ上の問題が発見された場合、ビルダーの実行イメージを変更することで、新しい実行中のイメージを使用してすべてのコンテナを再構築できます。上で述べたように、これは非常に効率的なレイヤーのリベースになります。 Dockerfile を使用すると、すべてのアプリケーション Dockerfile のベースイメージを更新する必要があり、すべてのコンテナイメージレイヤーの再構築がトリガーされます。

コンテナにはどのようなソフトウェア部品表が含まれていますか

ビルドパックが Dockerfile ビルドプロセスを強化する方法の 1 つの例は、ビルド関連のメタデータをコンテナーイメージに添付する方法です。ソフトウェアプロジェクトには多くの依存関係が含まれており、これらの依存関係に関する情報はイメージのビルド時にコンテナーイメージに埋め込まれます。

ソフトウェア部品表 (SBOM) は、コンテナイメージに含まれるコンポーネントの構造化されたリストです。これを使用すると、SBOM を既知のセキュリティ問題と比較することで、安全なソフトウェアのみが使用されていることを確認できます。 SBOM は、どのソフトウェアライセンスがソフトウェアを管理しているかなどを確認するためにも使用できます。CycloneDX と SPDX は、構造化された SBOM データの 2 つの一般的な標準です。

以下は、NodeJS プロジェクトの SBOM からの抜粋です。ここでは、使用されている Node エンジンの正確なバージョンと、それを提供するビルドパックを確認できます。

 {
 {
 "name" : "ノードエンジン" ,
 「メタデータ」 : {
 "ソース" ： {
 「チェックサム」 : {
 「ハッシュ」 : 「34b23965457fb0587cda6fa898e5d030211f5f374cb6」
 },
 "uri" : "https://nodejs.org/.../node-v16.13.1.tar.gz"
 },
 「バージョン」 : 「16.13.1」
 },
 「ビルドパック」 : {
 "id" : "paketo-buildpacks/node-engine" ,
 「バージョン」 : 「0.11.2」
 }
 }
 }

SBOM を使用してソフトウェアを保護することは、コンテナイメージスキャナーの使用を強力に補完します。 SBOM はビルドパックから作成されるため、配信チェーンを正確かつ明確に識別します。コンテナイメージスキャナーは、コンテナの実際のコンテンツからこのバージョンを差し引く必要があるため、精度は低くなります。

Buildpacks の使い方は?

Cloud Native Buildpacks では、ビルドプロセスと Buildpacks が、ビルダーイメージとランナーイメージの 2 つのコンテナーイメージに含まれています。ある意味、これは改良された Dockerfile の 2 段階ビルドと見ることができます。次の図は、2 段階の Dockerfile ビルドが Buildpacks にどのようにマッピングされるかを示しています。 NodeJS アプリケーションのビルドロジックがビルドパックにどのようにマッピングされるかに注目してください (通常、このようなアプリケーションビルドは複数のビルドパックに分散されます)

ビルダーイメージには、順序付けられた一連のビルドパックを使用してビルドを行うためのロジック、ビルドパックのライフサイクルコンポーネントのオーケストレーター、および実行中のイメージへの参照が含まれています。 Dockerfile は線形に処理されるため、Dockerfile とライフサイクルコンポーネントの間には並列処理はありません。検出フェーズでは、ビルドパックはビルドをオプトインまたはオプトアウトし、ライフサイクルコンポーネントがこれを管理します。

最後に、ライフサイクルコンポーネントをトリガーするためのツールが必要です。これは、docker build コマンドに非常に似ています。これにはさまざまなツールがあり、最もよく知られているのは pack と Tekton ですが、CircleCI や Gitlab などの商用継続的インテグレーションベンダーもビルドパックを使用したビルドをサポートしています。

pack を使用した Github アクションワークフローの例については、こちらをご覧ください。

結論は

経験豊富な Dockerfile 作成者は、Dockerfile からビルドパックに移行するときに詳細を制御できなくなると感じるかもしれませんが、上記の利点により、ビルドパックの使用にオープンな心で取り組むことができるようになることが期待されます。ほとんどの開発者はビルドパックを気に入ると思います。コンテナの構築と Dockerfile の保守は主な焦点ではなく、むしろアプリケーションのデプロイに必要な手順でした。ビルドプラットフォームオペレーター、SRE、セキュリティチームにとって、ビルドパックはコンテナイメージとコンテナイメージに組み込まれた成果物に対する制御を復元するため、非常に便利です。

Dockerfile をクラウドネイティブビルドパックに置き換えると、コンテナイメージの構築方法が変わります。

開発者や組織にとって、宣言部分に重点を置くことが重要です。コンテナをどのように構築するか、また何を構築するかを宣言する方法を学ぶことが最も重要になります。

ビルドパックは完璧ですか?

そうでもないです。この記事を書いている間、冒頭で提案した 2 段階 Dockerfile のリーンコンテナービルドを再現しようとしましたが、完全には実現できず (Paketo ビルダーを使用)、結果として得られるコンテナーのサイズが少し大きくなってしまいました。ただし、ビルドパックは将来改善されることを期待しています。

ビルドパックを使用してコンテナにパッケージ化するのが難しいアプリケーションもいくつかあります。たとえば、コンテナ (VM スタイルのコンテナ) にパッケージ化された従来のモノリシックアプリケーションは、カスタムビルドパックなしでは実装が困難です。このようなアプリケーションはビルドパックとうまく連携せず、Dockerfile の低レベルの制御が必要になる可能性があります。これはおそらく、コンテナパッケージングで認識しておくべきことです。

<<: K8S ステートレスおよびステートフル、初心者向けガイド!

>>: 夏休み中にオープンソースを学んで賞品を獲得しましょう。 2022 Red Hat ITプロフェッショナル総合スキルコンテストにぜひご参加ください