1. 作業ディレクトリーが作成され、すべての入力内容がその作業ディレクトリーに配置されます。たとえば、入力 Git リポジトリーのクローンはこの作業ディレクトリーに作成され、入力イメージから指定されたファイルはターゲットのパスを使用してこの作業ディレクトリーにコピーされます。
2. ビルドプロセスによりディレクトリーが contextDir に変更されます (定義されている場合)。
3. インライン Dockerfile がある場合は、現在のディレクトリーに書き込まれます。
4. 現在の作業ディレクトリーにある内容が Dockerfile、カスタムビルダーのロジック、または assemble スクリプトが参照するビルドプロセスに提供されます。つまり、ビルドでは contextDir 内にない入力コンテンツは無視されます。

1. ミラーの URL および接続の設定が含まれる settings.xml ファイル。
2. ~/.ssh/id_rsa などの、設定ファイルで参照されるプライベートキー。

手順

1. ローカルの .docker/config.json ファイルからシークレットを作成します。

   $ oc create secret generic dockerhub \
       --from-file=.dockerconfigjson=<path/to/.docker/config.json> \
       --type=kubernetes.io/dockerconfigjson

   このコマンドにより、dockerhub という名前のシークレットの JSON 仕様が生成され、オブジェクトが作成されます。

2. pushSecret フィールドを BuildConfig の output セクションに追加し、作成した secret の名前 (上記の例では、dockerhub) に設定します。

   spec:
     output:
       to:
         kind: "DockerImage"
         name: "private.registry.com/org/private-image:latest"
       pushSecret:
         name: "dockerhub"

   oc set build-secret コマンドを使用して、ビルド設定にプッシュするシークレットを設定します。

   $ oc set build-secret --push bc/sample-build dockerhub

   pushSecret フィールドを指定する代わりに、プッシュシークレットをビルドで使用されるサービスアカウントにリンクできます。デフォルトで、ビルドは builder サービスアカウントを使用します。シークレットにビルドのアウトプットイメージをホストするリポジトリーに一致する認証情報が含まれる場合、プッシュシークレットはビルドに自動的に追加されます。

   $ oc secrets link builder dockerhub

3. ビルドストラテジー定義に含まれる pullSecret を指定して、プライベートコンテナーイメージレジストリーからビルダーコンテナーイメージをプルします。

   strategy:
     sourceStrategy:
       from:
         kind: "DockerImage"
         name: "docker.io/user/private_repository"
       pullSecret:
         name: "dockerhub"

   oc set build-secret コマンドを使用して、ビルド設定でプルシークレットを設定します。

   $ oc set build-secret --pull bc/sample-build dockerhub

   注記

   以下の例では、ソールビルドに pullSecret を使用しますが、Docker とカスタムビルドにも該当します。

   pullSecret フィールドを指定する代わりに、プルシークレットをビルドで使用されるサービスアカウントにリンクできます。デフォルトで、ビルドは builder サービスアカウントを使用します。シークレットにビルドのインプットイメージをホストするリポジトリーに一致する認証情報が含まれる場合、プルシークレットはビルドに自動的に追加されます。pullSecret フィールドを指定する代わりに、プルシークレットをビルドで使用されるサービスアカウントにリンクするには、以下を実行します。

   $ oc secrets link builder dockerhub

   注記

   この機能を使用するには、from イメージを BuildConfig 仕様に指定する必要があります。oc new-build または oc new-app で生成される Docker ストラテジービルドは、場合によってこれを実行しない場合があります。

1. 新規の OpenShift Container Platform プロジェクトを作成します。
2. プライベートのソースコードリポジトリーにアクセスするための認証情報が含まれるシークレットを作成します。
3. ビルド設定を作成します。
4. ビルド設定エディターページまたは Web コンソールの create app from builder image ページで、Source Secret を設定します。
5. Save をクリックします。

手順

1. 空のディレクトリーからはじめ、以下の内容を含む Dockerfile という名前のファイルを作成します。

   FROM registry.redhat.io/rhel8/buildah
   # In this example, `/tmp/build` contains the inputs that build when this
   # custom builder image is run. Normally the custom builder image fetches
   # this content from some location at build time, by using git clone as an example.
   ADD dockerfile.sample /tmp/input/Dockerfile
   ADD build.sh /usr/bin
   RUN chmod a+x /usr/bin/build.sh
   # /usr/bin/build.sh contains the actual custom build logic that will be run when
   # this custom builder image is run.
   ENTRYPOINT ["/usr/bin/build.sh"]

