Tektonシリーズの実用記事 私の最初のパイプライン

上記ではTektonのインストールと理論的知識を紹介しました。この記事を注意深く読めば、何か得られるものがあると信じています。

この記事では主に、最初の組立ラインを実際に練習して完成させる方法について説明します。

パイプラインの全体的なプロセスは次のとおりです。

全体のプロセスは非常に簡単ですか?はい、これが最も基本的なプロセスです。実際には、最も基本的なものだけを理解すればよく、残りはこの基礎に基づいた拡張です。

以下はテスト用に Go で書かれた簡単なコードです。アドレスは https://gitee.com/coolops/devops-hello-world.git です。

Jenkins を使用して上記の機能を実装する場合は、Jenkinsfile を記述し、その中に 4 つのステージを記述するだけで済みます。ここで、Tekton を使用して、上記の手順を 4 つのタスクとして定義し、それらを Pipeline を通じて連結する必要があります。以下では、まずタスクを定義し、次にタスクをパイプラインに結合します。

プルコード

コードは配信の基礎であり、その後のすべてのアクションの道を開きます。コードを取得するためのタスクを作成する必要があります。

ただし、このタスクを自分で記述する必要はありません。 Tekton Hub で他の人が書いたものを直接使用できます。アドレスは https://hub.tekton.dev/tekton/task/git-clone です。このタスクは、幅広い機能と多くのパラメータをサポートします。具体的なパラメータについては、上記のアドレスで確認して確認できます。

インストールには、kubectl と tkn クライアントの 2 つの方法があります。

（1）kubectlを使用してインストールします。

 kubectl apply -f https://raw.githubusercontent.com/tektoncd/catalog/main/task/git-clone/0.5/git-clone.yaml

（２）tknクライアントを使用してインストールします。

 tkn hub インストールタスクgit - クローン

ここでは 2 番目のインストール方法を使用します。インストール後に特定のタスクを確認できます。

 # tkn hub インストールタスク git-clone
 タスクgit - clone ( 0.5 ) がデフォルトの名前空間にインストールされました
# kubectl タスクを取得 | grep gitクローン
git - クローン54 s

このタスクは私たちのニーズを満たすことができますか?次のように、TaskRun を作成してテストすることができます (コード リポジトリを取得するためのユーザー名とパスワードが設定されていないため、ここでは最初にパブリック リポジトリを使用してテストします)。

 apiバージョン: tekton.dev/v1beta1
 種類: タスク実行
メタデータ:
 名前: テスト- git - クローン
名前空間: デフォルト
仕様:
 ワークスペース:
 - 名前: 出力
空のディレクトリ: {}
 パラメータ:
 - 名前: URL
 値: "https://gitee.com/coolops/tekton-install.git"
 - 名前: リビジョン
値: "マスター"
 - 名前: gitInitImage
 値: "registry.cn-hangzhou.aliyuncs.com/coolops/tekton-git-init:v0.29"
 タスク参照:
 名前: git - クローン

実行後、コードが正常にプルされていることがわかります。

ユニットテスト

ユニット テストは比較的簡単で、基本的には、たとえば go test ./... コマンドを実行するだけです。

 > テストを実行します。 / . 。 。
 okdevops - hello - world 0.313 秒​
 ok devops - hello - world / pkg ( キャッシュ済み)

したがって、このタスクには、次のように Go コマンドを実行できる Go 環境のみが必要です。

 apiバージョン: tekton.dev/v1beta1
 種類: タスク
メタデータ:
 名前: ユニットテスト
仕様:
 ワークスペース:
 - 名前: ソース
手順:
 - 名前: ユニット- テスト
作業ディレクトリ: $ ( ワークスペース. ソース. パス)
 イメージ: golang : 1.17.5
 環境:
 - 名前: GOPROXY
 値: https://goproxy.cn
 コマンド: [ 'go' ]
 引数:
 - "テスト"
 - 「./...」

イメージのビルド/プッシュ

ここでアプリケーション構築用の個別のタスクがないのはなぜですか?主な理由は、ここでは多段階の建物を使用しているためです。アプリケーションのビルドイメージを Dockerfile にパッケージ化できるため、ここで記述する必要があるのは 1 つのタスクだけです。

 apiバージョン: tekton.dev/v1beta1
 種類: タスク
