Развертывание (единственного node) веб-приложения Django с практически нулевым временем простоя на EC2

Ответ 1

Что может заинтересовать, это техника под названием Canary Releasing. В прошлом году я увидел отличную презентацию Jez Humble на конференции по программному обеспечению в Амстердаме; речь шла о выпуске с низким уровнем риска, слайды здесь.

Идея состоит в том, чтобы не переключать сразу все системы, а отправлять небольшой набор пользователей в новую версию. Только когда все показатели производительности новых систем, как и ожидалось, переключились на другие. Я знаю, что этот метод также используется большими сайтами, такими как facebook.

Ответ 2

Живой сервер не должен мигрировать. Этот сервер должен быть доступен с двух промежуточных серверов, server0 и server1. Первоначально сервер0 является живым, и изменения вносятся в server1. Когда вы хотите сменить программное обеспечение, переключитесь на живые серверы. Что касается нового контента, это не должно быть на промежуточном сервере. Это должно быть на реальном сервере. Добавьте столбец в свои таблицы с номером версии для таблиц содержимого и измените базу кода, чтобы использовать правильный номер версии контента. Разрабатывайте программное обеспечение для копирования старых версий в новые строки с обновленными номерами версий по мере необходимости. Поместите текущий номер версии в свои settings.py на server0 и server1, чтобы у вас было центральное место для программного обеспечения, которое можно было бы использовать при выборе данных, или создать приложение для доступа к базе данных, которое можно обновить, чтобы получить правильные версии контента. Конечно, для файлов шаблонов они могут быть на каждом сервере и будут подходящими.

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

Ответ 3

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

Почему вы создаете новый сервер в первую очередь? Почему бы не перенести базу данных на место (конечно, после того, как вы тщательно протестировали миграцию), и, как только это будет сделано, обновите код и "перезапустите" свои процессы (например, gunicorn может принять сигнал HUP, который сделает он перезагружает приложение, не отбрасывая соединения в очереди).

Во многих миграциях не будет необходимости блокировать таблицы базы данных, поэтому это безопасно. Для остальных есть другие способы сделать это. Например, если вы хотите добавить новый столбец, который должен быть заполнен с правильными данными, вы можете сделать это в следующих шагах (кратко описано):

• Добавьте столбец как принимающий значения NULL и сделайте запись django в этот столбец, чтобы новые записи имели правильные данные.
• Заполните заполняющие записи.
• Создайте django для чтения из нового столбца.

Ответ 4

Чтобы достичь 0 времени простоя, вы должны иметь как минимум 2 сервера + балансировщик. И обновляйте их последовательно. Если вы хотите обновить как базу данных, так и приложение - и иметь 0 простоя - у вас должно быть 2 сервера db. Никаких чудес, ни серебряной пули, ни джанго вы не уйдете из проблем с развертыванием.