2. 同じディレクトリーに、dockerfile.sample という名前のファイルを作成します。このファイルはカスタムビルドイメージに組み込まれ、コンテンツビルドによって生成されるイメージを定義します。

   FROM registry.access.redhat.com/ubi8/ubi
   RUN touch /tmp/build

3. 同じディレクトリーに、build.sh という名前のファイルを作成します。このファイルには、カスタムビルドの実行時に実行されるロジックが含まれます。

   #!/bin/sh
   # Note that in this case the build inputs are part of the custom builder image, but normally this
   # is retrieved from an external source.
   cd /tmp/input
   # OUTPUT_REGISTRY and OUTPUT_IMAGE are env variables provided by the custom
   # build framework
   TAG="${OUTPUT_REGISTRY}/${OUTPUT_IMAGE}"
   
   
   # performs the build of the new image defined by dockerfile.sample
   buildah --storage-driver vfs bud --isolation chroot -t ${TAG} .
   
   
   # buildah requires a slight modification to the push secret provided by the service
   # account to use it for pushing the image
   cp /var/run/secrets/openshift.io/push/.dockercfg /tmp
   (echo "{ \"auths\": " ; cat /var/run/secrets/openshift.io/push/.dockercfg ; echo "}") > /tmp/.dockercfg
   
   
   # push the new image to the target for the build
   buildah --storage-driver vfs push --tls-verify=false --authfile /tmp/.dockercfg ${TAG}

手順

1. カスタムビルダーイメージをビルドする BuildConfig オブジェクトを定義します。

   $ oc new-build --binary --strategy=docker --name custom-builder-image

2. カスタムビルドイメージを作成したディレクトリーから、ビルドを実行します。

   $ oc start-build custom-builder-image --from-dir . -F

   ビルドの完了後に、新規のカスタムビルダーイメージが custom-builder-image:latest という名前のイメージストリームタグのプロジェクトで利用可能になります。

手順

1. buildconfig.yaml という名前のファイルを作成します。このファイルは、プロジェクトに作成され、実行される BuildConfig オブジェクトを定義します。

   kind: BuildConfig
   apiVersion: build.openshift.io/v1
   metadata:
     name: sample-custom-build
     labels:
       name: sample-custom-build
     annotations:
       template.alpha.openshift.io/wait-for-ready: 'true'
   spec:
     strategy:
       type: Custom
       customStrategy:
         forcePull: true
         from:
           kind: ImageStreamTag
           name: custom-builder-image:latest
           namespace: <yourproject> 1
     output:
       to:
         kind: ImageStreamTag
         name: sample-custom:latest

   1

   プロジェクト名を指定します。

2. BuildConfig を作成します。

   $ oc create -f buildconfig.yaml

3. imagestream.yaml という名前のファイルを作成します。このファイルはビルドがイメージをプッシュするイメージストリームを定義します。

   kind: ImageStream
   apiVersion: image.openshift.io/v1
   metadata:
     name: sample-custom
   spec: {}

4. imagestream を作成します。

   $ oc create -f imagestream.yaml

5. カスタムビルドを実行します。

   $ oc start-build sample-custom-build -F

   ビルドが実行されると、以前にビルドされたカスタムビルダーイメージを実行する Pod が起動します。Pod はカスタムビルダーイメージのエントリーポイントとして定義される build.sh ロジックを実行します。build.sh ロジックは Buildah を起動し、カスタムビルダーイメージに埋め込まれた dockerfile.sample をビルドしてから、Buildah を使用して新規イメージを sample-custom image stream にプッシュします。

手順

1. successfulBuildsHistoryLimit または failedBuildsHistoryLimit の正の値を BuildConfig に指定して、保持される以前のビルドの数を制限します。 以下は例になります。

   apiVersion: "v1"
   kind: "BuildConfig"
   metadata:
     name: "sample-build"
   spec:
     successfulBuildsHistoryLimit: 2 1
     failedBuildsHistoryLimit: 2 2

   1

   successfulBuildsHistoryLimit は、completed のステータスのビルドを最大 2 つまで保持します。

   2

   failedBuildsHistoryLimit はステータスが failed、cancelled または error のビルドを最大 2 つまで保持します。

