web-dev-qa-db-ja.com

config-mapkubernetesの複数の環境

Kubernetesクラスターの構成データを使用してSpringBootアプリケーションをデプロイしようとしています。 Kubernetesクラスターから読み取ることでメッセージを出力する単純なRestControllerがあります。

    private String message = "Message not coming from Kubernetes config map";

@RequestMapping(value="/echo", method=GET)
public String printKubeConfig() {
    return message;
}

Application.ymlで構成マップの名前を指定しました

spring:
  application:
    name: echo-configmap

echo-configmap

apiVersion: v1
kind: ConfigMap
metadata:
  name: echo-configmap
data:
  application.properties: |-
    message=Hello from dev Kubernetes Configmap
  application_qa.properties: |-
    message=Hello from qa Kubernetes Configmap

Qa、int、testなどのようないくつかの環境があります

  1. 構成マップで環境固有のプロパティを指定するための最良の方法は何ですか？そして、Springブートアプリケーションでそれらにアクセスする方法は？
    例：アプリケーションがqaにデプロイされている場合、サービスは「Hello from qaKubernetesConfigmap」というメッセージを返す必要があります
  2. また、将来的にはこれらの構成ファイルをGITから読み取る予定です。そのユースケースをどのように処理しますか？
spring-bootdeploymentkubernetes
7
A V

これは Helm の良いユースケースのように聞こえます。アプリケーションを ヘルムチャート としてデプロイできます。これにより、基本的に、テンプレートからKubernetesリソース（ConfigMaps、Deploymentsなどの必要なもの）を生成できます。

Helm Chartsのドキュメント を使用してHelmの使用を開始できます。 helm create を使用してグラフを作成すると、templates/ディレクトリが作成されます。このディレクトリに、ConfigMap用に次のYAMLテンプレートを配置できます。

apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ printf "%s-%s" .Release.Name .Chart.Name }}
  labels:
    app: {{ .Chart.Name | trunc 63 | trimSuffix "-" }}
    chart: {{ .Chart.Name }}-{{ .Chart.Version | replace "+" "_" }}
    release: {{ .Release.Name }}
    heritage: {{ .Release.Service }}
data:
  application.properties: |-
    message={{ .Values.properties.message }}

Deploymentオブジェクトに2番目のYAMLテンプレートを追加できます（実際には、helm createはすでに適切なデフォルトのデプロイメントを作成します）。 ConfigMapをボリュームとして追加するだけです。

containers:
  - name: {{ .Chart.Name }}
    # [...]
    volumes:
      - name: property-volume
        mountPath: /etc/your-app/properties
volumes:
  - name: property-volume
    configMap:
      name: {{ printf "%s-%s" .Release.Name .Chart.Name }}

各ヘルムチャートにはvalues.yamlファイルがあり、このファイルでデフォルト値を定義して、テンプレートの入力に使用できます。このデフォルトファイルは次のようになります（上記のConfigMapテンプレートには{{ .Values.properties.message }}式が含まれていることに注意してください）。

replicaCount: 1
image:
  repository: your-docker-image
  tag: your-docker-tag
properties:
  message: Hello!

次に、このヘルムチャートと helm installコマンド を使用して、さまざまな構成でアプリケーションを何度でもデプロイします。 values.yamlファイルから特定の値をオーバーライドするさまざまなYAMLファイルを提供するか、--setを使用して個々の値をオーバーライドできます。

$ helm install --name dev --set image.tag=latest --set replicaCount=1 path/to/chart
$ helm install --name prod --set image.tag=stable --set replicaCount=3 --set properties.message="Hello from prod" path/to/chart

2番目の質問について：もちろん、ヘルムチャートをバージョン管理に入れる必要があります。次に、 helm upgradeコマンド を使用して、すでにデプロイされているアプリケーションに変更を適用できます。

4
helmbert

ほとんどのボックスにインストールする以外のツールを使用せずに、必要なものが得られると思う答えを提供してみましょう。最初にこれを試してみてください。アプローチの管理と拡張が困難になった場合は、より洗練されたものに移行してください。

ステップ1：環境ごとのバージョン管理構成マップ

k8s/configmapsなどのフォルダーを作成し、環境ごとに1つの構成マップを作成します。

k8s/configmaps/properties.dev.yaml
k8s/configmaps/properties.qa.yaml
k8s/configmaps/properties.sit.yaml
k8s/configmaps/properties.uat.yaml

各構成マップには、環境固有の設定が含まれている必要があります。

