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

На что может быть интересно взглянуть, так это на технику под названием Канарское высвобождение. Я видел великолепную презентацию Джеза Хамбла в прошлом году на конференции по программному обеспечению в Амстердаме; речь шла об релизах с низким уровнем риска, слайды находятся здесь.

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

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

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

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

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

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

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

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