django + virtualenv = атомарное обновление - возможно ли это? - PullRequest
Новая
       52

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

3 голосов
/ 21 декабря 2011

У меня есть проект 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 занимает много времени и может также сломать сайт.

Как бы вы это сделали? Buildout

1 Ответ

4 голосов
/ 21 декабря 2011

Я делаю это с символическими ссылками и совершенно отдельными каталогами релизов. То есть развертывание включает в себя клонирование всего проекта в новый каталог, создание в нем virtualenv, а затем переключение символической ссылки «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, и это всегда будет работать без необходимости помнить, если Я активировал правильное virtualenv.

...