クラウドネイティブ CI/CD フレームワーク Tekton の初体験

[[404558]]

Tekton は、非常に強力で柔軟な CI/CD オープンソースクラウドネイティブフレームワークです。 Tekton の前身は、Knative プロジェクトのビルドパイプラインプロジェクトでした。このプロジェクトは、ビルドモジュールにパイプライン機能を追加するために設計されました。しかし、Knative ビルドモジュールにさまざまな機能が追加されるにつれて、ビルドモジュールは一般的な CI/CD システムに似てきました。そのため、ビルドパイプラインは単純に Knative から分離され、現在の Tekton になりました。それ以来、Tekton はフル機能の標準化されたクラウドネイティブ CI/CD ソリューションの提供に取り組んできました。

Tekton は CI/CD システムに多くの利点をもたらします。

カスタマイズ可能: Tekton は完全にカスタマイズ可能で柔軟性が高く、開発者がさまざまなシナリオで使用できるように、非常に詳細なビルディングブロックのカタログを定義できます。
再利用可能: Tekton は完全に移植可能で、誰でも特定のパイプラインを使い、その構成要素を再利用できるため、開発者は「車輪の再発明」をすることなく複雑なパイプラインを素早く構築できます。
拡張可能: Tekton Catalog は、Tekton ビルディングブロックのコミュニティ主導のリポジトリです。 Tekton カタログで定義されたコンポーネントを使用して、新しいパイプラインをすばやく作成し、既存のパイプラインを拡張できます。
標準化: Tekton は Kubernetes クラスターの拡張機能としてインストールおよび実行され、確立された Kubernetes リソースモデルを使用し、Tekton ワークロードは Kubernetes Pod 内で実行されます。
スケーラビリティ:ワークロード容量を増やすには、クラスターに新しいノードを追加するだけで、リソース割り当てを再定義したりパイプラインに他の変更を加えたりすることなく、Tekton がクラスターに合わせて拡張されます。

コンポーネント

Tekton はいくつかのコンポーネントで構成されています:

Tekton Pipelines は Tekton の基盤であり、CI/CD パイプラインを組み立てるために使用できるビルディングブロックとして Kubernetes CRD のセットを定義します。
Tekton Triggers を使用すると、イベントに基づいてパイプラインをインスタンス化できます。たとえば、PR が GitHub リポジトリにマージされるたびにパイプラインインスタンスをトリガーしてビルドできます。
Tekton CLI は、Kubernetes CLI 上に構築され、Tekton と対話できる tkn と呼ばれるコマンドラインインターフェースを提供します。
Tekton Dashboard は、パイプラインの実行に関するオンライン情報を提供する、Tekton Pipelines 用の Web ベースのグラフィカルインターフェイスです。
Tekton カタログは、コミュニティによって提供され、独自のパイプラインで直接使用できる高品質の Tekton ビルディングブロック (タスク、パイプラインなど) のリポジトリです。
Tekton Hub は、Tekton カタログにアクセスするための Web ベースのグラフィカルインターフェイスツールです。
Tekton Operator は、Kubernetes クラスター上で Tekton プロジェクトをインストール、更新、削除できる Kubernetes Operator です。

インストール

Tekton のインストールは非常に簡単です。以下に示すように、tektoncd/pipeline の GitHub リポジトリにある release.yaml ファイルから直接インストールできます。

 kubectl apply --filename https://storage.googleapis.com/tekton-releases/pipeline/previous/v0.24.1/release.yaml

公式イメージはgcrイメージなので、通常では入手できません。何らかの理由でクラスターがイメージを取得できない場合は、次のリソースマニフェストファイルを使用できます。イメージを Docker Hub のイメージに置き換えました:

 kubectl apply -f http://my-oss-testing.oss-cn-beijing.aliyuncs.com/k8s/tekton/release.yaml

上記のリソースマニフェストファイルがインストールされると、tekton-pipelines という名前の名前空間が作成されます。この名前空間には、Tekton 関連のリソースオブジェクトが多数存在します。この名前空間内の Pod を表示し、それらが実行状態であることを確認することで、インストールが成功したかどうかを確認できます。

 $ kubectl ポッドを取得 -n tekton-pipelines
