Коллеги, у меня тут возникла одна очень интересная задачка. Есть

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

Добрый день, у вас задача часто выкатывать фронт?

Ага. По несколько раз в день. В песочницу.

Будто бы проще сделать выкат раздельным на уровне CI.

Так а как выкат зависит? Хуку всё равно. Бандлом выкатывается.

А хук у вас какого плана?

обычный helm hook в виде джобы.

А, я понял. Подумал про webhook.

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

@ilya_lesikov глянь пожалуйста, как время будет.

Могу предложить такой велосипед: обернуть Job в if-условие, в условии должна проверяться версия образа бэкенда в текущем деплойменте, которую теоретически можно взять с помощью lookup-функции , с версией нового релиза

Интересно, может средствами CI детектить изменения до сборки образа? И в зависимости от этого выкатывать только то что нужно

Можно попробовать такой вариант: # .helm/templates/migrate.yaml kind: Job metadata: # "v1" in the name must be changed everytime Job spec is changed name: migrate-{{ include (print $.Template.BasePath "/backend.yaml") . | sha256sum | trunc 10 }}-v1 annotations: helm.sh/hook: ... helm.sh/hook-delete-policy: "" # .helm/templates/backend.yaml kind: Deployment metadata: name: backend # .helm/templates/frontend.yaml kind: Deployment metadata: name: frontend Так каждый раз при изменении backend.yaml будет меняться имя у Job, вызывая её перекат. Если же манифест джобы (включая её имя) не изменился, её выкат будет пропущен — так умеет werf 2.0. Единственное неудобство это то, что при изменении spec самой джобы, надо будет v1 в её имени поменять на что-то ещё, иначе получите ошибку "не можем обновить Job, т. к. она иммутабельна". Мы планировали добавить что-то вроде "werf.io/deploy-policy: recreateOnImmutableError", но пока не добрались.

В общем, я попробовал, но у меня почему-то всё равно покатилась миграция. Я даже больше скажу, раньше было название просто migrate без суффикса и всё равно катилось каждый раз. Или должно было завестись на связь с другим шаблоном? Но не завелось, просто выкатилось снова. Версия 2.4 была. Но у меня: annotations: "helm.sh/hook": "pre-install, pre-upgrade" "helm.sh/hook-delete-policy": "before-hook-creation"

Дак надо выставить "helm.sh/hook-delete-policy": "". before-hook-creation буквально значит "пересоздавай этот ресурс каждый раз при выкате". Мы в теории могли бы пропускать пересоздания, если ничего в релизе не изменилось и ничего не надо обновлять в кластере, но это может сломать обратную совместимость — что если пользователь чарта ожидает, что его хук будет обязательно запускаться при werf converge? Поэтому эта аннотация всегда форсирует новый релиз и пересоздание ресурса.

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

"helm.sh/hook-delete-policy": "hook-succeeded,hook-failed"

А как историю последнего запуска сохранить? Миграция упадёт и как узнать почему?

Пойти в логи посмотреть?

"helm.sh/hook-delete-policy": "hook-succeeded"

Если джоба исчезнет, то и логов не будет.

Тогда плодиться будут на каждую миграцию)) Вот в этом и задача.

логи должны собираться во внешнее хранилище: Loki, эластик, вотэвер. И там они всегда будут.

Кому они должны?🙃

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

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