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