Tektonシリーズに関する理論的な記事

前回の記事では、Tektonのインストールを紹介し、簡単なテストをしましたが、原因はわかりませんでした。この記事では主にその理由を理解し、学ぶことを目指します。

Tekton は、Kubernetes CRD に基づいてパイプラインを定義するオープンソースのクラウドネイティブ CI/CD プロジェクトです。強力で拡張も簡単です。

前回の記事では、Tekton をインストールした後、インストールされた CRD を次のように確認できます。

 # kubectlでcrd を取得します| grep テクトン
クラスタータスク.tekton .dev 2022-02-28 T06 : 15 : 38Z
 条件.tekton .dev 2022-02-28 T06 : 15 : 38Z
 拡張機能。 ダッシュボード。 テクトン。 開発2022-02-28 T06 : 18 : 40Z
 パイプラインリソース.tekton .dev 2022-02-28 T06 : 15 : 38Z
 Pipelineruns.tekton.dev 2022-02-28 T06 : 15 : 38Z
 パイプライン.tekton .dev 2022-02-28 T06 : 15 : 38Z
 .tekton .dev を実行します2022-02-28 T06 : 15 : 38Z
 taskruns.tekton.dev 2022-02-28 T06 : 15 : 38Z
 タスク.tekton .dev 2022-02-28 T06 : 15 : 38Z

その中でも、Task、TaskRun、Pipeline、PipelineRun、PipelineResource、Condition がコア CRD であり、ここでは主にこれらを紹介します。

• タスク:一連の順序付けられたステップで構成されるビルド タスクを定義します。各ステップでは入力と出力を定義でき、前のステップの出力を次のステップの入力として使用できます。各ステップはコンテナによって実行されます。
• TaskRun:タスクは特定のタスクを定義するために使用され、実際には実行されません。 TaskRun は実際の実行者であり、実行に必要なパラメータを提供します。 TaskRun は Pod です。
• パイプライン:名前が示すように、一連のタスクで構成されるパイプラインです。タスク内のステップと同様に、前のタスクの出力を次のタスクの入力として使用できます。
• PipelineRun:パイプラインの実際の実行。作成後、タスクを実行するための Pod が作成されます。 PipelineRun には複数のタスクがあります。
• PipelineResource:主に Git アドレスや Docker イメージなどの Pipeline リソースを定義するために使用されます。
• 条件:主にパイプラインでの判定に使用されます。タスクが実行されるかどうかは、条件の判定結果によって決定されます。

ヒント: PipelineResource と Condition は両方とも非推奨になります。ただし、下位バージョンでも引き続き使用されるため、ここで簡単に紹介します。

上の図に示すように、パイプラインは多数のタスクで構成され、各タスクは多数のステップで構成されます。実際の作業では、さまざまなタスクを柔軟に定義し、必要に応じてタスクを任意に組み合わせて、さまざまな要件を満たすさまざまなパイプラインを形成することができます。

実施原則

上記では、Tekton の主な CRD とその機能について簡単に紹介しました。それで、Tekton はこれらの CRD をどのように直列に接続するのでしょうか?

Tekton をインストールすると、次の 2 つの Pod が表示されます。

 # kubectl get po -n tekton - パイプライン
名前準備完了ステータス再起動年齢
tekton - パイプライン- コントローラ- 75 c456df85 - qxvq2 1 / 1 実行中0 2 d22h
 tekton - パイプライン- webhook - 5 bc8d6b7c4 - w6pdn 1 / 1 実行中0 2 d22h

1 つは tekton-pipelines-controller で、もう 1 つは tekton-pipelines-webhook です。実際、命名方法から、1 つは CRD オブジェクトを監視するために使用される te​​kton コントローラーであり、もう 1 つは CRD 検証を実行するために使用される te​​kton ネットワーク フックであることがわかります。その中で、tekton-pipelines-controller は Tekton のコア実装 Pod です。

tekton-pipelines-controller が起動すると、PipelineRunController と TaskRunController の 2 つのコントローラーが初期化されます。次のように、main.go (cmd/controller/main.go) を通じて確認できます。

 ......
 関数() {
 // ポートでWebサーバーを起動し、リクエストを受け入れます
ログ。 Printf ( "準備状況とヘルスチェックサーバーがポート %s で待機しています" 、 ポート)
 ログ。 致命的( http .ListenAndServe ( ":" + port , mux ))
 }()
 ctx = フィルターされた情報ファクトリー。 セレクター付き( ctx 、 v1beta1 。 ManagedByLabelKey )
 共有メイン。 MainWithConfig ( ctx 、 ControllerLogKey 、 cfg 、
 タスクを実行します。 NewController ( opts 、 clock . RealClock {})、
 パイプラインを実行します。 NewController ( opts 、 clock . RealClock {})、
 ）
 }

