第3章 ビルド入力の作成
以下のセクションでは、ビルド入力の概要、builds の動作に使用するソースコンテンツを提供するための入力の使用方法、およびビルド環境の使用およびシークレットの作成方法を説明します。
3.1. ビルド入力 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform で異なるビルド入力を使用して、ビルドのソースコンテンツを提供します。優先順位を理解すると、ビルドが正しいソースを使用するようにするのに役立ちます。
以下のビルド入力が利用可能であり、優先順位に従って一覧表示されます。
- インラインの Dockerfile 定義
- 既存イメージから抽出したコンテンツ
- Git リポジトリー
- バイナリー (ローカル) 入力
- 入力シークレット
- 外部アーティファクト
複数の異なる入力を単一のビルドにまとめることができます。インラインの Dockerfile が優先されるため、別の入力で指定される Dockerfile という名前の他のファイルは上書きされます。バイナリー (ローカル) 入力および Git リポジトリーは併用できません。
入力シークレットは、ビルド時に使用される特定のリソースや認証情報をビルドで生成される最終アプリケーションイメージで使用不可にする必要がある場合や、シークレットリソースで定義される値を使用する必要がある場合に役立ちます。外部アーティファクトは、他のビルド入力タイプのいずれとしても利用できない別のファイルをプルする場合に使用できます。
ビルドを実行すると、以下が行われます。
- 作業ディレクトリーが作成され、すべての入力内容がその作業ディレクトリーに配置されます。たとえば、入力 Git リポジトリーのクローンはこの作業ディレクトリーに作成され、入力イメージから指定されたファイルはターゲットのパスを使用してこの作業ディレクトリーにコピーされます。
-
ビルドプロセスによりディレクトリーが
contextDirに変更されます (定義されている場合)。 - インライン Dockerfile がある場合は、現在のディレクトリーに書き込まれます。
-
現在の作業ディレクトリーにある内容が Dockerfile、カスタムビルダーのロジック、または
assembleスクリプトが参照するビルドプロセスに提供されます。つまり、ビルドではcontextDir内にない入力コンテンツは無視されます。
以下のソース定義の例には、複数の入力タイプと、入力タイプの統合方法の説明が含まれています。それぞれの入力タイプの定義方法に関する詳細は、各入力タイプに関する個別のセクションを参照してください。
ここでは、以下のようになります。
uri- ビルド用の作業ディレクトリーにクローンを作成するリポジトリーを指定します。
destinationDir- ビルド用の作業ディレクトリーにクローンを作成するリポジトリーを指定します。
contextDir-
ビルドの作業ディレクトリーを <
original_workingdir>/app/dirに指定します。 Dockerfile-
このコンテンツを含む Dockerfile は
<original_workingdir>/app/dirに作成され、この名前が指定された既存ファイルは上書きされます。