Разворачиваем инструменты CI/CD: практики от DevOps-инженеров

Быстро и стабильно выкатывать релизы — сейчас база. Автоматизировать процесс разработки помогают инструменты CI/CD. По данным исследования CD Foundation, самую высокую эффективность показывают команды, которые используют и managed, и self-hosted решения: так, 12% деплоят аж несколько раз в день (против 10%, которые не используют никакие тулзы).

Мы поговорили с экспертами Solvery — Максимом Воробьевым, DevOps-инженером в Tymy, автором tg-канала, и Евгением Шаповаловым, DevOps Cloud Engineer в Virtuozo — и узнали, какие инструменты выбрать и как избежать подводных камней.

Максим Воробьев

DevOps-инженер в Tymy, ментор Solvery

Евгений Шаповалов

DevOps Cloud Engineer в Virtuozo, ментор Solvery

Лучшие инструменты CI/CD: что использовать?

Как правило, выбор инструмента зависит от ваших конкретных требований, используемой инфраструктуры и опыта команды. Например, если вы работаете над SaaS-приложением и хотите быстро запустить систему без лишних хлопот по поддержке, то SaaS-решения вроде GitLab CI/CD могут быть оптимальным вариантом. А если предстоит разработка крупного проекта со сложными этапами сборки и интеграции (вроде сборки приложений на компилируемых языках с большим количеством зависимостей под разные архитектуры), то на помощь приходит on-premise решение, например, Jenkins.

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

Евгений ШаповаловDevOps Cloud Engineer в Virtuozo, ментор Solvery

А если ваша команда уже знакома с GitLab, и инфраструктура позволяет использовать облачные сервисы, GitLab CI/CD может стать отличным выбором. Его интеграция с репозиторием значительно упрощает настройку пайплайнов, что особенно важно для быстрого развертывания и минимизации затрат на поддержку.

В иностранных компаниях чаще всего используют GitHub в связке с GitHub Actions, хотя после покупки компанией Microsoft никак не могу назвать его самым надёжным — раз в пару месяцев web UI пятисотит, и работа встаёт. При работе с российскими компаниями резко становится актуальным вопрос суверенной инфраструктуры и избежания блокировок, и в этом случае золотым стандартом является GitLab в self-hosted варианте. Он довольно хорошо себя показывает в реальной работе и лёгок в обновлении/обслуживании.

Максим ВоробьевDevOps-инженер в Tymy, ментор Solvery

Какие могут быть проблемы

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

При внедрении CI/CD инструментов можно столкнуться со следующими трудностями:

• Сложность настройки. С некоторыми инструментами придется попотеть, чтобы первоначально настроить конфиги и интегрировать их с существующим системами. 
• Поддержка плагинов. Например, постоянно обновлять и поддерживать плагины нужно в Jenkins.
• Обновления и совместимость. Обновления инструментов могут сломать все совместимости с настроенными конфигами и плагинами. 

Так, на одном из прошлых проектов мигрировали с ingress-nginx на Traefik: дело затянулось из-за несовместимости конфигов, повышенного потребления памяти и разного поведения в очень узких сценариях — пришлось отправлять PR с патчем, а пока его не приняли — использовать кастомно собранную версию.

Максим ВоробьевDevOps-инженер в Tymy, ментор Solvery

Чтобы избежать этого, при проектировании CI/CD системы важно думать о будущем:

• Фундаментальные принципы. Стройте архитектуру таким образом, чтобы она оставалась максимально независимой от конкретного инструмента. Это поможет избежать проблем при смене технологий. Например, для создания раннеров, где будет происходить сборка,  можно использовать подход Infrastructure as a Code — Terraform и ansible. 
• Масштабируемость. Часто изначально упускают из виду рост нагрузки и количество сборок, что может привести к проблемам в будущем. Частая проблема — нехватка железа или борьба за ресурсы, отсюда падает скорость.
• Опыт команды. Отдавайте предпочтение тем системам, в которых у ваших специалистов уже есть опыт. Иногда имеет смысл разделять процессы CI и CD, чтобы можно было оптимизировать их независимо.

