В прошлой статье Prequel рассматривался деплой приложений с использованием инструмента werf от компании Флант, цель которого была упростить развертывание для разработчиков и по сути разгрузить девопсов(чтобы они не тратили время на деплой приложений по крайне мере дева, так как по сути это все копипаст), уменьшить time to market, в этой статье хочу поделиться опытом этого решения на реальных проектах в ретроспективе, что оказалось не удобно к чему в итоге пришли.
Проблематика
Проблема с чартами
Изначально для разных языков программирования — PHP, Go и JavaScript — были разработаны отдельные Helm-чарты. Это быстро стало неудобным для поддержки. Например, при добавлении функциональности (например, VPA) в чарт для PHP, ту же модификацию приходилось вручную переносить в чарты для других языков. Поддержание консистентности между ними оказалось сложным.
Версионирование и несовместимости
Так как чарт поддерживает семантическое версирование, а сам чарт подгружается на лету при деплое(у нас была указана минорная версия), в случае если кто то напутал с версиями при добавлении фичи в чарт и случилось так что версия не совместима или вообще поломана, но тегнута как патч, может случится так что упадут все деплои при запуске, мы не контролируем обновление чарта.
Проблемы с настройками GitLab CI
У разработчиков сразу появились проблемы с настройками переменных в GitLab
У кого-то не было доступа.
Кто-то не знал, где найти нужные переменные.
Были частые случаи путаницы со значениями переменных(даже у DevOps).
Честно говоря, даже я не всегда помнил, какие именно переменные нужно добавить и куда. Это вызывало множество ненужных коммуникаций и замедляло процесс деплоя.
Сложность CI/CD пайплайна
Со временем шаблон CI/CD стал слишком большим и сложным. Разработчикам приходилось тратить значительное время на его изучение, несмотря на наличие шаблонов и примеров. Это приводило к постоянным вопросам и коммуникациям между разработчиками и DevOps-специалистами, что замедляло процесс работы.
Проблемы с управлением чартами в Git
Отсутствие гетерминизма — серьёзная ошибка. Всё, что касается приложения, должно быть под версионным контролем. В нашем случае Helm-чарты находились вне репозитория Git, хотя они являются частью приложения. Это привело к разрыву в управлении версиями и ухудшило контроль над инфраструктурой.
Fixs
Унификация Helm-чартов
Мы создали единый Helm-чарт, подходящий для всех используемых языков программирования, что значительно упростило поддержку и расширение. Теперь этим чартом деплоятся проекты на PHP, Go, JavaScript и Java, Payton. Это устранило дублирование и необходимость синхронизировать изменения в разных чартах.
Отказ от автоматического выкачивания чартов в CI/CD
Вместо того чтобы загружать чарт автоматически при деплое, теперь его нужно вручную выкачивать и хранить в репозитории приложения. Это обеспечило полный контроль версий чартов.
Однако возникла новая проблема: разработчики без участия DevOps должны уметь загружать чарт, а не все готовы изучать Helm. Документация с последовательными шагами часто оказывается недостаточно эффективной.Мы решили эту задачу с помощью скелетона для приложений. Например, для Go мы создали скелетон, который:
Устанавливает базовую структуру приложения.
Автоматически загружает нужный Helm-чарт.
Разработчику остаётся лишь писать бизнес-логику и настраивать values для деплоя. Такой же подход мы можем применить для PHP и других языков.
Упрощение CI/CD и избавление от лишних переменных
Так как мы убрали автоматическое выкачивание чарта в CI/CD, ненужные переменные в пайплайнах больше не нужны. Это снизило нагрузку на разработчиков и уменьшило количество ошибок при деплое.
Шаблоны CI/CD для упрощения деплоя
Чтобы избавить разработчиков от необходимости вникать в тонкости CI/CD, мы вынесли шаблоны деплоев в общие templates. При установке приложения через скелетон все нужные шаблоны подключаются автоматически. Пример подключения:
include: - project: 'helm-charts/helm-chart' file: '/templates/.gitlab-ci-laravel.yml'
Этот подход также позволяет легко поддерживать шаблоны в одном месте. Например, если нужно добавить стейдж линтинга для Go, мы меняем только один шаблон, и изменения применяются ко всем проектам.
Управление зависимостями через Git
Теперь все зависимости приложения, включая Helm-чарты, находятся под управлением Git. Это решило проблему, когда ранее после клонирования репозитория можно было не найти папку с чартами — что нарушало принцип гетерминизма и усложняло работу. Сейчас все необходимые компоненты деплоя доступны в репозитории приложения.
Итог
Мы значительно сократили время деплоя: раньше деплой готового или даже частично готового приложения мог занимать от одного дня до недели в зависимости от загрузки команды DevOps. Сейчас этот процесс занимает у разработчика около 30 минут. Конечно, у разработчиков всё ещё возникают мелкие проблемы, такие как опечатки, но это уже не критично.
Мы также разгрузили DevOps-команду: теперь разработчики самостоятельно деплоят свои приложения в dev и staging окружения, а деплой в production проходит через ревью-процесс. Этот подход хорошо зарекомендовал себя на практике. Самое важное — разработчики теперь понимают не только то, как писать код, но и что именно они деплоят и куда.
Послесловие
Зачем я написал этот пост? Просто знаю, что многие команды идут похожим путём, и кто-то уже задавал мне вопросы о реализации. Мне захотелось поделиться опытом, накопленным при работе с реальными проектами и взаимодействии с командами разработчиков и DevOps (и да, я сам разработчик, а не DevOps).
Я старался сделать этот пост простым и понятным, без углубления в сложные технические детали, чтобы он был доступен всем читателям. Надеюсь, мой опыт окажется полезным для тех, кто сталкивается с похожими задачами в своих проектах или тем кто уже работает по похожим схемам и чувствует, что что-то идёт не так.
Ребятам из Флант больше спасибо за то что вы делаете.