Tekton を使用した自動化パイプラインのリファクタリング

[[407592]]

先ほど、Jenkins パイプラインを使用して Kubernetes アプリケーションに CI/CD を実装する方法について説明しました。それでは、このパイプラインを Tekton に移行しましょう。実際、全体的な考え方は同じで、ワークフロー全体をさまざまなタスクに分割して実行します。これまでのワークフロー ステージは、次のステージに分かれています: コードのクローン作成 -> ユニット テスト -> Golang のコンパイルとパッケージ化 -> Docker イメージのビルド/プッシュ -> Kubectl デプロイメント サービス。

Tekton では、これらのステージを Task タスクに直接変換できます。 Tekton のクローン コードでは、タスクを積極的に定義する必要はありません。実行されたタスクに入力コード リソースを指定するだけで済みます。次に、上記のワークフローを段階的に Tekton パイプラインに変換します。コード リポジトリは引き続き http://git.k8s.local/course/devops-demo.git です。

クローンコード

コードを複製するために別のタスクを定義する必要はありませんが、git タイプの入力リソースを直接使用できます。ここには多くのタスクが関係しており、多くの場合、操作する前にコードを複製する必要があるため、コードを複製し、ワークスペースを通じて他のタスクと共有するのが最善の方法です。ここでは、カタログ git-clone を直接使用してこのタスクを実装できます。ニーズに応じてカスタマイズすることも可能です。対応するタスクは次のとおりです。

 # タスククローン.yaml
 apiバージョン: tekton.dev/v1beta1
種類: タスク
メタデータ:
名前: git-clone
仕様:
  ワークスペース:
    -名前:出力 
      説明: Git リポジトリは、このワークスペースをバックアップするボリュームにクローンされます。
    -名前: 基本認証
      オプション: true  
      説明: |
        .gitconfigおよび.git-credentials ファイルを含むワークスペース。これら
        gitコマンドが実行される前に、ユーザーのホームにコピーされます。どれでも 
        このワークスペース内の他のファイルは無視されます。強くお勧めします
可能な限り、基本認証ではなくssh-directoryを使用する 縛る​
        他のボリューム タイプよりもこのワークスペースの秘密です。
  パラメータ:
    -名前: URL
      説明:クローン元のリポジトリ URL 。
      タイプ: 文字列
    -名前: リビジョン
      説明: チェックアウトするリビジョン。 (ブランチ、タグ、sha、ref など)
      タイプ: 文字列
デフォルト： ""  
    -名前: 参照仕様
      説明: Refspecに リビジョンをチェックアウトする前に取得します。
デフォルト： ""  
    -名前: サブモジュール
      説明: 初期化して  Git サブモジュールを取得します。
      タイプ: 文字列
デフォルト: "true"  
    -名前: 深さ
      説明:最新の N コミットのみを取得して、浅いクローンを実行します。
      タイプ: 文字列
デフォルト: "1"  
    -名前: sslVerify
      説明: `http.sslVerify`グローバルGit 設定を設定します。これを「 false 」に設定すると  Git リモートを信頼できると確信していない限り、推奨されません。
      タイプ: 文字列
デフォルト: "true"  
    -名前: サブディレクトリ
      説明:リポジトリをクローンする` output ` ワークスペース内のサブディレクトリ。
      タイプ: 文字列
デフォルト： ""  
    -名前: sparseCheckoutDirectories
      説明:スパースチェックアウトを実行するときに一致または除外するディレクトリパターンを定義します。
      タイプ: 文字列
デフォルト： ""  
    -名前: 既存のものを削除
      説明:クローン作成前に宛先ディレクトリがすでに存在する場合は、その内容を削除します。
      タイプ: 文字列
デフォルト: "true"  
    -名前: 詳細
      説明: `git-clone` の操作中に実行されるコマンドをログに記録します。
      タイプ: 文字列
デフォルト: "true"  
    -名前: gitInitImage
      説明:このタスクが実行するgit-initバイナリを提供するイメージ。
      タイプ: 文字列
デフォルト: 「cnych/tekton-git-init:v0.24.1」  
    -名前: ユーザーホーム
      説明: |
ユーザーのホームディレクトリへの絶対パス。非ルートユーザーとしてイメージを実行している場合は、これを明示的に設定します または上書きした
        カスタムユーザー設定を含むイメージを含むgitInitImage パラメータ。
      タイプ: 文字列
