KubernetesでのConfigMapの作成と使用

KubernetesでのConfigMapの作成と使用

  • ITOps・DevOps
5分で読めます 更新日 May 5, 2021

ポイント: KubernetesのConfigMapsは、アプリケーションの設定データをキーと値のペアとして保存します。これにより、環境固有の設定をコンテナから分離し、アプリケーションのポータビリティを向上させます。ConfigMapsはディレクトリ、ファイル、または環境ファイルから作成でき、ポッド内で環境変数や設定ファイルとして利用されますが、機密データには適していません。

  • ConfigMapsは柔軟なアプリケーション構成管理を可能にします。
  • ディレクトリや環境ファイルなど、さまざまな方法を使用して作成できます。

プログラミングでは、envファイルまたは別の構成ファイルを使用して、プログラムを実行するために必要な設定、構成、または変数を保存します。Kubernetesでは、ConfigMapsを使用して同じ機能を実現できます。ConfigMapを正しく理解するには、Kubernetes、Pods、および基本的なKubernetesクラスター管理の知識が必要です。

ConfigMapとは?

ConfigMapは、キーと値のペアとしてデータを保存するために使用できるKubernetes APIオブジェクトです。Kubernetes Podsは、作成されたConfigMapsを以下のように使用できます:

  • 構成ファイル
  • 環境変数
  • コマンドライン引数

ConfigMapsは、環境固有の構成をコンテナから切り離すことによって、アプリケーションをポータブルにする能力を提供します。重要なことに、ConfigMapsは機密データの保存には適していません。暗号化の種類は提供されず、すべてのデータはファイルにアクセスできる人には表示されます。(Kubernetesは機密情報を保存するために使用できるSecretsを提供します。)ConfigMapsのもう一つの考慮事項は、ファイルのサイズです。アプリケーションの設定ConfigMapファイルは1MBに制限されています。より大きなデータセットには、別のファイルマウント、データベース、またはファイルサービスを使用することをお勧めします。

ConfigMapの例

    kind: ConfigMap
apiVersion: v1
metadata:
  name: example-configmap
  namespace: default
data:
  # Configuration Values are stored as key-value pairs
  system.data.name: "app-name"
  system.data.url: "https://app-name.com"
  system.data.type_one: "app-type-xxx"
  system.data.value: "3"
  # File like Keys
  system.interface.properties: |
    ui.type=2
    ui.color1=red
    ui.color2=green

ConfigMapでは、必要な情報をdataフィールドに保存できます。値を保存する方法は2つあります:

  • 個別のキー対プロパティとして
  • 構成形式の断片として、粒度の細かい形式で。 (ファイルのようなキー)

ConfigMapsの作成方法

ConfigMapsとPodsは密接に関連しており、ConfigMapsはKubernetes Pod内の環境変数および構成情報として使用できます。このセクションでは、ConfigMapsの作成方法を見ていきます。始める前にいくつかの注意点があります:

  • Windowsサブシステムを使用したLinux(Ubuntu)をターミナル環境として使用します。
  • DockerデスクトップはKubernetes環境を促進するために構成されます。
  • Kubernetesによって提供された公式サンプルファイルを使用して、ConfigMapの機能をデモンストレーションします。

ディレクトリからConfigMapsを作成

次のコマンドを使用して、ConfigMapディレクトリを作成できます。

    kubectl create configmap

特定のディレクトリ内の適切なファイル(通常のファイル)を探し、ConfigMapを作成するために使用できるファイルを見つけ、他のファイルタイプ(隠しファイル、サブディレクトリ、シンボリックリンクなど)は無視します。まず、次のコマンドを使用してディレクトリを作成します:

    mkdir configmap-example
コマンド

次に、必要なサンプルファイルをディレクトリにダウンロードします。これらのファイルはConfigMapを生成するために使用されます。

    wget https://kubernetes.io/examples/configmap/game.properties -O configmap-example/game.properties

wget https://kubernetes.io/examples/configmap/ui.properties -O configmap-example/ui.properties
cmd

次に、次のコマンドを使用してファイルの内容を確認します。

    cat game.properties
cat ui.properties
Cat Game Properties

ディレクトリを使用してConfigMapsを作成する際に最も重要な要素は、各ファイル内のキーと値のペアを正しく定義することです。その後、create configmapコマンドを使用してConfigMapを作成しましょう。

    kubectl create configmap game-config-example --from-file=configmap-example/
ConfigMap

このコマンドは、指定されたディレクトリ内のファイルをパッケージ化し、ConfigMapファイルを作成します。kubectl describeコマンドを使用して、ConfigMapファイルを表示できます。

    kubectl describe configmaps game-config-example
ゲーム設定の例

次のコマンドを使用して、YAML形式のConfigMapを取得できます。

    kubectl get configmaps game-config-example -o yaml
YAML

ファイルからConfigMapsを作成する

ディレクトリを使用してConfigMapsを作成したのと同様に、kubectl create configmapコマンドの--from-fileパラメータを使用して、単一のファイルを指すことでファイルからConfigMapsを作成することもできます。以下に示すように、game.propertiesファイルを使用してConfigMapを作成しましょう。

    kubectl create configmap game-config-example-2 --from-file=configmap-example/game.properties
