Введение в GitOps и DevOps для разработчиков

Дэвид Тор, генеральный директор Architect.io

Одна из главных целей современной команды DevOps — помочь разработчикам развертывать функции в производстве как можно быстрее. и максимально безопасно. Это означает создание инструментов и процессов, которые делают все, от предоставления частных сред разработки до развертывания и защиты производственных рабочих нагрузок. Эти усилия представляют собой постоянный баланс между тем, чтобы позволить разработчикам двигаться быстро, и гарантией того, что их поспешность не приведет к критическим сбоям. К счастью, и скорость, и стабильность значительно улучшаются всякий раз, когда внедряется автоматизация, такая как GitOps.

Как вы могли догадаться из этого вступления, GitOps — это тактика автоматизации DevOps. Однако, более конкретно, это тактика автоматизации, которая подключается к важнейшему инструменту, который уже существует в повседневном рабочем процессе разработчиков, Git. Поскольку разработчики уже передают код в централизованный репозиторий Git (часто размещаемый такими инструментами, как GitHub, GitLab или BitBucket), инженеры DevOps могут подключать любые свои рабочие сценарии, например те, которые используются для создания, тестирования или развертывания приложений, чтобы запустить отключается каждый раз, когда разработчики вносят изменения в код. Это означает, что разработчики могут работать исключительно с Git, и все, что помогает им запускать свой код в производство, будет автоматизировано за кулисами.

Почему GitOps?

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

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

• Прекратите создавать и поддерживать проприетарные сценарии и вместо этого используйте универсальный процесс

• Создавайте приложения и сервисы быстрее, используя универсальный процесс развертывания.

• Более быстрое подключение за счет развертывания каждый раз, когда они вносят изменения в код.

• Автоматическое развертывание, чтобы выпускать релизы быстрее, чаще и надежнее.

• Откат и прохождение аудита соответствия декларативным шаблонам проектирования

Разработчики любят GitOps

По всем причинам, указанным выше (и многим другим), компаниям нужны управляемые и автоматизированные подходы к CI/CD и DevOps, чтобы добиться успеха в создании и обслуживании облачных приложений. Однако, если автоматизация — это все, что нужно, почему GitOps лучше других стратегий (например, SlackOps, запланированных развертываний или простых скриптов)? Ответ прост: разработчики любят GitOps.

Один инструмент, чтобы управлять ими всеми, Git

В последние несколько лет стало очевидно, что GitOps является одной из наиболее высоко оцененных разработчиками стратегий автоматизации DevOps, и нетрудно понять, почему. Разработчики живут в Git. Они сохраняют временные изменения в git, сотрудничают с помощью git, рецензируют код с помощью git и хранят историю и контрольный журнал всех изменений, которые кто-либо когда-либо делал в git. Описанная выше стратегия конвейерной обработки была специально разработана для git. Поскольку разработчики уже так сильно полагаются на git, эти процессы, в свою очередь, созданы специально для разработчиков. Разработчики осознают это и более чем рады сократить количество инструментов и процессов, которые им необходимо использовать и соблюдать для выполнения своей работы.

Объявлен вместе с кодом

Помимо интуитивно понятного потока выполнения с поддержкой git, еще одна часть современных инструментов CI и GitOps, которая нравится разработчикам, — это декларативный дизайн. Предыдущее поколение инструментов CI имело конфигурации, которые находились внутри частных экземпляров инструментов. Если у вас не было доступа к инструментам, вы не знали, что делают пайплайны, правы они или нет, как и когда они выполняются и как их изменить при необходимости. Это был просто волшебный черный ящик, и поэтому разработчикам было трудно доверять ему.

В современных системах непрерывной интеграции, таких как те, которые чаще всего используются для поддержки GitOps, например CircleCI, Github Actions, Gitlab CI и т. д., конфигурации, поддерживающие конвейеры, находятся непосредственно в репозитории Git. Как и исходный код приложения, эти конфигурации контролируются версиями и видны каждому разработчику, работающему над проектом. Они не только могут видеть, что представляет собой конвейерный процесс, но также могут быстро и легко вносить в него изменения по мере необходимости. Эта простота доступа для разработчиков имеет решающее значение, поскольку разработчики пишут тесты для своих приложений и обеспечивают их безопасность и стабильность.

