Заявка на услуги DST
Наш специалист свяжется с вами, обсудит оптимальную стратегию сотрудничества,
поможет сформировать бизнес требования и рассчитает стоимость услуг.
Исследуйте синергию GitOps и Kubernetes в современной разработке программного обеспечения. Узнайте от разработчиков компании DST Global их значение, принципы работы и унифицированные возможности для обеспечения гибкости и эффективности.
Достижение гибкости, масштабируемости, эффективности и безопасности имеет первостепенное значение в современной разработке программного обеспечения. Хотя для достижения вышеупомянутых целей требуется несколько культурных методологий, инструментов и подходов, GitOps, Kubernetes и Platform Engineering являются краеугольными камнями этой трансформации. В этом подробном руководстве вы узнаете, что такое GitOps, Kubernetes и Platform Engineering, раскроете их значение, принципы работы и то, что делает это трио движущей силой современного DevOps.
Революция в управлении инфраструктурой с помощью GitOps
Понимание GitOps
GitOps — это методология, основанная на использовании систем контроля версий, при этом Git является основным выбором в качестве единственного источника достоверной информации как для кода приложения, так и для конфигураций инфраструктуры. GitOps поощряет декларацию желаемого состояния приложений и инфраструктуры в репозиториях Git. Такой подход позволяет легко отслеживать изменения, вести историю версий и способствовать беспрепятственному сотрудничеству между членами команды. Кроме того, использование запросов на включение и проверок кода в GitOps обеспечивает высокое качество и безопасность кода. Всякий раз, когда в репозитории Git вносятся изменения, автоматизированные процессы обеспечивают соответствие состояния системы заявленной конфигурации.
Как работает GitOps
Чтобы начать путешествие по GitOps, вам следует выполнить ряд фундаментальных шагов:
-Настройка репозитория Git. Начните с создания репозитория Git для размещения кода вашего приложения и файлов конфигурации. Этот репозиторий служит ядром вашего рабочего процесса GitOps.
- Предоставление кластера Kubernetes. Создайте кластер Kubernetes для наблюдения за вашей инфраструктурой. Kubernetes обеспечивает оркестрацию, необходимую для эффективного развертывания и масштабирования приложений.
- Использование декларативных манифестов. Определите манифесты Kubernetes, описывающие желаемое состояние вашей инфраструктуры и приложений. Эти декларативные конфигурации служат основой для вашей среды.
- Автоматизация в действии. Внесите изменения в Git и станьте свидетелем того, как автоматизация идет полным ходом.
Лучшее управление контейнерами с Kubernetes
Понимание Кубернетеса
Kubernetes, часто сокращенно K8s, представляет собой платформу оркестрации контейнеров, которая произвела революцию в развертывании и управлении контейнерными приложениями. Kubernetes превосходно справляется с оркестровкой контейнеров, автоматизацией развертывания, масштабированием приложений и управлением их жизненным циклом. Он обеспечивает надежную и масштабируемую основу для современных облачных приложений.
Ключевые особенности Kubernetes включают в себя:
- Оркестрация контейнеров. Kubernetes эффективно управляет развертыванием, масштабированием и работой контейнеров приложений.
- Обнаружение служб и балансировка нагрузки: предлагает встроенные решения для маршрутизации трафика в контейнеры, обеспечивая высокую доступность.
- Автоматическое масштабирование: Kubernetes может динамически регулировать количество запущенных контейнеров в зависимости от требований к трафику и ресурсам.
- Декларативная конфигурация. Как и GitOps, Kubernetes работает на основе декларативной модели, в которой вы указываете желаемое состояние, а Kubernetes согласовывает с ним фактическое состояние.
- Устойчивость и аварийное восстановление. Kubernetes также играет решающую роль в обеспечении отказоустойчивости приложений и поддерживает стратегии аварийного восстановления.
Как работает Кубернетес
Чтобы использовать возможности Kubernetes, выполните следующие действия:
- Настройка кластера Kubernetes. Как и в случае с GitOps, вам потребуется кластер Kubernetes для наблюдения за вашей инфраструктурой.
- Использование декларативных манифестов: Kubernetes оперирует концепцией желаемого состояния. Определите желаемую инфраструктуру и состояние приложения с помощью декларативных манифестов.
- Контейнерное развертывание: используйте контейнеры для упаковки и развертывания приложений. Контейнеры гарантируют согласованность и мобильность.
- Мониторинг и управление: используйте инструменты Kubernetes для мониторинга и управления вашими приложениями. Легко доступны такие функции, как балансировка нагрузки, автоматическое масштабирование и самовосстановление.
Платформенная инженерия: путь к эффективности
Проектирование платформы вращается вокруг создания модели платформы, которая обеспечивает быструю и надежную разработку приложений.
Возникшая в результате эволюции DevOps и развития облачных технологий, проектирование платформ направлено на то, чтобы не дать командам заново изобрести велосипед, решая общие проблемы и создавая хорошо проложенную дорогу. Основное внимание уделяется предоставлению разработчикам подходящих инструментов и среды для облегчения их работы, тем самым уменьшая трение и повышая эффективность.
Роль разработки платформ
Разработка платформ включает в себя проектирование, создание и обслуживание платформ, поддерживающих разработку и доставку приложений. Эти платформы обычно включают в себя инфраструктуру, услуги и инструменты, которые позволяют командам разработчиков эффективно создавать и развертывать программное обеспечение. Инженеры платформ играют ключевую роль в обеспечении оптимизации базовой инфраструктуры и инструментов для разработки и развертывания.
В важнейшие обязанности инженеров платформы входят:
- Управление инфраструктурой. Инженеры платформы контролируют управление инфраструктурой, будь то локально или в облаке. Сюда входит подготовка, масштабирование и обслуживание серверов, баз данных и сетевых компонентов.
- Автоматизация: они автоматизируют процессы, устраняя ручные задачи и повышая эффективность. Сюда входит создание конвейеров CI/CD , настройка мониторинга и настройка механизмов аварийного восстановления.
- Безопасность и соответствие требованиям. Инженеры платформы реализуют меры безопасности и гарантируют, что платформа соответствует соответствующим нормам и отраслевым стандартам.
- Сотрудничество и непрерывное обучение. Инженеры платформ также тесно сотрудничают с командами разработчиков и стремятся постоянно учиться, чтобы идти в ногу с быстро развивающимися технологиями.
Почему платформенная инженерия?
Проектирование платформ дает несколько преимуществ:
- Повышенная скорость разработки. Это значительно повышает скорость разработки, одновременно повышая надежность приложений и инфраструктуры.
- Уменьшение трения: проектирование платформ снижает трение, предоставляя разработчикам необходимые инструменты и среду.
- Повышение эффективности и экономичности. Решая общие проблемы, разработка платформ повышает эффективность, оптимизирует разработку и часто приводит к лучшему использованию ресурсов и экономии затрат.
Как реализовать проектирование платформы
Чтобы эффективно использовать Platform Engineering, выполните следующие действия:
- Создайте команду разработчиков платформы. Как и в случае с GitOps и Kubernetes, вам потребуется выделенная команда для управления вашей инфраструктурой и приложениями.
- Определите свою стратегию: создайте четкую стратегию, описывающую желаемое состояние вашей инфраструктуры и приложений.
- Предоставьте подходящие инструменты. Обеспечьте разработчиков инструментами и средой, необходимыми для достижения успеха в их работе.
- Эффективность и сотрудничество. Сосредоточьтесь на уменьшении разногласий, повышении эффективности и развитии сотрудничества путем решения общих проблем.
- Непрерывная обратная связь и итерация. Подчеркните важность непрерывной обратной связи и гибкой итерации в вашей стратегии разработки платформы.
Сила GitOps, Kubernetes и разработки платформ в SDLC
Когда GitOps, Kubernetes и Platform Engineering объединяются, они образуют мощную комбинацию с несколькими ключевыми преимуществами:
- Декларативная инфраструктура : GitOps и Kubernetes полагаются на декларативный подход. С помощью GitOps вы объявляете желаемое состояние в репозиториях Git, а Kubernetes использует файлы конфигурации YAML для указания желаемой формы и инфраструктуры приложения. Такая синергия гарантирует, что ваша инфраструктура и приложения четко определены и автоматически управляются.
- Автоматизация и самовосстановление . Автоматизация лежит в основе GitOps и Kubernetes. Инженеры платформ могут проектировать конвейеры CI/CD, которые автоматически развертывают и обновляют приложения. Kubernetes гарантирует, что желаемое состояние приложения всегда поддерживается. В сочетании эти технологии приводят к большей автоматизации и возможности самовосстановления, уменьшая необходимость ручного вмешательства и сводя к минимуму время простоя.
- Масштабируемость и переносимость . Kubernetes превосходно масштабирует приложения в большую или меньшую сторону в зависимости от требований к трафику и ресурсам. Эта присущая ему масштабируемость в сочетании с практиками GitOps позволяет легко масштабировать как инфраструктуру, так и приложения. Вы сможете справляться с повышенными нагрузками без значительных сбоев и сложных ручных регулировок.
- Согласованность и контроль версий . GitOps обеспечивает использование контроля версий как для кода, так и для инфраструктуры. Это обеспечивает прозрачную и отслеживаемую историю изменений, что упрощает аудит и откат при необходимости. Благодаря своей декларативной модели конфигурации Kubernetes гарантирует, что желаемое состояние последовательно применяется во всех средах.
- Сотрудничество и прозрачность : GitOps способствует прозрачности и сотрудничеству через репозитории Git. Члены команды могут работать вместе, просматривать изменения и отслеживать эволюцию конфигурации инфраструктуры и приложений. Kubernetes позволяет командам последовательно работать с контейнерами, способствуя сотрудничеству и оптимизируя развертывание.
- Безопасность и соответствие требованиям . Инженеры платформы могут устанавливать меры безопасности и соответствия требованиям в среде Kubernetes. GitOps с его журналом аудита и точным контролем версий поддерживает эти усилия. Вместе они гарантируют, что инфраструктура и приложения развертываются безопасно и соответствуют необходимым нормам.
Заключение: что лучше для вашего бизнеса?
В заключение разработчики компании DST Global отмечают, что GitOps, Kubernetes и разработка платформ являются движущими силами современной разработки программного обеспечения. Эти принципы повышают скорость разработки, оптимизируют рабочие процессы и повышают эффективность и надежность. Приняв эти концепции, разработчики, менеджеры и владельцы проектов смогут беспрепятственно ориентироваться в тонкостях современных DevOps и облачных технологий, раскрывая весь потенциал своих усилий по разработке программного обеспечения.
Наш специалист свяжется с вами, обсудит оптимальную стратегию сотрудничества,
поможет сформировать бизнес требования и рассчитает стоимость услуг.
Ижевск, ул. Воткинское шоссе, д. 170 Е, Технопарк Нобель, офис 1117
Задать вопрос по почте
Команда Боба развертывает production-системы в облаке. Их основные приложения работают на GKE, пользуясь преимуществами Kubernetes в Google Cloud. Кроме того, они используют в работе различные инструменты для работы с данными и аналитики.
Family Insurance не собиралась использовать контейнеры, но заразилась энтузиазмом вокруг Docker. Вскоре специалисты компании обнаружили, что GKE позволяет развертывать кластеры для тестирования новых функций легко и непринужденно. Были добавлены Jenkins для CI и Quay для организации реестра контейнеров, написаны скрипты для Jenkins, которые push'или новые контейнеры и конфигурации в GKE.
Прошло некоторое время. Алиса и Боб разочаровались в производительности выбранного подхода и его влиянии на бизнес. Внедрение контейнеров не повысило производительность настолько, насколько надеялась команда. Иногда deployment'ы ломались, и было неясно, виноваты ли в этом изменения кода. Также оказалось тяжело отслеживать изменения конфигов. Часто приходилось создавать новый кластер и перемещать в него приложения, поскольку так было проще всего ликвидировать тот бардак, в который превратилась система. Алиса боялась, что ситуация ухудшится по мере развития приложения (кроме того, назревал новый проект на основе машинного обучения). Боб автоматизировал большую часть работы и не понимал, почему пайплайн по-прежнему неустойчив, плохо масштабируется и периодически требует ручного вмешательства?
Затем они узнали о GitOps. Это решение оказалось именно тем, что им было нужно для уверенного движения вперед.
Алиса и Боб уже не один год слышали о рабочих процессах на основе Git, DevOps и infrastructure as code. Уникальность GitOps в том, что он привносит ряд лучших практик — категоричных и нормативных — по реализации этих идей в контексте Kubernetes. Эта тема неоднократно поднималась, в том числе и в блоге Weaveworks.
Family Insurance решает внедрить GitOps. Теперь у компании есть автоматизированная модель эксплуатации, совместимая с Kubernetes и сочетающая скорость со стабильностью, поскольку они:
— обнаружили, что у команды вдвое выросла производительность и никто при этом не сходит с ума;
— перестали обслуживать скрипты. Вместо этого теперь они могут концентрироваться на новых функциях и совершенствовать инженерные методы — например, внедрить канареечные выкаты и улучшить тестирование;
— усовершенствовали процесс развертывания — теперь он редко ломается;
— получили возможность восстанавливать deployment'ы после частичных сбоев без ручного вмешательства;
— приобрели большую уверенность в системах поставки. Алиса и Боб обнаружили, что можно разделить команду на группы, занимающиеся микросервисами и работающие параллельно;
— могут вносить по 30-50 изменений в проект каждый день усилиями каждой группы и пробовать новые техники;
— легко привлекают к проекту новых разработчиков, которые имеют возможность накатывать обновления на production с помощью pull request'ов уже через несколько часов;
— легко проходят аудит в рамках SOC2 (на соответствие поставщиков услуг требованиям по безопасному управлению данных; подробнее читайте, например, здесь — прим. перев.).
Что произошло?
GitOps — это две вещи:
1. Модель эксплуатации для Kubernetes и cloud native. Она предоставляет набор лучших практик для развертывания, управления и мониторинга собранных в контейнеры кластеров и приложений. Элегантное определение в виде одного слайда от Luis Faceira:
2. Путь к созданию ориентированного на разработчиков окружения для управления приложениями. Мы применяем рабочий процесс Git как к эксплуатации, так и к разработке. Обратите внимание, что речь идет не просто о Git push, а об организации всего набора инструментов CI/CD и UI/UX.
Пара слов о Git
Если вы не знакомы с системами контроля версий и основанном на Git рабочим процессом, мы настоятельно рекомендуем изучить их. Поначалу работа с ветвями и pull request'ами может показаться черной магией, но плюсы стоят затраченных усилий. Вот хорошая статья для начала.
Как работает Kubernetes
В нашей истории Алиса и Боб обратились к GitOps, некоторое время проработав с Kubernetes. Действительно, GitOps тесно связан с Kubernetes — это модель эксплуатации для инфраструктуры и приложений, основанных на Kubernetes.
Что Kubernetes дает пользователям?
Вот некоторые основные возможности:
— В модели Kubernetes все можно описывать в декларативной форме.
— API-сервер Kubernetes принимает такую декларацию как вводные данные, а затем постоянно пытается привести кластер в состояние, описанное в декларации.
— Декларации достаточны для описания и управления большим разнообразием рабочих нагрузок — «приложений».
— В результате, внесение изменений в приложение и кластер происходит из-за:
изменений в образах контейнеров;
изменений в декларативной спецификации;
ошибок в среде — например, падений контейнеров.
Прекрасные способности Kubernetes по конвергенции
Когда администратор вносит изменения в конфигурацию, оркестратор Kubernetes будет применять их к кластеру до тех пор, пока его состояние не приблизится к новой конфигурации. Эта модель работает для любого ресурса Kubernetes и расширяется с помощью Custom Resource Definitions (CRDs). Поэтому deployment'ы Kubernetes обладают следующими чудесными свойствами:
— Автоматизация: обновления Kubernetes предоставляют механизм для автоматизации процесса применения изменений корректно и своевременно.
— Конвергенция: Kubernetes будет продолжать попытки обновлений до достижения успеха.
— Идемпотентность: повторные применения конвергенции приводят к тому же результату.
— Детерминизм: при достаточности ресурсов состояние обновленного кластера зависит только от желаемого состояния.
Как работает GitOps
Мы достаточно узнали о Kubernetes, чтобы объяснить принципы работы GitOps.
Давайте вернемся к командам Family Insurance, связанным с микросервисами. Чем им обычно приходится заниматься? Посмотрите на перечень ниже (если какие-то пункты в нем покажутся странными или незнакомыми — пожалуйста, повремените с критикой и оставайтесь с нами). Это всего лишь примеры рабочих процессов на основе Jenkins. Существует и множество других процессов при работе с другими инструментами.
Главное — мы видим, что каждое обновление заканчивается внесением изменений в конфигурационные файлы и репозитории Git. Эти изменения в Git приводят к тому, что «оператор GitOps» обновляет кластер:
1. Рабочий процесс: «Сборка Jenkins — ветка master».
Список задач:
Jenkins push'ит тегированные образы в Quay;
Jenkins push'ит конфиг и Helm-чарты в бакет master-хранилища;
Облачная функция копирует конфиг и чарты из бакета master-хранилища в Git-репозиторий master;
Оператор GitOps обновляет кластер.
2. Сборка Jenkins — ветка release или hotfix:
Jenkins push'ит нетегированные образы в Quay;
Jenkins push'ит конфиг и Helm-чарты в бакет staging-хранилища;
Облачная функция копирует конфиг и чарты из бакета staging-хранилища в Git-репозиторий staging;
Оператор GitOps обновляет кластер.
3. Сборка Jenkins — ветка develop или feature:
Jenkins push'ит нетегированные образы в Quay;
Jenkins push'ит конфиг и Helm-чарты в бакет develop-хранилища;
Облачная функция копирует конфиг и чарты из бакета develop-хранилища в Git-репозиторий develop;
Оператор GitOps обновляет кластер.
4. Добавление нового клиента:
Менеджер или администратор (LCM/ops) вызывает Gradle для первоначального развертывания и настройки сетевых балансировщиков нагрузки (NLB);
LCM/ops коммитит новый конфиг для подготовки deployment'а к обновлениям;
Оператор GitOps обновляет кластер.
Краткое описание GitOps
Опишите желаемое состояние всей системы, используя декларативные спецификации для каждого окружения (в нашей истории команда Боба определяет всю конфигурацию системы в Git).
Git-репозиторий является единственным источником истины в отношении желаемого состояния всей системы.
Все изменения в желаемое состояние осуществляются путем коммитов в Git.
Все желаемые параметры кластера также наблюдаемы в самом кластере. Таким образом мы можем определить, совпадают (конвергируют, converge) или отличаются (дивергируют, diverge) желаемое и наблюдаемое состояния.
Если желаемое и наблюдаемое состояния отличаются, то:
Существует механизм конвергенции, который рано или поздно автоматически синхронизирует целевое и наблюдаемое состояния. Внутри кластера этим занимается Kubernetes.
Процесс запускается незамедлительно с оповещением «change committed».
Через некоторый настраиваемый промежуток времени может быть послано оповещение «diff», если состояния отличаются.
Таким образом, все коммиты в Git вызывают проверяемые и идемпотентные обновления в кластере.
Откат — это конвергенция к ранее желаемому состоянию.
Конвергенция окончательна. О ее наступлении свидетельствуют:
Отсутствие оповещений «diff» в течение определенного промежутка времени.
Оповещение «converged» (например, webhook, событие Git writeback).
Что такое дивергенция?
Повторим еще раз: все желаемые свойства кластера должны быть наблюдаемы в самом кластере.
Несколько примеров дивергенции:
Изменение в файле конфигурации из-за слияния веток в Git.
Изменение в файле конфигурации из-за коммита в Git, сделанного GUI-клиентом.
Множественные изменения в желаемом состоянии из-за PR в Git с последующей сборкой образа контейнера и изменениями конфига.
Изменение состояния кластера из-за ошибки, конфликта ресурсов, приводящего к «плохому поведению», или просто случайного отклонения от оригинального состояния.
Что представляет собой механизм конвергенции?
Несколько примеров:
Для контейнеров и кластеров механизм конвергенции предоставляет Kubernetes.
Тот же механизм можно использовать для управления приложениями и конструкциями на основе Kubernetes (например, Istio и Kubeflow).
Механизм для управления рабочим взаимодействием между Kubernetes, репозиториями образов и Git'ом предоставляет GitOps-оператор Weave Flux, являющийся частью Weave Cloud.
Для базовых машин механизм конвергенции должен быть декларативным и автономным. По своему опыту можем сказать, что Terraform ближе всего к этому определению, однако все же требует контроля со стороны человека. В этом смысле GitOps расширяет традиции Infrastructure as Code.
GitOps объединяет Git с прекрасным механизмом конвергенции Kubernetes, предлагая модель для эксплуатации.
GitOps позволяет нам заявить: автоматизации и контролю поддаются только те системы, которые можно описывать и наблюдать.
GitOps предназначен для всего cloud native-стека (например, Terraform и т.п.)
GitOps — это не только Kubernetes. Мы хотим, чтобы вся система управлялась декларативно и использовала конвергенцию. Под всей системой мы подразумеваем совокупность сред, работающих с Kubernetes — например, «dev cluster 1», «production» и т. п. В каждую среду входят машины, кластеры, приложения, а также интерфейсы для внешних сервисов, обеспечивающих данные, мониторинг и т. п.
Заметьте, насколько в данном случае Terraform важен для проблемы bootstrapping'а. Kubernetes должен быть где-то развёрнут, и использование Terraform означает, что мы можем применить те же самые рабочие процессы GitOps для создания управляющего слоя, лежащего в основе Kubernetes и приложений. Это полезная лучшая практика.
Большое внимание уделяется применению концепций GitOps к слоям над Kubernetes. На данный момент имеются решения GitOps-типа для Istio, Helm, Ksonnet, OpenFaaS и Kubeflow, а также например, для Pulumi, что создают слой для разработки приложений под cloud native.
Допустим, у вас приложение, состоящее из двух бэков + базы.
И у вас Docker и Helm Chart лежат прямо с кодом, который они обсуждивают — у каждого из двух бэков свой набор.
Вы сделали изменение в брэнче одного из бэков. Он улетел в ориджин. Оттуда хуком пнулся Дженкинс, тот увидел новый брэнч, сгенерировал под него джобу (multibranch) и запустил pipeline. Один из шагов — деплоймент.
Допустим, Helm не используется. Деплоймент пойдет напрямую через apply deployment.yml в k8s. В таком случае получается, что деплоймент только одного бэка. То есть у вас прилетит бэк1 новый, а бэк2 будет стоять старый. Вместе они работать не рассчитаны, так как находятся на разных версиях.
А теперь тот же сценарий, но с Helm.
Вы ставите бэк1 через helm upgrade. Он по зависимостям вытягивает правильную версию базы (да может даже у вас там прибавилось еще других зависимостей даже) и правильную версию парного бэка2.
Другими словами, Helm дает вам консистентность на уровне всего приложения. И Git это никак не отменяет. Они даже никак не связаны. Вы, конечно, могли изначально в Jenkinfile захардкодить это поведение, но боюсь, это не так элегентно и гибко.
Как говорилось, GitOps — это две вещи:
1. Модель эксплуатации для Kubernetes и cloud native, описанная выше.
2. Путь к организации ориентированной на разработчиков среды для управления приложениями.
Для многих GitOps — это прежде всего рабочий процесс на основе Git push'ей. Нам он тоже нравится. Но это не все: давайте теперь посмотрим на CI/CD-пайплайны.
GitOps обеспечивает непрерывное развертывание (CD) под Kubernetes
GitOps предлагает механизм непрерывного развертывания, устраняющий необходимость в отдельных «системах управления развертываниями». Всю работу за вас выполняет Kubernetes.
— Обновление приложения требует обновления в Git'е. Это транзакционное обновление до желаемого состояния. «Развертывание» затем осуществляется внутри кластера самим Kubernetes на основе обновленного описания.
— Из-за специфики работы Kubernetes эти обновления конвергентны. Так обеспечивается механизм для непрерывного развертывания, в котором все обновления атомарны.
— Примечание: Weave Cloud предлагает GitOps-оператор, интегрирующий Git и Kubernetes и позволяющий выполнять CD путем согласования желаемого и текущего состояния кластера.
Без kubectl и скриптов
Следует избегать использования Kubectl для обновления кластера, а в особенности — скриптов для группирования команд kubectl. Вместо этого, с помощью GitOps-пайплайна пользователь может обновить свой кластер Kubernetes через Git.
Преимущества включают в себя:
1. Правильность. Группу обновлений можно применить, конвергировать и наконец валидировать, что приближает нас к цели атомарного развертывания. Напротив, использование скриптов не дает никаких гарантий конвергенции (подробнее об этом ниже).
2. Безопасность. Цитируя Kelsey Hightower: «Ограничьте доступ к кластеру Kubernetes инструментам автоматизации и администраторам, в обязанности которых входит его отладка или поддержание работоспособности». См. также мою публикацию о безопасности и соответствии техническим условиям, а также статью о взломе Homebrew путем хищения учетных данных из небрежно составленного Jenkins-скрипта.
3. Пользовательский опыт. Kubectl обнажает механику объектной модели Kubernetes, которая весьма сложна. В идеале пользователи должны взаимодействовать с системой на более высоком уровне абстракции. Здесь я снова сошлюсь на Kelsey и рекомендую посмотреть такое резюме.
Разница между CI и CD
GitOps улучшает существующие CI/CD-модели.
Современный CI-сервер представляет собой инструмент для оркестрации. В частности, это инструмент для оркестрации CI-пайплайнов. Они включают в себя build, test, merge to trunk и т. д. CI-серверы автоматизируют управление сложными многошаговыми пайплайнами. Распространенный соблазн состоит в том, чтобы создать скрипт для набора обновлений Kubernetes и выполнить его в качестве элемента пайплайна для push'а изменений в кластер. Действительно, так поступают многие специалисты. Однако это неоптимально, и вот почему.
CI должна использоваться для внесения обновлений в trunk, а кластер Kubernetes должен менять себя на основе этих обновлений, чтобы управлять CD «внутренне». Мы называем это pull-моделью для CD, в отличие от CI push-модели. CD является частью runtime-оркестрации.
Почему CI-серверы не должны делать CD через прямые обновления в Kubernetes
Не используйте CI-сервер для оркестрации прямых обновлений в Kubernetes в виде набора CI-заданий. Это анти-паттерн, о котором мы уже рассказывали в своем блоге.
Давайте вернемся к Алисе и Бобу.
С какими проблемами они столкнулись? CI-сервер Боба применяет изменения к кластеру, но если в процессе он упадет, Боб не будет знать, в каком состоянии находится (или должен быть) кластер и как его исправить. То же самое справедливо и в случае успеха.
Давайте предположим, что команда Боба собрала новый образ и затем пропатчила свои deployment'ы, чтобы развернуть образ (все это из CI-пайплайна).
Если образ соберется нормально, но пайплайн упадет, команде придется выяснять:
— Развернулось ли обновление?
— Запускаем ли мы новую сборку? Приведет ли это к ненужным побочным эффектам — с возможностью получить две сборки одного и того же неизменного образа?
— Стоит ли нам дождаться очередного обновления, прежде чем запустить сборку?
— Что именно пошло не так? Какие шаги нужно повторить (и какие из них безопасно повторять)?
Организация основанного на Git'е рабочего процесса не гарантирует, что команда Боба не столкнется с этими проблемами. Они по-прежнему могут ошибиться с push'ем коммита, с тегом или каким-либо другим параметром; однако этот подход все же гораздо ближе к явному все-или-ничего.
Подытоживая, вот почему CI-серверы не должны заниматься CD:
— Скрипты обновления не всегда детерминированы; в них легко наделать ошибок.
— CI-серверы не конвергируют к декларативной модели кластера.
— Сложно гарантировать идемпотентность. Пользователи должны разбираться в глубокой семантике системы.
— Сложнее провести восстановление после частичного сбоя.
Примечание о Helm'e: если вы хотите использовать Helm, мы рекомендуем объединить его с GitOps-оператором, таким как Flux-Helm. Это поможет обеспечить конвергентность. Сам по себе Helm не является ни детерминированным, ни атомарным.
GitOps как лучший способ осуществлять Continuous Delivery для Kubernetes
Команда Алисы и Боба внедряет GitOps и обнаруживает, что стало гораздо проще работать с программными продуктами, поддерживать высокую производительность и стабильность. Давайте закончим эту статью иллюстрациями, показывающими, как выглядит их новый подход. Учтите, что мы в основном говорим о приложениях и сервисах, однако GitOps можно использовать для управления всей платформой.
Модель эксплуатации для Kubernetes
Посмотрите на следующую диаграмму. Она представляет Git и хранилище образов контейнеров как общие ресурсы для двух оркестрированных жизненных циклов:
— Пайплайна непрерывной интеграции, который считывает и записывает файлы в Git и может обновлять репозиторий контейнерных образов.
— Пайплайна Runtime GitOps, сочетающего деплой с управлением и наблюдаемостью. Он считывает и записывает файлы в Git и может загружать образы контейнеров.
1. Разделение проблем: Обратите внимание, что оба пайплайна могут обмениваться данными, только обновляя Git или репозиторий образов. Другими словами, существует сетевой экран между CI и runtime-средой. Мы называем его «брандмауэром неизменяемости» (immutability firewall), поскольку все обновления репозиториев создают новые версии. Для дополнительной информации по данной теме обратитесь к слайдам 72-87 этой презентации.
2. Можно использовать любой CI- и Git-сервер: GitOps работает с любыми компонентами. Вы можете продолжать использовать свои любимые CI- и Git-серверы, репозитории образов и наборы тестов. Почти все остальные инструменты для Continuous Delivery на рынке требуют собственного CI-/Git-сервера или хранилища образов. Это может стать ограничивающим фактором в развитии cloud native. В случае GitOps вы можете использовать привычные инструменты.
3. События как инструмент интеграции: Как только данные в Git обновляются, Weave Flux (или оператор Weave Cloud) извещает об этом runtime. Всякий раз, когда Kubernetes принимает набор изменений, Git обновляется. Это обеспечивает простую модель интеграции для организации рабочих процессов для GitOps, как показано ниже.
GitOps предоставляет весомые гарантии обновления, необходимые любому современному инструменту CI/CD:
автоматизация;
конвергенция;
идемпотентность;
детерминизм.
Это важно, поскольку он предлагает модель эксплуатации для разработчиков в области cloud native.
— Традиционные инструменты для управления и мониторинга систем связаны с командами эксплуатации, действующими в рамках runbook'а (набора рутинных процедур и операций — прим. перев.), привязанного к конкретному deployment'у.
— В управлении cloud native-системами инструментарий для наблюдения является лучшим способом оценки результатов развертываний, чтобы команда разработчиков смогла оперативно реагировать на них.
Представьте множество кластеров, разбросанных по различным облакам и множество сервисов со своими собственными командами и планами развертываний. GitOps предлагает масштабно-инвариантную модель для управления всем этим изобилием.