4.5. OpenShift Pipelines を使用したアプリケーションの CI/CD ソリューションの作成
Red Hat OpenShift Pipelines を使用すると、カスタマイズされた CI/CD ソリューションを作成して、アプリケーションをビルドし、テストし、デプロイできます。
アプリケーション向けの本格的なセルフサービス型の CI/CD パイプラインを作成するには、以下のタスクを実行する必要があります。
- カスタムタスクを作成するか、または既存の再利用可能なタスクをインストールします。
- アプリケーションの配信パイプラインを作成し、定義します。
以下の方法のいずれかを使用して、パイプライン実行のためにワークスペースに接続されているストレージボリュームまたはファイルシステムを提供します。
- 永続ボリューム要求 (PVC) を作成するボリューム要求テンプレートを指定します。
- 永続ボリューム要求 (PVC) を指定します。
-
PipelineRun
オブジェクトを作成し、Pipeline をインスタンス化し、これを起動します。 - トリガーを追加し、ソースリポジトリーのイベントを取得します。
このセクションでは、pipelines-tutorial
の例を使用して前述のタスクについて説明します。この例では、以下で設定される単純なアプリケーションを使用します。
-
pipelines-vote-ui
Git リポジトリーにソースコードがあるフロントエンドインターフェイス (pipelines-vote-ui
)。 -
pipelines-vote-api
Git リポジトリーにソースコードがあるバックエンドインターフェイス (pipelines-vote-api
)。 -
pipelines-tutorial
Git リポジトリーにあるapply-manifests
タスクおよびupdate-deployment
タスク。
4.5.1. 前提条件
- OpenShift Container Platform クラスターにアクセスできる。
- OpenShift OperatorHub に一覧表示されている Red Hat OpenShift Pipelines Operator を使用して OpenShift Pipelines をインストールしている。インストールが完了すると、クラスター全体に適用可能になります。
- OpenShift Pipelines CLI をインストールしている。
-
GitHub ID を使用してフロントエンドの
ui-repo
およびバックエンドのapi-repo
Git リポジトリーをフォークしており、これらのリポジトリーに管理者権限でアクセスできる。 -
オプション:
pipelines-tutorial
Git リポジトリーのクローンを作成している。
4.5.2. プロジェクトの作成およびパイプラインのサービスアカウントの確認
手順
OpenShift Container Platform クラスターにログインします。
$ oc login -u <login> -p <password> https://openshift.example.com:6443
サンプルアプリケーションのプロジェクトを作成します。このサンプルワークフローでは、
pipelines-tutorial
プロジェクトを作成します。$ oc new-project pipelines-tutorial
注記別の名前でプロジェクトを作成する場合は、サンプルで使用されているリソース URL をプロジェクト名で更新してください。
pipeline
サービスアカウントを表示します。Red Hat OpenShift Pipelines Operator は、イメージのビルドおよびプッシュを実行するのに十分なパーミッションを持つ
pipeline
という名前のサービスアカウントを追加し、設定します。このサービスアカウントはPipelineRun
オブジェクトによって使用されます。$ oc get serviceaccount pipeline
4.5.3. パイプラインタスクの作成
手順
pipelines-tutorial
リポジトリーからapply-manifests
およびupdate-deployment
タスクリソースをインストールします。これには、パイプラインの再利用可能なタスクの一覧が含まれます。$ oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/pipelines-1.5/01_pipeline/01_apply_manifest_task.yaml $ oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/pipelines-1.5/01_pipeline/02_update_deployment_task.yaml
tkn task list
コマンドを使用して、作成したタスクを一覧表示します。$ tkn task list
出力では、
apply-manifests
およびupdate-deployment
タスクリソースが作成されていることを検証します。NAME DESCRIPTION AGE apply-manifests 1 minute ago update-deployment 48 seconds ago
tkn clustertasks list
コマンドを使用して、buildah
およびs2i-python-3
などの Operator でインストールされた追加のクラスタータスクを一覧表示します。注記制限された環境で
buildah
クラスタータスクを使用するには、Dockerfile が内部イメージストリームをベースイメージとして使用していることを確認する必要があります。$ tkn clustertasks list
出力には、Operator でインストールされた
ClusterTask
リソースが一覧表示されます。NAME DESCRIPTION AGE buildah 1 day ago git-clone 1 day ago s2i-python 1 day ago tkn 1 day ago
4.5.4. パイプラインのアセンブル
パイプラインは CI/CD フローを表し、実行するタスクによって定義されます。これは、複数のアプリケーションや環境で汎用的かつ再利用可能になるように設計されています。
パイプラインは、from
および runAfter
パラメーターを使用してタスクが相互に対話する方法および実行順序を指定します。これは workspaces
フィールドを使用して、パイプラインの各タスクの実行中に必要な 1 つ以上のボリュームを指定します。
このセクションでは、GitHub からアプリケーションのソースコードを取り、これを OpenShift Container Platform にビルドし、デプロイするパイプラインを作成します。
パイプラインは、バックエンドアプリケーションの vote-api
およびフロントエンドアプリケーション vote-ui
について以下のタスクを実行します。
-
git-url
およびgit-revision
パラメーターを参照して、Git リポジトリーからアプリケーションのソースコードのクローンを作成します。 -
buildah
クラスタータスクを使用してコンテナーイメージをビルドします。 -
image
パラメーターを参照してイメージを内部イメージレジストリーにプッシュします。 -
apply-manifests
およびupdate-deployment
タスクを使用して新規イメージを OpenShift Container Platform にデプロイします。
手順
以下のサンプルのパイプライン YAML ファイルの内容をコピーし、保存します。
apiVersion: tekton.dev/v1beta1 kind: Pipeline metadata: name: build-and-deploy spec: workspaces: - name: shared-workspace params: - name: deployment-name type: string description: name of the deployment to be patched - name: git-url type: string description: url of the git repo for the code of deployment - name: git-revision type: string description: revision to be used from repo of the code for deployment default: "pipelines-1.5" - name: IMAGE type: string description: image to be built from the code tasks: - name: fetch-repository taskRef: name: git-clone kind: ClusterTask workspaces: - name: output workspace: shared-workspace params: - name: url value: $(params.git-url) - name: subdirectory value: "" - name: deleteExisting value: "true" - name: revision value: $(params.git-revision) - name: build-image taskRef: name: buildah kind: ClusterTask params: - name: IMAGE value: $(params.IMAGE) workspaces: - name: source workspace: shared-workspace runAfter: - fetch-repository - name: apply-manifests taskRef: name: apply-manifests workspaces: - name: source workspace: shared-workspace runAfter: - build-image - name: update-deployment taskRef: name: update-deployment params: - name: deployment value: $(params.deployment-name) - name: IMAGE value: $(params.IMAGE) runAfter: - apply-manifests
パイプライン定義は、Git ソースリポジトリーおよびイメージレジストリーの詳細を抽象化します。これらの詳細は、パイプラインのトリガーおよび実行時に
params
として追加されます。パイプラインを作成します。
$ oc create -f <pipeline-yaml-file-name.yaml>
または、Git リポジトリーから YAML ファイルを直接実行することもできます。
$ oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/pipelines-1.5/01_pipeline/04_pipeline.yaml
tkn pipeline list
コマンドを使用して、パイプラインがアプリケーションに追加されていることを確認します。$ tkn pipeline list
この出力では、
build-and-deploy
パイプラインが作成されていることを検証します。NAME AGE LAST RUN STARTED DURATION STATUS build-and-deploy 1 minute ago --- --- --- ---
4.5.5. 制限された環境でパイプラインを実行するためのイメージのミラーリング
OpenShift Pipelines を非接続のクラスターまたは制限された環境でプロビジョニングされたクラスターで実行するには、制限されたネットワークに Samples Operator が設定されているか、またはクラスター管理者がミラーリングされたレジストリーでクラスターを作成しているか確認する必要があります。
以下の手順では、pipelines-tutorial
の例を使用して、ミラーリングされたレジストリーを持つクラスターを使用して、制限された環境でアプリケーションのパイプラインを作成します。pipelines-tutorial
の例が制限された環境で機能することを確認するには、フロントエンドインターフェイス (pipelines-vote-ui
)、バックエンドインターフェイス (pipelines-vote-api
) および cli
のミラーレジストリーからそれぞれのビルダーイメージをミラーリングする必要があります。
手順
フロントエンドインターフェイス (
pipelines-vote-ui
) のミラーレジストリーからビルダーイメージをミラーリングします。必要なイメージタグがインポートされていないことを確認します。
$ oc describe imagestream python -n openshift
出力例
Name: python Namespace: openshift [...] 3.8-ubi8 (latest) tagged from registry.redhat.io/ubi8/python-38:latest prefer registry pullthrough when referencing this tag Build and run Python 3.8 applications on UBI 8. For more information about using this builder image, including OpenShift considerations, see https://github.com/sclorg/s2i-python-container/blob/master/3.8/README.md. Tags: builder, python Supports: python:3.8, python Example Repo: https://github.com/sclorg/django-ex.git [...]
サポートされるイメージタグをプライベートレジストリーに対してミラーリングします。
$ oc image mirror registry.redhat.io/ubi8/python-38:latest <mirror-registry>:<port>/ubi8/python-38
イメージをインポートします。
$ oc tag <mirror-registry>:<port>/ubi8/python-38 python:latest --scheduled -n openshift
イメージを定期的に再インポートする必要があります。
--scheduled
フラグは、イメージの自動再インポートを有効にします。指定されたタグを持つイメージがインポートされていることを確認します。
$ oc describe imagestream python -n openshift
出力例
Name: python Namespace: openshift [...] latest updates automatically from registry <mirror-registry>:<port>/ubi8/python-38 * <mirror-registry>:<port>/ubi8/python-38@sha256:3ee3c2e70251e75bfeac25c0c33356add9cc4abcbc9c51d858f39e4dc29c5f58 [...]
バックエンドインターフェイス (
pipelines-vote-api
) のミラーレジストリーからビルダーイメージをミラーリングします。必要なイメージタグがインポートされていないことを確認します。
$ oc describe imagestream golang -n openshift
出力例
Name: golang Namespace: openshift [...] 1.14.7-ubi8 (latest) tagged from registry.redhat.io/ubi8/go-toolset:1.14.7 prefer registry pullthrough when referencing this tag Build and run Go applications on UBI 8. For more information about using this builder image, including OpenShift considerations, see https://github.com/sclorg/golang-container/blob/master/README.md. Tags: builder, golang, go Supports: golang Example Repo: https://github.com/sclorg/golang-ex.git [...]
サポートされるイメージタグをプライベートレジストリーに対してミラーリングします。
$ oc image mirror registry.redhat.io/ubi8/go-toolset:1.14.7 <mirror-registry>:<port>/ubi8/go-toolset
イメージをインポートします。
$ oc tag <mirror-registry>:<port>/ubi8/go-toolset golang:latest --scheduled -n openshift
イメージを定期的に再インポートする必要があります。
--scheduled
フラグは、イメージの自動再インポートを有効にします。指定されたタグを持つイメージがインポートされていることを確認します。
$ oc describe imagestream golang -n openshift
出力例
Name: golang Namespace: openshift [...] latest updates automatically from registry <mirror-registry>:<port>/ubi8/go-toolset * <mirror-registry>:<port>/ubi8/go-toolset@sha256:59a74d581df3a2bd63ab55f7ac106677694bf612a1fe9e7e3e1487f55c421b37 [...]
cli
のミラーレジストリーからビルダーイメージをミラーリングします。必要なイメージタグがインポートされていないことを確認します。
$ oc describe imagestream cli -n openshift
出力例
Name: cli Namespace: openshift [...] latest updates automatically from registry quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:65c68e8c22487375c4c6ce6f18ed5485915f2bf612e41fef6d41cbfcdb143551 * quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:65c68e8c22487375c4c6ce6f18ed5485915f2bf612e41fef6d41cbfcdb143551 [...]
サポートされるイメージタグをプライベートレジストリーに対してミラーリングします。
$ oc image mirror quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:65c68e8c22487375c4c6ce6f18ed5485915f2bf612e41fef6d41cbfcdb143551 <mirror-registry>:<port>/openshift-release-dev/ocp-v4.0-art-dev:latest
イメージをインポートします。
$ oc tag <mirror-registry>:<port>/openshift-release-dev/ocp-v4.0-art-dev cli:latest --scheduled -n openshift
イメージを定期的に再インポートする必要があります。
--scheduled
フラグは、イメージの自動再インポートを有効にします。指定されたタグを持つイメージがインポートされていることを確認します。
$ oc describe imagestream cli -n openshift
出力例
Name: cli Namespace: openshift [...] latest updates automatically from registry <mirror-registry>:<port>/openshift-release-dev/ocp-v4.0-art-dev * <mirror-registry>:<port>/openshift-release-dev/ocp-v4.0-art-dev@sha256:65c68e8c22487375c4c6ce6f18ed5485915f2bf612e41fef6d41cbfcdb143551 [...]
4.5.6. パイプラインの実行
PipelineRun
リソースはパイプラインを開始し、これを特定の呼び出しに使用する必要のある Git およびイメージリソースに関連付けます。これは、パイプラインの各タスクについて TaskRun
を自動的に作成し、開始します。
手順
バックエンドアプリケーションのパイプラインを起動します。
$ tkn pipeline start build-and-deploy \ -w name=shared-workspace,volumeClaimTemplateFile=https://raw.githubusercontent.com/openshift/pipelines-tutorial/pipelines-1.5/01_pipeline/03_persistent_volume_claim.yaml \ -p deployment-name=pipelines-vote-api \ -p git-url=https://github.com/openshift/pipelines-vote-api.git \ -p IMAGE=image-registry.openshift-image-registry.svc:5000/pipelines-tutorial/pipelines-vote-api \ --use-param-defaults
直前のコマンドは、パイプライン実行の永続ボリューム要求 (PVC) を作成するボリューム要求テンプレートを使用します。
パイプライン実行の進捗を追跡するには、以下のコマンドを入力します。
$ tkn pipelinerun logs <pipelinerun_id> -f
上記のコマンドの <pipelinerun_id> は、直前のコマンドの出力で返された
PipelineRun
の ID です。フロントエンドアプリケーションのパイプラインを起動します。
$ tkn pipeline start build-and-deploy \ -w name=shared-workspace,volumeClaimTemplateFile=https://raw.githubusercontent.com/openshift/pipelines-tutorial/pipelines-1.5/01_pipeline/03_persistent_volume_claim.yaml \ -p deployment-name=pipelines-vote-ui \ -p git-url=https://github.com/openshift/pipelines-vote-ui.git \ -p IMAGE=image-registry.openshift-image-registry.svc:5000/pipelines-tutorial/pipelines-vote-ui \ --use-param-defaults
パイプライン実行の進捗を追跡するには、以下のコマンドを入力します。
$ tkn pipelinerun logs <pipelinerun_id> -f
上記のコマンドの <pipelinerun_id> は、直前のコマンドの出力で返された
PipelineRun
の ID です。数分後に、
tkn pipelinerun list
コマンドを使用して、すべてのパイプライン実行を一覧表示してパイプラインが正常に実行されたことを確認します。$ tkn pipelinerun list
出力には、パイプライン実行が一覧表示されます。
NAME STARTED DURATION STATUS build-and-deploy-run-xy7rw 1 hour ago 2 minutes Succeeded build-and-deploy-run-z2rz8 1 hour ago 19 minutes Succeeded
アプリケーションルートを取得します。
$ oc get route pipelines-vote-ui --template='http://{{.spec.host}}'
上記のコマンドの出力に留意してください。このルートを使用してアプリケーションにアクセスできます。
直前のパイプラインのパイプラインリソースおよびサービスアカウントを使用して最後のパイプライン実行を再実行するには、以下を実行します。
$ tkn pipeline start build-and-deploy --last
4.5.7. トリガーのパイプラインへの追加
トリガーは、パイプラインがプッシュイベントやプル要求などの外部の GitHub イベントに応答できるようにします。アプリケーションのパイプラインをアセンブルし、起動した後に、TriggerBinding
、TriggerTemplate
、Trigger
、および EventListener
リソースを追加して GitHub イベントを取得します。
手順
以下のサンプル
TriggerBinding
YAML ファイルの内容をコピーし、これを保存します。apiVersion: triggers.tekton.dev/v1alpha1 kind: TriggerBinding metadata: name: vote-app spec: params: - name: git-repo-url value: $(body.repository.url) - name: git-repo-name value: $(body.repository.name) - name: git-revision value: $(body.head_commit.id)
TriggerBinding
リソースを作成します。$ oc create -f <triggerbinding-yaml-file-name.yaml>
または、
TriggerBinding
リソースをpipelines-tutorial
Git リポジトリーから直接作成できます。$ oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/pipelines-1.5/03_triggers/01_binding.yaml
以下のサンプル
TriggerTemplate
YAML ファイルの内容をコピーし、これを保存します。apiVersion: triggers.tekton.dev/v1alpha1 kind: TriggerTemplate metadata: name: vote-app spec: params: - name: git-repo-url description: The git repository url - name: git-revision description: The git revision default: pipelines-1.5 - name: git-repo-name description: The name of the deployment to be created / patched resourcetemplates: - apiVersion: tekton.dev/v1beta1 kind: PipelineRun metadata: generateName: build-deploy-$(tt.params.git-repo-name)- spec: serviceAccountName: pipeline pipelineRef: name: build-and-deploy params: - name: deployment-name value: $(tt.params.git-repo-name) - name: git-url value: $(tt.params.git-repo-url) - name: git-revision value: $(tt.params.git-revision) - name: IMAGE value: image-registry.openshift-image-registry.svc:5000/pipelines-tutorial/$(tt.params.git-repo-name) workspaces: - name: shared-workspace volumeClaimTemplate: spec: accessModes: - ReadWriteOnce resources: requests: storage: 500Mi
テンプレートは、ワークスペースのストレージボリュームを定義するための永続ボリューム要求 (PVC) を作成するためのボリューム要求テンプレートを指定します。そのため、データストレージを提供するために永続ボリューム要求 (PVC) を作成する必要はありません。
TriggerTemplate
リソースを作成します。$ oc create -f <triggertemplate-yaml-file-name.yaml>
または、
TriggerTemplate
リソースをpipelines-tutorial
Git リポジトリーから直接作成できます。$ oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/pipelines-1.5/03_triggers/02_template.yaml
以下のサンプルの
Trigger
YAML ファイルの内容をコピーし、保存します。apiVersion: triggers.tekton.dev/v1alpha1 kind: Trigger metadata: name: vote-trigger spec: serviceAccountName: pipeline bindings: - ref: vote-app template: ref: vote-app
Trigger
リソースを作成します。$ oc create -f <trigger-yaml-file-name.yaml>
または、
Trigger
リソースをpipelines-tutorial
Git リポジトリーから直接作成できます。$ oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/pipelines-1.5/03_triggers/03_trigger.yaml
以下のサンプル
EventListener
YAML ファイルの内容をコピーし、これを保存します。apiVersion: triggers.tekton.dev/v1alpha1 kind: EventListener metadata: name: vote-app spec: serviceAccountName: pipeline triggers: - triggerRef: vote-trigger
または、トリガーカスタムリソースを定義していない場合は、トリガーの名前を参照する代わりに、バインディングおよびテンプレート仕様を
EventListener
YAML ファイルに追加します。apiVersion: triggers.tekton.dev/v1alpha1 kind: EventListener metadata: name: vote-app spec: serviceAccountName: pipeline triggers: - bindings: - ref: vote-app template: ref: vote-app
以下のコマンドを実行して
EventListener
リソースを作成します。セキュアな HTTPS 接続を使用して
EventListener
リソースを作成するには、以下を実行します。ラベルを追加して、
Eventlistener
リソースへのセキュアな HTTPS 接続を有効にします。$ oc label namespace <ns-name> operator.tekton.dev/enable-annotation=enabled
EventListener
リソースを作成します。$ oc create -f <eventlistener-yaml-file-name.yaml>
または、
EvenListener
リソースをpipelines-tutorial
Git リポジトリーから直接作成できます。$ oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/pipelines-1.5/03_triggers/04_event_listener.yaml
re-encrypt TLS 終端でルートを作成します。
$ oc create route reencrypt --service=<svc-name> --cert=tls.crt --key=tls.key --ca-cert=ca.crt --hostname=<hostname>
または、re-encrypt TLS 終端 YAML ファイルを作成して、セキュアなルートを作成できます。
セキュアなルートの re-encrypt TLS 終端 YAML の例
apiVersion: route.openshift.io/v1 kind: Route metadata: name: route-passthrough-secured 1 spec: host: <hostname> to: kind: Service name: frontend 2 tls: termination: reencrypt 3 key: [as in edge termination] certificate: [as in edge termination] caCertificate: [as in edge termination] destinationCACertificate: |- 4 -----BEGIN CERTIFICATE----- [...] -----END CERTIFICATE-----
他のオプションについては、
oc create route reencrypt --help
を参照してください。
非セキュアな HTTP 接続を使用して
EventListener
リソースを作成するには、以下を実行します。-
EventListener
リソースを作成します。 EventListener
サービスを OpenShift Container Platform ルートとして公開し、これをアクセス可能にします。$ oc expose svc el-vote-app
-
4.5.8. Webhook の作成
Webhook は、設定されたイベントがリポジトリーで発生するたびにイベントリスナーよって受信される HTTP POST メッセージです。その後、イベントペイロードはトリガーバインディングにマップされ、トリガーテンプレートによって処理されます。トリガーテンプレートは最終的に 1 つ以上のパイプライン実行を開始し、Kubernetes リソースの作成およびデプロイメントを実行します。
このセクションでは、フォークされた Git リポジトリー pipelines-vote-ui
および pipelines-vote-api
で Webhook URL を設定します。この URL は、一般に公開されている EventListener
サービスルートを参照します。
Webhook を追加するには、リポジトリーへの管理者権限が必要です。リポジトリーへの管理者アクセスがない場合は、Webhook を追加できるようにシステム管理者に問い合わせてください。
手順
Webhook URL を取得します。
セキュアな HTTPS 接続の場合:
$ echo "URL: $(oc get route el-vote-app --template='https://{{.spec.host}}')"
HTTP (非セキュアな) 接続の場合:
$ echo "URL: $(oc get route el-vote-app --template='http://{{.spec.host}}')"
出力で取得した URL をメモします。
フロントエンドリポジトリーで Webhook を手動で設定します。
-
フロントエンド Git リポジトリー
pipelines-vote-ui
をブラウザーで開きます。 -
Settings
Webhooks Add Webhook をクリックします。 Webhooks/Add Webhook ページで以下を実行します。
- 手順 1 の Webhook URL を Payload URL フィールドに入力します。
- Content type について application/json を選択します。
- シークレットを Secret フィールドに指定します。
- Just the push event が選択されていることを確認します。
- Active を選択します。
- Add Webhook をクリックします。
-
フロントエンド Git リポジトリー
-
バックエンドリポジトリー
pipelines-vote-api
について手順 2 を繰り返します。
4.5.9. パイプライン実行のトリガー
push
イベントが Git リポジトリーで実行されるたびに、設定された Webhook はイベントペイロードを公開される EventListener
サービスルートに送信します。アプリケーションの EventListener
サービスはペイロードを処理し、これを関連する TriggerBinding
および TriggerTemplate
リソースのペアに渡します。TriggerBinding
リソースはパラメーターを抽出し、TriggerTemplate
リソースはこれらのパラメーターを使用して、リソースの作成方法を指定します。これにより、アプリケーションが再ビルドされ、再デプロイされる可能性があります。
このセクションでは、空のコミットをフロントエンドの pipelines-vote-ui
リポジトリーにプッシュし、パイプライン実行をトリガーします。
手順
ターミナルから、フォークした Git リポジトリー
pipelines-vote-ui
のクローンを作成します。$ git clone git@github.com:<your GitHub ID>/pipelines-vote-ui.git -b pipelines-1.5
空のコミットをプッシュします。
$ git commit -m "empty-commit" --allow-empty && git push origin pipelines-1.5
パイプライン実行がトリガーされたかどうかを確認します。
$ tkn pipelinerun list
新規のパイプライン実行が開始されたことに注意してください。
4.5.10. 関連情報
- Developer パースペクティブのパイプラインについての詳細は、Developer パースペクティブでのパイプラインの使用 についてのセクションを参照してください。
- SCC (Security Context Constraints) の詳細は、SSC (Security Context Constraints) の管理 を参照してください。
- 再利用可能なタスクの追加の例については、OpenShift Catalog リポジトリーを参照してください。さらに、Tekton プロジェクトで Tekton Catalog を参照することもできます。
- re-encrypt TLS 終端についての詳細は、 再暗号化終端 について参照してください。
- セキュリティー保護されたルートについての詳細は、セキュリティー保護されたルート についてのセクションを参照してください。