名前準備完了 ステータス 再起動 年齢
tekton-pipelines-controller-795dd94d96-lkbxt 1/1 実行中 0 92秒
tekton-pipelines-webhook-6b8964445d-mp4k6 1/1 実行中 0 92秒

Tekton をインストールした後、CLI ツールをインストールするかどうかも選択できます。これらのリソースを管理するには、kubectl よりも Tekton が提供するコマンドラインツールの方が便利な場合があります。もちろん、これは必須ではありません。私は Mac システムを使用しているので、一般的に使用されている Homebrew ツールを使用してインストールできます。

ブリュータップ tektoncd/ツール
brew install tektoncd/tools/tektoncd-cli

インストールが完了したら、次のコマンドを実行して、CLI が正常にインストールされたかどうかを確認できます。

 $ tkn バージョン
クライアントバージョン: 0.15.0
パイプラインバージョン: v0.24.1
ダッシュボードバージョン: v0.17.0

tknReleases ページからインストールパッケージをダウンロードすることもできます。ファイルをダウンロードしたら、PATH に解凍します。

 # YOUR-DOWNLOADED-FILE を自分のファイル パスに置き換えます。
 sudo tar xvzf ダウンロードしたファイル -C /usr/ local /bin/ tkn

さらに、Tekton が提供するダッシュボードをインストールすることもできます。ダッシュボードを使用して、Tekton のタスク構築プロセス全体を表示できます。直接インストールするには、次のコマンドを実行するだけです。

 kubectl を適用 -f http://my-oss-testing.oss-cn-beijing.aliyuncs.com/k8s/tekton/dashboard.yaml

インストールが完了すると、ダッシュボードのサービスの NodePort を通じてアプリケーションにアクセスできるようになります。

コンセプト

Tekton は、パイプラインの定義に使用できる Kubernetes 用のさまざまな CRD リソースオブジェクトを提供します。

主に以下のリソースオブジェクトがあります。

タスク: コマンドを実行するための一連の順序付けられたステップを表します。タスクでは、コードのコンパイル、イメージのビルド、イメージのプッシュなど、一連のステップを定義できます。各ステップは実際には Pod によって実行されます。
パイプライン: 順序付けられたタスクのセット。パイプライン内のタスクは、以前に実行されたタスクの出力を入力として使用できます。 1 つ以上のタスク、PipelineResources、およびさまざまな定義パラメータのコレクションを表します。
TaskRun : Task はテンプレートのみを定義しますが、TaskRun は実際の実行を表します。もちろん、TaskRun を手動で作成することもできます。 TaskRun が作成されると、Task で記述されたビルドタスクが自動的にトリガーされます。
PipelineRun : Task と TaskRun の関係と同様に、PipelineRun も実際に実行されているパイプラインを表します。 PipelineRun CRD インスタンスが Kubernetes に送信されると、パイプラインのビルドもトリガーされます。
ClusterTask : 単一の名前空間ではなく、クラスター全体をカバーするタスク。これが Task との最大の違いであり、残りは基本的に同じです。
PipelineResource : GitHub 上のソースコードなどのパイプライン入力リソース、またはコンテナイメージやビルドによって生成された jar パッケージなどのパイプライン出力リソースを表します。

各タスクは独自の Kubernetes Pod で実行されるため、デフォルトではパイプライン内のタスクはデータを共有しません。タスク間でデータを共有するには、各タスクの出力を次のタスクで使用できるようにし、以前に実行されたタスクの出力を入力として取得するように、各タスクを明示的に構成する必要があります。

例

Tekton を使用すると、CI/CD ワークフロー内の各操作はステップになり、指定されたコンテナイメージを使用して実行されます。ステップはタスクに編成され、クラスター内で Kubernetes ポッドとして実行されます。タスクはさらにパイプラインに編成され、複数のタスクの実行順序を制御できます。

ここでは、シンプルな Golang アプリケーションを使用します。アプリケーションコード、テスト、Dockerfile ファイルは、リポジトリ https://github.com/cnych/tekton-demo で入手できます。

