Комментарии 3
Очень крутая статья, спасибо!
Из стати не совсем понял в какой момент вы накатываете миграции БД? В момент деплоя или в момент старта приложения? И почему именно такой способ?
Есть ли у вас какой-то отдельный процесс ревью миграций (а то вдруг кто-то захочет добавить индекс на проде в не concurrently режиме)?
Доброе утро!

Как коллега Саши, давайте я попробую ответить.

В большинстве сервисов миграции запускаются в одном из init-контейнеров.
При этом свежие поды недоступны, пока не пройдёт redinessProbe, в этом заключается очевидное преимущество такого подхода.

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

Если же ваш фреймворк поддерживает накат миграций при старте приложения — отлично, вы можете использовать и этот способ. Тогда убедитесь, что redinessProbe на новых подах не будет проходить до тех пор, пока база не будет приведена в ожидаемое состояние. Очень часто эндпоинты проверки (/info, /health, /healtz — не важно, как называется) не проверяют готовность, просто отвечают кодом 200.

Что же касается ревью самих миграций.
Большинство миграций содержат в себе определения новых таблиц — с этой задачей справится любой разработчик.
Когда требуется, на помощь приходит команда DBA.
Они же следят (благодаря мониторингу) за состоянием индексов, что-то перестраивают, что-то удаляют.
Поэтому построение/перестроение индекса в concurrenly-режиме — скорее исключение, чем правило.

Надеюсь, получилось ответить на Ваши вопросы.

Спасибо за статью! Узнал много интересного.


Получается, helmgen нынче не имеет отношения к helm?


Вообще, главный минус PaaS, на мой взгляд, в том, что все равно нужно разбираться, как устроена нижележащая инфраструктура. Только теперь ее "прячет" PaaS, с соответствующими последствиями: неполной документацией и неожиданными изменениями. Для простых кейсов PaaS упрощает жизнь, позволяет быстрее онбордиться. Но как только что-то пойдет не так — тут платформа больше мешает, чем помогает. Например, дашборд позволяет настроить секреты для Prod и Non-prod. ОК, тогда почему окружение для нагрузочных тестов не видит секретов ни из Prod, ни из Non-prod? Как в него передать секреты? Через платформу — никак! Только разбираться с vault.


Думаю, это системная проблема любой PaaS. Единственный способ борьбы — доводить стабильность фичей до идеальной, чтобы разработчику не приходилось лезть под платформу вообще.


И вот вам фича реквест заодно: сделайте перевыкатку сервиса из того образа, который уже в проде. Сейчас 24/7 вынуждены пересобирать сервис из мастера с непредсказуемыми последствиями. Имхо, достаточно научить rollback перевыкатывать текущую версию, а не только предыдущие.

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Информация

Дата основания
2007
Местоположение
Россия
Сайт
avito.tech
Численность
1 001–5 000 человек
Дата регистрации

Блог на Хабре