2. 以下の動作のいずれかを実行して、ビルドのプルーニングをトリガーします。

   • ビルド設定が更新された場合
   • ビルドがそのライフサイクルを完了するのを待機します。

手順

1. エンタイトルメントを含むシークレットを作成し、パブリックキーとプライベートキーが含まれる別々のファイルがあることを確認します。

   $  oc create secret generic etc-pki-entitlement --from-file /path/to/entitlement/{ID}.pem \
   > --from-file /path/to/entitlement/{ID}-key.pem ...

2. シークレットをビルド入力としてビルド設定に追加します。

   source:
     secrets:
     - secret:
         name: etc-pki-entitlement
       destinationDir: etc-pki-entitlement

手順

1. rbac.authorization.kubernetes.io/autoupdate アノテーションを適用します。

   $ oc edit clusterrolebinding system:build-strategy-docker-binding

   出力例

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
     annotations:
       rbac.authorization.kubernetes.io/autoupdate: "false" 1
     creationTimestamp: 2018-08-10T01:24:14Z
     name: system:build-strategy-docker-binding
     resourceVersion: "225"
     selfLink: /apis/rbac.authorization.k8s.io/v1/clusterrolebindings/system%3Abuild-strategy-docker-binding
     uid: 17b1f3d4-9c3c-11e8-be62-0800277d20bf
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: ClusterRole
     name: system:build-strategy-docker
   subjects:
   - apiGroup: rbac.authorization.k8s.io
     kind: Group
     name: system:authenticated

   1

   rbac.authorization.kubernetes.io/autoupdate アノテーションの値を "false" に変更します。

2. ロールを削除します。

   $ oc adm policy remove-cluster-role-from-group system:build-strategy-docker system:authenticated

3. ビルドストラテジーのサブリソースもこれらのロールから削除されることを確認します。

   $ oc edit clusterrole admin

   $ oc edit clusterrole edit

4. ロールごとに、無効にするストラテジーのリソースに対応するサブリソースを指定します。

   1. admin の docker ビルドストラテジーの無効化

      kind: ClusterRole
      metadata:
        name: admin
      ...
      - apiGroups:
        - ""
        - build.openshift.io
        resources:
        - buildconfigs
        - buildconfigs/webhooks
        - builds/custom 1
        - builds/source
        verbs:
        - create
        - delete
        - deletecollection
        - get
        - list
        - patch
        - update
        - watch
      ...

      1

      builds/custom と builds/source を追加しして、admin ロールが割り当てられたユーザーに対して docker ビルドをグローバルに無効にします。

手順

1. 自己署名証明書を使用するレジストリーの信頼される証明書が含まれる ConfigMap を openshift-config namespace に作成します。それぞれの CA ファイルについて、ConfigMap のキーが hostname[..port] 形式のレジストリーのホスト名であることを確認します。

   $ oc create configmap registry-cas -n openshift-config \
   --from-file=myregistry.corp.com..5000=/etc/docker/certs.d/myregistry.corp.com:5000/ca.crt \
   --from-file=otherregistry.com=/etc/docker/certs.d/otherregistry.com/ca.crt

2. クラスターイメージの設定を更新します。

   $ oc patch image.config.openshift.io/cluster --patch '{"spec":{"additionalTrustedCA":{"name":"registry-cas"}}}' --type=merge

手順

1. Web コンソールの Administrator パースペクティブで、Operators → OperatorHub に移動します。
2. Filter by keyword ボックスを使用して、カタログで Red Hat OpenShift Pipelines Operator を検索します。Red Hat OpenShift Pipelines Operator タイルをクリックします。
3. Red Hat OpenShift Pipelines Operator ページで Operator についての簡単な説明を参照してください。Install をクリックします。

4. Install Operator ページで以下を行います。

   1. Installation Mode について All namespaces on the cluster (default) を選択します。このモードは、デフォルトの openshift-operators namespace で Operator をインストールし、Operator がクラスターのすべての namespace を監視し、これらの namespace に対して利用可能になるようにします。
   2. Approval Strategy について Automatic を選択します。これにより、Operator への今後のアップグレードは Operator Lifecycle Manager (OLM) によって自動的に処理されます。Manual 承認ストラテジーを選択すると、OLM は更新要求を作成します。クラスター管理者は、Operator を新規バージョンに更新できるように OLM 更新要求を手動で承認する必要があります。

   3. Update Channel を選択します。

      • Stable チャネルは、Red Hat OpenShift Pipelines Operator の最新の安定したサポートされているリリースのインストールを可能にします。
      • preview チャネルは、Red Hat OpenShift Pipelines Operator の最新プレビューバージョンのインストールを有効にします。これには、Stable チャネルでは利用できず、サポートされていない機能が含まれる場合があります。