最初のタスクは、テスト用にアプリケーションコードを複製することです。タスクを作成するには、Kubernetes で定義されたタスク CRD オブジェクトを使用する必要があります。ここでは、以下に示すように、次の内容のリソースファイルを作成します。

 # タスクテスト.yaml
 apiバージョン: tekton.dev/v1beta1
種類: タスク
メタデータ:
名前: テスト
仕様:
  リソース：
    入力:
      -名前: リポジトリ
        タイプ: git
  手順:
    -名前: 実行テスト
      イメージ: golang:1.14-alpine
      作業ディレクトリ: /workspace/repo
      コマンド: [ 'go' ]
      引数: [ 'テスト' ]

その中で、リソースはタスクで定義されたステップに必要な入力コンテンツを定義します。ここで、このステップでは、go test コマンドの入力として Git リポジトリをクローンする必要があります。現在、git、pullRequest、イメージ、クラスター、ストレージ、クラウドイベントなどのリソースをサポートしています。

Tekton には組み込みの git リソースタイプがあり、コードリポジトリを /workspace/$input_name ディレクトリに自動的に複製します。ここでの入力は repo という名前なので、コードは /workspace/repo ディレクトリに複製されます。

次に、次の手順を使用して、テストコマンドを実行する手順を定義します。ここでは、コードのルートディレクトリで go test コマンドを直接実行できます。コマンドとパラメータは別々に定義する必要があることに注意してください。

定義が完了したら、kubectl を使用してタスクを直接作成します。

 $ kubectl apply -f タスクテスト.yaml
 task.tekton.dev/test が作成されました

これで新しいタスクが定義されましたが、タスクはすぐには実行されません。これを参照し、必要な入力データをすべて提供するには、TaskRun を作成する必要があります。もちろん、tkn コマンドを使用してタスクを直接開始することもできます。タスクを開始するために必要なリソースオブジェクトを取得するには、次のコマンドを使用できます。

 $ tkn タスク開始テスト--dry-run  
名前空間に「git」タイプのパイプライン リソースが見つかりません: default  
パイプライン リソース「repo」に新しい「git」リソースを作成してください 
 ?名前を入力してください パイプラインリソースの場合: demo-git
 ? URLの値を入力してください: https://github.com/cnych/tekton-demo
 ?リビジョンの値を入力してください: マスター
新しい git リソース「demo-git」が作成されました
apiバージョン: tekton.dev/v1beta1
種類: タスク実行
メタデータ:
  作成タイムスタンプ: null  
  生成名: テスト実行
  名前空間:デフォルト 
仕様:
  リソース：
    入力:
    -名前: リポジトリ
      リソース参照:
名前: デモgit
  サービスアカウント名: ""  
  タスク参照:
名前: テスト
状態：
  ポッド名: ""

ここでの Task タスクでは入力として git コードリポジトリが必要なので、入力情報を定義するには PipelineResource オブジェクトが必要です。上記のコマンドは、以下に示すように、demo-git という名前の PipelineResource リソースオブジェクトを自動的に作成します。

 $ kubectl パイプラインリソースを取得する
名前年齢
デモ-git 3分37秒
$ kubectl パイプラインリソースの取得 demo-git -o yaml
 apiバージョン: tekton.dev/v1alpha1
種類: パイプラインリソース
メタデータ:
名前: デモgit
  名前空間:デフォルト 
  ......
仕様:
  パラメータ:
  -名前: URL
    値: https://github.com/cnych/tekton-demo
  -名前: リビジョン
    値: マスター
  タイプ: git

PipelineResource の作成方法がわからない場合は、上記の方法を参照して作成できます。もちろん、タスクを実際に実行するには、最後に TaskRun オブジェクトを作成する必要があります。上記の tkn task start コマンドは、対応する TaskRun リソースも出力し、その内容を taskrun.yaml ファイルに追加します。

 #タスク実行.yaml
 apiバージョン: tekton.dev/v1beta1
種類: タスク実行
メタデータ:
名前: テストラン
仕様:
  リソース：
    入力:
      -名前: リポジトリ
        リソース参照:
