Tekton を使用したクラウドネイティブ CI/CD

[[399353]]

この記事はWeChat公式アカウント「Xintai Cloud Service」から転載し、張俊が翻訳したものです。この記事を転載する場合は、Xintai Cloud Service公式アカウントまでご連絡ください。

本格的なプロジェクトには必ず CI/CD が必要であることは誰もが知っていますし、その理由を説明する必要もないと思います。ただし、CI/CD を構築する場所を決定する際に選択できるツール、プラットフォーム、ソリューションは多数あります。 Jenkins、Travis、CircleCI、Bamboo などから選択できますが、Kubernetes 上で実行されるクラウドネイティブ アプリケーションの CI/CD を構築する場合は、適切なツールを使用してクラウドネイティブ CI/CD も実行するのが合理的です。

Kubernetes 上で CI/CD をネイティブに実行できるソリューションの 1 つが Tekton です。そこでこの記事では、Kubernetes 上でクラウドネイティブ CI/CD を実現する旅を始めるために、まず Tekton を紹介、インストール、カスタマイズすることから始めて、Tekton を使用した CI/CD の構築に関するシリーズを開始します。

TL;DR: Tekton で CI/CD を開始するために必要なすべてのリソース、スクリプト、ファイルは、https://github.com/MartinHeinz/tekton-kickstarter にあります。

タイトルと紹介文が示すように、Tekton はクラウドネイティブの CI/CD ツールです。これはもともと Google で開発され、Knative Pipelines として知られています。これは、パイプラインやタスクなどのカスタム リソース (crd) のセットとして Kubernetes 上で実行され、そのライフサイクルは Tekton のコントローラーによって管理されます。 Kubernetes 上でネイティブに実行されるため、Kubernetes 上にデプロイされたあらゆるアプリケーションやリソースの管理、構築、デプロイに最適です。

これは、Kubernetes ワークロードの管理に適していることを示唆していますが、他のより一般的なツールを使用しないのはなぜでしょうか?

Jenkins、Travis、Bamboo などの一般的に使用される CI/CD ソリューションは、Kubernetes 上で実行するように構築されていないか、Kubernetes との適切な統合が欠けています。これにより、CI/CD ツール自体のデプロイ、保守、管理が困難になり、煩わしくなります。また、それを使用して Kubernetes ネイティブ アプリケーションをデプロイすることも困難になります。

一方、Kubernetes Operator は他のすべてのコンテナ化されたアプリケーションと並んで存在し、各 Tekton Pipeline は旧式の Pod や Deployment と同じ方法で管理される別の Kubernetes リソースであるため、Tekton は非常に簡単にデプロイできます。

これにより、Tekton は GitOps プラクティスともうまく連携します。すべてのパイプラインと構成を取得して Git で管理できるためです。これは、前述のツールの少なくとも 1 つでは不可能です。リソースの消費についても同様です。Tekton のデプロイメント全体がほんの数個のポッドであることを考慮すると、他の CI/CD ツールと比較して、パイプラインが実行されていないときのメモリと CPU の消費量は非常に少なくなります。

そうは言っても、すべてのワークロードを Kubernetes 上で実行している場合は、CI/CD に Kubernetes ネイティブのツールを使用するのが最善であることは明らかです。 Tekton が唯一の選択肢でしょうか?いいえ、もちろん、他のツールを使用することもできます。その 1 つが JenkinsX です。これは、Kubernetes を使用した継続的デリバリーをローカルで開始するための独自の方法です。

代替手段を強く望んでいない場合には生活を楽にしてくれるツールが多数含まれていますが、技術スタックをカスタマイズしたい場合には煩わしいこともあります。ただし、JenkinsX はバックグラウンドで Tekton を引き続き使用するため、JenkinsX が提供する他のすべてのコンポーネントも必要かどうかを判断する前に、Tekton の使い方を学習したほうがよいでしょう。

もう 1 つの選択肢は、長い間使用されているマルチクラウド ソリューションである Spinnaker です。プラグインを使用してさまざまなプロバイダーと統合しますが、その 1 つが Kubernetes です。ただし、これはビルド エンジンではありません。コードのテスト、アプリケーション イメージのビルド、レジストリへのプッシュを行うツールは提供されていないため、これらのタスクには別の CI ツールが必要です。

それでは、Tekton が何で構成されているかを詳しく見てみましょう。Tekton のコアは、TaskRuns と PipelineRuns の青写真として機能する、Tasks と PipelineRuns であるいくつかの CustomResourceDefinitions (CRD) で構成されています。これら 4 つ (および廃止予定のものや現時点では関連のない他のいくつか) があれば、いくつかのパイプラインとタスクの実行を開始するのに十分です。

