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

Проблемы устаревают после 90 дней бездействия.
Отметьте проблему как новую с помощью /remove-lifecycle stale .
Устаревшие выпуски гниют после дополнительных 30 дней бездействия и в конечном итоге закрываются.

Если сейчас проблему можно безопасно закрыть, сделайте это с помощью /close .

Отправьте отзыв в sig-testing, kubernetes / test-infra и / или fejta .
/ жизненный цикл устаревший

Возвращаясь к этому снова, поскольку он был поднят в https://github.com/kubernetes/charts/pull/5919

Копирование части моего недавнего комментария:

Мы специально стараемся, чтобы младшая версия нашей диаграммы была согласована с дополнительной версией приложения (хотя номера версий исправлений могут и действительно расходятся).

Это связано с тем, что мы можем добавить новый флаг в новую версию cert-manager, и добавление его поддержки в диаграмму Helm нарушит совместимость со старыми версиями cert-manager, поскольку они не поддерживают этот флаг. Это довольно фундаментальный вопрос о версиях диаграммы Helm в целом IMO, и у нас нет хорошей истории.

Я знаю, что не рекомендуется пытаться согласовать appVersion с версией диаграммы, но таким образом пользователь знает, что может использовать Helm chart версии 0.3.x с любым из cert-manager 0.3.x и диаграммы версии 0.4.x с сертификатом. -manager 0.4.x. Совместимость определяется в дополнительной версии.

/ remove-жизненный цикл устаревший

Я хотел бы вернуть это для обсуждения.

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

Копирование моего исходного предложения, упомянутого выше:

Наш текущий рабочий процесс для развертывания Helm-диаграмм включает в себя доступные задачи, которые вызывают команду CLI helm upgrade, и было бы неплохо иметь возможность передать флаг для установки appVersion при пересмотре выпуска для той же версии диаграммы.

Это может быть немного странно концептуально, потому что appVersion связана с диаграммой, а не с выпуском, но в нашем случае мы просто обновляем тег изображения, используемый для некоторых контейнеров, и наш рабочий процесс не дошел до включения версии диаграммы и / или репозиториев диаграмм. пока что. Это может измениться в будущем, но на данный момент я не вижу проблем с добавлением флага для --app-version при установке и обновлении, поскольку это поле носит чисто информационный характер.

при разработке собственных внутренних приложений само приложение меняет гораздо больше, чем диаграмма, на которой оно развертывается. Обычно наша команда непрерывного развертывания представляет собой команду helm upgrade содержащую не что иное, как --set imageTag=<new_version> (очевидно, используется в другом месте диаграммы для установки версии контейнера). Если мы заменим это на --app-version, это даст нам еще одну визуальную точку в helm ls чтобы увидеть, какие версии кода развернуты вместе с версией развернутой диаграммы.

Чтобы сделать это более заметным в противном случае, я стандартизировал установку тега метаданных imageTag который устанавливается в imageTag, передаваемый при установке / обновлении. Это позволяет мне использовать приборную панель K8s или легко создавать информационные панели Graphana с отображаемым imageTag, но требует, чтобы я покинул командную строку и начал щелкать мышью.

Есть новости об этом?

Спасибо

Любые обновления по этому поводу. Похоже, PR от @Eraac делает то, о чем просят. Как упоминалось в @ TD-4242, мы также запускаем helm upgrade --set imageTag=<imagetag> , однако при этом не обновляется ВЕРСИЯ ПРИЛОЖЕНИЯ, указанная в выводе helm ls . Возможность --set app-version или --set version позволит нам запустить helm upgrade , что helm ls правильно покажет развернутую версию.

Любые обновления?

Аааааное время скоро будет прекрасным!

это будет очень полезно

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

+1

+1

Было бы очень полезно

Запрашивая то же самое

Пожалуйста, остановите спам с помощью +1. Уже есть PR (https://github.com/helm/helm/pull/4961), и люди обсуждают предложение. Последний ответ был еще 2 дня назад.

Привет @filipre

Уже есть PR (# 4961), и люди обсуждают предложение.

Согласно этому PR, это было перемещено сюда:
https://github.com/helm/helm/pull/5492
Это последний PR к # 4961 и похоже, что если мы ждем объединения обзора ...

@filipre Скажите , пожалуйста, что происходит с пиаром? Похоже, что у пиара нет хода полмесяца

Это было бы очень полезно. Я столкнулся с чем-то, что мне нужно привязать к версии 0.6.0 приложения, и версия диаграммы не имеет отношения к версии приложения.

Согласен, тоже думаю, что это было бы очень полезно. Любые обновления?

См. Https://github.com/helm/helm/pull/5492#issuecomment -509662190.

Просто коснитесь этой проблемы сейчас, когда я понял, что это будет проблемой при написании диаграммы Helm, которую мы планируем повторно использовать для многих приложений. Учитывая отсутствие прогресса в решении этой проблемы простым способом (то есть с помощью флага для установки версии приложения при установке), я придумал альтернативу, которая должна работать на данный момент. На самом деле это очень просто - просто сделайте сначала helm fetch с параметром untar, а затем helm package с флагом --app-version , который там существует, а затем приступите к установке этой локальной диаграммы.

Это не идеально, но конечный результат в виде helm list правильный, и это очень просто сделать на сервере CI. Хотелось бы, чтобы --app-version были доступны на helm install и helm upgrade .

Сводка обсуждения в # 5492 заключалась в том, что команда, которая объединяет логику helm package и helm install , решит вариант использования, первоначально описанный в этой проблеме.

Другими словами, вы можете обойти это, выполнив следующее:

$ helm package myapp --app-version 1.0.0
$ helm install myapp-1.0.0.tgz

(Перемещение сюда комментария из недавно закрытого PR - чтобы он не попал в Nirvana)

Вот мои 2 цента на это:
Предположим, у нас есть штурвал chart version X развертывающий службу с appVersion Y .

Helm-диаграмма используется для описания инфраструктуры внутри Kubernetes на chart version X который используется для размещения службы appVersion Y .

На начальном этапе разработки и X и Y будут регулярно меняться. Однако в какой-то момент X будет более или менее стабильным, а Y продолжит меняться (если только Y не предъявляет каких-либо новых требований к инфраструктуре, что, скорее всего, случается гораздо реже. в цикле разработки Y ).

С подходом, предложенным в этом билете, можно взять стабильный пакет helm-диаграммы в версии X для развертывания appVersion Y , Y+1 , Y+N и т. Д.

Однако запрет на переопределение этого флага во время установки или обновления Helm и вместо этого, например, только в пакете, эффективно связывает X и Y вместе, заставляя меня всегда создавать новый X+1 за Y+1 . Мне это кажется ненужным и приведет к тонне пакетов helm, которые фактически не изменились, за исключением того, что они ссылаются на новый appVersion . С моей точки зрения, версия приложения и версия инфраструктуры, в которой размещено это приложение, имеют отношение, но должны или могут иметь независимые версии. Как это делается, следует оставить на усмотрение соответствующих команд разработчиков.

Резюме:

Этот подход определенно работает, но он также приводит к появлению множества ненужных пакетов Helm, в которых изменился только AppVersion :
$ helm package myapp --app-version 1.0.0 $ helm install myapp-1.0.0.tgz

Да, но я полагаю, что это не большая проблема, если вы воспользуетесь подходом, о котором я упоминал выше. Отправьте свою диаграмму в репозиторий диаграммы без установленной версии приложения (или 0.0.0 или чего-то еще), затем, когда вы захотите ее использовать, используйте helm fetch , затем упакуйте ее в нужную версию приложения, затем используйте локальную .tgz file и не нажимайте эту диаграмму. Таким образом, репозиторий графиков остается чистым, и на нем отображаются только фактические изменения графика.

Да, сработает. В этом случае нельзя напрямую использовать артефакт развертывания (например, путем прямой установки из репозитория Helm), но всегда нужно отправлять его через дополнительный шаг, который мутирует артефакт.

Когда утверждалось, что Charts.yaml должен быть неизменным, я утверждаю, что артефакт развертывания должен быть неизменным.

_Обобщение моих мыслей с https://github.com/helm/helm/pull/5492#issuecomment -520029902_

Проблема в том, как сообщество интерпретирует пакет, диаграмму и версии. @BenjaminSchiborr , я надеюсь, что это будет иметь для вас смысл.

Диаграмма - это исходный код вашего релиза. Как исходный код вашего приложения. Состоит из шаблонов, файлов кода.
Пакет - это сборка вашего релиза, артефакт. Как двоичный файл, созданный из вашего исходного кода. Состоит из фиксированных производственных версий: как версия диаграммы, так и версия приложения.
Релиз - это сборка, развернутая с заданной конфигурацией.

Невозможно сделать Релиз вне графика . Это просто так не работает!

Перед развертыванием приложения на сцене вам понадобится диаграмма. Затем вам нужно упаковать приложение с диаграммой, исправив обе версии, используя helm package . В результате получится пакет, который можно развернуть на любом этапе. Затем вы устанавливаете этот пакет, например, на этапе контроля качества, продвигаете его в UA, а затем в рабочей среде, используя helm install .

Так работает любое пакетно-ориентированное программное обеспечение.

Путаница

helm install нужен источник, который нужно установить. Источник мог быть:

1. Имя пакета, доступное в реестре
2. Путь к файлу пакета, если пакет уже загружен или создан
3. URL пакета, если он доступен по HTTP
4. Путь к каталогу диаграммы

Четвертый подход кажется здесь паршивой овцой, вам не кажется? Вот почему люди путают Пакет и Диаграмму. И в этом корень проблем.

Рассуждение

В дикой природе есть два типа приложений:

Большой / средний - здесь у нас есть время, деньги и ресурсы для настройки детальных, детализированных потоков для лучшего самоанализа и гарантий качества.
Небольшие - микросервис, любимый проект, PoC, недорогие проекты, проекты без знаний DevOps или даже тестирование процесса разработки.

В небольших проектах у вас нет времени или необходимости создавать или заниматься упаковкой. Вы хотите написать несколько файлов шаблонов и развернуть их с помощью одной команды !

Вот почему helm install допускает такое использование, как helm package & helm install . Но он не предоставляет полные возможности helm package , такие как --app-version .

helm install может быть helm package & helm install , но это сделает helm install беспорядком, адом для поддержки, тестирования и применения передовых методов.

Предложение 1

Упростите helm install . Он должен позволять предоставлять только пакеты, чтобы упростить кодовую базу, тесты и сделать их самоуверенными, чтобы упростить понимание helm .

Предложение 2 - helm run

Введите новую команду: helm run . Команда, которая должна просто работать . Идеально подходит для небольших приложений. А может даже средний и большой.

Он должен сочетать helm package и helm install , обеспечивая возможности обеих команд, за исключением тех, которые не имеют смысла в таком случае использования.

helm package создает сборку, как go build . go run позволяет запускать приложение без процесса сборки, поэтому helm run выглядит как солидное имя.

Дополнительные моменты, которые следует учитывать:

• Следует ли вместо этого использовать upgrade --install ?
• Должен ли он быть включен по умолчанию --atomic ?

@iorlas ,
ваши комментарии имеют смысл. Однако вы предполагаете, что может быть только один окончательный пакет, который наследственно связывает вместе как версию инфраструктуры, так и версию программного обеспечения, при этом я предполагаю, что у меня есть пакет для моей версии программного обеспечения и пакет для моей инфраструктуры и я хочу связать их. в выпуске (например, через желаемую конфигурацию состояния, которая ссылается на версию программного обеспечения и версию инфраструктуры).

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

Я в порядке, если в этом есть какое-то долгосрочное преимущество. Я этого просто не вижу.

@BenjaminSchiborr Хорошо, позвольте мне немного

У вас может быть диаграмма (== инфраструктура) с версией X .
У вас может быть ваше приложение версии Y .

Как сейчас работает helm он связывает воедино версии инфраструктуры и приложений на этапе helm package . Затем вам нужно связать его с пространством имен k8s, создав Release.

Итак, формула: package(infra + app) + k8s = Release

Что вам действительно нужно, так это пропустить этот средний шаг и связать все 3 компонента вместе на одном шаге - Release. Вот так: infra + app + k8s = Release . Я прав?

Вот что делает helm run на поверхности. Под капотом будет то же самое.

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

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

Сам Helm создан для того, чтобы абстрагироваться от шаблонов и развертывания k8s, связать вместе приложение и инфраструктуру с его зависимостями: вместо того, чтобы вручную переписывать шаблоны, применять их на K8s и затем предоставлять новый тег изображения, вам нужна только одна команда - helm upgrade . Как пакет MSI или deb.

Когда вам нужно установить новую версию приложения или понизить ее, вы должны использовать для этого helm. Вместо управления приложением вы управляете всем пакетом. Было бы головной болью откатывать версию приложения и инфраструктуру отдельно, когда что-то пойдет не так - я был там, никому не предлагаю.

Поэтому правильно иметь много пакетов в вашем реестре, поскольку пакет - это не инфраструктура, пакет - это приложение, потому что приложение ничего не значит в K8s без инфраструктуры.

Если ваша проблема в том, что у вас слишком много пакетов в репо, я бы предложил использовать артефакты вместо репозиториев. Я делаю это в CI так: создаю приложение, отправляю в реестр докеров, создаю пакет, сохраняю его как артефакт для выпуска. CircleCI, Travis, Azure Pipelines поддерживают создание файлов, прикрепленных к сборке в виде артефактов. Вы можете сделать то же самое?

Может, я упускаю суть Хельма. Может быть, Хельм здесь что-то упустил. Я думаю, что этот билет предназначен для оценки именно этого. И лично - тоже о расширении кругозора :)

Но да, абстрактно то, что вы говорите, правильно. Я не хочу, чтобы версия программного обеспечения была связана с пакетом / выпуском helm, поэтому по сути это infra + app + k8s = Release . Так же, как я не хочу, чтобы свойства моей версии программного обеспечения были привязаны к моему пакету / выпуску Helm (кроме, возможно, нормального значения по умолчанию, которое я могу переопределить).

Что касается примера, который вы приведете ниже. Я не понимаю, как это показывает, насколько проблематичен такой подход. Вы все равно будете использовать helm для отката или отката вперед. Если инфраструктура изменяется, вы используете измененную версию рулевой диаграммы. Если версия программного обеспечения изменится, вы используете другую версию приложения. Если параметр изменяется, вы используете другой параметр. Это всегда будет (один) вызов руля для каждой службы.

Вы можете уточнить?

Если ваша проблема в том, что у вас слишком много пакетов в репо, я бы предложил использовать артефакты вместо репозиториев.

Я имел в виду слишком много упакованных диаграмм руля (которые уже включают appVersion). Думайте об этом как об одной стабильной версии диаграммы управления и версии приложения, которая изменяется сотни раз в день. Итак, ежедневно в репозитории создается несколько сотен упакованных диаграмм руля для каждой службы, которые затем используются средствами автоматизации.

(Мои конвейеры обычно выглядят так же, как ваш: Сборка приложения -> Образ Docker (результаты в appVersion) -> диаграмма пакетов (с обновленной версией appVersion) -> отправляет в репозиторий?

Я думаю, что этот билет предназначен для оценки именно этого.

Точно! На мой взгляд, у нас уже слишком много уровней абстракции, поэтому наличие здесь штурвала немного подавляет 😄Кроме того, здесь есть операторы k8s, которые созданы для некоторых (может быть, большинства?) Проблем, которые решает Helm. Но это тема для другого раза, хе-хе.

Думайте об этом как об одной стабильной версии диаграммы управления и версии приложения, которая изменяется сотни раз в день. Итак, ежедневно в репозитории создается несколько сотен упакованных диаграмм руля для каждой службы, которые затем используются средствами автоматизации.

Да, это определенно кажется слишком большим, но это задумано. Например, у вас есть запуск сборки, он должен произвести некоторые артефакты, а затем сохранить его, чтобы использовать для развертывания на сцене. Например ... как мы можем запустить сборку без результата сборки? Должны ли мы генерировать сборку при развертывании? Это было бы действительно неправильно. Хотя некоторые конвейеры CI делают это для сборок JS.

Та же проблема, что и с докером: каждая сборка генерирует новый образ докера, который попадает в реестр докеров. Нам нужно его сохранить, как мы должны тогда его развернуть, если бы у нас его не было?

Конечно, мы можем docker save сэкономить место в реестре и подметать позже при сборке политики хранения файлов. Но так мы можем helm package и сохранить как файл.

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

Само приложение не имеет смысла в среде k8s без инфраструктуры .

Что, если ваше приложение полагается на некоторую инфраструктуру? Базовый пример - configmap.

Что делать, если тогда вам нужно будет откатить приложение?
Вам нужно будет понизить версию приложения, но тогда вам нужно будет также понизить версию инфраструктуры.

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

Право, это было бы адом. И это ад, когда у тебя нет руля. И в этом нет ничего плохого. Но в этом случае у вас мало причин использовать helm.

у нас уже слишком много уровней абстракции
Все красиво и просто подмигнуть

Я думаю, что ваш последний пункт очень убедителен:

Предыдущая инфраструктура не знает, какую версию приложения вам нужно установить, поскольку она не привязана к ней.
Это определенно проблема, если вы разделите эти вещи и используете пакет / выпуск Helm в качестве источника истины.

Однако для многих людей это, вероятно, не так. На вершине Helm есть оркестровка (ура, еще один уровень абстракции), которая связывает несколько диаграмм управления (и appVersions) вместе (подумайте, рулевой, упряжь и т. Д.). И сам этот слой тоже версируется. В этом случае то, что вы описываете, больше не является проблемой, потому что вы не вернетесь к более старой версии диаграммы управления, а вернетесь к более старой версии уровня оркестровки (который имеет смысл в приложении и инфраструктуре).

Но один только штурвал, да, 100% проблема. Я думаю, что это причина, по которой идея заключалась в том, чтобы явно разрешить переопределение appVersion и по умолчанию не разрешать это.

Что мне нравится в соединении версии диаграммы и версии приложения, так это то, что становится ясно, какая версия приложения принадлежит какой диаграмме. Если вам нужно повторно развернуть одну конкретную версию, вам не нужно помнить, какая версия приложения была совместима с какой версией диаграммы. Поскольку они связаны друг с другом, вы просто ссылаетесь на нужную версию диаграммы, и вы будете уверены, что это приложение и диаграмма совпадают. Я думаю, что это в основном то, что описал @iorlas , верно?

В конце концов, графическая версия будет выступать в роли «супер» -версии:

• любое изменение (независимо от того, изменилось ли оно приложение или инфраструктура, т.е. диаграмма) приведет к новой версии диаграммы, т. е. новая версия приложения будет означать, что версия диаграммы также изменилась
• новая версия диаграммы не означает, что версия приложения изменилась

В целях документации (и, возможно, других интересных идей) вы можете сами представить другую версию «только диаграммы», которая будет относиться только к самому определению диаграммы.

@filipre
Ага-ага! Именно так должен был работать Хельм, основываясь на текущих архитектурных дизайнерских решениях. Как я вижу это.

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

@BenjaminSchiborr

Однако для многих людей это, вероятно, не так.

Точно! Даже целые k8, контейнеризация может быть слишком большой.

Позвольте мне попытаться разобрать это с немного другой точки зрения, пытаясь найти проблему, для которой создан штурвал:

• Экземпляр инфраструктуры - это то, как работает весь продукт: экземпляры SaaS, пулы виртуальных машин, настройки k8s, версии приложений (включая базы данных, инструменты наблюдения, маршрутизаторы, вспомогательные машины и экземпляры приложений продукта)
• Экземпляру инфраструктуры нужен один источник правды. Теперь у нас есть такие утилиты, как Terraform.
• Слишком много вещей в одной папке = сложно. Нам нужно его разложить. Привет, модули Terraform.
• И платформа, и приложение в одной папке = хард. Нам нужно разложить. Привет, платформа и контейнеры. K8s вступает.
  
  
  
  1. Таким образом, модули Terraform могут управлять платформой, в том числе создавать слой пустых, готовых к использованию контейнеров.
  
  
  2. K8s управляет контейнерами, позволяя создавать базовые ресурсы с помощью YAML.
  
  
• Многие файлы YAML для многих приложений K8s (включая базы данных и прочее) = сложно. Разделите его по папке для каждого приложения.
  
  
  
  1. Итак, у нас есть несколько папок, таких как PostgreSQL, Redis, MyPetShop. У каждого из них есть файлы YAML для имеющихся у нас ресурсов. И ему нужно установить версии его приложения, чтобы его можно было применить в K8s.
  
  
• Hello Helm - инструмент, позволяющий настраивать эти папки (называемые Charts), но более того: применять вместе, откат.
• График выглядит солидно. Давайте использовать его повторно, добавив вспомогательные переменные. Теперь диаграмма - это не инфраструктура, а шаблон инфраструктуры.
• График выглядит потрясающе. Давайте поделимся этим с друзьями. Каждый раз, когда мы обновляем диаграмму, нам нужно помещать ее в репозиторий файлов с index.

Так что он чувствует себя потрясающе, и все такое, вообще без пакетов. Итак, вам необходимо применить эту диаграмму, а затем указать версию приложения. Так и должно быть.

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

В конце концов, все, что нам нужно, это «Настроить myApp версии 1.4.2 как приложение K8s» , которое объединяет все риски, зависимости и изменения в один артефакт - установщик приложения, который называется apps versions + hooks + setup logic + infrastructure to connect it all . Вот почему у нас есть такие вещи, как MSI, Deb, RPM, даже NPM, Go mod, Pip, Gem.

Здесь на сцену выходит Package. И пакет, по определению, должен быть создан как устанавливаемый выпуск в потоке CI / CD. Таким образом, мы можем отправить его в реестр и / или настроить в нашей системе (кластер k8s).

И ни один другой проект не отличается. Когда мы делаем helm install Chart напрямую, без упаковки, мы делаем то же самое. Но вместо создания пакета мы создаем его на другом этапе. Вместо того, чтобы строить его на процессе сборки приложения, мы строим его на этапе выпуска. Мы по-прежнему связываем воедино версии инфраструктуры и приложений . Неявно .

Забавная вещь:

• Зависимость обновлена ​​= обновить версию шаблона инфраструктуры (диаграммы)
• Приложение обновлено = создать форк, подмножество шаблона инфраструктуры (диаграмма) - пакет с собственной версией

Тем не менее, операторы k8s должны быть спроецированы на текущие проблемы, поэтому должен быть только один инструмент, который должен работать как операторы, но обеспечивать простой процесс выпуска, как это делает helm.

Есть предположения? Возможно, мы создаем здесь что-то новое, но лучше

То, что вы описываете, имеет большой смысл для приложений, которые предназначены для использования другими людьми в инфраструктуре, которую вы не можете контролировать. Однако в корпоративных сценариях создание пакетов превращается в рутинную работу: у нас могут быть десятки микросервисов для вырезания файлов cookie, которые развернуты в общих средах или средах для вырезания файлов cookie, а также благодаря определению конвейера CI / CD, которое живет в самом репозитории (подумайте, azure-pipelines.yaml), «версия пакета» - это просто сборка, созданная на основе конкретной версии основной ветки. Это означает, что мне действительно не нужно где-либо хранить «пакет» - моя сборка создаст тот же пакет, с теми же битами и теми же переменными, которые используются в конфигурационных картах и ​​т.д. сервисная инфраструктура меняется, что случается довольно редко. Helm на этой картинке потому, что 1) мне уже нужно использовать его для развертывания некоторых частей инфраструктуры (например, nginx), 2) мне не нужно изобретать колесо с шаблонами k8s yaml.