Если есть возможность, стоит стремиться к использованию единого инструмента CI/CD для всех команд. Это облегчает обмен опытом и стандартизирует процессы. Однако рост компании и появление новых продуктов иногда требуют перехода на более современные решения. Например, если устаревшая архитектура уже не справляется с нагрузками, переход на GitLab CI/CD может быть проще и эффективнее, чем попытки модернизировать существующую систему.

Евгений ШаповаловDevOps Cloud Engineer в Virtuozo, ментор Solvery

Отказоустойчивость и масштабируемость

Иногда команды, чтобы повысить отказоустойчивость и масштабируемость приложений, разворачивают инструменты CI/CD на разных серверах. Например, GitLab имеет микросервисную архитектуру, и каждый компонент скейлится отдельно. Процесс скейлинга довольно неплохо описан в документации. ​​

Чтобы добавиться отказоустойчивости, следуйте этим шагам:

• продумайте сценарии отказов,
• определите целевые показатели по восстановлению — довольно неплохо про это написано у Atlassian,
• поддерживайте актуальную документацию по системе и ранбуки по её восстановлению,
• делайте бэкапы данных по правилу 3-2-1 и проверяйте их на работоспособность.

Более того, сегодня многие компании переходят к оркестраторам вроде Kubernetes для управления CI/CD-инфраструктурой.

Такой подход позволяет:

• Автоматически масштабировать агентов и интегрировать систему с мониторингом.
• Обеспечить динамическое управление ресурсами (например, установка Jenkins в Kubernetes через Helm-чарт).
• При использовании SaaS-решений проблемы с управлением инфраструктурой отпадают, и можно сосредоточиться на разработке и тестировании.

Риски будут всегда — как и в любой распределенной архитектуре: сетевые задержки, сложнее мониторить и восстанавливать.

Безопасность: как хранить секреты

Безопасность — ключевой момент в любой CI/CD-системе. Очень важно правильно хранить конфиденциальную информацию, такую как ключи, токены и настройки:

• Специализированные сервисы. Используйте решения вроде Microsoft Azure Key Vault, HashiCorp Vault, AWS Secrets Manager или Google Cloud Secret Manager.
• Рекомендации. Никогда не встраивайте credentials в код или образы. 
• Ограничьте доступ к раннерам, организовав его только внутри защищённого контура (например, с помощью RBAC, OAuth и временных токенов).

Лучший способ сохранить креды в секрете — вынести во внешнюю доверенную систему (HashiCorp Vault или форк OpenBao), в которой доступ к ним ограничивается, выдаётся маленькими частями и аудируется.

Максим ВоробьевDevOps-инженер в Tymy, ментор Solvery

Вариант попроще — хранить секреты в репозитории зашифрованными. Это можно делать с помощью проектов Sops или Sealed Secrets, а ключ есть только у доверенных систем (хранится в CI variables / только в K8s кластере).

Но ни в коем случае не храните важные секреты открытыми в репозиториях. Манифест 12 факторов вышел в 2011, но команды до сих пор совершают такие ошибки, и в случае утечки последствия могут быть довольно фатальными.

Как оптимизировать сборку

При сборке Docker-образов в CI/CD pipeline разработчикам часто приходится выбирать между Kaniko и Docker-in-Docker (DinD):

• Kaniko. Это инструмент, который позволяет строить образы внутри контейнеров без запуска демона Docker. Он считается более безопасным и простым в использовании, особенно в Kubernetes-средах.
• Docker-in-Docker. Подход, при котором Docker запускается внутри контейнера. Да, у него полный функционал Docker, но есть и риски, связанные с безопасностью и производительностью, а также сложности в настройке.

На проектах используем DinD — он легко устанавливается, но требует повышенных привилегий. Kaniko — более современный и в теории более безопасный. Если потребуется собирать образы из недоверенных источников, в первую очередь, рассмотрел бы именно его. Лучшую же безопасность обеспечивают Rootless-контейнеры. Сейчас поддерживаю в компаниях доверенные системы, поэтому риски, связанные с privilege escalation, не так значительны. По поводу версионности — используйте immutable tags (у нас commit SHA в качестве версии образа) и не используйте :latest.

