一个简单的Python部署问题——一个痛苦的世界

一个简单的Python部署问题——一个痛苦的世界,python,linux,deployment,pylons,Python,Linux,Deployment,Pylons,我们有几个在Linux上运行的Python 2.6应用程序。其中一些是挂架web应用程序,另一些只是我们使用nohup从命令行运行的长时间运行的进程。我们还在开发和生产中使用virtualenv将这些应用程序部署到生产服务器的最佳方式是什么? 在开发过程中,我们只需将源代码树放入任何目录中,设置virtualenv并运行即可-非常简单。我们可以在生产中也这样做,也许这是最实际的解决方案,但在生产中运行svn update感觉有点不对劲。我们也尝试过fab,但第一次就没用了。对于每个应用程序,都会

我们有几个在Linux上运行的Python 2.6应用程序。其中一些是挂架web应用程序,另一些只是我们使用
nohup
从命令行运行的长时间运行的进程。我们还在开发和生产中使用
virtualenv
将这些应用程序部署到生产服务器的最佳方式是什么?

在开发过程中,我们只需将源代码树放入任何目录中,设置virtualenv并运行即可-非常简单。我们可以在生产中也这样做,也许这是最实际的解决方案,但在生产中运行
svn update
感觉有点不对劲。我们也尝试过
fab
,但第一次就没用了。对于每个应用程序,都会出现其他问题。考虑到我们试图实现的目标从根本上说非常简单,我觉得整个过程太难了。下面是我们希望从部署过程中得到的信息

  • 我们应该能够运行一个简单的命令来部署应用程序的更新版本。(如果初始部署涉及到一点额外的复杂性,那没关系。)
  • 当我们运行此命令时,它应该将某些文件从Subversion存储库或本地工作副本复制到服务器上的指定“环境”,这可能意味着不同的VirtualEnvironment。我们在同一台服务器上有应用程序的暂存版本和生产版本,因此它们需要以某种方式分开。如果它安装到站点包中,只要它工作,也可以
  • 我们在服务器上有一些应该保留的配置文件(即,不被部署过程覆盖或删除)
  • 其中一些应用程序从其他应用程序导入模块,因此它们需要能够以某种方式相互引用为包。这是我们遇到最多麻烦的部分!我不在乎它是否通过相对导入、站点包或其他方式工作,只要它在开发和生产中都能可靠地工作
  • 理想情况下,部署过程应该自动安装我们的应用程序所依赖的外部包(例如psycopg2)

  • 真的是这样!这有多难?

    看看是否有可复制的部署。

    我一直在为我们的工作项目实施这一点。这涉及到几个不同的部分

    首先,我们使用virtualenv.py的引导功能自定义virtualenv.py,以添加您自己的自定义后期创建函数和标志。它们允许我们定义常见的项目类型,还为我们提供了创建新virtualenv、从git存储库签出项目以及使用pip和requirements.txt将任何需求安装到virtualenv的单个命令 档案

    因此,我们的命令如下所示: python venv.py——无站点包-g$git\u proj-t$tag\u num$venv\u dir

    现在,这让我们完成了现有项目的初始签出。在我们工作和更新项目时,我们在每个项目中使用fabric命令来构建版本,然后部署它们:

    我有一个fab命令:make_标记,它检查未使用的提交,打开需要更新版本字符串的文件,构建并上传sphinx文档,然后将最终标记提交到存储库

    另一方面是fab deploy命令,它将通过ssh执行指定标记的git co,对任何新需求运行pip更新,运行所需的任何数据库迁移,然后重置web服务器(如果这是web应用程序)

    以下是标记功能的示例:

    你可以使用谷歌代码搜索浏览大量优秀的fabric文件。我知道我做了一些自用的作弊单

    为了让事情顺利进行,它肯定很复杂,有几个部分。不过,一旦你让它运行起来,它的灵活性和速度就太棒了。

    又一次投票支持fabric(尚未尝试构建)。我们已经成功地使用了几个月了


    如果您在面料方面遇到问题,另一种选择是。非常有效(即使对于非rails应用程序也是如此)。只是因为使用Ruby部署Python应用程序感觉很奇怪,才停止使用它;)

    这真的不难。你主要需要和我一起玩

    虽然学习buildout可能需要一点时间,但它是值得的,因为它可以减少重复设置中的痛苦

    关于nohup:nohup方法不适合严肃的部署。我有很好的管理经验。它是运行生产python应用程序的优秀解决方案。安装起来很容易

    下面是一些具体的答案

  • 要部署的单个命令:Buildout就是答案。我们使用它已经有几年了,没有太多问题
  • 通常情况下,这就像你检查源代码一样。然后运行buildout。此外,让安装程序复制到站点包中可能不是一个好主意。最好将环境分开
  • 配置不会被覆盖
  • 你可以考虑为普通包裹造鸡蛋。就像你可以为一个包(比如commonlib)构建一个egg,然后将它上传到你的代码库中。然后可以在buildout.cfg中将其指定为依赖项
  • Buildout能够构建与中央/顶级安装完全分离的最基本的软件包。然而,根据我的经验,如果将带有c扩展的python软件包作为操作系统软件包安装,那么就容易多了

  • 我将使用rsync从生产“prime”服务器向外同步到其他服务器,从“beta测试”平台向外同步到生产“prime”服务器

    rsync的好处是只复制更改的文件,只复制部分更改的文件的一部分,并在所有计算机上验证完整性和相同的内容。一个部分通过并处于运行状态的更新
    $ python <untarred_directory>/virtualenv.py venv
    
    $ . venv/bin/activate
    
    $ easy_install pip
    
    $ pip install -e pkg1
    
    $ cd pkg1
    $ python setup.py develop
    
    $ cd pkg1
    $ python setup.py --help
    $ python setup.py --help-commands