GitOps, как подход, является достаточно молодым. В интернете существует достаточно много статей на эту тему. Давайте постараемся разобраться в основным терминах и особенностях.
Начнем с краткого обзора истории разработки программного обеспечения.
Вы, вероятно, уже знакомы с термином «Waterfall» в жизненном цикле разработки программного обеспечения. На смену модели Waterfall пришел Agile, который не требует, чтобы вы отправляли в компанию свои многостраничные требования, а скорее были готовы к изменениям и обновлениям каждую неделю. Здесь есть одна проблема. Когда кодовая база исчисляется миллионами строк, а программное обеспечение огромно, простое изменение кода потребует дополнительной работы по интеграции и повторного анализа и запуска тестов. Это может происходить каждую неделю, и при повторении таких сценариев люди неизбежно совершают ошибки. Следовательно, необходимо что-то, что могло бы автоматизировать процесс и снять эту нагрузку с наших плеч.
Это породило механизм CI/CD-пайплайнов. Он может автоматизировать интеграцию, тестирование и создание кода. С помощью всего одного нажатия вручную вы также можете развернуть веб-сайт и обслуживать своих пользователей в кратчайшие сроки. Это стало возможным с помощью инструментов, которые доступны только для этой цели: инструменты CI/CD. Этот процесс называется DevOps, а использование Git аналогичным образом называется GitOps.
Cтоит отметить, что DevOps представляет из себя набор различных практик, призванных увеличить скорость доставки ценности до конечного пользователя. IaC является одной из основополагающих практик.
Что такое GitOps? Первое, что приходит на ум при использовании термина «GitOps», - «DevOps». DevOps включает в себя разработку операционных инструментов и практик в одном. GitOps - это метод имплементации непрерывной поставки (Continuous Delivery, CD), при котором описание и изменение системы производятся декларативно с использованием системы контроля версий (VCS, обычно Git).
GitOps как отдельная практика вполне может входить в набор DevOps-практик, и он как раз направлен на более плотное взаимодействие с разработчиками.
Поскольку Git уже используется для разработки программного обеспечения, вовлечение Git в операции не только включает в себя методы DevOps, но также использует мощь системы контроля версий.
GitOps позволяет разработчикам помещать код инфраструктуры в репозиторий вместе с программным обеспечением. Заметив, что изменение произошло, GitOps вносит необходимые изменения в программную среду и инфраструктуру и перемещает их дальше в пайплайн CI/CD.
Использование GitOps не всегда означает хранение инфра-кода в репозитории с кодом самого приложения. Достаточно часто инфра-код хранится в отдельном инфраструктурном репозитории, что позволяет инфраструктурной команде выполнять различные операции без прямой привязки к команде разработки.
Люди часто воспринимают IaC и GitOps как единый термин. Эта сравнительная таблица может помочь прояснить ситуацию:
IaC - это другой процесс, который стоит сам по себе, в то время как GitOps использует преимущества IaC, а также Git в своей системе.
GitOps напрямую связан с IaC, так как мы оперируем сущностями, которые описаны в виде кода. Работа с таким кодом осуществляется с практиками, которые применимы и в разработке (merge request, review, etc).
Хотя GitOps является довольно новой моделью, ее использование важно и из-за следующих аспектов:
Вовлечение использования Git: использование такой популярной системы контроля версий, как Git, не требует изучения абсолютно нового инструмента, такого как CodeDeploy от Amazon. Вы, скорее всего, знакомы с пользовательским интерфейсом и возможностями Git и GitHub. Вдобавок ко всему, вы получаете все преимущества системы контроля версий мирового класса в вашем операционном управлении.
Прозрачность: поскольку Git знаком всем в команде, любой (из числа авторизованных пользователей) может просто открыть платформу и очень легко увидеть изменения. Вы также можете получить изменения и проанализировать их в системе. Такая прозрачность чрезвычайно полезна для новых участников, которые хотят понимать общие процессы и инфраструктуру.
Ориентация на разработчиков: DevOps требует двух команд: одной для разработки, и одной для управления инфраструктурой. За то, что происходит в инфраструктуре и облаке, отвечает инфраструктурная команда. С GitOps, поскольку Git управляет инфраструктурой, разработчикам просто нужно отправить изменения в репозиторий. Это делает GitOps платформой, ориентированной на разработчиков, где разработчики сами могут управлять инфраструктурой и контролировать ее.
Проще вернуться к предыдущему состоянию: с GitOps очень легко вернуться к предыдущей конфигурации окружения. Все, что вам нужно сделать, это открыть предыдущую версию, которая представляет собой всего два шага в Git, и посмотреть на код того времени, чтобы понять разницу между текущим и предыдущим состоянием инфраструктуры.
Проще откатить изменения: раньше для GitOps откаты были головной болью, так как очень сложно поддерживать предыдущую версию и поддерживать совместимость системы. С помощью GitOps всего несколькими щелчками мыши вы можете вернуться к предыдущему состоянию, если что-то пойдет не так. Если вы знакомы с Git, вы, должно быть, уже знакомы с этим в рамках разработки программного обеспечения.
Командная работа стала проще: Git, как и другие системы контроля версий, позволяет сотрудничать при разработке программного обеспечения. Таким образом, используя те же возможности Git, GitOps позволяет авторизованным пользователям беспрепятственно взаимодействовать друг с другом, находясь в любой точке мира.
Синхронизация окружений: когда мы имеем дело с традиционными методами разработки инфраструктуры, синхронизация окружений для любых целей требует много времени и ресурсов. С GitOps, поскольку мы используем IaC внизу, мы можем в кратчайшие сроки дублировать окружение для других команд, регионов и т. д., поскольку все сохраняется в виде кода внутри инфраструктурного репозитория.
Рентабельность: Управление инфраструктурой является основной причиной расходов в проекте. Преобразование в код и перенос всего в Git значительно сокращает затраты на управление инфраструктурой.
Быстрее развертывание: GitOps обеспечивает более быстрое развертывание, поскольку с GitOps становится чрезвычайно легко управлять инфраструктурой и кодом.
Безопасность: Git позволяет только авторизованным пользователям получать доступ к окружению и вносить какие-либо изменения. Кроме того, известно, что Git хорошо защищен от вредоносных атак, пытающихся проникнуть в конфиденциальные репозитории.
Простой аудит: когда приходит время проанализировать, какие изменения были внесены, как они были реализованы и какие события были выполнены в какое время, Git Logs предоставляет все журналы для таких сценариев, и никаких внешних инструментов не требуется. Это значительно упрощает процесс аудита.
Как показано на изображении в разделе выше, GitOps работает за счет комбинации двух вещей: системы IaC и CI/CD пайплайна. Следовательно, необходимо создание механизма, позволяющего начать работу по принципу GitOps. Чтобы понять пайплайн и процесс разработки, необходимо учесть следующие условия:
Инфраструктурный репозиторий и IaC
В системе, работающей с GitOps, есть два типа репозиториев:
Инфраструктурный репозиторий является единственным в системе и содержит в себе код конфигурации инфраструктуры. Этот код управляет конфигурацией, созданием, обновлением и возможно удалением. Инфраструктурный репозиторий - это сердце IaC. Разработчику необходимо отправить файл с кодом, работающим как инструкции по развертыванию, в этот репозиторий. Когда мы снова хотим изменений, мы повторяем тот же процесс. Второй - это репозиторий кода, который представляет собой обычный репозиторий GitHub.
Инфраструктурный репозиторий всегда является единственным источником правды о том, какая должна быть инфраструктура, и что должно в ней работать. Если при каких-то обстоятельствах состояние инфраструктуры расходится с состоянием описанным в инфра репозитории, GitOps, как инструмент, должен привести целевое состояние системы к состоянию, описанному в инфра репозитории
Другой компонент этой системы - CI/CD пайплайн. Таким образом, до сих пор в наших руках находятся два компонента:
Теперь нам необходим способ соединения этих двух блоков, чтобы CI/CD знал время, когда запускать тесты и развертывать, то есть запускать пайплайн. Для этого мы разберемся с методами развертывания в GitOps.
Развертывание на основе push - это первый из двух методов, используемых для развертывания изменений в GitOps. Развертывание на основе push - это традиционная стратегия развертывания, которую мы используем в DevOps, а также с различными инструментами CI/CD. Это простой процесс отправки кода в репозиторий, который переходит в пайплайн сборки. Если код предназначен для изменения конфигурации инфраструктуры, инфраструктурный репозиторий обновляется, и это изменение запускает пайплайн CI/CD. Поскольку мы сосредоточены на окружении, мы не будем рассматривать развертывание кода или управление контейнерами. Предполагается, что развертывание кода приложения известно как пользователь Git. Те же изменения показаны ниже с изображением потока:
На изображении выше показано, что изменение репозитория приложения запускается в пайплайне сборки. Если есть изменение в репозитории окружения, то же самое обновляется и в репозитории. Затем это изменение запускает пайплайн развертывания, и все изменения развертываются. Инструменты, используемые при развертывании на основе push, - это Jenkins, TeamCity, CircleCI, Travis и т.д.
У развертывания на основе push-запросов есть один серьезный недостаток - это дорога с односторонним движением. Изменения в репозитории среды запускают конвейер развертывания и, следовательно, инфраструктуру. Но что, если что-то случится с самой инфраструктурой? У нас нет метода, кроме ручного анализа состояния инфраструктуры и текущего состояния репозитория инфраструктуры или кода время от времени, чтобы знать, все ли в порядке, или нет. Этот недостаток настолько велик, что его нельзя игнорировать. Поэтому развертывание на основе push в GitOps не рекомендуется.
Развертывание по запросу - развертывание на основе push + оператор
Такая модель развертыванию позволяет решить проблемы доставки кода в защищенную инфраструктуру, к примеру в инфраструктуру банка, где нет доступа “наружу”.
Оператор - это инструмент, который может не только обновлять инфраструктуру, но и следить за ней на предмет непреднамеренных изменений.Оператор может обнаружить любые различия между развернутой инфраструктурой и желаемой инфраструктурой и соответствующим образом действовать в инфраструктурном репозитории. Блок-схема развертывания по запросу может выглядеть следующим образом:
На изображении выше есть два дополнения: первое - это добавление оператора в систему, а второе - двусторонняя стрелка между оператором и конвейером поставки. Поскольку оператор может не только запускать конвейер для изменений, он также может напрямую обращаться к нему, наблюдать за любыми различиями между желаемым состоянием и развернутым состоянием и может записывать то же самое в репозиторий среды. Кроме того, главный герой здесь - оператор, и крайне необходимо уметь хорошо им владеть.
Поскольку сейчас мы работаем с системой контроля версий, которая содержит множество ветвей, мы даже можем соединять разных операторов с разными ветвями для наблюдения. Хотя это повысит сложность системы.
В таблице ниже приведены различные инструменты для каждого процесса, необходимого от передачи кода до развертывания с помощью GitOps. Сравните инструменты и используйте тот, который наиболее соответствует вашим требованиям:
Данный список можно дополнить следующими инструментами: ArgoCD, FluxCD, Werf.
GitOps - недавнее достижение во всем жизненном цикле разработки программного обеспечения. Нет сомнений в том, что GitOps останется с нами надолго, в зависимости от темпов его роста. Но верно также и то, что, поскольку GitOps является относительно новым, организациям еще предстоит полностью сосредоточиться на нем. Этот фокус будет работать как катализатор в методах и инструментах, помогающих улучшить разработку программного обеспечения с помощью GitOps.
GitOps использует инфраструктуру как код в качестве основного механизма для простого, дешевого и быстрого развертывания изменений. GitOps - это процесс, ориентированный на разработчиков, и поэтому он широко принят сообществом.
Часто можно встретить информацию о том, что Kubernetes необходим для GitOps, и это также упомянуто в таблице выше. Это не соответствует действительности: GitOps можно реализовать и без Kubernetes, но оркестровка контейнеров станет дополнительной работой.
Единственная проблема, с которой сталкивается GitOps, заключается в том, что, поскольку он вращается вокруг Git, не все SDLC делает то же самое. GitOps определенно проще и достижимее, но сложные задачи для больших проектов могут вынудить вас выйти за пределы модели GitOps. Выяснить это наверняка можно только путем построения модели и архитектуры проекта.
Запишитесь на вебинар
Расскажите о вашем проекте, мы свяжемся с вами
и вместе рассчитаем стоимость в индивидуальном порядке.
Давайте обсудим ваш проект
и разберемся, как мы можем вам помочь
Остались вопросы?
Мы перезвоним и ответим на них!
Спасибо, ваши данные успешно отправлены!
Мы свяжемся с вами как можно скорее
