Tektonを物理マシンに接続して構築する方法

[[396376]]

この記事はWeChatの公開アカウント「Ask Qi」から転載したもので、著者はChen Shaowenです。記事を転載する場合は公式アカウントまでご連絡ください。

1. 物理的なビルドマシンが必要なのはなぜですか?

記事「Jenkins パイプラインビルドのためにリモート macOS 物理マシンに接続する方法」では、Jenkins に物理ビルドマシンを追加する方法について説明しました。これは私が衝動的に思いついた要望ではなく、当時、実際に ToB のビジネスクライアントからソリューションについて相談を受けていました。

マルチターミナル開発者にとって、Android、IOS、macOS、Arm、Windows、X86 アプリケーションの構築は一般的な要件です。

良いニュースとしては、GitHub Actions が macOS ビルド環境を提供し、AWS が macOS 仮想マシンを提供し、Huawei が ARM ホストを提供していることです。クラウドネイティブのコンテキストでは、Kubernetes ランタイムがより一般的に使用されます。 Kubernetes がサポートしていないプロセッサアーキテクチャとオペレーティングシステムの場合、継続的インテグレーション (CI) は無力であるように思われます。継続的インテグレーションには、物理的なビルドマシンのサポートが必要です。

この記事では、Kubernetes での CI 構築のために物理マシンにアクセスする方法について説明します。この記事ではTektonを例に挙げます。他のエンジンにも同様の処理ロジックがあります。

2. Tekton は物理マシンとどのように対話しますか?

Kubernetes による物理マシンまたは仮想マシンの管理は、実際には典型的な Operator シナリオです。関連するフィールドを記述する CRD を定義し、Pod とビルダー間のロジックを処理するコントローラーを記述できます。

Tekton タスクのカプセル化を記述することもできます。この記事ではこれを使用します。これにより、別の疑問も生じます。Tekton は一部の Operator シナリオを置き換えることができますか?次回以降の記事で私の考えを述べたいと思います。

ここではプロトタイプの検証のみを行い、製品化の詳細についてはあまり注意を払いません。

Tekton では、各パイプラインは多数のタスクで構成され、タスクは並列に実行できます。タスクには、多数のコンテナを含むポッドに対応する多数のシリアルステップが含まれます。

ここで重要なのは、Pod をビルドマシンに関連付けることです。私は、Pod とビルドマシン間でファイルを同期するために rsync を使用し、物理マシン上でビルドコマンドを実行するために Pod で sshpass を使用することを選択しました。

主に以下のステップに分かれています（以下のコマンドはすべてコンテナ内で実行されます）。

クローンコード
rsyncを実行してコードをビルドマシンに同期します
sshpassを実行してビルドマシンでビルドコマンドを実行します。
rsyncを実行して、ビルドマシン内のビルド製品をコンテナに同期します。
ビルド製品をアーカイブする（この例では、この手順は省略され、ビルド製品が取得できることのみを確認します）

実際のところ、プロセス全体は Tekton に直接関係しているわけではなく、コンテナがビルドマシンに直接接続されているあらゆる環境で実行可能であることがわかります。次のデモンストレーションでは、Tekton を例に挙げます。

3. リソース準備リスト

Kubernetes クラスター。 Tekton を実行するために使用されます。最新のTekton 0.23ではKubernetesが1.17以上である必要があります。
物理マシンまたは仮想マシン。建築アプリケーション向け

3.1 Kubernetesのバージョンを確認する

kubectl バージョン
 
クライアント バージョン: version.Info{メジャー: "1" 、マイナー: "19" 、GitVersion: "v1.19.7" 、GitCommit: "1dd5338295409edcfff11505e7bb246f0d325d15" 、GitTreeState: "clean" 、BuildDate: "2021-01-13T13:23:52Z" 、GoVersion: "go1.15.5" 、コンパイラ: "gc" 、プラットフォーム: "darwin/amd64" }
サーバー バージョン: version.Info{メジャー: "1" 、マイナー: "20" 、GitVersion: "v1.20.2" 、GitCommit: "faecb196815e248d3ecfb03c680a4507229c2a56" 、GitTreeState: "clean" 、BuildDate: "2021-01-21T01:11:42Z" 、GoVersion: "go1.15.5" 、コンパイラ: "gc" 、プラットフォーム: "linux/amd64" }

3.2 物理マシンの準備

