Лекция 222: Spring Cloud Config: как централизованно управлять конфигурациями

На прошлой лекции мы узнали, зачем нужно централизованное управление конфигурациями и познакомились со Spring Cloud Config. Сегодня разберём, как это работает изнутри и подготовимся к практике.

Как Spring Cloud Config устроен внутри

Помните, мы говорили о Config Server и Config Client? Давайте посмотрим, как эти ребята общаются между собой.

Схема работы выглядит так:

• Git или другое хранилище держит конфигурации
• Config Server читает их и предоставляет через REST API
• Микросервисы с помощью Config Client запрашивают свои настройки

Как Spring Cloud Config устроен внутри

Помните, мы говорили о Config Server и Config Client? Представьте, что Config Server – это такой мудрый библиотекарь, который знает, где лежат все книги (конфигурации). А Config Client – это читатели (наши микросервисы), которые приходят и спрашивают свои книги.

Схема работы довольно простая:

[Git/Файлы] <--- [Config Server] <--- [Микросервисы]
Хранилище     REST API + логика    Config Client

Где хранить конфигурации

Spring Cloud Config умеет работать с разными хранилищами. Давайте разберём их плюсы и минусы.

Git-репозиторий

Пример структуры репозитория:

configs/
  ├── application.yml         # Общие настройки
  ├── order-service.yml      # Настройки для заказов
  └── payment-service.yml    # Настройки для платежей

Файловая система

Для тех, кто любит всё попроще

• Просто папка с файлами
• Идеально для разработки и экспериментов
• Никакого Git-флоу
• Используйте только для тестов

Как Config Server выдаёт конфигурации

Config Server работает как REST API. Представьте, что это библиотечный каталог:

GET /{приложение}/{профиль}/{версия}

Например:

GET /order-service/prod/main

Это как сказать: "Дайте мне настройки для сервиса заказов, боевое окружение, последняя версия". И в ответ получите что-то вроде:

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

Умные фичи Spring Cloud Config

Можно создавать общие настройки для всех сервисов и переопределять их для конкретных случаев:

# application.yml - общие настройки
logging:
  pattern: "%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n"

# order-service.yml - специфичные настройки
logging:
  level: DEBUG  # Для сервиса заказов нужно больше логов!

Безопасность превыше всего

Spring Cloud Config умеет шифровать секретные данные. Выглядит это примерно так:

# Обычная конфигурация
database:
  url: jdbc:postgresql://localhost:5432/myapp
  username: postgres
  password: {cipher}AQA6EN7aXNXrBFBEpw==

Заметили {cipher}? Это значит, что пароль зашифрован. Config Server расшифрует его перед отправкой клиенту.

Интеграция со Spring Security

Config Server можно (и нужно!) защитить:

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

А для разных команд можно настроить разные права:

• Команда разработки видит dev-конфигурации
• Команда поддержки видит prod
• А стажёр пусть работает с тестовым окружением

HashiCorp Vault для особых случаев

Когда обычного шифрования мало, подключаем тяжёлую артиллерию — HashiCorp Vault:

• Хранит секреты отдельно от конфигураций
• Автоматически меняет пароли
• Ведёт аудит доступа к секретам

О чём нужно помнить

1. Порядок загрузки конфигураций

Config Server загружает настройки в таком порядке:

1. Общие настройки (application.yml)
2. Настройки сервиса (order-service.yml)
3. Настройки профиля (order-service-prod.yml)

Более поздние настройки перезаписывают ранние. Как в CSS, помните?

2. Отказоустойчивость

Что делать, если Config Server вдруг недоступен? Варианты есть:

• Кэшировать конфигурации локально
• Использовать настройки по умолчанию
• Держать реплики Config Server

Главное - продумать это заранее, а не во время падения продакшена!

3. Мониторинг

За чем следить в Config Server:

• Количество запросов к конфигурациям
• Время ответа сервера
• Ошибки при получении настроек
• История изменений конфигураций

В следующий раз

Мы перейдём от теории к практике:

• Поднимем свой Config Server
• Подключим его к Git
• Настроим клиентский сервис
• Научимся обновлять конфигурации "на лету"

И помните: хорошая конфигурация — как хороший код. Её нужно ревьювить, тестировать и защищать.