ただし、ほとんどのセットアップではビルド、デプロイメント、および何らかのイベントによってトリガーされるパイプラインが必要であることを考慮すると、通常はこれでは不十分です。そのため、EventListener、TriggerBinding、TriggerTemplate などの追加リソースを提供する Tekton トリガーもインストールしました。これら 3 つのリソースは、特定のイベント (GitHub の Webhook、CloudEvents、cron ジョブによって送信されるイベントなど) をリッスンし、特定のパイプラインを開始する方法を提供します。

最後の（そして非常にオプションのコンポーネント）は Tekton ダッシュボードです。これは非常にシンプルな GUI ですが、すべての CRD（タスク、パイプライン、トリガーを含む）を検査するのに非常に便利なツールです。また、検索とフィルタリングも可能で、TaskRun や PipelineRun を探すときに役立ちます。また、既存のタスクとパイプラインから TaskRun と PipelineRun を作成することもできます。これらすべての部分は、前述の CRD のライフサイクルを担当するコントローラー デプロイメントとポッドによって管理されます。

##設定

Tekton は複数のコンポーネントで構成されているため、インストールは多少複雑になる可能性があり、さまざまな方法で実行できます。通常は、少なくともパイプラインとトリガーをインストールする必要があります。最も明白な方法は、生の Kubernetes マニフェストを使用してインストールすることですが、より簡単な方法として、すべての部分がすでに含まれている OperatorHub から Tekton Operator をインストールすることもできます。

どのインストール方法の前提条件としても、当然ながらクラスターが必要です。ここでは、ローカル パイプラインの開発に KinD (Docker 内の Kubernetes) を使用します。 Tekton Triggers イベント リスナーにアクセスできるようにするには、Ingress コントローラーをデプロイし、ポート 80/443 を公開する必要があるため、KinD には次のカスタム構成を使用します。

 # 種類-tekton.yaml
種類: クラスター
APIバージョン: kind.x-k8s.io/v1alpha4
ノード:
 - 役割: コントロールプレーン
  kubeadmConfigパッチ:
  - |
    種類: InitConfiguration
    ノード登録:
      kubelet 追加引数:
        ノードラベル: "ingress-ready=true"  
  追加ポートマッピング:
  - コンテナポート: 80
    ホストポート: 80
    プロトコル: TCP
  - コンテナポート: 443
    ホストポート: 443

次のコマンドを使用してクラスターを作成できます。

 ~ $ kindクラスターを作成します--name tekton --image=kindest/node:v1.20.2 --config=kind-tekton.yaml  
 ~ $ kubectl クラスター情報--context kind-tekton  
 ~ $ kubectl config set -context kind-tekton
 ~ $ kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/静的/provider/kind/deploy.yaml
 ~ $ kubectl wait --namespace ingress-nginx --for=condition=ready ポッド --selector=app.kubernetes.io/component=controller --timeout=90s  

さて、Tekton パイプラインとトリガーの実際の展開についてですが、Tekton Operator 経由でインストールする方法について言及しましたが、これはすべてを事前に構成して起動して実行するための最も迅速で最良の方法のように思えますが、このオペレーターには何も含まれていません (執筆時点では)。実際のドキュメントはないので、仕組みの説明を見つけるにはかなりの調査が必要になりますが、私にとってはそれほど大きな問題ではありませんでした。しかし、ここでの本当の問題は、OperatorHub の Operator が最新ではなく、現在のビルド/イメージが見つからないため、多かれ少なかれ役に立たないことです。

Tekton Operator がより成熟した時点でこの状況は変わると確信しています (そのため、リポジトリに注目してください)。ただし、それまでは他のインストール オプションが機能するはずです。 OpenShift 上で実行している場合は、Red Hat Pipeline Operator というオプションを使用できます。これも Kubernetes Operator ですが、この場合は Red Hat によってキュレートされ、OpenShift 用にカスタマイズされています。 Web コンソールで数回クリックするだけでインストールできるので、OpenShift クラスターにアクセスできる場合はぜひ試してみてください。

この機能を使用することの欠点の 1 つは、リリース サイクルが遅いため、最新バージョンの Tekton を使用する必要があることです。 OpenShift が選択肢にない場合、または Kubernetes 上で実行したいだけの場合は、元のマニフェストを使用してインストールするだけで十分です。方法は次のとおりです。

 ~ $ kubectl apply -f https://storage.googleapis.com/tekton-releases/pipeline/latest/release.yaml # パイプラインをデプロイする
~ $ kubectl apply -f https://storage.googleapis.com/tekton-releases/triggers/latest/release.yaml # トリガーをデプロイする
~ $ kubectl get svc、deploy --namespace tekton-pipelines --selector=app.kubernetes.io/part-of=tekton-pipelines  
名前タイプ クラスター IP 外部 IP ポート 年齢
service/tekton-pipelines-controller ClusterIP 10.106.114.94 <なし> 9090/TCP、8080/TCP 2分13秒
service/tekton-pipelines-webhook ClusterIP 10.105.247.0 <なし> 9090/TCP、8008/TCP、443/TCP、8080/TCP 2分13秒
  