名前: デモgit
  タスク参照:
名前: テスト

ここで、taskRef は入力として上記で定義された Task と git リポジトリを参照し、resourceRef も上記で定義された PipelineResource リソースオブジェクトを参照します。このリソースオブジェクトを作成したら、実行を開始します。

 $ kubectl を適用 -f タスク実行.yaml
 taskrun.tekton.dev/testrun が作成されました

Tekton はタスクの実行を開始します。最後の TaskRun のログを表示するには、次の tkn コマンドを使用します。

 tkn タスク実行ログ--last -f

さらに、TaskRun リソースオブジェクトのステータスを表示することで、ビルドのステータスを確認することもできます。

 $ kubectl タスク実行を取得します
名前成功 理由 開始時間 完了時間
テスト実行 不明 保留中 21秒
$ kubectl ポッドを取得する
名前準備完了 ステータス 再起動 年齢
testrun-pod-l629c 0/2 初期化:1/2 0 59s
 $ kubectl 説明ポッド testrun-pod-l629c
名前: testrun-pod-l629c
名前空間:デフォルト 
 ......
イベント:
  タイプ 理由 年齢送信元 メッセージ
---- ------ ---- ---- -------  
  通常スケジュール 2 分 53 秒デフォルト-schedulerデフォルトの/testrun-pod-l629cをnode1に正常に割り当てました
  通常のプル 2m52s kubelet、node1 イメージ"cnych/tekton-distroless-base:v0.24.1"のプル 
  通常プル 2 分 27 秒 kubelet、node1 イメージ「cnych/tekton-distroless-base:v0.24.1」を正常にプルしました  24.910571044秒後
  正常 2分27秒でkubelet、node1が作成されました コンテナworking-dir-initializerが作成されました
  正常に開始しました 2分27秒 kubelet、node1 コンテナ working-dir-initializer を開始しました
  通常のプル 2 分 27 秒 kubelet、node1 イメージ「cnych/tekton-entrypoint:v0.24.1」をプルしています 
  2m kubelet、node1 を正常にプルしました。イメージ「cnych/tekton-entrypoint:v0.24.1」を正常にプルしました。   27.120230223秒後
  通常 2m kubelet、node1 を作成しました コンテナ place-tools を作成しました
  正常 2m kubelet、node1 コンテナ place-tools を開始
  通常のプル 119s kubelet、node1 イメージ"cnych/tekton-git-init:v0.24.1"のプル 
  82 秒の kubelet、node1 を正常にプルしました。イメージ「cnych/tekton-git-init:v0.24.1」がプルされました。   36.318235738秒後
  正常 82s kubelet、node1 コンテナ step-git-source-repo-jg7vz を作成
  正常に開始しました 82 秒 kubelet、node1 コンテナを開始しました step-git-source-repo-jg7vz
  通常のプル 82s kubelet、node1 イメージ"golang:1.14-alpine"のプル 
  正常にプルされました 28 秒 kubelet、node1 イメージ「golang:1.14-alpine」が正常にプルされました  54.587298174秒
  正常 27 秒で kubelet、node1 が作成されました コンテナ step-run-test が作成されました
  正常 27 秒で開始 kubelet、node1 コンテナ step-run-test を開始

kubectl describe コマンドを使用して、タスクの実行プロセスを表示できます。まず、tekton-git-init を通じてコードがプルされ、次に定義した Task タスク内の Steps イメージを使用してタスクが実行されます。タスクが完了すると、Pod は Completed 状態に変わります。

 $ kubectl ポッドを取得する
名前準備完了 ステータス 再起動 年齢
testrun-r-n97ls-pod-7jvrd 0/2 完了 0 4分27秒
$ kubectl タスク実行を取得します
名前成功 理由 開始時間 完了時間
testrun-r-n97ls成功16分119秒