メタデータ:
 名前: ビルド- プッシュ- イメージ
仕様:
 パラメータ:
 - 名前: Dockerファイルへのパス
説明: ビルドするdockerfile へのパス( コンテキストに対する相対パス)
 デフォルト: Dockerfile
 - 名前: イメージURL
 説明: 画像リポジトリのURL
 - 名前: イメージタグ
説明: ビルドされたイメージに適用するタグ
デフォルト: 最新
ワークスペース:
 - 名前: ソース
- 名前: dockerconfig
 マウントパス: / kaniko / 。 docker # config 。 json マウントディレクトリ
手順:
 - 名前: ビルドとプッシュ​
 画像: レジストリ。 cn - 杭州。 アリユンクス。 com / coolops / kaniko - エグゼキューター: v1 .5 .0
 作業ディレクトリ: $ ( ワークスペース. ソース. パス)
 指示：
 - / カニコ/ 執行者
引数:
 --dockerfile = $ ( params . pathToDockerfile )
 -- destination = $ ( params.imageUrl ) : $ ( params.imageTag )
 -- context = $ ( ワークスペース. ソース. パス)

ここでは、kaniko を使用してイメージを構築します。この方法では、docker.sock ファイルをマウントする必要はありませんが、docker 構成を /kaniko/.docker ディレクトリに保存する必要があります。次のコマンドを使用してシークレットを作成できます。

 kubectl でシークレットdocker - registry dockerhub --docker -server = https : //index.docker.io/v1/ --docker-username=[ユーザー名] --docker-password=[パスワード] --dry-run=client -o json | を作成します。 jq -r '.data.".dockerconfigjson"' | base64 -d > /tmp/config.json && kubectl はシークレットジェネリック docker-config を作成します --from-file=/tmp/config.json && rm -f /tmp/config.json

上記コマンドを実行した際にjqコマンドがない場合はインストールする必要があります。

 yum インストールjq -y

アプリケーションをデプロイする

ここで使用されるデプロイメント方法はアプリケーションをデプロイすることなので、デプロイするには kubectl を使用するだけで済みます。

ただし、kubectl を使用する場合は /root/.kube/config ファイルが必要なので、構成ファイルは引き続き secret を通じてコン​​テナーにマウントされます。

次のようにシークレットを作成します。

 kubectl は、 ジェネリックkubernetes - config シークレットを作成します--from - file = /root/.kube/config ​

次に、次のようにタスクを作成します。

 apiバージョン: tekton.dev/v1alpha1
 種類: タスク
メタデータ:
 名前: deploy - to - k8s
 仕様:
 ワークスペース:
 - 名前: ソース
- 名前: kubernetesconfig
 マウントパス: / root / 。 キューブ
パラメータ:
 - 名前: YamlFileへのパス
説明: Git ソース内にデプロイするyaml ファイルへのパス
デフォルト: デプロイメント。 ヤム
- 名前: 画像
- 名前: タグ
手順:
 - 名前: 実行- kubectl
 画像: レジストリ。 cn - 杭州。 アリユンクス。 com / coolops / kubectl : 1.19.16
 作業ディレクトリ: $ ( ワークスペース. ソース. パス)
 スクリプト: |
 sed -i s #IMAGE # $ ( params.IMAGE ) #g $ ( params.pathToYamlFile )
 sed -i s #TAG #$ ( params . TAG ) #g $ ( params . pathToYamlFile )
 kubectl apply -f $ ( パラメータ.YamlFile へのパス )

パイプラインに統合

上記の各ステップをタスクに整理しました。ここで、次のように Pipeline を結合し、必要な変数を宣言する必要があります。

 apiバージョン: tekton.dev/v1beta1
 種類: パイプライン
メタデータ:
 名前: devops - hello - world - パイプライン
仕様:
 ワークスペース: # ワークスペースを宣言する
- 名前: go - リポジトリ- pvc
 - 名前: docker - 設定
- 名前: kubernetes - 設定
パラメータ:
 - 名前: git_url
 - 名前: リビジョン
タイプ: 文字列
デフォルト: "master"
 - 名前: gitInitImage
 タイプ: 文字列
