ConfigMap（コンフィグマップ）

2025年11月6日

ConfigMap（コンフィグマップ）

英語表記: ConfigMap

概要

ConfigMapは、Kubernetes環境において、アプリケーションの構成情報（設定ファイル、環境変数、コマンドライン引数など）をコンテナイメージやコード本体から切り離して管理するためのAPIオブジェクトです。これは、オーケストレーション（Kubernetes, OpenShift）における最も重要な機能の一つであり、アプリケーションのポータビリティと柔軟性を高めるために設計されています。ConfigMapを利用することで、アプリケーションの動作に必要な設定をデータとして外部化し、Pod（アプリケーションを実行する最小単位）が実行時にその設定を動的に利用できるようになるため、構成/シークレット管理の核となる仕組みだと断言できます。

詳細解説

ConfigMapがオーケストレーション（Kubernetes）における「構成/シークレット管理」の分野で重要視されるのは、設定情報をアプリケーションから分離することで、環境に依存しない汎用的なコンテナイメージの利用を可能にするためです。

目的と背景

従来のアプリケーション開発では、開発環境、ステージング環境、本番環境といった異なる実行環境に応じて、データベースの接続先やログレベルなどの設定値をコード内部に記述するか、コンテナイメージ内にバンドルすることが一般的でした。しかし、この方法では、設定を変更するたびにイメージを再ビルドする必要が生じ、オーケストレーションシステムの目的である迅速なデプロイとスケーリングが阻害されてしまいます。

ConfigMapは、この問題を解決するために生まれました。設定データをKey-Value（キーと値）のペアとしてKubernetesクラスタ内に保存し、アプリケーションの実行時（Podの起動時）に設定値が必要なPodに対して、そのデータを「注入」します。この分離原則により、同じコンテナイメージを使いながら、ConfigMapの内容を切り替えるだけで、異なる環境に対応できるようになるのです。これは、Kubernetesの柔軟性を支える非常に強力なメカニズムだと感じています。

動作原理と構成要素

ConfigMapは、主に以下の方法でPodに構成情報を渡します。

環境変数（Environment Variables）として注入:
ConfigMap内の特定のキーの値を、Pod内のコンテナの環境変数として設定します。これは最も手軽な利用方法です。
ボリュームマウント（Volume Mounts）によるファイルとしての注入:
ConfigMap全体、あるいは特定のキーの内容をファイルとしてPod内の特定のパスにマウントします。これにより、従来のアプリケーションが設定ファイルを読み込むのと同じ方法でConfigMapのデータを利用できます。Webサーバーの設定ファイルやカスタムスクリプトなど、複雑な設定を扱う場合に特に有効です。
コマンドライン引数（Command Line Arguments）としての利用:
Podの起動コマンドの引数として、ConfigMapの値を参照して渡すことも可能です。

ConfigMapが格納するデータは、基本的にテキスト形式であり、機密性のない非構造化データや構造化データ（JSON, YAML, Propertiesファイルなど）を保持します。ただし、ここで注意が必要なのは、ConfigMapはあくまで「構成情報」を扱うものであり、パスワードやAPIキーといった「機密情報」は、同じ構成/シークレット管理カテゴリに属するSecret（シークレット）オブジェクトで扱うべきだという点です。ConfigMapのデータはBase64エンコードされていないため、クラスタ内部から容易に閲覧できてしまうからです。この使い分けの理解が、Kubernetesのセキュリティを確保する上で非常に重要です。

具体例・活用シーン

ConfigMapの働きを理解するための最も分かりやすい例は、「料理のレシピと調味料の棚」の比喩です。

アプリケーション（Pod）のコードは、料理のレシピに相当します。レシピ（コード）自体には、「塩を少々、胡椒を多めに」といった具体的な味付けの指示はありますが、実際に使う塩や胡椒の銘柄や量が明記されているわけではありません。

ConfigMapは、このレシピに具体的な味付けを与える調味料の棚です。

開発環境のConfigMap（調味料の棚A）: ログレベル＝DEBUG、DB接続先＝localhost:5432
本番環境のConfigMap（調味料の棚B）: ログレベル＝INFO、DB接続先＝prod-db-cluster:5432

同じレシピ（コンテナイメージ）を使って料理（アプリケーション）を実行する際、Kubernetes（料理人）は、どの環境で実行するかによって、棚Aまたは棚Bから調味料（設定）を取り出してアプリケーションに渡します。これにより、レシピを書き換えることなく、環境ごとに異なる味付け（設定）を実現できるのです。この分離こそが、オーケストレーションの真髄であり、運用管理を劇的にシンプルにします。

活用シーンの具体例

環境ごとのエンドポイント設定:
マイクロサービスアーキテクチャにおいて、他のサービスやデータベースの接続URLを環境変数としてConfigMapに定義し、各Podに注入します。
サードパーティAPIキー/トークン管理（非機密部分）:
公開されているAPIのキーや設定情報など、機密性の低い設定値を管理します。（機密性の高い認証情報はSecretを利用します。）
設定ファイルの管理:
NginxやApacheの設定ファイル全体（例：nginx.conf）をConfigMapに格納し、ボリュームマウントによってコンテナ内の所定のパスにファイルとして配置します。これにより、設定変更時にコンテナイメージを再ビルドする手間がなくなります。

資格試験向けチェックポイント

ConfigMapは、IT Passportでは直接的な出題は稀ですが、基本情報技術者試験や応用情報技術者試験の午後問題、あるいはクラウド/コンテナ関連の専門資格では頻出する重要概念です。特に、オーケストレーション（Kubernetes）における構成管理の基礎として問われます。

ConfigMapとSecretの明確な違い:
ConfigMapは「非機密情報（平文）」の構成管理に使用し、Secretは「機密情報（パスワードなど）」の管理に使用します。この使い分けは、セキュリティの観点から非常に重要です。
構成の外部化（Separation of Concerns）:
ConfigMapの最大の目的は、アプリケーションのコードと構成情報を分離することであり、これによりポータビリティと再利用性が向上します。オーケストレーションのメリットとして説明できるようにしておきましょう。
データの注入方法:
ConfigMapのデータをPodに渡す主な方法（環境変数、ボリュームマウント）を理解しておく必要があります。特にボリュームマウントによってファイルとして利用できる点は、実践的知識として問われやすいです。
ConfigMapのデータ形式:
ConfigMapはKey-Value形式でデータを保持します。値はテキストデータであり、バイナリデータは基本的に扱いません。
階層構造の理解:
この機能が「オーケストレーション（Kubernetes, OpenShift） → Kubernetes 機能 → 構成/シークレット管理」のパスに位置づけられるのは、システム全体を効率的に管理し、設定のセキュリティと柔軟性を担保する役割を担っているからです。