コンテナのログ情報を表示して、タスクの実行結果情報を把握できます。

 $ kubectl ログ testrun-r-n97ls-pod-7jvrd --all-containers  
 2021/06/08 09:07:31 /ko-app/entrypoint を/tekton/tools/entrypointにコピーしました
{ "level" : "info" , "ts" :1623144122.7787642, "caller" : "git/git.go:169" , "msg" : "https://github.com/cnych/tekton-demo @ c6c2a85091d538a13c44f85bcee9e861c362b0d3 (grafted、HEAD、origin/master) をパス /workspace/repo に正常にクローンしました" }
 { "level" : "info" , "ts" :1623144122.796532, "caller" : "git/git.go:207" , "msg" : "パス /workspace/repo のサブモジュールが正常に初期化され、更新されました" }
合格
ok _/workspace/repo 0.002秒

テストが合格したことがわかります。

Docker Hub の設定

Docker イメージを構築するには、通常、Docker を使用する必要があります。ここではコンテナなので、Docker In Docker モードを使用できます。このモードはあまり安全ではありません。この方法に加えて、Google がリリースした Kaniko ツールを使用して構築することもできます。このツールは、Docker デーモンに依存せずに Kubernetes クラスター内に Docker イメージを構築できます。以前、Kaniko フォームを紹介しましたが、ここでは DIND モードを紹介します。

Kaniko を使用してイメージを構築する方法は基本的に Docker コマンドと同じなので、事前に Docker Hub のログイン資格情報を設定すると、その後のイメージウェアハウスへのイメージのプッシュが容易になります。ログイン資格情報は、Kubernetes の Secret リソースオブジェクトに保存できます。次の内容を含む harbor-auth.yaml という名前のファイルを作成します。

 # ハーバー認証.yaml
 APIバージョン: v1
種類: 秘密
メタデータ:
名前: ハーバー認証
  注釈:
    tekton.dev/docker-0: http : //harbor.k8s.local  
タイプ: kubernetes.io/basic-auth
文字列データ:
  ユーザー名: admin
パスワード: Harbor12345

ユーザー名とパスワードを Harbor リポジトリのログイン資格情報に置き換えることを忘れないでください。

ここで、Secret オブジェクトに tekton.dev/docker-0 アノテーションを追加します。このアノテーションは、これらの認証情報が属する Docker イメージリポジトリを Tekton に伝えるために使用されます。

次に、上記の docker-auth Secret オブジェクトを使用するための ServiceAccount オブジェクトを作成し、次の内容を含む sa.yaml という名前のファイルを作成します。

 # sa.yaml
 APIバージョン: v1
種類: サービスアカウント
メタデータ:
名前: build-sa
秘密:
  -名前: harbor-auth

次に、上記の 2 つのリソースオブジェクトを作成します。

 $ kubectl apply -f harbor-auth.yaml
 secret/harbor-auth が作成されました
$ kubectl を適用 -f sa.yaml
 serviceaccount/build-sa が作成されました

作成すると、上記の build-sa ServiceAccount オブジェクトを使用して、Tekton タスクまたはパイプラインを実行するときに Docker Hub にログインできるようになります。

画像タスクを作成する

ここで、Docker イメージをビルドしてプッシュするタスクを作成します。ここで使用するサンプルアプリケーションには、ルートディレクトリの下に Dockerfile ファイルがすでに含まれているため、コードを直接クローンして取得できます。

 golang:1.14-alpineより
 
ワークディレクトリ /go/src/app
コピー 。 。 
 
 go get -d -v ./... を実行します。
 go install -v ./... を実行します。 
 
 CMD [ "アプリ" ]

次の内容を含む task-build-push.yaml という名前のファイルを作成します。

 apiバージョン: tekton.dev/v1beta1
種類: タスク
メタデータ:
名前: ビルドとプッシュ
仕様:
  リソース：
    入力: #入力リソースを定義する
      - name : repo #GitHub上のリポジトリであるリソースを入力します
        タイプ: git
    出力: #出力リソースを定義する
      - name :builtImage # 出力イメージ名
        タイプ: 画像
  パラメータ:
    - name : pathToDockerfile #リポジトリ内のdockerfileの場所を指定します
      タイプ: 文字列
デフォルト: /workspace/repo/Dockerfile # リポジトリリソースへのパス
      説明: dockerfile パス
    - name : pathToContext #ウェアハウス内のdockerfileの場所を指定します
      タイプ: 文字列