5. Install をクリックします。Operator が Installed Operators ページに一覧表示されます。

   注記

   Operator は openshift-operators namespace に自動的にインストールされます。

6. Status が Succeeded Up to date に設定され、Red Hat OpenShift Pipelines Operator のインストールが正常に行われたことを確認します。

手順

1. Subscription オブジェクトの YAML ファイルを作成し、namespace を Red Hat OpenShift Pipelines Operator にサブスクライブします (例: sub.yaml)。

   Subscription の例

   apiVersion: operators.coreos.com/v1alpha1
   kind: Subscription
   metadata:
     name: openshift-pipelines-operator
     namespace: openshift-operators
   spec:
     channel:  <channel name> 1
     name: openshift-pipelines-operator-rh 2
     source: redhat-operators 3
     sourceNamespace: openshift-marketplace 4

   1

   Operator のサブスクライブ元のチャネル名を指定します。

   2

   サブスクライブする Operator の名前。

   3

   Operator を提供する CatalogSource の名前。

   4

   CatalogSource の namespace。デフォルトの OperatorHub CatalogSource には openshift-marketplace を使用します。

2. Subscription オブジェクトを作成します。

   $ oc apply -f sub.yaml

   Red Hat OpenShift Pipelines Operator がデフォルトのターゲット namespace openshift-operators にインストールされるようになりました。

手順

1. Web コンソールの Administrator パースペクティブで、Administration → Custom Resource Definition に移動します。
2. Filter by name ボックスに config.operator.tekton.dev を入力し、 Red Hat OpenShift Pipelines Operator CR を検索します。
3. CRD Config をクリックし、 Custom Resource Definition Details ページを表示します。

4. Actions ドロップダウンメニューをクリックし、Delete Custom Resource Definition を選択します。

   注記

   CR を削除すると Red Hat OpenShift Pipelines コンポーネントが削除され、クラスター上のすべての Task および Pipeline が失われます。

5. Delete をクリックし、CR の削除を確認します。

手順

1. Operators → OperatorHub ページから、Filter by keyword ボックスを使用して Red Hat OpenShift Pipelines Operator を検索します。
2. OpenShift Pipelines Operator タイルをクリックします。Operator タイルはこれがインストールされていることを示します。
3. OpenShift Pipelines Operator 記述子ページで、Uninstall をクリックします。

手順

1. OpenShift Container Platform クラスターにログインします。

   $ oc login -u <login> -p <password> https://openshift.example.com:6443

2. サンプルアプリケーションのプロジェクトを作成します。このサンプルワークフローでは、pipelines-tutorial プロジェクトを作成します。

   $ oc new-project pipelines-tutorial

   注記

   別の名前でプロジェクトを作成する場合は、サンプルで使用されているリソース URL をプロジェクト名で更新してください。

3. pipeline サービスアカウントを表示します。

   Red Hat OpenShift Pipelines Operator は、イメージのビルドおよびプッシュを実行するのに十分なパーミッションを持つ pipeline という名前のサービスアカウントを追加し、設定します。このサービスアカウントは PipelineRun オブジェクトによって使用されます。

   $ oc get serviceaccount pipeline

手順

1. pipelines-tutorial リポジトリーから apply-manifests および update-deployment タスクリソースをインストールします。これには、パイプラインの再利用可能なタスクの一覧が含まれます。

   $ oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/pipelines-1.4/01_pipeline/01_apply_manifest_task.yaml
   $ oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/pipelines-1.4/01_pipeline/02_update_deployment_task.yaml

2. tkn task list コマンドを使用して、作成したタスクを一覧表示します。

   $ tkn task list

   出力では、apply-manifests および update-deployment タスクリソースが作成されていることを検証します。

   NAME                DESCRIPTION   AGE
   apply-manifests                   1 minute ago
   update-deployment                 48 seconds ago

