python项目打包部署

浏览了以上所有人的答案，结合我平常在项目中的实际经验，谈谈我们团队的Python部署与发布流程。
目前很多公司还是用着石器时代的部署方式，怎么做呢？

  1. 1. 本地写代码，可能还没有virtualenv环境，是的其实我的老东家就是这样的。
  3. 2. 写一个脚本，安装需要的依赖到系统global环境，比如说 MySQLdb，
  4. 可能还要用apt-get 或者 yum 安装 python-dev 等等系统依赖，然后用pip 安装Python依赖。
  6. 3. 提交到svn/git，然后在测试机器上拉代码下来，运行脚本安装完依赖后，
  7. 如果是一个web项目，那么可能会直接 python web.py 8080 测试一下会不会报错，
  8. 测试完几个接口发现没问题，关掉测试机器。
  10. 4. 在生产环境把代码拉下来，或者通过部署系统，这里的部署系统一般是一个web页面，
  11. 能够将svn/git 上的代码打包后执行某一个脚本，来完成相应的部署，
  12. 也有可能是直接在机器上执行：
  13. nohup python /path/to/python/main.py 2&1 > /dev/null &
  14. 就启动来这个进程，然后自己可能还有一些业务监控来定时的监控这个脚本的存活状态。
  16. 5. 这里可能nginx已经配置好，你发布的是一个Django应用，那么打开浏览器，
  17. 查看网页无误。

ok，大功告成，我已经是一位合格的工程师了，我所理解的Python发布或者所有的发布不都是这样么，大家都是这样的。
如果你躺枪了，很好，我喜欢。
让我们看看这里的步骤缺少什么，我不仅仅从发布部署来说，我们谈谈一个理想的开发测试部署流程应该是怎样的。
1. 你应该有一个与线上环境一模一样的测试/开发机器，这里说的是系统环境而不是物理环境，比如说内核版本，Python版本，libc 版本，gcc 版本，shell 的环境等等都应该跟线上环境一样，这是保证代码质量的*关，或许不应该叫做代码质量而是工程质量。有人可能会用eclipse或者其他的云云开发IDE，OK，没问题，保证系统是一样的，这里有点难。
2. 你应该有一个virtualenv环境，因为你的开发机器可能有多个项目，而且可能因为有些依赖版本问题，导致你发现不同的项目可能对同一个模块有不同版本的依赖，那么请你准备一个virtualenv环境，这是Python开发人员必备的。
3. 你应该把代码提交到git, 但是提交之前，你应该运行一般单元测试，单元测试包含两个部分，一是对整个项目里的所有代码有一个代码静态检查，例如pylint和pep8，第二部分是自动运行你的测试用例，因为你的一个小改动可能会影响到其他模块，而这一点你开发的时候没有意识到或者说你影响的模块不是你写的，这一点会让你写的代码更健壮，同时你更有信心对现有代码做新需求开发或者变动，这里，你可以把你的测试用例启动脚本活着命令加到git hook，这样每次commit的时候都会启动测试程序。
4. OK，保证测试用例通过后，你应该对这次写的代码很有信心了，那接下来就是把代码发布到测试环境。怎么做呢？

一个起码看起来合格的Python项目，大体上代码构建的目录应该是下面这样的，请参考《以正确的方式开源Python项目》oschina.net/translate/o
所有的代码文件都在pro中，其他都是项目发布于部署使用到的

  1. -rwxr-xr-x 8 root root 4096 Sep 16 22:06 .git/
  2. -rw-r–r– 1 root root 434 Aug 10 16:00 .gitignore
  3. -rw-r–r– 1 root root 166 Jul 26 11:49 AUTHORS.md
  4. -rw-r–r– 1 root root 149 Aug 10 16:49 AUTHORS.rst
  5. -rw-r–r– 1 root root 0 Aug 10 16:49 CONTRIBUTING.rst
  6. -rw-r–r– 1 root root 245 Jul 26 11:59 HISTORY.md
  7. -rw-r–r– 1 root root 100 Aug 10 16:49 HISTORY.rst
  8. -rw-r–r– 1 root root 1453 Aug 10 16:49 LICENSE
  9. -rw-r–r– 1 root root 221 Aug 10 16:49 MANIFEST.in
  10. -rw-r–r– 1 root root 2964 Sep 12 11:19 Makefile
  11. -rw-r–r– 1 root root 239 Jul 26 11:49 README.md
  12. -rw-r–r– 1 root root 161 Aug 10 16:49 README.rst
  13. drwxr-xr-x 2 root root 4096 Sep 16 22:06 conf/
  14. drwxr-xr-x 2 root root 4096 Jul 26 11:59 deb-scripts/
  15. drwxr-xr-x 2 root root 4096 Aug 23 15:52 doc/
  16. drwxr-xr-x 8 root root 4096 Jan 16 13:12 pro/
  17. -rw-r–r– 1 root root 67 Aug 10 16:49 requirements-dev.txt
  18. -rw-r–r– 1 root root 284 Sep 2 15:34 requirements.txt
  19. -rw-r–r– 1 root root 22 Aug 10 16:49 setup.cfg
  20. -rwxr-xr-x 1 root root 1406 Aug 10 16:49 setup.py*
  21. drwxr-xr-x 4 root root 4096 Sep 2 17:30 utils/

