ざっくり理解するOpenShift(Kubernetes)のConfigMapとSecret

はじめに

OpenShift/KubernetesにおけるConfigMapとSecretについて概要を解説します。

詳細な機能や仕様には深入りせず、全体像をつかむことを目的としています。
OpenShiftやKubernetesを使い始めたばかりで、まずは手早く理解したいという方は、ぜひ参考にしてください。

ConfigMap、Secretとは

SecretやConfigMapを用いることで、アプリケーションの設定情報や機密データをコンテナイメージに含めることなく、外部で管理できます。

Podからこれらのオブジェクトを参照するだけで、アプリケーションはPod内でそのデータを利用することが可能です。

• ConfigMap
  • アプリケーションの非機密な設定データを保存するために使用されます。
    例えば、データベースのホスト名、ポート番号、ログレベルなどの環境変数、設定ファイルそのものなどです。
  • ファイル(設定ファイル、テキストファイルなど)や環境変数としてPodから参照させることが可能です。
  • https://kubernetes.io/ja/docs/concepts/configuration/configmap/
• Secret
  • アプリケーションの機密データを保存するために使用されます。
    例えば、データベースのパスワード、APIキー、TLS証明書、SSHキーなどです。
  • ファイルとしてPodから参照させることが可能です。
  • https://kubernetes.io/ja/docs/concepts/configuration/secret/

※ConfigMap、Secretともに、Pod側からは参照のみ可能であり更新を行うことはできません。
※ConfigMap、Secretともに、プロジェクト(Namespace)ごとに作成が必要です。
　例：プロジェクトAで作成したConfigMapをプロジェクトB内のPodから参照させることはできません。

ConfigMap、Secretのメリット

従来の物理/仮想マシン環境では、構成管理ソフトウェアやバッチ処理を用いて各サーバへアプリケーションの設定ファイルを配備しているケースも多いかと思います。

一方、OpenShift/Kubernetesでは、起動中の複数のコンテナ内のディレクトリへファイルを一括で送り込むような機能は標準で提供されていません。
もし従来と同じような仕組みを実現したい場合は、CI/CDパイプラインなどを利用し、各コンテナへアクセス・ファイルを更新するような処理を個別に作り込む必要があります。

ただし作り込みで実現する場合、コンテナは再起動すると内部のデータが消えてしまうため、起動のたびにファイルを再配布する仕組みも用意する、または永続ボリュームをマウント(ストレージを確保)するといった対策も同時に行う必要があります。

そのため、従来の方法をそのまま適用するのはコンテナ環境では思った以上に障壁が高いと言えます。

この課題を解決する仕組みとしてOpenShiftでは、ConfigMapやSecretといった独自のリソースが提供されています。
これらを用いることで、設定ファイルを効率的に反映・管理することを可能にしています。

各Podが参照しているConfigMapやSecretを更新(上書き)することで、設定ファイルを一度に変更することが可能です。

ConfigMapやSecretの内容はYAMLファイルとしてテキストで管理することが可能です。

更新の際はYAML形式のテキストファイルを編集し、OpenShiftのCLIツールであるocコマンド(Kubernetesのkubectl)やOpenShift Webコンソール(Kubenetesであればrancherなどの利用が可)などで反映が行えます。

oc apply -f <ConfigMap YAML>

参考：ConfigMap、Secretの管理方法について

ConfigMapやSecretだけに限りませんが、OpenShift(Kubernetes)のリソースはYAMLというテキストファイルで定義します。

そのため、実運用の場では「このYAMLファイル群をどこに保管し、どうやって更新していくか？」といった運用ルールをあらかじめ考えておく必要があります。

一般的によく使われるのは、Gitのようなバージョン管理システムです。

YAMLファイルもテキストであるためGitでの管理が容易であるほか、Gitを利用することで「誰がいつ何を変更したか」の履歴の管理、チームでのレビューも行いやすいなど運用上もメリットが多く得られます。

ただし、コンテナ上で動作させるアプリケーションのソースコードとOpenShift(Kubernetes)のYAMLファイルを別々に、別々のチームで管理する必要のあるプロジェクトなどでは注意が必要です。

例えば、アプリケーションの更新で新しい環境変数が必要になった際に、ソースコードは更新されたのに、その環境変数を定義するConfigMap（YAML）の更新が漏れてしまうと、両者の間でバージョンの食い違いが生まれます。

その結果、デプロイされたアプリケーションは設定不足で起動に失敗するといった問題が発生する可能性があります。

あらかじめリソースの更新方法/管理方法については十分に整理をおすすめします。

※Kustomizeなどのツールを利用することでより差分の管理も行いやすくなります。
　https://kustomize.io