構成サーバーの埋め込み

構成サーバーは、スタンドアロンアプリケーションとして最適に実行されます。ただし、必要に応じて、別のアプリケーションに埋め込むことができます。これを行うには、@EnableConfigServer アノテーションを使用します。この場合、spring.cloud.config.server.bootstrap という名前のオプションのプロパティが役立ちます。これは、サーバーが独自のリモートリポジトリから自身を構成する必要があるかどうかを示すフラグです。デフォルトでは、起動が遅れる可能性があるため、フラグはオフになっています。ただし、別のアプリケーションに組み込む場合は、他のアプリケーションと同じ方法で初期化するのが理にかなっています。spring.cloud.config.server.bootstrap を true に設定する場合は、複合環境リポジトリ構成も使用する必要があります。たとえば

spring:
  application:
    name: configserver
  profiles:
    active: composite
  cloud:
    config:
      server:
        composite:
          - type: native
            search-locations: ${HOME}/Desktop/config
        bootstrap: true

ブートストラップフラグを使用する場合、構成サーバーの名前とリポジトリ URI を bootstrap.yml で構成する必要があります。

サーバーエンドポイントの場所を変更するには、（オプションで） spring.cloud.config.server.prefix （たとえば、/config）を設定して、プレフィックスでリソースを提供できます。プレフィックスは / で開始する必要がありますが、終了することはできません。これは、構成サーバーの @RequestMappings に適用されます（つまり、Spring Boot server.servletPath および server.contextPath プレフィックスの下）。

アプリケーションの構成を（構成サーバーからではなく）バックエンドリポジトリから直接読み取りたい場合は、基本的に、エンドポイントのない組み込み構成サーバーが必要です。@EnableConfigServer アノテーションを使用しないことでエンドポイントを完全にオフにすることができます（spring.cloud.config.server.bootstrap=true を設定）。

組み込み型 vs. スタンドアロン型: 適切なデプロイモデルの選択

構成サーバーをシステムに組み込むか、スタンドアロンサービスとして実行するかは、アーキテクチャの規模とセキュリティ要件によって異なります。以下の表に、主なトレードオフをまとめました。

懸念	組み込み構成サーバー	スタンドアロン構成サーバー
運営上の諸経費	なし — 追加で導入または監視するサービスはありません	専用サービスのデプロイ、運用、監視が必要です。
Git 認証情報	サーバーを組み込むすべてのアプリケーションは、独自の Git 認証情報を保持する必要があります。(SSH keys or username/password)	認証情報は一箇所に保管され、クライアントアプリケーションは構成サーバーの URL のみを必要とします。
暗号化キー	すべてのアプリケーションは独自の暗号化 / 復号化キーを保持しています	キーは構成サーバー上で一元的に管理されます
設定のずれ	各埋め込みアプリケーションは、サーバーのバージョンや構成が若干異なる場合があります。	一元管理により、すべてのクライアントが同じ構成を参照できるようになります。
High availability	HA falls on each application; no shared point of failure	The Config Server itself becomes a shared point of failure (mitigated by clustering or multiple instances)
Network round-trips	ゼロ— configuration is resolved in-process	Adds a network call per startup (and per refresh)
Security isolation	Each application has access to all configurations held in its repository; no per-application access control at the server layer	The standalone server can enforce per-application access control ( セキュリティを参照してください)
Suitable for	Single-application or monolith deployments, local development, or cases where reducing operational overhead outweighs centralization benefits	Microservice environments with many applications that share configuration, strict security requirements, or centralized secrets management

懸念

組み込み構成サーバー

スタンドアロン構成サーバー

運営上の諸経費

なし — 追加で導入または監視するサービスはありません

専用サービスのデプロイ、運用、監視が必要です。

Git 認証情報

サーバーを組み込むすべてのアプリケーションは、独自の Git 認証情報を保持する必要があります。(SSH keys or username/password)

認証情報は一箇所に保管され、クライアントアプリケーションは構成サーバーの URL のみを必要とします。

暗号化キー

すべてのアプリケーションは独自の暗号化 / 復号化キーを保持しています

キーは構成サーバー上で一元的に管理されます

設定のずれ

各埋め込みアプリケーションは、サーバーのバージョンや構成が若干異なる場合があります。

一元管理により、すべてのクライアントが同じ構成を参照できるようになります。

High availability

HA falls on each application; no shared point of failure

The Config Server itself becomes a shared point of failure (mitigated by clustering or multiple instances)

Network round-trips

ゼロ— configuration is resolved in-process

Adds a network call per startup (and per refresh)

Security isolation

Each application has access to all configurations held in its repository; no per-application access control at the server layer

The standalone server can enforce per-application access control ( セキュリティを参照してください)

Suitable for

Single-application or monolith deployments, local development, or cases where reducing operational overhead outweighs centralization benefits

Microservice environments with many applications that share configuration, strict security requirements, or centralized secrets management

When embedding the Config Server in a multi-application environment (for example, if each microservice embeds its own Config Server), each application independently connects to the Git repository. This means each application must possess valid Git credentials and encryption keys, which can complicate secret rotation and auditing.