オペレーティングシステムはCentOS 7.6です

ユーネーム -a 
 
 Linux テスト 3.10.0-957.21.3.el7.x86_64 #1 SMP 2019 年 6 月 18 日火曜日 16:35:19 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

プリインストールされたGolangコンパイル環境

当初の計画では macOS ビルド例を選択する予定でしたが、直接ネットワーク環境を提供できなかったため、代わりに Golang ビルド例が使用されました。

移動バージョン
 
 go バージョン go1.13 linux/amd64

4. TektonとPipelineのリソースを準備する

4.1 Tektonパイプラインのデプロイ

負荷を作成する

Tekton はデフォルトで gcr.io イメージを使用します。国内環境であれば、gcr.azk8s.cn イメージに置き換えることが可能です。

 kubectl apply -f https://github.com/tektoncd/pipeline/releases/download/v0.23.0/release.notags.yaml

リソースを表示

4.2 リソース計画

kubectl -n tekton-pipelines はすべてを取得します  
 
名前準備完了 ステータス 再起動 年齢
pod/tekton-pipelines-controller-86c487c965-p6s5t 1/1 実行中 0 51秒
pod/tekton-pipelines-webhook-7b775d9cd8-fzdrq 1/1 実行中 0 51秒
 
名前タイプ クラスター IP 外部 IP ポート 年齢
service/tekton-pipelines-controller ClusterIP 10.233.61.46 <なし> 9090/TCP、8080/TCP 51秒
service/tekton-pipelines-webhook ClusterIP 10.233.46.233 <なし> 9090/TCP、8008/TCP、443/TCP、8080/TCP 51 秒
 
名前準備完了最新利用可能年齢
デプロイメント.apps/tekton-pipelines-controller 1/1 1 1 51秒
デプロイメント.apps/tekton-pipelines-webhook 1/1 1 1 51秒
 
名前希望現在の年齢
レプリカセット.apps/tekton-pipelines-controller-86c487c965 1 1 1 51s
レプリカセット.apps/tekton-pipelines-webhook-7b775d9cd8 1 1 1 51s 
 
名前参照 ターゲット MINPODS MAXPODS レプリカ 年齢
horizonpodautoscaler.autoscaling/tekton-pipelines-webhook Deployment/tekton-pipelines-webhook <不明>/100% 1 5 1 51秒

必要なパイプラインリソースのリスト:

コードを複製するタスク
タスク間でファイルを共有するために使用されるpv
コードをビルドマシンに同期し、ビルドが完了した後に再度同期するために使用されるカスタムタスク
パイプラインは、パイプラインを記述し、タスクを配置するために使用されます。
パイプラインをインスタンス化し、構築に必要なパラメータを提供するために使用されるパイプライン実行

4.2 ファイルの同期とスクリプトの実行のためのタスクの作成

上の図に示すように、ここでのタスクは、コンテナと VM 間のファイルとプロセスを接続して、クロスコンパイルのような効果を実現するために使用されます。

 ---  
 apiバージョン: tekton.dev/v1beta1
種類: タスク
メタデータ:
名前: リモートシェル
  ラベル:
    app.kubernetes.io/バージョン: "0.1"  
  注釈:
    tekton.dev/pipelines.minバージョン: "0.12.1"  
    tekton.dev/タグ:git
    tekton.dev/displayName: 「リモート シェル」  
仕様:
  説明: >-
    このタスクはリモートマシンでシェルを実行するために使用できます
  ワークスペース:
  -名前: ソース
  パラメータ:
  -名前: リモートIP
    タイプ: 文字列
  -名前: リモートポート
    タイプ: 文字列
  -名前: リモートユーザー名
    タイプ: 文字列
  -名前: リモート-パスワード 
    タイプ: 文字列
  -名前: リモートワークスペース
    タイプ: 文字列
  -名前: リモートスクリプト
    タイプ: 文字列
  手順:
  -名前: リモートシェル
    イメージ: shaowenchen/rsync-sshpass:v1
    作業ディレクトリ: $(workspaces.source.path)
    スクリプト: |
      sshpass -p "$(params.remote-password)" ssh -o StrictHostKeyChecking= no   "$(params.remote-username)" @ "$(params.remote-ip)" -p "$(params.remote-port)"   「mkdir -p $(params.remote-workspace)」   
 
      rsync -ratlz --progress --rsh="sshpass -p $(params.remote-password) ssh -o StrictHostKeyChecking=no -l $(params.remote-username)" ./ "$(params.remote-ip)":"$(params.remote-workspace)"   
 
      sshpass -p "$(params.remote-password)" ssh -o StrictHostKeyChecking= no   "$(params.remote-username)" @ "$(params.remote-ip)" -p "$(params.remote-port)"   "$(params.remote-script)"   
 
      rsync -ratlz --progress --rsh="sshpass -p $(params.remote-password) ssh -o StrictHostKeyChecking=no -l $(params.remote-username)" "$(params.remote-ip)":"$(params.remote-workspace)"/ 。