我来解释一下这里的几个主要文件的作用. 这里的目录结构可能也跟我们团队的命名习惯有关.

  1. conf/
  2. conf/api.conf // 项目配置
  3. conf/logrotate.conf // 日志轮转配置
  4. conf/uwsgi.ini // uwsgi 配置
  5. conf/pro.upstart // upstart 文件
  6. conf/paste.ini // paste 是用来部署uwsgi的一个中间件
  7. conf/pro.cron // 这里是crontab配置
  8. conf/pro // 其他配置，可能是允许执行的sudo命令等

deb-scripts/ 包含三个文件，这里我们说debian系统打包，Redhat 打 rpm 也同理。

  1. eb-scripts/before-remove.sh // 卸载前执行的脚本
  2. deb-scripts/before-install.sh // 安装前执行的脚本
  3. deb-scripts/after-install.sh // 安装后执行的脚本

doc/ 应该是项目的文档，这里推荐用sphinx 生成文档或者你自己写markdown也可以。

utils/ 下面包含了你可能需要用到的启动依赖，但是又不想每次都远程下载，且不是Python本身的依赖而是环境依赖，好吧，我们在utils下面放了一个virtualenv，执行virtualenv 就可以在本地生成一个virtualenv 环境了, 还有打包deb的脚本

Makefile 文件包含了很多命令，比如:

  1. make test // 执行单元测试和静态检查
  2. make lint // 执行 pylint
  3. make pep // 执行pep8 检查

一系列你经常用到的功能，都可以放到Makefile

2. 你应该把你的代码打成一个安装包，而不是一个压缩包，因为你要发布的是一个服务而不是一个模块，那么请你打成deb或者rpm包。
让我们看下打包代码:

  1. #!/bin/sh
  2. set -e
  4. … // 省略了变量部分
  6. if [ ! -d wheelhouse ]; then
  7. make wheel
  8. fi
  10. fpm -t deb -s dir -n “$PKG_NAME” -v “$VERSION” –prefix “$DEST_DIR” -f \
  11. –depends make \
  12. -x ‘*__pycache__’ \
  13. -x ‘*.pyc’ \
  14. -x ‘*.pyo’ \
  15. -x ‘*.deb’ \
  16. –before-install deb-scripts/before-install.sh \
  17. –after-install deb-scripts/after-install.sh \
  18. –before-remove deb-scripts/before-remove.sh \
  19. Makefile HISTORY.rst LICENSE AUTHORS.rst CONTRIBUTING.rst setup.cfg \
  20. MANIFEST.in README.rst setup.py utils requirements-dev.txt requirements.txt wheelhouse conf \
  21. $PYTHON_MODULES

一目了然，我们会把依赖打到 wheelhouse 里面，然后把 wheelhouse 一同打包到 deb 包，这里使用了 fpm 这个打包工具，需要安装ruby gem 来安装。
然后在你的 make install 命令可以包含下面这个:

pip install --use-wheel --no-index --find-links=wheelhouse -r requirement.txt

在你的 deb-scirpt/after-install.sh 里面，这个脚本会在deb包安装完成后执行，你应该在这里完成你的环境依赖安装还有你配置文件的加载，crontab的配置等，一个简单的脚本应该像下面这样:

  1. #!/bin/sh
  2. set -e
  4. PREFIX=${PREFIX:-/opt/pro}
  5. REPODIR=${REPODIR:-/data2/pro}
  6. LOGDIR=${LOGDIR:-/data2/log/pro}
  7. IMAGE_CACHE=${IMAGE_CACHE:-/data2/image/cache}
  8. RUN_AS_USER=www-data
  10. mkdir -p $REPODIR
  11. mkdir -p $LOGDIR
  12. mkdir -p $IMAGE_CACHE
  14. chown -R “$RUN_AS_USER”:”$RUN_AS_USER” $REPODIR
  15. chown -R “$RUN_AS_USER”:”$RUN_AS_USER” $LOGDIR
  16. chown -R “$RUN_AS_USER”:”$RUN_AS_USER” $IMAGE_CACHE
  18. cd “$PREFIX”
  19. # this project does not require install.
  20. # make bootstrap install
  21. make bootstrap
  22. # install crontab, upstart job, logrotate config etc
  23. install conf/pro.upstart /etc/init/pro.conf
  24. install conf/logrotate.conf /etc/logrotate.d/pro
  25. install -o root -m 0440 conf/pro /etc/sudoers.d/pro
  26. install -o root -m 0644 conf/pro.cron /etc/cron.d/pro
  28. start pro || true

3. *后一步就是 start pro
这里使用upstart启动你的应用，你应该把你的应用交给系统而不是你自己
所以在 after-install 中，你需要把pro.conf这个文件安装到 upstart 目录.
4. 以上的所有步骤，还在你的本地，你需要做的是把代码发布到生产环境。这里你需要把你的deb包上传到私有apt源，然后就是发布到正式环境了。
5. 发布有几种方式：

  1. 1. 在机器上直接执行 apt-get install pro(不推荐)
  2. 2. 利用fabric执行远程命令发布(次不推荐)
  3. 3. 利用puppet发布(推荐)

前两者无需多说，利用puppet发布，可以使你的发布更佳规范，同时也可以对配置做更规范的管理，一些系统依赖，不是Python的而是系统本身的，比如有时候出现libpcre 这样的二进制系统依赖的时候，你应该利用puppet安装这些依赖，而不是手动去执行安装, 具体的 puppet 相关就不细说了。