自动化部署(二)

2 自动化部署流程设计

2.1 需求分解

一个集群有10个节点:

  1. 一键部署10个节点。
  2. 一键回滚到任意版本。
  3. 一键回滚到上个版本。

2.2 部署流程分解

2.2.1 准备

  1. 代码放在哪里? git/svn
  2. 获取什么版本的代码?
    svn: 指定版本号
    git: 指定tag
  3. 差异解决:
    • 各个节点的配置文件差异:列如crontab.xml 只需要由一台机器来执行或者是预生产节点和生产节点的配置文件有差异。
    • 代码仓库和实际的差异,配置文件是放在代码仓库中。
  4. 如何更新?tomcat 部署过后需要重启。
  5. 测试。
  6. 串行部署还是并行部署。
  7. 如何执行?shell还是web界面。

2.2.2 上线流程

  1. 获取代码(直接拉取)
  2. 编译(可选,java代码需要编译)
  3. 替换配置文件》
  4. 打包
  5. scp到指定的服务器
  6. 将目标服务器移除集群
  7. 解压
  8. 放置到webroot
  9. scp差异文件
  10. 重启应用(可选,tomcat需要重启)
  11. 测试
  12. 加入集群

2.2.3 回滚流程 - 普通流程

  1. 列出回滚的脚本
  2. 将目标服务器从集群中移除
  3. 执行回滚版本
  4. 重启和测试
  5. 加入集群

2.2.4 回滚流程 - 紧急流程

  1. 列出回滚版本
  2. 执行回滚
  3. 重启

2.2.5 回滚流程 - 最

  1. 回滚上个版本
  2. 重启

2.3 部署脚本

2.3.1 部署准备

  1. 所有的web服务都应该使用普通用户运行。(用root用户运行web服务,系统如果被黑,那就没法玩了。)
  2. 所有的web服务都不应该监听80端口,负载均衡器除外。

2.3.1 部署脚本内容

#!/bin/bash

#NODE LIST
NODE_LIST="10.0.0.205 10.0.0.203"

# 生产中有预热节点,一般预热节点为一台。
PRE_LIST="10.0.0.203"
GROUP2_LIST="10.0.0.205"
ROLLBACK_LIST="10.0.0.205 10.0.0.203"

# Date/Time variables
LOG_DATE=‘date +"%Y-%m-%d"‘
LOG_TIME=‘date +"%H-%M-%S"‘

CDATE=$(date +"%Y-%m-%d")
CTIME=$(date +"%H-%M-%S")

# shell env
SHELL_NAME="deploy.sh"
SHELL_DIR="/home/www"
SHELL_LOG="${SHELL_DIR}/${SHELL_NAME}.log"

# CODE ENV
PRO_NAME="web_demo"
CODE_DIR="/deploy/code/${PRO_NAME}"
CONFIG_DIR="/deploy/config/${PRO_NAME}"
TMP_DIR="/deploy/tmp"
TAR_DIR="deploy/tar"
LOCK_FILE="/tmp/deploy.lock"

# FUNCTION

url_test(){
    URL=$1
    curl -s -I "$URL"|grep ‘200 OK‘
    if [ $? -ne 0 ];then
        shell_unlock;
        writelog "test error" && exit
    fi
}

usage(){
    echo "usage: $0 { deploy | rollback [list | version]}"
}

writelog(){
    LOGINFO=$1
    echo "${CDATE} ${CTIME}: ${SHELL_NAME} :${LOGINFO}" >> ${SHELL_LOG}

}

shell_lock(){
    touch ${LOCK_FILE} 

}

shell_unlock(){
    rm -f $LOCK_FILE
}

code_get(){
    writelog ‘code_get‘;
    # $CODE_DIR目录下只能进行git pull
    cd $CODE_DIR && git pull
    # git pull 之后就copy走
    cp -r ${CODE_DIR} ${TMP_DIR}/
    # 定义版本号,下面的PKG_NAME需要用到。
    API_VER=`git show|grep commit|cut -d " " -f 2|head -c 6`
}

code_build(){
echo code_build

}

