django + virtualenv = атомное обновление - возможно ли это?

Question

У меня есть проект Django, работающий внутри virtualenv без пакетов сайтов. Когда дело доходит до ввода моих новых изменений на сервер, я хотел бы создать новый каталог virtualenv, установить мой проект и все его зависимости, а затем быстро переименовать два каталога virtualenv ТОЛЬКО, если новый код будет успешно развернут.

Все отлично работает на бумаге, пока вы не переименуете каталог virtualevn. Параметр Relocate на virtualenv не является надежным в соответствии с его документацией.

Как вы предлагаете модернизировать мой проект ТОЛЬКО, если новый код окажется пригодным для развертывания.

Вот шаги:

# fab update_server to run the following: 
cd /srv/myvenv # existing instance 
cd ../ 
virtualenv myenv-1 
source myenv-1/bin/activate 
git co http://my.com/project 
pip install -r project/req.txt 
# all worked 
mv myenv myenv-2; mv myenv-1 myenv 
touch /path/proj.wsgi # have apache to reload us 

выше совершенен, но переименование или перемещение virtualenv не является надежным.

Обновление сайта в режиме myvenv требует времени и может также сломать сайт.

Как вы это сделаете? Строить?

Answer 1

Я делаю это с символическими ссылками и полностью отдельными каталогами релизов. Т.е. развертывание включает клонирование всего проекта в новый каталог, построение виртуального пространства внутри него, а затем переключение символической ссылки «production» в точку в этом каталоге.

Моя раскладка в основном

/var/www/myapp/ 
       uploads/ 
       tmp/ 
       releases/ 
         001/myapp/ 
         002/myapp/ 
         003/myapp/ 
           ve/ 
           ...etc in each release directory... 
       myapp # symlink to releases/003/myapp/ 

Так что, когда я раскрываю к производству, мои сценарии развертывания RSync совершенно новая копия на /var/www/myapp/releases/004/myapp/, построить virtualenv там, установить все пакеты в него, а затем

rm -f /var/www/myapp/myapp 
ln -s /var/www/myapp/releases/004/myapp/ /var/www/myapp/myapp 

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

Каждая внешняя ссылка (в файлах конфигурации apache или wsgi-файлах или что-то еще) указывает на библиотеки и двоичные файлы в virtualenv как /var/www/myapp/myapp/ve/. Я также избегаю использования source ve/bin/activate и вместо этого укажу на полный путь в файлах конфигурации, и я редактирую manage.py, чтобы использовать #!ve/bin/python, поэтому я могу запускать команды с ./manage.py whatever, и он будет работать без меня, если я буду помнить, активировал ли я виртуальный виртуальный.