Комментарии 5
Из стати не совсем понял в какой момент вы накатываете миграции БД? В момент деплоя или в момент старта приложения? И почему именно такой способ?
Есть ли у вас какой-то отдельный процесс ревью миграций (а то вдруг кто-то захочет добавить индекс на проде в не 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 перевыкатывать текущую версию, а не только предыдущие.
Спасибо за статью.
А не планируете ли вы выпустить в опен-сорс своё PaaS решение? Такой российский OpenShift.
Платформа как сервис в Авито: как это устроено