Что такое «GitOps» и почему это важно?

GitOps — это подход к инфраструктуре, который использует лучшие практики разработки программного обеспечения и применяет их к ИТ-системам. GitOps основывается на модели «Инфраструктура как код» для создания автоматизированной модели инфраструктуры, которая поддерживает совместную работу и имеет версии, аналогичные вашему коду.

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

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

В конечном итоге репозиторий инфраструктуры очень похож на репозиторий программного обеспечения. Вы создаете ветку для каждого изменения, обновляете свои файлы конфигурации, выполняете проверку и объединяетесь с основной веткой. Затем автоматический инструмент, такой как Ansible или Terraform, применяет изменения к вашей среде. Рабочий процесс — это та же модель версионного ветвления, которую используют разработчики.

Что такое Гит?

Git в GitOps относится к системе контроля версий Git. Git стал предпочтительным инструментом управления исходным кодом для большинства разработчиков. Он имеет децентрализованную модель хранения и делает упор на использование локальных филиалов для развития изменений.

Системы контроля версий упрощают повторение вашей работы. Вы можете работать с автономными компонентами параллельно, используя ветки, прежде чем объединиться с основной веткой, представляющей «выпущенную» версию вашего проекта. Вы отправляете свой код в общий репозиторий, часто в такой сервис, как GitHub или GitLab, чтобы поделиться им с другими.

Декларативная инфраструктура

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

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

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

Возможность проверки

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

Репозиторий — единственный источник правды. Отсюда следует, что любое различие, наблюдаемое в реальной системе, является ошибкой, которую следует исправить. Агент с доступом к репозиторию и предоставленным ресурсам может принять меры для исправления текущего состояния, если оно больше не соответствует вашим объявлениям.

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

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

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

Проблемы с GitOps

Отсутствие зрелости — самое большое препятствие для принятия GitOps. Термин остается непрозрачным для операционных групп, которые могут быть относительно неопытными в рабочих процессах с контролем версий.

Многие инфраструктурные команды привыкнут к методам работы, которые они отточили за последние пару десятилетий. Они подключаются по SSH к серверам, вносят свои изменения и документируют их в централизованно поддерживаемой вики. Это неконтролируемо, но просто и работает.

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

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

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

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

Краткое содержание

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

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

Тем не менее, во многих случаях GitOps по-прежнему сложно реализовать. Для этого требуется организационная поддержка, принятие некоторых неотъемлемых недостатков и обязательство решать технические проблемы, которые вы не всегда можете предвидеть. Организации, полностью использующие GitOps, могут ожидать большей согласованности и стандартизации. Но для многих других предоставляемые преимущества еще не являются достаточным стимулом, чтобы отказаться от команд CLI в терминале системного администратора.