概要
以前書いたGKEでArgoを使ったカナリアリリースを実現する（完結編）でArgoとHelmを使用したカナリアデプロイをご紹介しました。
これと同等の構成を別環境で構築した際、ConfigMapの更新が反映されてないぞ？ ということがあり、ハマったのでご紹介します。
ハマったこと
GKE上でNginxを動かす要件ができたため、kubernetesで動かすソフトウェアの設定をConfigMapで記述するを参考に、ConfigMapにNginxを設定を入れておき、Nginx用のPodがMountする方式を取ることにしました。
ConfigMapの設定を書き換えてGitHubにPushすると、Argoが更新を検知してConfigMapが更新され、
さらにそれをMountしているNginx用PodのNginx設定も動的書き換わっていることが確認できました。
ちなみにConfigMapを参照する方法として、VolumeでMountする方法と環境変数として渡す方法の2通り方法があります。
VolumeでMountする方法は、一定期間ごとに変更を確認し、ConfigMapに変更がある場合は動的に反映させます。
一方、環境変数として渡す方法は、動的な反映はしないようです。
詳細は、KubernetesのConfig＆Storageリソース（その1）が分かりやすかったです。
一見、VolumeでMountする方法でPodのNginx設定は反映されているように見えますが、
起動しているNginx Podは、一つ前のNginxの設定で起動したものであり、新しいNginx設定を反映させるには、Podの再デプロイが必要となります。
もちろん手動で再デプロイやることは可能ですが、Pod数が増えてきたりするとあまり現実ではないので、
ConfigMapの更新を検知してPodを自動デプロイする方法を調査しました。
実現方法
Helmを使用している場合、以下のようなannotationを入れることで、自動デプロイが実現できました。
kind: Deployment
spec:
template:
metadata:
annotations:
checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") . | sha256sum }}
Automatically Roll Deployments When ConfigMaps or Secrets changeによると、sha256sum関数を使用して、指定したConfigMapのManifestファイルのHash値が更新されることにより、annotationに更新がかかります。そして、その差分を検知したArgoがPodを再デプロイといった感じでしょうか。
まとめ
Helm使ってない場合はどうするんだ？という疑問が。
手動で入れ替えるしかないのかな？知ってる方がいたら教えてください。