Django в Kubernetes Deployment: лучшие практики для миграции баз данных

Question

В моем Django развертывании имеется x количество модулей (3 в настоящее время), на которых работает сервер Django REST API. Мы все еще на стадии разработки / постановки. Я хотел спросить совета относительно миграции БД. Прямо сейчас модули запускаются с запуска веб-сервера, предполагая, что база данных перенесена и готова. Это предположение может быть ошибочным, конечно.

Можно ли просто поставить python manage.py migrate перед запуском сервера? Что произойдет, если 2 или 3 модуля запускаются одновременно и все миграции выполняются одновременно? будет ли какой-либо потенциальный ущерб или проблема от этого? Есть ли здесь рекомендуемый шаблон, чтобы все модули запускали сервер с исправной перенастроенной базой данных?

Я думал об этом:

Во время первоначального развертывания определите объект Kubernetes Job, который будет запущен один раз после того, как модуль базы данных будет готов. Он будет использовать тот же Django контейнер, который у меня есть, и просто запустит python manage.py migrate. сценарий, который развертывает, будет kubectl wait для этого модуля работы до fini sh, а затем применяет yaml, который создает полное развертывание Django. Это обеспечит «пробуждение» всех django модулей с полностью перенастроенной базой данных.

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

Теперь возникает вопрос о курице и яйце и поддержании 100% безотказной работы во время работы. миграция, но это вопрос для другого поста: как вы применяете миграции данных, которые ломают существующий контейнер версии X, когда код для работы с новыми миграциями обновляется в контейнере версии X + 1. Вы отключаете весь сервис на время обновления? Есть ли шаблон для поддержания работоспособности сервиса?

Answer 1

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

Но это не вызовет никаких проблем. Когда вы собираетесь внести реальные изменения в вашу базу данных, если изменения уже применяются, ваши изменения будут игнорироваться. Итак, скажем, 3 модуля запускаются одновременно и запускают команду migrate. Только One из этих команд приведет к внесению изменений в базу данных. Миграции обычно должны блокировать базу данных для различных действий (это тесно связано с вашей СУБД). Блокировка произойдет одной из команд migrate (одной из модулей), а другие команды должны дождаться окончания работы первой из них. После того, как задание выполнено первым, чужие команды будут автоматически игнорироваться. Таким образом, каждая миграция будет происходить один раз.

Однако вы можете изменить свою стратегию развертывания и попросить kubernetes сначала развернуть только 1 модуль, и когда проверка состояния первого модуля пройдет успешно, другие также будут ускорены. В этом случае вы можете быть уверены, что время блокировки для миграции произойдет только один раз, а другие просто проверят, что миграции уже применены, и автоматически проигнорируют их.