@wasker

Спроецируем его, например, на докер. Образ Docker - это тоже пакет. Он связывает двоичные файлы с образом ОС = инфраструктура. Я считаю, что причина создания образа докера каждый раз, когда мы делаем сборку, та же, что и для создания пакета helm.

Если нет необходимости абстрагировать все до образов докеров, докер не нужен, и он может жить с простой виртуальной машиной.

Итак, если мы попытаемся спроецировать использование докеров на helm, использование helm только в качестве инструмента инфраструктуры будет похоже на использование docker только для создания начального образа с последующим обновлением такого образа на самом хосте k8s путем отправки новых двоичных файлов. Это плохо, так же плохо, как пользоваться рулем и каждый раз не переупаковывать его.

В любом случае, я думаю, мы пошли неправильным путем. Кто-нибудь использует helm, а затем обновляет изображение вручную? Я считаю, что у нас есть 3 общих варианта использования:

1. helm package chart -> helm install package
2. helm install chart
3. helm install -> kubectl set image

@wasker Какой твой? Думаю, не 3-й. Даже если это настоящее разделение конфигурации инфраструктуры и управления версиями приложений, работать с ним было бы неприятно. Поскольку это будет означать, что когда вам нужно будет обновить инфраструктуру, вы потеряете все версии. Вам нужно будет обновить его в Chart вручную или kubectl set image для каждого развертывания.

Итак, речь идет о втором, helm install chart , «без упаковки». Итак, штурвал всегда на виду . Проблема в том, что пакет создается, но во время выполнения - когда мы развертываем наше приложение. Таким образом, сборка CI неявно отвечает за создание пакета, когда нам нужно его развернуть.

И если спроектировать его на golang, такая практика выглядит как отправка исходного кода и запуск его как go run в докере вместо его сборки и использования двоичного файла.

Итак, настоящая причина пропустить этап упаковки - упростить для инженера всю картину. Это так ?

Здесь мы можем начать разговор. Здесь https://github.com/helm/helm/issues/3555#issuecomment -529022699 - мое предложение. Добавьте helm run и смоделируйте его как go run .

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

Спроецируем его, например, на докер. Образ Docker - это тоже пакет. Он связывает двоичные файлы с образом ОС = инфраструктура. Я считаю, что причина создания образа докера каждый раз, когда мы делаем сборку, та же, что и для создания пакета helm.

Я предполагаю, что проблема в том, что если вы создаете новый образ Docker, это потому, что что-то в этом образе изменилось. В описываемом здесь сценарии содержимое упакованной Helm Chart не изменилось, за исключением одной строки - версии приложения. Это действительно влияет на конечный результат, но не влияет на поведение диаграммы Helm. Он будет делать то же самое, точно так же, только с разными значениями - Helm Chart как самостоятельный объект не изменился ни в малейшей степени в результате изменения версии этого приложения; есть только то, что выпущено в конце.

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

И если спроектировать его на golang, такая практика выглядит как отправка исходного кода и запуск его как go run в докере вместо его сборки и использования двоичного файла. [...] Итак, настоящая причина пропустить этап упаковки - упростить для инженера всю картину. Это?

Не на мой взгляд. На самом деле аргумент здесь заключается в том, считают ли люди версию приложения «частью диаграммы», а также считают ли они диаграмму Helm отличной от образов Docker, которые развертываются в результате диаграммы. Моя точка зрения на это - это то, о чем я говорил выше. Это как взять скомпилированный двоичный файл Go в образе Docker и запустить его с разными переменными среды.

При этом аргументы, которые были выдвинуты в пользу переупаковки Helm Chart с новой версией приложения и использования версии диаграммы в качестве некой «суперверсии», являются убедительными (а именно, за преимущество всегда иметь совместимую версию приложения, развернутую с диаграмма - при условии, что версия приложения не настраивается с помощью значений).

У меня вопрос - почему бы не поддержать оба подхода? У каждого подхода есть свои плюсы и минусы. По сути, отказ от поддержки этого только усложняет некоторые совершенно корректные рабочие процессы. Например, используя Flux CD и его Helm Operator. Если у вас есть общая диаграмма Helm (то есть потому, что у вас есть определенный тип службы, многие из которых вы развертываете, и у них есть многие из одинаковых характеристик), то для получения полезного вывода helm list вам необходимо иметь новый Helm Диаграмма для каждого приложения, и для каждого выпуска также нужна собственная диаграмма Helm. Само по себе это усложняет конвейеры, потому что, если бы диаграмма могла быть общедоступной, у нее мог бы быть свой собственный конвейер, который запускался бы только при обновлении диаграммы, и конвейерам приложений даже не нужно было бы запускать одну команду Helm (при условии, что в Flux CD добавлена ​​поддержка для флаг новой версии приложения при установке / обновлении).

У меня вопрос - почему бы не поддержать оба подхода?

Это именно то, о чем я думаю.

В моем случае «супер версия» - это не диаграмма руля, а другой слой, который просто использует множество диаграмм руля. Для меня одна диаграмма Helm бессмысленна, поскольку она описывает лишь небольшую услугу среди многих других. Только вместе они образуют значимый релиз.
Таким образом, в моем случае «суперверсия» - это сводка всех этих выпусков вместе (так оно и есть на самом деле).

Тем не менее, есть аргумент в пользу наличия самой диаграммы Helm в качестве описательной «суперверсии».

Вернемся к мнению @seeruk : почему бы не поддержать оба

Для текущих дебатов может быть полезно получить посторонний голос. Для небольшого контекста, я использую helm в общей сложности _11 дней_. Я думаю, что это дает мне уникальную перспективу, которую я могу добавить, потому что я не участвовал ни в каком продвинутом обучении. Все, что я почерпнул, получено из документации и экспериментов.

Как я смотрю на шлем

До тех пор, пока я не прочитал текущие дебаты об установке пакетов Helm, а не диаграмм, я полагал, что Helm - это в основном интерфейс для описания связанных ресурсов Kubernetes. Это убеждение происходит в основном из документации Helm, в которой говорится следующее:

Helm устанавливает диаграммы в Kubernetes, создавая новый выпуск для каждой установки. А чтобы найти новые диаграммы, вы можете выполнить поиск в репозиториях диаграмм Helm.

Для контекста в текущей стабильной документации Helm также указано:

Диаграмма - это пакет Helm. Он содержит все определения ресурсов, необходимые для запуска приложения, инструмента или службы внутри кластера Kubernetes. Думайте об этом как о Kubernetes-эквиваленте формулы Homebrew, Apt dpkg или Yum RPM-файле.

Так что теперь есть некоторая путаница! В документации Helm четко сказано, что «диаграмма - это пакет Helm», но если это так, то почему, черт возьми, helm install принимает неупакованные репозитории Chart?

Именно это поведение повлияло на мое текущее представление о том, что такое шлем и как он должен работать:

Helm действует как сопоставитель между структурой того, что_ входит в кластер, и какими свойствами_ у этих вещей.

Итак, теперь вопрос: «Что развертывает Helm?»

Что такое Helm Deploying?

Когда я запускаю helm install release-name ./local_chart я ожидаю, что helm отобразит все шаблоны диаграмм локально с указанными значениями (либо по умолчанию, либо с переопределениями) и отправит обработанные версии в Kubernetes. Я также ожидаю, что Helm сохранит ранее развернутые объекты Kubernetes в случае отката. Эта концепция «коллекции визуализированных шаблонов» (которая содержит некоторые метаданные) является выпуском и является пакетом. Все эти определения ресурсов (даже если они не менялись) должны быть в _состоянии, описанном в пакете_, чтобы выпуск существовал (или был откат).

Исходя из этого, я полагаю, что helm действительно развертывает только пакеты . Кажется, это единственное семантически правильное, что вы можете сказать; однако аргумент о том, как эти пакеты распространяются, кажется основной причиной этих дебатов на практике. В частности, «является ли обновление или изменение версии приложения новым пакетом?»

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

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

Какой шаблон следует использовать?

Это уже высказано Helm: packages .

Учитывая, что этот шаблон является принудительным, даже если он не очевиден на 100%, кажется логически последовательным наличие флага --appVersion . Ответ на вопрос «почему», вероятно, важнее всего остального, поэтому позвольте мне завершить свой вклад этим ответом.

Зачем нужна поддержка --appVersion?

Давайте посмотрим на частный случай развертывания:

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

Что делать этой компании?

1. Создайте две отдельные, почти идентичные диаграммы штурвала, которые отличаются только appVersion ?
2. Использовать одну диаграмму управления, но постоянно обновлять appVersion переключаясь между основными версиями приложения?
3. Заменить appVersion флагом (в настоящее время не поддерживается), ведущим к потенциальной ошибке разработчика в командной строке?
4. Переместить appVersion из Chart.yaml в values.yaml ?

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

Предложение 2 имеет меньше накладных расходов, чем предложение 1, но вносит большую вариативность в диаграмму. Что произойдет, если вы запустите helm install release-name https://remote-repo.com/chart а самая последняя версия диаграммы - это неправильная версия приложения? Упс. Наверное, не лучший подход.

Предложение 3 - это то, что мы сейчас обсуждаем. Мне лично этот вариант не нравится, но только потому, что я считаю, что это неправильное решение проблемы. Делает ли это настраиваемую версию appVersion? Конечно. Но у него также есть та же проблема, с которой вы сталкиваетесь при запуске helm install release-name https://remote-repo/chart : метаданные недолговечны и поддерживаются ТОЛЬКО Helm.

