django + virtualenv = 原子升级 - 有可能吗？

Question

我有一个 Django 项目在 virtualenv 中运行，没有站点包。当谈到将我的新更改推送到服务器时，我想创建一个新的 virtualenv 目录，安装我的项目及其所有依赖项，然后仅在新代码部署成功时才快速重命名两个 virtualenv 目录。

一切在纸上都很棒，直到您重命名 virtualevn 目录。根据其文档，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

我使用符号链接(symbolic link)和完全独立的发布目录来完成此操作。即，部署涉及将整个项目克隆到一个新目录中，在其中构建 virtualenv，然后切换“生产”符号链接(symbolic link)以指向该目录。

我的布局基本上是

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

因此，当我部署到生产环境时，我的部署脚本将一个全新的副本同步到 /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

我的实际部署脚本有点复杂，因为我还确保保留以前的版本并进行标记，因此如果我发现某些东西确实损坏了，回滚只需切换符号链接(symbolic link)以指向回前一个。 (如果您担心磁盘空间，还需要一些额外的工作来清理旧的、未使用的版本)。

每个外部引用(在 apache 配置文件或 wsgi 文件或其他文件中)都指向 virtualenv 中的库和二进制文件，如 /var/www/myapp/myapp/ve/。我还避免使用 source ve/bin/activate ，而是指向配置文件中的完整路径，然后编辑 manage.py 以使用 #!ve/bin/python 这样我就可以使用 ./manage.py 运行任何命令，并且它总是可以工作，而无需我记住是否激活了正确的 virtualenv。