デフォルト: "/root"  
  結果：
    -名前:コミット 
      説明:このタスクによって取得された正確なコミットSHA 。
    -名前: URL
      説明:このタスクによって取得された正確な URL。
  手順:
    -名前:クローン
      画像: "$(params.gitInitImage)"  
      環境:
      -名前: HOME
        値: "$(params.userHome)"  
      -名前: PARAM_URL
        値: $(params.url)
      -名前: PARAM_REVISION
        値: $(params.revision)
      -名前: PARAM_REFSPEC
        値: $(params.refspec)
      -名前: PARAM_SUBMODULES
        値: $(params.submodules)
      -名前: PARAM_DEPTH
        値: $(params.depth)
      -名前: PARAM_SSL_VERIFY
        値: $(params.sslVerify)
      -名前: PARAM_SUBDIRECTORY
        値: $(params.subdirectory)
      -名前: PARAM_DELETE_EXISTING
        値: $(params.deleteExisting)
      -名前: PARAM_VERBOSE
        値: $(params.verbose)
      -名前: PARAM_SPARSE_CHECKOUT_DIRECTORIES
        値: $(params.sparseCheckoutDirectories)
      -名前: PARAM_USER_HOME
        値: $(params.userHome)
      -名前: WORKSPACE_OUTPUT_PATH
        値: $(ワークスペース.出力.パス)
      -名前: WORKSPACE_BASIC_AUTH_DIRECTORY_BOUND
        値: $(workspaces.basic-auth.bound)
      -名前: WORKSPACE_BASIC_AUTH_DIRECTORY_PATH
        値: $(workspaces.basic-auth.path)
      スクリプト: |
        #!/usr/bin/envsh
