Argo CD を使用したアプリケーションサービスのエンドツーエンドカナリアリリースとデプロイメント - Alibaba Cloud Service Mesh

マイクロサービスアプリケーションの新しいバージョンを安全にリリースし、新機能を段階的に検証するために、Argo CD を使用してエンドツーエンドカナリアリリースを実行します。この方法では、きめ細かいトラフィックスケジューリングとバージョン管理を提供し、バージョン間のシームレスな切り替えを保証します。これにより、オンラインサービスへの影響を最小限に抑え、システムの安定性を向上させます。

前提条件

Enterprise Edition または Ultimate Edition の ASM インスタンスが作成されており、インスタンスのバージョンが 1.20.6.27 以降であること。詳細については、「ASM インスタンスの作成」および「ASM インスタンスのアップグレード」をご参照ください。
Kubernetes クラスターを ASM インスタンスに追加済みであること。
Argo CD がインストールされ、ASM ゲートウェイが作成されていること。詳細については、「Argo CD と ASM を統合して GitOps を実装する」のステップ 1 から 3 をご参照ください。
kubectl を使用して Kubernetes クラスターに接続済みであること。詳細については、「クラスターの kubeconfig ファイルを取得し、kubectl を使用してクラスターに接続する」をご参照ください。

背景情報

Argo CD は GitOps アプローチを使用して、アプリケーションサービスのデプロイとリリースを行います。開発者は、Deployment や Service などのアプリケーションリソース、および VirtualService、Gateway、DestinationRule などのトラフィック管理ルールの YAML マニフェストを Git リポジトリにコミットします。Argo CD は、クラスター内のこれらのリソースのステータスを監視し、Git リポジトリで定義された望ましい状態と比較します。Git リポジトリを source of truth として、Argo CD は変更が検出されたときにリソースを自動または手動で同期できます。

Service Mesh は、トラフィックレーンを使用してアプリケーションの特定のバージョン (またはその他の特性) を独立したランタイム環境に分離し、アプリケーションサービスのエンドツーエンドカナリアリリースの円滑化をサポートします。バージョン 1.20.6.27 以降、ASM は YAML で記述された 2 つのカスタムリソース (ASMSwimLaneGroup と ASMSwimLane) を使用したトラフィックレーンの定義をサポートします。Argo CD を使用してこれらのカスタムリソースを管理し、エンドツーエンドカナリアリリースを実装できます。詳細については、「トラフィックレーンの概要」をご参照ください。

ステップ 1：アプリケーションとトラフィックレーンのデプロイ

モックアプリケーション用のエンドツーエンドカナリアリリースサンプルを作成します。

Argo CD UI で、[NEW APP] をクリックし、次のパラメーターを設定します。

パラメーター	説明
Application Name	アプリケーション名。この例では、`mock` と入力します。
SYNC POLICY	アプリケーションの同期ポリシー。この例では、`Automatically` を選択します。この設定により、Git リポジトリから最新のリソース定義が自動的に同期されます。`PRUNE RESOURCES` を選択すると、Git リポジトリから定義が削除された場合に、リソースがクラスターから削除されます。
Repository URL	ソース Git リポジトリの URL。この例では、サンプルリポジトリの URL `https://github.com/AliyunContainerService/asm-labs.git` を入力します。サンプルを変更する場合は、このリポジトリをフォークし、フォークしたリポジトリの URL を入力します。
Revision	同期元の Git タグまたはブランチ名。この例では、サンプルリポジトリのブランチ `argocd-asm` を入力します。
Path	リソースマニフェストが含まれるリポジトリ内のパス。この例では、サンプルで使用されるリソースのパス `argo-cd/swimlane` を入力します。
Cluster URL	宛先クラスターの API サーバーアドレス。この例では、Argo CD がデプロイされている Kubernetes クラスターの API サーバーアドレス `https://kubernetes.default.svc` を入力します。

設定が完了したら、ページ上部の [CREATE] をクリックします。

Argo CD の [Applications] ページで、先ほど作成した mock アプリケーションのステータスを確認できます。

アプリケーションのステータスが [Healthy]、同期ステータスが [Synced] になっているはずです。これは、アプリケーションが正常にデプロイされ、同期されたことを示します。
mock アプリケーションをクリックして、そのリソースの同期ステータスを表示します。

リソースビューには、アプリケーションのステータスが [Healthy]、同期ステータスが [Synced] であり、すべてのリソースがエラーなく同期されていることが表示されます。

Git リポジトリには、アプリケーションを定義する Deployment リソースと Service リソースに加えて、VirtualService や Gateway などのトラフィック管理リソース、および ASMSwimLaneGroup や ASMSwimLane などの ASM トラフィックレーンリソースも含まれています。

ステップ 2：エンドツーエンドカナリアリリースの検証

この例では、ASMSwimLaneGroup および ASMSwimLane リソースが、アプリケーションサービスの v1 環境と v2 環境を分離します。VirtualService リソースは、ASM ゲートウェイが 1:1 の比率で 2 つのバージョンにトラフィックを転送するように設定します。ASM ゲートウェイに繰り返しアクセスして、エンドツーエンドカナリアリリースを検証できます。

