OpenShift Pipelines Lab - Pipeline 1/2
はじめに
Red Hat OpenShift Pipelinesは、Kubernetesリソースに基づくクラウドネイティブの継続的インテグレーションおよび継続的デリバリー(CI / CD)ソリューションです。
Tektonビルディングブロックを使用して、基盤となる実装の詳細を抽象化することにより、複数のプラットフォームにわたる展開を自動化します。
Tektonは、Kubernetesディストリビューション間で移植可能なCI / CDパイプラインを定義するためのいくつかの標準カスタムリソース定義(CRD)を導入しています。
tkn コマンドの使用 (補足)
今回のLabでは tkn コマンドは使いませんが、利用イメージをご紹介します。
- 
Taskの一覧を表示
tkn task list- 
出力例(実環境とは異なる可能性があります)
No Tasks foundTaskが登録されていないことがわかります。
 
 - 
 - 
ClusterTaskの一覧を表示
tkn clustertask list- 
出力例(実環境とは異なる可能性があります)
NAME DESCRIPTION AGE argocd-task-sync-and-wait This task syncs (de... 3 hours ago buildah Buildah task builds... 3 hours ago buildah-1-8-0 Buildah task builds... 3 hours ago git-cli This task can be us... 3 hours ago git-clone These Tasks are Git... 3 hours ago git-clone-1-8-0 These Tasks are Git... 3 hours ago helm-upgrade-from-repo These tasks will in... 3 hours ago helm-upgrade-from-source These tasks will in... 3 hours ago jib-maven This Task builds Ja... 3 hours ago kn This Task performs ... 3 hours ago kn-1-8-0 This Task performs ... 3 hours ago kn-apply This task deploys a... 3 hours ago kn-apply-1-8-0 This task deploys a... 3 hours ago kubeconfig-creator This Task do a simi... 3 hours ago maven This Task can be us... 3 hours ago maven-1-8-0 This Task can be us... 3 hours ago openshift-client This task runs comm... 3 hours ago openshift-client-1-8-0 This task runs comm... 3 hours ago pull-request This Task allows a ... 3 hours ago s2i-dotnet s2i-dotnet task fet... 3 hours ago s2i-dotnet-1-8-0 s2i-dotnet task fet... 3 hours ago s2i-go s2i-go task clones ... 3 hours ago s2i-go-1-8-0 s2i-go task clones ... 3 hours ago s2i-java s2i-java task clone... 3 hours ago s2i-java-1-8-0 s2i-java task clone... 3 hours ago s2i-nodejs s2i-nodejs task clo... 3 hours ago s2i-nodejs-1-8-0 s2i-nodejs task clo... 3 hours ago s2i-perl s2i-perl task clone... 3 hours ago s2i-perl-1-8-0 s2i-perl task clone... 3 hours ago s2i-php s2i-php task clones... 3 hours ago s2i-php-1-8-0 s2i-php task clones... 3 hours ago s2i-python s2i-python task clo... 3 hours ago s2i-python-1-8-0 s2i-python task clo... 3 hours ago s2i-ruby s2i-ruby task clone... 3 hours ago s2i-ruby-1-8-0 s2i-ruby task clone... 3 hours ago skopeo-copy Skopeo is a command... 3 hours ago skopeo-copy-1-8-0 Skopeo is a command... 3 hours ago tkn This task performs ... 3 hours ago tkn-1-8-0 This task performs ... 3 hours ago trigger-jenkins-job The following task ... 3 hours ago 
 - 
 
ClusterTaskは、Tekton Catalogの一部がデフォルトで登録されていることがわかります。
Task と TaskRun
プロジェクトの作成
- 
OpenShift web コンソールで Administrator パースペクティブを選択します
 - 
左のナビゲーションバーで ホーム → プロジェクト を選択し、画面右上の プロジェクトの作成 ボタンをクリックし、 名前 に
trivial-pipelineを入力し作成します 
タスクの作成
- 
以下の YAML をインポートして、次の方法で新しいタスクを作成します
- 
左のナビゲーションバーから Pipelines → Tasks をクリックします
 - 
右上の 作成 ボタンをクリックし、ドロップダウンから Task を選択します
 - 
表示されたデフォルトの YAML 定義を次のように置き換えます
apiVersion: tekton.dev/v1beta1 kind: Task metadata: name: hello namespace: trivial-pipeline spec: steps: - name: say-hello image: registry.access.redhat.com/ubi8/ubi command: - /bin/bash args: ['-c', 'echo Hello World'] 
 - 
 - 
作成 ボタンをクリックします
 
タスクの実行(TaskRun)
タスクを実行するには、TaskRunオブジェクトを作成する必要があります。
コマンドラインの tkn ユーティリティを使用するか、次の yaml をインポートできます。
- 
左のナビゲーションバーでもう一度 Tasks をクリックします
 - 
作成 ボタンをクリックしドロップダウンメニューから TaskRun を選択します
 - 
デフォルトの YAML を以下のように変更し、 作成 をクリックします
apiVersion: tekton.dev/v1beta1 kind: TaskRun metadata: namespace: trivial-pipeline generateName: hello-run- labels: app.kubernetes.io/managed-by: tekton-pipelines tekton.dev/task: hello spec: resources: serviceAccountName: pipeline taskRef: kind: Task name: hello - 
ログ タブをクリックし実行したタスクを確認します。"Hello World" が表示されていると思います。
 
2 Tier アプリケーションのデプロイ
Task 作成 -1/2
いくつかのTask、ClusterTasks、およびカスタムタスクを使用してアプリケーションをビルドおよびデプロイをします。
まず、この作業用の名前空間/プロジェクトを作成します。
- 
プロジェクト: のドロップダウンボックスから、プロジェクトの作成 を選び、名前 に
pipelines-testを入力し新しいプロジェクトを作成します。 - 
ナビゲーションバーから Pipelines → Tasks → 作成 をクリックし、 Task を選択します。
 - 
デフォルトの YAML を以下のように変更します。
# task apiVersion: tekton.dev/v1beta1 kind: Task metadata: name: apply-manifests spec: workspaces: # ----- <a> ----- - name: source # ----- <b> ----- params: - name: manifest_dir description: The directory in source that contains yaml manifests type: string default: "k8s" # ----- <c> ----- steps: - name: apply image: quay.io/openshift/origin-cli:latest workingDir: /workspace/source command: ["/bin/bash", "-c"] # ----- <d> ----- args: - |- echo Applying manifests in $(inputs.params.manifest_dir) directory oc apply -f $(inputs.params.manifest_dir) echo -----------------------------------備考:
- 
<a>
workspacesとはパラメータやタスクの出力が格納されるPVCを示しています。これに "source" と名前を付与しています。 - 
<b> このタスクが受け付ける1つのパラメータです。ここでは、アプリケーションをデプロイするためのyamlマニフェストが存在するディレクトリの入力を求めています。
 - 
<c> このタスクの1つのステップです。このタスクは、パラメータで定義された
manifest_dir内のすべてのファイルに対してoc apply -fを実行することで、実際に OpenShift のオブジェクトを作成します。 - 
<d> ステップの中でパラメータが
$(inputs.params.)という構文で参照されていることに注意してください。 
 - 
 - 
作成 をクリックします。
 
| 
 パラメータを使用するタスクに送信される前に、パラメータはどこで定義されているでしょうか? それは TaskRuns の中です。上記のtrivial-pipelineで行ったように、個々のTaskRunを作成することもできますし、以下で説明するように、PipelineRun にこれらの値を与えることもできます。  | 
Task 作成 -2/2
Deployment リソースで展開されたイメージの名前を更新するタスクを作成します。 パイプラインでは、アプリケーションを新たにビルドするたびに新しいコンテナイメージを構築しているため、新しいコンテナイメージには異なるタグやハッシュ値が設定されます。
Podの再デプロイ時に適切なコンテナイメージが使用されていることを確認するために、パイプラインにタスクが必要です。
- 
Pipeline → Tasks → 作成 をクリックし、 Task を選択します.
 - 
デフォルトの YAML を以下のように変更します。
apiVersion: tekton.dev/v1beta1 kind: Task metadata: name: update-deployment spec: workspaces: # ----- <a> ----- - name: source params: # ----- <a> ----- - description: The name of the deployment patch the image name: deployment type: string # ----- <a> ----- - description: Location of image to be patched with name: IMAGE type: string steps: - args: - |- oc patch deployment $(inputs.params.deployment) --patch='{"spec":{"template":{"spec":{ "containers":[{ "name": "$(inputs.params.deployment)", "image":"$(inputs.params.IMAGE)" }] }}}}' command: - /bin/bash - -c # ----- <b> ----- image: quay.io/openshift/origin-cli:latest name: patch resources: {}備考:
- 
<a> これらは Task リソースが、TaskRun リソースから受け取ろうとしているパラメータです。
 - 
<b> この Task は、OpenShiftのコマンドラインツールである
oc専用のコンテナを使用します。 
 - 
 - 
作成 をクリックします。
 
Persistent Volume Claim リソースの作成
Workspace のデータを保存するための PVC を作成します。
- 
Task のパラメータと結果の出力は、Tektonによって専用のPVCに自動的に保存されます。
 - 
これら Workspaces は、PipelineRun によってタスクに関連付けられており、任意の数のワークスペースを持つことができます。
 - 
さらに、Workspaces は1つまたは複数のタスクにまたがることができ、 Task がお互いのデータにアクセスできる共有領域を証明することができます。これらは通常のPVCです。
- 
OpenShiftのWebコンソールの右上の "+" ボタン(YAMLのインポート)をクリックし、以下のYAMLを貼り付けて、Workspace をサポートするPVCを作成します。
本手順では、定義を適用してPVCリソースを作成するために、右上の "+" ボタン(YAMLのインポート)を使用しています。 GUIから実施する場合は、 ストレージ → PersistentVolumeClaims → PersistentVolumeClaims の作成 を選択することでPVCを作成することができます。
apiVersion: v1 kind: PersistentVolumeClaim metadata: name: source-pvc spec: accessModes: - ReadWriteOnce resources: requests: storage: 500Mi 
 - 
 
ビルド/デプロイを行うパイプラインの作成
今作成中のパイプラインは3つの大きいセクションと、4つの Task で構成されています。 セクションは以下です。
- Workspaces
 - 
Workspace を使用する Task リソースにコンテキストを提供するために定義されています
 - Params
 - 
パイプラインが PipelineRun から期待され、Task リソースで利用できる入力が定義されています
 - Tasks
 - 
実行されるタスクが定義されるタスクの配列です。 Workspace は Tasks が利用可能なように作成され、渡されるパラメータを定義しています。
パイプラインの定義にあるようなタスクの順序は適用されません。いくつかのステップには
runAfterという値があり、現在のステップが後に実行すべき特定のタスクを示しています。Tektonのデフォルトでは、すべてのステップを並行して実行するため、この値が必要になります。 これは、他の継続的統合システムとの重要な差別化要因として覚えておいてください。- 
ナビゲーションバーより Pipelines を選択し、表示されたメニューから Pipelines → 作成 → Pipeline を選択します。
 - 
🔘 YAML ビュー のラジオボタンをクリックし、定義を貼り付けるためのテキストエリアを表示します。
 - 
デフォルトの YAML を以下のように変更します。
apiVersion: tekton.dev/v1beta1 kind: Pipeline metadata: name: build-and-deploy spec: # ----- <a> ----- workspaces: - name: shared-workspace # ----- <b> ----- 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: "master" - name: IMAGE type: string description: image to be build from the code # ----- <c> ----- tasks: - name: fetch-repository taskRef: name: git-clone kind: ClusterTask workspaces: # ----- <d> ----- - 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: TLSVERIFY value: "false" - name: IMAGE value: $(params.IMAGE) workspaces: # ----- <d> ----- - name: source workspace: shared-workspace # ----- <e> ----- 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 workspaces: - name: source workspace: shared-workspace params: - name: deployment value: $(params.deployment-name) - name: IMAGE value: $(params.IMAGE) runAfter: - apply-manifests備考:
- 
<a> ここのタスクと共有されるPVCを定義します。
 - 
<b> パイプラインが PipelineRun リソースから期待するパラメータが定義されています。
 - 
<c> Task リソースの配列です。このリストの表示順に実行されるわけではありません。
 - 
<d> Workplace の詳細: これらの#4の設定はいずれも、ワークスペースのファイルシステム内の異なるサブディレクトリ (
outputandsource) を示しています。Tektonはこれらを自動的に整理し、必要に応じて、先ほど見たように、$(input.)を介して、お互いのデータにアクセスすることができます。 - 
<e>
runAfter:は Task の中で設定され、このパイプライン内のタスクの実行順序を定義します。 
 - 
 - 
