Lecture 222: Spring Cloud Config: how to centrally manage configurations

In the last lecture we learned why centralized configuration management is needed and got introduced to Spring Cloud Config. Today we'll dig into how it works under the hood and get ready for some hands-on.

How Spring Cloud Config is organized internally

Remember we talked about Config Server and Config Client? Let's see how those folks talk to each other.

The flow looks like this:

• Git or another repository stores the configurations
• Config Server reads them and exposes them via REST API
• Microservices use Config Client to request their settings

How Spring Cloud Config is organized internally

Remember we talked about Config Server and Config Client? Imagine Config Server as a wise librarian who knows where all the books (configurations) live. And Config Client are the readers (our microservices) who come and ask for their books.

The flow is pretty simple:

[Git/Files] <--- [Config Server] <--- [Microservices]
Repository    REST API + logic    Config Client

Where to store configurations

Spring Cloud Config can work with different backends. Let's go over their pros and cons.

Git repository

Example repo structure:

configs/
  ├── application.yml         # Common settings
  ├── order-service.yml       # Settings for orders
  └── payment-service.yml     # Settings for payments

Filesystem

For those who like to keep things simple

• Just a folder with files
• Perfect for development and experiments
• No Git flow
• Use only for tests

How Config Server serves configurations

Config Server works like a REST API. Think of it as a library catalog:

GET /{application}/{profile}/{version}

For example:

GET /order-service/prod/main

That's like saying: "Give me the settings for the order service, production environment, latest version". And you'll get something like:

{
    "name": "order-service",
    "profiles": ["prod"],
    "properties": {
        "database.url": "jdbc:postgresql://prod-db:5432/orders",
        "kafka.brokers": "kafka1:9092,kafka2:9092"
    }
}

Smart features of Spring Cloud Config

You can create shared settings for all services and override them for specific cases:

# application.yml - common settings
logging:
  pattern: "%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n"

# order-service.yml - service-specific settings
logging:
  level: DEBUG  # Order service needs more logs!

Security first

Spring Cloud Config can encrypt secret data. It looks roughly like this:

# Regular configuration
database:
  url: jdbc:postgresql://localhost:5432/myapp
  username: postgres
  password: {cipher}AQA6EN7aXNXrBFBEpw==

Notice the {cipher}? That means the password is encrypted. The Config Server will decrypt it before sending it to the client.

Integration with Spring Security

You can (and should!) protect your Config Server:

spring:
  security:
    user:
      name: configuser
      password: {cipher}AQB6yvk+yL...

And you can set different permissions for different teams:

• The dev team sees dev configurations
• The ops/support team sees prod
• And the intern works with the test environment

HashiCorp Vault for special cases

When regular encryption isn't enough, bring out the heavy artillery — HashiCorp Vault:

• Stores secrets separately from configs
• Rotates passwords automatically
• Keeps an audit trail of secret access

What to keep in mind

1. Configuration loading order

Config Server loads settings in this order:

1. Common settings (application.yml)
2. Service settings (order-service.yml)
3. Profile settings (order-service-prod.yml)

Later settings override earlier ones. Like CSS, remember?

2. Fault tolerance

What to do if the Config Server becomes unavailable? Options:

• Cache configurations locally
• Use default settings
• Run replicas of the Config Server

The main thing is to plan this ahead, not during a production outage!

3. Monitoring

What to watch in the Config Server:

• Number of config requests
• Server response time
• Errors when fetching settings
• History of configuration changes

Next time

We'll move from theory to practice:

• Bring up our own Config Server
• Connect it to Git
• Configure a client service
• Learn how to update configs "on the fly"

And remember: a good configuration is like good code. It needs to be reviewed, tested, and secured.