基于Jenkins+Gitlab的自动化部署实战

故事背景

  一个中小型企业,是典型的互联网公司,当初期的时候可能运维只能标配到2~3人,此时随着公司的发展,项目会逐渐增多。前期部署项目可能都是手动的,

俗称“人肉部署”,这简直是无比的痛苦,不能忍受的。这样开发的时间也会耽误,运维的时间也会耽误,全都浪费在这些重复性的工作上面,毫无价值可言,

这时候运维终于忍受不了,上了脚本。但是慢慢的发现项目依旧在增长,脚本每次还要更改给开发,效率低下,后来测试环境以及开发环境直接上了jeknins,

每台开发机器是jeknins agent端,自此,开发环境运维终于解脱了出去。但是线上上线运维依旧、所以得定制一套线上上线的流程标准,然后上jenkins自动化。

前提标准

想要实现自动化的前提是标准化,例如程序的日志目录、程序目录、程序目录命名、代码分支、代码命名规则、程序高可用. 针对以上内容我们给开发做了

严格的标准并落地执行。

在此我会以Java程序为例子,因为我见到的最多的就是java程序比较麻烦,而php或者python可能只需要在服务器上git pull更新一下代码就可以了。

  tomcat规则: 每台服务器放置一个tomcat,tomcat使用ROOT.war,并配置日志切割

  程序目录:统一使用tomcat进行管理,所有的项目统一打出war包,放置tomcat下面命名为ROOT.war

  程序日志:统一放置在规定的目录,例如: /apps/logs/$app.log

  代码分支:不同的环境使用不同的分支,开发 dev分支, 测试 test 分支, 预发布 pre分支, 生产线上 master分支。分支隔离,不同环境取不同环境的配置

  代码打包: 因为是java的代码,我们选择的是使用maven进行打包,开发只需要关心代码层即可

  高可用: 每个程序必须支持多节点部署,不可出现单点故障的情况,否则不予上线.

自动化部署系统

  因为中型公司不可能配置运维开发,而开发只管开发的,所以运维只能是通过使用开源工具的方式来搭建自动化部署系统,组件如下图:

上图的Jenkins服务器即自己是自己的agent,gitlab服务器是代码仓库服务器,Jenkins服务器会调用脚本,脚本做一些响应的动作进行自动化上线。

自动化上线流程:

下面进行步骤的分解:

1. 运维人员登录jeknins,在jenkins界面点击响应的job,每个job是更新一个主机,job以服务名+ip组成,点击后jeknins会调用Shell发布脚本,下面这些都是脚本完成

2. 发布脚本所做的第一步就是获取此项目的最新的代码版本

3. 发布脚本所做的第二部是使用maven进行打包,每个maven打包的参数都统一

4. 将打包好的war包拷贝到目标服务器上面

5. 将需要上线的主机在前端负载haproxy上面进行下线(针对核心业务,建议这么做,比较优雅,不太暴力)

方法参考: http://www.cnblogs.com/topicjie/p/7106860.html

6.重启目标主机的tomcat服务

7.测试url访问,返回是否正常

8.在haproxy上线该主机

脚本实例

下面是一个线上使用的上线脚本,scp是通过ssh免密的方式,并且部署tomcat是java用户. tomcat路径是/usr/loca/tomcat,每台主机一个tomcat

 注意: 此脚本中不包含 5,7,8 步骤,如果需要,请自行补充。

#!/bin/bash
##################################################################
#
# Date :  2016/07/15
# Email:  [email protected]
# Proj :  xx java项目
#
# 主要功能是更新线上tomcat服务使用.
# 使用此脚本必须配置java用户免密码登录
# 第一次必须手动将代码clone到BASE_CODE_PATH目录
##################################################################
. /etc/profile

# 定义此项目所包含的主机,以空格隔开,必须严格遵守
inc_host=("192.168.24.50" "192.168.24.51")

##### *** 定义项目代码存放目录,必须定义正确 ***  ####
CODE_PATH="/app/code/xxxxxx"

# 定义tomcat实例目录
Tomcat_PATH="/usr/local/tomcat"

# 定义git分支,默认是master分支
CODE_BRANCH=‘master‘