code_config(){
    writelog  code_config
    # 加 -r 参数 ,覆盖原来的老文件。
    # 这里为什么是/bin/cp ??  后面为什么加“”
    /bin/cp -r ${CONFIG_DIR}/base/* ${TMP_DIR}/"${PRO_NAME}"
    PKG_NAME="${PRO_NAME}"_"$API_VER"_"${CDATE}-${CTIME}"
    cd ${TMP_DIR} && mv ${PRO_NAME} ${PKG_NAME}
}

code_tar(){
    writelog "code_tar"
    cd ${TMP_DIR} && tar -cf ${PKG_NAME}.tar.gz $PKG_NAME
}

code_scp(){
    writelog "code_scp"
    for  node in $NODE_LIST
    do
        # /opt/webroot 目录要存在
        scp -P52113 ${TMP_DIR}/${PKG_NAME}.tar.gz $node:/opt/webroot
    done
}

cluster_node_remove(){
    writelog "cluster_node_remove"
}

pre_deploy(){
# 先上预热节点,当他测试没问题的时候再接着上下面的节点。

    writelog ‘remove from cluster‘
    ssh -p52113 ${PRE_LIST} "cd  /opt/webroot && tar xf ${PKG_NAME}.tar.gz"
    ssh -p52113 ${PRE_LIST} "rm -f /webroot/web-demo && ln -s /opt/webroot/${PKG_NAME} /webroot/web-demo"
}

pre_test(){
    url_test http://${PRE_LIST}/index.html
}

group2_deploy(){
# 包含
        writelog ‘remove from cluster.‘
        for node in $GROUP2_LIST
        do
                ssh -p52113 $node "cd  /opt/webroot && tar xf ${PKG_NAME}.tar.gz"
                ssh -p52113 $node "rm -f /webroot/web-demo && ln -s /opt/webroot/${PKG_NAME} /webroot/web-demo"
        done
        # 差异配置文件,应该放到最后去完成。如果软连接没完成,而配置文件拷贝过去就尴尬了。
        scp -P52113 ${CONFIG_DIR}/other/10.0.0.205.crontab.xml 10.0.0.205:/webroot/web-demo/crontab.xml
}

group2_test(){
    for node in $GROUP2_LIST
    do
        url_test http://${node}/index.html
    done
}

cluster_node_in(){
    echo cluster_node_in
}

rollback_fun(){
    ROLLBACK_VER=$1
    for node in $ROLLBACK_LIST
    do
        ssh -p52113 $node "[ -d /opt/webroot/"$ROLLBACK_VER" ] && rm -f /webroot/web-demo && ln -s /opt/webroot/${ROLLBACK_VER} /webroot/web-demo || echo rollback failed."
    done
}

rollback(){
    ROLLBACK_VER=$1
    [ -z "$ROLLBACK_VER" ] && echo "exit! no version." && shell_unlock && exit

    case $ROLLBACK_VER in
    list)
        #ssh -p52113 10.0.0.203 ‘ls -l /opt/webroot/*.tar.gz |awk -F "[/.]" "{print $(NF-2)}"‘
        ssh -p52113 10.0.0.203 "find /opt/webroot/ -maxdepth 1 -type d|cut -d "/" -f 4"
        ;;
    *)
        rollback_fun $ROLLBACK_VER
    esac
}

main(){
    # 进程锁
    [ -f "$LOCK_FILE" ] && echo "deploy is running " && exit
    DEPLOY_METHOD=$1
    ROLLBACK_VER=$2
    case $DEPLOY_METHOD in
      deploy)
        shell_lock;
        code_get;
        code_build;
        code_config;
        code_tar;
        code_scp;
        cluster_node_remove;
        pre_deploy;
        pre_test;
        group2_deploy;
        group2_test;
        cluster_node_in;
        shell_unlock;
        ;;
      rollback)
        shell_lock;
        rollback $ROLLBACK_VER;
        shell_unlock;
        ;;
      *)
        usage;
    esac

}

# $1: deploy | rollback
# $2: rollback version

main $1 $2

原文地址:http://blog.51cto.com/damaicha/2118712

时间: 2024-10-05 05:34:21

自动化部署(二)的相关文章

搭建Puppet自动化部署环境

最近项目上线,自己在部署过程中发现很多问题,发现没有自动化部署工具简直就是纯体力活儿,费时又费力,干的事就是那几个,就不能"一键完成么"的想法油然而生,答案是肯定的,自动化的工具有很多,之所以安装Puppet,只是因为比起别的软件,这款软件原来有学习过,现在又重新拾起来,要把它用到生产环境中,让运维工作不再是体力活,而是实现,全自动部署,更新,这篇只是聊聊安装和配置Puppet,后续还会写具体在生产环境中如何实现自动化代码更新,软件部署等,敬请期待~ 环境介绍: puppetserve

持续集成+自动化部署[代码流水线管理及Jenkins和gitlab集成]

持续集成+自动化部署[代码流水线管理及Jenkins和gitlab集成] 标签(空格分隔): Jenkins 一.代码流水线管理 Pipeline名词顾名思义就是流水线的意思,因为公司可能会有很多项目.如果使用jenkins构建完成后,开发构建项目需要一项一项点击,比较麻烦.所以出现pipeline名词. 代码质量检查完毕之后,我们需要将代码部署到测试环境上去,进行自动化测试 新建部署代码项目 点击新建 这里只需要写一下描述 执行Shell脚本 温馨提示:执行命令主要涉及的是权限问题,我们要搞明

MDT 2013 从入门到精通之自动化部署WinSer 2008 R2

因加班等问题,前一段时间我们只更新了MDT 2013从入门到精通系列的前半部分,趁着阅兵休息的这几天,为大家奉上后续的部分,供大家学习参考,如有不足还请大家多多包涵.正如我们所知道的,MDT其实不止能部署用户端操作系统,还可以部署Server服务器端操作系统,今天为大家带来有关MDT 2013如何部署Windows Server 2008 R2企业版操作系统,实现自动化操作,减轻工程师工作量等: 一.导入系统镜像: 1.在MDT控制台Operating Systems项中添加对应Server 版

MDT 2013 从入门到精通之自动化部署WinSer 2012 R2

Windows Server 2012 R2 是由Microsoft设计开发的新一代的服务器专属操作系统,其核心版本号为 Windows NT 6.3 .提供企业级数据中心与混合云解决方案,直观且易于部署.具有成本效益.以应用程序为重点.以用户体验为中心,深受广大 IDC 运营商青睐.之前有好多朋友说MDT无法部署全新设计后的2012,本文将简单介绍该服务器操作系统的自动化部署过程.同时建议大家在使用MDT的时候多测试,因为实践是检验真理的唯一标准,我们测试的结果是为了我们更好的部署自动化,可能

MySQL主从复制原理及配置详细过程以及主从复制集群自动化部署的实现

Technorati 标签: 那你魔鬼 一.复制概述 Mysql内建的复制功能是构建大型,高性能应用程序的基础.将Mysql的数据分布到多个系统上去,这种分布的机制,是通过将Mysql的某一台主机的数据复制到其它主机(slaves)上,并重新执行一遍来实现的.复制过程中一个服务器充当主服务器,而一个或多个其它服务器充当从服务器.主服务器将更新写入二进制日志文件,并维护文件的一个索引以跟踪日志循环.这些日志可以记录发送到从服务器的更新.当一个从服务器连接主服务器时,它通知主服务器从服务器在日志中读

通过shell脚本实现代码自动化部署

一.传统部署方式及优缺点 1.传统部署方式 (1)纯手工scp (2)纯手工登录git pull.svn update (3)纯手工xftp往上拉 (4)开发给打一个压缩包,rz上去:解压 2.缺点 (1)全程运维参与,占用大量时间 (2)上线速度慢 (3)人为失误多,管理混乱 (4)回滚慢,不及时 二.环境规划 1.开发环境--开发者本地有自己的环境. 运维需要设置的开发环境,大家共用的服务. 2.测试环境:功能测试环境和性能测试环境. 3.预生产环境:生产环境集群中的某一个节点. 4.生产环

一键自动化部署(定制rpm包,yum仓库)

部署--前篇 上午将MySQL多实例部署完成,由于有公司特定一些需求,需要源码安装,现在需要批量部署,如果一台台部署,就太过麻烦,而且浪费时间,这个时候自动化部署 就体现出价值了 我们将MySQL制作定制化rpm包,然后放到我们的yum仓库中,在将yum所有客户端,都指向yum源,之后就是喝喝茶,看看片,轻松批量部署了,废话不多说,开干. 如果MySQL多实例还没配置的,或不了解软件的安装方式 的 请参考:http://qiuyt.blog.51cto.com/1229789/1920686 一

实战:ansible自动化部署nginx+keepalived+mysql负载均衡集群

一.目的 使用ansible自动化部署nginx+keepalived+mysql负载均衡集群. 二.拓扑规划 三.详细步骤 1.环境的搭建 (1).安装ansible,同时配置私钥免密码进行通信 [[email protected] ~]# ssh-keygen  -t rsa #-t表示使用的加密类型,其中rsa1表示version1版本,rsa.dsa.ecdsa的加密对于的是version2版本 Generating public/private rsa key pair. #这里询问你

MySQL5.7多实例自动化部署脚本

一.安装说明 mysql5.7.10_onekey_install.sh自动化部署脚本支持mysql5.7.10初始化安装,多实例创建,且使用经过优化后的my.cnf配置文件和mysql.server启动脚本,该SHELL脚本在CentOS6.5_x86_64操作系统测试通过.部署示意图如下: 1.安装方式 需要准备的文件如下,放到同一个目录下,然后执行shell脚本 执行方式: ./mysql5.7.10_onekey_install.sh 3307 端口自定义,要求整数,且不和服务器端口冲突