デフォルト: /workspace/repo # リポジトリリソースのパス
      説明: dockerデーモンが使用するビルドコンテキスト
  手順:
    -名前: ビルドとプッシュ
      イメージ: docker:stable
      スクリプト: |
        #!/usr/bin/envsh
        docker ログインharbor.k8s.local  
        docker ビルド -t $(resources.outputs.builtImage.url) -f $(params.pathToDockerfile) $(params.pathToContext)
        docker push $(resources.outputs.builtImage.url) # ここでのパラメータは入力と出力で定義されます
      ボリュームマウント:
        - name : dockersock #docker.sock ファイルをマウントし、ホストの docker デーモンを使用してイメージを構築します
          マウントパス: /var/run/docker.sock
  ボリューム:
    -名前: dockersock
      ホストパス:
        パス: /var/run/docker.sock

前のテストタスクと同様に、ここでも git を入力リソースとして使用します。さらに、Dockerfile のパスを指定するために dockerfile-path パラメータを定義します。さらに、Docker イメージの関連パラメータを定義するために、builtImage という名前のイメージ出力リソースを定義します。次に、build-and-push という名前のステップが定義されます。ここでは、DIND メソッドを使用してホストの /var/run/docker.sock ファイルを docker:stable コンテナにマウントし、スクリプトの下で Docker イメージのビルドとプッシュ操作を実行します。同様に、上記のリソースオブジェクトを直接作成することもできます。

 $ kubectl apply -f タスクビルドプッシュ.yaml
 task.tekton.dev/build-および-push が作成されました

タスクを作成した後、実際にこのタスクを実行する場合は、対応する TaskRun リソースオブジェクトを作成する必要があります。

タスクを実行する

前と同様に、タスクをトリガーする TaskRun オブジェクトを作成しますが、違いは、タスクに必要な ServiceAccount オブジェクトを指定する必要があることです。次の内容を含む taskrun-build-push.yaml という名前のファイルを作成します。

 # タスク実行ビルドプッシュ.yaml
 apiバージョン: tekton.dev/v1beta1
種類: タスク実行
メタデータ:
名前: ビルドとプッシュ
仕様:
  サービスアカウント名: build-sa
  タスク参照:
 name : build- and -push # 定義されたタスクを関連付ける
  リソース：
    入力:
      - name : repo #入力ウェアハウスリソースを指定します
        リソース参照:
名前: デモgit
    出力: #出力画像リソースを指定する
      -名前: 組み込みイメージ
        リソース参照:
名前: 港のイメージ

ここでは、serviceAccountName 属性を通じて Docker 認証情報の ServiceAccount オブジェクトを指定し、taskRef を通じてタスクを参照し、次の resourceRef が最初の部分で宣言した入力リソースを関連付けていることに注意してください。さらに、出力イメージ用の PipelineResource リソースを定義する必要があります。

 # ハーバーイメージres.yaml
 apiバージョン: tekton.dev/v1alpha1
種類: パイプラインリソース
メタデータ:
名前: 港のイメージ
仕様:
  タイプ: 画像
  パラメータ:
    -名前: URL
      値: harbor.k8s。 local /course/tekton-demo:latest #ビルドされたイメージの名前

次に、このリソースオブジェクトを作成します。

 $ kubectl apply -f ハーバーイメージres.yaml
 pipelineresource.tekton.dev/harbor-image が作成されました
$ kubectl apply -f タスク実行ビルドプッシュ.yaml
 taskrun.tekton.dev/build-および-push が作成されました

作成が完了すると、タスクの実行がトリガーされます。 Pod オブジェクトのステータスを確認することで、進行状況を把握できます。

 $ kubectl ポッドを取得する
名前準備完了 ステータス 再起動 年齢
ビルドとプッシュポッドfl65m 0/4 PodInitializing 0 9s
 $ kubectl タスク実行を取得します
名前成功 理由 開始時間 完了時間
ビルドとプッシュ 不明 保留中 26 秒