3. 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

手順

1. 以下のサンプルのパイプライン 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.4"
     - 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 として追加されます。

2. パイプラインを作成します。

   $ oc create -f <pipeline-yaml-file-name.yaml>

   または、Git リポジトリーから YAML ファイルを直接実行することもできます。

   $ oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/pipelines-1.4/01_pipeline/04_pipeline.yaml

3. tkn pipeline list コマンドを使用して、パイプラインがアプリケーションに追加されていることを確認します。

   $ tkn pipeline list

   この出力では、build-and-deploy パイプラインが作成されていることを検証します。

   NAME               AGE            LAST RUN   STARTED   DURATION   STATUS
   build-and-deploy   1 minute ago   ---        ---       ---        ---

手順

1. フロントエンドインターフェイス (pipelines-vote-ui) のミラーレジストリーからビルダーイメージをミラーリングします。

   1. 必要なイメージタグがインポートされていないことを確認します。

      $ 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
      
      [...]

   2. サポートされるイメージタグをプライベートレジストリーに対してミラーリングします。

      $ oc image mirror registry.redhat.io/ubi8/python-38:latest <mirror-registry>:<port>/ubi8/python-38

   3. イメージをインポートします。

      $ oc tag <mirror-registry>:<port>/ubi8/python-38 python:latest --scheduled -n openshift

      イメージを定期的に再インポートする必要があります。--scheduled フラグは、イメージの自動再インポートを有効にします。

   4. 指定されたタグを持つイメージがインポートされていることを確認します。

      $ 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
      
      [...]

2. バックエンドインターフェイス (pipelines-vote-api) のミラーレジストリーからビルダーイメージをミラーリングします。

   1. 必要なイメージタグがインポートされていないことを確認します。

      $ 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
      
      [...]

   2. サポートされるイメージタグをプライベートレジストリーに対してミラーリングします。

      $ oc image mirror registry.redhat.io/ubi8/go-toolset:1.14.7 <mirror-registry>:<port>/ubi8/go-toolset

   3. イメージをインポートします。

      $ oc tag <mirror-registry>:<port>/ubi8/go-toolset golang:latest --scheduled -n openshift

      イメージを定期的に再インポートする必要があります。--scheduled フラグは、イメージの自動再インポートを有効にします。

   4. 指定されたタグを持つイメージがインポートされていることを確認します。

      $ 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
      
      [...]

3. cli のミラーレジストリーからビルダーイメージをミラーリングします。

   1. 必要なイメージタグがインポートされていないことを確認します。

      $ 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
      
      [...]

   2. サポートされるイメージタグをプライベートレジストリーに対してミラーリングします。

      $ 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

   3. イメージをインポートします。

      $ oc tag <mirror-registry>:<port>/openshift-release-dev/ocp-v4.0-art-dev cli:latest --scheduled -n openshift

      イメージを定期的に再インポートする必要があります。--scheduled フラグは、イメージの自動再インポートを有効にします。

   4. 指定されたタグを持つイメージがインポートされていることを確認します。

      $ 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
      
      [...]

手順

1. バックエンドアプリケーションのパイプラインを起動します。

   $ tkn pipeline start build-and-deploy \
       -w name=shared-workspace,volumeClaimTemplateFile=https://raw.githubusercontent.com/openshift/pipelines-tutorial/pipelines-1.4/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

   直前のコマンドは、パイプライン実行の永続ボリューム要求 (PVC) を作成するボリューム要求テンプレートを使用します。

2. パイプライン実行の進捗を追跡するには、以下のコマンドを入力します。

   $ tkn pipelinerun logs <pipelinerun_id> -f

   上記のコマンドの <pipelinerun_id> は、直前のコマンドの出力で返された PipelineRun の ID です。

3. フロントエンドアプリケーションのパイプラインを起動します。

   $ tkn pipeline start build-and-deploy \
       -w name=shared-workspace,volumeClaimTemplateFile=https://raw.githubusercontent.com/openshift/pipelines-tutorial/pipelines-1.4/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

4. パイプライン実行の進捗を追跡するには、以下のコマンドを入力します。

   $ tkn pipelinerun logs <pipelinerun_id> -f

   上記のコマンドの <pipelinerun_id> は、直前のコマンドの出力で返された PipelineRun の ID です。

5. 数分後に、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

