Comments 29
Класс, то что надо! А статику я так понимаю вы храните не в папке проекта? Или симлинк стоит?
Статика хранится в подпапке media и отдаётся напрямую через nginx. Сейчас, правда, это уже не модно, но проект создавался ещё во времена django 1.2, когда staticfiles был не так популярен)
Я просто недавно на джанго. У меня 2 копии проекта — одна работает, вторая на тесте (ее можно перезапускать). При апдейте меняю конфиг nginx. Я так понимаю у вас одна папка — вы заливаете апдейт — потом перезапускаете graceful-ом, так?
Тестовая версия может жить совсем в другом месте. Когда нужно обновить боевую копию, я просто делаю там:
и нет нужды править конфиг сервера или перезапускать его.
$ git pull
$ ./manage.py updateи нет нужды править конфиг сервера или перезапускать его.
Спасибо, по исследую еще.
Если я правильно понял, то у вас две копии проекта на одной и той же машине и они по очереди меняются ролями. Если у них при этом ещё и общая база, то это может вызвать проблемы, когда очередной апдейт затрагивает структуру таблиц. Извиняюсь, если понял неправильно)
Наша тестовая версия, например, живёт на отдельной виртуалке и у неё в manage.py есть команда clone, которая по ssh дампит боевую базу и ресторит её локально, а также синхронизирует загруженные пользователями файлы.
Наша тестовая версия, например, живёт на отдельной виртуалке и у неё в manage.py есть команда clone, которая по ssh дампит боевую базу и ресторит её локально, а также синхронизирует загруженные пользователями файлы.
Спасибо!
docs.djangoproject.com/en/dev/howto/static-files/
какая разница где она хранится, главное что отдавать её питоном глупо
какая разница где она хранится, главное что отдавать её питоном глупо
альтернативой fastcgi является uwsgi, у которого есть прекрасная опция touch-reload, после деплоя на сервер новой версии проекта вам всего лишь надо сделать touch определенного файла (указанного в конфиге uwsgi) и ваш проект мягко перезапустится, данную схему удобно применять в составе автоматизированного деплоя (например через ant). детали: goo.gl/uluY9
Отличное решение. Долгое время работали с FastCGI, и возникала проблема другого рода, часть тяжелого кода могла не успеть выполнится до момента перезапуска процесса и это могло породить разные баги. Но с ошибками 502 не было проблем, т.к. балансер nginx в этом случае перекидывал на другой сервер клиента(по сути то что вы решили на одном сервере через симлинки).
Но теперь перевели на uwsgi — там gracefull рестарт из коробки работает и в целом он более гибок.
Но теперь перевели на uwsgi — там gracefull рестарт из коробки работает и в целом он более гибок.
Спасибо за статью!
Мы как раз сейчас работаем над похожей проблемой, только нам нужно более универсальное решение. В результате сталкнулись с такой проблемой — непонятно что делать с миграциями данных.
В общем случае если приложение работает с какими ни будь глобальными данными, например БД, и протокол работы поменялся, то может возникнуть проблема целостности данных. Если одновременно в какой-то момент будут работать две версии приложения с разными протоколами доступа к данным, то данные могут бать повреждены.
Как решить — пока непонятно. Может я параноик и на самом деле нет никакой проблемы?
Мы как раз сейчас работаем над похожей проблемой, только нам нужно более универсальное решение. В результате сталкнулись с такой проблемой — непонятно что делать с миграциями данных.
В общем случае если приложение работает с какими ни будь глобальными данными, например БД, и протокол работы поменялся, то может возникнуть проблема целостности данных. Если одновременно в какой-то момент будут работать две версии приложения с разными протоколами доступа к данным, то данные могут бать повреждены.
Как решить — пока непонятно. Может я параноик и на самом деле нет никакой проблемы?
Тоже задумывался об этом, но ничего лучшего, чем выкатывать меняющие протокол апдейты в часы минимальной загруженности, пока не придумал.
Думаю в этом случае кратковременное отключение безболезненней чем нарушение целостности данных.
Кратковременное отключение тут может не спасти: пользователь мог открыть сайт и уйти на обед, а по приходу инициировать выполнение какого-то ajax-запроса, обработчик которого с тех пор мог поменяться. Тут нужен какой-то принципиально другой подход.
Как я понял проблема в том, что во время обновления запрос может попасть к «старому» процессу, хотя в этот момент структура данных (на стороне ДБ) может уже изменится.
Ну да, это даже в первую очередь.
Кругом засада. В голову лезут только очень сложные решения.
Ну можно ввести на сайте «режим апдейта», когда вместо всех страниц будет показываться заглушки, а на все ajax запросы будет отдаваться типовая ошибка «обновите страницу». Этот режим будет активироваться на старом процессе перед выполнением миграции базы данных, а затем сразу выключаться (т. е. работать он чаще всего будет меньше секунды). Теоретически, это должно защитить от ошибок, про которые писал Jimmy.
Это проблема относится к сайтам в общности… Такие возможные ошибки надо учитывать в архитектуре самого сайта. Например в ajax передавать версию и сравнивать ее с какой была загружена страница.
По-моему, стоит всем командам дать какой-то префикс. А то слишком стандартно выглядят (тот же start) — не знающий человек может чего-нибудь перепутать.
деплою восновном через nginx + uwsgi/gunicorn последний редко но случается.
Меня в «мягком» деплое всегда беспокоят две вещи:
а) миграция базы
б) изменение шаблонов/статики
как ни крути, между началом деплоя и его завершением, проходит пара минут, в течении которых эти вещи находятся в непонятном состоянии.
нет ли у кого-нибудь толковых наработок/ссылок по этим пунктам?
а) миграция базы
б) изменение шаблонов/статики
как ни крути, между началом деплоя и его завершением, проходит пара минут, в течении которых эти вещи находятся в непонятном состоянии.
нет ли у кого-нибудь толковых наработок/ссылок по этим пунктам?
Иногда бывает, что выкатывается код с ошибкой. В этом случае инстанс взлетает и тут же падает. И так каждую минуту. Поэтому мой вам совет — сделайте логирование стартов в отдельный лог. Чтобы по нему можно было увидеть, что происходит (ну и что происходило).
Использую вашу библиотеку уже порядка 2х месяцев.
Большое спасибо! Отличное решение, все работает как часы :)
Большое спасибо! Отличное решение, все работает как часы :)
Sign up to leave a comment.
Плавный перезапуск FastCGI-процессов — django_graceful