Открыть список
Как стать автором
Обновить

Комментарии 29

Класс, то что надо! А статику я так понимаю вы храните не в папке проекта? Или симлинк стоит?
Статика хранится в подпапке media и отдаётся напрямую через nginx. Сейчас, правда, это уже не модно, но проект создавался ещё во времена django 1.2, когда staticfiles был не так популярен)
Я просто недавно на джанго. У меня 2 копии проекта — одна работает, вторая на тесте (ее можно перезапускать). При апдейте меняю конфиг nginx. Я так понимаю у вас одна папка — вы заливаете апдейт — потом перезапускаете graceful-ом, так?
Тестовая версия может жить совсем в другом месте. Когда нужно обновить боевую копию, я просто делаю там:
$ git pull
$ ./manage.py update

и нет нужды править конфиг сервера или перезапускать его.
Спасибо, по исследую еще.
Если я правильно понял, то у вас две копии проекта на одной и той же машине и они по очереди меняются ролями. Если у них при этом ещё и общая база, то это может вызвать проблемы, когда очередной апдейт затрагивает структуру таблиц. Извиняюсь, если понял неправильно)

Наша тестовая версия, например, живёт на отдельной виртуалке и у неё в manage.py есть команда clone, которая по ssh дампит боевую базу и ресторит её локально, а также синхронизирует загруженные пользователями файлы.
Да, базу ручками править приходится. Сайт не очень посещаемый — пока не страшно.
Спасибо!
альтернативой fastcgi является uwsgi, у которого есть прекрасная опция touch-reload, после деплоя на сервер новой версии проекта вам всего лишь надо сделать touch определенного файла (указанного в конфиге uwsgi) и ваш проект мягко перезапустится, данную схему удобно применять в составе автоматизированного деплоя (например через ant). детали: goo.gl/uluY9
Спасибо! Обязательно попробую.
Отличное решение. Долгое время работали с FastCGI, и возникала проблема другого рода, часть тяжелого кода могла не успеть выполнится до момента перезапуска процесса и это могло породить разные баги. Но с ошибками 502 не было проблем, т.к. балансер nginx в этом случае перекидывал на другой сервер клиента(по сути то что вы решили на одном сервере через симлинки).
Но теперь перевели на uwsgi — там gracefull рестарт из коробки работает и в целом он более гибок.
Спасибо, надо тоже посмотреть в сторону uwsgi.
Спасибо за статью!

Мы как раз сейчас работаем над похожей проблемой, только нам нужно более универсальное решение. В результате сталкнулись с такой проблемой — непонятно что делать с миграциями данных.
В общем случае если приложение работает с какими ни будь глобальными данными, например БД, и протокол работы поменялся, то может возникнуть проблема целостности данных. Если одновременно в какой-то момент будут работать две версии приложения с разными протоколами доступа к данным, то данные могут бать повреждены.
Как решить — пока непонятно. Может я параноик и на самом деле нет никакой проблемы?
Тоже задумывался об этом, но ничего лучшего, чем выкатывать меняющие протокол апдейты в часы минимальной загруженности, пока не придумал.
Думаю в этом случае кратковременное отключение безболезненней чем нарушение целостности данных.
Кратковременное отключение тут может не спасти: пользователь мог открыть сайт и уйти на обед, а по приходу инициировать выполнение какого-то ajax-запроса, обработчик которого с тех пор мог поменяться. Тут нужен какой-то принципиально другой подход.
Как я понял проблема в том, что во время обновления запрос может попасть к «старому» процессу, хотя в этот момент структура данных (на стороне ДБ) может уже изменится.
Ну да, это даже в первую очередь.
Кругом засада. В голову лезут только очень сложные решения.
Ну можно ввести на сайте «режим апдейта», когда вместо всех страниц будет показываться заглушки, а на все ajax запросы будет отдаваться типовая ошибка «обновите страницу». Этот режим будет активироваться на старом процессе перед выполнением миграции базы данных, а затем сразу выключаться (т. е. работать он чаще всего будет меньше секунды). Теоретически, это должно защитить от ошибок, про которые писал Jimmy.
Это проблема относится к сайтам в общности… Такие возможные ошибки надо учитывать в архитектуре самого сайта. Например в ajax передавать версию и сравнивать ее с какой была загружена страница.
По-моему, стоит всем командам дать какой-то префикс. А то слишком стандартно выглядят (тот же start) — не знающий человек может чего-нибудь перепутать.
Я пробовал, но с префиксами команды выглядят монструозно немного, да и набирать неудобно. А текущие названия по-моему подходят по смыслу.
деплою восновном через nginx + uwsgi/gunicorn последний редко но случается.
Меня в «мягком» деплое всегда беспокоят две вещи:
а) миграция базы
б) изменение шаблонов/статики

как ни крути, между началом деплоя и его завершением, проходит пара минут, в течении которых эти вещи находятся в непонятном состоянии.

нет ли у кого-нибудь толковых наработок/ссылок по этим пунктам?
Иногда бывает, что выкатывается код с ошибкой. В этом случае инстанс взлетает и тут же падает. И так каждую минуту. Поэтому мой вам совет — сделайте логирование стартов в отдельный лог. Чтобы по нему можно было увидеть, что происходит (ну и что происходило).
Использую вашу библиотеку уже порядка 2х месяцев.
Большое спасибо! Отличное решение, все работает как часы :)
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.