記述方法については、Tekton が提供する例を参照してください。主にいくつかのステップに分かれています。

パラメータの定義
書き込み手順の流れ
スクリプトの作成

これはスクリプト文字列のプロセスですが、コンテナイメージの助けを借りて、さまざまなツールをインストールする手順が省略されます。

4.3 Tektonパイプラインの説明の準備

クローンコードタスク

Tekton はタスクを共有するためのハブサービスを正式に開始しました。ここでは https://hub.tekton.dev/tekton/task/git-clone を直接使用します。

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

ツールボックスイメージ shaowenchen/rsync-sshpass:v1 をビルドします。

Dockerfile は次のとおりです。

 ARGアルパイン_ver=3.13
アルパインより:${alpine_ver}.5 
 
 apkアップデートを実行\
 && apk アップグレード \
 && apk追加  --キャッシュなし\  
            rsync \
            opensshクライアント\
            オープンシュ\
            sshpass \
            ca証明書\
 && -ca-証明書を更新\
 && rm -rf /var/cache/apk/*

パイプライン

apiバージョン: tekton.dev/v1beta1
種類: パイプライン
メタデータ:
名前: リモートビルドパイプライン
仕様:
  パラメータ:
  -名前: リポジトリ URL
    タイプ: 文字列
  -名前: 支店名 
    タイプ: 文字列
  -名前: リモートIP
    タイプ: 文字列
  -名前: リモートポート
    タイプ: 文字列
  -名前: リモートユーザー名
    タイプ: 文字列
  -名前: リモート-パスワード 
    タイプ: 文字列
  -名前: リモートワークスペース
    タイプ: 文字列
  -名前: リモートスクリプト
    タイプ: 文字列
  ワークスペース:
  -名前: 共有データ
  タスク:
  -名前:フェッチ-repo
    タスク参照:
名前: git-clone
    ワークスペース:
    -名前:出力 
      ワークスペース: 共有データ
    パラメータ:
    -名前: URL
      値: $(params.repo-url)
    -名前: リビジョン
      値: $(params.branch- name )
  -名前: リモートビルド
    タスク参照:
名前: リモートシェル
    runAfter: [ "リポジトリの取得" ]
    ワークスペース:
    -名前: ソース
      ワークスペース: 共有データ
    パラメータ:
    -名前: リモートIP
      値: $(params.remote-ip)
    -名前: リモートポート
      値: $(params.remote-port)
    -名前: リモートユーザー名
      値: $(params.remote-username)
    -名前: リモート-パスワード 
      値: $(params.remote-パスワード)
    -名前: リモートワークスペース
      値: $(params.remote-workspace)
    -名前: リモートスクリプト
      値: $(params.remote-script)

パイプラインには、コードを複製するタスクとリモートビルドを実行するタスクの 2 つのタスクが含まれています。

パイプライン実行

---  
 apiバージョン: tekton.dev/v1beta1
種類: PipelineRun
メタデータ:
名前: リモートビルドパイプライン実行 1
仕様:
  パイプライン参照:
名前: リモートビルドパイプライン
  ワークスペース:
  -名前: 共有データ
    ボリュームクレームテンプレート:
      仕様:
        アクセスモード:
        -一度だけ読み書き可能
        リソース：
          リクエスト:
            ストレージ: 10Gi
  パラメータ:
  -名前: リポジトリ URL
    値: https://github.com/shaowenchen/terraform-provider-qingcloud.git
  -名前: 支店名 
    値: マスター
  -名前: サブディレクトリ
    値: terraform-provider-qingcloud-001
  -名前: リモートIP
    値: 0.0.0.0
  -名前: リモートポート
    値: "22"  
  -名前: リモートユーザー名
    値: ルート
  -名前: リモート-パスワード 
    値: パスワード
  -名前: リモートワークスペース
    値: ~/workspaces/terraform-provider-qingcloud-001
  -名前: リモートスクリプト
    値: |
        cd ~/workspaces/terraform-provider-qingcloud-001
        作る

ここで、コードは pv の terraform-provider-qingcloud-001 ディレクトリにクローンされ、ビルダーの ~/workspaces/terraform-provider-qingcloud-001 ディレクトリに同期されます。つまり、これら 2 つのディレクトリ内の最終ファイルは一貫性があり、ビルドされたバイナリはビルドマシン上で生成されます。

Tekton リソース定義を表示

上記のすべてのリソースが適用されると、関連するリソースとパイプラインのステータスを表示できます。

 kubectl タスクの取得
 
名前年齢
git クローン 18 分
リモートシェル 5分47秒

kubectl パイプライン実行を取得する
 
名前成功 理由 開始時間 完了時間
remote-build-pipelinerun-1成功6分15秒 5分42秒

実行は成功しました。次に、機能が期待どおりであるかどうかを検証し続けます。

5. 機能検証

関連する荷物を表示

kubectl ポッドを取得する
 
名前準備完了 ステータス 再起動 年齢
remote-build-pipelinerun-1- fetch -repo-56ws8-pod-mgx77 0/1 完了 0 8分49秒
remote-build-pipelinerun-1-remote-build-wxtms-pod-bcn6r 0/1 完了 0 8分35秒

物理ビルドマシンでビルドディレクトリを表示する

パスワード
 
 /root/ワークスペース/terraform-provider-qingcloud-001 
 
 ls 
 
 CHANGELOG.md glide.yaml に移動します。合計main.go qingcloud スクリプト terraform-provider-qingcloud ウェブサイト
dev.md go.mod LICENSE Makefile README.md terraform ベンダー

Kubernetes PVのビルドディレクトリを表示する

kubectl PV を取得する
 
名前容量 アクセスモード 回収ポリシー ステータス 請求 ストレージクラス
pvc-860016bb-14b6-414a-9c5a-1a71d7290ba8 10Gi RWO削除バインドデフォルト/pvc-e7ceb0582a openebs-hostpath 2m12s

PVストレージパスの検索

kubectl describe pv pvc-860016bb-14b6-414a-9c5a-1a71d7290ba8 |grep パス
 
    パス: /var/openebs/ローカル/pvc-860016bb-14b6-414a-9c5a-1a71d7290ba8

PVディレクトリのファイル構造を表示する

ls /var/openebs/ローカル/pvc-860016bb-14b6-414a-9c5a-1a71d7290ba8 
 
 CHANGELOG.md glide.yaml に移動します。合計main.go qingcloud スクリプト terraform-provider-qingcloud ウェブサイト
dev.md go.mod LICENSE Makefile README.md terraform ベンダー

両方のディレクトリにビルド製品 terraform-provider-qingcloud が存在し、これは期待どおりであり、目標を達成したことを示しています。

6. 結論

従来の CICD エンジンは通常、C/S アーキテクチャです。プロセスを解析し、パイプラインをスケジュールするには S エンドが必要です。高負荷のビルドタスクを実行するには、多くの C エンドが必要になります。この方法のスケーラビリティは線形ではなく、クラウドネイティブではビジネス量が多い場合にボトルネックが発生しやすくなります。したがって、よりクラウドネイティブなビルドエンジンが必要になります。新しいエンジンではいくつかの古い問題を解決する必要があり、物理マシンビルドのサポートもその 1 つです。

この記事では主にTektonを例に挙げ、rsyncとsshpassを使って構築用の物理マシンにアクセスするアイデアを紹介します。要点は次のとおりです。

rsync\sshpass を使用する主な目的は、コンテナを物理マシンにバインドし、双方向でファイルを同期し、プロセス空間を通信することです。
この方法は、Tekton だけでなく、どのエンジンでも使用できます。
これは単なるソリューションの検証です。製品に実装する場合は、キャッシュ、キーのセキュリティ、データのセキュリティ、テナントの分離などの問題を考慮する必要があります。

<<: PingCAP は、完全な HTAP 機能を備えた分散データベースを構築する TiDB 5.0 をリリースしました。

>>: 従来のビジネスをパブリッククラウドに移行する際の落とし穴を回避するためのガイド