ASM コンソールからゲートウェイのパブリック IP アドレスを取得します。詳細については、「ASM ゲートウェイの IP アドレスの取得」をご参照ください。
次のコマンドを実行して、環境変数を設定します。

xxx.xxx.xxx.xxx を前の手順で取得した IP アドレスに置き換えます。
```
export ASM_GATEWAY_IP=xxx.xxx.xxx.xxx
```

次のコマンドを実行して、ASM ゲートウェイに繰り返しアクセスします。

for i in {1..100}; do curl http://${ASM_GATEWAY_IP}/mock; echo ''; sleep 1; done;

期待される出力：

-> mocka(version: v2, ip: 10.0.239.73)-> mockb(version: v2, ip: 10.0.239.136)-> mockc(version: v2, ip: 10.0.239.139)
-> mocka(version: v1, ip: 10.0.239.75)-> mockb(version: v1, ip: 10.0.239.138)-> mockc(version: v1, ip: 10.0.239.137)
-> mocka(version: v2, ip: 10.0.239.73)-> mockb(version: v2, ip: 10.0.239.136)-> mockc(version: v2, ip: 10.0.239.139)
-> mocka(version: v2, ip: 10.0.239.73)-> mockb(version: v2, ip: 10.0.239.136)-> mockc(version: v2, ip: 10.0.239.139)
-> mocka(version: v2, ip: 10.0.239.73)-> mockb(version: v2, ip: 10.0.239.136)-> mockc(version: v2, ip: 10.0.239.139)
-> mocka(version: v1, ip: 10.0.239.75)-> mockb(version: v1, ip: 10.0.239.138)-> mockc(version: v1, ip: 10.0.239.137)
-> mocka(version: v1, ip: 10.0.239.75)-> mockb(version: v1, ip: 10.0.239.138)-> mockc(version: v1, ip: 10.0.239.137)
-> mocka(version: v1, ip: 10.0.239.75)-> mockb(version: v1, ip: 10.0.239.138)-> mockc(version: v1, ip: 10.0.239.137)
-> mocka(version: v1, ip: 10.0.239.75)-> mockb(version: v1, ip: 10.0.239.138)-> mockc(version: v1, ip: 10.0.239.137)
-> mocka(version: v1, ip: 10.0.239.75)-> mockb(version: v1, ip: 10.0.239.138)-> mockc(version: v1, ip: 10.0.239.137)
-> mocka(version: v1, ip: 10.0.239.75)-> mockb(version: v1, ip: 10.0.239.138)-> mockc(version: v1, ip: 10.0.239.137)
-> mocka(version: v1, ip: 10.0.239.75)-> mockb(version: v1, ip: 10.0.239.138)-> mockc(version: v1, ip: 10.0.239.137)
-> mocka(version: v2, ip: 10.0.239.73)-> mockb(version: v2, ip: 10.0.239.136)-> mockc(version: v2, ip: 10.0.239.139)
-> mocka(version: v1, ip: 10.0.239.75)-> mockb(version: v1, ip: 10.0.239.138)-> mockc(version: v1, ip: 10.0.239.137)
...

出力は、サンプルアプリケーションが mocka、mockb、mockc の 3 つのサービスで構成されていることを示しています。サービス呼び出しチェーンは mocka→mockb→mockc であり、各サービスには v1 と v2 のバージョンがあります。リクエストは、約 1:1 の比率でアプリケーションの v1 バージョンと v2 バージョンに送信されます。各バージョンの分離されたサービス呼び出しチェーンは、エンドツーエンドカナリアリリースが成功したことを示しています。

関連操作

新しいサービスバージョンのリリース

この例で使用されているサンプル Git リポジトリには、次のファイル構造があります：

ファイル	説明
mock-v1.yaml mock-v2.yaml	`mocka`、`mockb`、`mockc` サービスの v1 および v2 バージョンの Deployment 定義。
swimlanegroup.yaml	レーングループの定義。レーングループは 1 つ以上のトラフィックレーンに関連付けられ、それらの共有情報を定義します。これにより、分離された環境を必要とする `services` と、レーングループ内のサービスにアクセスするための `Ingress` ゲートウェイルールが指定されます。
swimlanes.yaml	トラフィックレーンの定義。このファイルは、v1 と v2 の 2 つの `ASMSwimLane` リソースを定義します。トラフィックレーンは、主に `labelSelector` を使用して、ラベルに基づいてサービスバージョンを区別します。
mock-route.yaml	ASM Ingress ゲートウェイに適用される Gateway および VirtualService リソースを定義します。これらのトラフィック管理リソースは、ASM ゲートウェイが各トラフィックレーンのサービスにリクエストをルーティングする方法を制御します。