上記のように、初期化には taskrun.NewController と pipelinerun.NewController が使用され、次に sharedmain.MainWithConfig を通じて controller.StartAll が呼び出され、すべてのコントローラーが起動されます。

PipelineRunController は、PipelineRun オブジェクトの変更をリッスンし、PipelineSpec からタスク リストを取得して有向非巡回グラフ (DAG) を構築し、DAG を走査してスケジュール可能なタスク ノードを見つけて、対応する TaskRun オブジェクトを作成します。詳細については、(pkg/reconciler/pipelinerun/pipelinerun.go) の reconcile メソッドを通じて確認できます。

TaskRunController は、TaskRun オブジェクトの変更を監視するときに、TaskRun 内の Task を Pod に変換し、Kubernetes によって実行するようにスケジュールします。 (pkg/reconciler/taskrun/taskrun.go) の reconcile メソッドを通じて表示できます。

Kubernetes の OwnerReference メカニズムを使用することで、PipelineRun が TaskRun を所有し、TaskRun が Pod を所有し、Pod のステータスが変化すると TaskRun の調整ロジックがトリガーされます。 TaskRun のステータスが変化すると、PipelineRun の調整ロジックがトリガーされます。

TaskRun Pod が実行状態になると、最初のステップ コンテナーに実行を通知します (entrypoint と呼ばれるバイナリ ファイルを通じて)。

もちろん、このエントリポイントバイナリファイルにも実行条件があります。提供されたコマンドは、パイプライン ステータス アノテーションが Kubernetes ダウンロード API を介してファイルとしてステップ コンテナーに挿入された場合にのみ開始されます。この文章は少しわかりにくいでしょうか?公式声明によると、Tekton Pipeline は Kubernetes Annotation を通じて Pipeline のステータスを追跡し、これらの注釈は Kubernetes Download API を通じてファイルとして Step Container に挿入されます。ステップ コンテナーのエントリポイントはこれらのファイルをリッスンします。特定のアノテーションがファイルの形式で挿入されると、エントリポイントはコマンドを実行します。たとえば、タスクに 2 つのステップがある場合、2 番目のステップのエントリポイントは、最初のステップが完了したことがファイルの形式でアノテーションによって通知されるまで待機します。

全体的なプロセスを次のように整理してみましょう。

1. ユーザーはクライアントを通じて PipelineRun リソースを作成します。
2. PipelineRunController は PipelineRun リソースをリッスンすると、その中のタスクを DAG (有向非巡回グラフ) に整理し、DAG を走査してタスクを取得し、TaskRun を作成します。
3. TaskRunController は、TaskRun リソースを監視するときに、Task を Pod に変換し、Kubernetes を通じて起動します (Task は Condition によって制御されます)。
4. Pod が起動すると、タスク内の各ステップが実行され、特定の指示が完了します。
5. 実行が完了すると、Pod は Completed 状態に変わり、PipelineRun のステータスも更新されます。

この時点で、パイプラインは完成しました。

パイプラインリソース

ここで最初に PipelintResource について言及するのは、次の操作で必要になることを説明するためです。

PipelineResource はリソース情報を定義するために使用されます。非推奨となりますが、古いバージョンでは引き続き使用されます。

PipelineResource の定義は次のように非常にシンプルです。

 apiバージョン: tekton.dev/v1alpha1
 種類: パイプラインリソース
メタデータ:
 名前: こんにちは- 単語- リソース
仕様:
 タイプ: git
 パラメータ:
 - 名前: URL
 値: https://gitee.com/coolops/springboot-helloworld.git

TaskRun では、hello-word-resource リソースを参照して特定の git アドレスを取得できます。

TasksTask はタスク テンプレートです。タスクの定義には変数を含めることができ、実際の実行時には変数に値を割り当てる必要があります。

タスク

入力パラメータは input.params を通じて定義されます。各入力パラメータにはデフォルト値を指定することもできます。各ステップでは、変数は $(params.A) によって参照できます。ステップ フィールドには、現在のタスクのステップが示されます。各ステップでは、コンテナを定義して特定の操作を実行します。

タスクには主に次の要素が含まれます。

