DUICUO

すぐに習得できるZadig初心者向けチュートリアル!

Zadigは、KodeRoverがKubernetesをベースに設計・開発したオープンソースの分散型継続的デリバリー製品です。柔軟で使いやすい高並列ワークフロー、開発者向けのクラウドネイティブ環境、効率的で協調的なテスト管理、強力でメンテナンスフリーのテンプレートライブラリ、客観的かつ正確なパフォーマンス分析、クラウドネイティブIDEプラグインといった主要機能を誇り、エンジニアに統合されたコラボレーションプラットフォームを提供します。Zadigは、Kubernetes YAML、Helm Charts、ホストといった複雑なシナリオ向けのベストプラクティスを取り入れており、大規模なマイクロサービスや高頻度・高品質なデリバリーシナリオに適しています。

コアコンセプト

Zadig を使用する前に、まずその中核となる概念のいくつかを理解しましょう。

  • プロジェクト:Zadig のプロジェクトには、ワークフロー、環境、サービス、ビルド、テスト、バージョンなどのリソースが含まれます。ユーザーは、プロジェクト内でサービス開発、サービスデプロイ、統合テスト、バージョンリリースなどの操作を実行できます。
  • ワークフロー:典型的なソフトウェア開発プロセスは、一般的にコードの記述 -> ビルド -> デプロイ -> テスト -> リリースというステップで構成されます。ワークフローは、Zadig プラットフォームにおけるこのような開発プロセスの実装であり、ワークフローを通じて環境内のサービスや設定を更新します。
  • ワークフロー コンポーネント: Zadig ワークフローの簡略化された図を以下に示します。

  • 現在、ワークフローの基本コンポーネントは次のとおりです。
  • ビルド: コードをプルしてビルドを実行します。
  • デプロイメント: ビルド成果物をテスト環境にデプロイします。
  • テスト: 自動テストを実行して、デプロイメントの結果を確認します。
  • 配布: テストと検証が完了すると、ビルド成果物はリポジトリに配布され、リリースされます。
  • 環境: Zadig 環境は、サービスとその構成およびランタイム環境の集合です。Kubernetes 名前空間と 1 対 1 で対応しています。単一のサービステンプレートを使用して複数の環境を作成できます。
  • サービス:Zadigにおけるサービスは、Ingress、Service、Deployment/StatefulSet、ConfigMapなどを含むKubernetesリソースのセットとして理解できます。また、完全なHelm Chartやクラウドホスト/物理マシンサービスとして理解することもできます。デプロイが成功すると、外部にサービス機能を提供できるようになります。
  • サービスコンポーネント:サービスコンポーネントは、Zadigにおける更新可能な最小単位であり、Kubernetesをインフラストラクチャとして利用するプロジェクトにおける概念です。サービスには複数のサービスコンポーネントを含めることができます。各プロジェクトにおけるサービスコンポーネントに関する情報は、以下の表に示されています。

  • サービスコンポーネントはサービスビルド設定の一部です。サービスコンポーネントのビルドを設定したら、ワークフロー実行時に対応するサービスコンポーネントを選択して更新できます。
  • ビルド:Zadigビルドはサービス設定の一部であり、ワークフロー実行フェーズで呼び出されます。サービスと1対多の対応関係にあるため、1つのビルドを複数のサービスで共有できます。
  • テスト: Zadig テストはプロジェクトのリソースですが、ワークフロー内で必須ではないステージとして呼び出すこともでき、プロジェクト間での使用をサポートします。
  • バージョン管理: Zadig バージョンは、Helm Chart や完全な K8s YAML 構成ファイルなどの完全で信頼性の高い成果物です。

インストール

ここでは、インストールに Helm を使用することを選択します。

 $ helm リポジトリkoderover を追加します- チャートhttps://koderover.tencentcloudcr.com/chartrepo/chart
$ helm リポジトリの更新

チャート パッケージを取得します。

 $ helm pull koderover - chart / zadig -- untar

以下のように値ファイル (ci/local-values.yaml) を作成します。

 # ci / local - .yaml
タグ:
mongodb :
minio本当
イングレスコントローラ: false
MySQL :
終点
タイプ: FQDN
FQDN : zadig.k8s.local
デックス
設定:
静的クライアント:
- id : zadig
リダイレクトURI :
- 'http://zadig.k8s.local/api/v1/callback'
名前: 'zadig'
秘密: ZXhhbXBsZS1hcHAtc2VjcmV0

