Методология GitOps (способ реализации непрерывного развертывания для нативных облачных приложений) привлекает все больше внимания разработчиков. Портал The New Stack приводит четыре основных правила, лежащих в ее основе.

В прошлом году сообщество OpenGitOps выпустило GitOps Principles 1.0. Сегодня мы видим общую поддержку GitOps и множество конкурирующих интересов в разработке движков GitOps, например, Argo и Flux (два проекта Cloud Native Computing Foundation). Но сосредоточение на принципах позволяет всем понять, что такое GitOps, и, более того, помогает определить, чем он не является.

OpenGitOps определяет GitOps как набор принципов для эксплуатации и управления программными системами, отмечает Open Source-инженер Скотт Ригби. «При использовании GitOps желаемое состояние системы или подсистемы определяется декларативно как версионные, неизменяемые данные, а конфигурация работающей системы постоянно формируется на основе этих данных, — пишет он. — Эти принципы заимствованы из современных операций с ПО, но уходят корнями в ранее существовавшие и широко принятые лучшие практики».

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

На майской конференции «cdCON + GitOpsCon» в Ванкувере принципы GitOps обсудили Скотт Ригби и Кристиан Эрнандес, старший главный менеджер по продуктам Red Hat. Вот несколько выводов из этого и других выступлений на конференции.

Принцип 1. Декларативность

Система, управляемая GitOps, должна иметь желаемое состояние, выраженное декларативно.

GitOps позволяет автоматизировать методы обеспечения безопасности, заявил Ив Бен Эзра, инженер-программист из The New York Times. DevOps поощряет сотрудничество, что означает включение безопасности в каждый этап жизненного цикла разработки ПО.

Сравнение с практиками безопасности перекликается со вторым принципом GitOps.

Принцип 2. Версионность и неизменяемость

Желаемое состояние хранится таким образом, что обеспечивается неизменяемость, версионность и полная история версий.

Общая точка зрения: откат должен быть простым.

«В GitOps вы идете дальше, предоставляя аудируемый след всех изменений в инфраструктуре и приложениях», — сказал Бен Эзра.

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

«Хотя автоматизация является важной частью DevOps, это далеко не единственная методология, которая также требует межфункционального сотрудничества, разрушения изолированности и обмена знаниями в рамках организации, — сказал Бен Эзра. — GitOps основывается на этих принципах использования автоматизации и инфраструктуры как кода (IaC) для уменьшения дрейфа конфигурации и обеспечения единого источника правды для всей команды или организации».

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

Принцип 3. Автоматическое извлечение

Автоматизация ПО автоматически извлекает декларацию состояния из источника.

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

«Таким образом, Flux — это набор инструментов непрерывной доставки, которые ориентированы на безопасность, скорость и надежность. И они сосредоточены на автоматизации, — сказала Приянка Пинки Рави, инженер по опыту разработчиков компании Weaveworks. — Идея заключается в том, что у вас есть контроллеры Kubernetes, которые вы устанавливаете на свой кластер, и они запускаются в цикле согласования, который является просто интервалом, который вы задаете. И каждый раз, когда этот цикл выполняется, контроллер источника будет заходить и брать данные из любого указанного вами источника, например, из git-репозитория, домашнего или репо-образа, реестра образов, реестра OCI. Он извлекает манифесты, которые он там находит, а затем фактически применяет их на вашем кластере».

Принцип 4. Непрерывное согласование

Программные агенты постоянно наблюдают за фактическим состоянием системы и пытаются применить желаемое состояние.

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