6. アプリケーションルートを取得します。

   $ oc get route pipelines-vote-ui --template='http://{{.spec.host}}'

   上記のコマンドの出力に留意してください。このルートを使用してアプリケーションにアクセスできます。

7. 直前のパイプラインのパイプラインリソースおよびサービスアカウントを使用して最後のパイプライン実行を再実行するには、以下を実行します。

   $ tkn pipeline start build-and-deploy --last

手順

1. 以下のサンプル 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)

2. 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.4/03_triggers/01_binding.yaml

3. 以下のサンプル 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.4
     - 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) を作成する必要はありません。

4. 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.4/03_triggers/02_template.yaml

5. 以下のサンプルの Trigger YAML ファイルの内容をコピーし、保存します。

   apiVersion: triggers.tekton.dev/v1alpha1
   kind: Trigger
   metadata:
     name: vote-trigger
   spec:
     serviceAccountName: pipeline
     bindings:
       - ref: vote-app
     template:
       ref: vote-app

6. 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.4/03_triggers/03_trigger.yaml

7. 以下のサンプル 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

8. 以下のコマンドを実行して EventListener リソースを作成します。

   • セキュアな HTTPS 接続を使用して EventListener リソースを作成するには、以下を実行します。

     1. ラベルを追加して、Eventlistener リソースへのセキュアな HTTPS 接続を有効にします。

        $ oc label namespace <ns-name> operator.tekton.dev/enable-annotation=enabled

     2. 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.4/03_triggers/04_event_listener.yaml

     3. 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-----

        1 2

        オブジェクトの名前で、63 文字に制限されます。

        3

        termination フィールドは reencrypt に設定されます。これは、必要な唯一の tls フィールドです。

        4

        再暗号化に必要です。destinationCACertificate は CA 証明書を指定してエンドポイントの証明書を検証し、ルーターから宛先 Pod への接続のセキュリティーを保護します。サービスがサービス署名証明書を使用する場合または、管理者がデフォルトの CA 証明書をルーターに指定し、サービスにその CA により署名された証明書がある場合には、このフィールドは省略可能です。

        他のオプションについては、oc create route reencrypt --help を参照してください。

   • 非セキュアな HTTP 接続を使用して EventListener リソースを作成するには、以下を実行します。

     1. EventListener リソースを作成します。

     2. EventListener サービスを OpenShift Container Platform ルートとして公開し、これをアクセス可能にします。

        $ oc expose svc el-vote-app

手順

1. 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 をメモします。

2. フロントエンドリポジトリーで Webhook を手動で設定します。

   1. フロントエンド Git リポジトリー pipelines-vote-ui をブラウザーで開きます。
   2. Settings → Webhooks → Add Webhook をクリックします。

   3. Webhooks/Add Webhook ページで以下を実行します。

      1. 手順 1 の Webhook URL を Payload URL フィールドに入力します。
      2. Content type について application/json を選択します。
      3. シークレットを Secret フィールドに指定します。
      4. Just the push event が選択されていることを確認します。
      5. Active を選択します。
      6. Add Webhook をクリックします。
3. バックエンドリポジトリー pipelines-vote-api について手順 2 を繰り返します。

手順

1. ターミナルから、フォークした Git リポジトリー pipelines-vote-ui のクローンを作成します。

   $ git clone git@github.com:<your GitHub ID>/pipelines-vote-ui.git -b pipelines-1.4

2. 空のコミットをプッシュします。

   $ git commit -m "empty-commit" --allow-empty && git push origin pipelines-1.4

3. パイプライン実行がトリガーされたかどうかを確認します。

   $ tkn pipelinerun list

   新規のパイプライン実行が開始されたことに注意してください。

手順

1. Developer パースペクティブの +Add ビューで、Pipeline タイルをクリックし、Pipeline Builder ページを表示します。

