Запуск команд в процессе доставки нового релиза приложения в Kubernetes

[gecube]

Вопросы из зала:

• насколько жизненно необходимо выносить миграции в отдельный под? Тем более, если мы делаем zero-downtime деплой? Какие минусы, если миграции будут выполняться в основном деплойменте и не он зажжет готовность, пока они не пройдут (а, следовательно, и роллаут дальше не пройдет)? Какие аргументы можно привести разработчикам в пользу того, что миграции нужно выносить наружу?

У коллег из Weave есть аналогичная статья, но она описывает более высокоуровневые вещи, а в настоящей статье — подкапотная машинерия больше.

Ну, и интересно выглядит идея использовать оператор для этой машинерии — вроде https://github.com/quay/dba-operator

[konstantin_axenov]

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

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

[gecube]

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

> Liquibase does implement an exclusive lock, using the ACID transactional features of your RDBMS. This prevents multiple instances of Liquibase from performing schema migrations concurrently. It is accomplished by doing transactional updates to the DATABASECHANGELOGLOCK table that is added to your schema by Liquibase.

stackoverflow.com/a/25785040/698689

Поэтому даже в роллинг апдейте пачками со встроенными миграциям ничего плохого не должно случиться. Если же используемый фреймворк для наката миграций не обладает такой функциональностью — ну, что ж, придется самому дейтвительно выносить миграции в отдельный под и обеспечивать руками семантику «at most one»

[konstantin_axenov]

Я уверен, что есть много фреймворков, в которых данная проблема решена. Также я уверен в том, что данная проблема встречается в каком-то числе фреймворков, особенно в старых. Вот, например, обсуждение для laravel github.com/laravel/ideas/issues/1645

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

[JenoOvchi]

Есть ощущение, что для оркестрации всех этих дел логичнее задействовать Tekton — гибче и универсальнее.

[gecube]

очень… специфичная штука… вообще все что делают парни из гугла… специфичное…
Чего тогда не ArgoCD?
Кстати, они по ходу с Flux объединяются:
https://www.weave.works/blog/argo-flux-join-forces
https://discuss.kubernetes.io/t/flux-cd-joins-forces-with-argo-cd-project/8678
https://www.youtube.com/watch?v=dNcyLNFd3lk
https://www.intuit.com/blog/technology/introducing-argo-flux/

[JenoOvchi]

Можно и Argo или ещё какую-то GitOps штуку. По моим ощущениям Tekton в фаворе — на него и OpenShift переезжает вместо Jenkins, и, собственно, Jenkins X его может использовать в качестве движка.

[mobilz]

Приветствую, werf прекрасна, спасибо за вашу работу.
Подскажите по поводу "Запуск миграций до релиза".
Есть кластер, есть отдельно база. Вариант с обновлением кода, потом миграцией, потом траффиком -- подходит, но смущает, что пауза между миграцией и переброской траффика -- существенная, несколько секунд. Тогда как миграция может похерить часть кода в определённых кейсах (например, переименование таблиц итп). Есть какие-то механизмы и обновления кодовой базы и сразу создания нужных подов/ингресов, чтобы после миграции моментально переключить траффик? Или общий совет, подобные кейсы решать в 2 шага (код, понимающий и старые названия таблиц и новые, потом миграция + новый код с новыми таблицами)?

[klamas]

всегда делать "безопасные миграции" и катить в два шага

[mobilz]

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