Рубрика «gitops»

Что такое GitOps и почему он (почти) бесполезен. Часть 2 - 1
Одной каноничной синей изоленты может не хватить

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

Первая часть статьи вызвала живое обсуждение. Мысль, что git является не единственным источником истины при наличии связанных артефактов во внешних системах (особенно если эти артефакты имеют потенциальные проблемы с повторяемостью сборок), встретила некоторые возражения. Но в этом вопросе я предлагаю следовать закону Мерфи: если неприятность может случиться, то она случается. Рано или поздно не отображаемые в git проблемы внешних зависимостей выстрелят вам в ногу. Эти риски нужно постоянно держать в голове и по возможности митигировать.

Какие ещё потенциальные сложности могут встретить вас при следовании пути GitOps и какие могут быть альтернативы? Давайте разберёмся вместе.
Читать полностью »

В этой статье мы рассмотрим новый экспериментальный режим совместной работы Open Source-утилиты werf и инструмента для непрерывной доставки Argo CD, объединяющий в себе возможности и удобства обоих проектов в рамках одного CI/CD-процесса. Сейчас идет активная разработка этих возможностей werf, но в первом приближении функционал уже доступен и готов к использованию.

Новые возможности werf: CI-CD на основе werf и Argo CD - 1

Читать полностью »

Теоретическая часть

Для начала стоит отметить, что в ArgoCD по умолчанию нет возможности скрытно управлять credentials (логинами, паролями, токенами, etc). В документации по ArgoCD приведён список возможных решений по управлению credentials. По моему мнению, наиболее близок к нативному — вариант работы с секретами посредством argocd-vault-plugin (AVP) с использованием Kubernetes auth в Vault. Схема получается следующей: argocd-repo-server авторизуется в Vault при помощи Service Account token, в манифесте Secret в < ... > подставляет небходимое значение, и создаёт секрет.

Читать полностью »

Разбираемся с Custom Tooling в Argo CD - 1

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

В большинстве случаев требуется типовая задача: "сгенерировать YAML и положить его в Kubernetes". Собственно, с чем Argo CD замечательно и справляется.

Argo CD позволяет подключить Git-репозиторий и синкать его состояние в Kubernetes. По умолчанию есть поддержка нескольких видов приложений: Kustomize, Helm чарты, Ksonnet, голый Jsonnet или просто директории с YAML/JSON манифестами.

Большинству пользователей этого набора будет достаточно, но не всем. Для того чтобы удовлетворить потребности всех и каждого в Argo CD имеется возможность использовать custom tooling.

В первую очередь интересует возможность добавления поддержки qbec и git-crypt, которые с полна были рассмотренны в предыдущей статье.

Читать полностью »

На днях вышла прекрасная, хотя и спорная статья — Please, stop using GitFlow! (и еще десяток на эту же тему после нее).

Ее основными тезисами были:

  • GitFlow противоречит тезису "ветки должны быть короткоживущими".
    Это важно, потому что чем меньше живет ветка — тем меньше шанс конфликтов (не только git, но и логических)
  • GitFlow препятствует rebase-ам, чтобы сохранить merge-коммиты.
    Да, их можно сохранять и при ребейзах, но команды Git Flow не делают этого.
  • GitFlow отрицает подход Contunious Delivery, считая, что каждый акт Delivery должен совершаться релиз-инженером, да и в целом можно увидеть, что он ориентирован только на долгий релизный цикл.
  • GitFlow не дружит с микросервисами поверх мультирепозиториев (впрочем, тут вообще мало что подходит, это идея, которая всегда плохо заканчивается)
  • Но проблема GitFlow в том, что он и с монорепозиториями тоже не дружит.

    Я сам об это споткнулся в процессе дизайна пайплайнов CI: GitFlow чудовищно мешает, когда работает поверх монорепозитория с несколькими deliverables, например, когда в одном репозитории отдельно и бэкэнд, и фронтэнд — уже из-за того, что он позволяет докоммичивать в релизные ветки, могут возникнуть конфликты при обратном мердже, если в один момент времени существует больше, чем одна релизная ветка. Да даже если одна, все равно плохо — в таких условиях надо патчить в принципе релизные механизмы GitFlow, чтобы хоть как-то заработали отдельные релизы сущностей.

Так что делать-то?

Читать полностью »