Zadig には MongoDB、MinIO、MySQL のサービスが必要です。外部サービスが利用できない場合は、組み込みサービスを使用できます。これらのサービスを有効にするかどうかは、`tags` のプロパティで設定できます。`endpoint.FQDN` は、Zadig サービスのアドレスを設定するために使用されます。その後、`values` ファイルを使用して Zadig をデプロイできます。

 $ kubectl 作成ns zadig
$ helm upgrade -- zadig をインストールします- f ci / ローカル- yaml -- 名前空間zadig
名前ザディグ
最終展開日: 2022年7月11 月曜日14:21:16
名前空間: zadig
ステータス: 展開済み
改訂1
テストスイート: なし
注記:
Zadig正常にインストールされました
最初ログイン用に初期アカウント生成されました:
- ログイン: zadig.k8s.local
- ユーザー: admin
- パスワード: zadig

WeChat ID 「guotimeme」 を追加するとZadig テクニカルサポートを無料で受けることができ オンラインコミュニティ参加できます

デプロイ後、Zadig 関連サービスのステータスを確認します。

 $ kubectl ポッドを取得-n zadig
名前準備完了ステータス再起動年齢
aslan - 69 d6759654 - rtsrn 2 / 2 ランニング0 155 m
config - 547f b89564 - vkj84 1 / 1 実行中1 ( 153 ) 155
cron - f8544788c - 5 b8fl 2 / 2 実行中1 ( 143 ) 155
dind - 0 1 / 1 ランニング0 155 m
ディスカバリー- 74945f c6d4 - sn8ws 1 / 1 ランニング0 155 m
ゲートウェイ- 6 bdf56976 - gg4nx 1 / 1 実行中3 ( 154 ) 155
ゲートウェイ- プロキシ- f7d46ccb9 - bln5j 1 / 1 実行中0 155 m
gloo - 66 d69d848f - khvfk 1 / 1 ランニング0 155 m
ハブ- サーバー- 7f b68b65cb - 4 c7lp 1 / 1 実行中0 155 m
nsqlookup - 0 1 / 1 ランニング0 155 m
opa - b5df66445 - stjjp 1 / 1 ランニング0 155 m
ピケット- 84 d4758c5f - kp88l 1 / 1 ランニング0 155 m
podexec - 57 db555984 - tgrk8 1 / 1 ランニング0 155 m
ポリシー- 67f 7 d4f744 - n9g5l 1 / 1 ランニング0 155 m
リソース- サーバー- bcd7cd7f8 - krpg6 1 / 1 実行中0 155 m
ユーザー- 5 c95bb8fb7 - z8wg5 1 / 1 実行中1 ( 153 ) 155
ワープドライブ- 7f fff47d47 - n2vwb 2 / 2 ランニング0 155 m
ワープドライブ- 7f fff47d47 - rwpq4 2 / 2 ランニング0 155 m
zadig - dex - c575978d9 - n68q9 1 / 1 実行中1 ( 150 ) 155
zadig - init -- 1 - f98xb 0 / 1 完了0 155 m
ザディグ- ミニオ- fb7fdd6b6 - cfjss 1 / 1 ランニング0 155 m
zadig - mongodb - 5 c59975745 - 4 s24h 1 / 1 ランニング0 155 m
zadig - mysql - 0 1 / 1 実行中0 155 m
zadig - ポータル- 5 cdd6d9fdd - 6 g8ds 1 / 1 ランニング0 155 m

ご覧のとおり、zadig には依存サービスが多数あります。デフォルトでは、zadig は gloo などの Ingress コントローラーを使用してサービスを公開し、zadig という名前の仮想サービス オブジェクトを作成します。これは基本的に Ingress のより高度なバージョンです。

 $ kubectl get virtualservices zadig - n zadig
