Коллеги, всем привет! =)
Небольшой экскурс про то как катить миграции баз данных приложений которые развернуты в k8s.
Очень часто на просторах интернетов вы можете столкнуться к тем, что катить миграции предлагают при помощи инит контайнеров в подах. План надежный как швейцарские часы, но есть одно большое НО😤
Миграции в случае использования инит контейнеров будут прокатываться всегда, например когда вы поскейлили количество подов или отработал HPA. И потенциально миграции могут приводить к локам таблиц БД, что в проде, да еще в рабочее время максимально не весело.
Как еще есть варианты?
Конечно же использовать jobs в k8s.
Суть заключается в том, что “джоба” эта такая сущность, которая может отработать только один раз. Соотвественно у нас не будет проблем с повторной накаткой миграций.
Ну сделали мы джобу, а дальше то что? Как сделать так что бы джоба отрабатывала перед началом, к примеру обновления, самого приложения?
В случае с helm нам на помощь придут helm hooks
В нашем случае, нам прекрасно подойдет pre-install и pre-upgrade.
И если вы проставите эти хуки в аннотация соотвествующих ресурсов, а мы с вами говорим про джобы, то эти ресурсы будут задеплоины первыми и уже после них будут задеплоины оставшиеся ресурсы.
Зачем я это пишу - обновлял я тут defectdojo в k8s и что-то пошло не так. Посмотрел, хуки на месте, install и upgrade. Посмотрел внимательно, а хуки то post-install и post-upgrade, то есть миграции defectdojo исходя из конфига должны отрабатывать после всех действий. И все благополучно падало =)
Post #74
962
- 🔥 7
- ❤ 3
- 😁 2
- 👍 1