基于GitLab+Jenkins的DevOps赋能实践

随着微服务、中台架构的兴起,DevOps也变得非常关键,毕竟是一些基础设施层面的建设,如果搞好了对后面的研发工作会有很大的效率提升。关于DevOps本身的概念,网上已经非常多了,在园子里随便搜索一些都一堆概念,我就不再重复介绍了。下面直接进入正题,怎么使用GitLab+Jenkins来完成DevOps的建设。

在开始实战演练之前,首先用一张图来展示一下这次实践所要完成的功能:

在这个流程中,分为3个环境,分别是预览环境、预发环境和生产环境,普通开发者接受到任务以后,在GitLab中基于feature分支进行开发,然后把开发好的需求申请合并到dev分支,在申请合并的过程中,会触发构建流水线进行编译、单元测试、接口测试、发布环境等系列校验,当pipeline完成以后,组长就可以在代码审查后,进行合并到dev分支。这个时候又会触发dev分支的构建流水线,然后再完成一遍上述的流程,把代码发布到预发环境。最后由项目负责人定期把dev合并到master分支,完成生产环境版本发布。

首先,在GitLab中创建一个测试项目:

这个项目是在lizongshenblogs的group下面的applications子group下的一个项目,代表了这是一个源代码项目。

接下来再为这个项目创建3个流水线配置,主要目的是为了让代码和配置分离:

在3个配置项目中,分别存放了相应的Jenkinsfile,用于Jenkins流水线的构建配置,接下来开始配置Jenkins。首先进行Jenkins的全局配置:在Jenkins的Manage Jenkins - Configure System下面配置Gitlab Connection,如图:

在这里需要注意,这个connection是需要一个gitlab的访问令牌,可以在gitlab的个人设置 - 访问令牌里面生成,生成完成之后,填入到相应的Credentials里面:

最后测试一下,连接是否成功,只要显示success,就可以了。

接下来就可以配置具体pipeline了,首先使用Jenkins的New Item分别创建3个流水线类型的项目:

在Jenkins中新建3个流水线类型的项目,分别叫feature-pipeline、dev-pipeline、master-pipeline,然后对这3个项目分别进行配置,先来看feature-pipeline的配置:

首先要配置的项是Build Triggers,在其中勾选Opened Merge Request Events,并且把Rebuild open Merge Requests设置成On push to source branch:

然后点击Advanced按钮,进行高级设置:

这里需要注意的地方是原分支是任何分支,目标分支是dev分支,然后生成一个Secret token,这个token在配置gitlan webhooks的时候会用到。

接下来是配置Pipeline项:

这个地方需要配置具体的流水线仓储的地址,在credentials的地方,使用账号密码登录到gitlab即可。

dev流水线和master流水线配置略有不同,其中dev分支需要配置成accepted merge request events,意思就是当组长接受合并请求的时候触发:

而master分支需要改变的地方是匹配的分支,表示只接受从dev分支到master分支的合并请求:

到这里Jenkins的配置已经配置完成,接下来再回到gitlab进行联动配置,首先配置项目的webhoos,在项目的Integrations Settings里面添加一个webhooks:

其中URL就填写Jenkins的Build Triggers项目自动生成的那个URL,secret token是在Build Triggers的高级选项里面生成的那个token,触发的选项选择Merge request events,表示当合并请求的时候进行触发,点击保存,gitlab和Jenkins的配置基本上就完成了。

最后看一下3个项目中的Jenkinsfile:

pipeline {
    agent {
        label ‘slave-pipeline‘
    }
    options {
        gitLabConnection(‘gitlab‘)
    }
    stages {
        stage(‘Prepare‘){
            steps{
                script{
                        git branch: ‘${gitlabSourceBranch}‘, changelog: false, credentialsId: ‘gitlab‘, poll: false, url: ‘https://gitlab.com/lizongshenblogs/applications/devopsdemo.git‘

                        script {
                            GIT_COMMIT_ID = sh(returnStdout: true, script: ‘git rev-parse --short HEAD‘).trim()
                            IMAGE_TAG = "${GIT_COMMIT_ID}-snapshot"
                            INGRESS_HOST = "preview-${gitlabSourceRepoName}-${gitlabMergeRequestIid}"
                            MR_URL = "${gitlabSourceRepoHomepage}/merge_requests/${gitlabMergeRequestIid}"

                            build_tag = "feature-${gitlabSourceRepoName}-${gitlabSourceBranch}-${GIT_COMMIT_ID}"
                            currentBuild.displayName = "#" + BUILD_NUMBER + "_" + gitlabMergeRequestIid + "_" + build_tag
                        }
                }
            }

        }

        stage(‘Build‘) {

            when {
                expression {
                    "${gitlabTargetBranch}" == ‘dev‘
                }
            }

            steps {
                script {
                    updateGitlabCommitStatus name: ‘Build‘, state: ‘running‘

                    try {

                        echo "开始编译..."

                    } catch(Exception ex){
                        updateGitlabCommitStatus name: ‘Build‘, state: ‘failed‘
                        throw ex;
                    } finally {

                    }

                    updateGitlabCommitStatus name: ‘Build‘, state: ‘success‘

                }
            }
        }
        stage(‘Test‘) {
            steps {
                script {
                    updateGitlabCommitStatus name: ‘Test‘, state: ‘running‘

                    try {
                        echo "开始进行单元测试..."
                    } catch(Exception ex){
                        updateGitlabCommitStatus name: ‘Test‘, state: ‘failed‘
                        throw ex;
                    } finally {

                    }

                    updateGitlabCommitStatus name: ‘Test‘, state: ‘success‘

                }
            }
        }
        stage(‘Deploy‘) {
            steps {
                script {
                    updateGitlabCommitStatus name: ‘Deploy‘, state: ‘running‘

                    try {
                        echo "开始进行发布..."

                    } catch(Exception ex){
                        updateGitlabCommitStatus name: ‘Deploy‘, state: ‘failed‘
                        throw ex;
                    } finally {

                    }

                    updateGitlabCommitStatus name: ‘Deploy‘, state: ‘success‘
                    addGitLabMRComment comment: "App ${gitlabSourceRepoName} preview link: <a href=‘http://localhost‘>${gitlabSourceRepoName}</a>"
                }
            }
        }
    }

    post {
        failure {
            updateGitlabCommitStatus name: ‘Complete‘, state: ‘failed‘
        }
        success {
            updateGitlabCommitStatus name: ‘Complete‘, state: ‘success‘
        }
    }
}

其中updateGitlabCommitStatus就可以实时地把Jenkins的构建状态发回到gitlab中去:

点击这些构建状态,就可以实时地查看到构建日志。在这里gitlab和Jenkins的配置基本上就全部完成了,接下来再看一下gitlab中关于代码管理配置,一般情况下,dev分支和master分支是不允许直接push代码的,只允许从需求分支中合并代码,这就需要在gitlab的       Settings - Repository - Protected Branches中把dev和master保护起来:

另外还可以设置只有当流水线成功了以后,才可以进行合并:

通过这样一些保护措施,就可以让dev和master分支变得相对稳定。由于篇幅有限,再加上Jenkinsfile中包含了太多的定制化敏感内容,只能进行一些删减,如果有不明白的地方,可以私下找我相互交流。

写在最后:DevOps是一个很广泛的话题,今天讲的GitLab+Jenkins这套流程只是DevOps中的一部分,完全实现DevOps还需要更多的流程配合,以后有机会再为大家分享。

原文地址:https://www.cnblogs.com/lizongshen/p/11493945.html

时间: 2024-08-01 12:26:50

基于GitLab+Jenkins的DevOps赋能实践的相关文章

基于Gitlab+Jenkins的代码自动化发布

这里所讲的自动化发布是指代码从提交到仓库,到发布到目标服务器的整个过程. 主要涉及到两个工具Gitlab,Jenkins,要完成自动化还需要rsync,qqbot,log,ant.shell脚本,python等. Gitlab:我们主要用它来做代码的仓库 Jenkins:用来执行任务的持续集成,构建等.一.大体的自动化思路: 开发人员push代码到gitlab,触发webhook,调用jenkins job. jenkins job 执行拉取代码,编译,调用loadblance,下架部分服务器更

DevOps企业实践与架构