名前年齢
ザディグ171 m
$ kubectl get svc -n zadig
名前タイプクラスタ- IP 外部- IP ポート( ) 年齢
aslanClusterIP 10.97 .27 .165 < なし> 25000 / TCP 172 m
構成ClusterIP 10.107 .241 .188 < なし> 80 / TCP 172 m
dind ClusterIP なし< なし> 2375 / TCP 172 m
ゲートウェイクラスタIP 10.99 .26 .142 < なし> 443 / TCP 172 m
ゲートウェイ- プロキシLoadBalancer 10.111 .109 .206 192.168 .0 .102 80 : 31600 / TCP , 443 : 31572 / TCP 172 m
glooClusterIP 10.103 .178 .8 < なし> 9977 / TCP 9976 / TCP9988 / TCP9979 / TCP 172 m
ハブ- サーバーClusterIP 10.109 .70 .132 < なし> 26000 / TCP 172 m
nsqlookupd ClusterIP なし< なし> 4160 / TCP4161 / TCP 172 m
opa ClusterIP 10.111 .93 .64 < なし> 9191 / TCP , 8181 / TCP 172 m
ピケットクラスタIP 10.97 .6 .111 < なし> 80 / TCP 172 m
podexec ClusterIP 10.100 .251 .156 < なし> 27000 / TCP 172 m
policyClusterIP 10.105 .50 .162 < なし> 80 / TCP 172 m
リソース- サーバーClusterIP 10.111 .41 .231 < なし> 80 / TCP 172 m
userClusterIP 10.106 .85 .172 < なし> 80 / TCP 172 m
warpdrive ClusterIP 10.107 .219 .101 < なし> 25001 / TCP 172 m
zadig - dex ClusterIP 10.102 .181 .112 < なし> 5556 / TCP5558 / TCP 172 m
zadig - minio ClusterIP 10.99 .45 .95 < なし> 9000 / TCP 172 m
zadig - mongodb ClusterIP 10.98 .252 .235 < なし> 27017 / TCP 172 m
zadig - mysql ClusterIP 10.101 .122 .76 < なし> 3306 / TCP 172 m
zadig - mysql - ヘッドレスClusterIP なし< なし> 3306 / TCP 172 m
zadig - ポータルClusterIP 10.104 .141 .49 < なし> 80 / TCP 172 m

ローカルクラスターにmetalbをデプロイしました。これにより、LoadBalancerタイプのIPアドレスがgateway-proxyサービスに自動的に割り当てられます。zadig.k8s.localドメイン名をこのIPアドレスに解決するだけで、ブラウザからアクセスできるようになります。

デフォルトのユーザー名はadmin、パスワードはzadigです。ログイン後、ホームページにアクセスできます。

基本的な使い方

Zadig をインストールした後、コンテナ化された Nginx を例として、Zadig の基本的な使用方法を説明します。

統合コードソース

まず、一般的な GitHub、GitLab などのコード ソースを追加する必要があります。

GitHub

GitHubのコードソースを統合するには、まずhttps://github.com/settings/developersにアクセスし、新しいOAuthアプリを作成する必要があります。アプリケーション名は任意です。ここでは、ホームページURLはhttp://zadig.k8s.localです。さらに重要なのは、下記のコールバックURLです。http://zadig.k8s.local/api/directory/codehosts/callbackと入力してください。

アプリケーションが正常に作成されると、GitHub からアプリケーションの基本情報が返されます。「新しいクライアントシークレットを生成」をクリックして、クライアントシークレットを生成してください。

生成されたクライアントIDとクライアントシークレットを記録します。Zadigシステムに切り替えます。管理者は「システム設定」→「統合管理」→「コードソース統合ページ」をクリックし、「追加」ボタンをクリックします。ポップアップダイアログボックスで「GitHubコードソース」を選択し、上記で取得したクライアントIDとクライアントシークレットを入力します。

次に、「認証へ進む」ボタンをクリックします。クリックすると、GitHubの認証ページに自動的にリダイレクトされ、認証と承認を行う必要があります。承認後、Zadigのシステムページに自動的にリダイレクトされます。

ギットラボ

