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

クラウドネイティブ 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 ファイルから直接インストールできます。

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

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

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

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

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

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

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

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

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

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

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

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

  1. 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 オブジェクトを使用する必要があります。ここでは、以下に示すように、次の内容のリソース ファイルを作成します。

  1. # タスクテスト.yaml
  2. apiバージョン: tekton.dev/v1beta1
  3. 種類: タスク
  4. メタデータ:
  5. 名前: テスト
  6. 仕様:
  7. リソース:
  8. 入力:
  9. -名前: リポジトリ
  10. タイプ: git
  11. 手順:
  12. -名前: 実行テスト
  13. イメージ: golang:1.14-alpine
  14. 作業ディレクトリ: /workspace/repo
  15. コマンド: [ 'go' ]
  16. 引数: [ 'テスト' ]

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

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

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

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

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

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

  1. $ tkn タスク開始テスト--dry-run  
  2. 名前空間「git」タイプパイプライン リソースが見つかりませ: default  
  3. パイプライン リソース「repo」新しい「git」リソースを作成してください 
  4. ?名前を入力してください パイプラインリソースの場合: demo-git
  5. ? URL値を入力してください: https://github.com/cnych/tekton-demo
  6. ?リビジョン値を入力してください: マスター
  7. 新しい git リソース「demo-git」が作成されました
  8. apiバージョン: tekton.dev/v1beta1
  9. 種類: タスク実行
  10. メタデータ:
  11. 作成タイムスタンプ: null  
  12. 生成名: テスト実行
  13. 名前空間:デフォルト 
  14. 仕様:
  15. リソース:
  16. 入力:
  17. -名前: リポジトリ
  18. リソース参照:
  19. 名前: デモgit
  20. サービスアカウント名: ""  
  21. タスク参照:
  22. 名前: テスト
  23. 状態:
  24. ポッド名: ""  

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

  1. $ kubectl パイプラインリソースを取得する
  2. 名前年齢
  3. デモ-git 3分37秒
  4. $ kubectl パイプラインリソースの取得 demo-git -o yaml
  5. apiバージョン: tekton.dev/v1alpha1
  6. 種類: パイプラインリソース
  7. メタデータ:
  8. 名前: デモgit
  9. 名前空間:デフォルト 
  10. ......
  11. 仕様:
  12. パラメータ:
  13. -名前: URL
  14. 値: https://github.com/cnych/tekton-demo
  15. -名前: リビジョン
  16. 値: マスター
  17. タイプ: git

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

  1. #タスク実行.yaml
  2. apiバージョン: tekton.dev/v1beta1
  3. 種類: タスク実行
  4. メタデータ:
  5. 名前: テストラン
  6. 仕様:
  7. リソース:
  8. 入力:
  9. -名前: リポジトリ
  10. リソース参照:
  11. 名前: デモgit
  12. タスク参照:
  13. 名前: テスト

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

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

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

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

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

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

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

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

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

  1. $ kubectl ログ testrun-r-n97ls-pod-7jvrd --all-containers  
  2. 2021/06/08 09:07:31 /ko-app/entrypoint を/tekton/tools/entrypointコピーしました
  3. { "level" : "info" , "ts" :1623144122.7787642, "caller" : "git/git.go:169" , "msg" : "https://github.com/cnych/tekton-demo @ c6c2a85091d538a13c44f85bcee9e861c362b0d3 (grafted、HEAD、origin/master) をパス /workspace/repo に正常にクローンしました" }
  4. { "level" : "info" , "ts" :1623144122.796532, "caller" : "git/git.go:207" , "msg" : "パス /workspace/repo のサブモジュールが正常に初期化され、更新されました" }
  5. 合格
  6. 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 という名前のファイルを作成します。

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

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

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

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

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

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

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

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

画像タスクを作成する

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

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

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

  1. apiバージョン: tekton.dev/v1beta1
  2. 種類: タスク
  3. メタデータ:
  4. 名前: ビルドプッシュ
  5. 仕様:
  6. リソース:
  7. 入力: #入力リソースを定義する
  8. - name : repo #GitHub上のリポジトリであるリソースを入力します
  9. タイプ: git
  10. 出力: #出力リソースを定義する
  11. - name :builtImage # 出力イメージ名
  12. タイプ: 画像
  13. パラメータ:
  14. - name : pathToDockerfile #リポジトリ内のdockerfileの場所を指定します
  15. タイプ: 文字列
  16. デフォルト: /workspace/repo/Dockerfile # リポジトリリソースへのパス
  17. 説明: dockerfile パス
  18. - name : pathToContext #ウェアハウス内のdockerfileの場所を指定します
  19. タイプ: 文字列
  20. デフォルト: /workspace/repo # リポジトリリソースのパス
  21. 説明: dockerデーモン使用するビルドコンテキスト
  22. 手順:
  23. -名前: ビルドプッシュ
  24. イメージ: docker:stable
  25. スクリプト: |
  26. #!/usr/bin/envsh
  27. docker ログインharbor.k8s.local  
  28. docker ビルド -t $(resources.outputs.builtImage.url) -f $(params.pathToDockerfile) $(params.pathToContext)
  29. docker push $(resources.outputs.builtImage.url) # ここでのパラメータは入力と出力で定義されます
  30. ボリュームマウント:
  31. - name : dockersock #docker.sock ファイルをマウントし、ホストの docker デーモンを使用してイメージを構築します
  32. マウントパス: /var/run/docker.sock
  33. ボリューム:
  34. -名前: dockersock
  35. ホストパス:
  36. パス: /var/run/docker.sock

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

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

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

