PipeCDを使ったプログレッシブデリバリー
第2回で触れたようにプログレッシブデリバリーには「トラフィック制御」「分析」「自動化されたロールバック」という3つのプロセスがあります。PipeCDではトラフィック制御はKubernetesのPodsの制御、Istio、Service Mesh Interfaceを利用できます。分析ではPrometheusやDatadogが利用できます。そして分析段階で問題があれば自動でロールバックがされます。
PipeCDの分析機能のことをAutomated Deployment Analysis（ADA）と呼びます。これを利用した今回構築するプログレッシブデリバリーによるソフトウェアデリバリーフローは以下のようになります。
PipedエージェントはHello App Configのprodへの変更を検知すると新しいバージョン（カナリア）をデプロイします。今回の設定では既存のPodsの数の20%のPodsを新たに作成します。トラフィックが流れ出すので、分析（ANALYSISステージ）に移行します。分析段階ではPrometheusを利用します。ANALYSISステージではPrometheusにクエリを投げて、5xx系のエラーに5%以上の増加がないかを30秒間、確認します。5％以上の増加があれば異常としてロールバックをして、問題がなければ既存の全てのPodsを新しいバージョンへロールアウトします。
PipeCDではメトリクスやログを提供するシステム（今回ではPrometheus）をAnalysis Providerと呼びます。
Prometheusのインストール
次のコマンドでmonitoringネームスペースを作成し、Prometheusをインストールします。
$ kubectl create ns monitoring $ kubectl apply -f https://raw.githubusercontent.com/gkuga/hello-app-config/main/monitoring/config-map.yaml $ kubectl apply -f https://raw.githubusercontent.com/gkuga/hello-app-config/main/monitoring/prometheus.yaml
http://localhost:32000でPrometheusのWeb UIを確認できます。
Pipedの設定
WAIT_APPROVALステージを削除しANALYSISステージを追加します。Hello App Configリポジトリのprod/.pipe.yamlを以下のように変更してください。
apiVersion: pipecd.dev/v1beta1
kind: KubernetesApp
spec:
input:
manifests:
- deployment.yaml
- service.yaml
pipeline:
stages:
- name: K8S_CANARY_ROLLOUT
with:
replicas: 20%
- name: ANALYSIS
with:
duration: 1m
metrics:
- provider: prometheus
interval: 30s
expected:
max: 0.05
query: |
sum(rate(http_requests_total{code=~"5.*"}[30s])) or vector(0)
/
sum(rate(http_requests_total{}[30s]))
- name: K8S_PRIMARY_ROLLOUT
- name: K8S_CANARY_CLEAN
変更後のDiffは以下のようになります。
K8S_CANARY_ROLLOUTステージで20％のカナリアをロールアウトします。ANALYSISステージでPrometheusに投げるクエリとその値の許容範囲と分析の時間を指定しています。ここで成功すれば、K8S_PRIMARY_ROLLOUT、K8S_CANARY_CLEANというようにステージが進んでいきます。
次にPipedエージェントの設定を変更します。manifestリポジトリのquickstart/piped-values.yamlにanalysisProvidersの設定を追加します。次のように編集してください。
args:
insecure: true
config:
data: |
apiVersion: pipecd.dev/v1beta1
kind: Piped
spec:
projectID: quickstart
pipedID: YOUR_PIPED_ID
pipedKeyFile: /etc/piped-secret/piped-key
git:
sshKeyFile: /etc/piped-secret/ssh-key
apiAddress: pipecd.pipecd.svc.cluster.local:8080
webAddress: http://localhost:8080
syncInterval: 1m
repositories:
- repoId: hello-app-config
remote: git@github.com:<あなたのGitHubアカウント名>/hello-app-config.git
branch: main
# 以下を追加
analysisProviders:
- name: prometheus
type: PROMETHEUS
config:
address: http://prometheus-service.monitoring.svc.cluster.local:8080
この設定でPipedエージェントがPrometheusを使えるようになります。以下のコマンドで変更を適用してください。
$ helm -n piped upgrade piped ./manifests/piped \ --values ./quickstart/piped-values.yaml \ --set secret.pipedKey.data=<Piped Key> \ --set-file secret.sshKey.data=<作成したSSH秘密鍵ファイルへのパス>
以上でプログレッシブデリバリーのための設定を終わります。
構築したプログレッシブデリバリーの動作確認
構築したプログレッシブデリバリーの動作を確認してみましょう。Hello App Configリポジトリのprod環境のイメージタグを更新してください。しばらくするとデプロイが始まります。ANALYSISステージで設定した時間（30秒間）、Hello Appにアクセスをしないと以下のようになります。
ログを見るとReason: failed to run query: no time series data points in range vector type: no data found.というような表示が確認できます。これはデータがないために失敗したということです。5xx系エラーが設定した5％に達してもロールバックされますが、アクセスがない場合も分析ができずにロールバックされます。ブラウザ上から再デプロイをしてみましょう。PipeCD Web UIのメニューからApplicationsを選択肢、Out of Syncと表示されているprodをクリックしてください。右上にSYNCというメニューがあります。
Pipeline Syncを選び、クリックしてください。再びデプロイが始まるので、今度はツールやブラウザを使い定期的にhttp://localhost:31000/helloにアクセスしてください。しばらくするとデプロイが成功します。ちなみに、Hello Appはhttp://localhost:31000/wrongにアクセスすると500エラーを返すようになっています。分析段階でこちらにアクセスし、設定した5%の値を超えるとデプロイが失敗しロールバックされますので確認してみてください。
まとめ
GitOpsとプログレッシブデリバリーによるソフトウェアデリバリーパイプラインを構築し、実際に体験してみました。第1回と第2回で紹介した概念をPipeCDを使い実装することで運用するイメージが掴めたかと思います。
