Спасибо! LVM как нельзя кстати. Раз уж теперь можно выбирать ядро и параметры загрузки, не могли бы вы кратко прокомментировать, как в общем случае адаптировать ванильный дистрибутив линукса для работы в вашем облаке? Думаю, многим было бы интересно.
У меня почти получилось завести там gentoo с дополнительного lvm-раздела под вашим рекоммендуемым ядром: всё работало, за исключением того, что утилиты lvm отказывались видеть физические тома:
/dev/xvda1: Not in udev db
Device /dev/xvda1 not found (or ignored by filtering).
Ну можно ввести на сайте «режим апдейта», когда вместо всех страниц будет показываться заглушки, а на все ajax запросы будет отдаваться типовая ошибка «обновите страницу». Этот режим будет активироваться на старом процессе перед выполнением миграции базы данных, а затем сразу выключаться (т. е. работать он чаще всего будет меньше секунды). Теоретически, это должно защитить от ошибок, про которые писал Jimmy.
Кратковременное отключение тут может не спасти: пользователь мог открыть сайт и уйти на обед, а по приходу инициировать выполнение какого-то ajax-запроса, обработчик которого с тех пор мог поменяться. Тут нужен какой-то принципиально другой подход.
Если я правильно понял, то у вас две копии проекта на одной и той же машине и они по очереди меняются ролями. Если у них при этом ещё и общая база, то это может вызвать проблемы, когда очередной апдейт затрагивает структуру таблиц. Извиняюсь, если понял неправильно)
Наша тестовая версия, например, живёт на отдельной виртуалке и у неё в manage.py есть команда clone, которая по ssh дампит боевую базу и ресторит её локально, а также синхронизирует загруженные пользователями файлы.
Тестовая версия может жить совсем в другом месте. Когда нужно обновить боевую копию, я просто делаю там: $ git pull
$ ./manage.py update
и нет нужды править конфиг сервера или перезапускать его.
Статика хранится в подпапке media и отдаётся напрямую через nginx. Сейчас, правда, это уже не модно, но проект создавался ещё во времена django 1.2, когда staticfiles был не так популярен)
Кстати, в OS X Lion Ctrl + Left/Right по умолчанию переключает рабочие столы и браузером не перехватывается. Для перехода по страницам хабратопиков можно использовать Ctrl + Option + Left/Right.
У меня почти получилось завести там gentoo с дополнительного lvm-раздела под вашим рекоммендуемым ядром: всё работало, за исключением того, что утилиты lvm отказывались видеть физические тома:
/dev/xvda1: Not in udev dbDevice /dev/xvda1 not found (or ignored by filtering).
А в dmesg появлялось следующее:
[ 0.382840] blkfront: xvda: barrier: enabled[ 9.854950] blkfront: write barrier: empty xvda op failed
[ 9.854955] blkfront: xvda: barrier: disabled
На ваших адаптированных машинах такого не происходит.
Наша тестовая версия, например, живёт на отдельной виртуалке и у неё в manage.py есть команда clone, которая по ssh дампит боевую базу и ресторит её локально, а также синхронизирует загруженные пользователями файлы.
$ git pull$ ./manage.py update
и нет нужды править конфиг сервера или перезапускать его.
:)
заранее большое спасибо!