上記では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
(2)tknクライアントを使用してインストールします。 tkn hub インストールタスクgit - クローン
ここでは 2 番目のインストール方法を使用します。インストール後に特定のタスクを確認できます。 タスクgit - clone ( 0.5 ) がデフォルトの名前空間にインストールされました
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 : 作成します。
上記コマンドを実行した際に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。 要約するパイプライン全体は単純に見えますが、定義されたパラメータが渡されたり指定し忘れられたりすることがあるため、デバッグには多少の労力がかかります。そのため、継続的なデバッグが必要になります。 |