Релиз werf 1.1: улучшения в сборщике сегодня и планы на будущее - 1

werf — наша GitOps CLI-утилита с открытым кодом для сборки и доставки приложений в Kubernetes. Как и обещали, выход версии v1.0 знаменовал начало добавления в werf новых возможностей и пересмотра привычных подходов. Теперь мы рады представить релиз v1.1, который является большим шагом в развитии и заделом на будущее сборщика werf. Версия доступна на данный момент в канале 1.1 ea.

Основа релиза — это новая архитектура хранилища стадий и оптимизация работы обоих сборщиков (для Stapel и Dockerfile). Новая архитектура хранилища открывает возможности к реализации распределенных сборок с нескольких хостов и параллельных сборок на одном хосте.Читать полностью »

Представляем werf 1.0 stable: при чём тут GitOps, статус и планы - 1

Werf — это GitOps CLI-утилита с открытым кодом для сборки и доставки приложений в Kubernetes. Werf поддерживает сборку образов приложения с помощью Dockerfile или собственного встроенного сборщика (на основе синтаксиса YAML, с поддержкой Ansible и инкрементальной пересборки на базе Git). Для доставки приложения используется формат конфигурации, совместимый с Helm. Код приложения, конфигурация собираемых образов и конфигурация выката приложения хранятся в одном Git-репозитории.

Долгожданный стабильный релиз 1.0 — это законченная по функциям базовая версия утилиты (точный номер версии первого стабильного релиза — это 1.0.6). В базовой версии werf поддерживает полный цикл доставки приложения и его сопровождения. Это включает в себя сборку образов приложения, деплой в Kubernetes, очистку неиспользуемых образов.Читать полностью »

27 мая в главном зале конференции DevOpsConf 2019, проходящей в рамках фестиваля РИТ++ 2019, в рамках секции «Непрерывная поставка», прозвучал доклад «werf — наш инструмент для CI/CD в Kubernetes». В нём рассказывается о тех проблемах и вызовах, с которыми сталкивается каждый при деплое в Kubernetes, а также о нюансах, которые могут быть заметны не сразу. Разбирая возможные пути решения, мы показываем, как это реализовано в Open Source-инструменте werf.

С момента выступления наша утилита (ранее известная как dapp) преодолела исторический рубеж в 1000 звёзд на GitHub — мы надеемся, что растущее сообщество её пользователей упростит жизнь многим DevOps-инженерам.

werf — наш инструмент для CI-CD в Kubernetes (обзор и видео доклада) - 1

Итак, представляем видео с докладом (~47 минут, гораздо информативнее статьи) и основную выжимку из него в текстовом виде. Поехали!Читать полностью »

Прим. перев.: После недавней публикации материала о методах pull и push в GitOps мы увидели интерес к этой модели в целом, однако русскоязычных публикаций на эту тему оказалось совсем мало (на хабре их попросту нет). Посему рады предложить вашему вниманию перевод другой статьи — пусть и уже почти годичной давности! — от компании Weaveworks, глава которой придумал термин «GitOps». В тексте поясняется суть подхода и ключевые отличия от уже существующих.

Что же такое GitOps? - 1

Год назад мы опубликовали введение в GitOps. Тогда мы рассказали, как команда Weaveworks запустила SaaS, целиком основанную на Kubernetes, и разработала набор предписывающих лучших практик для развертывания, управления и мониторинга в среде cloud native.Читать полностью »

Прим. перев.: В сообществе Kubernetes явную популярность набирает тренд под названием GitOps, в чём мы лично убедились, посетив KubeCon Europe 2019. Этот термин был относительно недавно придуман главой компании Weaveworks — Alexis Richardson — и означает применение привычных для разработчиков инструментов (в первую очередь — Git, откуда и само название) для решения задач эксплуатации. В частности, речь об эксплуатации Kubernetes через хранение его конфигураций в Git и автоматического выката изменений в кластер. О двух подходах к этому выкату и рассказывает Matthias Jg в данной статье.

GitOps: сравнение методов Pull и Push - 1

В прошлом году (на самом деле, формально это произошло в августе 2017 г. — прим. перев.) появился новый подход к развёртыванию приложений в Kubernetes. Он называется GitOps, а в его основе лежит базовое представление о том, что отслеживание версий deployment'ов ведется в безопасной среде Git-репозитория.Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js