# 定义编译配置文件,生产环境默认应是product,此处是pom.xml文件中定义
MVN_CONF="product"

# 获取需要更新的主机IP
U_host="$1"

# Define help
usage() {
    echo
    echo -e "   Usage : sh ./`basename $0` ipaddress"
    echo
}

code_pull() {

    echo "[Info] --->>> 项目开始更新代码... <<<---"

    cd $CODE_PATH
    git checkout $CODE_BRANCH
    git pull -u origin master:master 

    if [ $? -ne 0 ];then
        echo "Git Pull Code Error"
        exit 1
    fi

    echo "[Succ] --->>> 项目代码更新完成... <<<---"
    echo
}

# Define build war
mvn_build() {
    cd $CODE_PATH
    echo "[Info] --->>> 项目开始编译... <<<---"
    mvn clean package -P $MVN_CONF

    if [ $? -ne 0 ];then
        echo "[Error] Compile Error,Please Check Your Code."
        exit 1
    fi
    echo "[Succ] --->>> 项目编译完成... <<<---"
    echo
}

# Define publish
push_remote() {

    echo "[Info] --->>> 开始发布主机: $U_host  <<<---"

    ssh $U_host "/bin/rm -rf ${Tomcat_PATH}/webapps/ROOT*"
    scp ${CODE_PATH}/target/*.war $U_host:$Tomcat_PATH/webapps/ROOT.war
    ssh $U_host "/bin/sh /app/scripts/stop_tomcat.sh"
    sleep 3
    ssh $U_host "source /etc/profile;/bin/sh ${Tomcat_PATH}/bin/catalina.sh start"  

    echo "[Succ] --->>> 主机: $U_host 发布完成. <<<---"
    echo

}

# check host
check_host() {

    for host in  ${inc_host[@]};
    do
        if [[ "$U_host" == "$host" ]];then
            return 0
        fi
    done
    return 1
}

# Check user
check_user() {
    if [ `whoami` != ‘java‘ ]; then
        echo "---------------------------------------------------"
        echo "You must use the Java user to run this script !!!"
        echo "---------------------------------------------------"
        exit 3
    fi
}

check_user

#check args
if [ $# -ne 1 ];then
    usage;exit 1
fi
if [ $1 == "-h" -o $1 == "--help" ];then
    usage;exit 1
fi

check_host
if [ $? != 0 ];then
    echo "Please check the server ip address to be updated !"
    exit 64
fi

code_pull
mvn_build
push_remote

  

自此,以上可以实现在jenkins点击一下,服务一会自己就上好了,虽然说还有很多地方需要改进,但是一般中小型公司采用这种方式则是足够了,

只能持续的进行优化,当然,再厉害一点的公司可以自己开发运维平台。

  

时间: 2024-10-01 03:30:58

基于Jenkins+Gitlab的自动化部署实战的相关文章

Jenkins+Gitlab+Ansible自动化部署(六)

Pipeline Job实现Nginix+MySQL+PHP+Wordpress实现自动化部署交付(Jenkins+Gitlab+Ansible自动化部署(五)https://www.cnblogs.com/zd520pyx1314/p/10249094.html) 环境准备 编写ansible playbook脚本实现Wordpress远程部署 将wordpress源码与playbook部署脚本提交到gitlab仓库 编写pipeline job脚本实现Jenkins流水线持续交付流程 Jen

Linux-GitLab+Jenkins持续集成+自动化部署

GitLab+Jenkins持续集成+自动化部署 什么是持续集成? (1)Continuous integration (CI) 持续集成是一种软件开发实践,即团队开发成员经常集成他们的工作,通常每个成员至少集成一次,也就意味着每天可能会发生多次集成.每次集成都通过自动化的构建(包括编译.发布.自动化测试)来验证,从而尽快地发现集成错误.许多团队发现这个过程可以大大减少集成的问题,让团队能够更快的开发内聚的软件. (2)没有持续集成 项目做模块集成的时候,发现很多接口都不通==>浪费大量时间 需

centos7+docker+Jenkins+svn搭建自动化部署平台

centos7+docker+Jenkins+svn搭建自动化部署平台 1. centos7 参考链接:http://www.macrozheng.com/#/reference/linux_install tips 公司服务器配置(1T机械+256固态+i7的u) 需要我们把系统,环境(java,mysql,redis,docker等)装到固态上(速度快),我们的代码放到机械上.分区情况如下图 2. centos7中安装docker1.31.1 自行百度,此处无坑 3. centos7安装配置

gitlab,gitlab runner自动化部署docker容器

一 .基础概念 软件开发中经常持续集成,持续交付,持续部署这三个概念到底是什么意思? 持续集成: 持续集成是指开发者在代码的开发过程中,可以频繁的将代码部署集成到主干并进程自动化测试 持续交付: 持续交付指的是在持续集成的环境基础之上,将代码部署到预生产环境 持续部署: 在持续交付的基础上,把部署到生产环境的过程自动化,持续部署和持续交付的区别就是最终部署到生产环境是自动化的 二.自动化部署流程 第一步:开发人员将代码上传到代码仓库,gitlab 根据gitlab-ci.yml中的命令,触发ci

jenkins+gitlab+maven+docker部署项目之jenkins用户权限管理

一.用户管理 jenkins自身带有权限管理,入口:系统管理-->全局安全配置,这里的权限配置太过简略,没有角色的概念,显然无法满足我们复杂的需求,所以在这个时候引入了 Jenkins 的一个插件:Role-based Authorization Strategy 安装插件:Role-based Authorization Strategy,插件管理-->可选插件搜索一下点击安装,安装完后重启就可以使用该插件 系统管理-->全局安全配置,然后用重新登录一下 系统管理-->Manag

Linux基于PXE实现系统自动化部署

一.前言: 通常为计算机安装操作系统的方式主要是,光盘安装和U盘安装:在企业生产环境中,会需要对多台客户机或服务器安装Linux操作系统,如果还用常规的方法去安装,费时又费力:PXE批量部署系统即可高效完成此类工作. 二.原理: 使用光盘(镜像)安装Linux操作系统过程:POST(加电自检)-->引导序列(通过BISO发现引导CD-ROM或U盘)--Bootloader(kernel+ramdisk)-->anaconda(安装程序) 1.自动化部署服务器所需环境: PXE:Preboot

基于Jenkins+Gitlab+Harbor+Rancher架构的CICD实现

在讲正文开始前先回顾一下以往传统的代码部署方式. 通常运维人员在接到代码(新项目)上线的任务前都要做大量的准备工作,包括:物理主机.虚拟机.代码运行环境.数据库安装配置.各种帐号创建,.运行后期的系统监控.应用的日志收集,性能优化等一系列的工作. 想一想这个流程不是很复杂,但是很繁琐,效率低下,如需要调试还需要给开发人员提供线上系统权限等等,细节没有注意的话,还会造成解决问题的难度等各种问题. OK,说完以上的问题,那接下来就有相对应的解决方案. 在经过两个月的不间断的测试下,一套我自认为比较好

使用Gitlab实现自动化部署与持续集成

Gitlab-Ci运行原理: 由以下两个模块组成gitlab-ci servergitlab-ci-runner其中,gitlab-ci server负责调度.触发Runner,以及获取返回结果. 而gitlab-ci-runner则是主要负责来跑自动化CI(测试,编译,打包等). 基本流程是: 用户提交代码->检查是否有.gitlab-ci.yml文件->如果无,则结束:-> 如果有,则调用runner执行脚本->获取返回的结果. 1. 登录Gitlab前提: gitlab 已经

jenkins + pipeline构建自动化部署

一.引言 Jenkins 2.x的精髓是Pipeline as Code,那为什么要用Pipeline呢?jenkins1.0也能实现自动化构建,但Pipeline能够将以前project中的配置信息以steps的方式放在一个脚本里,将原本独立运行于单个或者多个节点的任务连接起来,实现单个任务难以完成的复杂流程,形成流水式发布,构建步骤视图化.简单来说,Pipeline适用的场景更广泛,能胜任更复杂的发布流程.举个例子,job构建工作在master节点,自动化测试脚本在slave节点,这时候je