セット-eu 
 
        [ "${PARAM_VERBOSE}" = "true"の場合;それから 
 -xを設定する
        フィ
 
        [ "${WORKSPACE_BASIC_AUTH_DIRECTORY_BOUND}" = "true"の場合;それから 
          cp "${WORKSPACE_BASIC_AUTH_DIRECTORY_PATH}/.git-credentials"   "${PARAM_USER_HOME}/.git-credentials"  
          cp "${WORKSPACE_BASIC_AUTH_DIRECTORY_PATH}/.gitconfig"   "${PARAM_USER_HOME}/.gitconfig"  
          chmod 400 "${PARAM_USER_HOME}/.git-credentials"  
          chmod 400 "${PARAM_USER_HOME}/.gitconfig"  
        フィ
 
        CHECKOUT_DIR = "${WORKSPACE_OUTPUT_PATH}/${PARAM_SUBDIRECTORY}"   
 
        クリーンディレクトリ() {
          ＃消去 リポジトリ ディレクトリの既存のコンテンツ(存在する場合)。
          #
          # ${CHECKOUT_DIR} が"/"である可能性があるため、単に"rm -rf ${CHECKOUT_DIR}" を実行するだけでは不十分です。  
          #またはマウントされたボリュームのルート。
          [ -d "${CHECKOUT_DIR}" ] の場合;それから 
            #隠しファイルとディレクトリを削除する
            rm -rf "${CHECKOUT_DIR:?}" /*
            #で始まるファイルとディレクトリを削除します。ただし除きます。
            rm -rf "${CHECKOUT_DIR}" /.[!.]*
            # .. とその他の文字で始まるファイルとディレクトリを削除します 
            rm -rf "${CHECKOUT_DIR}" /..?*
          フィ
        } 
 
        [ "${PARAM_DELETE_EXISTING}" = "true"の場合;それから 
          クリーンディレクトリ
        フィ
 
        /ko-app/git-init \
          -url= "${PARAM_URL}" \
          -リビジョン= "${PARAM_REVISION}" \
          -refspec= "${PARAM_REFSPEC}" \
          -path= "${CHECKOUT_DIR}" \
          -sslVerify= "${PARAM_SSL_VERIFY}" \
          -submodules= "${PARAM_SUBMODULES}" \
          -depth= "${PARAM_DEPTH}" \
          -sparseCheckoutDirectories= "${PARAM_SPARSE_CHECKOUT_DIRECTORIES}"  
        cd "${CHECKOUT_DIR}"  
        RESULT_SHA = "$(git rev-parse HEAD)"  
        EXIT_CODE = "$?"  
        [ "${EXIT_CODE}" != 0 ] の場合;それから 
          終了"${EXIT_CODE}"  
        フィ
        printf "%s"   "${RESULT_SHA}" > "$(results.commit.path)"  
        printf "%s"   "${PARAM_URL}" > "$(results.url.path)"  

一般的に言えば、永続化コード用の出力ワークスペースと、URL およびリビジョン パラメータのみを指定し、その他についてはデフォルトを使用します。

ユニットテスト

ユニットテストフェーズは比較的単純です。通常は、テスト コマンドを単純に実行するだけです。ここでは実際にユニットテストは実行しないので、簡単なテストで十分です。以下のようにタスクを記述します。

 # タスクテスト.yaml
 apiバージョン: tekton.dev/v1beta1
種類: タスク
メタデータ:
名前: テスト
仕様:
  手順:
    -名前: テスト
      イメージ: golang:1.14-alpine
      コマンド: [ 'echo' ]
      args: [ 'これはテストタスクです' ]

コンパイルとパッケージ化

2 番目の段階は、コンパイルとパッケージ化の段階です。私たちのプロジェクトの Dockerfile はマルチステージ構築を使用していないため、タスクを使用してアプリケーションをコンパイルし、バイナリ ファイルにパッケージ化し、コンパイルされたファイルをイメージ構築の次のタスクに渡す必要があります。

この段階で何をする必要があるかを明確に定義したので、タスクを記述するのは簡単です。次のタスクを作成するには、まずワークスペースを定義してクローン タスク内のコードを関連付ける必要があります。

 # タスクビルド.yaml
 apiバージョン: tekton.dev/v1beta1
種類: タスク
メタデータ:
名前: ビルド
仕様:
  ワークスペース:
    -名前: go-repo
      マウントパス: /workspace/repo
  手順:
    -名前:ビルド
      イメージ: golang:1.14-alpine
      作業ディレクトリ: /workspace/repo
      スクリプト: |
        ビルド -v -o アプリ
      環境:
        -名前: GOPROXY
          値: https://goproxy.cn
        -名前：GOOS
          値: Linux
        -名前: GOARCH
          値: amd64

このビルドタスクも非常に簡単です。必要な環境変数を env を通じて直接挿入するだけです。もちろん、スクリプトに直接書き込むことも、コマンドを使用してタスクを直接実行することもできます。次に、生成されたアプリのバイナリ ファイルをビルドし、コードのルート ディレクトリに保存して、ワークスペースを通じて共有できるようにします。

Docker イメージ

次のステップは、Docker イメージをビルドしてプッシュすることです。これまで、Kaniko、DooD、DinD という 3 つのイメージ構築モードを紹介してきました。ここでは、DinD モードを直接使用します。ここで構築したいイメージ Dockerfile は非常にシンプルです。

アルパインから
ワークディレクトリ /home 
 
 # アルパインソースをAlibaba Cloudに変更
実行 sed -i 's/dl-cdn.alpinelinux.org/mirrors.ustc.edu.cn/g' /etc/apk/repositories && \
  apkアップデート&& \
  apk アップグレード && \
  apk ca-certificatesを追加&& -ca-certificatesを更新&& \
  apk追加  --tzdata を更新 && \  
  rm -rf /var/cache/apk/* 
 
アプリをコピー /home/
 ENV TZ=アジア/上海
 
エクスポーズ8080 
 
エントリポイント ./app

コンパイルされたバイナリ ファイルをイメージに直接コピーできるため、以前のビルド タスクの成果物を取得するために Workspace も使用する必要があります。もちろん、DinD モードを使用してイメージをビルドするには、サイドカー機能を使用して、以下に示すようにタスクを作成する必要があります。

 #タスクDocker.yaml
 apiバージョン: tekton.dev/v1beta1
種類: タスク
メタデータ:
名前: docker
仕様:
  ワークスペース:
    -名前: go-repo
  パラメータ:
    -名前:画像
      説明:ドッカーが生成するイメージの参照。
    -名前: registry_mirror
      説明: Dockerレジストリミラーを指定します
デフォルト： ""  
    -名前: レジストリURL
      説明: プライベート Docker イメージ レジストリ URL
  手順:
    - name : docker-build # ビルド手順
      イメージ: docker:stable
      環境:
        - name : DOCKER_HOST # TLSを使用してTCP経由でサイドカーに接続します
          値: tcp://localhost:2376
        - name : DOCKER_TLS_VERIFY # TLSを検証する
          値: "1"  
        - name : DOCKER_CERT_PATH # サイドカーデーモンによって生成された証明書を使用する
          値: /certs/client
        -名前: DOCKER_PASSWORD
          値:
            シークレットキーリファレンス:
名前: ハーバー認証
キー:パスワード 
        -名前: DOCKER_USERNAME
          値:
            シークレットキーリファレンス:
名前: ハーバー認証
キー: ユーザー名
      作業ディレクトリ: $(workspaces.go-repo.path)
      スクリプト: | # docker ビルドコマンド
        docker ログイン $(params.registry_url) -u $DOCKER_USERNAME -p $DOCKER_PASSWORD
        イメージをコピーして、Docker イメージをビルドします。  
        docker push $(params.image)
      volumeMounts: #マウント証明書ディレクトリを宣言する
        - マウントパス: /certs/client
名前: dind-certs
  sidecars: # サイドカー モード、docker デーモン サービスを提供し、真の DinD モードを実現します
    - イメージ: docker:dind
名前: サーバー
      引数:
        - --ストレージドライバー=vfs  
        - --userland-proxy=false  
        - --デバッグ 
        - --insecure-registry=$(params.registry_url)  
        - --registry-mirror=$(params.registry_mirror)  
      セキュリティコンテキスト:
        特権: true  
      環境:
        - name : DOCKER_TLS_CERTDIR #生成された証明書をクライアントと共有するパスに書き込みます
          値: /certs
      ボリュームマウント:
        - マウントパス: /certs/client
名前: dind-certs
      readinessProbe: # dindデーモンがクライアントと共有する証明書を生成するのを待ちます
        期間秒数: 1
実行:
          コマンド: [ "ls" , "/certs/client/ca.pem" ]
  ボリューム: # emptyDir を使用する
    -名前:dind-certs
      空ディレクトリ: {}

このタスクの重要なポイントは、ワークスペースを宣言することです。タスクを実行するときは、上記でコンパイルされたアプリのバイナリ ファイルを取得できるように、前のビルド タスクと同じワークスペースを使用する必要があります。

展開する

次のデプロイメント段階では、以前の Jenkins パイプラインの実装を参照することもできます。プロジェクトには Helm Chart パッケージが含まれているため、Helm を直接使用してデプロイできます。もちろん、Helm デプロイメントを実装するには、まず helm コマンドを含むイメージが必要です。もちろん、そのようなタスクを自分で作成することもできます。さらに、カタログを見つけるために hub.tekton.dev に直接アクセスすることもできます。そこには、helm-upgrade-from-source タスクなど、私たちのニーズを完全に満たす一般的なタスクが多数あるためです。

ヘルムテクトン

カタログには完全な使用方法のドキュメントも含まれています。タスクを直接ダウンロードし、以下に示すように、独自のニーズに応じてカスタマイズされた変更を加えることができます。

 # タスクデプロイ.yaml
 apiバージョン: tekton.dev/v1beta1
種類: タスク
メタデータ:
名前: デプロイ
仕様:
  パラメータ:
    -名前: charts_dir
      説明:ソース内のHelmチャートを含むディレクトリ
    -名前:リリース名
      説明: Helm リリース名 
    -名前: リリース名前空間
      説明: Helm リリース名前空間
デフォルト： ""  
    -名前: 上書き値
      説明: 「上書きしたい値をカンマ区切りで指定します: autoscaling.enabled=true,replicas=1」  
デフォルト： ""  
    -名前: values_file
      説明: 「使用する値ファイル」  
デフォルト: "values.yaml"  
    -名前: helm_image
      説明: 「使用する helm イメージ」  
デフォルト: "docker.io/lachlanevenson/k8s-helm:v3.3.4@sha256:e1816be207efbd342cba9d3d32202e237e3de20af350617f8507dc033ea66803" #タグ: v3.3.4
  ワークスペース:
    -名前: ソース
  結果：
    -名前: ヘルムステータス
      説明: Helm デプロイステータス
  手順:
    -名前: アップグレード
      画像: $(params.helm_image)
      作業ディレクトリ: /workspace/source
      スクリプト: |
        現在インストールされている Helm リリースをエコーし​​ます
        helm list --namespace "$(params.release_namespace)"   
 
        echo helm チャートをインストールしています...
        helm アップグレード--install --wait --values ​​"$(params.charts_dir)/$(params.values_file)" --create-namespace --namespace "$(params.release_namespace)" $(params.release_name) $(params.charts_dir) --debug --set "$(params.overwrite_values)"   
 
        ステータス = `helm status $(params.release_name) --namespace "$(params.release_namespace)" | awk '/STATUS/ {$2 を印刷}'`  
        ${ステータス} をエコーし​​ます | tr -d "\n" |ティー $(results.helm-status.path)

Helm Chart テンプレートはコード リポジトリにあるため、Chart Repo リポジトリから取得する必要はありません。チャートのパスを指定するだけです。その他の構成可能なパラメータは、非常に柔軟な params パラメータを通じて公開されます。最後に、Helm デプロイメントのステータスも取得し、それを Results に書き込み、後続のタスク処理を容易にします。

ロールバック

最後に、アプリケーションがデプロイされた後、デプロイされたアプリケーションにエラーが発生する可能性があるため、ロールバックが必要になる場合があります。もちろん、このロールバックは自分でトリガーするのが最善ですが、Helm のデプロイメントが明らかに失敗した場合など、一部のシナリオでは自動的にロールバックできるため、ロールバックを実行する前にデプロイメントが失敗したタイミングを特定する必要があります。つまり、このタスクは必ずしも発生するわけではなく、特定のシナリオでのみ発生します。 WhenExpressions を使用して、パイプラインでこの関数を実装できます。条件は以前のバージョンで使用されていましたが、廃止されました。特定の条件が満たされた場合にのみタスクを実行するには、when フィールドを使用してタスクの実行を保護します。これにより、WhenExpressions への一連の参照をリストできます。

WhenExpressions は入力、演算子、値で構成されます。

• Input は WhenExpressions の入力であり、静的入力または変数 (Params または Results) にすることができます。入力が指定されていない場合は、デフォルトで空の文字列になります。
• 演算子は、入力と値の関係を表す演算子です。有効な演算子にはin、notinなどがある。
• 値は文字列の配列です。空でない値の配列を指定する必要があります。静的な値や変数（Params、Results、Workspacesバインディング）も含めることができます。

タスク内で WhenExpressions が設定されている場合、宣言された WhenExpressions はタスクの実行前に評価されます。結果が True の場合、タスクが実行されます。 False の場合、タスクは実行されません。

ここで作成したロールバック タスクは次のとおりです。

 # タスクロールバック.yaml
 apiバージョン: tekton.dev/v1beta1
種類: タスク
メタデータ:
名前:ロールバック 
仕様:
  パラメータ:
    -名前:リリース名
      説明: Helm リリース名 
    -名前: リリース名前空間
      説明: Helm リリース名前空間
デフォルト： ""  
    -名前: helm_image
      説明: 「使用する helm イメージ」  
デフォルト: "docker.io/lachlanevenson/k8s-helm:v3.3.4@sha256:e1816be207efbd342cba9d3d32202e237e3de20af350617f8507dc033ea66803" #タグ: v3.3.4
  手順:
    -名前:ロールバック 
      画像: $(params.helm_image)
      スクリプト: |
        エコーロールバック 現在インストールされている Helm リリース
        helmロールバック$(params.release_name) --namespace $(params.release_namespace)  

組立ライン

ワークフロー タスク全体が作成されたので、これらすべてのタスクを連続して接続し、Pipeline パイプラインを形成できます。上記で定義したいくつかのタスクをパイプラインに参照します。もちろん、タスクで使用されるリソースまたはワークスペースも宣言する必要があります。

 # パイプライン.yaml
 apiバージョン: tekton.dev/v1beta1
種類: パイプライン
メタデータ:
名前: パイプライン
仕様:
  ワークスペース: # ワークスペースを宣言する
    -名前: go-repo-pvc
  パラメータ:
    # コードリポジトリを定義する
    -名前: git_url
    -名前: リビジョン
      タイプ: 文字列
デフォルト: "master"  
    # 画像パラメータを定義する
    -名前:画像
    -名前: レジストリURL
      タイプ: 文字列
デフォルト: "harbor.k8s.local"  
    -名前: registry_mirror
      タイプ: 文字列
デフォルト: "https://ot2k4d59.mirror.aliyuncs.com/"  
    # Helmチャートパラメータを定義する
    -名前: charts_dir
    -名前:リリース名
    -名前: リリース名前空間
デフォルト: "デフォルト"  
    -名前: 上書き値
デフォルト： ""  
    -名前: values_file
デフォルト: "values.yaml"  
  タスク: #パイプラインにタスクを追加する
    -名前:クローン
      タスク参照:
名前: git-clone
      ワークスペース:
        -名前:出力 
          ワークスペース: go-repo-pvc
      パラメータ:
        -名前: URL
          値: $(params.git_url)
        -名前: リビジョン
          値: $(params.revision)
    -名前: テスト
      タスク参照:
名前: テスト
    - name : build # バイナリプログラムをコンパイルする
      タスク参照:
名前: ビルド
      runAfter: # テストタスクの実行後にビルドタスクを実行する
        - テスト
        - クローン
      ワークスペース: # ワークスペースを渡す
        -名前: go-repo
          ワークスペース: go-repo-pvc
    - name : docker # Dockerイメージをビルドしてプッシュする
      タスク参照:
名前: docker
      実行後:
        - 建てる
      ワークスペース: # ワークスペースを渡す
        -名前: go-repo
          ワークスペース: go-repo-pvc
      params: # パラメータを渡す
        -名前:画像
          値: $(params.image)
        -名前: レジストリURL
          値: $(params.registry_url)
        -名前: registry_mirror
          値: $(params.registry_mirror)
    - name : deploy # アプリケーションをデプロイする
      タスク参照:
名前: デプロイ
      実行後:
        - ドッカー
      ワークスペース:
        -名前: ソース
          ワークスペース: go-repo-pvc
      パラメータ:
        -名前: charts_dir
          値: $(params.charts_dir)
        -名前:リリース名
          値: $(params.release_name)
        -名前: リリース名前空間
          値: $(params.release_namespace)
        -名前: 上書き値
          値: $(params.overwrite_values)
        -名前: values_file
          値: $(params.values_file)
    -名前:ロールバック# ロールバック
      タスク参照:
名前:ロールバック 
いつ：
        - 入力: "$(tasks.deploy.results.helm-status)"  
          演算子: in  
値: [ "失敗" ]
      パラメータ:
        -名前:リリース名
          値: $(params.release_name)
        -名前: リリース名前空間
          値: $(params.release_namespace)

全体的なプロセスは比較的簡単です。パイプラインでは、ワークスペース、リソース、パラメーターなどの使用するリソースを宣言し、宣言したデータをタスクに渡す必要があります。最後のロールバックタスクでは、前回のデプロイタスクの結果に基づいてタスクを実行するかどうかを決定する必要があることに注意してください。そのため、ここでは when 属性を使用して、$(tasks.deploy.results.helm-status) を通じてデプロイステータスを取得します。

実行パイプライン

これで、パイプラインを実行して、独自の要件を満たしているかどうかを確認できます。まず、Workspace に対応する PVC や、GitLab および Harbor の認証情報など、関連するその他のリソース オブジェクトを作成する必要があります。

 # その他の.yaml
 APIバージョン: v1
種類: 秘密
メタデータ:
名前: gitlab-auth
  注釈:
    tekton.dev/git-0: http : //git.k8s.local  
タイプ: kubernetes.io/basic-auth
文字列データ:
  ユーザー名: root
パスワード: admin321 
 
 ---   
 
 APIバージョン: v1
種類: 秘密
メタデータ:
名前: ハーバー認証
  注釈:
    tekton.dev/docker-0: http : //harbor.k8s.local  
タイプ: kubernetes.io/basic-auth
文字列データ:
    ユーザー名: admin
パスワード: Harbor12345 
 
 ---  
 APIバージョン: v1
種類: サービスアカウント
メタデータ:
名前: tekton-build-sa
秘密:
  -名前: harbor-auth
  -名前: gitlab-auth 
 
 ---   
 
 apiバージョン: rbac。認証.k8s.io/v1
種類: ClusterRoleBinding
メタデータ:
名前: tekton-clusterrole-binding
ロールリファレンス:
  apiGroup : rbac.authorization.k8s.io
  種類: ClusterRole
名前: 編集
科目:
 - 種類: サービスアカウント
名前: tekton-build-sa
  名前空間:デフォルト  
 
 ---  
 APIバージョン: v1
種類: PersistentVolumeClaim
メタデータ:
名前: go-repo-pvc
仕様:
  リソース：
    リクエスト:
      ストレージ: 1Gi
  ボリュームモード: ファイルシステム
  storageClassName: nfs-storage # StorageClassを使用してPVを自動的に生成します
  アクセスモード:
    -一度だけ読み書き可能

これらの関連リソース オブジェクトが作成された後、上記の ServiceAccount にアクセス許可をバインドする必要もあります。 Helm コンテナ内でいくつかのクラスター リソースを操作する必要があるため、最初に権限を宣言する必要があります。ここで、tekton-build-sa を編集 ClusterRole にバインドできます。

次に、パイプライン ビルドをトリガーする PipelineRun リソース オブジェクトを作成します。

 # パイプライン実行.yaml
 apiバージョン: tekton.dev/v1beta1
種類: PipelineRun
メタデータ:
名前: パイプライン実行
仕様:
  サービスアカウント名: tekton-build-sa
  パイプライン参照:
名前: パイプライン
  ワークスペース:
    -名前: go-repo-pvc
      永続ボリュームクレーム:
        クレーム名: go-repo-pvc
  パラメータ:
    -名前: git_url
      値: http://git.k8s。ローカル/course/devops-demo.git
    -名前:画像
      値: "harbor.k8s.local/course/devops-demo:v0.1.0"  
    -名前: charts_dir
      値: "./helm"  
    -名前:リリース名
      値: devops-demo
    -名前: リリース名前空間
      値: "kube-ops"  
    -名前: 上書き値
      値: "image.repository=harbor.k8s.local/course/devops-demo,image.tag=v0.1.0"  
    -名前: values_file
      値: "my-values.yaml"  

Pipeline パイプラインを実行するには、上記のリソース オブジェクトを作成するだけです。

 $ kubectl apply -f パイプライン実行.yaml
 $ tkn pr パイプライン実行を記述する
名前: pipelinerun
名前空間:デフォルト 
パイプライン参照: パイプライン
サービスアカウント: tekton-build-sa
タイムアウト: 1時間0分0秒
ラベル:
 tekton.dev/pipeline=パイプライン
 
 🌡️ ステータス
 
開始期間ステータス
1分前 1分成功しました(完了) 
 
 📦 リソース
 
リソースなし
 
 ⚓ パラメータ
 
名前値
 ∙ git_url http://git.k8s.ローカル/course/devops-demo.git
 ∙ 画像 harbor.k8s。ローカル/course/devops-demo:v0.1.0
 ∙ charts_dir ./helm
 ∙ リリース名 devops-demo
 ∙ release_namespace kube-ops
 ∙ overwrite_values ​​image.repository=harbor.k8s。ローカル/course/devops-demo、image.tag=v0.1.0
 ∙ values_file my- values ​​.yaml 
 
 📝 結果
 
結果なし
 
 📂 ワークスペース
 
名前サブパス ワークスペース バインディング
 ∙ go-repo-pvc --- PersistentVolumeClaim (claimName=go-repo-pvc)   
 
 🗂 タスクラン
 
名前タスク名開始 所要時間 ステータス
 ∙ pipelinerun-deploy-zpmg9 デプロイ 33 秒前 15 秒 成功
 ∙ pipelinerun-docker-rkhxq docker 1分前 45秒 成功
 ∙ pipelinerun-build-gnnsp ビルド 1分前 15 秒 成功
 ∙ pipelinerun-test-z5ppb テスト 1分前 5 秒 成功
 ∙ pipelinerun-clone-xdrjh クローン 1分前 8 秒 成功
 
 # デプロイメントに成功しました
$ curl devops- demo.k8s.localを実行します。  
 { "msg" : "Kubernetes での DevOps へようこそ" }

ダッシュボードでは、パイプラインが正常に実行できることも確認できます。デプロイメントは成功したため、ロールバック タスクは無視されます。

パイプラインを展開

トリガー

パイプライン全体が正常に実行されました。次の最後のステップは、Gitlab と Tekton を接続すること、つまり、Tekton Trigger を通じてビルドを自動的にトリガーすることです。 Tekton Trigger の使用方法についてはすでに詳しく説明したので、ここでは詳しく説明しません。もちろん、使用する前にインターセプターをデプロイする必要があります。

 kubectl apply -f https://storage.googleapis.com/tekton-releases/triggers/previous/v0.14.2/interceptors.yaml

まず、Gitlab Webhook アクセス用のシークレット トークンを追加します。また、この Secret を上記で使用した ServiceAccount に関連付け、対応する RBAC 権限の追加を続けます。

 # その他の.yaml
 # ......
 APIバージョン: v1
種類: 秘密
メタデータ:
名前: gitlab-secret
タイプ: 不透明
文字列データ:
  シークレットトークン: "1234567"   
 
 ---   
 
 APIバージョン: v1
種類: サービスアカウント
メタデータ:
名前: tekton-build-sa
秘密:
  -名前: harbor-auth
  -名前: gitlab-auth
  -名前: gitlab-secret 
 
 ---  
 apiバージョン: rbac。認証.k8s.io/v1
種類: 役割
メタデータ:
名前: tekton-triggers-gitlab-minimal
ルール:
 #イベントリスナーは フェッチ すべての名前空間リソース
- apiグループ: [ "triggers.tekton.dev" ]
  リソース: [ "イベントリスナー" 、 "トリガーバインディング" 、 "トリガーテンプレート" 、 "トリガー" ]
  動詞: [ 「取得する」 、 「一覧表示する」 、 「見る」 ]
 -apiグループ: [ "" ]
 #ログ設定を更新するにはconfigmapsが必要です
  リソース: [ "configmaps" ]
  動詞: [ 「取得する」 、 「一覧表示する」 、 「見る」 ]
 #権限 関連するトリガーテンプレートにリソースを作成する
-apiグループ: [ "tekton.dev" ]
  リソース: [ "pipelineruns" 、 "pipelineresources" 、 "taskruns" ]
  動詞: [ "作成する" ]
 -apiグループ: [ "" ]
  リソース: [ "serviceaccounts" ]
  動詞: [ 「なりすます」 ]
 -apiGroups: [ "ポリシー" ]
  リソース: [ "podsecuritypolicies" ]
  resourceNames: [ "tekton-triggers" ]
  動詞: [ "使用する" ]
 ---  
 apiバージョン: rbac。認証.k8s.io/v1
種類: RoleBinding
メタデータ:
名前: tekton-triggers-gitlab-binding
科目:
 - 種類: サービスアカウント
名前: tekton-build-sa
ロールリファレンス:
  apiGroup : rbac.authorization.k8s.io
  種類: 役割
名前: tekton-triggers-gitlab-minimal
 ---  
種類: ClusterRole
 apiバージョン: rbac。認証.k8s.io/v1
メタデータ:
名前: tekton-triggers-gitlab-clusterrole
ルール:
  #イベントリスナーは フェッチ 任意のクラスタートリガーバインディング
- apiグループ: [ "triggers.tekton.dev" ]
  リソース: [ "clustertriggerbindings" 、 "clusterinterceptors" ]
  動詞: [ 「取得する」 、 「一覧表示する」 、 「見る」 ]
 ---  
 apiバージョン: rbac。認証.k8s.io/v1
種類: ClusterRoleBinding
メタデータ:
名前: tekton-triggers-gitlab-clusterbinding
科目:
 - 種類: サービスアカウント
名前: tekton-build-sa
  名前空間:デフォルト 
ロールリファレンス:
  apiGroup : rbac.authorization.k8s.io
  種類: ClusterRole
名前: tekton-triggers-gitlab-clusterrole

次に、次に示すように、Gitlab の Push Event イベントを受信するための EventListener リソース オブジェクトを作成できます。

 # gitlab-リスナー.yaml
 apiバージョン: triggers.tekton.dev/v1alpha1
種類: イベントリスナー
メタデータ:
 name : gitlab-listener # このイベントリスナーはel-gitlab-listenerという名前のサービスオブジェクトを作成します
仕様:
  サービスアカウント名: tekton-build-sa
  トリガー:
  -名前: gitlab-push-events-トリガー 
    迎撃機:
    - 参照:
名前: gitlab
      パラメータ:
      - name : secretRef # gitlab-secret の Secret オブジェクト内の secretToken の値を参照します
        価値：
          シークレット名: gitlab-secret
          シークレットキー: シークレットトークン
      -名前: イベントタイプ
        価値：
          - プッシュフック # GitLab プッシュイベントのみを受信する
    バインディング: #TriggerBinding を定義し、パラメータを構成する
    -名前: gitrevision
      値: $(body.checkout_sha)
    -名前: gitリポジトリURL
      値: $(body.repository.git_http_url)
    テンプレート：
      参照: gitlab-テンプレート

上記では、TriggerBinding を通じて gitrevision と gitrepositoryurl の 2 つのパラメータを定義しました。これら 2 つのパラメータの値は、Gitlab から送信された POST リクエストから取得でき、その後、これら 2 つのパラメータを TriggerTemplate オブジェクトに渡すことができます。ここでのテンプレートは、実際には上で定義した PipelineRun オブジェクトのテンプレートであり、以下に示すように、主に 2 つのパラメーター git_url と mirror TAG を置き換えます。

 # gitlab-テンプレート.yaml
 apiバージョン: triggers.tekton.dev/v1alpha1
種類: トリガーテンプレート
メタデータ:
名前: gitlab-template
仕様:
  params: #TriggerBinding と一致するパラメータを定義します
    -名前: gitrevision
    -名前: gitリポジトリURL
  resourcetemplates: #リソーステンプレートを定義する
    - apiバージョン: tekton.dev/v1beta1
      kind: PipelineRun # パイプラインテンプレートを定義する
      メタデータ:
        generateName: gitlab-run- # TaskRun 名のプレフィックス
      仕様:
        サービスアカウント名: tekton-build-sa
        パイプライン参照:
名前: パイプライン
        ワークスペース:
          -名前: go-repo-pvc
            永続ボリュームクレーム:
              クレーム名: go-repo-pvc
        パラメータ:
          -名前: git_url
            値: $(tt.params.gitrepositoryurl)
          -名前:画像
            値: "harbor.k8s.local/course/devops-demo:$(tt.params.gitrevision)"  
          -名前: charts_dir
            値: "./helm"  
          -名前:リリース名
            値: devops-demo
          -名前: リリース名前空間
            値: "kube-ops"  
          -名前: 上書き値
            値: "image.repository=harbor.k8s.local/course/devops-demo,image.tag=$(tt.params.gitrevision)"  
          -名前: values_file
            値: "my-values.yaml"  

上記で作成したリソース オブジェクトを作成するだけです。これにより、Webhook リクエストを受信するためのイベント リスト サービスが作成されます。

 $ kubectl イベントリスナーを取得する
名前住所 利用可能理由 準備完了理由
gitlab-listener http://el-gitlab-listener.デフォルトは.svc.cluster です。ローカル:8080 True MinimumReplicasAvailable True  

したがって、Gitlab リポジトリで Webhook を必ず設定してください。

GitLabウェブフック

このようにして、トリガーとリスナー全体が構成されます。次に、プロジェクト コードを変更してコードを送信します。通常の送信後、パイプラインを実行するための PipelinRun オブジェクトがクラスター内に作成されます。

 $ kubectl パイプライン実行を取得します
名前成功 理由 開始時間 完了時間
gitlab-run-kx6zr真完了 2分14秒50秒
$ curl devops- demo.k8s.localを実行します。  
 { "msg" : "こんにちは、Tekton" }

パイプラインが正常に実行されると、アプリケーションが新しく送信したコードが正常にデプロイされたことがわかります。この時点で、Tekton を使用してプロジェクトをリファクタリングするパイプラインが完了しました。