新しいアプリケーションサービスバージョンをリリースするには、https://github.com/AliyunContainerService/asm-labs.git のサンプルリポジトリの argocd-asm ブランチをフォークします。argo-cd/swimlane パス内の YAML リソースを変更し、変更をコミットします。コミットをプッシュすると、Argo CD が自動的に変更を同期します。「ステップ 1」の Repository URL が、フォークしたリポジトリの URL に設定されていることを確認してください。

たとえば、mocka、mockb、mockc サービス用に新しい v3 バージョンをリリースするには、Git リポジトリ内の YAML リソースを次のように変更します：

argo-cd/swimlane/mock-v3.yaml ファイルを追加します。

この YAML ファイルは、mocka、mockb、mockc サービスの v3 バージョンの Deployment を定義します。

YAML

apiVersion: apps/v1
kind: Deployment
metadata:
 name: mocka-v3
 labels:
 app: mocka
 version: v3
spec:
 replicas: 1
 selector:
 matchLabels:
 app: mocka
 version: v3
 ASM_TRAFFIC_TAG: v3
 template:
 metadata:
 labels:
 app: mocka
 version: v3
 ASM_TRAFFIC_TAG: v3
 spec:
 containers:
 - name: default
 image: registry.cn-beijing.aliyuncs.com/aliacs-app-catalog/go-http-sample:1.0
 imagePullPolicy: IfNotPresent
 env:
 - name: version
 value: v3
 - name: app
 value: mocka
 - name: upstream_url
 value: "http://mockb:8000/"
 ports:
 - containerPort: 8000
---
apiVersion: apps/v1
kind: Deployment
metadata:
 name: mockb-v3
 labels:
 app: mockb
 version: v3
spec:
 replicas: 1
 selector:
 matchLabels:
 app: mockb
 version: v3
 ASM_TRAFFIC_TAG: v3
 template:
 metadata:
 labels:
 app: mockb
 version: v3
 ASM_TRAFFIC_TAG: v3
 spec:
 containers:
 - name: default
 image: registry.cn-beijing.aliyuncs.com/aliacs-app-catalog/go-http-sample:1.0
 imagePullPolicy: IfNotPresent
 env:
 - name: version
 value: v3
 - name: app
 value: mockb
 - name: upstream_url
 value: "http://mockc:8000/"
 ports:
 - containerPort: 8000
---
apiVersion: apps/v1
kind: Deployment
metadata:
 name: mockc-v3
 labels:
 app: mockc
 version: v3
spec:
 replicas: 1
 selector:
 matchLabels:
 app: mockc
 version: v3
 ASM_TRAFFIC_TAG: v3
 template:
 metadata:
 labels:
 app: mockc
 version: v3
 ASM_TRAFFIC_TAG: v3
 spec:
 containers:
 - name: default
 image: registry.cn-beijing.aliyuncs.com/aliacs-app-catalog/go-http-sample:1.0
 imagePullPolicy: IfNotPresent
 env:
 - name: version
 value: v3
 - name: app
 value: mockc
 ports:
 - containerPort: 8000

argo-cd/swimlane/swimlanes.yaml ファイルを次の内容に変更します。

v3 という名前の新しいトラフィックレーン (ASMSwimLane) を追加します。このリソースは mock レーングループ (ASMSwimLaneGroup) に関連付けられ、version:v3 ラベルを持つ Pod が v3 サービスバージョンに属することを指定します。

YAML

apiVersion: istio.alibabacloud.com/v1
kind: ASMSwimLane
metadata:
 labels:
 swimlane-group: mock
 name: v1
spec:
 labelSelector:
 version: v1
---
apiVersion: istio.alibabacloud.com/v1
kind: ASMSwimLane
metadata:
 labels:
 swimlane-group: mock
 name: v2
spec:
 labelSelector:
 version: v2
---
apiVersion: istio.alibabacloud.com/v1
kind: ASMSwimLane
metadata:
 labels:
 swimlane-group: mock
 name: v3
spec:
 labelSelector:
 version: v3

argo-cd/swimlane/mock-route.yaml ファイルを次の内容に変更します。

mock という名前の VirtualService を変更し、ルートの宛先に mocka サービスの v3 バージョンを追加します。subset フィールドをトラフィックレーン (ASMSwimLane) の名前にマッピングします。VirtualService の weight フィールドを、v1、v2、v3 バージョン間で 6:3:1 の比率でトラフィックを分割するように調整します。

YAML

apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
 name: ingressgateway
 namespace: istio-system
spec:
 selector:
 istio: ingressgateway
 servers:
 - port:
 number: 80
 name: http
 protocol: HTTP
 hosts:
 - '*'
---
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
 name: mock
 namespace: istio-system
spec:
 gateways:
 - ingressgateway
 hosts:
 - '*'
 http:
 - match:
 - uri:
 exact: /mock
 route:
 - destination:
 host: mocka.default.svc.cluster.local
 subset: v1
 weight: 60
 - destination:
 host: mocka.default.svc.cluster.local
 subset: v2
 weight: 30
 - destination:
 host: mocka.default.svc.cluster.local
 subset: v3
 weight: 10