タスクを実行する

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

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

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

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

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

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

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

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

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

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

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

パイプラインの作成

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

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

  1. apiバージョン: tekton.dev/v1beta1
  2. 種類: パイプライン
  3. メタデータ:
  4. 名前: テストビルドプッシュ
  5. 仕様:
  6. リソース:
  7. -名前: リポジトリ
  8. タイプ: git
  9. タスク:
  10. # アプリケーションテストを実行する
  11. -名前: テスト
  12. タスク参照:
  13. 名前: テスト
  14. リソース:
  15. 入力:
  16. - name : repo # タスク入力名
  17. resource: repo # パイプラインリソース名
  18. # Dockerイメージをビルドしてプッシュする
  19. -名前: ビルドプッシュ
  20. タスク参照:
  21. 名前: ビルドプッシュ
  22. 実行後:
  23. - test # テストタスクが実行された後
  24. リソース:
  25. 入力:
  26. - name : repo # タスク入力名
  27. resource: repo # パイプラインリソース名

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

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

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

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

  1. apiバージョン: tekton.dev/v1beta1
  2. 種類: PipelineRun
  3. メタデータ:
  4. 名前: テストビルドプッシュ実行
  5. 仕様:
  6. サービスアカウント名: build-sa
  7. パイプライン参照:
  8. 名前: テストビルドプッシュ
  9. リソース:
  10. -名前: リポジトリ
  11. リソース参照:
  12. 名前: デモgit

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

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

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

推薦する

imidc: 直接接続帯域幅、香港 VPS は年間 49 ドルから (20~80M 帯域幅)、香港専用サーバー (30M 帯域幅) は月額 59 ドルから

imidc は、香港データセンターの香港 VPS と香港独立サーバーの帯域幅をアップグレードした後、...

オンラインローンプラットフォーム保証の混乱:保証会社は単なる見せかけだと非難されている

今年の10のオンライン融資プラットフォームの取引量は主に4億から17億の間で分布している。一部のプラ...

Vipshopの「成長不安」

電子商取引業界では、アリババ、JD.com、ピンドゥオドゥオなどの総合電子商取引プラットフォームがま...

ブラウザ信頼IP SSL証明書の申請には1~3日しかかかりません

月収10万元の起業の夢を実現するミニプログラム起業支援プランIP SSL 証明書は現時点では主流の需...

Huayun Data が VMware と提携し、安全で信頼性の高い金融クラウドの構築を支援

インターネット、特にモバイル インターネットの急速な発展に伴い、金融機関はインターネット シナリオへ...

China Search がクラウドソーシングで試験運用中: 異なる種類の検索の可能性はあるか?

検索エンジンはインターネットへの最初の入り口であり、常にインターネット企業にとっての戦場となっていま...

メガレイヤー: 高防御サーバー + 高速回線、40% 割引、月額 79 ドル、香港 CN2、シンガポール CUII/AS9929

Megalayerは、香港サーバー(オプション:CN2/直結/国際回線)、シンガポールサーバー(オプ...

テンセントクラウドの支援により、貴州銀行は中国で初めて全業務をクラウドに移行する商業銀行となった。

12月28日、貴州銀行の次世代情報システムが無事に稼働を開始したと報じられた。このシステムはプライベ...

ドメイン名の先占:侵害事件は年々増加、ビジネスチャンスと侵害は密接に関係

ジェレミー・リンは全米バスケットボール協会で急速に人気者となり、「リン・トルネード」もインターネット...

IBMのハイブリッドマルチクラウドプラットフォームは、企業のアプリケーションの最新化とコンテナ化の実現を支援します。

IBM と Red Hat の強力な組み合わせは、まさに開発者が望んでいるものです。 Red Hat...

ハイブリッドクラウドを構成する方法

IT リーダーは、ハイブリッド クラウド環境に向けてネットワーク チームとインフラストラクチャ チー...

1ヶ月で体重を2から6に増やした方法

これ以上言う意味がないので、まずは写真を載せておきます。写真が真実を物語っています。信じられないなら...