На самом деле я очень шокирован тем, что еще никто не предложил Предложение 4 или что-то в этом роде. Он переводит appVersion в состояние, в котором его можно переопределить (разрешить что-то похожее на helm run ), он может содержаться в пакете, сгенерированном helm package , и действительно раскрывает концепцию версии приложения. из версии диаграммы, сохраняя при этом концепцию appVersion связанную с развертыванием руля (appVersion должна быть где-то правильно?).

Я надеюсь, что это было полезно. 👀 это пиар.

@jrkarnes : в некотором смысле 4) уже был предложен и используется в качестве обходного пути многими людьми (см. здесь https://github.com/helm/helm/pull/5492#issuecomment-517255692). Вы можете использовать что-то подобное в своих шаблонах диаграмм:

{{ default .Values.appVersion .Chart.AppVersion }}

Это позволит вам использовать appVersion в Charts.yaml по умолчанию и заменить его чем-то в Values.yaml (что может быть отменено во время вызовов установки / обновления). Обратной стороной является то, что при выполнении, например, helm ls он покажет вам либо нет, либо неверный appVersion .

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

Я думаю, что мое четвертое предложение было немного неправильно понято. Вместо того, чтобы иметь что-то вроде {{ default .Values.appVersion .Chart.AppVersion}} вы должны использовать {{ .Values.Helm.AppVersion}} а values.yaml содержит appVersion вместо Chart.yaml

@jrkarnes
Вот о чем я сейчас думаю. Мол, почему версию приложения нужно рассматривать как уникальную снежинку. Это значение диаграммы.

Причина этого проста: все является частью инфраструктуры. Итак, у инфра есть версия. Почему две версии?

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

Я подумаю об этом еще немного

@jrkarnes
Вот о чем я сейчас думаю. Мол, почему версию приложения нужно рассматривать как уникальную снежинку. Это значение диаграммы.

Причина этого проста: все является частью инфраструктуры. Итак, у инфра есть версия. Почему две версии?

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

Допустим, у вас есть развернутое приложение, которое ver 4.0.0 запущено на вашей диаграмме с версией ver 1.1.0 . Во время работы вы понимаете, что вам нужно будет запустить задачу cron для этого приложения. Вместо того, чтобы писать объект cronJob и применять его к кластеру, вы понимаете, что другим людям, которые запускают эту диаграмму, вероятно, также понадобится задача cron ... поэтому вы добавляете ее в свою диаграмму. Ваша диаграмма теперь продвинулась до ver 1.2.0 но никаких изменений в приложении, которым управляет диаграмма, не произошло, он по-прежнему находится на ver 4.0.0 .

Обратное также применимо и уже является предметом обсуждения в этом PR.

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

Я подумаю об этом еще немного

Вместо того, чтобы думать о побочном случае или проекции, подумайте о таких вещах, как MySql, который имеет три широко используемых и поддерживаемых версии движка: [5.6, 5.7, 8.0] . Для развертывания экземпляра mysql в кластере у вас всегда будет:

• Pod (ы), запускающие экземпляр MySql выбранной версии
• Служба, которая позволяет разрешать kube-dns для модуля (или модулей, если они запущены в HA).
• PV, в которые модули должны записывать свои данные, с сопутствующими PVC.

Схема развертывания MySql 5.6, 5.7 или 8.0 должна быть относительно одинаковой для всех версий Engine (приложения). Единственная реальная разница - это версия приложения и образ докера (который, вероятно, имеет семантические теги в соответствии с версией движка).

Я понимаю, что вы имеете в виду, задаваясь вопросом о «необходимости» версии приложения. Я думаю, это сводится к удобству разработчика или эксплуатации при запуске helm ls или helm inspect .

+1 к последнему посту @jrkarnes . Сохранение версий диаграммы и приложения как отдельных концепций имеет большое значение именно потому, что версия диаграммы - это «инфраструктурная версия».

Если я публикую диаграмму для использования другими, она становится частью инфраструктуры для проектов, которые зависят от нее. Однако, если я никогда не собираюсь использовать свое приложение для других, все, что меня волнует, - это время от времени пересматривать свою собственную версию диаграммы, когда сама диаграмма изменяется , но в противном случае мне просто нужно, чтобы моя версия приложения соответствовала CI. / CD выход. В этой разновидности диаграммы использования частота вращения меняется относительно редко, однако версия приложения повышается при каждом возникновении CI. Мое репозиторий кода поддерживает взаимосвязь между кодом и инфра-версией, которая применима для этой версии кода для запуска. Другими словами, вместо отката моего развертывания с помощью helm install last-known-good-chart-version я просто перезапускаю конвейер компакт-диска с помощью указателя. до последнего известного исправного идентификатора фиксации.

@iorlas Я прочитал ваше предложение по helm run и у меня нет проблем с этим. Хотя я считаю, что дихотомия установка / запуск необязательна , но если она позволяет разработчикам руля легко сделать изменяемую версию приложения, я с этим согласен. :)

@iorlas У вас была возможность подумать, что бы вы хотели сделать с этим предложением?

Я не думаю, что понимаю, как работает обходной путь, связанный с {{ default .Values.appVersion .Chart.AppVersion}} . Я получаю такую ​​ошибку:

Ошибка: ошибка преобразования YAML в JSON: yaml: недопустимый ключ карты: map [interface {}] interface {} {". Values.appVersion | default \" 0.0.1 \ "": interface {} (nil)} [

Вот мой Chart.yaml:

name: demo-helm
version: 0.0.1
appVersion: {{ .Values.appVersion | default "0.0.1" }}
home: http://example.com
description: Demo Helm

@IRobL Вам нужно поместить этот фрагмент в templates/deployment.yaml , где используется версия. Такие файлы, как values.yaml , не рассматриваются как шаблоны.

@jrkarnes Я не сопровождаю, так что последнее слово, я думаю, будет за других ребят. Но так или иначе, последние несколько недель я был очень занят. На следующей неделе я пересмотрю наш текущий подход к управлению helm и его packages .

Мы используем подход, который я описал:

• Helm Chart является частью репозитория приложения
• Сборка приложения производит:
  
  
  
  • Образ докера -> реестр докеров
  
  
  • Статические файлы -> Сервис CDN
  
  
  • Пакет Helm -> Хранилище CI
  
  
• Итак, пакет Helm - это главный артефакт, связывающий воедино все артефакты приложения.
• При развертывании install сказал пакет

Текущие проблемы:

• Сложность процесса сборки.
  
  
  
  • Вместо образа докера и статических файлов создается дополнительный файл ( helm package )
  
  
  • Каковы основные причины, по которым нам нужно что-то помимо полученного файла go build / make install ?
  
  
  • Какова цена?
  
  
  • Зачем применять?
  
  
  • Когда подавать заявку?
  
  
• Продолжительность сборки
  
  
  
  • Даже если нам не нужно его развертывать, мы все равно теряем время и деньги. 2-5 секунд. Немного, но бессмысленная работа бессмысленна.
  
  
• Сложность обновления шаблонов инфраструктуры
  
  
  
  • При обновлении диаграммы значения также должны быть обновлены.
  
  
  • Диаграмма - это одно репо, значения - другое, каждое обновление значений означает небольшую головную боль
  
  

Такая переоценка может привести к дополнительным упрощениям и идеям. Посмотрим :)
Я пришлю обновление ближе к следующей пятнице.

Ах, теперь я понимаю, почему этот трюк не сработает, когда вы мне на это указали, спасибо. Вот трюк, который, как мне кажется, отлично подходит для многих людей, использующих Helm 2.x, при условии, что вам удобно оборачивать свой инструмент Helm такими накладными частями:

APP_VERSION=0.0.7
sed -i.bak "s/^appVersion:.*\\\$/appVersion: $APP_VERSION/" helm/Chart.yaml
helm install --name helm_demo helm/

@IRobL

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

Когда gitlab был в зачаточном состоянии и не имел поддержки Helm, мы буквально вводили значения для целей замены в созданном вручную файле манифеста.

Это плохая практика для чего-то вроде этого, и я настоятельно рекомендую вам отказаться от этого, если это вообще возможно.

7 октября 2019 г. в 15:33 IRobL [email protected] написал:

Ах, теперь я понимаю, почему этот трюк не сработает, когда вы мне на это указали, спасибо. Вот трюк, который, как мне кажется, отлично подходит для многих людей, использующих Helm 2.x, при условии, что вам удобно оборачивать свой инструмент Helm такими накладными частями:

APP_VERSION = 0.0.7
sed -i.bak "s / ^ a ppVersion :. * \\ $ / appVersion: $ APP_VERSION /" helm / Chart.yaml
helm install --name helm_demo helm /
-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub или отключите обсуждение.

@jrkarnes , когда вы говорите о плохой практике, вы говорите, что необходимость заключать команду helm сценарий нежелательна? Если так, то я полностью согласен. Я не говорю, что вообще против добавления флага --app-version ; Напротив, я думаю, что это было бы очень удобное дополнение к штурвалу. Очевидно, исходя из этого PR, я не единственный, кто использует helm и хочет, чтобы переменная appVersion соответствовала фактической развертываемой сборке. Я занимаюсь разработкой повторно используемой библиотеки конвейера сборки, которая объединяет различные инструменты сборки вместе для создания воспроизводимых сборок - это обычная практика для крупных технологических организаций. В моем случае библиотека конвейера создает контейнеры докеров, публикует их и, в конечном итоге, развертывает их через helm из конвейера сборки приложения (например, рассмотрим версию приложения 1.0.1-pr-3.1 для первой сборки третьего PR приложение, которое потенциально является предварительным выпуском версии 1.0.1).

Даже после того, как эта проблема будет решена в библиотеке конвейера сборки моей компании, мне определенно будет удобнее иметь встроенный в Helm переключатель --app-version ; это просто кажется более гибким способом обработки развертываний. Я имею в виду, почему внешняя система или инженер должны заходить в файл диаграммы и обновлять yaml перед каждым развертыванием, если это можно автоматизировать с помощью платформы сборки, которая не может случайно испортить числа? С моей точки зрения, моя организация должна полностью отказаться от функциональности appVersion или добавить «небрежную» работу sed код нашей библиотеки конвейера, поэтому я подумал, что поделюсь ею для кто-нибудь еще, кто решал эту проблему.

@IRobL
В общем, любая утилита должна быть самодостаточной на собственном уровне абстракции: она должна абстрагироваться от проблемы, которую решает, предоставляя достаточный API. Хельм не исключение. Итак, если вам нужно настроить его поведение, вам нужно сначала спросить: соответствует ли он архитектуре, принципам дизайна или, может быть, я что-то упускаю?

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

И вы правы насчет флага app-version . Вы должны предоставить его, тогда Helm должен справиться со всем самостоятельно.

Могу я задать вам вопрос? Как вы используете Helm в своем продукте? Когда вы используете helm install ? Как именно вы им пользуетесь? Вы рассматривали возможность использования helm package ?

Вчера вечером я еще раз взглянул на helm package . Я на самом деле не был продан. sed существует уже очень давно и очень стабильно. Все эти tiller / package / install подкоманды относительно новые и менее стабильные. Чтобы лучше сформулировать свою точку зрения, несколько месяцев назад я решил, что «конечно, Tiller может сработать», хотя я видел чей-то плагин, который обходился без Tiller. Я смотрел на плагин как на что-то менее популярное, но с тех пор я сам себя ругал. Если бы я доверял плагину, я был бы в гораздо лучшем положении, чем сейчас. Сопровождающие в Helm даже подтвердили, что согласны с тем, что это был неподходящий проект и он будет удален в будущих выпусках.

Я думаю, что с моей стороны было бы ошибкой использовать helm package для выполнения этой простой операции sed. В любом случае, каков ваш вариант использования для package ? Мне кажется, что вся концепция helm package упускает из виду суть выпусков Web 2.0 / контроля версий за счет упаковки в двоичный zip-архив, в первую очередь, когда современные технологические группы используют возможности тегов для достижения того же процесса. но более компактным и поддающимся проверке способом.

Для моего варианта использования я разрешаю разработчикам кодифицировать свои контейнерные приложения и развертывать их в удобном для обслуживания способе, поэтому минимизация накладных расходов (системные администраторы / администраторы, избыточное управление артефактами выпуска и т. Д.) Имеет первостепенное значение. Я думаю, что мое использование более точно соответствует философии Unix, чтобы решить использовать инструмент для того, что он делает лучше всего, а затем переключиться на другие инструменты (и т. Д. Sed), где это необходимо. Я не думаю, что вы когда-нибудь найдете один инструмент, который бы все делал идеально за вас, но если вас устраивает ваш текущий рабочий процесс, не позволяйте мне отговаривать вас от следования вашей собственной философии.

@IRobL

когда вы говорите «плохая практика», вы говорите, что необходимость заключать команду helm в скрипт нежелательна?

да. Это именно так.

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

Именно этим мы и занимаемся.

Даже после того, как эта проблема будет решена в библиотеке конвейера сборки моей компании, мне определенно будет удобнее иметь переключатель --app-version, встроенный в Helm.

Я бы пошел дальше и сказал, что наличие appVersion как свойства файла Chart.yaml вероятно, неверно. Если значение можно изменить на лету, оно не должно быть в том, что считается «неизменяемым набором значений». Я полагаю, что защищал то же самое в предыдущем комментарии.

Все эти подкоманды tiller / package / install относительно новы и менее стабильны.

FWIW, Tiller не будет использоваться в Helm 3. Вы упомянули об этом позже в своем посте; однако я просто повторяю это, потому что это показывает, что синтаксис helm package для создания «двоичного файла kubernetes» и его отправки в Tiller , вероятно, является плохой практикой.

Я думаю, что с моей стороны было бы ошибкой использовать пакет helm для выполнения этой простой операции sed. В любом случае, каков ваш вариант использования пакета?

Я, вероятно, смогу поддержать команду Helm в этом вопросе. Я чувствую, что за штурвалом я помогал разработчикам приложений указывать, как правильно запускать их приложения изнутри Kubernetes. Вот почему поставщики приложений запускают свои собственные репозитории Helm, которые вы можете добавить, чтобы загрузить определенную версию их развертывания. Команда Helm, вероятно, увидела, что код приложения и код инфраструктуры взаимосвязаны, потому что их предполагаемые целевые производственные группы не собирались использовать Helm в повседневных рабочих процессах, как это делаем мы в CI / CD. Пример: в среднем мы используем helm upgrade 130 раз в день. Я не думаю, что это было когда-либо предполагаемое использование.

Вероятно, гораздо чаще люди говорили: «Я просто хочу установить mysql в кубернеты», и helm был (относительно) простым способом сделать это для людей, которые мало знали о кубернетах и ​​просто играли с ним.

Таким образом, helm package конечном итоге предназначались для _этой аудитории_. Этот инструмент определенно находит гораздо большее применение в сферах, в которых команда (я думаю) либо не верила, что возьмется за инструмент, либо никогда не намеревалась использовать его так, как они есть.

Я думаю, что мое использование более точно соответствует философии Unix, чтобы решить использовать инструмент для того, что он делает лучше всего, а затем переключиться на другие инструменты (и т. Д. Sed), где это необходимо.

Я в основном отношусь к Хелму как к awk с кучей kubectl apply -f s после него. Просто гораздо проще иметь автоматизированный инструмент, который позаботится о значениях, чтобы избежать человеческой ошибки.

Похоже, у нас с вами много общих ценностей и, возможно, мы делаем много похожих вещей.

@IRobL

культиватор

Для меня tiller неприемлемо. Поскольку он добавляет еще одну точку воздействия, дополнительные риски безопасности и, что наиболее важно, ничего не делает, кроме создания еще одного способа применения файлов yaml, но с другим API. Tiller был разработан для обеспечения безопасности, согласования процесса применения пакетов Helm, но с таким большим количеством рисков, дополнительным программным обеспечением (и контролем версий!). Вот почему Хелм 3-й его не использует.

Я думаю, что с моей стороны было бы ошибкой использовать пакет helm для выполнения этой простой операции sed.

Я думаю, вы упускаете мою точку зрения. Дай мне попробовать снова. Для чего сделан sed ? Преобразовать поток данных. Он должен абстрагироваться от проблемы преобразований, давая вам API и результат для любого заданного ввода.

Что, если вы создали сценарий, в котором ваша команда sed не работает (т.е. у вас есть ошибка в регулярном выражении)? Итак, вы сделали вывод, не работает. Попытаетесь ли вы понять, почему sed не работает сам по себе, или вы бы добавили один дополнительный канал с помощью сценария perl?

