第1章 イメージビルドについて
1.1. ビルド
ビルド とは、入力パラメーターを結果として作成されるオブジェクトに変換するプロセスです。ほとんどの場合、このプロセスは入力パラメーターまたはソースコードを実行可能なイメージに変換するために使用されます。BuildConfig オブジェクトはビルドプロセス全体の定義です。
OpenShift Container Platform は、ビルドイメージからコンテナーを作成し、それらをコンテナーイメージレジストリーにプッシュして Kubernetes を使用します。
ビルドオブジェクトは共通の特性を共有します。これらには、ビルドの入力、ビルドプロセスの完了についての要件、ビルドプロセスのロギング、正常なビルドからのリリースのパブリッシュ、およびビルドの最終ステータスのパブリッシュが含まれます。ビルドはリソースの制限を利用し、CPU 使用、メモリー使用およびビルドまたは Pod の実行時間などのリソースの制限を指定します。
OpenShift Container Platform ビルドシステムは、ビルド API で指定される選択可能なタイプに基づくビルドストラテジー を幅広くサポートします。利用可能なビルドストラテジーは主に 3 つあります。
- Docker ビルド
- Source-to-Image (S2I) ビルド
- カスタムビルド
デフォルトで、Docker ビルドおよび S2I ビルドがサポートされます。
ビルドの結果作成されるオブジェクトはこれを作成するために使用されるビルダーによって異なります。Docker および S2I ビルドの場合、作成されるオブジェクトは実行可能なイメージです。カスタムビルドの場合、作成されるオブジェクトはビルダーイメージの作成者が指定するものになります。
さらに、Pipeline ビルドストラテジーを使用して、高度なワークフローを実装することができます。
- 継続的インテグレーション
- 継続的デプロイメント
1.1.1. Docker ビルド
Docker ビルドストラテジーは docker build コマンドを起動するため、Dockerfile とそれに含まれるすべての必要なアーティファクトのあるリポジトリーが実行可能なイメージを生成することを予想します。
1.1.2. Source-to-Image (S2I) ビルド
Source-to-Image (S2I) は再現可能な Docker 形式のコンテナーイメージをビルドするためのツールです。これはアプリケーションソースをコンテナーイメージに挿入し、新規イメージをアセンブルして実行可能なイメージを生成します。新規イメージはベースイメージ (ビルダー) とビルドされたソースを組み込み、buildah run コマンドで使用することができます。S2I は増分ビルドをサポートします。 これは以前にダウンロードされた依存関係や、以前にビルドされたアーティファクトなどを再利用します。
S2I の利点には以下が含まれます。
| イメージの柔軟性 |
S2I スクリプトを作成して、アプリケーションコードをほとんどすべての既存の Docker 形式コンテナーに挿入し、既存のエコシステムを活用することができます。現時点で S2I は |
| 速度 | S2I の場合、アセンブルプロセスは、各手順で新規の層を作成せずに多数の複雑な操作を実行でき、これによりプロセスが高速になります。さらに、S2I スクリプトを作成すると、ビルドが実行されるたびにダウンロードまたはビルドを実行することなく、アプリケーションイメージの以前のバージョンに保存されたアーティファクトを再利用できます。 |
| パッチ容易性 (Patchability) | S2I により、基礎となるイメージがセキュリティー上の問題でパッチを必要とする場合にアプリケーションを一貫して再ビルドできるようになります。 |
| 運用効率 | Dockerfile が許可するように任意のアクションを実行する代わりにビルド操作を制限することで、PaaS オペレーターはビルドシステムの意図しない、または意図した誤用を避けることができます。 |
| 運用上のセキュリティー | 任意の Dockerfile をビルドすると、root の権限昇格のためにホストシステムを公開します。これは、Docker ビルドプロセス全体が Docker 権限を持つユーザーとして実行されるため、悪意あるユーザーが悪用する可能性があります。S2I は root ユーザーとして実行される操作を制限し、スクリプトを root 以外のユーザーとして実行できます。 |
| ユーザー効率 |
S2I は開発者が任意の |
| エコシステム | S2I により、アプリケーションのベストプラクティスを利用できるイメージの共有されたエコシステムが促進されます。 |
| 再現性 | 生成されるイメージには、特定バージョンのビルドツールおよび依存関係などのすべての入力が含まれる可能性があります。これにより、イメージを正確に再現できます。 |
1.1.3. カスタムビルド
カスタムビルドストラテジーにより、開発者はビルドプロセス全体を対象とする特定のビルダーイメージを定義できます。独自のビルダーイメージを使用することにより、ビルドプロセスをカスタマイズできます。
カスタムビルダーイメージは、RPM またはベースイメージのビルド用などの、ビルドプロセスロジックで組み込まれた単純な Docker 形式のコンテナーイメージです。
カスタムビルドは非常に高いレベルの権限で実行されるため、デフォルトではユーザーが利用することはできません。クラスター管理者のパーミッションを持つ信頼できるユーザーのみにカスタムビルドを実行するためのアクセスが付与される必要があります。
1.1.4. パイプラインビルド
Pipeline ビルドストラテジーは OpenShift Container Platform 4 では非推奨になりました。同等の機能および改善機能は、Tekton をベースとする OpenShift Pipeline にあります。
OpenShift の Jenkins イメージは完全にサポートされており、ユーザーは Jenkins ユーザーのドキュメントに従ってジョブで Jenkinsfile を定義するか、またはこれをソースコントロール管理システムに保存します。
開発者は、Pipeline ビルドストラテジーを利用して Jenkins Pipeline プラグインで実行できるように Jenkins Pipeline を定義することができます。このビルドは他のビルドタイプの場合と同様に OpenShift Container Platform での起動、モニターリング、管理が可能です。
Pipeline ワークフローは、ビルド設定に直接組み込むか、または Git リポジトリーに配置してビルド設定で参照して Jenkinsfile で定義します。