GitLabのソースコードを統合するには、認証アプリケーションも作成する必要があります。GitLabのアプリケーション管理ページ(http://git.k8s.local/-/profile/applications)にアクセスしてください。

ここでは、Zadig という名前の新しいアプリケーションを作成する必要があります。リダイレクト URI は http://zadig.k8s.local/api/directory/codehosts/callback であり、api、read_user、および read_repository の権限を選択する必要があります。

アプリケーションが正常に作成されると、GitLab はアプリケーション ID やシークレット情報など、アプリケーションに関する関連情報を返します。

次に、同じように、Zadig に移動して新しいソースコードを追加し、ダイアログボックスに GitLab 情報を入力します。

次に、「承認に移動」ボタンをクリックすると、承認と認証のために GitLab ページに自動的にリダイレクトされます。

承認を確認すると、自動的に Zadig にリダイレクトされ、追加されたコード ソースを確認できるようになります。

統合画像リポジトリ

ソースコードを統合したら、Zadigにイメージリポジトリを追加する必要があります。Zadigは、Alibaba Cloud ACR、Tencent Cloud TCR、Huawei Cloud SWR、Amazon ECR、DockerHub、Harborなどのイメージリポジトリの統合をサポートしています。ここでは、同じKubernetesクラスターにデプロイされたHarborサービスを統合します。

まず、Zadig でビルドしたイメージを保存するために、Harbor に zadig という名前の新しいプロジェクトを作成します。

Zadig システム ページ http://zadig.k8s.local/v1/system/registry で、「作成」ボタンをクリックし、Harbor 情報を設定します。

Harborサービスは自己署名サービスなので、利便性のためSSL検証は有効化していません。保存ボタンをクリックするだけです。

新しいプロジェクト

例として、シンプルなNginxアプリケーションを使用します。コードはGitLabでホストされており、リポジトリのアドレスはhttp://git.k8s.local/course/zadig-nginx-demoです。リポジトリにはDockerfileとindex.htmlファイルのみが含まれています。

 nginx から安定版
インデックス.html / usr / share / nginx / html を追加

ソースコードが準備できたら、プロジェクトを作成できます。Zadigのプロジェクトには、ワークフロー、環境、サービス、ビルド、テスト、バージョンなどのリソースが含まれます。ユーザーは、プロジェクト内でサービス開発、サービスデプロイ、統合テスト、バージョンリリースなどの操作を実行できます。

上記のプロジェクトリストが開き、新しいプロジェクトを作成できます。ここでは、K8s YAMLプロジェクトタイプを選択します。

「今すぐ新規作成」ボタンをクリックしてプロジェクト初期化ウィザードに入り、「次へ」をクリックしてサービスの作成を開始します。

「次へ」をクリックして、新しいサービスの作成を開始します。Zadigにおけるサービスは、サービス、デプロイメントなどのKubernetesリソースのグループ、またはHelm Chartパッケージとして理解できます。

新しいサービスを作成するには、次の 3 つの方法があります。

  • 手動入力: K8s リソース マニフェスト ファイルを直接構成します。
  • コード リポジトリからのインポート: コード リポジトリからサービスの Kubernetes リソース マニフェスト ファイルを同期します。
  • 新しいテンプレートを作成します。K8s YAML テンプレートに基づいて作成するか、K8s からインポートします。

ここでの例は非常にシンプルなので、手動で直接入力してサービスを作成します。以下に示すように、 ​nginx​という名前の新しいサービスを作成し、サービスのリソースマニフェストファイルを中央のYAMLセクションに記述します。

ここでは、デプロイメント リソースとサービス リソースを 1 つずつ作成するだけで済みます。対応するリソース マニフェスト ファイルを以下に示します。

 apiバージョン: アプリ/ v1
種類: デプロイメント
メタデータ
名前: nginx
仕様:
セレクター:
マッチラベル
アプリ: nginx
バージョン: "``.`nginxVersion`"
テンプレート
メタデータ
ラベル:
アプリ: nginx
バージョン: "``.`nginxVersion`"
仕様:
コンテナ
- 名前: nginx
イメージ: harbor.k8s.local / zadig / nginx : stable
ポート:
- コンテナポート: 80
---
apiバージョン: v1
種類: サービス
メタデータ
名前: nginx
ラベル:
アプリ: nginx
バージョン: "``.`nginxVersion`"
仕様:
ラベルセレクター:
アプリ: nginx
タイプ: NodePort
ポート:
- 名前: http
ポート80
ターゲットポート: 80

次に「保存」ボタンをクリックします。保存すると、システム変数、YAMLのカスタム変数、サービスコンポーネントが自動的に読み込まれます。上記のYAMLファイルでは、変数「nginxVersion」を追加しており、Zadigはこれを自動的に読み取ります。

次に、変数領域で「ビルドの追加」をクリックして、サービスのビルド方法を設定します。

必要に応じてビルド環境を構成し、GitLab コード ソース、および以前のプロジェクト コード リポジトリとブランチを選択できます。

次に、以下の一般的なビルド スクリプトを設定できます。

 cd $WORKSPACE / zadig - nginx - デモ
docker build -t $ IMAGE -f Dockerfile
docker push $イメージ

$IMAGE変数は、前の変数($IMAGE)から読み取った現在のイメージバージョンです。設定が完了したら、「保存してビルド」をクリックします。

ご覧の通り、上記で作成したビルド情報にリンクされています。

次に、「次へ」をクリックして続行します。このステップでは、システムは2つの環境と3つのワークフローを自動的に作成します。2つの環境はそれぞれ日常的な開発プロセスとテスト/受入プロセスに使用でき、3つのワークフローは対応する環境に自動的にバインドされ、異なる環境間での継続的デリバリーを実現します。

Zadig は、Kubernetes クラスターに nginx-demo-env-dev と nginx-demo-env-qa という名前の 2 つの名前空間を作成します。

 $ kubectl get ns | grep nginx - デモ
nginx - デモ- env - dev アクティブ23
nginx - デモ- env - qa アクティブ23

次のステップに進み、ワークフロー実行ページに入ると、それぞれ異なる環境に対応する、作成した 3 つのワークフローが表示されます。

たとえば、開発環境の継続的デリバリーを完了するために nginx-demo-workflow-dev ワークフローを選択する場合は、その横にある「実行」ボタンをクリックします。

実際のニーズに応じて、デプロイするサービスと対応するコード ブランチを選択し、[タスクの開始] をクリックしてビルド タスクを開始します。

タスク開始後、ビルドタスクを実行するためにPodが自動的に起動されることがわかります。これは基本的にJenkinsの動的スレーブと同じです。タスクが完了すると、Podは自動的に破棄されます。

 $ kubectl ポッドを取得-n zadig
名前準備完了ステータス再起動年齢
dind - 0 1 / 1 ランニング0 16 m
nginx - デモ- ワークフロー- dev - 2 - buildv2 - szhrk -- 1 - mn6dd 1 / 1 実行中0 8
# ……

タスクが完了すると、新しくビルドされたイメージ harbor.k8s.local/zadig/nginx:20220711184844-1-main が、前に構成したリソース リスト内のイメージ アドレスを置き換え、nginx-demo-env-dev 名前空間に自動的にデプロイされます。

 $ kubectl get pods -n nginx -demo -env ​​-dev    
名前準備完了ステータス再起動年齢
nginx - 5 d5c7f978 - r2vkd 1 / 1 実行中0 30

このサービスの NodePort を介して nginx サービスにアクセスできます。

 $ kubectl get svc -n nginx -demo -env ​​-dev    
名前タイプクラスタ- IP 外部- IP ポート( ) 年齢
nginx ノードポート10.96 .32 .211 < なし> 80 : 31675 / TCP 6 分57秒
$ カール192.168 .0 .106 : 31675

<h1>
こんにちは、 Advantages Knowledge (youdianzhishi.com ) !
</h1>

同時に、開発環境のイメージ情報も上記で構築したイメージ情報に自動的に更新されます。

トリガー

他の環境でのサービス配信も上記と同様です。次に、ワークフローの自動トリガーとバージョン配信を設定します。

開発ワークフロー構成ボタンをクリックして、ワークフロー構成ページに入ります。

左側の「+」ボタンをクリックしてトリガーの追加を開始し、「Webook」をチェックしてWebhookトリガーを追加します。

「設定を追加」をクリックしてトリガーを追加します。ここではGitLabコードリポジトリのトリガーを追加します。対応するコードリポジトリとブランチ情報を選択し、追加後に必ず保存してください。

ここで、GitLab コード リポジトリにプル リクエストを作成すると、対応する Zadig ワークフロー ステータスがマージ処理ページで自動的に関連付けられます。

タスク リンクをクリックすると、Zadig ワークフロー情報ページに移動します。

もちろん、この PR をメイン ブランチにマージすると、新しいタスクもトリガーされます。

Zadig を使用した基本的なアプリケーション配信はこれで完了です。Zadig は、さらに高度な機能やプラクティスも数多く提供しています。