Родительский helm chart для проектов + werf Sequel

dd05ae5d6713b8dcaf7344e035236e44.png

В прошлой статье Prequel рассматривался деплой приложений, цель которого была упростить развертывание для разработчиков и по сути разгрузить девопсов (чтобы они не тратили время на деплой приложений по крайне мере дева, так как по сути это все копипаст), уменьшить time to market, в этой статье хочу поделиться опытом этого решения на реальных проектах в ретроспективе, что оказалось не удобно к чему в итоге пришли.

Проблематика

  1. Проблема с чартами

    Изначально для разных языков программирования — PHP, Go и JavaScript — были разработаны отдельные Helm-чарты. Это быстро стало неудобным для поддержки. Например, при добавлении функциональности (например, VPA) в чарт для PHP, ту же модификацию приходилось вручную переносить в чарты для других языков. Поддержание консистентности между ними оказалось сложным.

  2. Версионирование и несовместимости

    Так как чарт поддерживает семантическое версирование, а сам чарт подгружается на лету при деплое (у нас была указана минорная версия), в случае если кто то напутал с версиями при добавлении фичи в чарт и случилось так что версия не совместима или вообще поломана, но тегнута как патч, может случится так что упадут все деплои при запуске, мы не контролируем обновление чарта.

  3. Проблемы с настройками GitLab CI

    У разработчиков сразу появились проблемы с настройками переменных в GitLab

    • У кого-то не было доступа.

    • Кто-то не знал, где найти нужные переменные.

    • Были частые случаи путаницы со значениями переменных (даже у DevOps).

    Честно говоря, даже я не всегда помнил, какие именно переменные нужно добавить и куда. Это вызывало множество ненужных коммуникаций и замедляло процесс деплоя.

  4. Сложность CI/CD пайплайна

    Со временем шаблон CI/CD стал слишком большим и сложным. Разработчикам приходилось тратить значительное время на его изучение, несмотря на наличие шаблонов и примеров. Это приводило к постоянным вопросам и коммуникациям между разработчиками и DevOps-специалистами, что замедляло процесс работы.

  5. Проблемы с управлением чартами в Git

    Отсутствие гетерминизма — серьёзная ошибка. Всё, что касается приложения, должно быть под версионным контролем. В нашем случае Helm-чарты находились вне репозитория Git, хотя они являются частью приложения. Это привело к разрыву в управлении версиями и ухудшило контроль над инфраструктурой.

Fixs

  1. Унификация Helm-чартов

    Мы создали единый Helm-чарт, подходящий для всех используемых языков программирования, что значительно упростило поддержку и расширение. Теперь этим чартом деплоятся проекты на PHP, Go, JavaScript и Java, Payton. Это устранило дублирование и необходимость синхронизировать изменения в разных чартах.

  2. Отказ от автоматического выкачивания чартов в CI/CD

    Вместо того чтобы загружать чарт автоматически при деплое, теперь его нужно вручную выкачивать и хранить в репозитории приложения. Это обеспечило полный контроль версий чартов.
    Однако возникла новая проблема: разработчики без участия DevOps должны уметь загружать чарт, а не все готовы изучать Helm. Документация с последовательными шагами часто оказывается недостаточно эффективной.

    Мы решили эту задачу с помощью скелетона для приложений. Например, для Go мы создали скелетон, который:

    Разработчику остаётся лишь писать бизнес-логику и настраивать values для деплоя. Такой же подход мы можем применить для PHP и других языков.

  3. Упрощение CI/CD и избавление от лишних переменных

    Так как мы убрали автоматическое выкачивание чарта в CI/CD, ненужные переменные в пайплайнах больше не нужны. Это снизило нагрузку на разработчиков и уменьшило количество ошибок при деплое.

  4. Шаблоны CI/CD для упрощения деплоя

    Чтобы избавить разработчиков от необходимости вникать в тонкости CI/CD, мы вынесли шаблоны деплоев в общие templates. При установке приложения через скелетон все нужные шаблоны подключаются автоматически. Пример подключения:

    include: - project: 'helm-charts/helm-chart' file: '/templates/.gitlab-ci-laravel.yml'

    Этот подход также позволяет легко поддерживать шаблоны в одном месте. Например, если нужно добавить стейдж линтинга для Go, мы меняем только один шаблон, и изменения применяются ко всем проектам.

  5. Управление зависимостями через Git

    Теперь все зависимости приложения, включая Helm-чарты, находятся под управлением Git. Это решило проблему, когда ранее после клонирования репозитория можно было не найти папку с чартами — что нарушало принцип гетерминизма и усложняло работу. Сейчас все необходимые компоненты деплоя доступны в репозитории приложения.

Итог

Мы значительно сократили время деплоя: раньше деплой готового или даже частично готового приложения мог занимать от одного дня до недели в зависимости от загрузки команды DevOps. Сейчас этот процесс занимает у разработчика около 30 минут. Конечно, у разработчиков всё ещё возникают мелкие проблемы, такие как опечатки, но это уже не критично.

Мы также разгрузили DevOps-команду: теперь разработчики самостоятельно деплоят свои приложения в dev и staging окружения, а деплой в production проходит через ревью-процесс. Этот подход хорошо зарекомендовал себя на практике. Самое важное — разработчики теперь понимают не только то, как писать код, но и что именно они деплоят и куда.

Послесловие

Зачем я написал этот пост? Просто знаю, что многие команды идут похожим путём, и кто-то уже задавал мне вопросы о реализации. Мне захотелось поделиться опытом, накопленным при работе с реальными проектами и взаимодействии с командами разработчиков и DevOps (и да, я сам разработчик, а не DevOps).

Я старался сделать этот пост простым и понятным, без углубления в сложные технические детали, чтобы он был доступен всем читателям. Надеюсь, мой опыт окажется полезным для тех, кто сталкивается с похожими задачами в своих проектах или тем кто уже работает по похожим схемам и чувствует, что что-то идёт не так.

© Habrahabr.ru