第13章 コンフィグマップと秘密 コンフィグマップとシークレット
この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている:translation-feedback@oreilly.com
コンテナ・イメージはできるだけ再利用可能にするのが良い習慣だ。 同じイメージを開発、ステージング、本番で使えるようにするべきだ。 同じイメージがアプリケーションやサービス全体で使用できるほど一般化されていれば、さらに良い。 新しい環境ごとにイメージを作成し直す必要がある場合、テストやバージョニングはよりリスクが高く、複雑になる。 では、実行時にそのイメージの使用を特殊化するにはどうすればいいのだろうか?
ここでConfigMapsとSecretsが登場する。 ConfigMapsは、ワークロードの設定情報を提供するために使用される。 これは、文字列のような細かい情報であったり、ファイル形式の複合値であったりする。 シークレットはコンフィグマップと似ているが、ワークロードが機密情報を利用できるようにすることに重点を置いている。 資格情報やTLS証明書などに使用できる。
コンフィグマップ
ConfigMapを考える1つの方法は、小さなファイルシステムを定義するKubernetesオブジェクトとして考えることだ。 もう1つの考え方は、コンテナの環境やコマンドラインを定義するときに使用できる変数のセットだ。 注意すべき点は、ConfigMapは実行直前にPodと結合されることだ。 つまり、コンテナイメージとPod定義は、使用するConfigMapを変更するだけで、多くのワークロードで再利用できる。
コンフィグマップを作成する
さっそくConfigMapを作成してみよう。 Kubernetesの多くのオブジェクトと同様、ConfigMapは即座に命令形で作成することもできるし、ディスク上のマニフェストから作成することもできる。 まずは命令的なメソッドから始めよう。
まず、例13-1に示すように、問題のPodが利用できるようにしたいファイル(my-config.txtと呼ぶ)がディスク上にあるとする。
例13-1. my-config.txt
# This is a sample config file that I might use to configure an application parameter1 = value1 parameter2 = value2
次に、そのファイルでConfigMapを作成しよう。 ここには、単純なキーと値のペアをいくつか追加する。 これらはコマンドラインではリテラル値と呼ばれる:
$ kubectl create configmap my-config \ --from-file=my-config.txt \ --from-literal=extra-param=extra-value \ --from-literal=another-param=another-value
先ほど作成したConfigMapオブジェクトに相当するYAMLは以下の通りである:
$ kubectl get configmaps my-config -o yaml apiVersion: v1 data: another-param: another-value extra-param: extra-value my-config.txt: | # This is a sample config file that I might use ...