编程是一门艺术

raptor.zh(at)gmail.com Creative Commons License
本作品采用知识共享署名-非商业性使用-相同方式共享 2.5 中国大陆许可协议进行许可。

archives 存档

01 Jan - 31 Dec 2018
01 Jan - 31 Dec 2017
01 Jan - 31 Dec 2016
01 Jan - 31 Dec 2015
01 Jan - 31 Dec 2014
01 Jan - 31 Dec 2013
01 Jan - 31 Dec 2012
01 Jan - 31 Dec 2011
01 Jan - 31 Dec 2010
01 Jan - 31 Dec 2009
01 Jan - 31 Dec 2008
01 Jan - 31 Dec 2007
01 Jan - 31 Dec 2006
01 Jan - 31 Dec 2005
01 Jan - 31 Dec 2004
01 Jan - 31 Dec 2003
01 Jan - 31 Dec 2002
01 Jan - 31 Dec 2001
01 Jan - 31 Dec 2000
01 Jan - 31 Dec 1999

--

links 链接

--

基于fabric和hg的自动化部署

自动化部署

fabric是个很好用的自动化部署工具,虽然功能比起puppet,saltstack之类要弱一些,但胜在用python,而且免安装服务端。

当然你要说docker更好我也同意,然而我是经常使用FreeBSD的,而且还有一些32位的低配系统,并不适合用docker。更不用说虚拟机了。

自动化部署的目的主要是简化手工部署的麻烦,包括初次安装部署和代码修改后的更新部署。初始部署主要是安装基础环境,初始化数据库等。更新部署则更麻烦一些,需要修改基础环境配置,变更数据库结构等。相比之下代码发布和更新反而是最简单的,用一个版本控制工具即可。

我是比较习惯用hg做代码版本管理的,当然这里要把hg换成git也可以,但我就是喜欢hg,你咬我啊。

fabric

fabric的官网是fabfile.org,基本用法都可以看官方文档,这里只对几种常用的用法作简单说明。

安装很简单,只要在本地用pip安装fabric即可,远程只要有SSH服务即可,不需要安装额外的东西,这点比puppet和saltstack省事。

使用上也很简单,最关键的是部署脚本是用python,比起puppet用的ruby来说,更合我口味。

默认的脚本文件名为: fabfile.py,当然你也可以用别的名字,但用起来就不方便了,类似make要用默认的Makefile文件名才方便一样。

执行默认脚本的命令为:fab <函数名>[<[参数名:]值>]

其中的函数名为fabfile.py中定义的任意函数(当使用@task装饰器时就只能使用已经装饰过的函数),也可以带上参数。对于特定主机或用户,还可以给函数加上角色装饰器。

运行本地命令的例子如下:

from fabric.api import local
def deploy_1():
    local(“hg commit”)
    local(“hg push”)
fab deploy_1

运行远端命令的例子如下:

from fabric.api import run
def deploy_2():
    run(“hg pull”)
    run(“hg update”)
fab deploy_2 -H hostname_or_ip

切换当前目录:

with lcd(“path”) # 本地目录
with cd(“path”) # 远端

错误处理:任何返回值不为0的操作都将导致异常,除非…

with settings(warn_only=True)

并且用命令的.failed属性来判断执行结果

env用于保存相关配置环境,比如SSH的KEY文件:key_filename,还有主机名列表:hosts,角色定义:roledefs等

角色的使用:

env.roledefs={‘role1’:[“user1@server1:port1”, “user2@server2:port2”],
    ‘role2’:[“user3@server3:port3”]}
@roles(“role1”)
def deploy_3():
    pass

结合fabric和hg的部署

以一个简单的python web应用为例来说明。

一次完整的手工初次部署大致包括以下内容(假设服务端系统已安装必要软件,比如hg, python, virtualenv, database, webserver,其中database和webserver已经配置好,单独的virtualenv已创建)等:

  • 在virtualenv环境中安装必要的依赖包 pip install -r requirements.txt
  • 通过hg发布要部署的代码 [local] hg push ssh://user@host/path; [remote] hg update
  • 初始化数据库
  • 启动(通过gunicorn, supervisord等)

代码修改过以后再次部署则涉及以下一些内容:

  • 更新依赖包
  • 更新代码
  • 更新数据库结构
  • 重启服务

再考虑到可能需要分别部署到测试环境和正式环境,又需要考虑以下问题:

  • 测试环境和正式环境涉及不一样的配置(比如连接不一样的数据库,配置不同的端口,甚至静态文件指向不同的路径)
  • 必须是测试环境中测试通过的版本才可以更新到正式环境中
  • 正式环境有更严格的权限管理(开发部门不可以直接部署到正式环境,甚至不能接触正式环境的配置信息)

由此,我们至少需要两个代码仓库:一个是开发代码库(repo_dev),包括测试配置,另一个是正式配置仓库(repo_prod)。

那么,基本的fabfile.py的deploy_dev函数大致有以下内容:

local("hg push repo_dev")
with cd("/target"):
    run("hg pull repo_dev")
    run("hg update")
    run("workon venv") # 切换到指定的virtualenv
    run("pip install -r requirements.txt")
    # 初始化数据库或更新数据库结构
    sudo("supervisorctl restart xxx") # gunicorn不能用supervisor重启,因为停止需要等待一段时间,建议用kill信号进行软重启

可以通过角色配置使repo_dev指定的远程服务器为测试主机 testhost ,在测试主机上测试通过以后,测试部分可以部署到正式机 prodhost 上。

with cd("/prodconf"):
    run("hg pull repo_prod")
with cd("/prod"):
    run("hg pull testhost") # 从测试主机上更新代码
    run("hg update rev") # 注意,这里要更新测试过的指定版本
    run("cp /prodconf/config .") # 使用正式配置替换测试配置
    run("workon venv")
    run("pip install -r requirements.txt")
    # 更新数据库结构
    sudo("supervisorctl restart xxx")

这个部署函数使用另一个用户角色,只要控制这个角色只有测试部门有权限即可,开发部门即使不慎运行了这个部署函数,也会因为没有权限而失败。

推送到[go4pro.org]

Trackback link:

Please enable javascript to generate a trackback url

No trackbacks

评论(0)


 
   
 
  表情图标 

 


提示: 除了 <b> 和 <i> 之外,其他的Html标签都将从您的评论中去除.url或mail地址会被自动加上链接.