検索

4.5. OpenShift Pipelines を使用したアプリケーションの CI/CD ソリューションの作成

download PDF

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. プロジェクトの作成およびパイプラインのサービスアカウントの確認

手順

  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

4.5.3. パイプラインタスクの作成

手順

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

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 にデプロイします。

手順

  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.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 として追加されます。

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

    $ 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
  3. 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 のミラーレジストリーからそれぞれのビルダーイメージをミラーリングする必要があります。

手順

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

4.5.6. パイプラインの実行

PipelineRun リソースはパイプラインを開始し、これを特定の呼び出しに使用する必要のある Git およびイメージリソースに関連付けます。これは、パイプラインの各タスクについて TaskRun を自動的に作成し、開始します。

手順

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

    $ 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) を作成するボリューム要求テンプレートを使用します。

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

4.5.7. トリガーのパイプラインへの追加

トリガーは、パイプラインがプッシュイベントやプル要求などの外部の GitHub イベントに応答できるようにします。アプリケーションのパイプラインをアセンブルし、起動した後に、TriggerBindingTriggerTemplateTrigger、および EventListener リソースを追加して GitHub イベントを取得します。

手順

  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.5/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.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) を作成する必要はありません。

  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.5/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.5/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.5/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

4.5.8. Webhook の作成

Webhook は、設定されたイベントがリポジトリーで発生するたびにイベントリスナーよって受信される HTTP POST メッセージです。その後、イベントペイロードはトリガーバインディングにマップされ、トリガーテンプレートによって処理されます。トリガーテンプレートは最終的に 1 つ以上のパイプライン実行を開始し、Kubernetes リソースの作成およびデプロイメントを実行します。

このセクションでは、フォークされた Git リポジトリー pipelines-vote-ui および pipelines-vote-api で Webhook URL を設定します。この URL は、一般に公開されている EventListener サービスルートを参照します。

注記

Webhook を追加するには、リポジトリーへの管理者権限が必要です。リポジトリーへの管理者アクセスがない場合は、Webhook を追加できるようにシステム管理者に問い合わせてください。

手順

  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 を繰り返します。

4.5.9. パイプライン実行のトリガー

push イベントが Git リポジトリーで実行されるたびに、設定された Webhook はイベントペイロードを公開される EventListener サービスルートに送信します。アプリケーションの EventListener サービスはペイロードを処理し、これを関連する TriggerBinding および TriggerTemplate リソースのペアに渡します。TriggerBinding リソースはパラメーターを抽出し、TriggerTemplate リソースはこれらのパラメーターを使用して、リソースの作成方法を指定します。これにより、アプリケーションが再ビルドされ、再デプロイされる可能性があります。

このセクションでは、空のコミットをフロントエンドの pipelines-vote-ui リポジトリーにプッシュし、パイプライン実行をトリガーします。

手順

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

    $ git clone git@github.com:<your GitHub ID>/pipelines-vote-ui.git -b pipelines-1.5
  2. 空のコミットをプッシュします。

    $ git commit -m "empty-commit" --allow-empty && git push origin pipelines-1.5
  3. パイプライン実行がトリガーされたかどうかを確認します。

    $ tkn pipelinerun list

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

4.5.10. 関連情報

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.