Menu Close

2.5. ビルドストラテジーの使用

以下のセクションでは、主なサポートされているビルドストラテジー、およびそれらの使用方法を定義します。

2.5.1. Docker ビルド

OpenShift Container Platform は Buildah を使用して Dockerfile からコンテナーイメージをビルドします。Dockerfile を使用したコンテナーイメージのビルドについての詳細は、Dockerfile リファレンスドキュメントを参照してください。

ヒント

buildArgs 配列を使用して Docker ビルド引数を設定する場合は、Dockerfile リファレンスドキュメントのARG および FROM の対話方法について参照してください。

2.5.1.1. Dockerfile FROM イメージの置き換え

Dockerfile の FROM 命令は、BuildConfig オブジェクトの from に置き換えられます。Dockerfile がマルチステージビルドを使用する場合、最後の FROM 命令のイメージを置き換えます。

手順

Dockerfile の FROM 命令は、BuildConfigfrom に置き換えられます。

strategy:
  dockerStrategy:
    from:
      kind: "ImageStreamTag"
      name: "debian:latest"

2.5.1.2. Dockerfile パスの使用

デフォルトで、docker ビルドは、BuildConfig.spec.source.contextDir フィールドで指定されたコンテキストのルートに配置されている Dockerfile を使用します。

dockerfilePath フィールドでは、ビルドが異なるパスを使用して Dockerfile ファイルの場所 (BuildConfig.spec.source.contextDir フィールドへの相対パス) を特定できます。デフォルトの Dockerfile (例: MyDockerfile) とは異なるファイル名や、サブディレクトリーにある Dockerfile へのパス (例: dockerfiles/app1/Dockerfile) を設定できます。

手順

ビルドが Dockerfile を見つけるために異なるパスを使用できるように dockerfilePath フィールドを使用するには、以下を設定します。

strategy:
  dockerStrategy:
    dockerfilePath: dockerfiles/app1/Dockerfile

2.5.1.3. docker 環境変数の使用

環境変数を docker ビルドプロセスおよび結果として生成されるイメージで利用可能にするには、環境変数をビルド設定の dockerStrategy 定義に追加できます。

ここに定義した環境変数は、Dockerfile 内で後に参照できるよう単一の ENV Dockerfile 命令として FROM 命令の直後に挿入されます。

手順

変数はビルド時に定義され、アウトプットイメージに残るため、そのイメージを実行するコンテナーにも存在します。

たとえば、ビルドやランタイム時にカスタムの HTTP プロキシーを定義するには以下を設定します。

dockerStrategy:
...
  env:
    - name: "HTTP_PROXY"
      value: "http://myproxy.net:5187/"

oc set env コマンドで、ビルド設定に定義した環境変数を管理することも可能です。

2.5.1.4. docker ビルド引数の追加

buildArgs 配列を使用して docker ビルド引数 を設定できます。ビルド引数は、ビルドの開始時に docker に渡されます。

ヒント

Dockerfile リファレンスドキュメントの「Understand how ARG and FROM interact」を参照してください。

手順

docker ビルドの引数を設定するには、以下のように buildArgs 配列にエントリーを追加します。これは、BuildConfig オブジェクトの dockerStrategy 定義の中にあります。以下に例を示します。

dockerStrategy:
...
  buildArgs:
    - name: "foo"
      value: "bar"
注記

name および value フィールドのみがサポートされます。valueFrom フィールドの設定は無視されます。

2.5.1.5. Docker ビルドによる層の非表示

Docker ビルドは通常、Dockerfile のそれぞれの命令を表す層を作成します。imageOptimizationPolicySkipLayers に設定することにより、すべての命令がベースイメージ上部の単一層にマージされます。

手順

  • imageOptimizationPolicySkipLayers に設定します。

    strategy:
      dockerStrategy:
        imageOptimizationPolicy: SkipLayers

2.5.1.6. ビルドボリュームの使用

ビルドボリュームをマウントして、実行中のビルドに、アウトプットコンテナーイメージで永続化しない情報にアクセスできます。

ビルドボリュームは、ビルド時にビルド環境や設定が必要なリポジトリーの認証情報など、機密情報のみを提供します。ビルドボリュームは、データが出力コンテナーイメージに保持されるビルド入力とは異なります。

実行中のビルドがデータを読み取るビルドボリュームのマウントポイントは機能的に pod volume mounts に似ています。

手順

  • BuildConfig オブジェクトの dockerStrategy 定義で、ビルドボリュームを volumes 配列に追加します。以下は例になります。

    spec:
      dockerStrategy:
        volumes:
          - name: secret-mvn 1
            mounts:
            - destinationPath: /opt/app-root/src/.ssh 2
            source:
              type: Secret 3
              secret:
                secretName: my-secret 4
          - name: settings-mvn 5
            mounts:
            - destinationPath: /opt/app-root/src/.m2  6
            source:
              type: ConfigMap 7
              configMap:
                name: my-config 8
    1 5
    必須。一意な名前
    2 6
    必須。マウントポイントの絶対パス。.. または : を含めないでください。こうすることで、ビルダーが生成した宛先パスと競合しなくなります。/opt/app-root/src は、多くの Red Hat S2I 対応イメージのデフォルトのホームディレクトリーです。
    3 7
    必須。ソースのタイプ、ConfigMap、または Secret
    4 8
    必須。ソースの名前。