Максим ВоробьевDevOps-инженер в Tymy, ментор Solvery

Автоматизация и мониторинг

Минимизировать ручные операции можно и нужно, поэтому не бойтесь автоматизировать. Но не забудьте удостовериться, что время на автоматизацию потрачено с пользой.

Вот, что может помочь:

• Infrastructure as Code (IaC) — Terraform, Ansible, Pulumi для автоматизированного развертывания окружений.
• GitOps + ArgoCD, Flux.
• Шаблоны CI/CD pipeline — стандартизированные pipeline (например, shared GitLab CI templates или Jenkins shared libraries).
• Автоматическое управление версиями и релизами — semantic versioning + Git tags.
• Self-healing механизмы — автоисправление проблем (например, перезапуск зависших pipeline).

Конечно, есть вариант проще: напишите подробный ранбук по ручным действиям, назначьте ответственных за его выполнение, поставьте напоминалку.

В любом случае, надёжный CI/CD требует постоянного контроля:

• Определение метрик. Время сборок, тестов, количество запусков, утилизация выделенного железа
• Мониторинг. Собирайте метрики и логи с помощью инструментов вроде Prometheus и систем логирования, чтобы вовремя обнаруживать проблемы инфраструктуры и следить за метриками CI/CD.
• Уведомления. Настройте интеграцию с системами инцидент-менеджмента, например, Jira, для оперативного реагирования на сбои.
• Хранилище артефактов. Обеспечьте надежное хранение сборочных артефактов (например, с помощью Nexus или Artifactory).

В случае SaaS-решений, например, GitLab или TeamCity, существует поддержка внутренних систем сборки и анализа метрик, а также интеграции с системами мониторинга, поддерживающими стандарты Prometheus.

В РФ часто приходится довольствоваться опенсорс-решениями, много чего недоступно из коробки. Из-за этого даже базовые задачи, вроде сбора метрик для развития CI/CD, превращаются в сложный квест, но без него не получится развивать ваш CI/CD. Часто доработка выходит в копеечку и ложится на плечи отдела разработки. Помимо метрик, собирать и анализировать приходится логи, а значит, нужна система логирования. Опять же накладывается оверхед, если приходится поддерживать несколько CI/CD и новую систему наблюдаемости. Что собирать? Определите несколько ключевых метрик. Это могут быть частота и время пайплайнов интеграции, время прохождения тестов, время восстановления деплоев после падений MTTR и так далее.

Евгений ШаповаловDevOps Cloud Engineer в Virtuozo, ментор Solvery

Какие есть методы быстрого восстановления после сбоев

Самый банальный совет — старайтесь не допускать таких сбоев, восстановление которых требует ручных операций. Правильно настроенные сервисы (в нескольких репликах за балансировщиком, stateless или со стейтом в БД отдельно от сервиса) самовосстанавливаются (спасибо Kubernetes!).

Ещё рекомендация — о сбоях лучше узнавать от мониторинговых систем и заранее («место на диске вот-вот закончится»), а не от пользователей.

Максим ВоробьевDevOps-инженер в Tymy, ментор Solvery

Если сбоя всё-таки избежать не удалось, после восстановления делаем работу над ошибками, пишем постмортемы и улучшаем надёжность на практике. Чиним первопричину сбоя, а не только его последствия.

Вместо заключения

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

• Выбирать технологии с учетом специфики проекта и опыта команды.
• Проектировать архитектуру с прицелом на будущий рост.
• Иногда разделять процессы CI и CD для лучшей оптимизации.
• Интегрировать систему с оркестраторами для повышения отказоустойчивости.
• Использовать специализированные сервисы для безопасного хранения секретов.
• Обеспечить централизованный мониторинг и систему уведомлений.

Наконец, это стратегический процесс, который требует опыта и учета множества факторов. Если вам нужна помощь с выбором оптимального решения или разбор сложных кейсов — на Solvery можно найти DevOps-менторов, которые внедряли CI/CD в продуктах и знают, как избежать типичных ошибок. Разбирайте инфраструктуру с практиками, а не на собственных фейлах.