如何部署基于Django / Tornado的网络应用程序，使用拼盘构建？

Question

这个问题主要是关于如何有效部署使用拼盘构建的python Web应用程序的技术细节+一些最佳实践。

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

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

所以我的问题是：

1. 如何将这些额外文件包装到包含项目的发行版中？
2. 如果我只是使用git克隆/拉取服务器上的项目我有这些文件，但后来我在项目中都有重复的源代码，并在tarball中压缩。我怎么能避免这种情况？将tarball提交到一个单独的仓库？
3. 也许重复并不是那么糟糕，我最终会在dist/目录中找到多个tarball，只有一个符号链接到我部署的current？

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

Answer 1

我的第一个部署规则是＆＃34;无论如何工作＆＃34;。每个生产环境都有不同的要求。但要对你的问题发表意见：

1. 并非所有内容都应该在您的Python项目中。也许有办法做到这一点，但我认为它使用了错误的锤子。

2. 您可以创建一个单独的Git仓库来处理生产部署的配置和资产文件（如果您不关心旧的，不相关的配置文件，这甚至不会由Git管理）。这不一定是Python项目，只是生产部署的文件。您可以选择在这里放置一两个Python脚本（或者只是README.txt或fab文件或Buildout配置）来自动执行任务，例如解压盘或复制配置文件。

   将生产配置内容放入主Git仓库中是很诱人的（并且可能）。甚至可以通过为开发和生产配置创建样板文件的应用程序来建议这一点。这并不意味着它是最好的做事方式。

   我的规则是，主要的Git回购只是＆＃34;仅开发＆＃34;。它是由在开发环境中设置和工作的开发人员克隆的。它混淆了一个Python项目太多，无法尝试成为一个Python应用程序，也是一个管理生产系统的地方，恕我直言。

   生产是单独管理的。有时与开发人员不同的人或者至少开发人员在考虑生产部署时戴着不同的帽子。通过这种方式，您还可以拥有一个小型，干净的仓库，可以跟踪生产系统的变化。

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

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