То же самое происходит с каждым решением: оно должно предоставлять API, принимать входные и выходные данные, абстрагируя одну проблему. Вы знаете, в стиле Unix.

Проецируемый на Helm, он предназначен для версии вашего релиза и внедрения его в K8s. Это позволяет настраивать конфигурацию с помощью шаблонов. Итак, вы наблюдаете проблему, вам нужно предоставить версию. Helm предоставляет простой механизм управления версиями и простой способ настройки работы вашей сборки. Итак, почему бы не попытаться понять, как это работает, вместо того, чтобы добавить обходной путь с дополнительным программным обеспечением?

@jrkarnes

Да, мы оба приближаемся к штурвалу, имея в виду схожие интересы. Я действительно не осознавал, что корень команды package был переплетен с ошибками, вымощенными Тиллером, спасибо за то, что поделились со мной этими идеями!

Я на самом деле просматривал историю того, почему эта функция не просто добавлена, и видел два аргумента относительно того, почему они не могут добавить эту функцию, первый заключался в том, что, поскольку она уже определена в package они также не должны также необходимо определить его в install / upgrade . Я сочувствую этому, это звучит как проблема технического долга. Не существует общедоступного программного обеспечения, не имеющего технического долга. Другая причина заключалась в том, что файл Chart.yml был метаданными и не должен обновляться. Это показалось мне очень странным ... поскольку люди разрабатывают диаграммы управления, они наверняка обновляют этот файл вручную, когда что-то меняется, и поэтому он сам по себе не является неизменяемым. Мне проще рассматривать файл Chart.yml как способ подачи параметров в двоичный файл helm, поскольку он создает объекты развертывания, которые, напротив, фактически неизменяемы.

Какая у вас платформа для сборки, кстати? Код конвейера, который я пишу, написан для Jenkins как глобальная библиотека конвейеров.

@IRobL Основная проблема: вы смотрите на Helm как на сценарий развертывания. Но Хельм не такой. Helm - это слой абстракции. Helm берет все ваши артефакты и применяет их как единое целое к K8s как платформе.

Хелм - упаковщик. Helm разработан для упрощения развертывания. Он создает «установщик» из ваших артефактов, так что вы можете «установить» его на свою ОС - K8s.

app-version в install имеет ничего общего с техническим долгом. Это совсем не нужно, если вы хотите install или upgrade . То же самое - Chart.yml . Его вообще не следует изменять, так как это файл конфигурации по умолчанию, который содержит версию действительной диаграммы, но диаграмма не является вашим программным обеспечением. Вы просто неправильно это используете.

С этой точки зрения, почему бы вам не рассмотреть возможность использования package ? Вам это кажется слишком сложным или как?

Некоторое время я не был в курсе этой проблемы, но я видел, как несколько раз возникали подобные вопросы:

Хелм - упаковщик. Helm разработан для упрощения развертывания. Он создает «установщик» из ваших артефактов, так что вы можете «установить» его на свою ОС - K8s.

По сути, Helm никоим образом не создает установщик. Он не создает «бинарный». Он не создает ничего похожего на файл ".deb" или что-то подобное. Он создает архив некоторых шаблонов манифестов Kubernetes с некоторыми значениями по умолчанию и / или предустановленными значениями. Ваше актуальное программное обеспечение не находится в этой Helm Chart. Он не упакован с этим. Его неизменность не гарантируется.

Я думаю, будет справедливо сказать, что в большинстве случаев ваша Helm Chart изменит на _lot_ меньше, чем программное обеспечение, которое вы развертываете через вашу Chart.

Это основная причина (по крайней мере, IMO) для того, чтобы --app-version был доступен на helm install и helm upgrade . Зачем вам снова упаковывать график, если буквально ничего не изменилось?

Я вижу Helm Chart как версионное описание манифестов Kubernetes, описывающее набор компонентов Kubernetes, которые будут успешно запускать приложение, и это все, что я вижу в этом. Если эти инструкции нужно изменить, тогда я хотел бы обновить свою диаграмму - не каждый раз, когда мое приложение изменяется, и мне нужно только обновить версию изображения (которую вы часто устанавливаете через значения в любом случае).

Взгляните, например, на Flux и на то, как работает их Helm Operator. Вы можете настроить автоматическое обновление значения тега изображения - при этом обновляется не диаграмма, а только развертываемый тег изображения.

Он создает архив некоторых шаблонов манифестов Kubernetes с некоторыми значениями по умолчанию и / или предустановленными значениями.

Но файл deb - это тот же набор файлов конфигурации, команд, манифестов и / или предустановленных значений. То же, что установщик MSI или даже, что ближе, ebuild в системе пакетов gento emerge. То же, что и пакеты Brew.

Так что же такое Helm, как не менеджер пакетов для K8s? Какую разницу вы видите?

Его неизменность не гарантируется.

Почему нет? Если вы изменяете пакет после генерации пакета, это неправильно. Если вы предоставляете дополнительные параметры во время процесса install/upgrade , это предусмотрено, как и во всех системах упаковки.

Я вижу Helm Chart как версионное описание манифестов Kubernetes.

Один у вас уже есть - GIT. Итак, зачем вам шлем?

Я думаю, будет справедливо сказать, что в большинстве случаев ваш Helm Chart будет меняться намного меньше, чем программное обеспечение, которое вы развертываете с помощью своего Chart.
Это основная причина (по крайней мере, IMO) для --app-version быть доступной при установке и обновлении Helm. Зачем вам снова упаковывать график, если буквально ничего не изменилось?

В этом дизайне appVersion не следует рассматривать как атрибут сборки Helm Package. Его следует рассматривать как параметр конфигурации в значениях.

Взгляните, например, на Flux и на то, как работает их Helm Operator. Вы можете настроить автоматическое обновление значения тега изображения - при этом обновляется не диаграмма, а только развертываемый тег изображения.

В этом случае вы потеряете связь между манифестами инфраструктуры приложения и версией приложения. Поскольку изменение тега изображения не приведет к новому обновлению руля (поправьте меня, если ребята из Flux делают это по-другому). В этом случае у вас будет Helm в качестве шаблона конфигурации. В этом случае вам вообще не нужно --app-version .

Но файл deb - это тот же набор файлов конфигурации, команд, манифестов и / или предустановленных значений. То же, что установщик MSI или даже, что ближе, ebuild в системе пакетов gento emerge. То же, что и пакеты Brew.

В вашем описании пакетов .deb и .msi отсутствует один ключевой компонент - фактическая установка. Если вы посмотрите содержимое файла .deb , вы найдете встроенное программное обеспечение - _THE_ программное обеспечение, которое будет установлено. Вообще говоря (всегда в случае .deb ?) Развертываемое приложение внутренне связано и является частью этого пакета (не в случае с brew).

Пакеты для варки разные, и их нельзя сравнивать одинаково. Brew на самом деле намного больше похож на Helm в настоящее время, поскольку это просто инструкции о том, как его следует установить и откуда следует загружать исходный код / ​​пакет.

Чтобы быть здесь абсолютно ясным; Helm Chart _ внутренне не привязан к конкретной версии приложения_ и не содержит артефакта, который развертывается (например, образ Docker). Он содержит только ссылку на него, и значение, стоящее за этой ссылкой, может даже измениться (то есть вы можете нажать на тот же тег Docker, если хотите). Итак, несмотря ни на что, Helm Chart не является упакованной версией приложения, и он также не связан строго с конкретной версией приложения.

Вам нужно только пойти посмотреть репо стабильных графиков для примера. Сколько приложений позволяют переопределить используемое изображение с помощью значений? (Много_)

Так что же такое Helm, как не менеджер пакетов для K8s? Какую разницу вы видите?

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

Все это возвращается к моей основной мысли - если эти манифесты меняются или шаблон должен быть изменен для этих манифестов по какой-либо причине, тогда _that_ это когда диаграмма Helm действительно должна быть изменена.

Основная сложность, которую я вижу, заключается в том, что есть 2 варианта использования:

• Развертывание сторонних приложений.
• Развертывание сторонних приложений.

В случае сторонних приложений, как потребителю Helm, желательно, чтобы диаграмма Helm выпускалась с каждой новой версией приложения. Одно из ключевых различий здесь заключается в частоте релизов. Вероятно, что сторонняя Helm Chart для чего-то вроде MySQL или чего-то еще не будет меняться несколько раз в день. В этом случае вы также не хотите случайно использовать старую версию диаграммы с новой версией программного обеспечения - ошибку, которую намного проще сделать с программным обеспечением и диаграммами, которые вы не написали сами.

В случае приложений сторонних производителей у вас может быть стандартный способ развертывания класса приложений. Например, в Icelolly мы пишем и развертываем наши сервисы Go практически одинаково. С этой целью мы фактически можем использовать одну диаграмму прямо сейчас для всех наших сервисов Go, развернутых в Kubernetes (сейчас мы используем обходной путь helm package ). Если подход к развертыванию наших собственных приложений изменится, мы обновим диаграмму. Мы версируем нашу диаграмму с помощью SemVer, поэтому приложения, которые не обновляются, не будут затронуты, пока мы не захотим их обновить.

Просто на этой заметке; наша диаграмма go-service последний раз обновлялась около месяца назад. За это время у нас, вероятно, были от десятков до сотен развертываний - и все это без изменения диаграммы.

В одном случае вам просто нужна простота. В другом случае вам нужен контроль и простота управления.

В этом случае вы потеряете связь между манифестами инфраструктуры приложения и версией приложения. Поскольку изменение тега изображения не приведет к новому обновлению руля (поправьте меня, если ребята из Flux делают это по-другому). В этом случае у вас будет Helm в качестве шаблона конфигурации. В этом случае вам вообще не нужна --app-version.

Flux фактически изменит значения, которые он использует для обновления диаграммы, а затем запустит обновление с новым значением изображения. Ваша точка зрения о потере связи между манифестами инфраструктуры и версией приложения остается в силе. Я утверждаю, что это действительно желательно в некоторых случаях использования. Вы правы, но в этом случае мне не нужен --app-version , он не будет использоваться, потому что его сейчас нет. Если бы это было так, возможно, Flux мог бы это использовать. В таком случае это действительно было бы полезно.

helm list - полезная команда. Возможность видеть, какие версии приложений развернуты, действительно по-прежнему полезна. Для наших приложений, установленных в настоящее время через Helm с подходом helm package мы устанавливаем только версию приложения (через --app-version на helm package ) так, чтобы результат helm list был полезный. Вот почему, если бы мы могли установить его на helm install|upgrade это было бы проще для нас. Нам не пришлось бы извлекать диаграмму и переупаковывать ее только для того, чтобы изменить версию.

Фактически, helm list и обработка откатов, вероятно, единственные причины, по которым мы вообще используем Helm для стороннего программного обеспечения.

В вашем описании пакетов .deb и .msi отсутствует один ключевой компонент - фактическая установка.

«Установка» - это процесс настройки необходимых средств (папок, конфигураций, двоичных файлов, выборки баз данных, обновления / миграции данных) на целевой платформе.

Все это делает deb. То же самое и с пакетом Helm. Что вы имеете в виду, что пакет Helm "не установлен на самом деле"?

Если вы посмотрите содержимое файла .deb, вы найдете встроенное программное обеспечение - программное обеспечение, которое будет установлено.

Ложь. Иногда вы найдете само программное обеспечение. Иногда можно встретить какие-то программные части. Иногда вы не найдете ничего, кроме набора скриптов для загрузки такого программного обеспечения. Итак, ключевой момент здесь - это не имеет значения , поскольку Linux и K8s являются платформами для размещения данного приложения, принимающими один универсальный формат приложения. А имена образов, параметры конфигурации - это части пакета.

Brew на самом деле намного больше похож на Helm в настоящее время, поскольку это просто инструкции о том, как его следует установить и откуда следует загружать исходный код / ​​пакет.

Точно. Вы пытаетесь убедить меня, что Brew не менеджер пакетов?

Чтобы быть здесь абсолютно ясным; Helm Chart _ внутренне не привязан к конкретной версии приложения ...
Сколько приложений позволяют переопределить используемое изображение с помощью значений? (Много)

Вы абсолютно правы. Helm может быть не более чем удобным движком для шаблонов k8s. У меня нет проблем с существованием такого программного обеспечения: это немного помогает, современную практику доставки не меняет.

Проблема в том, что Helm - это больше, чем движок для создания шаблонов. Это менеджер по упаковке со всеми преимуществами и недостатками. А в экосистеме, где существует менеджер пакетов, плохая практика - иметь какой-либо менеджер для управления другими пакетами. Хуже того - работает без диспетчера пакетов.

Я вижу причины, по которым версия приложения является аргументом пакета для этих пакетов. И я вижу причины, по которым вы и все вы, ребята, не должны делать пакеты. Проблема в том, что это устаревший, сложный и сложный в управлении подход. Забавно, стоимость небольшая, но приобретение у нее офигенное.

Я утверждаю, что это действительно желательно в некоторых случаях использования.

Ага, это центральный вопрос: желательно ли это для какого-либо продукта?

Ваш аргумент состоит в том, что Helm Chart редко меняется, так почему мы должны собирать ее вместе в каждом выпуске. Я согласен с вами, это кажется лишним. Но в любом случае мы по-прежнему упаковываем некоторые старые исходные файлы, старые вспомогательные средства (если Helm состоит из нескольких приложений), старые конфигурации, старый файл Dockerfile.

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

В те времена у нас был максимально понятный механизм доставки: загружать по FTP только измененные файлы. Теперь у нас так много всего. Нам нужно решить, что хорошо, почему это хорошо, кому следует этим пользоваться. Я не уверен, что был бы счастлив, если бы Хелм работал с обоими подходами одновременно - слишком сложно.

Развертывание сторонних приложений.

Я был бы оооочень счастлив, если бы смог установить любую версию PSQL / MySQL, используя исключительно Helm Chart. Было бы намного проще поддерживать устаревшие проекты, вводить инфраструктуру для новичков. Получать уведомления об обновлениях диаграмм стало еще проще. Почему у нас так много файлов tar.gz для каждого выпуска двоичных файлов, но не может быть такого же набора файлов tar.gz для пакетов Helm?

@iorlas Я только что прочитал это и отвергнутый PR, и вы сделали несколько очень хороших замечаний. Вы убедили меня, что мне нужно начать упаковывать свои диаграммы управления как еще один артефакт моей сборки / выпуска.

Но я хотел бы упомянуть, что я даже не знал, что у helm есть пакетная команда, и думаю, я не один такой. Вероятно, это потому, что так просто установить диаграмму из исходного каталога, но также документация на самом деле не продает концепцию и даже не объясняет ее подробно.

Команда package явно задокументирована, но в руководстве по быстрому запуску есть только пара очень общих упоминаний пакетов, на самом деле слово пакет часто встречается в быстром запуске, но в основном речь идет о том, как установить Helm и различные пакеты ОС. . Упаковка также не упоминается в передовых практиках, и я думаю, что нужно указать, что такое упаковка и почему она полезна. Я также проверил документы v3, которые имеют немного другую структуру, но также кажутся скудными, предлагая пользователям упаковать свои диаграммы.

Обычно я бы хотел отправить PR, а не просто так, как будто я на что-то жалуюсь, но я не уверен, что происходит с изменениями документации 3.0.

@jonstelly В документации определенно есть пробел. Даже я сначала подумал, что --app-version - это хорошо, но потом, хотя это просто не могло быть пропущено без причины.