2. Pipeline ビルダー ビューまたは YAML ビュー のいずれかを使用して、パイプラインを設定します。

   注記

   Pipeline ビルダー ビューは、限られた数のフィールドをサポートしますが、YAML ビュー は利用可能なすべてのフィールドをサポートします。オプションで、Operator によってインストールされた、再利用可能なスニペットおよびサンプルを使用して、詳細な Pipeline を作成することもできます。

   図3.1 YAML ビュー

   

   Pipeline Builder を使用してパイプラインを設定するには、以下を実行します。

   1. パイプラインの一意の名前を入力します。

   2. Select Task 一覧からタスクを選択し、タスクをパイプラインに追加します。この例では、s2i-nodejs タスクを使用します。

      • 連続するタスクをパイプラインに追加するには、タスクの右側または左側にあるプラスアイコンをクリックし、Select Task 一覧から、パイプラインに追加する必要のあるタスクを選択します。この例では、s2i-nodejs タスクの右側にあるプラスアイコンを使用して、openshift-client タスクを追加します。

      • 並列のタスクを既存のタスクに追加するには、タスクの横に表示されるプラスアイコンをクリックし、Select Task 一覧からパイプラインに追加する必要のある並列タスクを選択します。

        図3.2 Pipeline Builder

        

   3. Add Resources をクリックし、パイプライン実行が使用するリソースの名前およびタイプを指定します。これらのリソースは、パイプラインのタスクによって入力および出力として使用されます。この例では、以下のようになります。

      1. 入力リソースを追加します。Name フィールドに Source を入力してから、Resource Type ドロップダウンリストから Git を選択します。
      2. 出力リソースを追加します。Name フィールドに Img を入力してから、Resource Type ドロップダウンリストから イメージ を選択します。
   4. オプション: タスクの パラメーター は、タスクの仕様に基づいて事前に設定されます。必要な場合は、Add Parameters リンクを使用してパラメーターを追加します。

   5. タスクのリソースが指定されていない場合、Missing Resources (リソース不足) の警告がタスクに表示されます。s2i-nodejs タスクをクリックし、タスクの詳細情報が含まれるサイドパネルを表示します。

      図3.3 Pipelines Builder のタスクの詳細

      

   6. タスクのサイドパネルで、s2i-nodejs タスクのリソースおよびパラメーターを指定します。

      1. Input Resources → Source セクションで、Select Resources ドロップダウンリストに、パイプラインに追加したリソースが表示されます。この例では、Source を選択します。
      2. Output Resources → Image セクションで Select Resources リストをクリックし、Img を選択します。
      3. 必要な場合は、$(params.<param-name>) 構文を使用して、Parameters セクションでデフォルトのパラメーターに他のパラメーターを追加します。
      4. 同様に、openshift-client タスクの入力リソースを追加します。
3. Create をクリックし、Pipeline Details ページでパイプラインを作成し、表示します。
4. Actions ドロップダウンメニューをクリックしてから Start をクリックし、Pipeline を起動します。

手順

1. Developer パースペクティブの Pipelines ビューで、Project ドロップダウンリストからプロジェクトを選択し、そのプロジェクトのパイプラインを表示します。

2. 必要なパイプラインをクリックし、Pipeline Details ページを表示します。デフォルトで、Details タブが開き、パイプラインのすべての直列および並列タスクが視覚的に表示されます。タスクはページの右下にも一覧表示されます。一覧表示されている Tasks をクリックし、タスクの詳細を表示できます。

   図3.4 Pipeline の詳細

   

3. オプションで、Pipeline details ページで以下を実行します。

   • Metrics タブをクリックして、パイプラインについての以下の情報を表示します。

     • Pipeline 成功比率
     • Pipeline Run の数
     • Pipeline Run の期間

     • Task Run Balancing

       この情報を使用して、パイプラインのワークフローを改善し、パイプラインのライフサイクルの初期段階で問題をなくすことができます。

   • YAML タブをクリックし、パイプラインの YAML ファイルを編集します。

   • Pipeline Runs タブをクリックして、パイプラインの完了済み、実行中、または失敗した実行を確認します。

     注記

     Pipeline Run Details ページの Details セクションには、失敗したパイプライン実行の Log Snippet (ログスニペット) が表示されます。Log Snippet (ログスニペット) は、一般的なエラーメッセージとログのスニペットを提供します。Logs セクションへのリンクでは、失敗した実行に関する詳細へのクイックアクセスを提供します。Log Snippet は、Task Run Details ページの Details セクションにも表示されます。

     Options メニュー を使用して、実行中のパイプラインを停止するか、以前のパイプライン実行と同じパラメーターとリソースを使用してパイプラインを再実行するか、またはパイプライン実行を削除します。

   • Parameters タブをクリックして、パイプラインに定義されるパラメーターを表示します。必要に応じて追加のパラメーターを追加するか、または編集することもできます。
   • Resources タブをクリックして、パイプラインで定義されたリソースを表示します。必要に応じて追加のリソースを追加するか、または編集することもできます。