現在、タスク実行用の Pod はまだコンテナを初期化する段階にあります。 TaskRun のステータスが保留中であることがわかります。しばらくすると、通常のビルドが成功します。ビルドタスクの Pod ログ情報を表示できます。

 $ kubectl ポッドを取得する
名前準備完了 ステータス 再起動 年齢
ビルドとプッシュポッドfl65m 0/4 PodInitializing 0 9s
 $ tkn taskrunはビルドとプッシュをログに記録します
 
 [git-source-repo-rsvcf] { "level" : "info" , "ts" :1623151584.9503093, "caller" : "git/git.go:169" , "msg" : "https://github.com/cnych/tekton-demo @ c6c2a85091d538a13c44f85bcee9e861c362b0d3 (grafted、HEAD、origin/master) をパス /workspace/repo に正常にクローンしました" }
 [git-source-repo-rsvcf] { "level" : "info" , "ts" :1623151584.968812, "caller" : "git/git.go:207" , "msg" : "パス /workspace/repo のサブモジュールが正常に初期化され、更新されました" } 
 
 [ビルドとプッシュ]既存の資格情報を使用して認証しています...
 [ビルドとプッシュ] 警告!パスワードは暗号化されずに/root/.docker/config.jsonに保存されます。
 [ビルドおよびプッシュ]この警告を削除するには、資格情報ヘルパーを構成します。見る
[ビルドとプッシュ] https://docs.docker.com/engine/reference/commandline/login/#credentials-store
 [ビルドとプッシュ]
 [ビルドとプッシュ] ログインに成功しました
[build- and -push] ビルドコンテキストをDocker デーモンに送信 12.99MB
 [ビルドとプッシュ] ステップ 1/6: FROM golang:1.14-alpine
 ......
 [ビルドとプッシュ] 9f9d00b69565: プッシュされました
[ビルドおよびプッシュ] 最新: ダイジェスト: sha256:521a803fb15d2e05b6168cba36e6e31c548bdd369f274e86c8f5be2118cdb357サイズ: 2201 
 
 [image-digest-exporter-mpbwq] { "severity" : "INFO" 、 "timestamp" : "2021-06-08T11:26:43.642545898Z" 、 "caller" : "logging/config.go:116" 、 "message" : "ロガーを正常に作成しました。" }
 [image-digest-exporter-mpbwq] { "severity" : "INFO" 、 "timestamp" : "2021-06-08T11:26:43.642786678Z" 、 "caller" : "logging/config.go:117" 、 "message" : "ログレベルが info に設定されました" }
 [image-digest-exporter-mpbwq] { "severity" : "INFO" 、 "timestamp" : "2021-06-08T11:26:43.643090681Z" 、 "caller" : "imagedigestexporter/main.go:59" 、 "message" : "builtImage の index.json が見つかりません" 、 "commit" : "7ca5d61" }
 $ kubectl タスク実行を取得します
名前成功 理由 開始時間 完了時間
ビルドとプッシュ成功15分 2分24秒

TaskRun タスクが正常に実行されたことがわかります。この時点で、実際に Harbor でイメージを見つけることができ、もちろんこのイメージを直接テストに使用することもできます。

パイプラインの作成

この時点で、テストとビルドとプッシュの 2 つのタスクが完了しました。また、これら 2 つのタスクを整理するパイプラインを作成し、最初にテストタスクを実行し、成功した場合は後続のビルドおよびプッシュタスクを実行することもできます。

次の内容を含む pipeline.yaml という名前のファイルを作成します。

 apiバージョン: tekton.dev/v1beta1
種類: パイプライン
メタデータ:
名前: テストビルドプッシュ
仕様:
  リソース：
    -名前: リポジトリ
      タイプ: git
  タスク:
    # アプリケーションテストを実行する
    -名前: テスト
      タスク参照:
名前: テスト
      リソース：
        入力:
          - name : repo # タスク入力名
            resource: repo # パイプラインリソース名
    # Dockerイメージをビルドしてプッシュする
    -名前: ビルドとプッシュ
      タスク参照:
名前: ビルドとプッシュ
      実行後:
        - test # テストタスクが実行された後
      リソース：
        入力:
          - name : repo # タスク入力名
            resource: repo # パイプラインリソース名

