Question

我有一个在没有site-packages的virtualenv中运行的Django项目。当我将新的更改推送到服务器时，我想创建一个新的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

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

我的布局基本上是

/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，我总是在没有必须记住的情况下工作。

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

1 个答案: