Цитаты: GitOps leverages Git as the single source of truth to define every part of a cloud-native system.
With the declaration of your system stored in a version-controlled system, and serving as your canonical source of truth, you have an ultimate repository from which everything is derived and driven.
At the center of our pull pipeline pattern is a single source of truth for manifests (or a config repo).
By applying GitOps best practices, there is a pre-defined, ultimate source of truth for both your infrastructure and application code that lets your development teams increase velocity and improve system reliability.
Как вы можете заметить, в этих цитатах употребляются словообороты single source of truth, ultimate source of truth. Не main source of truth или common source of truth.
Отсюда можно сделать вывод, что авторы концепции предполагают, что мы должны иметь возможность разрешить ЛЮБОЙ вопрос, связанный с конфигурацией нашего приложения просто посмотрев в гит.
Если вам кажется, что мой перевод не верен, или я что-то важное упустил в документации, прошу это аргументированно изложить.
Я встречал множество паролей, токенов и сертификатов в гите. И, как правило, люди их туда положившие прекрасно знали, что этого делать нельзя. Просто ленились сделать по-другому. Что до использования vault-подобного тулинга в GitOps — я изложил свои соображения в статье. Можем рассмотреть их по существу.
Текст по ссылке, вольный перевод которого я привёл в статье: GitOps doesn’t provide a solution to propagating changes from one stage to the next one. We recommend using only a single environment and avoid stage propagation altogether.
Можете предложить свой вариант перевода, если считаете, что мой не корректен?
Если говорить об общих принципах и распространённых "хороших практиках", то у нас есть методология 12-factor app, в которой первый фактор говорит, что должна быть одна кодовая база, отслеживаемая в системе контроля версий, — множество развёртываний (https://12factor.net/ru/codebase ). Когда у вас несколько веток, код в которых принципиально отличается друг от друга, то между ними накапливается drift, код разъезжается и вам приходится тратить дополнительные силы на поддержку этой разницы. В частности, за это ругают gitflow, в котором предполагается несколько отдельных долгоживущих веток под разные нужды. Но вообще я давал ссылки в статье на стратегии организации инфраструктурных репозиториев от авторов flux. Там много примеров, где одна ветка и несколько папок на окружения. Это близко к стратегии ветка на окружение, и это, на мой взгляд плохая практика (исходя из вышеизложенных соображений).
На самом деле, здесь речь идёт немного о другом — об инфраструктурном репозитории. Код, который в нём лежит, — это не код программы, а код, описывающий её деплой. Вы же говорите об артефакте, который собираете из программного кода и этот вопрос "outside of GitOps scope".
Лукапы для рандомных паролей и самоподписанных сертов, генерируемых на окружение. Хуки - для миграций и прогрева баз и кешей. Какие есть способы сделать это проще в рамках гитопс?
Причин может быть много. В основном они связаны с подключаемыми библиотеками и внешними зависимостями.
Например в моей практике был случай, когда интеграционные тесты падали на некторых сборках. Это было потому что сборка производилась на четырёх раннерах, и на одном из них в кеше залип базовый имидж с неправильной библиотекой, который сопредельная команда собрала неправильно, потом перепушила с тем же тегом. И поймать это было ой как сложно.
У вас неверное понимание определений CI CD. Это достаточно частая ошибка, и в начале статьи я специально дал их каноническое определение со ссылкой на источники. Поскольку они появились задолго до GitOps, нет нужды их пересматривать.
Что до обещаний улучшенной безопасности GitOps, это я рассмотрю этот вопрос во второй части статьи. Опубликую на следующей неделе.
да просто вещи называются своими именами. какие бы плоские структуры кампании не анонсировали, какими бы бирюзовыми они себя не называли, всегда есть сотрудники, которые равнее других. возьмите хотя бы эйпл и токсичного психопата Стива Д. гораздо приятнее работать в кампании где всё называется своими именами и положение вещей обозначается явно, а не не маскируется неочевидными принципами толерантности и политкорректности
Helm слишком удобный и популярный инструмент чтобы его убирать. Можно рендерить тимплейты из чарта и ложить их в инфраструктурный репозиторий, но тогда мы лишаемся как минимум хелм хуков и функции lookup. Проще убрать из цепочки gitops.
Ребята, объясните мне всё-таки - почему vim? Это добро создавалось на самой-самой заре компьютерных технологий, когда решения в области построения пользовательский интерфейсов нащупывались с трудом и в слепую, плюс была полная неразбериха с графическими терминалами. Интерфейс VIM - отражение тех тяжелых времён. Отличный пример - мемный выход из vim'а.
Однако с тех пор мысль в этом направлении шагнула очень далеко вперёд.
На мой взгляд vim плохо подходит для разработки. Если смотреть на код, vim-специфичные ошибки очень заметны. Это например когда нет части символов в названии переменных потому что разраб забыл переключиться в режим редактирования и начал что-то набирать.
Ребята, объясните мне всё-таки - почему vim? Это добро создавалось на самой-самой заре компьютерных технологий, когда решения в области построения пользовательский интерфейсов нащупывались с трудом и в слепую. Интерфейс VIM - отражение тех тяжелых времён. Отличный пример - мемный выход из vim'а.
Однако с тех пор мысль в этом направлении шагнула очень далеко вперёд.
На мой взгляд vim плохо подходит для разработки. Если смотреть на код, vim-специфичные ошибки очень заметны. Это например когда нет части символов в названии переменных потому что разраб забыл переключиться в режим редактирования и начал что-то набирать.
Да это просто пример, иллюстрирующий что гит - плохой источник истины, если он не имеет связи с артефактами.
Два запуска сборки артефакта на одном комите могут дать совершенно разные результаты. Причин может быть тысяча - от незафиксированных зависимостей до кешей на сборщике.
И в гиотпс нет рецепта как сделать его хорошим источником истины.
Это нужно понимать чтобы выстроить качественный, стабильный процесс доставки программного обеспечения.
Мы тегировали имидж по git commit hash, запушили его в registry, потом была автоматическая чистка регистри от образов старше полугода. Спот ноды, на которых крутилось приложение перезаказались и новые поды тупо не смогли подняться. Мы повторяем сборку этого имиджа, но в коде есть незафиксированная транзитивная зависимость от библиотечки, которая за пол года стала несовместима с текущими вызовами и часть функционала приложения просто ломается.
Я ориентируюсь на описание GitOps от авторов концепции: https://www.weave.works/technologies/gitops/
Цитаты:
GitOps leverages Git as the single source of truth to define every part of a cloud-native system.
With the declaration of your system stored in a version-controlled system, and serving as your canonical source of truth, you have an ultimate repository from which everything is derived and driven.
At the center of our pull pipeline pattern is a single source of truth for manifests (or a config repo).
By applying GitOps best practices, there is a pre-defined, ultimate source of truth for both your infrastructure and application code that lets your development teams increase velocity and improve system reliability.
Как вы можете заметить, в этих цитатах употребляются словообороты single source of truth, ultimate source of truth.
Не main source of truth или common source of truth.
Отсюда можно сделать вывод, что авторы концепции предполагают, что мы должны иметь возможность разрешить ЛЮБОЙ вопрос, связанный с конфигурацией нашего приложения просто посмотрев в гит.
Если вам кажется, что мой перевод не верен, или я что-то важное упустил в документации, прошу это аргументированно изложить.
Я встречал множество паролей, токенов и сертификатов в гите. И, как правило, люди их туда положившие прекрасно знали, что этого делать нельзя. Просто ленились сделать по-другому.
Что до использования vault-подобного тулинга в GitOps — я изложил свои соображения в статье. Можем рассмотреть их по существу.
Текст по ссылке, вольный перевод которого я привёл в статье:
GitOps doesn’t provide a solution to propagating changes from one stage to the next one. We recommend using only a single environment and avoid stage propagation altogether.
Можете предложить свой вариант перевода, если считаете, что мой не корректен?
Не очень понимаю, почему мы не можем относиться к инфраструктурному коду так же как к программному. Можете пояснить свою мысль?
Можете пояснить свою мысль? Почему helm плохо подходит для GitOps?
Если говорить об общих принципах и распространённых "хороших практиках", то у нас есть методология 12-factor app, в которой первый фактор говорит, что должна быть одна кодовая база, отслеживаемая в системе контроля версий, — множество развёртываний (https://12factor.net/ru/codebase ). Когда у вас несколько веток, код в которых принципиально отличается друг от друга, то между ними накапливается drift, код разъезжается и вам приходится тратить дополнительные силы на поддержку этой разницы. В частности, за это ругают gitflow, в котором предполагается несколько отдельных долгоживущих веток под разные нужды.
Но вообще я давал ссылки в статье на стратегии организации инфраструктурных репозиториев от авторов flux. Там много примеров, где одна ветка и несколько папок на окружения. Это близко к стратегии ветка на окружение, и это, на мой взгляд плохая практика (исходя из вышеизложенных соображений).
gitflow или gitops?
На самом деле, здесь речь идёт немного о другом — об инфраструктурном репозитории. Код, который в нём лежит, — это не код программы, а код, описывающий её деплой. Вы же говорите об артефакте, который собираете из программного кода и этот вопрос "outside of GitOps scope".
Раз пошла такая пьянка, не могу не вспомнить о runc.
Кубернетес это всего лишь докер композ на стероидах. Гиперсложен и избыточен. Без него процессы поставки сильно упрощаются.
Сори, ничего личного. Просто к слову пришлось :)
Лукапы для рандомных паролей и самоподписанных сертов, генерируемых на окружение. Хуки - для миграций и прогрева баз и кешей. Какие есть способы сделать это проще в рамках гитопс?
Причин может быть много. В основном они связаны с подключаемыми библиотеками и внешними зависимостями.
Например в моей практике был случай, когда интеграционные тесты падали на некторых сборках. Это было потому что сборка производилась на четырёх раннерах, и на одном из них в кеше залип базовый имидж с неправильной библиотекой, который сопредельная команда собрала неправильно, потом перепушила с тем же тегом. И поймать это было ой как сложно.
У вас неверное понимание определений CI CD. Это достаточно частая ошибка, и в начале статьи я специально дал их каноническое определение со ссылкой на источники. Поскольку они появились задолго до GitOps, нет нужды их пересматривать.
Что до обещаний улучшенной безопасности GitOps, это я рассмотрю этот вопрос во второй части статьи. Опубликую на следующей неделе.
да просто вещи называются своими именами. какие бы плоские структуры кампании не анонсировали, какими бы бирюзовыми они себя не называли, всегда есть сотрудники, которые равнее других. возьмите хотя бы эйпл и токсичного психопата Стива Д. гораздо приятнее работать в кампании где всё называется своими именами и положение вещей обозначается явно, а не не маскируется неочевидными принципами толерантности и политкорректности
Helm слишком удобный и популярный инструмент чтобы его убирать. Можно рендерить тимплейты из чарта и ложить их в инфраструктурный репозиторий, но тогда мы лишаемся как минимум хелм хуков и функции lookup. Проще убрать из цепочки gitops.
Ребята, объясните мне всё-таки - почему vim? Это добро создавалось на самой-самой заре компьютерных технологий, когда решения в области построения пользовательский интерфейсов нащупывались с трудом и в слепую, плюс была полная неразбериха с графическими терминалами. Интерфейс VIM - отражение тех тяжелых времён. Отличный пример - мемный выход из vim'а.
Однако с тех пор мысль в этом направлении шагнула очень далеко вперёд.
На мой взгляд vim плохо подходит для разработки. Если смотреть на код, vim-специфичные ошибки очень заметны. Это например когда нет части символов в названии переменных потому что разраб забыл переключиться в режим редактирования и начал что-то набирать.
Ребята, объясните мне всё-таки - почему vim? Это добро создавалось на самой-самой заре компьютерных технологий, когда решения в области построения пользовательский интерфейсов нащупывались с трудом и в слепую. Интерфейс VIM - отражение тех тяжелых времён. Отличный пример - мемный выход из vim'а.
Однако с тех пор мысль в этом направлении шагнула очень далеко вперёд.
На мой взгляд vim плохо подходит для разработки. Если смотреть на код, vim-специфичные ошибки очень заметны. Это например когда нет части символов в названии переменных потому что разраб забыл переключиться в режим редактирования и начал что-то набирать.
У меня есть по крайней мере два варианта лучше. И это не блокчейн. Раскрою тему во второй части статьи.
Да это просто пример, иллюстрирующий что гит - плохой источник истины, если он не имеет связи с артефактами.
Два запуска сборки артефакта на одном комите могут дать совершенно разные результаты. Причин может быть тысяча - от незафиксированных зависимостей до кешей на сборщике.
И в гиотпс нет рецепта как сделать его хорошим источником истины.
Это нужно понимать чтобы выстроить качественный, стабильный процесс доставки программного обеспечения.
Не всё так просто. Кейс из практики:
Мы тегировали имидж по git commit hash, запушили его в registry, потом была автоматическая чистка регистри от образов старше полугода. Спот ноды, на которых крутилось приложение перезаказались и новые поды тупо не смогли подняться. Мы повторяем сборку этого имиджа, но в коде есть незафиксированная транзитивная зависимость от библиотечки, которая за пол года стала несовместима с текущими вызовами и часть функционала приложения просто ломается.