CI/CD в Kubernetes

Выбираем инструменты для автоматизации деплоймента
7 минут

Мир разработки стремительно меняется. Лет десять назад большинство компаний использовало монолиты, тестировало и деплоило приложения вручную. Сегодня разработка с учетом микросервисной архитектуры становится стандартом, а вместе с ней — средства оркестрации и CI/CD инструменты. Какие инструменты выбрать с учетом специфики проекта и как их интегрировать в существующие процессы?

Illustration showing stages in a DevOps toolchain
Источник: https://en.wikipedia.org/wiki/DevOps#/media/File:Devops-toolchain.svg

Представим, что мы основали небольшую IT-компанию и приступили к разработке SaaS-решения. Не стоит сразу внедрять все лучшие практики разработки: микросервисы, event sourcing, Kubernetes и другие технологии. Но это не означает, что нужно идти по пути монолита. Необходимо планировать разработку так, чтобы со временем прийти к микросервисам, event sourcing и Kubernetes.

Перед тем как решить, нужен ли вам CI/CD, задайте себе ряд вопросов:

  • Будете ли вы деплоить приложения в облаках?
  • Часто ли вы планируете выпускать релизы?
  • Планируете ли вы использовать end-to-end тестирование?
  • Планируете ли вы использовать инструменты оркестрации?
  • Есть ли необходимость в Chat/Ops? Например, собираетесь ли вы деплоить через чатботов?

Если хотя бы на часть этих вопросов вы ответили «да», задумайтесь о переходе на CI/CD хотя бы в самом базовом виде.


Как выглядит типичный CI/CD в Kubernetes? Чем отличается деплоймент в Kubernetes и Docker от традиционных подходов?

CI/CD предполагает автоматическую интеграцию кода в репозитории, сборку, тестирование и запуск приложений в продакшн. Идеальный для разработчика CI/CD выглядит так: «запушил — увидел результат». Однако то, насколько результат похож на эту идеальную картинку, зависит от среды запуска.

Можно выделить три подхода к проблеме — традиционный деплоймент, деплоймент с Docker и с Kubernetes. Во всех случаях мы имеем дело с этапами создания сборок/образов, тестирования и деплоймента, но в подходах к деплойменту они принципиально отличаются.

Традиционный деплоймент

Для начала традиционный подход к запуску приложений. Допустим, есть машина, на которой мы запустили Tomcat. Чтобы задеплоить новую версию приложения, нужно заменить существующий war-файл, то есть — остановить Tomcat —> заменить war-файл —> запустить Tomcat. В результате при обновлении сервис какое-то время недоступен.

И если у нас несколько машин, процесс обновления нужно последовательно повторить на каждой из них, грубо говоря, вручную.

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

Деплоймент с Docker

Теперь о том, что происходит, когда мы используем Docker без оркестратора. У нас есть docker-контейнер с веб-приложением, который запущен в облаке (например, AWS EC2). Перед тем как задеплоить новый образ, нужно запушить его в registry. При деплое новой версии приложения придется удалить текущий контейнер и сразу же запустить (pull) новый. Разумеется, какое-то время сервис будет недоступен.

В Docker есть собственный инструмент оркестрации — docker compose, который позволяет выполнять rolling update. Однако по сравнению с Kubernetes это довольно простой инструмент, в котором отсутствует возможности управления различными нодами и обеспечения high availability.

Деплоймент с Kubernetes

CI/CD pipeline workflow with Kubernetes
Источник: https://thenewstack.io/ci-cd-with-kubernetes-tools-and-practices/

В Kubernetes процесс деплоймента выглядит следующим образом: после того как вы запушили образ и обновили деплоймент, Kubernetes создаст под с новой версией. После того как он запустится, Kubernetes удалит под со старой версией — так что сервис будет доступен все время в результате «мягкого» rolling upgrade.

Если вы используете Kubernetes, скорее всего, вы деплоите более одного микросервиса, и, следовательно, деплоите часто. В случае с традиционным подходом в таком случае возникает риск длительного downtime. В Kubernetes сервис доступен в любом случае, даже если при деплое что-то пойдет не так.

Kubernetes и GitOps

С Kubernetes легко перейти к GitOps — одному из самых популярных подходов к деплою. Он предполагает, что вы пушите код в git-репозиторий, а все остальные операции от сборки до запуска новой версии выполняются сами. Собственно, здесь и проявляется «настоящий» CI/CD, который стремится автоматизировать все, что только можно автоматизировать.


Что стоит учесть при переходе на CI/CD?

Kubernetes — с ним или без него?

Kubernetes необычайно популярен. Но это не значит, что все компании должны использовать его с первых же дней существования. Если вы — небольшой стартап и ваша текущая цель — создать MVP, Kubernetes подождет. Если же вам нужно быстро масштабироваться, использовать инструменты оркестрации микросервисов, и вдобавок у вас уже есть опыт работы с Kubernetes — самое время подумать о его внедрении.

Простота использования

CI/CD должен быть простым, поэтому выбирайте инструменты, которые совместимы с вашим рабочим процессом. Например, если вы используете Kubernetes, присмотритесь к GitLab — он нативно поддерживает Kubernetes и может работать с несколькими кластерам одновременно.

Everything as a Code

Будьте готовы к тому, что в CI/CD вам придется описывать операции на всех уровнях в виде кода. В Jenkins для этого используется Jenkinsfile в GitLab — gitlab-ci.yml и т.д. Как и в написании любого кода, здесь важна последовательность — в противном случае через некоторое время вы не сможете вспомнить, что и как вы настроили.


Основные инструменты

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

CI/CD для стартапов (Early stages)

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

Travis-CI

Один из простейших в настройке инструментов. Его легко подключить к репозиториям в GitHub при минимальном количестве настроек. Ещё одно преимущество — это облачное решение, его не нужно устанавливать и следить за работоспособностью. Кроме того, он бесплатен для open source-проектов.

Circle-CI

Как и в предыдущем случае, Circle CI работает по принципу «зайди через GitHub и работай». У него удобный веб-интерфейс для управление builds/jobs. Он поддерживает отправку оповещений через электронную почту, slack и так далее. Это простой и удобный инструмент для начальных стадий проектов.

CI/CD для крупных проектов (Mid/Late Stages)

Когда проект уже прошел стадию MVP и вы можете сконцентрироваться на разработке нового функционала, пора переходить на более продвинутые системы с гибкими возможностями конфигурирования и интеграции в существующий процесс работы, например, Jenkins, GitLab, TeamCity.

Jenkins

Jenkins — инструмент, популярный благодаря поддержке разнообразных плагинов для точной настройки CI/CD-процессов под требования разработки. Правда, он не так прост в настройке, и если вы используете open-source-плагины, их работоспособность не гарантируется. Но доступна и более надежная коммерческая версия — CloudBees.

GitLab-CI

GitLab — это CI и репозиторий в одном продукте. Вы можете настроить его так, чтобы код билдился после каждого коммита/merge request, без сторонних сервисов и плагинов. Кроме того, GitLab легко интегрируется с кластерами Kubernetes — вот где настоящий GitOps!

TeamCity

В отличие от двух предыдущих инструментов, TeamCity — проект с закрытым исходным кодом. Возможности бесплатного использования ограничены 3 build-агентами, поддержка доступна по платной подписке. Тем не менее, его предпочитают использовать за простоту установки и конфигурирования, а также широкий функционал из коробки.

Заключение

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

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