Станет ли GitOps новым прорывом в DevOps?

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

Запросы pull — ключевая функция при совместной работе, изменившая подход к разработке программного обеспечения в командах и компаниях. С помощью запросов pull достигается прозрачность и измеримость ранее закрытого процесса. Именно благодаря запросам pull в Git стало возможно применение процессов DevOps в разработке программного обеспечения. А системные администраторы, которые обычно не решались на изменения, теперь используют новые методологии разработки программного обеспечения, такие как agile и DevOps.

Системное администрирование как профессия имеет довольно неприглядную историю. Ранее системные администраторы управляли оборудованием вручную, подключаясь к компьютерам и выделяя ресурсы для них в физической серверной стойке или через облачные API. Помимо ручного выделения ресурсов регулярно требовалось проводить вручную и большие объемы настройки. У администраторов были собственные наборы императивных скриптов и конфигураций, которые они применяли где придется в различных сочетаниях. Эти скрипты могли в любой момент дать сбой или потеряться. Вести совместную работу было затруднительно, поскольку эти индивидуальные цепочки инструментов редко документировались и распространялись.

Движение DevOps возникло из этого первичного бульона системного администрирования. Подход DevOps заимствует лучшие идеи из разработки программного обеспечения и применяет их к системному администрированию, превращая написанные на коленке скрипты в код с управлением версиями.

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

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

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

Императивные инструкции могут выглядеть следующим образом:

1. Установить операционную систему на этом компьютере.
2. Установить эти зависимости.
3. Загрузить код с этого URL-адреса.
4. Переместить код в этот каталог.
5. Повторить 3 раза для 3 других машин.

А декларативная версия будет выглядеть просто: на 4 машинах должно быть установлено программное обеспечение с такого-то URL-адреса в таком-то каталоге.

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

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

GitOps предполагает использование центрального репозитория для обеспечения прозрачности и ясности инфраструктурных потребностей организации. Сохранение всех системных конфигураций в центральном репозитории помогает масштабировать вклад участников команды. Запросы pull, выполняемые через размещенные сервисы Git, такие как Bitbucket, содержат эффективные инструменты для проверки и обсуждения кода. Это создает пассивные круги общения, которые позволяют всей команде инженеров проверять и отслеживать изменения в инфраструктуре.

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

Процедуры GitOps выполняются базовой системой оркестрации. Сама по себе методология GitOps — это независимый набор передовых практик. Многие популярные сегодня решения GitOps используют в качестве системы оркестрации Kubernetes, однако появляются и альтернативные наборы инструментов, которые поддерживают прямое манипулирование платформой Terraform.

Для полной установки GitOps требуется конвейерная платформа. Среди популярных инструментов для конвейера, дополняющих GitOps, можно назвать Jenkins, Bitbucket Pipelines и CircleCI. Конвейеры автоматизируют работу и устраняют разрыв между запросами pull в Git и системой оркестрации. Запросы pull активируют хуки конвейера, после чего выполняются команды для элемента оркестрации.

Новый компонент, введенный в GitOps, — это «оператор» GitOps, расположенный между конвейером и системой оркестрации. Запрос pull запускает конвейер, который затем вызывает оператор. Тот проверяет и синхронизирует состояние репозитория и начало оркестрации. Оператор — это волшебный ингредиент GitOps.

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

Один из участников команды открывает новый запрос pull для оптимизации параметров балансировщика нагрузки. Другой участник команды проверяет и подтверждает запрос pull, после чего он объединяется с репозиторием. При объединении запускается конвейер GitOps, который вызывает оператор GitOps. Оператор регистрирует изменение конфигурации балансировщика нагрузки. Он отправляет запрос инструменту оркестрации системы, чтобы подтвердить, что эта конфигурация не соответствует действующей в кластере команды.

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

Предположим, что команда хочет не просто оптимизировать параметры, а принимает радикальное решение: развернуть балансировщик нагрузки совершенно нового типа. Участники команды считают, что текущий вариант имеет фундаментальные недостатки, и хотят опробовать альтернативу. Рабочий процесс будет таким же, как при настройке отдельного параметра. Команда создает запрос pull, который вводит совершенно новую конфигурацию балансировщика нагрузки и удаляет старую конфигурацию. Его подтверждают и развертывают через конвейер.

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

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