Лекція 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

Це як сказати: «Дайте мені налаштування для сервісу замовлень, робоче (prod) оточення, остання версія». І в відповіді отримаєте щось на кшталт:

{
    "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
• Налаштуємо клієнтський сервіс
• Навчимося оновлювати конфігурації «на льоту»

І пам'ятайте: хороша конфігурація — як хороший код. Її треба рев'ювати, тестувати й захищати.