名前準備完了最新利用可能年齢
デプロイメント.apps/tekton-pipelines-controller 1/1 1 1 2分13秒
デプロイメント.apps/tekton-pipelines-webhook 1/1 1 1 2分13秒

このインストールにTektonダッシュボードも含める場合は、もう1セットのマニフェストを適用する必要があります。

 ~ $ kubectl apply -f https://storage.googleapis.com/tekton-releases/dashboard/latest/tekton-dashboard-release.yaml # ダッシュボードをデプロイする
~ $ kubectl get svc,deploy -n tekton-pipelines --selector=app=tekton-dashboard  
名前タイプ クラスター IP 外部 IP ポート 年齢
service/tekton-dashboard ClusterIP 10.111.144.87 <なし> 9097/TCP 25秒
  
名前準備完了最新利用可能年齢
デプロイメント.apps/tekton-dashboard 1/1 1 1 25秒

これに加えて、ダッシュボードにアクセスするための追加のエントリ ポイントが必要です。

 APIバージョン: networking.k8s.io/v1
種類: イングレス
メタデータ:
名前: ダッシュボード
  名前空間: tekton-pipelines
  注釈:
    nginx.ingress.kubernetes.io/rewrite-target: '/$2'  
仕様:
  ルール:
    - http:
        パス:
          - パス: /dashboard(/|$)(.*)
            パスタイプ: プレフィックス
            バックエンド:
              サービス：
名前: tekton-dashboard
                ポート：
                  番号: 9097

以前適用されたダッシュボード リソースは、デフォルトで tekton-pipelines 名前空間に作成され、上記の Ingress で参照されている値であるポート 9097 を使用する tekton-dashboard という名前のサービスが含まれていました。この Ingress には、ダッシュボードを / ではなく /dashboard/... パスに表示する書き換えルールもあります。

これは、イベント リスナー Webhook (後で説明するトピック) にデフォルトの / (ルート) パスを使用するためです。ダッシュボードが実際にアクティブで、すべてが実行されていることを確認するには、localhost/dashboard/ を参照します (KinD を使用していると仮定)。次のような内容が表示されます (実際のパイプラインは除きます)。

このセットアップに多大な労力がかかると思われる場合は、tekton-kickstarter リポジトリを取得して make を実行することで、1 分以内にすべてを準備できます。デプロイが完了すると、すべての（非常に）基本的な作業が完了するので、CLI を調べて、実際にコマンドどおりにデプロイされたかどうかを確認しましょう...

カスタム リソースの調査 上記の手順を実行した場合 (またはスタートアップ リポジトリから make ターゲットを使用した場合)、クラスターに多くの新しいリソースが追加されているはずです。 Tekton のすべてのコンポーネントは tekton-pipelines 名前空間に配置され、次のものを含める必要があります。

 ~ $ kubectl get deploy、service、ingress、hpa -n tekton-pipelines
名前準備完了最新利用可能年齢
デプロイメント.apps/tekton-dashboard 1/1 1 1 2分24秒
デプロイメント.apps/tekton-pipelines-controller 1/1 1 1 6分57秒
デプロイメント.apps/tekton-pipelines-webhook 1/1 1 1 6分57秒
デプロイメント.apps/tekton-triggers-controller 1/1 1 1 6分56秒
デプロイメント.apps/tekton-triggers-core-interceptors 1/1 1 1 6分56秒
デプロイメント.apps/tekton-triggers-webhook 1/1 1 1 6分56秒
  
名前タイプ クラスター IP 外部 IP ポート 年齢
service/tekton-dashboard ClusterIP 10.108.143.42 <なし> 9097/TCP 2分24秒
service/tekton-pipelines-controller ClusterIP 10.98.218.218 <なし> 9090/TCP、8080/TCP 6分57秒
service/tekton-pipelines-webhook ClusterIP 10.101.192.94 <なし> 9090/TCP、8008/TCP、443/TCP、8080/TCP 6分57秒
service/tekton-triggers-controller ClusterIP 10.98.189.205 <なし> 9090/TCP 6分56秒
service/tekton-triggers-core-interceptors ClusterIP 10.110.47.172 <なし> 80/TCP 6分56秒
service/tekton-triggers-webhook ClusterIP 10.111.209.100 <なし> 443/TCP 6分56秒
  
名前クラス ホスト アドレス ポート 年齢
ingress.networking.k8s.io/dashboard <なし> * localhost 80 2分24秒
  
名前参照 ターゲット MINPODS MAXPODS レプリカ 年齢
hpa.autoscaling/tekton-pipelines-webhook デプロイメント/tekton-pipelines-webhook <不明>/100% 1 5 1 6分57秒

