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
命令は、BuildConfig
の from
に置き換えられます。
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 のそれぞれの命令を表す層を作成します。imageOptimizationPolicy
を SkipLayers
に設定することにより、すべての命令がベースイメージ上部の単一層にマージされます。
手順
imageOptimizationPolicy
をSkipLayers
に設定します。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
2.5.2. Source-to-Image ビルド
Source-to-Image (S2I) は再現可能なコンテナーイメージをビルドするためのツールです。これはアプリケーションソースをコンテナーイメージに挿入し、新規イメージをアセンブルして実行可能なイメージを生成します。新規イメージはベースイメージ、ビルダーおよびビルドされたソースを組み込み、buildah run
コマンドで使用することができます。S2I は増分ビルドをサポートします。これは以前にダウンロードされた依存関係や、以前にビルドされたアーティファクトなどを再利用します。
2.5.2.1. Source-to-Image (S2I) 増分ビルドの実行
Source-to-Image (S2I) は増分ビルドを実行できます。 つまり、以前にビルドされたイメージからアーティファクトが再利用されます。
手順
増分ビルドを作成するには、ストラテジー定義に以下の変更を加えてこれを作成します。
strategy: sourceStrategy: from: kind: "ImageStreamTag" name: "incremental-image:latest" 1 incremental: true 2
関連情報
- 増分ビルドをサポートするビルダーイメージを作成する方法の詳細については、S2I 要件について参照してください。
2.5.2.2. Source-to-Image (S2I) ビルダーイメージスクリプトの上書き
ビルダーイメージによって提供される assemble
、run
、および save-artifacts
Source-to-Image (S2I) スクリプトを上書きできます。
手順
ビルダーイメージによって提供される assemble
、run
、および save-artifacts
S2I スクリプトを上書きするには、以下のいずれかを実行します。
-
アプリケーションのソースリポジトリーの
.s2i/bin
ディレクトリーにassemble
、run
、 またはsave-artifacts
スクリプトを指定します。 ストラテジー定義の一部として、スクリプトを含むディレクトリーの URL を指定します。以下に例を示します。
strategy: sourceStrategy: from: kind: "ImageStreamTag" name: "builder-image:latest" scripts: "http://somehost.com/scripts_directory" 1
- 1
- このパスに、
run
、assemble
、およびsave-artifacts
が追加されます。一部または全スクリプトがある場合、そのスクリプトが、イメージに指定された同じ名前のスクリプトの代わりに使用されます。
scripts
URL にあるファイルは、ソースリポジトリーの .s2i/bin
にあるファイルよりも優先されます。
2.5.2.3. Source-to-Image 環境変数
ソースビルドのプロセスと生成されるイメージで環境変数を利用できるようにする方法として、2 つの方法があります。2 種類 (環境ファイルおよび BuildConfig 環境の値の使用) あります。指定される変数は、ビルドプロセスでアウトプットイメージに表示されます。
2.5.2.3.1. Source-to-Image 環境ファイルの使用
ソースビルドでは、ソースリポジトリーの .s2i/environment
ファイルに指定することで、アプリケーション内に環境の値 (1 行に 1 つ) を設定できます。このファイルに指定される環境変数は、ビルドプロセス時にアウトプットイメージに表示されます。
ソースリポジトリーに .s2i/environment
ファイルを渡すと、Source-to-Image (S2I) はビルド時にこのファイルを読み取ります。これにより assemble
スクリプトがこれらの変数を使用できるので、ビルドの動作をカスタマイズできます。
手順
たとえば、ビルド中の Rails アプリケーションのアセットコンパイルを無効にするには、以下を実行します。
-
DISABLE_ASSET_COMPILATION=true
を.s2i/environment
ファイルに追加します。
ビルド以外に、指定の環境変数も実行中のアプリケーション自体で利用できます。たとえば、Rails アプリケーションが production
ではなく development
モードで起動できるようにするには、以下を実行します。
-
RAILS_ENV=development
を.s2i/environment
ファイルに追加します。
サポートされる環境変数の完全なリストについては、各イメージのイメージの使用についてのセクションを参照してください。
2.5.2.3.2. Source-to-Image ビルド設定環境の使用
環境変数をビルド設定の sourceStrategy
定義に追加できます。ここに定義されている環境変数は、assemble
スクリプトの実行時に表示され、アウトプットイメージで定義されるので、run
スクリプトやアプリケーションコードでも利用できるようになります。
手順
たとえば、Rails アプリケーションのアセットコンパイルを無効にするには、以下を実行します。
sourceStrategy: ... env: - name: "DISABLE_ASSET_COMPILATION" value: "true"
関連情報
- ビルド環境のセクションでは、より詳細な説明を提供します。
-
oc set env
コマンドで、ビルド設定に定義した環境変数を管理することも可能です。
2.5.2.4. Source-to-Image ソースファイルを無視する
Source-to-Image (S2I) は .s2iignore
ファイルをサポートします。これには、無視する必要のあるファイルパターンの一覧が含まれます。このファイルには、無視すべきファイルパターンの一覧が含まれます。 .s2iignore
ファイルにあるパターンと一致する、さまざまな入力ソースで提供されるビルドの作業ディレクトリーにあるファイルは assemble
スクリプトでは利用できません。
2.5.2.5. Source-to-Image によるソースコードからのイメージの作成
Source-to-Image (S2I) は、アプリケーションのソースコードを入力として取り、アセンブルされたアプリケーションを出力として実行する新規イメージを生成するイメージを簡単に作成できるようにするフレームワークです。
再生成可能なコンテナーイメージのビルドに S2I を使用する主な利点として、開発者の使い勝手の良さが挙げられます。ビルダーイメージの作成者は、イメージが最適な S2I パフォーマンスを実現できるように、ビルドプロセスと S2I スクリプトの基本的なコンセプト 2 点を理解する必要があります。
2.5.2.5.1. Source-to-Image ビルドプロセスについて
ビルドプロセスは、以下の 3 つの要素で設定されており、これら 3 つを組み合わせて最終的なコンテナーイメージが作成されます。
- ソース
- Source-to-Image (S2I) スクリプト
- ビルダーイメージ
S2I は、最初の FROM
命令として、ビルダーイメージで Dockerfile を生成します。S2I によって生成される Dockerfile は Buildah に渡されます。
2.5.2.5.2. Source-to-Image スクリプトの作成方法
Source-to-Image (S2I) スクリプトは、ビルダーイメージ内でスクリプトを実行できる限り、どのプログラム言語でも記述できます。S2I は assemble
/run
/save-artifacts
スクリプトを提供する複数のオプションをサポートします。ビルドごとに、これらの場所はすべて、以下の順番にチェックされます。
- ビルド設定に指定されるスクリプト
-
アプリケーションソースの
.s2i/bin
ディレクトリーにあるスクリプト -
io.openshift.s2i.scripts-url
ラベルを含むデフォルトの URL にあるスクリプト
イメージで指定した io.openshift.s2i.scripts-url
ラベルも、ビルド設定で指定したスクリプトも、以下の形式のいずれかを使用します。
-
image:///path_to_scripts_dir
: S2I スクリプトが配置されているディレクトリーへのイメージ内の絶対パス。 -
file:///path_to_scripts_dir
: S2I スクリプトが配置されているディレクトリーへのホスト上の相対パスまたは絶対パス。 -
http(s)://path_to_scripts_dir
: S2I スクリプトが配置されているディレクトリーの URL。
スクリプト | 説明 |
---|---|
|
|
|
|
|
これらの依存関係は |
|
|
|
注記
|
S2I スクリプトの例
以下の S2I スクリプトの例は Bash で記述されています。それぞれの例では、tar
の内容は /tmp/s2i
ディレクトリーに展開されることが前提とされています。
assemble
スクリプト:
#!/bin/bash # restore build artifacts if [ "$(ls /tmp/s2i/artifacts/ 2>/dev/null)" ]; then mv /tmp/s2i/artifacts/* $HOME/. fi # move the application source mv /tmp/s2i/src $HOME/src # build application artifacts pushd ${HOME} make all # install the artifacts make install popd
run
スクリプト:
#!/bin/bash # run the application /opt/application/run.sh
save-artifacts
スクリプト:
#!/bin/bash pushd ${HOME} if [ -d deps ]; then # all deps contents to tar stream tar cf - deps fi popd
usage
スクリプト:
#!/bin/bash # inform the user how to use the image cat <<EOF This is a S2I sample builder image, to use it, install https://github.com/openshift/source-to-image EOF
関連情報
2.5.2.6. ビルドボリュームの使用
ビルドボリュームをマウントして、実行中のビルドに、アウトプットコンテナーイメージで永続化しない情報にアクセスできます。
ビルドボリュームは、ビルド時にビルド環境や設定が必要なリポジトリーの認証情報など、機密情報のみを提供します。ビルドボリュームは、データが出力コンテナーイメージに保持される ビルド入力 とは異なります。
実行中のビルドがデータを読み取るビルドボリュームのマウントポイントは機能的に pod volume mounts に似ています。
手順
BuildConfig
オブジェクトのsourceStrategy
定義で、ビルドボリュームをvolumes
配列に追加します。以下に例を示します。spec: sourceStrategy: 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
2.5.3. カスタムビルド
カスタムビルドストラテジーにより、開発者はビルドプロセス全体を対象とする特定のビルダーイメージを定義できます。独自のビルダーイメージを使用することにより、ビルドプロセスをカスタマイズできます。
カスタムビルダーイメージは、RPM またはベースイメージの構築など、ビルドプロセスのロジックに組み込まれるプレーンなコンテナーイメージです。
カスタムビルドは高いレベルの権限で実行されるため、デフォルトではユーザーが利用することはできません。クラスター管理者のパーミッションを持つ信頼できるユーザーのみにカスタムビルドを実行するためのアクセスが付与される必要があります。
2.5.3.1. カスタムビルドの FROM イメージの使用
customStrategy.from
セクションを使用して、カスタムビルドに使用するイメージを指定できます。
手順
customStrategy.from
セクションを設定するには、以下を実行します。strategy: customStrategy: from: kind: "DockerImage" name: "openshift/sti-image-builder"
2.5.3.2. カスタムビルドでのシークレットの使用
すべてのビルドタイプに追加できるソースおよびイメージのシークレットのほかに、カスタムストラテジーを使用することにより、シークレットの任意の一覧をビルダー Pod に追加できます。
手順
各シークレットを特定の場所にマウントするには、
strategy
YAML ファイルのsecretSource
およびmountPath
フィールドを編集します。strategy: customStrategy: secrets: - secretSource: 1 name: "secret1" mountPath: "/tmp/secret1" 2 - secretSource: name: "secret2" mountPath: "/tmp/secret2"
2.5.3.3. カスタムビルドの環境変数の使用
環境変数をカスタムビルドプロセスで利用可能にするには、環境変数をビルド設定の customStrategy
定義に追加できます。
ここに定義された環境変数は、カスタムビルドを実行する Pod に渡されます。
手順
ビルド時に使用されるカスタムの HTTP プロキシーを定義します。
customStrategy: ... env: - name: "HTTP_PROXY" value: "http://myproxy.net:5187/"
ビルド設定で定義された環境変数を管理するには、以下のコマンドを入力します。
$ oc set env <enter_variables>
2.5.3.4. カスタムビルダーイメージの使用
OpenShift Container Platform のカスタムビルドストラテジーにより、ビルドプロセス全体を対象とする特定のビルダーイメージを定義できます。パッケージ、JAR、WAR、インストール可能な ZIP、ベースイメージなどの個別のアーティファクトを生成するためにビルドが必要な場合は、カスタムビルドストラテジーを使用してカスタムビルダーイメージを使用します。
カスタムビルダーイメージは、RPM またはベースのコンテナーイメージの構築など、ビルドプロセスのロジックに組み込まれるプレーンなコンテナーイメージです。
さらに、カスタムビルダーは、単体または統合テストを実行する CI/CD フローなどの拡張ビルドプロセスを実装できます。
2.5.3.4.1. カスタムビルダーイメージ
呼び出し時に、カスタムのビルダーイメージは、ビルドの続行に必要な情報が含まれる以下の環境変数を受け取ります。
変数名 | 説明 |
---|---|
|
|
| ビルドするソースが含まれる Git リポジトリーの URL |
|
|
| ビルド時に使用する Git リポジトリーのサブディレクトリーを指定します。定義された場合にのみ表示されます。 |
| ビルドする Git 参照 |
| このビルドオブジェクトを作成した OpenShift Container Platform のマスターのバージョン |
| イメージをプッシュするコンテナーイメージレジストリー |
| ビルドするイメージのコンテナーイメージタグ名 |
|
|
2.5.3.4.2. カスタムビルダーのワークフロー
カスタムビルダーイメージの作成者は、ビルドプロセスを柔軟に定義できますが、ビルダーイメージは、OpenShift Container Platform 内でビルドを実行するために必要な以下の手順に従う必要があります。
-
Build
オブジェクト定義に、ビルドの入力パラメーターの必要情報をすべて含める。 - ビルドプロセスを実行する。
- ビルドでイメージが生成される場合には、ビルドの出力場所が定義されていれば、その場所にプッシュする。他の出力場所には環境変数を使用して渡すことができます。
2.5.4. パイプラインビルド
パイプラインビルドストラテジーは OpenShift Container Platform 4 では非推奨になりました。同等の機能および改善機能は、Tekton をベースとする OpenShift Container Platform Pipeline にあります。
OpenShift Container Platform の Jenkins イメージは完全にサポートされており、ユーザーは Jenkins ユーザーのドキュメントに従ってジョブで jenkinsfile
を定義するか、またはこれをソースコントロール管理システムに保存します。
開発者は、パイプラインビルドストラテジーを利用して Jenkins パイプラインプラグインで使用できるように Jenkins パイプラインを定義することができます。このビルドについては、他のビルドタイプの場合と同様に OpenShift Container Platform での起動、モニターリング、管理が可能です。
パイプラインワークフローは、ビルド設定に直接組み込むか、または Git リポジトリーに配置してビルド設定で参照して jenkinsfile
で定義します。
2.5.4.1. OpenShift Container Platform Pipeline について
パイプラインビルドストラテジーは OpenShift Container Platform 4 では非推奨になりました。同等の機能および改善機能は、Tekton をベースとする OpenShift Container Platform Pipeline にあります。
OpenShift Container Platform の Jenkins イメージは完全にサポートされており、ユーザーは Jenkins ユーザーのドキュメントに従ってジョブで jenkinsfile
を定義するか、またはこれをソースコントロール管理システムに保存します。
Pipeline により、OpenShift Container Platform でのアプリケーションのビルド、デプロイ、およびプロモートに対する制御が可能になります。Jenkins Pipeline ビルドストラテジー、jenkinsfiles
、および OpenShift Container Platform のドメイン固有言語 (DSL) (Jenkins クライアントプラグインで提供される) の組み合わせを使用することにより、すべてのシナリオにおける高度なビルド、テスト、デプロイおよびプロモート用のパイプラインを作成できます。
OpenShift Container Platform Jenkins 同期プラグイン
OpenShift Container Platform Jenkins 同期プラグインは、ビルド設定およびビルドオブジェクトを Jenkins ジョブおよびビルドと同期し、以下を提供します。
- Jenkins での動的なジョブおよび実行の作成。
- イメージストリーム、イメージストリームタグまたは設定マップからのエージェント Pod テンプレートの動的作成。
- 環境変数の挿入。
- OpenShift Container Platform Web コンソールでのパイプラインの可視化。
- Jenkins Git プラグインとの統合。これにより、OpenShift Container Platform ビルドからの Jenkins Git プラグインにコミット情報が渡されます。
- シークレットを Jenkins 認証情報エントリーに同期。
OpenShift Container Platform Jenkins クライアントプラグイン
OpenShift Container Platform Jenkins Client プラグインは、OpenShift Container Platform API Server との高度な対話を実現するために、読み取り可能かつ簡潔で、包括的で Fluent (流れるような) スタイルの Jenkins Pipeline 構文を提供することを目的とした Jenkins プラグインです。このプラグインは、スクリプトを実行するノードで使用できる必要がある OpenShift Container Platform コマンドラインツール (oc
) を使用します。
OpenShift Jenkins クライアントプラグインは Jenkins マスターにインストールされ、OpenShift Container Platform DSL がアプリケーションの jenkinsfile
内で利用可能である必要があります。このプラグインは、OpenShift Container Platform Jenkins イメージの使用時にデフォルトでインストールされ、有効にされます。
プロジェクト内で OpenShift Container Platform Pipeline を使用するには、Jenkins Pipeline ビルドストラテジーを使用する必要があります。このストラテジーはソースリポジトリーのルートで jenkinsfile
を使用するようにデフォルト設定されますが、以下の設定オプションも提供します。
-
ビルド設定内のインラインの
jenkinsfile
フィールド。 -
ソース
contextDir
との関連で使用するjenkinsfile
の場所を参照するビルド設定内のjenkinsfilePath
フィールド。
オプションの jenkinsfilePath
フィールドは、ソース contextDir
との関連で使用するファイルの名前を指定します。contextDir
が省略される場合、デフォルトはリポジトリーのルートに設定されます。jenkinsfilePath
が省略される場合、デフォルトは jenkinsfile
に設定されます。
2.5.4.2. パイプラインビルド用の Jenkins ファイルの提供
パイプラインビルドストラテジーは OpenShift Container Platform 4 では非推奨になりました。同等の機能および改善機能は、Tekton をベースとする OpenShift Container Platform Pipeline にあります。
OpenShift Container Platform の Jenkins イメージは完全にサポートされており、ユーザーは Jenkins ユーザーのドキュメントに従ってジョブで jenkinsfile
を定義するか、またはこれをソースコントロール管理システムに保存します。
jenkinsfile
は標準的な groovy 言語構文を使用して、アプリケーションの設定、ビルド、およびデプロイメントに対する詳細な制御を可能にします。
jenkinsfile
は以下のいずれかの方法で指定できます。
- ソースコードリポジトリー内にあるファイルの使用。
-
jenkinsfile
フィールドを使用してビルド設定の一部として組み込む。
最初のオプションを使用する場合、jenkinsfile
を以下の場所のいずれかでアプリケーションソースコードリポジトリーに組み込む必要があります。
-
リポジトリーのルートにある
jenkinsfile
という名前のファイル。 -
リポジトリーのソース
contextDir
のルートにあるjenkinsfile
という名前のファイル。 -
ソース
contextDir
に関連して BuildConfig のJenkinsPipelineStrategy
セクションのjenkinsfilePath
フィールドで指定される名前のファイル (指定される場合)。 指定されない場合は、リポジトリーのルートにデフォルト設定されます。
jenkinsfile
は Jenkins エージェント Pod で実行されます。 ここでは OpenShift Container Platform DSL を使用する場合に OpenShift Container Platform クライアントのバイナリーを利用可能にしておく必要があります。
手順
Jenkins ファイルを指定するには、以下のいずれかを実行できます。
- ビルド設定に Jenkins ファイルを埋め込む
- Jenkins ファイルを含む Git リポジトリーへの参照をビルド設定に追加する
埋め込み定義
kind: "BuildConfig" apiVersion: "v1" metadata: name: "sample-pipeline" spec: strategy: jenkinsPipelineStrategy: jenkinsfile: |- node('agent') { stage 'build' openshiftBuild(buildConfig: 'ruby-sample-build', showBuildLogs: 'true') stage 'deploy' openshiftDeploy(deploymentConfig: 'frontend') }
Git リポジトリーへの参照
kind: "BuildConfig"
apiVersion: "v1"
metadata:
name: "sample-pipeline"
spec:
source:
git:
uri: "https://github.com/openshift/ruby-hello-world"
strategy:
jenkinsPipelineStrategy:
jenkinsfilePath: some/repo/dir/filename 1
- 1
- オプションの
jenkinsfilePath
フィールドは、ソースcontextDir
との関連で使用するファイルの名前を指定します。contextDir
が省略される場合、デフォルトはリポジトリーのルートに設定されます。jenkinsfilePath
が省略される場合、デフォルトはjenkinsfile
に設定されます。
2.5.4.3. Pipeline ビルドの環境変数の使用
パイプラインビルドストラテジーは OpenShift Container Platform 4 では非推奨になりました。同等の機能および改善機能は、Tekton をベースとする OpenShift Container Platform Pipeline にあります。
OpenShift Container Platform の Jenkins イメージは完全にサポートされており、ユーザーは Jenkins ユーザーのドキュメントに従ってジョブで jenkinsfile
を定義するか、またはこれをソースコントロール管理システムに保存します。
環境変数を Pipeline ビルドプロセスで利用可能にするには、環境変数をビルド設定の jenkinsPipelineStrategy
定義に追加できます。
定義した後に、環境変数はビルド設定に関連する Jenkins ジョブのパラメーターとして設定されます。
手順
ビルド時に使用される環境変数を定義するには、YAML ファイルを編集します。
jenkinsPipelineStrategy: ... env: - name: "FOO" value: "BAR"
oc set env
コマンドで、ビルド設定に定義した環境変数を管理することも可能です。
2.5.4.3.1. BuildConfig 環境変数と Jenkins ジョブパラメーター間のマッピング
Pipeline ストラテジーのビルド設定への変更に従い、Jenkins ジョブが作成/更新されると、ビルド設定の環境変数は Jenkins ジョブパラメーターの定義にマッピングされます。 Jenkins ジョブパラメーター定義のデフォルト値は、関連する環境変数の現在の値になります。
Jenkins ジョブの初回作成後に、パラメーターを Jenkins コンソールからジョブに追加できます。パラメーター名は、ビルド設定の環境変数名とは異なります。上記の Jenkins ジョブ用にビルドを開始すると、これらのパラメーターが使用されます。
Jenkins ジョブのビルドを開始する方法により、パラメーターの設定方法が決まります。
-
oc start-build
で開始された場合には、ビルド設定の環境変数が対応するジョブインスタンスに設定するパラメーターになります。Jenkins コンソールからパラメーターのデフォルト値に変更を加えても無視されます。ビルド設定値が優先されます。 oc start-build -e
で開始する場合、-e
オプションで指定される環境変数の値が優先されます。- ビルド設定に一覧表示されていない環境変数を指定する場合、それらは Jenkins ジョブパラメーター定義として追加されます。
-
Jenkins コンソールから環境変数に対応するパラメーターに加える変更は無視されます。ビルド設定および
oc start-build -e
で指定する内容が優先されます。
- Jenkins コンソールで Jenkins ジョブを開始した場合には、ジョブのビルドを開始する操作の一環として、Jenkins コンソールを使用してパラメーターの設定を制御できます。
ジョブパラメーターに関連付けられる可能性のあるすべての環境変数を、ビルド設定に指定することが推奨されます。これにより、ディスク I/O が減り、Jenkins 処理時のパフォーマンスが向上します。
2.5.4.4. Pipeline ビルドのチュートリアル
パイプラインビルドストラテジーは OpenShift Container Platform 4 では非推奨になりました。同等の機能および改善機能は、Tekton をベースとする OpenShift Container Platform Pipeline にあります。
OpenShift Container Platform の Jenkins イメージは完全にサポートされており、ユーザーは Jenkins ユーザーのドキュメントに従ってジョブで jenkinsfile
を定義するか、またはこれをソースコントロール管理システムに保存します。
以下の例では、nodejs-mongodb.json
テンプレートを使用して Node.js/MongoDB
アプリケーションをビルドし、デプロイし、検証する OpenShift Container Platform Pipeline を作成する方法を紹介します。
手順
Jenkins マスターを作成するには、以下を実行します。
$ oc project <project_name>
oc new-project <project_name>
で新規プロジェクトを使用するか、または作成するプロジェクトを選択します。$ oc new-app jenkins-ephemeral 1
永続ストレージを使用する場合は、
jenkins-persistent
を代わりに使用します。以下の内容で
nodejs-sample-pipeline.yaml
という名前のファイルを作成します。注記Jenkins Pipeline ストラテジーを使用して
Node.js/MongoDB
のサンプルアプリケーションをビルドし、デプロイし、スケーリングするBuildConfig
オブジェクトを作成します。kind: "BuildConfig" apiVersion: "v1" metadata: name: "nodejs-sample-pipeline" spec: strategy: jenkinsPipelineStrategy: jenkinsfile: <pipeline content from below> type: JenkinsPipeline
jenkinsPipelineStrategy
でBuildConfig
オブジェクトを作成したら、インラインのjenkinsfile
を使用して、Pipeline に指示を出します。注記この例では、アプリケーションに Git リポジトリーを設定しません。
以下の
jenkinsfile
の内容は、OpenShift Container Platform DSL を使用して Groovy で記述されています。ソースリポジトリーにjenkinsfile
を追加することが推奨される方法ですが、この例では YAML Literal Style を使用してBuildConfig
にインラインコンテンツを追加しています。def templatePath = 'https://raw.githubusercontent.com/openshift/nodejs-ex/master/openshift/templates/nodejs-mongodb.json' 1 def templateName = 'nodejs-mongodb-example' 2 pipeline { agent { node { label 'nodejs' 3 } } options { timeout(time: 20, unit: 'MINUTES') 4 } stages { stage('preamble') { steps { script { openshift.withCluster() { openshift.withProject() { echo "Using project: ${openshift.project()}" } } } } } stage('cleanup') { steps { script { openshift.withCluster() { openshift.withProject() { openshift.selector("all", [ template : templateName ]).delete() 5 if (openshift.selector("secrets", templateName).exists()) { 6 openshift.selector("secrets", templateName).delete() } } } } } } stage('create') { steps { script { openshift.withCluster() { openshift.withProject() { openshift.newApp(templatePath) 7 } } } } } stage('build') { steps { script { openshift.withCluster() { openshift.withProject() { def builds = openshift.selector("bc", templateName).related('builds') timeout(5) { 8 builds.untilEach(1) { return (it.object().status.phase == "Complete") } } } } } } } stage('deploy') { steps { script { openshift.withCluster() { openshift.withProject() { def rm = openshift.selector("dc", templateName).rollout() timeout(5) { 9 openshift.selector("dc", templateName).related('pods').untilEach(1) { return (it.object().status.phase == "Running") } } } } } } } stage('tag') { steps { script { openshift.withCluster() { openshift.withProject() { openshift.tag("${templateName}:latest", "${templateName}-staging:latest") 10 } } } } } } }
- 1
- 使用するテンプレートへのパス
- 1 2
- 作成するテンプレート名
- 3
- このビルドを実行する
node.js
のエージェント Pod をスピンアップします。 - 4
- この Pipeline に 20 分間のタイムアウトを設定します。
- 5
- このテンプレートラベルが指定されたものすべてを削除します。
- 6
- このテンプレートラベルが付いたシークレットをすべて削除します。
- 7
templatePath
から新規アプリケーションを作成します。- 8
- ビルドが完了するまで最大 5 分待機します。
- 9
- デプロイメントが完了するまで最大 5 分待機します。
- 10
- すべてが正常に完了した場合は、
$ {templateName}:latest
イメージに$ {templateName}-staging:latest
のタグを付けます。ステージング環境向けのパイプラインのビルド設定は、変更する$ {templateName}-staging:latest
イメージがないかを確認し、このイメージをステージング環境にデプロイします。
注記以前の例は、宣言型のパイプラインスタイルを使用して記述されていますが、以前のスクリプト化されたパイプラインスタイルもサポートされます。
OpenShift Container Platform クラスターに Pipeline
BuildConfig
を作成します。$ oc create -f nodejs-sample-pipeline.yaml
独自のファイルを作成しない場合には、以下を実行して Origin リポジトリーからサンプルを使用できます。
$ oc create -f https://raw.githubusercontent.com/openshift/origin/master/examples/jenkins/pipeline/nodejs-sample-pipeline.yaml
Pipeline を起動します。
$ oc start-build nodejs-sample-pipeline
注記または、OpenShift Container Platform Web コンソールで Builds
Pipeline セクションに移動して、Start Pipeline をクリックするか、Jenkins コンソールから作成した Pipeline に移動して、Build Now をクリックして Pipeline を起動できます。 パイプラインが起動したら、以下のアクションがプロジェクト内で実行されるはずです。
- ジョブインスタンスが Jenkins サーバー上で作成される
- パイプラインで必要な場合には、エージェント Pod が起動される
Pipeline がエージェント Pod で実行されるか、またはエージェントが必要でない場合には master で実行される
-
template=nodejs-mongodb-example
ラベルの付いた以前に作成されたリソースは削除されます。 -
新規アプリケーションおよびそれに関連するすべてのリソースは、
nodejs-mongodb-example
テンプレートで作成されます。 ビルドは
nodejs-mongodb-example
BuildConfig
を使用して起動されます。- Pipeline は、ビルドが完了して次のステージをトリガーするまで待機します。
デプロイメントは、
nodejs-mongodb-example
のデプロイメント設定を使用して開始されます。- パイプラインは、デプロイメントが完了して次のステージをトリガーするまで待機します。
-
ビルドとデプロイに成功すると、
nodejs-mongodb-example:latest
イメージがnodejs-mongodb-example:stage
としてトリガーされます。
-
パイプラインで以前に要求されていた場合には、スレーブ Pod が削除される
注記OpenShift Container Platform Web コンソールで確認すると、最適な方法で Pipeline の実行を視覚的に把握することができます。Web コンソールにログインして、Builds
Pipelines に移動し、Pipeline を確認します。
2.5.5. Web コンソールを使用したシークレットの追加
プライベートリポジトリーにアクセスできるように、ビルド設定にシークレットを追加することができます。
手順
OpenShift Container Platform Web コンソールからプライベートリポジトリーにアクセスできるようにビルド設定にシークレットを追加するには、以下を実行します。
- 新規の OpenShift Container Platform プロジェクトを作成します。
- プライベートのソースコードリポジトリーにアクセスするための認証情報が含まれるシークレットを作成します。
- ビルド設定を作成します。
-
ビルド設定エディターページまたは Web コンソールの
create app from builder image
ページで、Source Secret を設定します。 - Save をクリックします。
2.5.6. プルおよびプッシュの有効化
プライベートレジストリーへのプルを実行できるようにするには、ビルド設定にプルシークレットを設定し、プッシュします。
手順
プライベートレジストリーへのプルを有効にするには、以下を実行します。
- ビルド設定にプルシークレットを設定します。
プッシュを有効にするには、以下を実行します。
- ビルド設定にプッシュシークレットを設定します。