Поскольку будучи выдуманный в 2017 г. Гитопс возник как естественная эволюция современных практик разработки программного обеспечения, таких как DevOps, инфраструктура как код, а также CI / CD принципы, особенно для организаций, которые создают микросервисы развернуты в распределенных контейнеры и организовано Kubernetes, как это принято в наши дни.

Тем не менее, отрасли все еще предстоит преодолеть несколько серьезных культурных и технологических препятствий, чтобы позволить Gitops по-настоящему поразить широкое распространение в масштабах, которые до сих пор имеют практики Agile и DevOps.

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

Gitops расширяет DevOps прежде всего за счет лечения инфраструктура как код, так что и приложение, и его базовая инфраструктура могут рассматриваться как код и храниться в система контроля версий, скорее всего, Git, предоставляющий единый источник правды как для разработчиков, так и для операторов. Если все сделано правильно, это позволяет протолкнуть все изменения через декларативный код с набором автоматических шагов, которые исправляют любые отклонения от желаемого состояния.

Хотя в теории все это звучит великолепно, среди предприятий, которые, как известно, балуются практикой Gitops, – таких как Peloton, Volvo, Ticketmaster и Just Eat Takeaway.com – ни один не хотел разговаривать с InfoWorld на данном этапе. «Я не разговаривал ни с одной организацией, которая внедряет инициативу Gitops, и большинство организаций, с которыми я разговариваю, вероятно, даже не слышали об этом», – сказал Джим Мерсер, директор по исследованиям в IDC по разработке решений DevOps.

«[Gitops] все еще находится на ранних стадиях зрелости », – сказала Мукулика Капас, директор по управлению продуктами внутренняя платформа разработчика в финтех-фирме Intuit, которая стала одним из первых разработчиков Gitops после того, как в 2018 году приобрела Applatix, создателя компакт-дисков Argo.

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

«Умные организации задаются вопросом, как сделать так, чтобы разработчики не подключались по SSH к серверам, не создавали экземпляры и не вносили изменения неконтролируемым образом. Это проблема, которую решает Gitops », – сказал Джеймс Губернатор, соучредитель аналитической компании RedMonk, ориентированной на разработчиков.

Тем не менее, несмотря на свои обещания, Gitops по сей день остается на обочине. Вот четыре причины, по которым практики Gitops еще не получили широкого распространения, и некоторые усилия, предпринимаемые для того, чтобы это изменить.

В Gitops отсутствуют устоявшиеся шаблоны

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

«Самая большая проблема с Gitops прямо сейчас заключается в том, что нет установленных шаблонов, которые помогут вам в вашем выборе», – написал Ян Миелл, консультант по облачным технологиям в Container Solutions, в своем докладе 2020 года. Сообщение блога по теме. «Пока у нас не будут настоящие стандарты в этой области, создание правильной архитектуры Gitops всегда будет искусством, а не наукой».

А Рабочая группа Gitops была создана как проект открытого сообщества CNCF в ноябре 2020 года, чтобы начать решать некоторые из этих проблем и облегчить кривую принятия для новичков. Группе, возглавляемой поставщиками Amazon, Codefresh, GitHub и Weaveworks, изначально была поставлена ​​задача четко определить основные принципы Gitops, не зависящие от поставщика, и растущее распространение этой практики.

«Прямо сейчас мы находимся на этапе доступности, когда мы выносим племенные знания в открытый доступ и их легко использовать», – сказал Дэн Гарфилд, директор по открытым исходным кодом Codefresh и соучредитель рабочей группы Gitops. интервью с InfoWorld. «Мы формализуем принципы Gitops, чтобы они были более зрелыми, и полагаемся на специалистов-практиков, которые выявляют то, чего мы еще не видели, сглаживают острые углы и собирают шаблоны сообщества и эталонные реализации, на которые люди могут обратить внимание».

Гарфилд сказал, что рабочая группа получила «огромную поддержку сообщества», когда была создана, и 80 представителей компании позвонили по первому звонку.

Инструменты Gitops нуждаются в зрелости

В типичном процессе развертывания Gitops разработчик делает запрос на включение новой функции, чаще всего через Git (отсюда и название), который после утверждения запускает конвейер CI / CD, тестирует код и развертывает его в реестре. Затем программный агент, обычно Argo или Flux, автоматически определяет, соответствует ли состояние кластера конфигурации в Git, извлекает изменения и развертывает новую функцию.

«Несколько лет назад люди создали то, что очень похоже на операторы Git, чтобы брать и синхронизировать инфраструктуру как код, используя хранилище с контролем версий. Проблема не в том, что он соответствовал определениям [of Gitops], [but that] это было мрачное искусство с командой, использующей нестандартные инструменты, и это было сложно. Теперь, используя облачные инструменты, такие как Argo или Flux, мы действительно можем упростить процесс », – сказал Гарфилд.

Хотя в последние годы эти инструменты появились семимильными шагами, все еще существуют пробелы, которые сообществу необходимо заполнить, чтобы упростить внедрение. «Несмотря на то, что методология Gitops имеет некоторые интересные характеристики и преимущества, текущие инструменты Gitops сосредоточены только на развертывании приложения и ни на чем другом», – написал Костис Капелонис, защитник разработчиков Codefresh в сообщении в блоге 2020 года, озаглавленном «Боль Gitops 1.0. »

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

