Перейти к основному содержимому

HSM: Docker Workflow Deep Dive

Этот документ описывает, как hsm управляет инфраструктурными сервисами на базе Docker, обеспечивая гибкость разработки и надежность продакшена.

1. Проблема: Статичность Docker Compose​

Традиционный docker-compose.yml статичен. Разработчику часто приходится:

  • Комментировать/раскомментировать сервисы.
  • Вручную менять image на build при переходе к разработке компонента.
  • Следить за тем, чтобы локальные пути не попали в репозиторий.

2. Решение HSM: Динамическая генерация Override​

HSM использует мощь Profiles и Override-файлов, чтобы превратить Docker Compose в динамическую среду.

Преимущества HSM для Docker:​

  • Profiles Management: HSM автоматически активирует нужные профили сервисов на основе выбранных групп в hsm.yaml.
  • Seamless Mode Switch: Переключение между "готовым образом" и "сборкой из исходников" одной командой.
  • Ephemeral Overrides: Все локальные пути и настройки разработки живут в генерируемом файле docker-compose.hsm.yml, который не засоряет основной конфиг.

3. Детальный процесс (Step-by-Step)​

А. Режим Разработки (Dev)​

Когда сервис переведен в dev:

  1. Cloning: HSM обеспечивает наличие исходного кода сервиса.
  2. Override Generation: HSM создает docker-compose.hsm.yml, где для сервиса:
    • image заменяется на build (если указан build-path).
    • Прописываются dev-volumes для монтирования локального кода (Hot Reload).
    • Устанавливаются переменные окружения для дебага.
  3. Execution: hsm sync подготавливает всё необходимое. Запуск осуществляется через стандартный docker compose с подключением сгенерированного файла.

Б. Режим Продакшена (Prod)​

При переключении в prod:

  1. Image Resolution: HSM берет актуальную версию образа из Реестра.
  2. Clean Override: В генерируемом файле указывается только image и необходимые лимиты.
  3. Deployment: Готовый файл можно использовать для деплоя на сервер.

4. Группы сервисов (1-of-N)​

Это одна из самых мощных функций. Вы можете определить группу database и переключаться между postgres и mysql в hsm.yaml. HSM сам перестроит docker compose так, чтобы под логическим именем db в вашей сети поднялся нужный контейнер.

5. Implication Merging (Слияние параметров)​

В сложных системах несколько пакетов могут требовать один и тот же сервис, но с разными настройками. HSM автоматически объединяет эти требования. Например, если два плагина требуют разные базы данных в одном Postgres, HSM сгенерирует конфигурацию с объединенным списком БД, используя синтаксис ${HSM_MERGED_PARAMS.db_name} в манифесте сервиса.

5. Итог​

HSM превращает Docker из "просто контейнеров" в гибкий конструктор. Вы управляете стеком (Stack), а не отдельными файлами конфигурации.