デフォルト: "registry.cn-hangzhou.aliyuncs.com/coolops/tekton-git-init:v0.29"
 - 名前: Dockerファイルへのパス
説明: ワークスペース内でKaniko が使用するビルドコンテキストへのパス
デフォルト： 。
 - 名前: イメージURL
 説明: 画像リポジトリのURL
 - 名前: イメージタグ
説明: ビルドされたイメージに適用するタグ
デフォルト: 最新
タスク: # パイプラインにタスクを追加する
- 名前: クローン
タスク参照:
 名前: git - クローン
ワークスペース:
 - 名前: 出力
ワークスペース: go - repo - pvc
 パラメータ:
 - 名前: URL
 値: $ ( params . git_url )
 - 名前: リビジョン
値: $ ( パラメータ. リビジョン)
 - 名前: gitInitImage
 値: $ ( params . gitInitImage )
 - 名前: ユニット- テスト
ワークスペース: #pass ワークスペース
- 名前: ソース
ワークスペース: go - repo - pvc
 タスク参照:
 名前: ユニットテスト
実行後:
 - クローン
- 名前: ビルド- プッシュ- イメージ
パラメータ:
 - 名前: Dockerファイルへのパス
値: $ ( params . pathToDockerfile )
 - 名前: イメージURL
 値: $ ( params . imageUrl )
 - 名前: イメージタグ
値: $ ( params . imageTag )
 タスク参照:
 名前: ビルド- プッシュ- イメージ
実行後:
 -ユニット- テスト
ワークスペース: #pass ワークスペース
- 名前: ソース
ワークスペース: go - repo - pvc
 - 名前: dockerconfig
 ワークスペース: docker - config
 - 名前: デプロイ先: k8s
 タスク参照:
 名前: deploy - to - k8s
 パラメータ:
 - 名前: YamlFileへのパス
値: デプロイメント。 ヤム
- 名前: 画像
値: $ ( params . imageUrl )
 - 名前: タグ
値: $ ( params . imageTag )
 ワークスペース:
 - 名前: ソース
ワークスペース: go - repo - pvc
 - 名前: kubernetesconfig
 ワークスペース: kubernetes - 構成
実行後:
 - ビルド- プッシュ- イメージ

テストの実行

テストを実行するには PipelineRun を作成しますが、作成する前に、まず必要な認証情報を作成します。

 APIバージョン: v1
 種類: 秘密
メタデータ:
 名前: gitlab - auth
 注釈:
 tekton.dev/git-0:https://gitee.com/ # ここで使用されているgitee リポジトリ
タイプ: kubernetes .io / basic - auth
 文字列データ:
 ユーザー名: xxxx
 パスワード: xxxx
 ---
 APIバージョン: v1
 種類: サービスアカウント
メタデータ:
 名前: テクトン- ビルド- sa
 秘密:
 - 名前: gitlab - 認証
---
 apiバージョン: rbac 。 承認。 k8s 。 io / v1
 種類: ClusterRoleBinding
 メタデータ:
 名前: tekton - clusterrole - binding
 ロールリファレンス:
 apiグループ: rbac 。 承認。 k8s 。 io
 種類: ClusterRole
 名前: 編集
科目:
 - 種類: サービスアカウント
名前: テクトン- ビルド- sa
 名前空間: デフォルト

次に、次のように PipelineRun を作成します。

 apiバージョン: tekton.dev/v1beta1
 種類: PipelineRun
 メタデータ:
 名前: devops - hello - world - パイプライン- 実行
仕様:
 パイプライン参照:
 名前: devops - hello - world - パイプライン
パラメータ:
 - 名前: リビジョン
値: マスター
- 名前: git_url
 値: https://gitee.com/coolops/devops-hello-world.git
 - 名前: イメージURL
 値: レジストリ。 cn - 杭州。 アリユンクス。 com / coolops / devops - hello - world
 - 名前: イメージタグ
値: 最新
- 名前: Dockerファイルへのパス
値: Dockerfile
 ワークスペース:
 - 名前: go - リポジトリ- pvc
 ボリュームクレームテンプレート:
 仕様:
 アクセスモード:
 -ReadWriteOnce
 ストレージクラス名: openebs - ホストパス