作成 をクリックします。
 
 - 
 
バックエンドAPIのパイプラインを実行
Votingアプリのバックエンド部分のパイプラインを実行してみましょう。
- 
ナビゲーションバーより Pipelines を選択し、表示されたメニューから Pipelines → 作成 → PipelineRun を選択します。
 - 
デフォルトの YAML を以下のように変更します。
apiVersion: tekton.dev/v1beta1 kind: PipelineRun metadata: labels: tekton.dev/pipeline: build-and-deploy generateName: build-and-deploy-run-backendapp- spec: # ----- <a> ----- !必要に応じてプロジェクト名を修正してください params: - name: IMAGE value: image-registry.openshift-image-registry.svc:5000/pipelines-test/pipelines-vote-api - name: deployment-name value: pipelines-vote-api - name: git-url value: https://github.com/openshift/pipelines-vote-api.git # ----- <b> ----- pipelineRef: name: build-and-deploy serviceAccountName: pipeline timeout: 1h0m0s # ----- <c> ----- workspaces: - name: shared-workspace persistentVolumeClaim: claimName: source-pvc備考:
- 
<a> この PipelineRun が作成する TaskRuns によって、Task リソースに渡す実際の文字列の値です。
 - 
<b> 前のセクションで作成したPipelineへの参照です。
 - 