Документы определенно нуждаются в пояснении и описании общих проблем. Затем, введение в цикл разработки Helm. Но я считаю, что команда занята третьей версией. И я сейчас тоже слишком занят :(

«Установка» - это процесс настройки необходимых средств (папок, конфигураций, двоичных файлов, выборки баз данных, обновления / миграции данных) на целевой платформе.

Все это делает deb. То же самое и с пакетом Helm. Что вы имеете в виду, что пакет Helm "не установлен на самом деле"?

Я не имею в виду, что Helm Chart не установлен - все, что я говорю, это то, что Helm Chart не содержит фактического приложения, которое вы развертываете. Образ Docker не упакован в Helm Chart. Kubernetes извлекает его из внешнего источника.

Ложь. Иногда вы найдете само программное обеспечение. Иногда можно встретить какие-то программные части. Иногда вы не найдете ничего, кроме набора скриптов для загрузки такого программного обеспечения. Итак, ключевой момент здесь - это не имеет значения, поскольку Linux и K8s являются платформами для размещения данного приложения, принимающими один универсальный формат приложения. А имена образов, параметры конфигурации - это части пакета.

Насколько мне известно, на самом деле вы здесь неправы. Файл .deb - это архив AR. Вы можете извлечь его и просмотреть содержимое, и в конечном итоге это некоторые метаданные и некоторые файлы. Теоретически .deb файлы могут содержать исправления, но часто не содержат. Если файл .deb содержит сценарий для загрузки программного обеспечения, это будет означать, что это сценарий, который устанавливается файлом .deb , а не само программное обеспечение. Это похоже на установку установщика.

Если у вас есть пример части программного обеспечения Linux, упакованной в .deb куда идет .deb и загружает программное обеспечение для установки как часть процесса установки файла .deb , то мне очень хотелось бы это увидеть - поскольку я буквально никогда не сталкивался с этим за многие годы использования Linux.

Точно. Вы пытаетесь убедить меня, что Brew не менеджер пакетов?

Нет. Все, что я говорю, это то, что, как и Helm, сценарии, предоставляемые для установки программного обеспечения через Brew, являются всего лишь сценариями. Приложения создаются, упаковываются и распространяются отдельно и втягиваются этими сценариями. Это не делает Brew менее похожим на пакетный менеджер, точно так же, как то, что я сказал, не делает Helm менее похожим на пакетный менеджер Kubernetes. Однако суть проблемы не в этом, мы не обсуждаем, является ли Helm менеджером пакетов или нет, мы пытаемся решить, следует ли добавлять флаг --app-version к helm install|upgrade чтобы облегчить общий вариант использования.

Я вижу причины, по которым версия приложения является аргументом пакета для этих пакетов. И я вижу причины, по которым вы и все вы, ребята, не должны делать пакеты. Проблема в том, что это устаревший, сложный и сложный в управлении подход. Забавно, стоимость небольшая, но приобретение у нее офигенное.

Извините, я не понимаю, что вы имеете в виду. Что устарело / сложно / труднее управлять?

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

Опять же, разница в основном в том, что все те вещи, которые вы упомянули, внутренне связаны. Для запуска приложения вам понадобится весь исходный код, а не только то, что изменилось. Вы не упаковываете Dockerfile, поэтому не знаете, о чем идет речь, но вы часто будете использовать один и тот же Dockerfile, не меняя его, для создания новых версий образов (я имею в виду, зачем беспокоиться об автоматизации, если вам приходилось что-то менять вручную каждый раз). время, правда?). С помощью всего этого вы создаете что-то, что инкапсулирует все, что вам нужно, чтобы его можно было развернуть изолированно. Таким образом, вы можете делать такие вещи, как запуск нового узла и развертывание на нем так же, как и на существующем узле, и т. Д.

Есть много преимуществ, как я уверен, вы уже знаете, по сравнению со старой загрузкой через FTP.

Во всяком случае, это все кстати. Я думаю, что в конечном итоге, как я уже упоминал, на мой взгляд, все это сводится к следующему; Сопровождающие Helm хотят включить этот другой вариант использования или затруднить его использование людьми таким образом? В конце концов, в любом случае это не действительно большая разница. Для меня было бы хорошо, если бы мне не пришлось упаковывать нашу внутреннюю диаграмму, которая редко меняется, в каждой сборке только для того, чтобы установить версию приложения, которая снова используется только для отображения текущей версии в списке. Честно говоря, я сомневался, что Helm - это правильный подход для сторонних приложений.

Образ Docker не упакован в Helm Chart

Собственно, я бы так и хотел. Но не сейчас. Мое видение таково, что K8s будет / должен быть платформой, которая будет включать Helm (так что Helm не будет) в качестве API для установки пакетов: вам нужно будет упаковать свои материалы в архив и установить его. Вернемся к простоте файлов deb, но с надлежащей изоляцией и ресурсами k8s как гражданам первого класса.

Файл .deb - это архив AR.
Вы можете извлечь его и посмотреть содержимое
и в конечном итоге это какие-то метаданные
и некоторые файлы

Как .... пакет Helm!

Если у вас есть ... .deb там, где находится .deb, и загружает программное обеспечение для установки как часть процесса установки файла .deb ...
Это похоже на установку установщика. ...

Да, это будет похоже на установщик, у которого есть установщик внутри. Забавно, правда? Я бы использовал один артефакт, если это возможно , если этого будет достаточно для установки экземпляра приложения. Но у нас разное программное обеспечение, разные источники истины, иногда даже удобно иметь несколько источников.

• Brew имеет YAML как пакет, но извлекает двоичные файлы из удаленного хранилища.
• В Emerge (gentoo) есть определение ebuild, которое загружает даже клоны git.

Debian пытается упаковать все внутри. И это правильно, если возможно. Но чтобы доказать свою точку зрения, подойдут и

Но, пожалуйста, не упускайте главного: это не имеет значения ! Даже пустой пакет, внутри которого есть только ссылка, является пакетом. Может быть, вы согласитесь с другим термином, установщик?

Я говорю, что, как и в случае с Helm, скрипты, предоставляемые для установки программного обеспечения через Brew, - это всего лишь скрипты.
Приложения создаются, упаковываются и распространяются отдельно и втягиваются этими скриптами.

И у всех нас один и тот же конвейер - для создания образа докера.

мы пытаемся решить, следует ли добавлять флаг --app-version в helm install | upgrade, чтобы упростить общий вариант использования.

Это ключ. Но как мы можем решить? Нам следует задать два вопроса:

• Является ли это возможным? да
• Это правильно? Да? Нет?

Если есть люди, которые что-то делают, значит ли это, что это хорошо? Чтобы добиться прогресса, нам нужно все подвергать сомнению.

Извините, я не понимаю, что вы имеете в виду. Что устарело / сложно / труднее управлять?

пусть проект на Brew, так как Brew действительно близок к Helm и уже широко, успешно используется. Вы можете проецировать на Gentroo Ebuilds или deb, картинка не изменится.

• Устаревший. Когда в последний раз вам приходилось устанавливать MySQL / PSQL вручную? Почему мы от него перешли? Эти причины, приятель.
• Сложный. Это одно из «почему»: вам нужно настроить инфраструктуру самостоятельно, вам нужно знать, какая из них лучше всего работает с какими версиями программного обеспечения. Иногда вам нужно настроить инфраструктуру для запуска определенной версии программного обеспечения. Зачем беспокоиться? Почему вы не делегируете весь вопрос?
• Сложнее управлять. Вам нужно будет управлять как инфраструктурой, так и версиями приложений, если у вас может быть только один артефакт. Зачем усложнять себе жизнь?

Извините, сейчас как-то лень описывать все варианты использования, такие как чистый откат, изящные обновления, в любом случае это основные бонусы.

Опять же, разница в основном в том, что все те вещи, которые вы упомянули, внутренне связаны.

Не всегда. Например, образ докера может иметь SSR BE и ссылку на CDN.

Dockerfile, поэтому не уверен, о чем идет речь, но вы часто будете использовать один и тот же файл Docker, не меняя его для создания новых версий образов (я имею в виду, зачем беспокоиться об автоматизации, если вам приходилось что-то менять каждый раз вручную, верно?).

В этом-то и дело. Даже если Dockerfile не изменен, вы создаете новый образ. Если ваш исходный код не изменился, но Dockerfile изменился, вы создаете новый образ. Итак, в двух словах, Dockerfile - это тоже пакет. То же самое и с Хельмом. Вы так не думаете?

С помощью всего этого вы создаете что-то, что инкапсулирует все, что вам нужно, чтобы его можно было развернуть изолированно. Таким образом, вы можете делать такие вещи, как запуск нового узла и развертывание на нем так же, как и на существующем узле, и т. Д.

Но оказывается, что образа докера недостаточно для запуска приложения. Нам нужен экземпляр конфигурации, нам нужны определения сервисов. Почему бы не упаковать все это?

В конце концов, это не большая разница.

Я верю, что это так. Может быть, это не так уж важно для кодовой базы, но это остановит эволюцию контейнеризации.

Образ Docker не упакован в Helm Chart

Само изображение не упаковано, но ссылка (читается как: булавка) есть. Конечно, мы можем быть педантичными и зацикливаться на том, включено ли буквальное изображение разного размера (от МБ до ГБ) в артефакт helm package (спойлер: это не так), но суть утверждения «Данная версия кода приложения включена в пакет helm» по-прежнему является в основном правильным. Неважно, хотите ли вы увлечься вопросом как .

Возвращаясь к стране примеров, предположим, что у вас есть приложение, которое вы внутренне версировали как 1.9.9 работающее на диаграмме с версией 1.2.5 . Чтобы не было путаницы, образ Docker для контейнера приложения - fakeshaA .

Ваша команда решает, что в версии 2.0.0 вашего приложения будет версия файла с локальной файловой системой, на которую вы раньше ссылались через HTTP. Причина этого не важна, но последствия для вас довольно серьезны. Теперь вам нужны pv и pvc для ваших развертываний, чтобы эти теперь локальные файлы не терялись между обновлениями. Видя необходимость, вы продолжаете и обновляете свою диаграмму Helm, добавляя pv и pvc чтобы переход на 2.0.0 не был слишком разрушительным.

Перед изменением диаграммы у вас есть Artifact A связывающее версию приложения 1.9.9 с версией инфраструктуры 1.2.5 . Теперь вы меняете диаграмму ... _your Helm Chart теперь v. 1.3.0 _, и вы создадите артефакт, связывающий 1.9.9 с версией инфраструктуры 1.3.0 . Мы назовем это Artifact B

Когда развертывание кода для 2.0.0 будет запущено с изображением Docker sha fakeShaB , вы создадите еще один артефакт, связывающий 2.0.0 с инфра-версией 1.3.0 . Это Artifact C

Теперь предположим, что есть проблема, которую вы не полностью понимаете с выпуском 2.0.0, и вам нужно откатиться. Вы откатываетесь с помощью Artifact B ... но это не решает проблему, поэтому вы снова откатываетесь до Artifact A и проблема решается.

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

Несмотря ни на что, у вас все еще есть связь между версией приложения и версией инфраструктуры . Это цель Helm. Утверждать обратное - глупо.

@iorlas :

Отложим в сторону сравнения .deb . Я думаю, мы просто отвлеклись.

Не всегда. Например, образ докера может иметь SSR BE и ссылку на CDN.

Это очень верно. Но об этом позже.

В этом-то и дело. Даже если Dockerfile не изменен, вы создаете новый образ. Если ваш исходный код не изменился, но Dockerfile изменился, вы создаете новый образ. Итак, в двух словах, Dockerfile - это тоже пакет. То же самое и с Хельмом. Вы так не думаете?

Вы это делаете, но это потому, что продукт в конце этого процесса сборки (то есть образ Docker) зависит от _both_ Dockerfile и того, что вы в него вставляете. Изображение не может существовать без этих двух компонентов.

С другой стороны, Helm Chart может существовать еще до того, как приложение будет построено - буквально до того, как будет написана одна строка кода. Вы можете создать воображаемый, который не установится, но, тем не менее, Helm Chart может существовать полностью без чего-либо еще. Как я уже сказал, это было бы бесполезно, но я просто пытаюсь проиллюстрировать свою точку зрения, что они вообще не связаны.

Моя точка зрения и то, как это связано с этой конкретной проблемой, заключается в том, что Helm Charts не всегда внутренне связаны с приложениями, развертываемыми с помощью Chart. Не думаю, что это смелое заявление, бывает - это уже факт. Я делаю это прямо сейчас с производственными приложениями, как и другие, которые прокомментировали эту проблему. Итак, как я уже сказал ранее, все сводится к следующему; хотят ли сопровождающие Helm включить этот вариант использования или нет - в этом нет ничего другого.

Но оказывается, что образа докера недостаточно для запуска приложения. Нам нужен экземпляр конфигурации, нам нужны определения сервисов. Почему бы не упаковать все это?

Собственно, я бы так и хотел. Но не сейчас.

Если бы это было так, и Helm Chart действительно упаковал все, что он развернул (вы упомянули CDN ранее, но вы не развертываете это в Kubernetes, поэтому он не будет попадать в вашу диаграмму даже до сих пор), тогда я думаю, что этого разговора не было бы. Ваша Helm Chart будет внутренне связана с развертываемой версией приложения - точно так же, как создание образа Docker. Чтобы построить Helm Chart в этом сценарии, вам потребуется перестроить ее, когда ваше приложение изменится, и в этот момент нет никаких вопросов. Вы не могли бы использовать Helm так, как я использую его сегодня - так было бы намного яснее.

Однако это не так. Так работает Helm, и я не знаю, когда-нибудь так и будет. Но никогда не говори никогда, правда?

@jrkarnes :

Само изображение не упаковано, но ссылка (читается как: булавка) есть.

Конечно, но обычным вариантом использования является использование значений для переопределения этого значения. Я использовал его как для сторонних, так и для собственных графиков. Это не было бы вариантом, если бы люди не использовали его.

Конечно, мы можем быть педантичными и зацикливаться на том, включено ли буквальное изображение разного размера (от МБ до ГБ) в артефакт пакета helm (спойлер: это не так),

Я не думаю, что мы в чем-то педантичны - как вы уже отметили, было бы неверно утверждать, что образ Docker упакован внутри «встроенной» Helm Chart.

«Данная версия кода приложения включена в пакет helm» по-прежнему в основе своей верна.

Но не совсем так, как мой первый аргумент. Вы можете изменить то, что развертывается. Черт, вы можете изменить большинство диаграмм для запуска изображения hello-world если хотите. Это было бы бесполезно, но это хорошо доказывает мою точку зрения - Helm Chart не связан с вашим приложением. Есть _ ожидание_, что вы будете использовать его с правильным изображением, и, вероятно, по умолчанию он будет работать, но он определенно не _ должен_ - и ни в коем случае _ это код приложения, включенный в Helm Chart, иначе упакованный другой.

Возвращаясь в страну примеров, [...] и проблема решена.

Вы сделали это так, будто это невозможно без использования Helm, что, по-видимому, в настоящее время предназначено. Но на самом деле у вас может быть только 2 версии диаграммы (т.е. две версии вашей инфраструктуры) и 3 версии вашего приложения. Если вы хотите откатиться, сделайте это, вы можете довольно легко выбрать диаграмму и изображения, которые вы хотите развернуть. Запустите Helm с Chart, установите соответствующие значения для изображения, и все готово.

Несмотря ни на что, у вас все еще есть связь между версией приложения и версией инфраструктуры. Это цель Helm. Утверждать обратное - глупо.

Я думаю, что споры (в идеале, обсуждение) того, как что-то может измениться, часто приводит к улучшению. Я не думаю, что «цель» Helm - связать версию диаграммы и приложения. Я думаю, что его цель - упростить и безопаснее развертывать приложения в кластере Kubernetes, в то же время сохраняя манифесты Kubernetes в СУХИЕ и повторно используемые. Здесь нигде не требуется, чтобы диаграмма и версия приложения были строго связаны (прямо сейчас, как и в реальности, они вам не нужны).

И снова, как я уже сказал @iorlas , вопрос в том, должен ли Хельм адаптироваться? В чем причина того, что этот вариант использования не включен? Если причина просто «потому что в настоящее время этого нет», то это довольно плохая причина, если вы спросите меня. Похоже, что до сих пор ни один из участников этого обсуждения не дал ответа на этот вопрос.

... продукт в конце этого процесса сборки (то есть образ Docker) зависит как от файла Docker, так и от того, что вы в него вставляете. ... Изображение не может существовать без этих двух компонентов.

Итак ... Пакет Helm нуждается в диаграмме и версии приложения (= образ Docker) и не может существовать без него.

Helm Chart может существовать еще до того, как приложение будет построено - буквально до того, как будет написана единственная строка кода. ... Хелм-карта могла существовать совершенно без чего-либо другого. Как я уже сказал, это было бы бесполезно

Забавно то, что в одном проекте мы использовали образы докеров-заглушек для создания прототипа архитектуры. Мы буквально использовали диаграммы без написания единственной строчки кода. Кроме того, всегда целесообразно иметь диаграмму, состоящую только из поддиаграмм.

Итак, моя гипотеза такова : пакет Helm практически бесполезен без образа Docker. Образ Docker практически бесполезен без исходного кода. Разница в уровне абстракции. Обе вещи подобны пакетам .

но я просто пытаюсь проиллюстрировать свою точку зрения, что они вообще не связаны.

Ага, ага! Это действительно хорошо, что у нас есть люди, готовые обсудить все до мелочей. Без вас, без прогнозов и утверждений, мы не сделаем сусло живым в будущем 😃

