Что такое GitOps? Это техническое введение, которое вы так долго искали

    0
    138


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

    Подход основан на идее конфигурации как кода: сделать все состояния конфигурации декларативными (например, указанными в Helm Charts и Terraform Templates); сохранение этих файлов в репозитории кода (например, GitHub); а затем рассматривать это репозиторий как единственный источник правды для создания и развертывания облачной системы. Неважно, исправляете ли вы файл Python или обновляете файл конфигурации, репо запускает полностью автоматический конвейер CI / CD.

    Схема типичного конвейера CI / CD

    Схема типичного конвейера непрерывной интеграции / непрерывного развертывания

    Создав собственные облачные системы с использованием этой модели (например, см. Aether, пограничное облако с поддержкой 5G), сила этой модели GitOps очевидна – она ​​обеспечивает простой подход к сложной проблеме управления состоянием конфигурации. Но, как и в любом, казалось бы, простом решении, это еще не все. Как отмечали другие, GitOps – не серебряная пуля.

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

    Первое соображение заключается в том, что мы должны признать разницу между людьми, которые разрабатывают программное обеспечение, и людьми, которые создают и эксплуатируют системы с использованием этого программного обеспечения. DevOps (в его простейшей формулировке) подразумевает, что не должно быть никаких различий. На практике разработчики часто далеки от операторов, или, что более важно, они далеки от проектных решений о том, как именно другие в конечном итоге будут использовать их программное обеспечение. Например, программное обеспечение обычно реализуется с учетом определенного набора вариантов использования, но позже оно интегрируется с другим программным обеспечением для создания совершенно новых облачных приложений, которые имеют свой собственный набор абстракций и функций и, соответственно, свой собственный набор состояний конфигурации. . (Это верно для Aether, где программно-определяемое мобильное ядро ​​изначально было реализовано для использования в глобальных сотовых сетях, но теперь его перепрофилируют для поддержки частных сетей 4G / 5G на предприятиях.) ВНИМАНИЕ !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

    Хотя это правда, что таким состоянием можно управлять в собственном репозитории Git, идея управления конфигурацией с помощью запроса на вытягивание слишком упрощена. Существуют переменные как низкого уровня (ориентированные на реализацию), так и переменные высокого уровня (ориентированные на приложение); другими словами, один или несколько уровней абстракции обычно работают поверх базового программного обеспечения. В пределе это может быть даже конечный пользователь (например, корпоративный пользователь в Aether), который хочет изменить это состояние, что подразумевает, что детальный контроль доступа, вероятно, является требованием. Ничто из этого не дисквалифицирует GitOps как способ управления таким состоянием, но повышает вероятность того, что не все состояния созданы равными – что существует ряд переменных состояния конфигурации, к которым в разное время обращаются разные люди с разными наборами навыков, и самое главное, нужны разные уровни привилегий.

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

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

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

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

    Состояние выполнения и состояние конфигурации

    Состояние конфигурации достаточно четко определено, но что мы подразумеваем под состоянием выполнения? В целом состояние выполнения более динамично. Если мы возьмем пример Kubernetes, конфигурация объявлена ​​в файле YAML, но состояние выполнения обрабатывается контроллерами, которые должны быстро реагировать на такие события, как сбой модуля. Никто не думает, что запуск нового модуля после сбоя будет обрабатываться с помощью запроса на вытягивание GitOps; но файл YAML, в котором указывается, сколько модулей должно быть запущено, является примером состояния конфигурации, которое хорошо вписывается в структуру GitOps. В этом примере различие между конфигурацией и состоянием выполнения довольно очевидно, но на практике это может быть больше континуумом.

    Поддержание состояния выполнения требует соответствующего механизма управления (как в предыдущем примере). Мы создаем такой механизм управления для Aether (описанный здесь), и, не вдаваясь в подробности, основная идея заключается в использовании микросервиса настройки сетевых устройств, перенаправленного на виртуальные устройства (также известные как программные сервисы). У таких механизмов есть несколько хороших свойств: (1) они используют YANG в качестве языка декларативной спецификации и поэтому поставляются с богатым набором инструментов для определения и управления моделями данных; (2) они поддерживают управление версиями, поэтому изменения состояния можно откатить вперед и назад; (3) они не зависят от того, как данные становятся постоянными, но обычно используются в паре с облачным хранилищем ключей / значений; и (4) они поддерживают управление доступом на основе ролей (RBAC), поэтому разные участники могут иметь различную видимость и контроль над параметрами управления / конфигурации.

    Помимо того, что API-интерфейс управления, который может быть автоматически сгенерирован из модели данных YANG, был разработан для управления более динамичным состоянием управления во время выполнения, он имеет два преимущества в нашей среде: (1) RBAC помогает поддерживать принцип наименьших привилегий и (2) он дает возможность реализовать раннюю проверку параметров и проверки безопасности (тем самым выявляя ошибки ближе к пользователю и генерируя более значимые сообщения об ошибках). Эффективные модели данных оказались бесценными, и к этой теме мы еще вернемся.

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

    Предыдущая статьяКак получить идеальную концовку в Mass Effect 3
    Следующая статьяВсе скрытые изменения в Android 11, которые мы узнали из исходного кода
    Виктор Попанов
    Эксперт тестовой лаборатории. Первый джойстик держал в руках в возрасте 3 лет. Первый компьютер, на котором „работал” был с процессором Intel i386DX-266. Тестирует оборудование для издания ITBusiness. Будь то анализ новейших гаджетов или устранение сложных неполадок, этот автор всегда готов к выполнению поставленной задачи. Его страсть к технологиям и приверженность качеству делают его бесценным помощником в любой команде.