kubect
    kubectl describe configmap game-config-example-2
ゲーム設定の例2

さまざまなファイルを使用して単一のConfigMapファイルを作成するために、複数の--from-file引数を定義できます。

    kubectl create configmap game-config-example-2 --from-file=c

環境ファイルからConfigMapを作成

Kubernetesはユーザーがenvファイルを使用してConfigMapsを作成することを許可します。envファイルを定義するときに、--from-env-file引数を使用できます。この引数は、複数のenvファイルを定義するために複数回使用することもできます。envファイルを使用する場合は、各行が

ゲームenv
kubectl
envファイル
キー名
キー例
例のデータ
liteurlの例
例の値
基本プロパティ
基本ConfigMap
例のPod
kubectl logs
アプリケーションデフォルト
Config Map Key参照
Pod作成
アプリケーションタイプ
kubectl create configmap
cat configmap-example/game-env-file.properties
kubectl create configmap game-config-env-file-example --from-env-file=configmap-example/game-env-file.properties
kubectl get configmap game-config-env-file-example -o yaml
kubectl create configmap game-config-key-example --from-file=game-key-example-data=configmap-example/game.properties
kubectl get configmap game-config-key-example -o yaml
kubectl create configmap config-example-values --from-literal=example.value=one --from-literal=example-type=2 --from-literal=example.url="http://example.com"
kubectl get configmap config-example-values -o yaml

app-basic.properties

system.type="TESTING CONFIGMAP"
system.number=12345
kubectl create configmap app-basic-configmap --from-file=configmap-example/app-basic.properties
kubectl get configmap app-basic-configmap -o yaml
kubectl create -f example-pod.yaml
kubectl get pods
kubectl logs configmap-example-pod | grep system.number

application-defaults.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: application-configs
  namespace: default
data:
  app.value: "45000"
  app.type: test-application
  app.ui: web

application-logs.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: application-log-configs
  namespace: default
data:
  log_level: WARNING
  log_type: TEXT
kubectl create -f application-defaults.yaml
kubectl create -f application-logs.yaml
apiVersion: v1
kind: Pod
metadata:
  name: configmap-example-pod
spec:
  containers:
    - name: configmap-example-busybox
      image: k8s.gcr.io/busybox
      command: [ "/bin/sh", "-c", "env" ]
      env:
        - name: APPLICATION_TYPE
          valueFrom:
            configMapKeyRef:
              name: application-configs
              key: app.type
        - name: APPLICATION_UI_TYPE
          valueFrom:
            configMapKeyRef:
              name: application-configs
              key: app.ui
        - name: LOG_LEVEL
          valueFrom:
            configMapKeyRef:
              name: application-log-configs
              key: log_level
  restartPolicy: Never
kubectl create -f example-pod.yaml
kubectl get pods
kubectl logs configmap-example-pod | grep APPLICATION_TYPE
kubectl logs configmap-example-pod | grep APPLICATION_UI_TYPE
kubectl logs configmap-example-pod | grep LOG_LEVEL
apiVersion: v1
kind: Pod
metadata:
  name: configmap-example-pod
spec:
  containers:
    - name: configmap-example-busybox
      image: k8s.gcr.io/busybox
      command: [ "/bin/echo", "Application Type $(APPLICATION_TYPE) - $(APPLICATION_UI_TYPE)" ]
      env:
        - name: APPLICATION_TYPE
          valueFrom:
            configMapKeyRef:
              name: application-configs
              key: app.type
        - name: APPLICATION_UI_TYPE
          valueFrom:
            configMapKeyRef:
              name: application-configs
              key: app.ui
        - name: LOG_LEVEL
          valueFrom:
            configMapKeyRef:
              name: application-log-configs
              key: log_level
  restartPolicy: Never
apiVersion: v1
kind: Pod
metadata:
  name: configmap-example-volume-pod
spec:
  containers:
    - name: configmap-volume-example-busybox
      image: k8s.gcr.io/busybox
      command: [ "/bin/sh", "-c", "ls /etc/config/" ]
      volumeMounts:
      - name: config-volume
        mountPath: /etc/config
  volumes:
    - name: config-volume
      configMap:
        name: application-log-configs
  restartPolicy: Never

これらの投稿は私自身の見解であり、必ずしもBMCの立場、戦略、または意見を代表するものではありません。

ITOps・DevOpsの関連記事

BMCからのさらなる情報に興味がありますか?

ザ・ブリーフは、メインフレームとエンタープライズオーケストレーションに関する月刊メールです:研究、顧客ストーリー、製品ニュース、イベント。

このオファーに登録することで、あなたはBMCのプライバシーポリシーを読み、同意したことを確認します。

ザ・ブリーフに登録しました

ザ・ブリーフは、メインフレームとエンタープライズオーケストレーション—BMC AMIおよびControl-M—に関するアナリストの研究、顧客の展開、両者にわたるイベントを網羅しています。