• パラメーター: params パラメーターを定義するために使用されます。
• リソース:入力リソースと出力リソースを定義します。旧バージョンは PipelineResources によって定義されていましたが、新バージョンでは PipelineResources は非推奨になります。
• 手順:具体的な操作手順を定義します。
• ワークスペース:ワークスペースを定義します。タスクはワークスペースを共有できます。
• 結果:表示または他のタスクでの使用に使用できる結果出力を定義します。

タスクの定義は次のとおりです。

 apiバージョン: tekton.dev/v1beta1
 種類: タスク
メタデータ:
 名前: maven - ビルド
仕様:
 リソース：
 入力:
 - 名前: リポジトリ
タイプ: git
 手順:
 - 名前: ビルド
イメージ: maven : 3.3 - jdk - 8
 指示：
 - mvn クリーンパッケージ
作業ディレクトリ: / workspace / repo

次のように、Docker イメージをビルドしてハブにプッシュする別のタスクを定義します。

 apiバージョン: tekton.dev/v1beta1
 種類: タスク
メタデータ:
 名前: ビルドとプッシュイメージ​ ​
 仕様:
 パラメータ:
 - 名前: Dockerファイルへのパス
タイプ: 文字列
デフォルト: / workspace / repo / Dockerfile
 説明: Dockerfile パスを定義する
- 名前: コンテキストへのパス
タイプ: 文字列
デフォルト: / workspace / repo
 説明: Docker デーモンビルドコンテキスト
- 名前: イメージリポジトリ
タイプ: 文字列
デフォルト: レジストリ。 cn - 杭州。 アリユンクス。 com
 説明: docker イメージリポジトリ
リソース：
 入力:
 - 名前: リポジトリ
タイプ: git
 出力:
 - 名前: 組み込みイメージ
タイプ: 画像
手順:
 - 名前: ビルド- イメージ
イメージ: docker : 安定版
スクリプト: |
 # ! / usr / bin / envsh
 docker ログイン$ ( params . imageRepo )
 docker build -t $ ( resources.outputs.builtImage.url ) -f $ ( params.pathToDockerfile ) $ ( params.pathToContext ) ​
 docker push $ ( リソース. 出力. 組み込みイメージ.url )
 ボリュームマウント:
 - 名前: dockersock
 マウントパス: /var/run/docker.sock
 巻数:
 - 名前: dockersock
 ホストパス:
 パス: /var/run/docker.sock

前述のように、シェル スクリプトを直接記述することで要件を満たすことができますが、docker を使用してイメージを構築するには、ポッド マウントのようにマウントできる sock ファイルが必要です。

ステップのタイムアウトを設定するなど、ステップには次のような他の構成もあります。

 手順:
 - 名前: スリープ- その後- タイムアウト
画像: Ubuntu
 スクリプト: |
 # !/ usr / bin / env bash
 echo "60秒間寝ることになっています！"
 睡眠60
 タイムアウト: 5 秒

