2.9. 高度なビルドの実行
以下のセクションでは、ビルドリソースおよび最長期間の設定、ビルドのノードへの割り当て、チェーンビルド、ビルドのプルーニング、およびビルド実行ポリシーなどの高度なビルド操作について説明します。
2.9.1. ビルドリソースの設定
デフォルトでは、ビルドは、メモリーや CPU など、バインドされていないリソースを使用して Pod により完了されます。これらのリソースは制限できます。
手順
リソースの使用を制限する方法は 2 つあります。
- プロジェクトのデフォルトコンテナー制限でリソース制限を指定して、リソースを制限します。
リソースの制限をビルド設定の一部として指定し、リソースの使用を制限します。** 以下の例では、
resources
、cpu
、およびmemory
パラメーターはそれぞれオプションです。apiVersion: "v1" kind: "BuildConfig" metadata: name: "sample-build" spec: resources: limits: cpu: "100m" 1 memory: "256Mi" 2
ただし、クォータがプロジェクトに定義されている場合には、以下の 2 つの項目のいずれかが必要です。
明示的な
requests
で設定したresources
セクション:resources: requests: 1 cpu: "100m" memory: "256Mi"
- 1
requests
オブジェクトは、クォータ内のリソース一覧に対応するリソース一覧を含みます。
プロジェクトに定義される制限範囲。
LimitRange
オブジェクトからのデフォルト値がビルドプロセス時に作成される Pod に適用されます。適用されない場合は、クォータ基準を満たさないために失敗したというメッセージが出され、ビルド Pod の作成は失敗します。
2.9.2. 最長期間の設定
BuildConfig
オブジェクトの定義時に、completionDeadlineSeconds
フィールドを設定して最長期間を定義できます。このフィールドは秒単位で指定し、デフォルトでは設定されません。設定されていない場合は、最長期間は有効ではありません。
最長期間はビルドの Pod がシステムにスケジュールされた時点から計算され、ビルダーイメージをプルするのに必要な時間など、ジョブが有効である期間を定義します。指定したタイムアウトに達すると、ジョブは OpenShift Container Platform により終了されます。
手順
最長期間を設定するには、
BuildConfig
にcompletionDeadlineSeconds
を指定します。以下の例はBuildConfig
の一部で、completionDeadlineSeconds
フィールドを 30 分に指定しています。spec: completionDeadlineSeconds: 1800
この設定は、パイプラインストラテジーオプションではサポートされていません。
2.9.3. 特定のノードへのビルドの割り当て
ビルドは、ビルド設定の nodeSelector
フィールドにラベルを指定して、特定のノード上で実行するようにターゲットを設定できます。nodeSelector
の値は、ビルド Pod のスケジュール時の Node
ラベルに一致するキー/値のペアに指定してください。
nodeSelector
の値は、クラスター全体のデフォルトでも制御でき、値を上書きできます。ビルド設定で nodeSelector
のキー/値ペアが定義されておらず、 nodeSelector:{}
が明示的に空になるように定義されていない場合にのみ、デフォルト値が適用されます。値を上書きすると、キーごとにビルド設定の値が置き換えられます。
指定の NodeSelector
がこれらのラベルが指定されているノードに一致しない場合には、ビルドは Pending
の状態が無限に続きます。
手順
以下のように、
BuildConfig
のnodeSelector
フィールドにラベルを割り当て、特定のー度で実行されるビルドを割り当てます。apiVersion: "v1" kind: "BuildConfig" metadata: name: "sample-build" spec: nodeSelector:1 key1: value1 key2: value2
- 1
- このビルド設定に関連するビルドは、
key1=value2
とkey2=value2
ラベルが指定されたノードでのみ実行されます。
2.9.4. チェーンビルド
コンパイル言語 (Go、C、C++、Java など) の場合には、アプリケーションイメージにコンパイルに必要な依存関係を追加すると、イメージのサイズが増加したり、悪用される可能性のある脆弱性が発生したりする可能性があります。
これらの問題を回避するには、2 つのビルドをチェーンでつなげることができます。1 つ目のビルドでコンパイルしたアーティファクトを作成し、2 つ目のビルドで、アーティファクトを実行する別のイメージにそのアーティファクトを配置します。
以下の例では、Source-to-Image (S2I) ビルドが docker ビルドに組み合わされ、別のランタイムイメージに配置されるアーティファクトがコンパイルされます。
この例では、S2I ビルドと docker ビルドをチェーンでつないでいますが、1 つ目のビルドは、必要なアーティファクトを含むイメージを生成するストラテジーを使用し、2 つ目のビルドは、イメージからの入力コンテンツを使用できるストラテジーを使用できます。
最初のビルドは、アプリケーションソースを取得して、WAR
ファイルを含むイメージを作成します。このイメージは、artifact-image
イメージストリームにプッシュされます。アウトプットアーティファクトのパスは、使用する S2I ビルダーの assemble
スクリプトにより異なります。この場合、/wildfly/standalone/deployments/ROOT.war
に出力されます。
apiVersion: build.openshift.io/v1 kind: BuildConfig metadata: name: artifact-build spec: output: to: kind: ImageStreamTag name: artifact-image:latest source: git: uri: https://github.com/openshift/openshift-jee-sample.git ref: "master" strategy: sourceStrategy: from: kind: ImageStreamTag name: wildfly:10.1 namespace: openshift
2 つ目のビルドは、1 つ目のビルドからのアウトプットイメージ内にある WAR ファイルへのパスが指定されているイメージソースを使用します。インライン dockerfile
は、 WAR
ファイルをランタイムイメージにコピーします。
apiVersion: build.openshift.io/v1 kind: BuildConfig metadata: name: image-build spec: output: to: kind: ImageStreamTag name: image-build:latest source: dockerfile: |- FROM jee-runtime:latest COPY ROOT.war /deployments/ROOT.war images: - from: 1 kind: ImageStreamTag name: artifact-image:latest paths: 2 - sourcePath: /wildfly/standalone/deployments/ROOT.war destinationDir: "." strategy: dockerStrategy: from: 3 kind: ImageStreamTag name: jee-runtime:latest triggers: - imageChange: {} type: ImageChange
この設定の結果、2 番目のビルドのアウトプットイメージに、WAR
ファイルの作成に必要なビルドツールを含める必要がなくなります。また、この 2 番目のビルドにはイメージ変更のトリガーが含まれているので、1 番目のビルドがバイナリーアーティファクトで新規イメージを実行して作成するたびに、2 番目のビルドが自動的に、そのアーティファクトを含むランタイムイメージを生成するためにトリガーされます。そのため、どちらのビルドも、ステージが 2 つある単一ビルドのように振る舞います。
2.9.5. ビルドのプルーニング
デフォルトで、ライフサイクルを完了したビルドは無制限に保持されます。保持される以前のビルドの数を制限することができます。
手順
successfulBuildsHistoryLimit
またはfailedBuildsHistoryLimit
の正の値をBuildConfig
に指定して、保持される以前のビルドの数を制限します。 以下は例になります。apiVersion: "v1" kind: "BuildConfig" metadata: name: "sample-build" spec: successfulBuildsHistoryLimit: 2 1 failedBuildsHistoryLimit: 2 2
以下の動作のいずれかを実行して、ビルドのプルーニングをトリガーします。
- ビルド設定が更新された場合
- ビルドがそのライフサイクルを完了するのを待機します。
ビルドは、作成時のタイムスタンプで分類され、一番古いビルドが先にプルーニングされます。
管理者は、'oc adm' オブジェクトプルーニングコマンドを使用して、ビルドを手動でプルーニングできます。
2.9.6. ビルド実行ポリシー
ビルド実行ポリシーでは、ビルド設定から作成されるビルドを実行する順番を記述します。これには、Build
の spec
セクションにある runPolicy
フィールドの値を変更してください。
既存のビルド設定の runPolicy
値を変更することも可能です。以下を実行します。
-
Parallel
からSerial
やSerialLatestOnly
に変更して、この設定から新規ビルドをトリガーすると、新しいビルドは並列ビルドすべてが完了するまで待機します。 これは、順次ビルドは、一度に 1 つしか実行できないためです。 -
Serial
をSerialLatestOnly
に変更して、新規ビルドをトリガーすると、現在実行中のビルドと直近で作成されたビルド以外には、キューにある既存のビルドがすべてキャンセルされます。最新のビルドが次に実行されます。