По мнению Кристофера Кондо, главного аналитика Forrester, следующий этап инструментов Gitops, вероятно, будет встроен в облачные платформы, на которых разработчики уже работают, для «чего-то вроде Действия GitHub который интегрируется напрямую с Terraform, чтобы разработчикам было проще создавать инфраструктуру как код, поэтому они делают Gitops, даже не осознавая, что они это делают. Именно тогда он станет мейнстримом », – сказал он InfoWorld.

Масштабирование Gitops создает серьезные проблемы

Gitops по-прежнему имеет некоторые четко определенные ограничения при масштабной работе, писал Адам Шандор, облачный архитектор в компании по оказанию профессиональных услуг Container Solutions, в 2020 году. Сообщение блога. Эти ограничения включают проблемы аудита, исправления и наблюдения при работе в нескольких репозиториях Git.

«Для небольших команд из 10–15 экспертов Gitops – лучшее, что вы можете сделать», – сказал Каспар фон Грюнберг, генеральный директор Humanitec, стартапа, который помогает организациям создавать собственные внутренние платформы для разработчиков. «Это замечательно на определенном уровне, но проблема, которую я начал замечать в более крупных организациях, заключается в том, что масштабная реализация Gitops крайне разочаровывает».

Возьмите процесс продвижения изменений в различных средах. «Это, вероятно, одна из самых известных проблем с Gitops и одна из первых обсуждаемых тем, когда речь заходит о том, как Gitops может работать в крупных организациях», – говорит Капелонис. написал.

«Каждый раз, когда кто-то заявляет, что внедрение Gitops – это простой процесс, я всегда спрашиваю, как продвижение между различными средами работает в их случае. И я всегда получаю разные ответы », – написал он. «Я действительно разочарован тем, что даже страница в частности созданный для ответа на вопросы Gitops, говорит: «Gitops не предоставляет решения для распространения изменений с одного этапа на другой. Мы рекомендуем использовать только одну среду и вообще избегать распространения стадии ».

Тогда есть наблюдаемость проблема с большими развертываниями Gitops. «В своем текущем состоянии инструменты Gitops отлично подходят для наблюдения за содержимым кластера на техническом уровне, но с треском не справляются с мониторингом бизнес-показателей каждого развертывания», – написал Капелонис. «Если вы внедрите Gitops в крупной компании с большим количеством сред и приложений, количество репозиториев Git быстро возрастет. Это затрудняет отслеживание того, что происходит в каждой среде, и может быстро привести к дублированию конфигурации или к тому, что люди будут делать коммиты в определенных средах ».

Например, если у вас есть 20 репозиториев Git с манифестами Kubernetes и вам нужно сделать централизованное изменение, в настоящее время вам нужно вручную сделать 20 коммитов Git или создать какой-то самодельный связующий код, который сделает это за вас.

«Мы создаем классные инструменты, чтобы увидеть все развертывания, чтобы преодолеть эту проблему наблюдаемости», – сказал Гарфилд из Codefresh. «Добраться до масштаба важно, так как у вас бегают согласователи, и внезапно [don’t know] какое из многих сегодняшних изменений вызвало регресс, и вам нужен способ справиться с масштабом. … Сейчас это граница », – сказал он.

Получить бай-ин Gitops сложно

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

«Мы начинаем видеть организации, в которых специалисты-практики, входящие в группы разработчиков платформы или группы поддержки разработчиков, которые начинают понимать преимущества, которые может принести Gitops, чертовски помогают лицам, принимающим решения, понять ценность, которую приносит Gitops. , потому что часто то, как мы это описываем, либо слишком упрощено, либо не учитывает коммерческую ценность », – сказала Корнелия Дэвис, технический директор Weaveworks.

Одна ошибка, с которой часто сталкивается Дэвис, заключается в том, что он рассматривает Gitops как замену методам DevOps. «Это не переключатель, это революция», – сказала она. «Мы очень повзрослели в гибкой разработке, инструментарий, который поддерживает это, происходят всевозможные оптимизации. Gitops говорит, что мы много сделали со стороны разработчиков, и теперь нам нужно сделать больше с точки зрения эксплуатации ».

«Проблема в том, что технология сложна, и не многие люди знакомы с ней», – сказал Forrester’s Condo. «В ближайшие годы мы увидим еще большую доработку, поскольку предприятия без такого сочетания навыков разработчика и облачного инженера найдут более эффективные способы объединения усилий. [dev and ops]. Если есть какие-то проблемы с Gitops, то он прыгает обеими ногами и не вовлекает всех, кто участвует в этом процессе ».

Для губернатора RedMonk сосредоточение внимания на аспекте контроля, который предлагает Gitops, может стать веской причиной для перехода. «Экономическое обоснование основано на опасениях разработчиков, вносящих в систему изменения, которые могут вызвать проблемы. На данный момент это Дикий Запад, и Gitops собирается восстановить контроль над ситуацией », – сказал он.

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

Хотя все признаки указывают на то, что отрасль все еще находится на ранней стадии внедрения Gitops, Мерсер из IDC считает, что она, вероятно, закрепится «быстрее. [than devops], поскольку культурные барьеры уже немного сломаны. Если вы занимаетесь DevOps и непрерывной доставкой, вы в меньшинстве, но вы будете достаточно хорошо настроены для принятия Gitops ».

Авторские права © 2021 IDG Communications, Inc.


#Почему #Gitops #не #готов #массовому #использованию #пока

Source link