Ранее в разработке приложений преобладала монолитная архитектура — принцип единого и неделимого кода. Функции "организма" монолитного приложения тесно переплетены и взаимодействуют через внутренние механизмы. Сложно выделить конкретную функцию приложения: любые изменения затрагивают смежные функции. Поэтому каждый шаг разработки обновляет приложение целиком, продукт эволюционирует медленно и неповоротливо.
В противовес этому недостатку монолита появилась микросервисная архитектура. Код строится из простых компонентов, каждый компонент упакован в коробку-модуль и выполняет только собственную функцию. Общение между компонентами тоже простое: один, согласно протоколу, спросил, второй — ответил.
Что изменилось? Во-первых, проектирование модулей обрело независимость. Каждый разработчик (или команда) решает свою небольшую задачу. Во-вторых, развилась утилизация ресурсов. Микросервисы эксплуатируются равномерно, нагрузка на них распределяется оптимально. Как следствие, возникла профилактика кода от ошибок. Сбой в одном из модулей не тянет за собой другие, а в связях между модулями нет «бутылочных горлышек».
Побочный эффект микросервисной архитектуры — стремительное размножение коробок-модулей. Потребовалось наладить логистику. Микросервисы накапливаются и распределяются по репозиториям, а репозитории доставляют модули на сборочную площадку. Такая практика получила название CI/CD (Continuous Integration/Continuous Delivery, непрерывная интеграция/непрерывная доставка).
Внутри каждого репозитория настроены CI/CD-пайплайны — конвейеры передачи модулей на целевую платформу. На платформе (в нашем случае — Kubernetes) модули разворачиваются, переупаковываются, совмещаются в приложение. Получается некий промежуточный результат. Ура.
So… what the HELM?
Каждый отдельный модуль-микросервис несёт в себе метаданные. Много модулей — много метаданных, ими нужно уметь управлять. Helm — инструмент для упаковки модулей с метаданными в пакеты, которые удобно запускать в Kubernetes.
Перед нами встала конкретная задача: перенести в Kubernetes приложение (порядка пятидесяти микросервисов). Перенос происходит так:
- На входе — код-компонент, на выходе — модуль в виде docker-образа.
- Образы доставляются в Kubernetes, на их основе запускаются блоки платформы (pods).
- Для запуска контейнера из pods нужно объявить .yaml манифест. Манифест описывает ресурсы Kubernetes, необходимые для разворачивания.
- Создание манифеста — задача несложная, но рутинная. Один микросервис, в среднем, сопровождается пятью манифестами. Соответственно, у нас было двести пятьдесят .yaml манифестов.
Чем здесь полезен Helm?
- Позволяет создать шаблоны для .yaml манифестов.
Манифест состоит из описания множества объектов. Helm формирует функциональную структуру манифестов — шаблон. В шаблон подставляются значения. Значения хранятся отдельно от шаблонов в values-файле. Теперь вместо описания стопки манифестов можно заполнить один values-файл, и шаблоны соберутся автоматически.
- Распределяет шаблоны по чартам.
Чарт — это структурированный набор шаблонов. Чарт может нести в себе информацию о взаимодействии с другими чартами. Вместе они формируют суперчарт (umbrella-chart). Теперь все микросервисы взаимосвязаны одним документом, и Helm…
- Разворачивает чарты в Kubernetes «одним кликом».
Сравните объем работы:
-
Пятьдесят микросервисов по пять .yaml манифестов. В каждый манифест вручную записываются значения. Микросервисы разворачиваются по отдельности.
-
Манифесты объединены в шаблоны, шаблоны — в чарты, чарты — в «зонтик». Редактируется десяток values-файлов, приложение разворачивается легким движением руки.
Рекомендуем Helm. Пакетный менеджер немногим сложнее пакета с пакетами на вашей кухне.
Дата публикации:
3 ноября 2022
