S
Именно для апплая, не для генерации?
Pre sync хуки не подойдут?
Size: a a a
2020 September 02
k
Pre sync хуки не подойдут?
не уверен что оно в кластер пустит что-то сделать
GG
Все кубомонстры вышли в онлайн
GG
Не просто чат читал перед сном
Личный вопрос есть - вы VMware pks рассматриваете и/или используете ?
S
не уверен что оно в кластер пустит что-то сделать
https://argoproj.github.io/argo-cd/user-guide/resource_hooks/ не то что тебе надо?
S
Личный вопрос есть - вы VMware pks рассматриваете и/или используете ?
Не использую но могу наверное на какой то вопрос ответить
GG
Не использую но могу наверное на какой то вопрос ответить
Все, вас понял 👌
k
https://argoproj.github.io/argo-cd/user-guide/resource_hooks/ не то что тебе надо?
Ну это как бы джобы, их можно и во время деплоя нагенерить. с
annotations:будет примерно тоже самое
helm.sh/hook: pre-upgrade
helm.sh/hook-delete-policy: hook-succeeded
GG
Ну это как бы джобы, их можно и во время деплоя нагенерить. с
annotations:будет примерно тоже самое
helm.sh/hook: pre-upgrade
helm.sh/hook-delete-policy: hook-succeeded
Можно, но, наверное, не стоит
GG
Аргумент: пускай хельм остаётся «пакетным менеджером» (читай: шаблонизатором), а вся история с «развесистыми» воркфлоу (а зачем ещё эти хуки могут быть нужны) едет в Argo?
k
но должен признаться, мне такой подход нравится даже больше. Лучше иметь стандартизированное API для деплоя, чем нести свою кастомню логику по деплою в куб.
k
Аргумент: пускай хельм остаётся «пакетным менеджером» (читай: шаблонизатором), а вся история с «развесистыми» воркфлоу (а зачем ещё эти хуки могут быть нужны) едет в Argo?
Так хелм и используется в арго в качестве шаблонизатора, прикол в том, что эти "хелм-хуки" самим арго обрабатываются
k
То есть даже когда деплоишь хелм-релизы через арго, то в
helm ls они не видны.GG
То есть даже когда деплоишь хелм-релизы через арго, то в
helm ls они не видны.Действительно, зачем надо видеть хельм релизы, если ты приложения видишь в панели арго
k
Аргумент: пускай хельм остаётся «пакетным менеджером» (читай: шаблонизатором), а вся история с «развесистыми» воркфлоу (а зачем ещё эти хуки могут быть нужны) едет в Argo?
Вставлю своё "фе":
Я был бы рад обойтись без хелм-хуков и полагаться только на логику Kubernetes, для лучшей переносимости и прочего, но на данный момент Kubernetes не позволяет добиться похожего поведения используя стандартные утилиты.
Про immutable job'ы я уже писал, хотя этого могло бы быть достаточно.
Я был бы рад обойтись без хелм-хуков и полагаться только на логику Kubernetes, для лучшей переносимости и прочего, но на данный момент Kubernetes не позволяет добиться похожего поведения используя стандартные утилиты.
Про immutable job'ы я уже писал, хотя этого могло бы быть достаточно.
GG
Единственный кейс, когда ты захочешь в релизы - это когда у тебя арго и хельм одновременно сломаются
k
Действительно, зачем надо видеть хельм релизы, если ты приложения видишь в панели арго
ну когда ты деплоишь flux'ом, то все релизы через helm-operator применяются и в
helm ls они видныGG
ну когда ты деплоишь flux'ом, то все релизы через helm-operator применяются и в
helm ls они видныНу, это разница Флакс и арго. Flux v2 я не тыкал, но не похоже, что там будет принципиально другое
k
Единственный кейс, когда ты захочешь в релизы - это когда у тебя арго и хельм одновременно сломаются
Да, я предпочёл бы иметь запасной путь "поправить релиз руками", если с арго внезапно что-то случится
S
У нас все чарты/кустомайзы рендарятся в ci и арго синкает уже всё готовое из Стейт репы. Изменения в Стейт репу соответственно доставляются prом. В принципе соответствует тому что написано тут https://cloud.google.com/solutions/safe-rollouts-with-anthos-config-management