11
6

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

Helm環境でConfigMapの更新を検知してPodを自動デプロイする方法

Posted at

概要

以前書いた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使ってない場合はどうするんだ?という疑問が。
手動で入れ替えるしかないのかな?知ってる方がいたら教えてください。

11
6
1

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
11
6

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?