如何部署一个使用platter构建的基于Django/Tornado的web应用程序？

Question

这个问题主要是关于如何有效地部署使用platter构建的pythonweb应用的技术细节和一些最佳实践。在

以Django为例，我有一个已经构建到tarball发行版中的项目。这包括所有dep的所有轮子+应用程序本身的包。在

我的repo目录还包含一些其他需要与部署的代码一起分发的文件，例如：manage.py、带有fabric utils的fabfile包和一些配置文件（用于supervisor、nginx等）。在

所以我的问题是：

1. 如何将这些额外的文件打包到包含项目的发行版中？在
2. 如果我只是使用git在服务器上克隆/拉取项目，我有这些文件，但是我有源代码的副本，它们都在项目中并且压缩在tarball中。我怎么才能避免呢？将tarball提交到单独的回购中？在
3. 也许复制并不那么糟糕，最后我会在dist/目录中得到多个tarball，而只有一个符号链接到我部署的current上？在

基于龙卷风的应用程序也是如此。在

Answer 1

我的第一条部署规则是“一切可行”。每个生产环境都有不同的要求。但要对你的问题发表意见：

1. 不是所有的东西都应该在Python项目中。也许有办法，但我认为这是用错了锤子。

2. 您可以创建一个单独的Git repo，为您的生产部署处理配置和资产文件（如果您不关心旧的、不相关的配置文件，Git甚至不管理这些文件）。这不一定是Python项目，只需要生产部署的文件。你可以选择在这里放一两个Python脚本（或者仅仅是一个自述文件.txt或fab文件或Buildout config）来自动执行诸如解包盘片或复制配置文件之类的任务。在

   将生产配置放在主Git repo中是很诱人的（也是可能的）。这甚至被为开发和生产配置创建样板文件的应用程序所建议。但这并不意味着这是做事情的最佳方式。在

   我的规则是，主要的Git回购是“仅限开发”。它是由正在开发环境中设置和工作的开发人员克隆的。它将一个Python项目太过混为一谈，以至于无法尝试成为一个Python应用程序，同时也是一个管理生产系统的地方，IMHO。在

   生产分开管理。有时是由不同于开发人员的人，或者至少开发人员在考虑生产部署时戴着不同的帽子。通过这种方式，您还可以有一个小的、干净的repo，它只跟踪对生产系统的更改。

3. 在代表不同构建的单个部署中使用符号链接是一种额外的混乱。这样做的动力来自于尝试从单个Python项目中完成所有事情。在

   将python应用程序部署到/var/myapp/build-2015-10-29/中。然后在/var/myapp/current/处创建一个指向此位置的符号链接。通过这种方式，您可以在/var/myapp/build-2015-11-05/上创建一个完整的部署，然后调整配置以从一个单独的端口启动，启动应用程序并确保一切正常，然后只需在最短的停机时间内从旧版本切换到新版本。