第3章 Jenkins から Tekton への移行
3.1. Jenkins から Tekton への移行
Jenkins と Tekton は、アプリケーションとプロジェクトのビルド、テスト、デプロイのプロセスを自動化するために使用されます。ただし、Tekton は、Kubernetes および OpenShift Container Platform とシームレスに動作するクラウドネイティブの CI/CD ソリューションです。本書は、Jenkins CI/CD ワークフローを Tekton に移行するのに役立ちます。
3.1.1. Jenkins と Tekton の概念の比較
本セクションでは、Jenkins と Tekton で使用される基本的な用語の概要を説明し、同等の用語を比較します。
3.1.1.1. Jenkins の用語
Jenkins は、共有ライブラリーおよびプラグインを使用して拡張可能な宣言型およびスクリプト化されたパイプラインを提供します。Jenkins における基本的な用語は以下のとおりです。
- パイプライン: Groovy 構文を使用してアプリケーションをビルドし、テストし、デプロイするプロセスをすべて自動化します。
- ノード: スクリプト化されたパイプラインのオーケストレーションまたは実行できるマシン。
- ステージ: パイプラインで実行されるタスクの概念的に異なるサブセット。プラグインまたはユーザーインターフェイスは、このブロックを使用してタスクの状態または進捗を表示します。
- ステップ: コマンドまたはスクリプトを使用して、実行する正確なアクションを指定する単一タスク。
3.1.1.2. Tekton の用語
Tekton は宣言型パイプラインに YAML 構文を使用し、タスクで設定されます。Tekton の基本的な用語は以下のとおりです。
- パイプライン: 一連のタスク、並行したタスク、またはその両方。
- タスク: コマンド、バイナリー、またはスクリプトとしてのステップシーケンス。
- PipelineRun: 1 つ以上のタスクを使用したパイプラインの実行。
TaskRun: 1 つ以上のステップを使用したタスクの実行。
注記パラメーターやワークスペースなどの入力のセットを使用して PipelineRun または TaskRun を開始し、実行結果を出力およびアーティファクトのセットで開始できます。
ワークスペース: Tekton では、ワークスペースは以下の目的に対応する概念的なブロックです。
- 入力、出力、およびビルドアーティファクトのストレージ。
- タスク間でデータを共有する一般的な領域。
- シークレットに保持される認証情報のマウントポイント、設定マップに保持される設定、および組織が共有される共通のツール。
注記Jenkins には、Tekton ワークスペースに直接相当するものはありません。コントロールノードは、クローン作成したコードリポジトリー、ビルド履歴、およびアーティファクトを格納するため、ワークスペースと考えることができます。ジョブが別のノードに割り当てられると、クローンされたコードと生成されたアーティファクトがそのノードに保存されますが、ビルド履歴はコントロールノードによって維持されます。
3.1.1.3. 概念のマッピング
Jenkins と Tekton のビルディングブロックは同等ではなく、比較は技術的に正確なマッピングを提供しません。Jenkins と Tekton の次の用語と概念は、一般的に相関しています。
| Jenkins | Tekton |
|---|---|
| パイプライン | パイプラインおよび PipelineRun |
| ステージ | タスク |
| Step | タスクのステップ |
3.1.2. サンプルパイプラインの Jenkins から Tekton への移行
このセクションでは、Jenkins および Tekton でのパイプラインの例と同じ例を紹介します。これにより、ビルド、テスト、およびパイプラインを Jenkins から Tekton に移行するのに役立ちます。
3.1.2.1. Jenkins パイプライン
Groovy で書かれた Jenkins パイプラインについて、ビルド、テスト、およびデプロイについて見てみましょう。
pipeline {
agent any
stages {
stage('Build') {
steps {
sh 'make'
}
}
stage('Test'){
steps {
sh 'make check'
junit 'reports/**/*.xml'
}
}
stage('Deploy') {
steps {
sh 'make publish'
}
}
}
}3.1.2.2. Tekton パイプライン
Tekton では、Jenkins Pipeline の同等の例は 3 つのタスクで設定されており、それぞれは YAML 構文を使用して宣言的に記述できます。
build タスクの例
apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
name: myproject-build
spec:
workspaces:
- name: source
steps:
- image: my-ci-image
command: ["make"]
workingDir: $(workspaces.source.path)
test タスクの例
apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
name: myproject-test
spec:
workspaces:
- name: source
steps:
- image: my-ci-image
command: ["make check"]
workingDir: $(workspaces.source.path)
- image: junit-report-image
script: |
#!/usr/bin/env bash
junit-report reports/**/*.xml
workingDir: $(workspaces.source.path)
deploy タスクの例
apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
name: myprojectd-deploy
spec:
workspaces:
- name: source
steps:
- image: my-deploy-image
command: ["make deploy"]
workingDir: $(workspaces.source.path)
3 つのタスクを順次組み合わせ、Tekton パイプラインを形成できます。
例: ビルド、テスト、およびデプロイメント用の Tekton パイプライン
apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
name: myproject-pipeline
spec:
workspaces:
- name: shared-dir
tasks:
- name: build
taskRef:
name: myproject-build
workspaces:
- name: source
workspace: shared-dir
- name: test
taskRef:
name: myproject-test
workspaces:
- name: source
workspace: shared-dir
- name: deploy
taskRef:
name: myproject-deploy
workspaces:
- name: source
workspace: shared-dir
3.1.3. Jenkins プラグインから Tekton Hub タスクへの移行
プラグイン を使用して、Jenkins の機能を拡張することができます。Tekton で同様の拡張性を実現するには、Tekton Hub から利用可能なタスクのいずれかを使用します。
たとえば、Jenkins の git プラグイン に対応する Tekton Hub で利用可能な git-clone タスクについて考えてみましょう。
例: Tekton Hub からの git-clone タスク
apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
name: demo-pipeline
spec:
params:
- name: repo_url
- name: revision
workspaces:
- name: source
tasks:
- name: fetch-from-git
taskRef:
name: git-clone
params:
- name: url
value: $(params.repo_url)
- name: revision
value: $(params.revision)
workspaces:
- name: output
workspace: source
3.1.4. カスタムタスクおよびスクリプトを使用した Tekton 機能の拡張
Tekton では、Tekton Hub で適切なタスクが見つからない場合、またはタスクをより細かく制御する必要がある場合は、カスタムタスクとスクリプトを作成して Tekton の機能を拡張できます。
例: maven test コマンドを実行するカスタムタスク
apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
name: maven-test
spec:
workspaces:
- name: source
steps:
- image: my-maven-image
command: ["mvn test"]
workingDir: $(workspaces.source.path)
例: パスを指定してカスタムシェルスクリプトを実行します。
...
steps:
image: ubuntu
script: |
#!/usr/bin/env bash
/workspace/my-script.sh
...
例: YAML ファイルにカスタム Python スクリプトの実行
...
steps:
image: python
script: |
#!/usr/bin/env python3
print(“hello from python!”)
...
3.1.5. Jenkins および Tekton 実行モデルの比較
Jenkins と Tekton は同様の機能を提供しますが、アーキテクチャーと実行で異なります。このセクションでは、2 つの実行モデルを簡単に比較します。
| Jenkins | Tekton |
|---|---|
| Jenkins にはコントロールノードがあります。Jenkins は、パイプラインとステップを一元的に実行するか、他のノードで実行しているジョブのオーケストレーションを行います。 | Tekton はサーバーレスおよび分散であり、実行のための中心的な依存関係はありません。 |
| コンテナーは、パイプラインを使用してコントロールノードによって起動します。 | Tekton では、container-first アプローチを採用しています。ここでは、すべてのステップが Pod で実行されるコンテナーとして実行されます (Jenkins のノードと同等)。 |
| 拡張性はプラグインを使用して実現します。 | 拡張性は、Tekton Hub のタスクを使用するか、カスタムタスクおよびスクリプトを作成して実行します。 |