Не думаю, что это смелое заявление, бывает - это уже факт. ... Итак, как я сказал ранее, все сводится к следующему; хотят ли сопровождающие Helm включить этот вариант использования или нет - в этом нет ничего другого.

Факт. Чтобы сделать и принять такое изменение, его следует оценить: правильно ли это делать ?

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

Так что я не против такого подхода. Я вижу, как он может жить (см. Мое предложение с helm run ). Но хотя у нас есть шанс вмешаться и, возможно, исправить всю отрасль, пока еще не поздно, я бы оценил каждое использование, обсудил любые недостатки и проблемы.

Чтобы построить Helm Chart в этом сценарии, вам потребуется перестроить ее, когда ваше приложение изменится.

Ага. Даже сейчас это могло быть случаем. У нас есть один конвейер, в котором вместо push мы делаем save / load образа докера. И работает неплохо. Я не чувствую, что это прямо сейчас, но, по сути, это намного чище. Проблема в том, что K8s по-прежнему будет нуждаться в удаленном реестре докеров в качестве шины для передачи «стартового» образа докера.

Давайте сузим фокус, ребята

Ваша Helm Chart будет внутренне связана с развертываемой версией приложения - точно так же, как создание образа Docker.

Это ключевое отличие прямо здесь. И @seeruk это

1. Образ Docker не связан с пакетом Helm. Только ссылка на него.
2. Это дает возможность освободить эти пути самостоятельно.

Ключевые вопросы:

1. Каковы риски независимого подхода? (т.е. что, если некоторые DevOps будут его использовать, какие аргументы мы скажем против)
2. Как упаковочный подход решает эту проблему?
3. Какова цена?
4. Каким мы видим будущее контейнеризации в этом конкретном вопросе?

@seeruk :

И снова, как я уже сказал @iorlas , вопрос в том, должен ли Хельм адаптироваться? В чем причина того, что этот вариант использования не включен? Если причина просто «потому что в настоящее время этого нет», то это довольно плохая причина, если вы спросите меня. Похоже, что до сих пор ни один из участников этого обсуждения не дал ответа на этот вопрос.

Вы делаете много замечательных уточнений и замечаний. Лично я считаю, что Хелму следует адаптироваться. CI / CD - это будущее того, как будет создаваться программное обеспечение, и, честно говоря, с такими вещами, как --atomic helm уже становится более гибким в качестве надежного инструмента развертывания. Хотя это довольно старая проблема, поэтому я думаю, что объединение PR - не «следующий шаг» в этом процессе.

Будет ли возможно создание плагина, скажем, helm-ci-cd для этой конкретной функции --app-version ( @jrkarnes, вероятно, может поговорить с ним как со спонсором по связям с общественностью)? Я думаю, что потребности сообщества в выпуске Tiller были признаны только после того, как этот плагин стал популярным. С Helm можно легко обойти различные другие проблемы, которые могут быть другими хорошими кандидатами на helm-ci-cd посмотрите на двойственность install/ upgrade которую мы, CI / CD, уже объединили с помощью упаковки.

Даже если переключатель --app-version не является прямым добавлением ценности для конечных пользователей, которые пытаются установить приложение k8s, не просматривая файлы шаблонов (что, кстати, никогда не срабатывало для мне из-за необходимости добавить сетевые политики, совместимые с моей рабочей инфраструктурой k8s) конечный пользователь по-прежнему получает большую ценность, потому что человеку, который построил эту диаграмму, было легче это сделать из-за функций helm ci / cd, которые делают сборку стабильной а надежный софт проще.

Мы просто читаем Chart.yaml с помощью groovy, затем устанавливаем версию приложения и перезаписываем файл во время развертывания. Затем сделайте апгрейд руля. Было бы неплохо, если бы он был частью руля, но я бы не стал на это рассчитывать.

Нашел через гугл. Собственно, та же лодка.

Если verison: - это версия диаграммы, это означает, что эта версия изменяется при изменении YAML диаграммы. Поскольку диаграмма представляет собой шаблон с настраиваемыми значениями, можно с уверенностью предположить, что вы можете использовать диаграмму 1.3 для развертывания приложений нескольких версий, 1,2, 1,3, 1,6, 1,8 и т. Д., Без всякого изменения файлов YAML диаграммы.

Теперь идет appVersion: жестко закодированный в Chart.yaml, заставляющий вас редактировать файл диаграммы, чтобы обновить (и отразить) версию развернутого приложения.

Определенно существует необходимость в параметре --app-version CLI, который мы можем использовать в шаблонах диаграмм для ссылки на версию _application_ для развертывания разных версий с одной и той же диаграммой version: 1.3.0 .

@seeruk

Я не думаю, что «цель» Helm - связать версию диаграммы и приложения. Я думаю, что его цель - упростить и безопаснее развертывать приложения в кластере Kubernetes, в то же время сохраняя манифесты Kubernetes в СУХИЕ и повторно используемые.

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

Я сказал это в ходе обсуждения и думаю, что стоит повторить:

[...] Я полагаю, что helm по-настоящему развертывает только пакеты. Кажется, это единственное семантически правильное, что вы можете сказать; однако аргумент о том, как эти пакеты распространяются, кажется основной причиной этих дебатов на практике. В частности, «является ли обновление или изменение версии приложения новым пакетом?»

Диаграмма управления от 1-го лица (мне нравится использовать MySQL, поэтому я собираюсь ее использовать) без конфигурации должна устанавливать ресурс в кластер, как это описал и задумал создатель диаграммы . Глядя на фактическую диаграмму для mysql, можно

• image (по умолчанию mysql )
• imageTag (по умолчанию 5.7.14 )

Затем в их файле Chart.yaml :

apiVersion: v1
name: mysql
version: 1.4.0
appVersion: 5.7.27

Обратите внимание, что appVersion и imageTag по умолчанию не совпадают . Если я запустил helm list я получу отчет о том, что «версия приложения» (читай; версия движка) - это состояние, _ которое не отражает фактическую версию приложения, установленную в кластере_.

Здесь нигде не требуется, чтобы диаграмма и версия приложения были строго связаны (прямо сейчас, как и в реальности, они вам не нужны).

Это верно; и на мой взгляд недоработка конструкции.

И снова, как я уже сказал @iorlas , вопрос в том, должен ли Хельм адаптироваться?

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

@IRobL

