1. はじめに
ArgoCDでBlue/Greenデプロイを実現するのはかなり面倒だなと感じていました。
なにかいい方法がないかを探したところArgo Rolloutsがどうやら便利そうとのことで、実際に自分のお遊び環境で動作検証てみました。
これはその検証内容と実施手順の備忘メモとなります。
2. kubernetes環境の準備
簡単にArgo Rolloutsの使い方を理解するためなので、minikubeを利用します。
いきなりArgo Rolloutを試すのではなく、まずはminikube上でアプリを動かします。
2.1 マニフェストファイルの準備
今回は自作のWebアプリのコンテナイメージを検証に利用します。
用意したDockerfileをdocker buildでビルドし、ローカルのレジストリにイメージを格納します。
格納したイメージはminikubeで利用できないため、minikube image loadコマンドでイメージをminikubeに持ち込みます。
$ minikube image load blue-green-sample:latest
$ minikube image ls
# 省略
docker.io/library/blue-green-sample:latest
次にDeploymentとServiceのマニフェストファイルを準備します。
ローカルイメージを利用する場合は、DeploymentのImagePullPokicyをIfNotPresentにする必要があるので注意してください。
apiVersion: apps/v1
kind: Deployment
metadata:
name: blue-green-sample
labels:
app: blue-green-sample
spec:
replicas: 2
selector:
matchLabels:
app: blue-green-sample
template:
metadata:
labels:
app: blue-green-sample
spec:
containers:
- name: blue-green-sample
image: blue-green-sample:latest
imagePullPolicy: IfNotPresent
ports:
- containerPort: 8080
apiVersion: v1
kind: Service
metadata:
name: blue-green-sample-service
spec:
selector:
app: blue-green-sample
type: NodePort
ports:
- protocol: TCP
port: 8080
targetPort: 8080
2.2 アプリ動作確認
minikubeでDeploymentとServiceをデプロイします。
# deploymentの作成
$ kubectl apply -n sample -f ./k8s/deployment.yaml
$ kubectl get pod -n sample
NAME READY STATUS RESTARTS AGE
blue-green-sample-679d6b6dd4-564tb 1/1 Running 0 22s
blue-green-sample-679d6b6dd4-bxlph 1/1 Running 0 12s
# serviceの作成
$ kubectl apply -n sample -f ./k8s/service.yaml
service/blue-green-sample-service created
$ kubectl get service -n sample
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
blue-green-sample-service NodePort 10.97.200.105 <none> 8080:30641/TCP 2m49s
# Serviceのポートフォワード設定
$ kubectl port-forward -n sample service/blue-green-sample-service 8080:8080
Forwarding from 127.0.0.1:8080 -> 8080
Forwarding from [::1]:8080 -> 8080
デプロイ後、そのままではServiceにリクエストを送信できないのでポートフォワーディングを実行します。
フォワーディングが有効になっている状態でリクエストを送信するとレスポンスが返って来きたので、動作確認はOKです。
$ curl -s http://localhost:8080/sample/version
{"appVersion":"green"}
3. Argo Rolloutsの検証
では本題のArgo Rolloutsの動作検証を進めていきます。
Argo Rolloutsではデプロイ戦略としてカナリアとBlue/Greenが選択可能です。
今回はタイトルの通りBlue/Greenデプロイの検証が目的なのでデプロイ戦略はBlue/Greenを選択します。
3.1 Argo Rolloutsのインストール
まずは、Argo Rolloutsをインストールします。
公式のドキュメントではインストール方法は2通りあると記載されています。
- install.yaml - Standard installation method
- namespace-install.yaml - Installation of Argo Rollouts which requires only namespace level privileges.
1.はスタンダードな方法でこのインストールを実行するとArgo RolloutsのContorllerが起動するargo-rolloutsというnamespaceが作成されます。
一方で、2.は同じKubernetesクラスター上に複数のArgo Rollouts Controllerを起動する場合に利用するそうです。
今回は複数起動させる予定はないため、install.yamlでインストールします。
インストールコマンドは公式のドキュメントに記載されているとおりです。
$ kubectl create namespace argo-rollouts
$ kubectl apply -n argo-rollouts -f https://github.com/argoproj/argo-rollouts/releases/latest/download/install.yaml
次にプラグインもインストールします。
手順はKubectl Plugin Installationに記載されており、方法はbrewか手動の2通りが選択可能です。
私の環境はUbuntuなので手動インストールを選択しました。
手順通りで問題ないですが、公式のコマンドはディストリビューションがdarwinなのでlinuxに書き換えます。
# プラグインのインストール
$ curl -LO https://github.com/argoproj/argo-rollouts/releases/latest/download/kubectl-argo-rollouts-linux-amd64
$ chmod +x ./kubectl-argo-rollouts-linux-amd64
$ sudo mv ./kubectl-argo-rollouts-linux-amd64 /usr/local/bin/kubectl-argo-rollouts
# プラグインのインストール確認
$ kubectl argo rollouts version
kubectl-argo-rollouts: v1.4.0+e40c9fe
BuildDate: 2023-01-09T20:20:38Z
GitCommit: e40c9fe8a2f7fee9d8ee1c56b4c6c7b983fce135
GitTreeState: clean
GoVersion: go1.19.4
Compiler: gc
Platform: linux/amd64
kubectl argo rollouts versionコマンドでバージョンが表示されればインストールは完了です。
3.2 マニフェストファイルの作成
Argo Rolloutsを利用する場合、マニフェストファイルのkindはDeploymentではなくRolloutになります。
また、Rolloutの構造はDeploymentとよく似ていますが、strategy:にデプロイ戦略の設定を追記します。
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
name: rollout-blue-green
spec:
replicas: 2
revisionHistoryLimit: 2
selector:
matchLabels:
app: rollout-blue-green
template:
metadata:
labels:
app: rollout-blue-green
spec:
containers:
- name: rollout-blue-green-sample
image: blue-green-sample:blue
imagePullPolicy: IfNotPresent
ports:
- containerPort: 8080
strategy:
blueGreen:
activeService: rollout-blue-green-svc-active
previewService: rollout-blue-green-svc-preview
autoPromotionEnabled: false
次にRolloutに対応するServiceを作成します。
Blue/Greenデプロイの場合、公開面とスタンバイ面の2つのServiceを作成する必要があります。
また、Serviceの名前(metadata.name)にRolloutのactiveServiceとpreviewServiceに指定したService名を設定します。
apiVersion: v1
kind: Service
metadata:
name: rollout-blue-green-svc-active
spec:
selector:
app: rollout-blue-green
type: NodePort
ports:
- protocol: TCP
port: 8080
targetPort: 8080
---
apiVersion: v1
kind: Service
metadata:
name: rollout-blue-green-svc-preview
spec:
selector:
app: rollout-blue-green
type: NodePort
ports:
- protocol: TCP
port: 8080
targetPort: 8080
3.3 Blue/Greenデプロイの実行
それではBlue/Greenデプロイの動作検証を進めていきたいと思います。
3.3.1 Blue面のデプロイ
作成したRolloutとServiceのマニフェストファイルを指定してapplyを実行します。
# Rolloutの作成
$ kubectl apply -n sample -f rollout.yaml
rollout.argoproj.io/rollout-blue-green created
# Serviceの作成
$ kubectl apply -n sample -f rollout-service.yaml
service/rollout-blue-green-svc-active created
service/rollout-blue-green-svc-preview created
# Podの確認
$ kubectl get pod -n sample
NAME READY STATUS RESTARTS AGE
rollout-blue-green-5854f6d6dd-8qlsx 0/1 ContainerCreating 0 4s
rollout-blue-green-5854f6d6dd-vd7kr 0/1 ContainerCreating 0 4s
# Serviceの確認
$ kubectl get svc -n sample
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
rollout-blue-green-svc-active NodePort 10.111.189.10 <none> 8080:31917/TCP 48s
rollout-blue-green-svc-preview NodePort 10.101.18.128 <none> 8080:30764/TCP 47s
# Rolloutの確認
$ kubectl get rollout -n sample
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
rollout-blue-green 2 2 2 2 74s
# Argo Rolloutsの状態確認
$ kubectl argo rollouts get rollout -n sample rollout-blue-green
Name: rollout-blue-green
Namespace: sample
Status: ✔ Healthy
Strategy: BlueGreen
Images: blue-green-sample:blue (stable, active)
Replicas:
Desired: 2
Current: 2
Updated: 2
Ready: 2
Available: 2
NAME KIND STATUS AGE INFO
⟳ rollout-blue-green Rollout ✔ Healthy 2m9s
└──# revision:1
└──⧉ rollout-blue-green-5854f6d6dd ReplicaSet ✔ Healthy 109s stable,active
├──□ rollout-blue-green-5854f6d6dd-8qlsx Pod ✔ Running 107s ready:1/1
└──□ rollout-blue-green-5854f6d6dd-vd7kr Pod ✔ Running 107s ready:1/1
# ポートフォワーディング
$ kubectl port-forward -n sample service/rollout-blue-green-svc-active 8080:8080
rollout-blue-green-svc-activeのポートフォワーディングを実行します。
Serviceに対してリクエストを送信すると、Blue面からレスポンスが返ってきました。
$ curl -s http://localhost:8080/sample/version
{"appVersion":"blue"}
3.3.2 Green面のデプロイ
次にGreen面をデプロイするため、rollout.yamlのイメージのタグを修正します。
現在はblue面がデプロイされているので、タグ名をgreenに変更し保存します。
# イメージのタグをgreenに更新
image: blue-green-sample:green
変更したマニフェストファイルのapplyを実行します。
$ kubectl apply -n sample -f rollout.yaml
rollout.argoproj.io/rollout-blue-green configured
するとRolloutの状態が変化しrevision:2が新しく立ち上がります。
$ kubectl argo rollouts get rollout -n sample rollout-blue-green --watch
# ==============================
# revision:2の作成
# ==============================
Name: rollout-blue-green
Namespace: sample
Status: ◌ Progressing
Message: more replicas need to be updated
Strategy: BlueGreen
Images: blue-green-sample:blue (stable, active)
Replicas:
Desired: 2
Current: 2
Updated: 0
Ready: 2
Available: 2
NAME KIND STATUS AGE INFO
⟳ rollout-blue-green Rollout ◌ Progressing 119m
├──# revision:2
│ └──⧉ rollout-blue-green-8d77c86f5 ReplicaSet ◌ Progressing 2s preview
└──# revision:1
└──⧉ rollout-blue-green-5854f6d6dd ReplicaSet ✔ Healthy 119m stable,active
├──□ rollout-blue-green-5854f6d6dd-8qlsx Pod ✔ Running 119m ready:1/1
└──□ rollout-blue-green-5854f6d6dd-vd7kr Pod ✔ Running 119m ready:1/1
# ==============================
# revision:2のPod作成待ち
# ==============================
Name: rollout-blue-green
Namespace: sample
Status: ◌ Progressing
Message: more replicas need to be updated
Strategy: BlueGreen
Images: blue-green-sample:blue (stable, active)
Replicas:
Desired: 2
Current: 2
Updated: 0
Ready: 2
Available: 2
NAME KIND STATUS AGE INFO
⟳ rollout-blue-green Rollout ◌ Progressing 119m
├──# revision:2
│ └──⧉ rollout-blue-green-8d77c86f5 ReplicaSet ◌ Progressing 2s preview
│ ├──□ rollout-blue-green-8d77c86f5-2xn9n Pod ◌ Pending 0s ready:0/1
│ └──□ rollout-blue-green-8d77c86f5-vlsqd Pod ◌ Pending 0s ready:0/1
└──# revision:1
└──⧉ rollout-blue-green-5854f6d6dd ReplicaSet ✔ Healthy 119m stable,active
├──□ rollout-blue-green-5854f6d6dd-8qlsx Pod ✔ Running 119m ready:1/1
└──□ rollout-blue-green-5854f6d6dd-vd7kr Pod ✔ Running 119m ready:1/1
# ==============================
# revision:2のPod作成開始
# ==============================
Name: rollout-blue-green
Namespace: sample
Status: ◌ Progressing
Message: active service cutover pending
Strategy: BlueGreen
Images: blue-green-sample:blue (stable, active)
blue-green-sample:green (preview)
Replicas:
Desired: 2
Current: 4
Updated: 2
Ready: 2
Available: 2
NAME KIND STATUS AGE INFO
⟳ rollout-blue-green Rollout ◌ Progressing 119m
├──# revision:2
│ └──⧉ rollout-blue-green-8d77c86f5 ReplicaSet ◌ Progressing 6s preview
│ ├──□ rollout-blue-green-8d77c86f5-2xn9n Pod ◌ ContainerCreating 4s ready:0/1
│ └──□ rollout-blue-green-8d77c86f5-vlsqd Pod ◌ ContainerCreating 4s ready:0/1
└──# revision:1
└──⧉ rollout-blue-green-5854f6d6dd ReplicaSet ✔ Healthy 119m stable,active
├──□ rollout-blue-green-5854f6d6dd-8qlsx Pod ✔ Running 119m ready:1/1
└──□ rollout-blue-green-5854f6d6dd-vd7kr Pod ✔ Running 119m ready:1/1
# ==============================
# revision:2のPod作成完了
# ==============================
Name: rollout-blue-green
Namespace: sample
Status: ॥ Paused
Message: BlueGreenPause
Strategy: BlueGreen
Images: blue-green-sample:blue (stable, active)
blue-green-sample:green (preview)
Replicas:
Desired: 2
Current: 4
Updated: 2
Ready: 2
Available: 2
NAME KIND STATUS AGE INFO
⟳ rollout-blue-green Rollout ॥ Paused 120m
├──# revision:2
│ └──⧉ rollout-blue-green-8d77c86f5 ReplicaSet ✔ Healthy 30s preview
│ ├──□ rollout-blue-green-8d77c86f5-2xn9n Pod ✔ Running 28s ready:1/1
│ └──□ rollout-blue-green-8d77c86f5-vlsqd Pod ✔ Running 28s ready:1/1
└──# revision:1
└──⧉ rollout-blue-green-5854f6d6dd ReplicaSet ✔ Healthy 119m stable,active
├──□ rollout-blue-green-5854f6d6dd-8qlsx Pod ✔ Running 119m ready:1/1
└──□ rollout-blue-green-5854f6d6dd-vd7kr Pod ✔ Running 119m ready:1/1
revision:2のPodが立ち上がったことが確認できますが、rollout-blue-greenのSTATUSがPausedとなっています。
この状態でリクエストをactiveサービスに送信すると、Blueのレスポンスが返ってきます。
このことから、まだBlue面とGreen面が切り替わっていないことがわかります。
$ curl -s http://localhost:8080/sample/version
{"appVersion":"blue"}
この状態をダッシュボードでも確認してみます。
ダッシュボードを起動する場合は、でインストールしたプラグインのdashbordを実行します。
$ kubectl argo rollouts -n sample dashboard
INFO[0000] Argo Rollouts Dashboard is now available at http://localhost:3100/rollouts
ブラウザからhttp://localhost:3100/rolloutsのURLにアクセスると下記のダッシュボードが表示されます。
画面上の緑の✅はPodを表しており、それぞれのRevisionで2つのPodが起動しています。
また、Revision:1とRevision:2の両方が起動しており、Revision:1がActiveであることも確認できます。
3.3.3 面の切り替え
Blue面、Green面の両方がデプロイできたので面の切り替えを実行します。
切り替えの実行はコマンドまたはダッシュボードの画面から実行します。
下記は面切り替えのコマンド例です。
$ kubectl argo rollouts promote -n sample rollout-blue-green
$ kubectl argo rollouts get rollout -n sample rollout-blue-green --watch
# ==============================
# Green面がActiveに昇格
# ==============================
Name: rollout-blue-green
Namespace: sample
Status: ✔ Healthy
Strategy: BlueGreen
Images: blue-green-sample:blue
blue-green-sample:green (stable, active)
Replicas:
Desired: 2
Current: 4
Updated: 2
Ready: 2
Available: 2
NAME KIND STATUS AGE INFO
⟳ rollout-blue-green Rollout ✔ Healthy 150m
├──# revision:2
│ └──⧉ rollout-blue-green-8d77c86f5 ReplicaSet ✔ Healthy 30m stable,active
│ ├──□ rollout-blue-green-8d77c86f5-2xn9n Pod ✔ Running 30m ready:1/1
│ └──□ rollout-blue-green-8d77c86f5-vlsqd Pod ✔ Running 30m ready:1/1
└──# revision:1
└──⧉ rollout-blue-green-5854f6d6dd ReplicaSet ✔ Healthy 149m
├──□ rollout-blue-green-5854f6d6dd-8qlsx Pod ✔ Running 149m ready:1/1
└──□ rollout-blue-green-5854f6d6dd-vd7kr Pod ✔ Running 149m ready:1/1
# ==============================
# revision:1の縮退開始
# ==============================
Name: rollout-blue-green
Namespace: sample
Status: ✔ Healthy
Strategy: BlueGreen
Images: blue-green-sample:blue
blue-green-sample:green (stable, active)
Replicas:
Desired: 2
Current: 4
Updated: 2
Ready: 2
Available: 2
NAME KIND STATUS AGE INFO
⟳ rollout-blue-green Rollout ✔ Healthy 150m
├──# revision:2
│ └──⧉ rollout-blue-green-8d77c86f5 ReplicaSet ✔ Healthy 30m stable,active
│ ├──□ rollout-blue-green-8d77c86f5-2xn9n Pod ✔ Running 30m ready:1/1
│ └──□ rollout-blue-green-8d77c86f5-vlsqd Pod ✔ Running 30m ready:1/1
└──# revision:1
└──⧉ rollout-blue-green-5854f6d6dd ReplicaSet • ScaledDown 150m
├──□ rollout-blue-green-5854f6d6dd-8qlsx Pod ◌ Terminating 150m ready:1/1
└──□ rollout-blue-green-5854f6d6dd-vd7kr Pod ◌ Terminating 150m ready:1/1
# ==============================
# revision:1の縮退完了
# ==============================
Name: rollout-blue-green
Namespace: sample
Status: ✔ Healthy
Strategy: BlueGreen
Images: blue-green-sample:green (stable, active)
Replicas:
Desired: 2
Current: 2
Updated: 2
Ready: 2
Available: 2
NAME KIND STATUS AGE INFO
⟳ rollout-blue-green Rollout ✔ Healthy 152m
├──# revision:2
│ └──⧉ rollout-blue-green-8d77c86f5 ReplicaSet ✔ Healthy 32m stable,active
│ ├──□ rollout-blue-green-8d77c86f5-2xn9n Pod ✔ Running 32m ready:1/1
│ └──□ rollout-blue-green-8d77c86f5-vlsqd Pod ✔ Running 32m ready:1/1
└──# revision:1
└──⧉ rollout-blue-green-5854f6d6dd ReplicaSet • ScaledDown 152m
promoteを実行するとrevision:2がActiveになり、revision:1のPodは削除され縮退していることがわかります。
この状態でrollout-blue-green-svc-activeのポートフォワーディングを実行し、Serviceに対してリクエストを送信するとGreen面からレスポンスが返ってきました。
面の切り替えは成功です。
$ curl -s http://localhost:8080/sample/version
{"appVersion":"green"}
ダッシュボードでもRevision:2がActiveになっていることが確認できます。
3.4 ロールバックの実行
次にロールバック時にどういった挙動になるのかを確認してみます。
今回はコマンドではなくダッシュボードの画面から実行してみます。
ダッシュボードを開くと、Revisionsに2つのRevisionが表示されます。
ただしRevision 1は縮退しているため、Podは起動していません。
この縮退しているRevisionのROLLBACKを押します。
押すとボタンの文字が「本当に実行する？(Sure?)」となるので、ボタンを押してROLLBACKを実行します。
ROLLBACKを実行すると新しいRevisionのRevision 3が立ち上り、Podが起動します。
コンテナイメージのタグは縮退したRevisionと同じくgreenです。
Revision 3のPod起動が完了しましたので画面上部のPROMOTEを実行します。
こちらも再確認が求められるので、そのまま実行します。
PROMOTEを実行するとRevision 3がActiveに昇格し、Revision 2はPreviewに降格します。
そして降格の30秒後にPodの縮退を開始します。
縮退開始までの時間はrollout.yamlに設定するscaleDownDelaySecondsで変更可能です。
デフォルトでは30秒となっています。
設定可能なオプションは公式ドキュメントのConfigurable Featuresを参照してください。
4. マニフェストファイルのkustomize化
作成したマニフェストファイルをkustomize化してみます。
下記はディレクトリやファイルの構成です。
manifest
├ base
│ ├ kustomization.yaml
│ ├ rollout.yaml
│ └ rollout-service.yaml
└ overlays/dev
├ kustomization.yaml
├ patch.yaml
└ config.env
baseディレクトリの各ファイルの内容は以下の通り。
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- rollout.yaml
- rollout-service.yaml
# Version 2023-03-01-1677634140
openapi:
path: https://github.com/argoproj/argo-schema-generator/raw/2023-03-01-1677634140/schema/argo_all_k8s_kustomize_schema.json
# Version v1.4.0
configurations:
- https://raw.githubusercontent.com/argoproj/argo-rollouts/v1.4.0/docs/features/kustomize/rollout-transform.yaml
openapiとconfigurationsにAPIのスキーマや、Transformer Configurationsを設定する必要があります。
これらの設定がないとうまくRolloutが加工できません。
実際にこれらの設定をなくしてkustomize buildを実行すると、configMapがうまくRolloutに反映できませんでした。
また以前はこちらのブログに記載されているとおり、標準リソースとArgo RolloutsのOpenAPIスキーマを統合した独自のスキーマ定義を作成し、設定する必要がありました。
ですが、最新のArgoRolloutsのドキュメントによるとargo-schema-generatorで生成されたスキーマ定義を利用すれば独自に加工したスキーマ定義は不要とのことです。
詳細は公式ドキュメントを参照してください。
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
name: rollout-blue-green
spec:
replicas: 2
revisionHistoryLimit: 2
selector:
matchLabels:
app: rollout-blue-green
template:
metadata:
labels:
app: rollout-blue-green
spec:
containers:
- name: rollout-blue-green-sample
image: rollout-blue-green-sample-image
imagePullPolicy: IfNotPresent
ports:
- containerPort: 9090
env:
- name: TEST_ENV_01
value: "environment message01"
envFrom:
- configMapRef:
name: blue-green-sample-config
strategy:
blueGreen:
activeService: rollout-blue-green-svc-active
previewService: rollout-blue-green-svc-preview
autoPromotionEnabled: false
base/rollout-service.yamlは3.2 マニフェストファイルの作成と同じなので割愛します。
overlays/devディレクトリの各ファイルの内容は以下の通り。
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- ../../base
images:
- name: rollout-blue-green-sample-image
newName: blue-green-sample
newTag: latest
patches:
- target:
kind: Rollout
path: patch.yaml
configMapGenerator:
- name: blue-green-sample-config
envs:
- config.env
- op: replace
path: /spec/template/spec/containers/0/ports/0/containerPort
value: 8080
- op: add
path: /spec/template/spec/containers/0/env/-
value:
name: TEST_ENV_02
value: "environment message02"
ENV_VALUE01=ENV-VALUE
この構成でkustomize buildを実行すると下記の通りにマニフェストファイルが作成されます。
環境変数やconfigMap、コンテナイメージやポート番号がうまく上書き、追記されていることが確認できます。
apiVersion: v1
data:
ENV_VALUE01: ENV-VALUE
kind: ConfigMap
metadata:
name: blue-green-sample-config-gcfb6g9844
---
apiVersion: v1
kind: Service
metadata:
name: rollout-blue-green-svc-active
spec:
ports:
- port: 8080
protocol: TCP
targetPort: 8080
selector:
app: rollout-blue-green
type: NodePort
---
apiVersion: v1
kind: Service
metadata:
name: rollout-blue-green-svc-preview
spec:
ports:
- port: 8080
protocol: TCP
targetPort: 8080
selector:
app: rollout-blue-green
type: NodePort
---
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
name: rollout-blue-green
spec:
replicas: 2
revisionHistoryLimit: 2
selector:
matchLabels:
app: rollout-blue-green
strategy:
blueGreen:
activeService: rollout-blue-green-svc-active
autoPromotionEnabled: false
previewService: rollout-blue-green-svc-preview
template:
metadata:
labels:
app: rollout-blue-green
spec:
containers:
- env:
- name: TEST_ENV_01
value: environment message01
- name: TEST_ENV_02
value: environment message02
envFrom:
- configMapRef:
name: blue-green-sample-config-gcfb6g9844
image: blue-green-sample:latest
imagePullPolicy: IfNotPresent
name: rollout-blue-green-sample
ports:
- containerPort: 8080
5. さいごに
今回の検証作業でArgo RolloutsでのBlue/Greenデプロイがどうやって動くのかを確認しましたが、結構使えそうだということがわかりました。
またマニフェストファイルのkustomize化も問題ないことが確認できたました。
調べてみるとArgoCDのプラグインでrollout-extensionがあるらしく、ArgoCDのダッシュボードにArgo Rolloutsのダッシュボードを表示することができるそうです。
これを使うとさらに使い勝手がよくなりそうですね。