码迷,mamicode.com
首页 > 其他好文 > 详细

基于fabric和hg的自动化部署

时间:2015-12-25 01:15:41      阅读:237      评论:0      收藏:0      [点我收藏+]

标签:

自动化部署

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")

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

基于fabric和hg的自动化部署

标签:

原文地址:http://blog.csdn.net/raptor/article/details/50397658

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!