カスタム・スクリプトを使用したパイプラインのカスタマイズ
カスタム・スクリプトは、パイプラインに追加されるカスタマイズです。 採用者、チーム、およびユーザーは、カスタム・タスクを実行するためのスクリプトを提供して、戦略の継続的な統合と継続的なデプロイメントを確保します。
カスタム・スクリプトは、パイプラインのステージを制御します。 設定ファイル(.pipeline-config.yaml )を使用して、ステージの動作、スクリプトの内容、およびスクリプトを実行するベースイメージを設定することができます。 パイプラインのステージのスクリプトと構成は、Git リポジトリーからロードされます。Git リポジトリーはアプリケーション (アプリ) リポジトリー (.travis.yml や Jenkinsfile のようなもの) かカスタム・リポジトリーのいずれかです。
カスタムスクリプトのいずれかが開始されると、ファイル名とコミットハッシュを含むカスタムスクリプトファイルの完全な URL、パイプラインログの先頭に次のように出力されます: The custom script can be viewed using the following link: 'https://<source repo url>/<organization name>/<repository name>/blob/<commit hash>/.pipeline-config.yaml'.
この配置により、トレーサビリティーが向上します。
詳細については、初心者向けDevSecOpsパイプラインのカスタマイズを/span>のを参照してください。
設定は .pipeline-config.yaml
.pipeline-config.yaml の設定ファイルを使用して、パイプラインの動作を拡張します。
ファイルの場所
プルリクエストおよび継続的インテグレーションのパイプラインについては、 .pipeline-config.yaml 設定ファイルを、 .travis.yml や Jenkinsfile ファイルと同様に、アプリのリポジトリに保存してください。 継続的デプロイのパイプラインについては、このファイルを専用のリポジトリに保存してください。
どのパイプラインの場合でも、以下のパイプライン UI パラメーターを使用して .pipeline-config.yaml ファイルの場所とソースをカスタマイズすることができます。
pipeline-config: 構成ファイルのパスを設定します。 デフォルト値は.pipeline-config.yamlです。pipeline-config-repo設定やスクリプトを取得するリポジトリを設定するため。 デフォルト値は、継続的インテグレーションアプリのレポジトリです。pipeline-config-branchconfigリポジトリ内の設定のブランチとして使用するため。 デフォルト値は、継続的インテグレーションではアプリリポジトリのブランチ、継続的デプロイメントではmasterブランチです。
構成パラメーター
.pipeline-config.yaml ファイルの構成では、以下のパラメーターがサポートされています。
これらの設定は、パイプラインのパラメーターではなく、.pipeline-config.yaml ファイルの中に含まれていなければなりません。
-
image: パイプライン・ワーカーがアクセス可能な任意の Docker イメージを、タスクの基本イメージとして使用できます。 -
script: ステージで実行するスクリプト。 このフィールドはスクリプトファイルとして使用されるため、その内容が、ご提供いただいたベースイメージ上でスクリプトファイルとして正常に動作することを確認してください。 この構成ファイルの次に他のスクリプトを含め、それらをこのエントリー・ポイントから参照することができます。 以下に例を示します。
test:
image: icr.io/continuous-delivery/pipeline/pipeline-base-image:2.69
script: |
#!/bin/sh
scripts/lint.sh
scripts/unit-test.sh
-
dind: スクリプト・コンテキストでdocker-in-dockerを有効にするかどうかを指定します。 デフォルト設定はfalseです。 -
abort_on_failure: デフォルトでは、スクリプトが失敗するとパイプラインは停止します。 これをfalseに設定すると、ステージに警告 (オレンジ色の状態) のマークが付けられ (警告とともに渡されます)、パイプラインの続行が許可され、失敗したジョブがエビデンスで参照されます。 -
image_pull_policy: ベースイメージのイメージに用意されている「ImagePullPolicy」設定をポッドに設定します。 設定可能な値は、Kubernetes で有効な値と同じ (AlwaysまたはIfNotPresent) です。 デフォルト値はIfNotPresentです。 -
configmap:PipelineRunでアクセス可能な、提供されている構成マップからキーと値のペアをプルします。 以下の値がサポートされます。config-name: 直接構成マップ名の構文。 ステージ・ランナーは、config-nameの名前を持つ構成マップにアクセスしてこれをマウントすることを試みます。$prop-name: 間接構成マップ名の構文。 構成マップ名は、パイプライン UI で設定されたすべての環境値が含まれる environment-properties 構成マップから検索されます。 たとえば、環境プロパティに「my-config」というプロパティが設定されている場合、「$prop」に対しては「my-config」が使用されます。
-
secret:PipelineRunでアクセス可能な、提供されている構成マップからキーと値のペアをプルします。 以下の値がサポートされます。-
secret-name: 直接シークレット名の構文。 ステージ・ランナーは、secret-nameの名前を持つシークレットにアクセスしてこれをマウントすることを試みます。 -
$prop-name: 間接シークレット名の構文。 「Secret」という名前は、パイプライン UI で設定されたすべての環境変数が含まれる environment-properties コンフィグマップ内にあります。 例えば、environment-properties 構成マップにmy-secretプロパティーが含まれている場合、my-secretが$propに使用されます。
-
-
runAfter: このプロパティーで指定されたステージの完了後に、現在のステージを実行します。.pipeline-config.yamlで使用したステージ名を使用して値を設定します。 このプロパティーを慎重に使用し、このプロパティーで指定されたステージがパイプラインに存在することを確認してください。 このステージが存在しない場合、パイプラインはデッドロックになる可能性があります。 -
skip:trueに設定すると、可能であれば、 v10 パイプラインで現在のステージをバイパスします。 すべてのステージをバイパスできるわけではありません。 以下の表に、パイプラインの実行中にスキップできるステージをリストします。
| パイプライン | ステージ |
|---|---|
| PR パイプライン | code-unit-tests、code-compliance-tests、およびcode-pr-finish |
| CI パイプライン | code-unit-tests、 code-static-scan、 code-compliance-checks、 build-scan-artifact、 code-dynamic-scan、 deploy-acceptance-tests、 deploy-release、および code-ci-finish |
| cd パイプライン | prod-verify-artifact、prod-acceptance-tests、およびprod-finish |
| CC パイプライン | cc-static-scan、 cc-dynamic-scan、 cc-compliance-checks、 cc-scan-artifact、および cc-finish |
| アプリ-PR パイプラインのプレビュー | code-unit-tests、 code-static-scan、 code-compliance-checks、 build-scan-artifact、 deploy-acceptance-tests、および app-preview-pr-finish |
| 開発モード CI パイプライン | code-unit-tests、 code-static-scan、 deploy-release、および code-ci-finish |
| 開発モード CD パイプライン | prod-acceptance-tests および prod-finish |
構成の例
version: '1' # fixed, this value is used to track schema changes
# `setup` runs right after the app repo is cloned
setup:
# the pipeline will break in case setup fails (default is true)
abort_on_failure: true
# any docker image can be used which is accessible by the private worker
image: icr.io/continuous-delivery/pipeline/pipeline-base-image:2.69
# you can reference configmaps, each key in the configmap is going to be available as `/config/{key}`
configmap: my-config
# `$prop` is the indirect config map syntax, the concrete configmap is looked
# up from the `environment-properties` configmap
#
# Eg. if there's a `prop: my-config` entry in the environment properties,
# then `my-config` is going to be used for `$prop`
configmap: $prop
# the mechanism described works for secrets as well!
secret: $my-secrets
# the script is executed inside the checked out app repo
script: |
#!/bin/sh
...
# `test` runs after `setup`, but before building the docker image
test:
image: icr.io/continuous-delivery/pipeline/pipeline-base-image:2.69
script: |
#!/bin/sh
...
# `static-scan` runs after `test`, but before building the docker image
static-scan:
image: ibmcom/pipeline-base-image:2.12
script: |
#!/bin/sh
...
# `deploy` runs after building the docker image
deploy:
image: icr.io/continuous-delivery/pipeline/pipeline-base-image:2.69
# the script has access to the built docker image, which is available at `/config/image`
script: |
#!/bin/sh
cat /config/image
# `dynamic-scan` runs after `deploy`, but before the acceptance test run
dynamic-scan:
image: ibmcom/pipeline-base-image:2.12
script: |
#!/bin/sh
...
# `acceptance-test` runs after `deploy`
acceptance-test:
image: icr.io/continuous-delivery/pipeline/pipeline-base-image:2.69
script: |
#!/bin/sh
...