原文地址:http://www.sohu.com/a/112351816_355140 什么是DevOps及其误区 DevOps概念从2009年提出已有8个年头.可是在8年前的那个时候,为什么DevOps没有迅速走红呢?即便是在2006年Amazon发布了ECS,微软在2008年和2010年提出和发布了Azure,DevOps的重要性似乎都没有那么强烈.我分析其原因主要有: 第一个很重要的原因是因为那时候云计算还是小众产品,更多的与虚拟化.虚拟机相关,它们还是重量级的IT基础设施. 第二个很重要

基于 Docker 的微服务架构实践

本文来自作者 未闻 在 GitChat 分享的{基于 Docker 的微服务架构实践} 前言 基于 Docker 的容器技术是在2015年的时候开始接触的,两年多的时间,作为一名 Docker 的 DevOps,也见证了 Docker 的技术体系的快速发展.本文主要是结合在公司搭建的微服务架构的实践过程,做一个简单的总结.希望给在创业初期探索如何布局服务架构体系的 DevOps,或者想初步了解企业级架构的同学们一些参考. Microservice 和 Docker 对于创业公司的技术布局,很多声

gitlab + jenkins 自动部署

一.安装gitlab 和 jenkins 直接克隆项目 git clone [email protected]:GH16/devops.git 进入项目,直接运行, 等待五分钟左右部署(显示出错也会重启继续初始化) ? ~ cd devops ? devops git:(master) ls README.en.md docker-compose.yml jenkins stop.sh README.md gitlab start.sh ? devops git:(master) bash st

gitlab+jenkins自动化部署

基于gitlab和jenkins的自动化部署 Gitlab基于Jenkins自动化部署教程: https://blog.csdn.net/aaaaaab_/article/details/82012044 https://www.cnblogs.com/dengbingbing/p/10448185.html GitLab是一个代码仓库,用来管理代码. Jenkins是一个自动化服务器,可以运行各种自动化构建.测试或部署任务.所以这两者结合起来,就可以实现开发者提交代码到GitLab,Jenki

gitlab+jenkins+hook代码自动构建发布上线

Gitlab+Jenkins+Hook 1.gitlab和jenkins的安装见: http://www.cnblogs.com/cuishuai/p/7544663.html http://www.cnblogs.com/cuishuai/p/7544775.html 2.gitlab配置 1)创建一个project,并创建一个monkey的分支. 2)对分支进行设置: 点击project->settings->integrations: 1. 2. 3 Webhook,点击test,返回如

基于ITIL的SCOM监控最佳实践

1.  按照系统类别进行监控 很多朋友在使用SCOM进行监控的时候,往往只是导入管理包,推送代理,并不会思考很多,那么在这种情况下,SCOM在进行监控的时候都是基于缺省的类对象进行监控,比如说Windows计算机,一次就只能以一台Windows计算机的维度去监控,点击一台Windows计算机,下面会是关于这台计算机的进一步信息,比如这台计算机上面的磁盘,CPU,内存,数据库状态. 但是,这种监视方式太狭隘了,而且不便于整体统计,如果企业有很多业务系统呢,每个业务系统下面有很多机器,当企业要统计业

GitLab + Jenkins + Docker + Kubernetes。

目前方案是GitLab + Jenkins + Docker + Kubernetes. 方案的工作流程如下:首先,开发人员提交代码代码提交:随后,GitLab 会自动触发Jenkins job,Jenkins job会构建相应的镜像,放在一个Kubernetes的Pod里面:接下来,Kubernetes的Pod会把模块需要的其他依赖都包含在其内部(比如MySQL.Redis.MongoDB等),运行robot测试用例,测试用例的结果最后会反馈到Jenkins中:所有测试通过之后,GitLab把

京东基于Spark的风控系统架构实践和技术细节

京东基于Spark的风控系统架构实践和技术细节 时间 2016-06-02 09:36:32  炼数成金 原文  http://www.dataguru.cn/article-9419-1.html 主题 Spark软件架构 1.背景 互联网的迅速发展,为电子商务兴起提供了肥沃的土壤.2014年,中国电子商务市场交易规模达到13.4万亿元,同比增长31.4%.其中,B2B电子商务市场交易额达到10万亿元,同比增长21.9%.这一连串高速增长的数字背后,不法分子对互联网资产的觊觎,针对电商行业的恶