Полностью самообслуживание

Новые функции или исправления ошибок не считаются завершенными, пока они не будут запущены в производство. Это означает, что все, что мешает внесению изменений в код в производство, отнимает время и умственную энергию разработчика, когда функция, по мнению разработчика, «работает на моей машине». Предположим, разработчикам приходится ждать, хотя бы несколько минут, пока другая команда или отдельный человек выполнит какую-то задачу, прежде чем они смогут завершить свою работу. В этом случае это создает как трения, так и враждебность в организации.

Облегчение этого обмена между командами — одно из основных преимуществ тактики автоматизации DevOps, такой как GitOps. Разработчики не только получают возможность работать в знакомом инструменте, но и возможность запускать свой код в производство без ручного вмешательства означает, что они никогда не ждут кого-то еще, прежде чем они смогут выполнить свои задачи.

Непрерывно все

Еще одно большое преимущество GitOps заключается в том, что все процессы постоянно выполняются! Каждое вносимое нами изменение запускает тестовые сборки и развертывания без ЛЮБЫХ действий, выполняемых вручную. Поскольку разработчики будут использовать git с GitOps или без него, подключение к их существующему рабочему процессу для запуска процессов DevOps — идеальное место для запуска автоматических событий. До тех пор, пока разработчики не перестанут использовать Git, GitOps останется идеальным инструментом для автоматизации DevOps.

GitOps на практике

Естественно, вовлечение разработчиков в процесс привело к тому, что команды стали изучать использование удобных для разработчиков инструментов, таких как Git, но использование Git в качестве источника достоверной информации для процессов DevOps также создает естественную согласованность в форме конвейера CI/CD. этапы. В конце концов, в репозитории Git доступно ограниченное количество хуков (например, коммиты, открытие/закрытие запросов на включение, слияние и т. д.), поэтому внешний вид большинства реализаций GitOps включает набор типичных этапов:

1. Запросы на вытягивание, тесты и среды предварительного просмотра

После того, как разработчики потратили время на написание кода для своей новой функции, они обычно фиксируют этот код в новой ветке Git и отправляют запрос на извлечение или merge request back в основную ветку репозитория. Это то, что разработчики уже делают ежедневно, чтобы побудить технических менеджеров просмотреть изменения кода и утвердить их для объединения с основным кодом приложения. Поскольку разработчики уже используют этот процесс в своей ежедневной совместной работе, это прекрасная возможность для DevOps подключить дополнительные задачи.

Подключаясь к событиям открытия/закрытия, созданным этим процессом запроса на вытягивание, с помощью инструмента непрерывной интеграции (CI), команды DevOps могут инициировать выполнение модульных тестов, создание сред предварительного просмотра и выполнение интеграционных тестов для этой новой среды предварительного просмотра. Инструментарий этих шагов позволяет инженерам-менеджерам быстро установить доверие к изменениям кода и позволяет менеджерам по продуктам видеть изменения кода через среду предварительного просмотра перед слиянием. Более быстрое развитие доверия означает более быстрое слияние, а более ранний ввод данных от менеджеров по продуктам означает более простые изменения без сложных и запутанных откатов. Этот крючок GitOps является ключевым фактором для более быстрой и здоровой работы продуктовых и инженерных групп.

2. Слияние с мастером и развертывание на промежуточной стадии

После того, как все стороны рассмотрят изменения, код может быть объединен с основной веткой репозитория вместе с изменениями, внесенными остальной командой инженеров. Эта основная ветвь часто используется в качестве промежуточной площадки для кода, который почти готов к запуску в производство, и поэтому это еще одно идеальное время для выполнения некоторых операционных задач, таких как тесты и развертывание. Хотя мы тестировали код для каждого запроса на вытягивание перед его слиянием, мы хотим повторно запустить тесты, чтобы убедиться, что код работает с другими изменениями, внесенными членами команды сверстников. Мы также хотим развернуть все эти изменения в общей среде (так называемой «промежуточной»), которую вся команда может использовать для просмотра и тестирования последних изменений, прежде чем они будут выпущены для клиентов.

3. Сокращение релизов и развертывание в рабочей среде