リソース：
 リクエスト:
 ストレージ: 1 Gi
 - 名前: docker - 設定
秘密：
 secretName : docker - config
 - 名前: kubernetes - 設定
秘密：
 secretName : kubernetes - config
 サービスアカウント名: tekton - build - sa

次に、Tekton ダッシュボードでパイプラインが正常に実行されていることを確認します。

アプリケーションも正常に起動しました。

 # kubectl get po | grep http
 httpserver - 696479 dd5d - qplnx 2 / 2 実行中0 2 分18秒

ページにアクセスして通常の状態に戻ります。

 # カール10.102.140.2:8080
 { "データ" : 300 、 "言う" : "Hello World" }

しかし、上には固定ミラー TAG があります。実際の作業では固定のものが多いので修正していきます。 Tekton Hub の git-clone タスクはコミット結果を出力します。コミット ID をイメージ タグとして使用できます。変更されたパイプラインは次のとおりです。

 apiバージョン: tekton.dev/v1beta1
 種類: パイプライン
メタデータ:
 名前: devops - hello - world - パイプライン
仕様:
 ワークスペース: # ワークスペースを宣言する
- 名前: go - リポジトリ- pvc
 - 名前: docker - 設定
- 名前: kubernetes - 設定
パラメータ:
 # コードリポジトリを定義する
- 名前: git_url
 - 名前: リビジョン
タイプ: 文字列
デフォルト: "master"
 - 名前: gitInitImage
 タイプ: 文字列
デフォルト: "registry.cn-hangzhou.aliyuncs.com/coolops/tekton-git-init:v0.29"
 # ミラーパラメータを定義する
- 名前: Dockerファイルへのパス
説明: ワークスペース内でKaniko が使用するビルドコンテキストへのパス
デフォルト： 。
 - 名前: イメージURL
 説明: 画像リポジトリのURL
 - 名前: イメージタグ
説明: ビルドされたイメージに適用するタグ
デフォルト: 最新
タスク: # パイプラインにタスクを追加する
- 名前: クローン
タスク参照:
 名前: git - クローン
ワークスペース:
 - 名前: 出力
ワークスペース: go - repo - pvc
 パラメータ:
 - 名前: URL
 値: $ ( params . git_url )
 - 名前: リビジョン
値: $ ( パラメータ. リビジョン)
 - 名前: gitInitImage
 値: $ ( params . gitInitImage )
 - 名前: ユニット- テスト
ワークスペース: #pass ワークスペース
- 名前: ソース
ワークスペース: go - repo - pvc
 タスク参照:
 名前: ユニットテスト
実行後:
 - クローン
- 名前: ビルド- プッシュ- イメージ
パラメータ:
 - 名前: Dockerファイルへのパス
値: $ ( params . pathToDockerfile )
 - 名前: イメージURL
 値: $ ( params . imageUrl )
 - 名前: イメージタグ
値: $ ( タスク. クローン. 結果. コミット)
 タスク参照:
 名前: ビルド- プッシュ- イメージ
実行後:
 -ユニット- テスト
ワークスペース: #pass ワークスペース
- 名前: ソース
ワークスペース: go - repo - pvc
 - 名前: dockerconfig
 ワークスペース: docker - config
 - 名前: デプロイ先: k8s
 タスク参照:
 名前: deploy - to - k8s
 パラメータ:
 - 名前: YamlFileへのパス
値: デプロイメント。 ヤム
- 名前: 画像
値: $ ( params . imageUrl )
 - 名前: タグ
値: $ ( タスク. クローン. 結果. コミット)
 ワークスペース:
 - 名前: ソース
ワークスペース: go - repo - pvc
 - 名前: kubernetesconfig
 ワークスペース: kubernetes - 構成
実行後:
 - ビルド- プッシュ- イメージ

$(tasks.clone.results.commit) を使用すると、後続のタスクで前のタスクの出力を参照できます。

パイプラインを再実行すると、ビルドされたイメージのタグは次のようにコミット ID になります。

コード リポジトリ内の最後のコミットのコミット ID。

要約する

パイプライン全体は単純に見えますが、定義されたパラメータが渡されたり指定し忘れられたりすることがあるため、デバッグには多少の労力がかかります。そのため、継続的なデバッグが必要になります。