1. Developer パースペクティブの Pipelines ビューで、パイプラインに隣接する Options メニューで、Start を選択します。

2. Start Pipeline ダイアログボックスは、パイプライン定義に基づいて Git Resources および Image Resources を表示します。

   注記

   From Git オプションを使用して作成されるパイプラインの場合、Start Pipeline ダイアログボックスでは Parameters セクションに APP_NAME フィールドも表示され、ダイアログボックスのすべてのフィールドがパイプラインテンプレートによって事前に入力されます。

   1. namespace にリソースがある場合、Git Resources および Image Resources フィールドがそれらのリソースで事前に設定されます。必要な場合は、ドロップダウンを使用して必要なリソースを選択または作成し、Pipeline Run インスタンスをカスタマイズします。

3. オプション: Advanced Options を変更し、認証情報を追加して、指定されたプライベート Git サーバーまたはイメージレジストリーを認証します。

   1. Advanced Options で Show Credentials Options をクリックし、Add Secret を選択します。

   2. Create Source Secret セクションで、以下を指定します。

      1. シークレットの一意の シークレット名。
      2. Designated provider to be authenticated セクションで、Access to フィールドで認証されるプロバイダー、およびベース Server URL を指定します。

      3. Authentication Type を選択し、認証情報を指定します。

         • Authentication Type Image Registry Credentials については、認証する Registry Server Address を指定し、Username、Password、および Email フィールドに認証情報を指定します。

           追加の Registry Server Address を指定する必要がある場合は、Add Credentials を選択します。

         • Authentication Type Basic Authentication については、UserName および Password or Token フィールドの値を指定します。
         • Authentication Type SSH Keys については、SSH Private Key フィールドの値を指定します。
      4. シークレットを追加するためにチェックマークを選択します。

   パイプラインのリソースの数に基づいて、複数のシークレットを追加できます。

4. Start をクリックしてパイプラインを開始します。

5. Pipeline Run Details ページには、実行されるパイプラインが表示されます。パイプラインが開始すると、タスクおよび各タスク内のステップが実行されます。以下を実行することができます。

   • 各ステップの実行にかかった時間を表示するには、タスクにカーソルを合わせます。
   • タスクをクリックし、タスクの各ステップのログを表示します。
   • Logs タブをクリックして、タスクの実行シーケンスに関連するログを表示します。該当するボタンを使用して、ペインを展開し、ログを個別に、または一括してダウンロードすることもできます。

   • Events タブをクリックして、パイプライン実行で生成されるイベントのストリームを表示します。

     Task Runs、Logs、および Events タブを使用すると、失敗したパイプラインの実行またはタスクの実行のデバッグに役立ちます。

     図3.5 パイプライン実行の詳細

     

6. From Git オプションを使用して作成されるパイプラインの場合、Topology ビューを使用して、開始後のパイプラインと対話することができます。

   注記

   Topology ビューで Pipeline Builder を使用して作成されるパイプラインを表示するには、パイプラインのラベルをカスタマイズし、パイプラインをアプリケーションのワークロードにリンクします。

   1. 左側のナビゲーションパネルで Topology をクリックし、アプリケーションをクリックしてサイドパネルでパイプラインの実行を表示します。

   2. Pipeline Runs セクションで、Start Last Run をクリックし、直前のパラメーターおよびリソースと同じパラメーターおよびリソースを使用して新規パイプライン実行を開始します。このオプションは、パイプライン実行が開始されていない場合は無効になります。

      図3.6 Topology ビューのパイプライン

      

   3. Topology ページで、アプリケーションの左側にカーソルを合わせ、アプリケーションのパイプライン実行のステータスを確認します。

      注記

      Topology ページのアプリケーションノードのサイドパネルには、特定のタスクの実行時にパイプライン実行が失敗する場合に Log Snippet (ログスニペット) が表示されます。Resources タブの Pipeline Runs セクションに Log Snippet を表示できます。Log Snippet (ログスニペット) は、一般的なエラーメッセージとログのスニペットを提供します。Logs セクションへのリンクでは、失敗した実行に関する詳細へのクイックアクセスを提供します。