Наконец, после того, как у продукта и инженеров было время просмотреть и протестировать последние изменения в основной ветке, команды готовы вырезать релиз и развернуть его в рабочей среде! Часто эту задачу выполняет менеджер релиза — выделенный (или меняющийся) член команды, которому поручено выполнение сценариев развертывания и мониторинг релиза, чтобы гарантировать, что ничего не пойдет не так в пути. Без GitOps этот член команды должен был бы знать, где находятся правильные сценарии, в каком порядке их выполнять, и должен был бы убедиться, что на его компьютере установлены все правильные библиотеки и пакеты, необходимые для запуска сценариев.

Благодаря GitOps мы можем привязать это развертывание к другому событию на основе Git — создать выпуск или тег. Все, что нужно сделать менеджеру релиза, — это создать новый «релиз», часто используя semver для именования, и задачи по сборке и развертыванию изменений кода будут запущены автоматически. Как и большинство задач, выполняемых инструментом CI, они будут настроены с расположением сценариев и порядком библиотек и пакетов, необходимых для их выполнения.

Инструменты GitOps

Надежный и интуитивно понятный инструмент непрерывной интеграции — не единственное, что необходимо для инструментирования процессов GitOps, подобных описанным в этой статье. Система CI может активировать скрипты на основе событий git, но вам по-прежнему нужны надежные инструменты для запуска этих скриптов и обеспечения их простого и безопасного запуска и обслуживания. Развертывание изменений кода (также известное как непрерывная доставка (CD)) — один из самых сложных шагов для автоматизации, поэтому мы выбрали несколько категорий инструментов, которые могут помочь вам в вашем путешествии по GitOps:

Контейнеризация с помощью Docker

Docker запустил облачную разработку в совершенно новую распределенную среду и помог разработчикам начать реалистично рассматривать микросервисные архитектуры как жизнеспособный вариант. Часть того, что сделало Docker таким мощным, заключалась в том, насколько он удобен для разработчиков по сравнению с решениями виртуализации предыдущего поколения. Как и в случае с декларативными конфигурациями CI, которые находятся в наших репозиториях, разработчикам просто нужно написать и поддерживать файл Dockerfile в своем репозитории, чтобы обеспечить автоматическую сборку развертываемых виртуальных машин в контейнерах. Контейнеризация — чрезвычайно мощная тактика для облачных команд, и она должна стать основным инструментом в вашем репертуаре.

Инфраструктура как код (IaC)

Многое уходит на подготовку инфраструктуры и развертывание приложений, которые не сохраняются в файле Dockerfile. Для всего остального существуют решения «инфраструктура как код» (IaC), такие как [Terraform] (https://www.terraform.io/), [Cloudformation] (https://aws.amazon.com/cloudformation/), и другие. Эти решения позволяют разработчикам описывать другие части приложения, такие как ресурсы Kubernetes, балансировщики нагрузки, сеть, безопасность и многое другое, декларативным способом. Так же, как конфигурации CI и Dockerfiles, описанные ранее, шаблоны IaC могут контролироваться версиями и совместно работать над всеми разработчиками в вашей команде.

Инструменты автоматизации DevOps

Я действительно не могу говорить об автоматизации DevOps, не говоря об Architect. Мы любим IaC и активно используем его как часть нашего продукта. Мы обнаружили, что настройка развертывания, сети и сетевой безопасности, особенно для микросервисных архитектур, может быть требовательной к разработчикам, которые должны сосредоточиться на новых функциях продукта, а не на инфраструктуре.

Вместо написания шаблонов IaC и конвейеров CI, которые требуют от разработчиков изучения Kubernetes, Cilium, шлюзов API, управляемых баз данных или других инфраструктурных решений, просто попросите их написать файл architect.yml. Мы будем автоматически развертывать зависимые API/базы данных и безопасно подключаться к ним каждый раз, когда кто-то запускает architect deploy. Наш процесс может автоматически запускать частные среды разработки, автоматизированные среды предварительного просмотра и даже облачные среды производственного уровня с помощью всего одной команды.

Узнайте больше о DevOps и GitOps

Наша миссия в Architect – помочь операционным и инженерным командам просто и эффективно сотрудничать и одновременно автоматизировать развертывание, сетевое взаимодействие и безопасность.