ステップ2：環境ごとに名前空間を作成する

次のように、環境ごとにk8s名前空間を作成します。

 application-dev
 application-qa
 application-sit
 application-uat

ステップ3：環境ごとに構成マップを作成する

ここで少しバッシュが役立ちます：

#!/usr/bin/env bash
# apply-configmaps.sh
namespace="application-${ENVIRONMENT}"
for configmap in ./k8s/configmaps/*.${ENVIRONMENT}.yml; do
    echo "Processing ConfigMap $configmap"
    kubectl apply -n ${namespace} -f $configmap
done

これで、任意の環境のまたは更新 configmapsを作成するために必要なことは次のとおりです。

ENVIRONMENT=dev ./update-configmaps.sh

ステップ4：CI/CDでジョブを終了する

これで、CI/CDパイプラインを作成できます。configmapソースが変更された場合は、上記のコマンドを実行するだけです。

概要

プリミティブコマンドに基づいており、特別なツールはありません。

  • バージョン管理構成
  • 環境ごとの構成の管理
  • 構成コードが変更されたときに構成を更新または作成する
  • 必要に応じて、CI/CDパイプラインに同じアプローチを簡単に適用できます

同じ問題を解決するために、より洗練されたツールに飛び込む前に、この基本的な「第一原理」アプローチに従うことを強くお勧めします。多くの場合、多くの場合、多くの労力をかけずに自分でそれを行い、重要な概念を学び、より洗練されたツールを後で保存することができます。あなたは本当にそれを必要としています。

お役に立てば幸いです。

4
Dave Kerr

非秘密データの各gitプロジェクトにこのツールを使用します。 https://github.com/kubernetes-sigs/kustomize

メタデータでは、ポッドをフィルタリングできます

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: mycomponent
    env: dev
    tier: backend
  name: mycomponent
  namespace: myapplication

kubectl get pods -n myapplication -l env = dev、tier = backend、app = mycomponent

2
notmyitblog

通常、qaで実行されているアプリケーションがproductionで実行されているアプリケーションに干渉しないようにする必要があります。 Kubernetesを使用すると、この種の分離を取得できます 環境ごとに異なる名前空間を使用 。このように、prod名前空間上のオブジェクトはqa名前空間上のオブジェクトとは異なります。もう1つのより高価なアプローチは、さまざまな環境にさまざまなk8sクラスターを使用することです。

この設定があれば、デプロイ先の特定の環境の名前空間にアプリケーションをデプロイし、その名前空間にDeploymentオブジェクトを作成します。このDeploymentは、SpringBootプロパティを含むConfigMapオブジェクトを利用します。たとえば、これをConfigMapecho-propertiesと呼びましょう。

そうすれば、すべての名前空間にecho-propertiesConfigMapの一意のコピーがあります。それぞれに、それが属する環境の特定の構成が含まれています。

Deploymentオブジェクトは、環境変数を使用するかファイルを読み取ることにより、ConfigMapプロパティを消費します。ここで重要なのは、echo-propertiesConfigMapデータを変更すると、アプリケーションはそれらの新しい値を認識しないということです。デフォルト。 Kubernetesにはこれまでこの機能がありません。 ConfigMapsを動的構成ソリューションであるSpringCloudConfigと比較することはできません。

同様の動作（ただし、まったく同じではない）を取得するアプローチは、クラスターで fabric8 ConfigMap Controller を使用することです。このコントローラーはクラスター上で実行されるプロセスであり、ConfigMapが変更されるたびにアプリケーションを再起動して、新しい構成値を読み取ります。

構成が変更されるたびにアプリケーションを再起動したくない場合は、変更される可能性のある値についてはSpring Cloud Configに固執し、アプリケーション名など、変更されない他のプロパティについてはConfigMapsを使用する必要があります。またはポート。

0
Jose Armesto

ユースケースは、spring-cloud-config -- https://cloud.spring.io/spring-cloud-config/ を確認する必要があるように聞こえます。

Config-serverは、gitリポジトリに配置できる構成を提供するインフラストラクチャコンポーネントです。

Config-clientアプリケーションは、起動時にconfig-serverに接続し、現在のプロファイルに適用可能な構成をロードします。

環境ごとに異なるブランチを作成することも、環境ごとにプロファイルを使用することもできます。 kubernetesデプロイメントマニフェストで、SPRING_PROFILES_ACTIVE環境変数を設定してプロファイルを設定できます。

0
Mathias Dpunkt