これらには、すべてのデプロイメント、サービス、およびオートスケーラーが含まれており、リクエスト量が多い場合に可用性を向上させるのに役立ちます。 HA が必要な場合は、Tekton を HA 用に構成する方法を説明しているドキュメント セクションも参照してください。

上記のリソースに加えて、デフォルトの名前空間にはイベント リスナーとそのリソースも見つかります。コア コンポーネントと名前空間を共有できますが、このように分割することで、パイプラインとその Webhook を、使用されるアプリケーション/プロジェクトに応じて分割することができます。

 kubectl get deploy、サービス、イングレス、hpa -n デフォルト
名前 準備完了 最新 利用可能 年齢
deployment.apps/el-cron-listener 1/1 1 1 8分40秒
デプロイメント.apps/el-http-イベントリスナー 1/1 1 1 8分40秒
  
名前 タイプ クラスター IP 外部 IP ポート 年齢
service/el-cron-listener ClusterIP 10.100.238.60 <なし> 8080/TCP 8分40秒
service/el-http-event-listener ClusterIP 10.98.88.164 <なし> 8080/TCP 8分40秒
  
名前 クラス ホスト アドレス ポート 年齢
ingress.networking.k8s.io/http-listener <なし> * ローカルホスト 80 8分40秒

Tekton のインストールには、すべてのタスク、パイプライン、トリガーを管理するために使用されるいくつかの CRD も付属しています。

 kubectl で crd を取得します | grep テクトン
クラスタータスク.tekton.dev 2021-02-27T20:23:35Z
クラスタートリガーバインディング.triggers.tekton.dev 2021-02-27T20:23:36Z
条件.tekton.dev 2021-02-27T20:23:35Z
イベントリスナー.triggers.tekton.dev 2021-02-27T20:23:36Z
拡張機能.dashboard.tekton.dev 2021-02-27T20:28:08Z
パイプラインリソース.tekton.dev 2021-02-27T20:23:35Z
パイプライン実行.tekton.dev 2021-02-27T20:23:35Z
パイプライン.tekton.dev 2021-02-27T20:23:35Z
 2021-02-27T20:23:35Z を実行します
タスクランス.tekton.dev 2021-02-27T20:23:35Z
タスク.tekton.dev 2021-02-27T20:23:35Z
トリガーバインディング.triggers.tekton.dev 2021-02-27T20:23:36Z
トリガー.triggers.tekton.dev 2021-02-27T20:23:36Z
トリガーテンプレート.triggers.tekton.dev 2021-02-27T20:23:36Z

これらの CRD を使用すると、kubectl get または kubectl describe を使用してタスクとパイプラインを一覧表示および検査できます。 Kubernetes のすべてのユーザーにとって、リソースを操作する自然な方法は kubectl を使用することですが、Tekton には独自の CLI ツール tkn もあります。こちらのリリースページからダウンロードできます。この CLI を使用すると、CRD を処理せずに Tekton リソースと対話できます。たとえば、パイプを一覧表示したり検査したりできます。

 ~ $ tkn パイプラインリスト
名前年齢最終ランニング開始日 所要時間 ステータス
database -backup 12時間前 job-qxcwc 39分前 8分 失敗
12 時間前にデプロイ--- --- --- ---   
  
 ~ $ tknパイプラインの説明をデプロイする
# ... 長くて冗長な出力 

リソースを検査するだけでなく、taskruns または PipelineRuns を起動して、個々のポッドを探すことなくログを読み取ることもできます。

 ~ $ tkn タスク開始 send- to -webhook-slack
 ?タイプ `string`のパラメータ `webhook-secret`の値ですか? slackウェブフック
? `string` 型のパラメータ `message`の値ですか?こんにちは！
 TaskRun が開始されました: send- to -webhook-slack-run-d5sxv 
  
で 注文  TaskRun の進行状況を追跡するには:
 tkn taskrun ログ送信先-webhook-slack-run-d5sxv -f -nデフォルト  
  
 ~ $ tkn taskrun ログ送信先-webhook-slack-run-d5sxv -f -nデフォルト 
 [投稿] % 合計 % 受信 % 転送 平均速度時間    時間     時間  現在 
 [投稿] ダウンロード アップロード 合計 消費残り速度
100 23 0 0 100 23 0 111 --:--:-- --:--:-- --:--:-- 111  

上記のように、最初にパラメータを指定しなかった場合でも、パラメータの入力を求めるプロンプトが表示されます。

しかし、本当に気になるのは、この CLI ツールが kubectl と比べて逆の順序で引数を使用することです。 kubectl は kubectl、tkn は tkn という順番になっており、非常に便利なツールです。

※この記事はhttps://martinheinz.dev/blog/45より翻訳したものです。