まず、パイプラインに必要なリソース（入力リソースまたは出力リソース）を定義する必要があります。ここで入力されるのは、repo という名前のアプリケーションソースコードの GitHub リポジトリの 1 つだけです。次に、タスクを定義します。各タスクは taskRef を通じて参照され、タスクに必要な入力パラメータが渡されます。

このリソースオブジェクトを直接作成することもできます。

 $ kubectl apply -f パイプライン.yaml
 pipeline.tekton.dev/test-build-push が作成されました

先ほど、TaskRun を作成して Task タスクをトリガーするのと同様に、PipelineRun オブジェクトを作成してパイプラインを実行できることを説明しました。ここでは、パイプラインを実行するために、pipelinerun.yaml という名前の PipelineRun オブジェクトを作成します。ファイルの内容は次のとおりです。

 apiバージョン: tekton.dev/v1beta1
種類: PipelineRun
メタデータ:
名前: テストビルドプッシュ実行
仕様:
  サービスアカウント名: build-sa
  パイプライン参照:
名前: テストビルドプッシュ
  リソース：
    -名前: リポジトリ
      リソース参照:
名前: デモgit

定義方法はTaskRunとほぼ同じです。 ServiceAccount オブジェクトは serviceAccountName 属性を通じて指定され、pipelineRef はパイプラインオブジェクトに関連付けられます。同様に、このリソースを直接作成することもできます。これにより、作成後にパイプラインタスクがトリガーされます。

 $ kubectl apply -f パイプライン実行.yaml
 pipelinerun.tekton.dev/test-build-push-run が作成されました
$ kubectl ポッドを取得します | grep テストビルドプッシュ実行
test-build-push-run-build- and -push-xl7wp-pod-hdnbl 0/2 完了 0 5分27秒
test-build-push-run-test-4s6qh-pod-tkwzk 0/2 完了 0 6分5秒
$ kubectl logs -f test-build-push-run-build- and -push-xl7wp-pod-hdnbl --all-containers  
 { "level" : "info" , "ts" :1588908934.442572, "caller" : "git/git.go:136" , "msg" : "https://github.com/cnych/tekton-demo @ f840e0c390be9a1a6edad76abbde64e882047f05 (grafted、HEAD、origin/master) をパス /workspace/repo に正常にクローンしました" }
 { "level" : "info" , "ts" :1588908934.577377, "caller" : "git/git.go:177" , "msg" : "パス /workspace/repo のサブモジュールが正常に初期化され、更新されました" }
 { "level" : "info" , "ts" :1588908927.469531, "caller" : "creds-init/main.go:44" , "msg" : "資格情報が初期化されました。" }
 INFO[0004] イメージマニフェストを取得しています golang:1.14-alpine
 ......
アプリ
INFO[0281] スナップショットを撮る ファイルシステムがいっぱいです...
 INFO[0287] 11666個のパスを解決しています
INFO[0291] CMD [ "app" ]
 $ kubectl get taskrun |grep test-build-push-run
 test-build-push-run-build- and -push-xl7wp True成功 6分21秒 65秒
test-build-push-run-test-4s6qh True成功 6分58秒 6分21秒

これは、パイプラインが正常に実行されたことを証明します。 Kubernetes クラスターに Tekton をインストールし、タスクを定義し、YAML マニフェストと Tekton CLI を使用して TaskRun を作成してテストしました。私たちは 2 つのタスクで構成される Tektok パイプラインを作成しました。最初のタスクは GitHub からコードを複製してアプリケーションテストを実行し、2 番目のタスクは Docker イメージをビルドして Docker Hub にプッシュします。これまで、Tekton を使用して CI/CD パイプラインを作成する簡単な例を完了しました。ただし、この例は比較的単純です。次に、もう少し複雑なアプリケーションを使用してパイプラインを完成させます。

<<: テンセント学術専門家ワークステーションが2021年浦江イノベーションフォーラム科学技術イノベーション青年サミットをサポート

>>: マイクロサービスアーキテクチャにおける分散トレースの応用