より多くの操作については、(https://tekton.dev/docs/pipelines/tasks/) を参照してください。

タスクラン

タスクが定義された後、関数を定義した場合と同様に、タスクは実行されません。関数が呼び出されなければ、その関数は実行されません。また、TaskRun は呼び出し元のように機能し、これを使用して Task 内の特定のコンテンツを実行できます。

TaskRun は、次のように、タスクに必要なパラメータを設定し、taskRef フィールドを通じてタスクを参照します。

 apiバージョン: tekton.dev/v1beta1
 種類: タスク実行
メタデータ:
 名前: ビルドとプッシュイメージ​ ​
 仕様:
 パラメータ:
 - 名前: イメージリポジトリ
値: レジストリ。 cn - 張家口。 アリユンクス。 com
 タスク参照:
 name : build - and - push - image # 定義されたタスクを関連付ける
リソース：
 入力:
 - name : repo # 入力ウェアハウスリソースを指定します
リソース参照:
 名前: こんにちは- 単語- リソース
出力: # 出力画像リソースを指定する
- 名前: 組み込みイメージ
リソース参照:
 名前: こんにちは- 単語- 画像

上記の定義により、build-and-push-image タスクが関連付けられ、タスクに必要なソース パラメータがリソースを通じて定義され、次にパラメータが parms を通じて定義され、タスク内のデフォルト パラメータが置き換えられます。

実際には、タスクが適切に機能しているかどうかをテストする場合を除き、TaskRun を定義することはほとんどありません。

パイプライン

TaskRun は 1 つのタスクのみを実行できます。同時に多くのタスクをオーケストレーションする必要がある場合は、Jenkinsfile を使用してさまざまなタスクをオーケストレーションするのと同じように、Pipeline を使用する必要があります。

パイプラインはタスクを配置するためのテンプレートです。 Spec.params は実行に必要な入力パラメータを宣言するために使用され、spec.tasks は特定のタスクを配置するために使用されます。さらに、runAfter を使用してタスクの順序を制御することもできます。

まず、次のように単純なパイプラインを定義します。

 apiバージョン: tekton.dev/v1beta1
 種類: パイプライン
メタデータ:
 名前: ビルドとプッシュイメージ​ ​
 仕様:
 リソース：
 - 名前: リポジトリ
タイプ: git
 - 名前: 組み込みイメージ
タイプ: 画像
タスク:
 #Docker イメージをビルドしてプッシュする
- 名前: ビルド- および- イメージをプッシュ
タスク参照:
 名前: ビルドとプッシュイメージ​ ​
 リソース：
 入力:
 - name : repo # タスク入力名
resource : repo # パイプラインリソース名
出力:
 - 名前: 組み込みイメージ
リソース: 組み込みイメージ

上記で定義したパイプラインは、build-and-push-image タスクに関連付けられています。タスクに必要な入力および出力パラメータは、パイプラインの spec.resources を通じて定義されます。ここで、spec.resources は依然として PipelineResources で定義された特定のリソースに依存します。

前述のように、パイプライン内のタスクの順序を制御する場合は、次のように runAfter パラメータを使用する必要があります。

 - 名前: テスト- アプリ
タスク参照:
 名前: 作成- テスト
リソース：
 入力:
 - 名前: ワークスペース
リソース: 私のリポジトリ
- 名前: ビルド- アプリ
タスク参照:
 名前： カニコビルド​
 実行後:
 - テスト- アプリ
リソース：
 入力:
 - 名前: ワークスペース
リソース: 私のリポジトリ

上記のように、build-app タスクは test-app タスクに依存します。

さらに、次のように、前のタスクの出力を次のタスクの入力として使用することもできます。

 - 名前: ビルド- アプリ
タスク参照:
 名前: ビルド- プッシュ
リソース：
 出力:
 - 名前: 画像
リソース: 私の画像
- 名前: デプロイ- アプリ
タスク参照:
 名前: デプロイ- kubectl
 リソース：
 入力:
 - 名前: 画像
リソース: 私の画像
から：
 - ビルド- アプリ

上記のように、from キーワードは他のタスクの出力をインポートするために使用されます。

Pipeline で条件判断を使用する場合は、次のように when キーワードを使用することもできます。

 タスク:
 - 名前: デプロイ先: dev
 いつ：
 - 入力: "$(params.branch)"
 演算子: in
 値: [ "dev" ]
 タスク参照:
 名前: デプロイ先: dev
 ---
 タスク:
 - 名前: デプロイ- テスト​
 いつ：
 - 入力: "$(params.branch)"
 演算子: in
 値: [ "テスト" ]
 タスク参照:
 名前: デプロイからテスト​

注意: when と condition はタスク内で同時に使用できません。同時に使用すると無効とみなされます。

when と同じ効果を持つ別のキーワードとして condition があります。

条件の機能は、いくつかの条件でタスクを保護することです。条件が満たされた場合にのみタスクが実行されます。タスクが実行される前に、すべての条件が判断されます。すべての条件が成功した場合にのみタスクが実行され、そうでない場合は許可されません。

単純な条件文は次のように定義されます。

 タスク:
 - 名前: デプロイ- if - ブランチ- is - マスター
条件：
 - conditionRef : is - マスター- ブランチ
パラメータ:
 - 名前: 支店名- 名前
値: 私の- 値
タスク参照:
 名前: デプロイ

もちろん、条件付き制約は現在のタスクにのみ適用されます。他のタスクが現在のタスクの影響を受けない場合、それらのタスクは制約されません。

詳しい使用方法については、(https://tekton.dev/docs/pipelines/pipelines/) を参照してください。

パイプライン実行

パイプラインはタスクと同じです。パイプラインを定義するだけでは、それが実行されるわけではありません。パイプラインは、実際の実行を完了するために PipelineRun を使用する必要があります。

PipelineRun は、Pipeline で定義されたタスクに対応する TaskRun を自動的に作成します。

以下は単純な PipelineRun 定義です。

 apiバージョン: tekton.dev/v1beta1
 種類: PipelineRun
 メタデータ:
 名前: ビルドとプッシュイメージ​ ​
 仕様:
 パイプライン参照:
 名前: ビルドとプッシュイメージ​ ​
 リソース：
 - 名前: リポジトリ
リソース参照:
 名前: デモ- git
 - 名前: 組み込みイメージ
リソース参照:
 名前: 港- イメージ

このうち、 spec.pipelineRef は定義された Pipeline を関連付けるために使用され、 spec.resources は Pipeline にパラメータを渡すために使用されます。

上記の repo およびbuiltImage パラメータは、PipelineResources を通じて定義する必要があります。ただし、新しいバージョンでは、次のように resourceSpec を通じて定義することもできます。

 apiバージョン: tekton.dev/v1beta1
 種類: PipelineRun
 メタデータ:
 名前: ビルドとプッシュイメージ​ ​
 仕様:
 パイプライン参照:
 名前: ビルドとプッシュイメージ​ ​
 リソース：
 - 名前: リポジトリ
リソース仕様:
 タイプ: git
 パラメータ:
 - 名前: URL
 値: https://gitee.com/coolops/springboot-helloworld.git
 - 名前: 組み込みイメージ
リソース仕様:
 タイプ: 画像
パラメータ:
 - 名前: URL
 値: レジストリ。 cn - 杭州。 アリユンクス。 com / coolops / helloworld : 最新

条件

Condition は Pipeline で条件判断を行うために使用されますが、新しいバージョンでは非推奨となり、上記で紹介した に置き換えられます。ここでは詳しく紹介しません。

認証管理

上記では主要な CRD とその使い方を紹介しましたが、コードリポジトリのパスワードをどのように管理するかなど、他に注意すべき点はありますか?イメージリポジトリのパスワードを管理するにはどうすればよいですか?これらはすべて実際の仕事で必要になるからです。

Tekton は、PipelineRun で ServiceAccount を指定してこれを実行します。ただし、Tekton では、定義された各 Secret に対応するアノテーションを指定する必要があります。現在サポートされている注釈は次の 2 つです。

• Git: tekton.dev/git-**0:** https**:**//github.com。
• Docker: tekton.dev/docker-**0:** https**:**//gcr.io。

現在、これら 2 つのタイプはそれぞれ次のタイプをサポートしています。

Tekton はこれらの秘密をどのように活用するのでしょうか?

これらの Secrets を使用するために、Tekton は Pod をインスタンス化するときに資格情報の初期化を実行することがわかります。 Tekton は、特定のタスク ステップを実行する前に、特定のシークレットを /tekton/creds ディレクトリに関連付けて集約します。

以下では、イメージリポジトリを例に、具体的な操作をいくつか実行してみましょう。

（１）秘密を作成する：

 APIバージョン: v1
 種類: 秘密
メタデータ:
 名前: docker - レジストリ- シークレット
注釈:
 tekton .dev / docker - 0 : https://gcr.io #下記に説明
タイプ: kubernetes .io / basic - auth
 文字列データ:
 ユーザー名: < クリアテキストのユーザー名>
 パスワード: < クリアテキストパスワード>

このうち、tekton.dev/docker-0: [https://gcr.io](https://gcr.io) は対応する倉庫アドレスを指定するために使用されます。

（２）セバアカウントを作成する

 APIバージョン: v1
 種類: サービスアカウント
メタデータ:
 名前: docker - レジストリ- sa
 秘密:
 - 名前: docker - レジストリ- シークレット

（３）PipelineRunでの参照：

 apiバージョン: tekton.dev/v1beta1
 種類: PipelineRun
 メタデータ:
 名前: デモ- パイプライン
名前空間: デフォルト
仕様:
 サービスアカウント名: docker - レジストリ- sa
 パイプライン参照:
 名前: デモ- パイプライン

複数のサービス アカウントを同時に使用する必要がある場合はどうすればよいですか?たとえば、完成したパイプラインでは、コードをプルするときに Git アカウントを使用し、イメージをプッシュするときにイメージ リポジトリ アカウントを使用します。

現時点では、serviceAccountName は使用できなくなり、serviceAccountNames を使用する必要があります。 serviceAccountNames は、以下に示すように、タスクに関連付けられた特定のサービス アカウントを指定するために使用できるリストです。

 apiバージョン: tekton.dev/v1beta1
 種類: PipelineRun
 メタデータ:
 名前: デモ- パイプライン
名前空間: デフォルト
仕様:
 サービスアカウント名:
 - タスク名: ビルド- アプリ
サービスアカウント名: gitlab - sa
 -taskName : プッシュ- イメージ
サービスアカウント名: docker - レジストリ- sa
 パイプライン参照:
 名前: デモ- パイプライン

基本的なリソースと紹介はここにあります。この記事を理解すれば、簡単なパイプラインを書くことは問題ないはずです。以降の記事では具体的な実践方法を紹介します。