2.9. 高度なビルドの実行

以下のセクションでは、ビルドリソースおよび最長期間の設定、ビルドのノードへの割り当て、チェーンビルド、ビルドのプルーニング、およびビルド実行ポリシーなどの高度なビルド操作について説明します。

2.9.1. ビルドリソースの設定

デフォルトでは、ビルドは、メモリーや CPU など、バインドされていないリソースを使用して Pod により完了されます。これらのリソースは制限できます。

手順

リソースの使用を制限する方法は 2 つあります。

  • プロジェクトのデフォルトコンテナー制限でリソース制限を指定して、リソースを制限します。
  • リソースの制限をビルド設定の一部として指定し、リソースの使用を制限します。** 以下の例では、resourcescpu、および memory パラメーターはそれぞれオプションです。

    apiVersion: "v1"
    kind: "BuildConfig"
    metadata:
      name: "sample-build"
    spec:
      resources:
        limits:
          cpu: "100m" 1
          memory: "256Mi" 2
    1
    cpu は CPU のユニットで、100m は 0.1 CPU ユニット (100 * 1e-3) を表します。
    2
    memory はバイト単位です。256Mi は 268435456 バイトを表します (256 * 2 ^ 20)。

    ただし、クォータがプロジェクトに定義されている場合には、以下の 2 つの項目のいずれかが必要です。

    • 明示的な requests で設定した resources セクション:

      resources:
        requests: 1
          cpu: "100m"
          memory: "256Mi"
      1
      requests オブジェクトは、クォータ内のリソース一覧に対応するリソース一覧を含みます。
    • プロジェクトに定義される制限範囲。 LimitRange オブジェクトからのデフォルト値がビルドプロセス時に作成される Pod に適用されます。

      適用されない場合は、クォータ基準を満たさないために失敗したというメッセージが出され、ビルド Pod の作成は失敗します。

2.9.2. 最長期間の設定

BuildConfig オブジェクトの定義時に、completionDeadlineSeconds フィールドを設定して最長期間を定義できます。このフィールドは秒単位で指定し、デフォルトでは設定されません。設定されていない場合は、最長期間は有効ではありません。

最長期間はビルドの Pod がシステムにスケジュールされた時点から計算され、ビルダーイメージをプルするのに必要な時間など、ジョブが有効である期間を定義します。指定したタイムアウトに達すると、ジョブは OpenShift Container Platform により終了されます。

手順

  • 最長期間を設定するには、BuildConfigcompletionDeadlineSeconds を指定します。以下の例は BuildConfig の一部で、completionDeadlineSeconds フィールドを 30 分に指定しています。

    spec:
      completionDeadlineSeconds: 1800
注記

この設定は、パイプラインストラテジーオプションではサポートされていません。

2.9.3. 特定のノードへのビルドの割り当て

ビルドは、ビルド設定の nodeSelector フィールドにラベルを指定して、特定のノード上で実行するようにターゲットを設定できます。nodeSelector の値は、ビルド Pod のスケジュール時の Node ラベルに一致するキー/値のペアに指定してください。

nodeSelector の値は、クラスター全体のデフォルトでも制御でき、値を上書きできます。ビルド設定で nodeSelector のキー/値ペアが定義されておらず、 nodeSelector:{} が明示的に空になるように定義されていない場合にのみ、デフォルト値が適用されます。値を上書きすると、キーごとにビルド設定の値が置き換えられます。

注記

指定の NodeSelector がこれらのラベルが指定されているノードに一致しない場合には、ビルドは Pending の状態が無限に続きます。

手順

  • 以下のように、BuildConfignodeSelector フィールドにラベルを割り当て、特定のー度で実行されるビルドを割り当てます。

    apiVersion: "v1"
    kind: "BuildConfig"
    metadata:
      name: "sample-build"
    spec:
      nodeSelector:1
        key1: value1
        key2: value2
    1
    このビルド設定に関連するビルドは、key1=value2key2=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
1
from は、docker ビルドに、以前のビルドのターゲットであった artifact-image イメージストリームからのイメージの出力を追加する必要があることを指定します。
2
paths は、現在の docker ビルドに追加するターゲットイメージからのパスを指定します。
3
ランタイムのイメージは、docker ビルドのソースイメージとして使用します。

この設定の結果、2 番目のビルドのアウトプットイメージに、WAR ファイルの作成に必要なビルドツールを含める必要がなくなります。また、この 2 番目のビルドにはイメージ変更のトリガーが含まれているので、1 番目のビルドがバイナリーアーティファクトで新規イメージを実行して作成するたびに、2 番目のビルドが自動的に、そのアーティファクトを含むランタイムイメージを生成するためにトリガーされます。そのため、どちらのビルドも、ステージが 2 つある単一ビルドのように振る舞います。

2.9.5. ビルドのプルーニング

デフォルトで、ライフサイクルを完了したビルドは無制限に保持されます。保持される以前のビルドの数を制限することができます。

手順

  1. successfulBuildsHistoryLimit または failedBuildsHistoryLimit の正の値を BuildConfig に指定して、保持される以前のビルドの数を制限します。 以下は例になります。

    apiVersion: "v1"
    kind: "BuildConfig"
    metadata:
      name: "sample-build"
    spec:
      successfulBuildsHistoryLimit: 2 1
      failedBuildsHistoryLimit: 2 2
    1
    successfulBuildsHistoryLimit は、completed のステータスのビルドを最大 2 つまで保持します。
    2
    failedBuildsHistoryLimit はステータスが failedcancelled または error のビルドを最大 2 つまで保持します。
  2. 以下の動作のいずれかを実行して、ビルドのプルーニングをトリガーします。

    • ビルド設定が更新された場合
    • ビルドがそのライフサイクルを完了するのを待機します。

ビルドは、作成時のタイムスタンプで分類され、一番古いビルドが先にプルーニングされます。

注記

管理者は、'oc adm' オブジェクトプルーニングコマンドを使用して、ビルドを手動でプルーニングできます。

2.9.6. ビルド実行ポリシー

ビルド実行ポリシーでは、ビルド設定から作成されるビルドを実行する順番を記述します。これには、Buildspec セクションにある runPolicy フィールドの値を変更してください。

既存のビルド設定の runPolicy 値を変更することも可能です。以下を実行します。

  • Parallel から SerialSerialLatestOnly に変更して、この設定から新規ビルドをトリガーすると、新しいビルドは並列ビルドすべてが完了するまで待機します。 これは、順次ビルドは、一度に 1 つしか実行できないためです。
  • SerialSerialLatestOnly に変更して、新規ビルドをトリガーすると、現在実行中のビルドと直近で作成されたビルド以外には、キューにある既存のビルドがすべてキャンセルされます。最新のビルドが次に実行されます。