Возможно ли создание плагина, скажем, helm-ci-cd для этой конкретной функции --app-version ( @jrkarnes, вероятно, может говорить с этим как

Вы отвечаете на свой вопрос так:

Даже если переключатель --app-version не является прямым добавлением ценности для конечных пользователей, которые пытаются установить приложение k8s без необходимости просматривать файлы шаблонов, конечный пользователь все равно получает большую ценность, потому что человек, который Создавая эту диаграмму, было легче сделать это из-за функций helm ci / cd, которые упрощают создание стабильного и надежного программного обеспечения.

Если нам нужно сделать это как плагин, чтобы функция работала правильно, я бы поддержал этот подход; однако я думаю, что это не та проблема. Как я сказал ранее @seeruk , я считаю, что наличие appVersion как внутреннего свойства в неизменяемом файле Chart.yaml является недостатком дизайна. appVersion - это свойство image , которое устанавливается в кластер через диаграмму, и оно каким-то образом получено из изображения, на которое ссылается его tag .

Размышляя о плагине helm-ci , какие еще функции или надстройки вы ожидаете там увидеть? Я не думаю, что простое переключение appVersion из неизменяемых свойств Chart.yaml достаточно для добавления ценности, чтобы гарантировать, что это плагин.

@IRobL и @seeruk вместе:

Я думаю, что наши разные мнения исходят от того, кем мы видим наиболее распространенного конечного пользователя Helm. Если предполагается, что конечный пользователь - это тот, кто не собирается много настраивать или копаться в шаблонах, тогда helm ls может быть не особенно полезным, и это спорный вопрос.

Однако ... если вы используете helm в качестве административного инструмента и помощника для управления кластером ИЛИ, если вы используете Helm в большей части контекста CI / CD, тогда переключатель --appVersion оказывается намного более значительным. более полезен и, следовательно, вызывает беспокойство (и конфигурацию),

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

К тому, о чем я сказал

да. Я обращусь к некоторым предложениям через мгновение ...
... размышляя о плагине helm-ci , какие еще функции или надстройки вы ожидаете там увидеть?

У меня есть личный список, который может стать хорошей отправной точкой:

• Запуск helm в режиме CICD не будет сравнивать _only_ состояние ранее выпущенных пакетов с тем, что применяется в настоящее время. . Вместо этого каждое развертывание выпуска будет полностью применять каждый шаблон манифеста при запуске upgrade .
• helm-cicd должен заключать в оболочку базовые команды кубернетов. Я не могу сосчитать, сколько раз пытался запустить helm describe или helm logs .
• helm-cicd должно позволить мне увидеть результаты выполнения команд другим пользователем. Если мы используем RBAC, я хотел бы посмотреть, что происходит, когда неавторизованный пользователь пытается что-то сделать.
• helm-cicd должна иметь возможность разложить пространство имен на коллекцию манифестов для редактирования позже.
• helm-cicd должна иметь возможность _трансплантировать_ релиз в пространство имен.

Это большие ... но обсуждение полноценного плагина helm-ci выходит за рамки этого PR / выпуска (в настоящее время).

Я читаю все, что вы пишете, и ценю вашу беседу. Жду ваших ответов.

Я сейчас довольно занят, но хочу поправить вас по нескольким пунктам. @jrkarnes

Я думаю, что наличие appVersion как внутреннего свойства в неизменяемом файле Chart.yaml является недостатком дизайна.

Нет. Когда что-то сделано таким образом, а не иначе, всегда есть причина, даже самая дикая . В данном случае это моя идеология: один пакет = одна сборка, диаграмма = шаблон для сборок, пакет = приложение + инфра.

Helm разработан на основе этой идеологии, чтобы рассматривать K8s как ОС, а пакет - как программу установки / обновления для вашего приложения. У него есть некоторые проблемы, иногда кажется, что это слишком много, но это, безусловно, будущее.

_Почему я думаю, что он так устроен? Тот же helm list установлен для отображения текущих установленных версий пакетов.

Хорошо, у нас есть много диаграмм (общедоступных, таких как mysql и локальных, как у вас, вероятно, есть), которые не собираются для создания пакета каждый раз, когда появляется новый выпуск. И я восхищаюсь этой потребностью, поскольку для перехода к высокоуровневым решениям требуется время. Кроме того, кому-то нужно создавать пакеты, и было бы сложно убедить разработчиков mysql создавать пакет Helm для каждой сборки.

С диаграммой MySQL возникает дополнительная проблема. Вы правы, было бы лучше видеть версию MySQL, установленную в helm list , но это всего лишь часть версии, поскольку есть также тег Image, который, вероятно, является частью версии здесь.

И снова, как я уже сказал @iorlas , вопрос в том, должен ли Хельм адаптироваться?
да. Я обращусь к некоторым предложениям через минуту.

Опять же, было предложение добавить helm run , что вы все ищете. Он предназначен для мгновенного использования Chart как пакета, что позволяет предоставлять версии приложений и все такое.

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

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

Проблема в том, что это не так. Это всего лишь часть, артефакт. От маленьких до больших продуктов у вас будет много артефактов, связанных вместе. Иногда вы будете передавать версии в файле докеров в процессе сборки, иногда у вас будет ConfigMap, который связывает несколько артефактов. И у вас не будет одного файла докера, в котором будет все.

У меня есть личный список, который может стать хорошей отправной точкой

Думаю, у вас есть много предложений, но это более живой форк Helm , чем какой-то дикий плагин. Я бы сказал, что это не имеет ничего общего исключительно с CI CD. Я бы поспорил не создавать такой форк / плагин, а обсуждать и предлагать правильные решения. Никому не нужны 3 вилки Helm, учитывая, что текущее сообщество не так уж и велико прямо сейчас.

Внимание, пожалуйста!

Хорошо, мы много думали там и сям. Я считаю, что в лучшем случае будет:

• Возможность изменять версию приложения без необходимости сначала создавать пакеты
• Возможность увидеть правильную версию приложения в helm ls
• Разрешить любому API (например, оператору Helm) указывать / обновлять версию приложения без среднего состояния

У нас есть два подхода:

1. helm install создается для установки пакета. Он также поддерживает установку Chart, но имеет ограничения. Давайте упростим helm install и оставим его для своей цели - установки пакетов. Во-вторых, давайте добавим helm run , цель которого - обеспечить упрощенный поток: объединить helm package и helm run , предоставить аргументы обеих команд, но отфильтровать те, которые не имеют смысла в таком случае .
2. Добавьте app-version в helm install cmd. Он раздувает этот API и скроет идею использования пакетов, он скроет (как сейчас) идеологию использования пакетов в качестве установщиков, что имеет смысл, по крайней мере, для некоторых, если не для большинства проектов.

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

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

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

Ооо. Я понял. Helm-диаграмма [пакет] предназначена для использования в Kubernetes как «обороты в минуту» [per-say]. Совершенно не то впечатление, которое у меня сложилось: helm использует диаграммы для развертывания приложения. Диаграмма / пакет - это приложение, "отформатированное для k8s".

Меня это устраивает. Это имеет смысл - нам просто нужно обновить наш сервер сборки до appVersion по мере создания новых контейнеров:

• Сборка контейнера - тег "v1.2"
• Обновите Chart.yaml - appVersion: "v1.2" --- я вижу, что уже есть даже команда helm package --app-version .
• Таблица пакетов: helm package --app-version v1.2 => package [chart] -v1.2.tgz (т.е. "package [chart] -v1.2.rpm")
• Разверните пакет с помощью серверов развертывания, helm install package [диаграмма] -v1.2 (например, apt install [email protected])

Я ошибаюсь в понимании всего этого? Если package-v1.2 не является версией приложения v1.2, почему бы и нет? Разве это не было намерением? например, rpm - это версия приложения, а не пакет (диаграмма).

Редактировать:

Если package-v1.2 не является версией приложения v1.2, почему бы и нет? Разве это не было намерением?

Теперь я понимаю, почему люди в унисон комментируют Chart.version и Chart.appVersion. Аргументы здесь могут быть двоякими ... приложение со стабильной сборкой «диаграммы», вы ожидаете, что package-v1.2 изменит номера версий. Но вы также можете утверждать, что package-v1.2 будет номером версии диаграммы при изменении файлов yaml.

Как вы управляете стабильной версией Chart (1.2), в отличие от увеличивающейся версии приложения (1.6)? Будет ли package-[version] 1,2? или 1,6? Допустим, вы развертываете версию диаграммы 1.2, но версия приложения изменилась при упаковке: helm package --app-version 1.6 ?

➜  chart git:(master) ✗ helm package --app-version 1.5 nginx
Successfully packaged chart and saved it to: /Users/Documents/source/docker/nginx/chart/nginx-0.1.0.tgz

:(

.... Так запутанно.

Helm-диаграмма [пакет] предназначена для использования в Kubernetes как "обороты" [per-say].

Точно! Но иногда кажется, что это слишком строго или слишком много хлопот, и здесь нужен ярлык.

Я ошибаюсь в понимании всего этого? Если package-v1.2 не является версией приложения v1.2, почему бы и нет? Разве это не было намерением? например, rpm - это версия приложения, а не пакет (диаграмма).

Это проблема для другого обсуждения, но в настоящее время пакет будет называться в соответствии с версией диаграммы, а не версией приложения. Я не знаю причины этого, я чувствую, что должно быть наоборот. Думаю, это исторический вопрос, но на мой взгляд, как и на ваш, он должен быть package-{app-version}.tgz .

Согласно моим предыдущим сообщениям, версия состоит из 4 компонентов:

• Диаграмма
• Приложение
• Упаковка
• Выпуск

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

Если мы выберем идеологию упаковки приложения, версия приложения будет иметь смысл, поскольку один и тот же процесс создает и приложение, и изображение, и пакет. Итак, когда мы перейдем к этапу доставки, будет очевидно, как называются файлы и какой файл устанавливать. Прямо сейчас нам нужно жестко указать имя пакета в конвейерах> _ <

@iorlas

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

Мне потребовалась пара недель, чтобы обдумать это утверждение, и я на 100% согласен с вами. Кроме того, теперь я понимаю, откуда взялось наше расхождение во мнениях ...

Я придерживаюсь философии разработки и развертывания, согласно которой вы должны строить систему из небольших компонентов, которые невероятно хорошо выполняют набор вещей (например, UNIX); однако современные системы могут рассматривать «приложение» как группу этих небольших инструментов. Как вы должны отмечать «версию» приложения, если она зависит не только от артефакта докера, но и от других субкомпонентов (которые также могут быть артефактами докера)? Это не такой уж однозначный ответ, если вы начнете отказываться от такого типа связи.

Ответ на этот вопрос выходит далеко за рамки данного вопроса / запроса. Чтобы вернуться к корню проблемы, я хотел бы провести различие между install и run . Исходя из семантики, install должен работать только с пакетами, а run должен «запускать» helm через процесс генерации шаблонов и их применения _без сохранения состояния_.

Хотя часто мы должны использовать helm template чтобы увидеть, как будет разворачиваться перспективная диаграмма, очень полезно наблюдать за тем, как это происходит. Vi-ca-vi run которого есть двойная цель быть звездой в конвейерах разработки (где мы не обязательно хотим держать пакет, потому что он не имеет ценности, если скорость очень высока).

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

Как я уже сказал, в идеальной вселенной версия установленного объекта будет подвергнута интроспекции. Однако это дает мне представление.

Если мы будем помнить то, что я сказал раньше о том, как развертываются диаграммы, что, если бы у нас была возможность развернуть все подкомпоненты с помощью флага на helm describe ? Это не устраняет необходимость указывать версию приложения, но дает более четкое представление о том, что именно установлено (что является одной из движущих сил, стоящих за желанием скорректировать версию приложения с помощью флага).

Я прочитал все комментарии и не имею полностью квалифицированного мнения по этому поводу.

Я приехал сюда, потому что моя компания поддерживает частный репозиторий Helm, и 90% наших диаграмм в основном представляют собой одно развертывание с одной спецификацией контейнера. В этих случаях, если бы мы могли использовать appVersion для перечисления тега изображения, мы бы избежали дублирования переменной и увидели бы, что эта версия работает с helm version .

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

По запросу я добавлю свой последний ответ из предыдущей беседы, чтобы другие могли его просмотреть.

Хм. Здесь вещи начинают противоречить друг другу, когда вы начинаете связывать appVersion с тегом Docker (логическая ассоциация). Вот где у нас проблемы, то есть сценарий разработки, о котором я упоминал выше. Поскольку version должен быть SemVer, мы просто не можем использовать теги Docker в качестве Chart version .

Как сделать визуальную разницу в версии для разработчиков, когда appVersion не отображается на графиках?

Из-за того, как k8s работает с его приложениями: в мире разработчиков должен быть способ разрешить версии тегов повсюду.

Он не мог делать такие вещи, как SemVer в терминах операторов ~ или ^, потому что версия была чисто упорядоченной, без семантики.

Почему нет? Мы постоянно делаем это с помощью php composer . Мы можем использовать SemVer, или мы можем использовать строковые версии, которые просто анализируются или игнорируются в схеме управления версиями, т.е. если version не является номером SemVer, не включайте его в ~ и ^ сопоставление с образцом.

Поскольку вы цитируете мой комментарий к № 7299 , я поясню «Не удалось» на «Не удалось» (а, может быть, и до сих пор).

Для пакетов .deb и .rpm строка версии разделяется определенным образом (дефисами), но они не имеют семантического значения, такого как «Это API-совместимый с этим», и поэтому вы не можете сгенерировать выражение типа «Дать мне последняя версия, совместимая с API »или« Дайте мне последнюю версию с неизмененным API », как вы можете с SemVer.

Напомню, что и Debian, и RedHat использовали псевдонимы пакетов для достижения этих вариантов использования (и совместимости с ABI), как правило, на основе номеров версий. Это позволяло вести себя достаточно согласованно, используя только имена пакетов и сравнения только по порядку.

Что касается общей темы, то способ, которым мы используем диаграммы Helm для нашего продукта, заключается в упаковке наших различных услуг. Однако образы Docker являются всего лишь артефактом, и их именование определяется версией службы, для которой мы приняли SemVer, потому что они предлагают API.

Наш конвейер CI превращает git-репозитории кода и связанных скриптов и создает диаграммы Helm, которые можно установить и которые могут ссылаться на образы Docker. Теги на образах Docker не интересны нашим пользователям. Затем мы помечаем теги git SHA, из которых они были получены, а затем повторно добавляем теги к изображениям, используемым в выпуске. Основное преимущество смены тегов заключается в том, что мы знаем, что их нельзя снимать теги, в то время как мы можем снять теги с версий git-SHA через короткий промежуток времени.

Так что я вполне доволен тем, как Helm работает для нас, потому что version содержит точную версию нашего программного обеспечения, а appVersion содержит то же самое, но в виде строки, и никто никогда не смотрит в нашем репозитории Docker.

Я немного менее доволен способом создания версий диаграмм в https://github.com/helm/charts/ , поскольку там версионируется диаграмма , а не программное обеспечение, что иногда приводит к незначительным (стабильным) диаграммам version обновления, нарушающие обратную совместимость . Я думаю, что это вероятное последствие, которого трудно избежать, когда вы отделяете version диаграммы от версии того, что в ней содержится.

У нас есть аналогичная проблема с диаграммой стабильный / прометей-оператор на нашей внутренней странице «Внешние библиотеки и артефакты». Он содержит кучу разных программ, поэтому вопрос «На какой у нас версии?» и особенно "Безопасно ли обновляться?" ответить гораздо сложнее, чем на Agones, версии которых так же, как и мы.

@jrkarnes

Если мы будем помнить то, что я сказал ранее о том, как развертываются диаграммы, что, если бы у нас была возможность развернуть все подкомпоненты с помощью флага на описании руля? Это не устраняет необходимость указывать версию приложения, но дает более четкое представление о том, что именно установлено (что является одной из движущих сил, стоящих за желанием скорректировать версию приложения с помощью флага).

Я очень хотел бы это увидеть. Например, есть связанный запрос функции на # 6932.

Только что вернувшись к обсуждению, идея о том, что appVersion связана с метаданными образа Docker, определенно не подходит для нашего варианта использования, как, по крайней мере, некоторые из наших диаграмм (с которыми в основном имеют дело наши пользователи). не содержат образов Docker, являясь в основном хостами для общих ресурсов (например, открытых ключей JWT, values.yaml ) плюс requirements.yaml для извлечения других диаграмм.

идея о том, что appVersion связана с метаданными образа Docker, определенно не соответствует нашему варианту использования, поскольку, по крайней мере, некоторые из наших диаграмм

Я не говорю, что это было предназначено. Я просто сказал, что это логическая ассоциация. Вы все еще используете appVersion в качестве «логического контейнера» для ваших внутренних yamls.

Я до сих пор не знаю, какие преимущества дает блокировка version для SemVer. Может ли helm просто выполнить синтаксический анализ version (и appVersion ) и продолжить работу оттуда?

Я предполагаю, что моя точка зрения заключалась в том, что мы вообще не используем appVersion , его обычно нет в нашем Chart.yaml, а когда он присутствует, он идентичен version .

Преимущество блокировки version для SemVer заключается в том, что вы можете использовать для него различные операторы SemVer и надежно анализировать его для создания упорядочения и сопоставления при установке.

Системы упаковки RPM и DEB имеют одно и то же, за исключением того, что их системы управления версиями используют другой синтаксис, но по-прежнему являются ограниченным синтаксисом по причинам семантического синтаксического анализа. У них также другая важная семантика.

Учитывая, как было запущено репо helm / charts, я чувствую, что одно поле version с версией в стиле DEB или RPM было бы лучшим выбором, чем SemVer плюс appVersion string. Однако это совсем другой корабль, уже спущенный на воду. И, будучи в молодости и разработчиком исходных текстов, и упаковщиком Debian, я ценю то, что мне не нужно жонглировать «Какой из номеров версий нужно здесь указать?» в наших пакетах « version - единственная правда».

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

Привет. Нет новостей по этой функции.

Прочитав все комментарии, я понял, что это было бы действительно полезно.

Действительно, в нашей компании, поскольку у нас есть несколько приложений, которые используют одни и те же технологии и развертываются одинаково, у нас есть одна диаграмма для разных приложений, чтобы избежать дублирования.
Мы упаковываем новый график только при наличии инфраструктурных, структурных изменений.
И только когда мы обновляем или устанавливаем выпуск, мы применяем определенные значения как переменные tag, env ...

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

Поскольку в списке руля должна отображаться информация о выпуске, мы должны видеть версию приложения, развернутую в этом выпуске.

Я оставил комментарий в аналогичной проблеме https://github.com/helm/helm/issues/7517
Можно ли добавить возможность переопределения в values.yaml?
Тогда мы бесплатно получаем опцию командной строки --set

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

Я согласен. В настоящее время нам запрещено использовать Музей диаграмм для неизменяемых диаграмм на основе _приложений_. Версия диаграммы! = Версия приложения, что делает невозможным выпуск через Музей диаграмм.

Я прочитал кучу (не все) приведенного выше обсуждения, извините, если я повторяю некоторые моменты / мнения. Я пытаюсь дать более взвешенный ответ.

Мне нравится видеть appVersion, когда я делаю helm ls и концептуально переход от .Values.image.tag был хорошим, НО невозможность установить его во время развертывания - это настоящий стопор для шоу, и это то, что у меня было вернуться к.

Я твердо уверен, что (диаграмма) version - это версия диаграммы, а appVersion - это тег докера. В нашем процессе CI тег docker также является тегом git.
У нас также есть несколько микросервисов, и мы хотим, чтобы все было как можно СУХИЕ. У нас есть общие диаграммы в локальном репозитории диаграмм, потому что подавляющая часть приложений java-springboot одинакова. Основная часть приложений tomcat такая же (но отличается от приложений Springboot). Промыть и повторить для других технологий. Затем у нас есть экологические ценности, поскольку развертывание проходит в различных средах.
Затем каждый из этих микросервисов использует общую диаграмму через CI / CD.
например, helm upgrade release-name private-repo/generic-chart --values <environment>.yaml --set image.tag=<docker tag from build step> --namespace <environment> --install Я бы предпочел использовать .Chart.AppVersion а не .Values.image.tag но я ДОЛЖЕН иметь возможность развертывания таким образом, чтобы это было эффективно для нашей организации.

Если я делаю helm ls меня есть и CHART и APP VERSION поэтому вся версия диаграммы должна совпадать с версией приложения. Продолжение этого пути просто оттолкнет людей, и в какой-то момент проект будет разветвлен, потому что этот менталитет слишком строг, а не то, что многие люди хотят. Он также начинает идти по пути «Давайте удалим image.* , nameOverride & fullnameOverride . Image. * Можно жестко запрограммировать в deployment.yaml и т. Д.» по ОЧЕНЬ похожим причинам.

Наконец, многие общедоступные диаграммы не будут точно соответствовать используемой ими версии контейнера докеров. Взгляните на большинство известных контейнеров докеров, например, alpine или nginx, где основная и дополнительная версии являются плавающими тегами, а не обновляются только версии исправлений. Отображение 1: 1 для каждой версии патча приводит к довольно значительным накладным расходам, практически не приносящим никакой пользы.
Нередко производственные среды не могут обновиться до последней версии по множеству причин. Даже не говорите в большинстве мест о прокатных версиях в производстве.

В результате всего вышесказанного возникает вопрос: «Зачем вообще руль может использовать репо с графиком?».
Невозможность перезаписать appVersion во время установки / обновления означает, что вам уже нужно загрузить и распаковать диаграмму, отредактировать appVersion за установку / обновление, или вы можете также упаковать необходимые контейнеры докеров в график.
Исключение составляют случаи, когда происходит полностью стандартная установка, и уже ведется много споров по поводу автоматической генерации паролей и тому подобного.
Я знаю, что последние абзацы выглядели так, как будто я спускаюсь в кроличью нору и рисую себя в углу, но это IS, где «appVersion - это тег докера и не может установить appVersion через командную строку или значения», берет нас.

@timothyclarke: Что вы можете сделать, за helm upgrade потребительной случае вы описали здесь, helm package первым, который позволяет установить --version и --app-version , а затем вы можете helm install тарболл и сохранить его как артефакт CI, что увеличивает воспроизводимость при установке, поскольку для него не нужно добавлять какие-либо параметры --set . Это то, к чему мы перешли, хотя и без аспекта «обобщенной диаграммы», поскольку наши диаграммы не являются общими.

Это также хороший шанс добавить метаданные сборки в Version , что-то вроде +g<shortCommitSHA> .

Per # 7517, который позволил мне удалить кучу вызовов sed , которые переписывали image.tag перед установкой на наш тестовый кластер CI, а затем снова при последующей упаковке.

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

Для меня риск переопределения версии (или версии) приложения во время установки заключается в том, что это не так четко видно для кого-то, кто пытается воссоздать диаграмму, как это было сделано. Если он каким-то образом не взломан в поддержку значений, его не будет, когда кто-то извлечет текущую конфигурацию диаграммы с помощью helm get values -o yaml , поэтому он станет _ еще одной вещью_, которая отличает развертывание вашей живой диаграммы от того, что вы получаете с helm install <some way to specify a particular package> --values <values from helm get values> , например, при попытке воспроизвести проблему, замеченную в производственной среде, на тестовой установке.

Для меня риск переопределения версии (или версии) приложения во время установки заключается в том, что это не так четко видно для кого-то, кто пытается воссоздать диаграмму, как это было сделано. Если он каким-то образом не взломан в поддержку значений, его не будет, когда вы извлечете текущую конфигурацию диаграммы с помощью helm get values -o yaml

В точку. Это должно быть в values.yml с первого дня.

Хотя я понимаю философские аргументы против этой функции, практика показывает, что это очень поможет людям, в том числе и нам.

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

Я не уверен, что это обсуждалось (быстро нажал CTRL + F и не смог найти никаких следов), но как насчет удаления appVersion в качестве альтернативного решения? Мне кажется, что это позволило бы избежать всей неразберихи.

Прямо сейчас appVersion рассматривается как своего рода "особое" значение. Я предполагаю, что он предназначен для обеспечения видимости, например, у меня может быть диаграмма версии 123.5.6 Prometheus, но у нее будет appVersion: 2.17.1, поэтому я знаю, какая версия исправления безопасности у него есть и какие функции Prometheus ожидать, и я можно найти с помощью helm ls .

Думаю, это можно было бы представить как-то иначе. Может быть, через релизные лейблы? Или, возможно, запрос jsonPath по всем выпускам, аналогично тому, что возможно с kubectl например:

kubectl get nodes -o jsonpath='{.items[*].status.addresses[?(@.type=="ExternalIP")].address}'

Затем поддержка этого будет переключена на лучшие практики, вместо того, чтобы навязываться самим helm . Это тоже могло быть с линзами.

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

Может быть, сделать шаг назад и понять, почему было добавлено именно appVersion , поможет решить эту проблему?

@bokysan Ранее он был в values.yaml он был перемещен в Chart.yaml Я предполагаю для всего helm ls показывающего как диаграмму, так и тег докера, вместо того, чтобы запускать такую ​​команду в виде
kubectl get deployment <release name> -o jsonpath='{.spec.template.spec.containers[0].image}'

@TBBle Я бы обратился к каждому из ваших пунктов, но он сделает этот пост таким же длинным, как и предыдущий. Я думаю, что вся эта проблема сводится к тому, что кто-то решает, что общая диаграмма не является допустимым вариантом использования, исключительно путем просмотра диаграмм в общедоступном репо.

Вся предпосылка appVersion становится очевидной, как только вам нужно начать использовать initContainers и sidecars. Приведу реальный пример, в одном из проектов, которыми я сейчас должен управлять, есть nginx с дополнительным элементом php. Теги nginx и php меняются нечасто. Контейнер / версия php очень важен для разработчиков, пишущих код. Контейнер, который изменяется наиболее часто, - это initContainer который предоставляет содержимое.
Могу ли я установить appVersion в initContainer , в контейнер php или это nginx , и, выбрав только один из них, какая информация была потеряна?

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

Если вы хотите принудительно использовать тег изображения контейнера appVersion ==, то вы обнаружите, что это сложно с нетривиальными диаграммами, то есть диаграммами с более чем одним контейнером или без контейнеров. Но не в этом суть, иначе это было бы imageVersion . Если вы упаковываете одно исходное приложение, используйте его версию. Если вы создаете пакет из нескольких исходных приложений, выберите одно, например диаграмму оператора прометея, или игнорируйте appVersion, поскольку это необязательное поле.

Если ваш источник диаграммы является _ частью_ приложения, например Agones, просто оставьте поле appVersion пустым или скопируйте его из version если у вас есть инструменты, зависящие от него.

Ни одна из этих вещей не должно быть helm install -time решения. Как я упоминал ранее, helm package достаточно поздно для всех рабочих процессов, за исключением «переключить другую исходную версию во время установки для сторонней диаграммы», и это должно быть в --values или --set как и все другие действия «изменить X во время установки».

Честно говоря, фактически отсутствующей функцией, вероятно, является «передать appVersion через tpl », чтобы вы могли прочитать его из .Values.image.tag или из того, что вам подходит.

Если вы хотите принудительно использовать тег изображения контейнера appVersion ==

Тогда мы, вероятно, находимся в https://github.com/helm/helm/issues/7517 Возможно, откуда все это происходит.

Я вообще не понимаю этого обсуждения. Почему бы не дать людям возможность использовать версию приложения так, как они считают наиболее подходящим для них, - это такая большая проблема?

В текущем виде для меня будет лучше вообще не иметь этого APP VERSION . Это только запутывает людей в нашем проекте. У нас есть> 80 сервисов, которые используют одну и ту же диаграмму управления, и поскольку невозможно легко изменить этот APP VERSION в helm upgrade -i ... я вижу, что все наши приложения навсегда останутся с 1.0 здесь. И я не планирую переупаковывать уже упакованную диаграмму, чтобы просто изменить версию приложения. Почему я должен усложнять свой CI, чтобы он соответствовал вашему дизайну ???

Я также вижу, что мне просто нужно сказать всем, чтобы они не использовали helm list поскольку это будет чем-то бесполезным для них. Чтобы проверить, какая у них версия наших приложений, им нужно будет использовать что-то еще.

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

Наличие двух разных выходных данных «ДИАГРАММА (версия)» и «ВЕРСИЯ ПРИЛОЖЕНИЯ» в helm list , helm history и т.п. очень полезно и позволяет избежать необходимости углубляться в параметры командной строки и разбор вывода, чтобы получить самые важные факты.

Если «ДИАГРАММА (версия)» и «ВЕРСИЯ ПРИЛОЖЕНИЯ» связаны во время сборки («пакет helm»), все преимущества наличия двух разных значений несколько теряются. Создание диаграммы и обновление ВЕРСИИ ПРИЛОЖЕНИЯ без увеличения / обновления ВЕРСИИ ДИАГРАММЫ приведет к большим проблемам, поскольку одна и та же ВЕРСИЯ ДИАГРАММЫ даст вам очень разные результаты. : - <

Так что на данный момент мы вынуждены собирать пакет с каждым выпуском и синхронно увеличивать «ДИАГРАММУ (версия)» и «ВЕРСИЯ ПРИЛОЖЕНИЯ», чтобы не попасть в безумную / неясную ситуацию.

Как я только что узнал, мы могли бы отказаться от «ВЕРСИИ ПРИЛОЖЕНИЯ», поскольку это необязательно, и использовать какое-то настраиваемое значение и использовать его вместо {{Chart.appVersion}} для нашего изображения .... но тогда helm list будет быть менее информативным. : - <

С точки зрения пользователей (разработчиков):

• возможность установить какое-либо свойство / флаг / значение версии во время установки
• возможность видеть свойство / флаг / значение этой версии в выводе списка / истории руля с меткой «XX версия»

Есть ли шанс, что мы сможем это сделать?

Если «ДИАГРАММА (версия)» и «ВЕРСИЯ ПРИЛОЖЕНИЯ» связаны во время сборки («пакет helm»), все преимущества наличия двух разных значений несколько теряются.

Я думаю, что в этом суть расхождения. Преимущество версии приложения в том виде, в котором я ее использую, и, как кажется, предполагалось в текущей настройке, заключается в том, что вы знаете версию обернутого приложения _ для этой версии диаграммы_, потому что версия диаграммы - это версия всей диаграммы, а не версия диаграммы. версия шаблонов в диаграмме. Я бы не хотел, чтобы каждое утверждение вроде «Нам нужна версия ~ XY диаграммы Helm» требовало «О, и не связывайся с AppVersion» в конце.

Это преимущество теряется. Версия приложения (и фактическая версия приложения) изменяется во время установки, потому что теперь версия диаграммы не сообщает вам, какое приложение вы используете, и вы теряете возможность использовать SemVer для обеспечения, например, у вас последняя версия, но совместимая с API.

Для случая использования , описываемого appVersion качестве шаблона, указывающего на запись значений, заставит helm list делать то, что требуется, если диаграмма поддерживает версия приложения (возможно, тег контейнера) изменилась во время установки с помощью --set или --values как и любой другой параметр конфигурации "изменен во время установки".

Здесь у меня проблема с AppVersion .

Мы используем как Release-версию, так и AppVersions.

Чтобы установить их сейчас - я должен явно вызвать helm package перед helm upgrade --install чтобы создать локальный tar-архив с установленными обеими версиями.

Теперь добавляю поддержку helm-secrets , и ...
И эта оболочка не может работать с helm package !

И что теперь?
Отказаться от поддержки и потока всех наших версий?
Отказаться от секретов?
Любые идеи?

На самом деле это больше проблема для helm-secrets , но это также связано с обсуждаемой здесь способностью --set app-version , потому что если бы я мог использовать ее таким образом - мне не нужно было бы вызывать helm package вообще.

UPD Ой, подождите ... Я все еще могу использовать helm secrets upgrade chart.tgz -f secrets.yaml ...
Хорошо.
Но все же +1, чтобы добавить --set app-version .

И что теперь?
Отказаться от поддержки и потока всех наших версий?
Отказаться от секретов?
Любые идеи?

Мы создаем два пакета: пакет helm, содержащий только диаграммы, без значений env и файл секретов. Мы переименовываем этот пакет в chart-{app-version}.tgz поскольку версия диаграммы ничего не значит для нас, а версия диаграммы не поддерживает синтаксис версии приложения. Обновления нашего приложения включают любые потенциальные обновления диаграмм (в том же репозитории, с использованием тегов git).

Затем у нас есть второй tgz, зависящий от среды, chart-{app-version}-{env}.tgz который включает диаграмму tgz, значения yaml и файл зашифрованных секретов. Этот файл также включает «package.yaml», который содержит такие значения, как тег, приложение и имя среды для наших автоматических сценариев, развертываемых с использованием helm-secrets .

Мы привыкли идентифицировать версии наших приложений или большинство из них с помощью семантического номера версии. Затем используйте этот номер в ВЕРСИИ ПРИЛОЖЕНИЯ, чтобы легко идентифицировать его в списке helm history для откатов или других операций.
Поскольку система не позволяет вводить его автоматически во время развертывания, мы автоматически выполняем эту простую команду в нашем конвейере CI / CD перед командой развертывания:

sed -i -E "s/^appVersion: (.*)/appVersion: ${deploy.project.version}/" ${chartPath}/Chart.yaml

Это сложно, но работает так, как ожидалось.

@bvis
Проблема с вашим обходным путем заключается в том, что вам нужно отредактировать диаграмму в конвейере CI / CD.
Если вы используете централизованное репо для графиков, вы вынуждены использовать helm pull repo/chart --untar

Есть ли дальнейший прогресс с программным внедрением Chart.yaml / appVersion? Есть ли обходные пути? Это дало бы огромный импульс CI / CD Helm.

@jakovistuk, насколько я могу судить, диаграммы, которые используют appVersion для отображения версии контейнера, делают это напрямую через Chart.yaml, как видно, например, в nginx-ingress / Chart.yaml ...

Я довольно долго не задумывался об этой проблеме, так что это может быть действительно глупый вопрос, но есть ли способ использовать Helm CLI для переопределения appVersion?

Похоже, многие здесь спрашивают, как переопределить поле appVersion. Первоначальное намерение / запрос в этой проблеме состоит в том, чтобы разрешить -app-version в качестве замены -version, чтобы пользователь мог запустить 'helm fetch —app-version = v0.15.0', и Helm определил бы, какая последняя версия диаграммы была последней. указал v0.15.0 как appVersion и получите это.

В нашем проекте / диаграмме (cert-manager) мы хотим, чтобы конечным пользователям было как можно более понятно, какую версию они устанавливают, поэтому разрешение на установку по версии приложения вместо версии диаграммы было бы гораздо более естественным процессом установки.

Тем не менее, эта проблема была открыта 2 года назад, и с тех пор мы решили просто синхронизировать оба этих номера версий с синхронизацией / блокировкой. Через пару лет это оказалось на удивление легко и безболезненно, хотя пользователям иногда приходится ждать пару недель нового официального релиза, если в наши манифесты развертывания вносятся изменения.

Учитывая возраст этой проблемы, ее длину, огромное количество немного разных гейтов функций и изменения в проекте Helm с тех пор (Helm 3, диаграммы OCI и т. Д.), Я не думаю, что эта проблема находится в хорошем состоянии. быть продвинутым как запрос функции в его текущей форме. Я собираюсь закрыть этот вопрос, но всем, у кого есть похожий запрос на функцию, лучше всего открыть новый выпуск и

Я также думаю, что такая функциональность может быть и, вероятно, лучше всего реализована как внешний инструмент или оболочка вокруг
Helm, особенно с учетом изменений OCI, которые, как мне кажется, усложнили бы реализацию.

Пока это не решено (или нет) Вот как я решил это в моем CI / CD (GitLab):

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

deploy:
  image: alpine/helm:3.2.4
  stage: deploy
  environment:
    name: ${ENV}
  script:
    - helm package --app-version=${CI_COMMIT_TAG} --version=${CI_COMMIT_TAG} ${NAMESPACE}
    -  | 
       helm upgrade -i --wait ${CI_PROJECT_NAME} ./${NAMESPACE}-${CI_COMMIT_TAG}.tgz \
       --set image.repository="${CI_REGISTRY_IMAGE}" \
       --set image.tag="${CI_COMMIT_TAG}" \
       --set-string ingress.enabled="${INGRESS}" \
       --set service.port="${CONTAINER_PORT}" \
       --set service.targetPort="${CONTAINER_PORT}" \
       --set dc="${CI_ENVIRONMENT_NAME}" \
       --set project="${CI_PROJECT_NAME}" \
       --namespace ${NAMESPACE}
    - helm history ${CI_PROJECT_NAME} -n ${NAMESPACE}
  tags:
    - kubernetes
  only:
    - tags

Если по умолчанию для image.tag значение {{ .Chart.AppVersion }} тогда вам не потребуется --set во время установки, это уже будет правильно. Это также хорошо работает для автоматической сборки, когда ваши образы Docker помечены с помощью SHA1, поэтому AppVersion соответствует тегу образа Docker, а версия - это SemVer с автоматической сборкой.

Нет проблем с версией, совпадающей с AppVersion, если ваша версия AppVersion является SemVer.

Для пакетов, созданных моей командой, мы движемся к вещам, которые ищут AppVersion, например image.tag, по умолчанию используется версия, если AppVersion не установлен. Это не большая разница, просто на один аргумент меньше helm package для выпусков с тегами, но имеет смысл только в том случае, если ваша диаграмма построена из того же SCM, что и вещь, которую вы упаковываете.

@TBBle , который не будет работать, если вы используете

Вы имеете в виду, что image.tag находится на вложенной диаграмме, но вы пытаетесь использовать версию родительской диаграммы? Если так, то да, это очень неудобно, и с этим будет нелегко справиться. Я только что отскочил именно от этого макета в https://github.com/googleforgames/open-match/ диаграммах Helm. В этом случае я предлагаю откатить рассматриваемые поддиаграммы обратно в основную диаграмму.

Диаграммы должны быть независимо изолированными / используемыми единицами, не полагающимися на поведение родительской диаграммы. Подграфик имеет свою собственную версию, _это_ та, ​​которую должны использовать его изображения, иначе почему это подграфик?

В случае Open Match, поддиаграммы используются так, что XXX.enable можно использовать в качестве ярлыка в values.yaml для одновременного отключения кучи вещей, но тогда это приводит к ряду структурных проблем, подобных этой . Все поддиаграммы Open Match интенсивно используют родительскую диаграмму с именем templates, а также имеют локальную версию 0.0.0-dev , так что уже есть два запаха кода, что что-то плохо структурировано.

Или, возможно, я неправильно понял ваше наблюдение.

@haimari К сожалению, это не работает (относится к https://github.com/helm/helm/issues/6921?):

> helm package $DIR/deployment/chart --app-version="1111e8" --version="3454e5" --namespace stage
Error: Invalid Semantic Version

Но это работает:

> helm package $DIR/deployment/chart --app-version="0.0.0-1111e8" --version="0.0.0-3454e5" --namespace stage
Successfully packaged chart and saved it to: /Users/aws/service-0.0.0-3454e5.tgz

и даже это (но кажется грязным):

> helm package $DIR/deployment/chart --app-version="0-1111e8" --version="0-3454e5" --namespace stage
Successfully packaged chart and saved it to: /Users/aws/service-0-3454e5.tgz

версия helm version.BuildInfo {Версия: "v3.4.0", GitCommit: "7090a89efc8a18f3d8178bf47d2462450349a004", GitTreeState: "dirty", GoVersion: "go1.15.3"}

Я думаю, что решение @haimari как есть, работает только потому, что они используют теги, совместимые с semver, в своем конвейере CI (т.е. это будет пример выполнения задания для выпусков с тегами, а не для выполнения при каждой фиксации)

@ a0s : Обычно я предлагаю:

helm package $DIR/deployment/chart --app-version="<container image tag>" --version="<semver version>"

И тогда значение тега изображения контейнера должно быть чем-то вроде {{ Values.image.tag | default .Chart.AppVersion | default .Chart.Version , чтобы вам не нужно было менять его на лету, как это делает

В ваших примерах у вас есть две разные версии git, верно? Один для изображения контейнера, а другой для диаграммы?

С помощью SemVer вы не можете поместить SHA-код git commit в значимую часть semver, потому что semver подразумевает упорядочение, а SHA-ключи git commit не сортируются.

Таким образом, вы захотите использовать версию, например 0.0.1-alpha.<build-id>+g<gitcommitsha> где <build-id> - это что-то вроде идентификатора конвейера или задания из вашей системы CI, поэтому вы всегда делаете это для своего проекта. Таким образом, вы всегда получите последнюю сборку, когда захотите.

В SemVer использование - означает, что это предварительный выпуск для этой версии, поэтому 0.0.1-<anything> находится между выпусками 0.0.0 и 0.0.1. Часть после + - это информация о сборке, и она игнорируется для сортировки, поэтому хорошее место для размещения git SHA или имен веток или другой информации отслеживания, не подлежащей сортировке.

Итак, с тем, что вы использовали здесь, 0-3454e5 будет выглядеть новее, чем следующий коммит, если его SHA начинается с 2 , например, 0-2764e1 .

В ваших примерах у вас есть две разные версии git, верно? Один для изображения контейнера, а другой для диаграммы?

Да, приложение и диаграмма - это две независимые части программного обеспечения.

Таким образом, вы всегда получите последнюю сборку, когда захотите.

Что делать, если я не хочу (и даже не могу себе представить) просить последнюю информацию.

0.0.1-alpha.<build-id>+g<gitcommitsha>

Эта строка (после интерполяции) кажется слишком длинной, чтобы поместиться в один столбец стандартного вывода helm list :)

Я всегда знаю, какую версию (sha hash) приложения я хочу установить (передайте ее с помощью --set args). И я всегда знаю, какую версию диаграммы я использую (как описано в @haimari , я всегда буду использовать git checkout chart && helm pack && helm upgrade .tar.gz локально в моем ci / cd)

Что может пойти не так?
1) Ошибка при обычном helm upgrade . Хорошо, я исправлю ошибку и попробую еще раз (с другой фиксацией приложения - 99%) (или используя вместо этого --atomic )
2) Ручной откат: helm rollback <RELEASE_NAME> или развертывание предыдущего sha commit через CI / CD.

Что я упустил?

PS Честно говоря, я хочу использовать короткую часть sha в версии и app-version только в информационных целях (в течение helm list )

Если это просто для информационных целей, то оно идет после + в SemVer, а не - . Если вы _ никогда_ не заботитесь об упорядочивании выпусков или передаче диаграмм Helm кому-либо, а ваша диаграмма или приложение еще не SemVer'd, тогда 0+g<commitsha> является допустимым SemVer (эквивалент 0.0.0).

Это то, что, например, делают автоматически построенные графики Open Match Helm; все они в настоящее время 0.0.0-dev , и мы начали думать о создании этого 0.0.0-dev+g<commitsha> чтобы, если вы смотрите на то, что вы установили, вы могли по крайней мере сказать _какую_ мастер-сборку у вас есть.