на сколько я понял, при поднятии нескольких под, возможен в редких случаях лок. Верно? если верно, то как это решается, за исключением вынесение расскатки скриптов в ci? Или если соблюденны все правила : не дублированны id и тд, все должно быть ок? И если я не прав, и все ок, тогда зачем это выносят в трубы?
Подымать сначала одну ноду потом другие, стараться делать грамотные изменения в базе и не удалять поля трижды не подумав
А если я удалю какое то поле и убираю его из кода, получается первая пода уберет, а вторая еще нет, т.е ,надо сначала убрать поле из логики и раскатиться двум подам, а потом еще миграцию, так?
да, несколько релизов нужно сделать в зависимости от логики. первый уберет из кода, второй просто с миграцией
Блэт, ужас какой то, спасибо)
много подов - много веселья)
https://www.liquibase.org/blog/using-liquibase-in-kubernetes
еще норм вариант хуками хелма
As long as the process that has set the LOCKED column to 1 isn’t killed before it has a chance to set back to 0, this works fine. When it’s not working fine, all of the other Liquibase processes (including a newly restarted process on the same machine) will just continue to wait for a 0 value which will never come. Вот, фраза - When it’s not working fine, all of the other Liquibase processes , когда это работает не нормально, то будут проблемы, и вопрос, а когда это начнет работать не нормально? Если вроде как работа с мнопоток есть
В продолжение к теме, подскажите, где почитать или может быть свои практики расскажите про deploy vs startup migration, что популярнее и почему?
Обсуждают сегодня