<c> 最後に Workspace の定義です。ここで、PVC と Workspace がひもづけられています。
 
 - 
 - 
作成 をクリックし、パイプラインを実行します。
 
これで、アプリケーションの一部分がデプロイされました。
フロントエンドAPI用(ui)のパイプラインを実行
- 
バックエンドのときと同様に、以下の PipelineRun 定義を使用してビルドを実行し、アプリケーションをデプロイします。
apiVersion: tekton.dev/v1beta1 kind: PipelineRun metadata: generateName: build-and-deploy-run-frontendapp- labels: tekton.dev/pipeline: build-and-deploy spec: params: - name: IMAGE #<1> !必要に応じてプロジェクト名を修正してください value: image-registry.openshift-image-registry.svc:5000/pipelines-test/pipelines-vote-ui - name: deployment-name value: pipelines-vote-ui - name: git-url (2) value: https://github.com/openshift/pipelines-vote-ui.git pipelineRef: name: build-and-deploy serviceAccountName: pipeline timeout: 1h0m0s workspaces: - name: shared-workspace persistentVolumeClaim: claimName: source-pvc備考:
- 
<a> ビルドが書き込まれるイメージ名と、Pod がデプロイされるイメージ名が異なることに注意してください。
 - 
<b> アプリケーションのフロントエンド用に異なるリポジトリを使用しています。
 
 - 
 - 
作成 をクリックし、パイプラインの実行を見てみましょう!