精华内容
下载资源
问答
  • 利用jenkins,gitlab,构建自动化的代码发布流水线,并自动部署到k8s集群中。
  • 作者 | Rahul Jain策划 | 田晓旭近十年来,持续集成(Continuous Integration,CI)和持续交付(Continuous Delivery,CD)领域都取得...

    作者 | Rahul Jain

    策划 | 田晓旭

    近十年来,持续集成(Continuous Integration,CI)和持续交付(Continuous Delivery,CD)领域都取得了很大的进步。DevOps 测试的兴起导致了对 CI/CD 工具的快速需求。现有的解决方案总是随着时间的推移而改进,大量新产品或新版本正在进入 QA 领域。当你手头有这么多选项时,选择正确的工具确实会有一点儿挑战。

    在所有可选的用于测试的 CI/CD 工具中,Jenkins 和 GitLab CI/CD 是你肯定应该考虑的两款工具。Jenkins 在 GitHub 上有 16,000+ 点赞,而 GitLab CI/CD 有 2012 个点赞。Jenkins 的点赞数是 GitLab CI/CD 的点赞数的 8 倍多。然而,这些数字并不是选择一款 CI/CD 工具时需要查看的唯一东西。这也是尽管在点赞数上有巨大的差距,Jenkins vs GitLab CI/CD 在多个评审平台上还有着激烈的竞争。

    以 G2 为例,Jenkins 在 G2 上平均评分为 4.3 星,有 288 条评论;GitLab CI/CD 在 G2 上的平均评分为 4.4 星,有 270 条评论。可以说,Jenkins vs GitLab CI/CD 是一场旗鼓相当的竞争。有趣的是,Jenkins 是在 2011 年发布的,而且在 CI/CD 业务上,它一直是测试人员的首选。然而,自 2014 年发布以来,GitLab CI/CD 一直凭借尖端的功能而高居榜首。我们在发布这篇文章时,在社交媒体上进行了一次民意调查。

    另一个被提到最多的工具是 GitLab CI/CD。作为一个 DevOps 测试专家,你需要根据你自己的项目、预算和其它需求来仔细审查这些工具。为了帮助你,我将对 Jenkins vs GitLab CI/CD 做一个深入的评估,帮助你确定合适的 CI/CD 工具来满足你的项目需求。

    1Jenkins 介绍

    Jenkins 是一款著名的可扩展的用于自动化部署的开源 CI/CD 工具。Jenkins 是完全用 Java 编写的,是在 MIT 许可下发布的。它有一组强大的功能,可以将软件的构建、测试、部署、集成和发布等相关任务自动化。这款用于测试的自动化 CI/CD 工具可以在 macOS、Windows 和各种 UNIX 版本(例如 OpenSUSE、Ubuntu、Red Hat 等)系统上使用。除了通过本地安装包安装,它还可以在任何安装过 Java 运行时环境(Java Runtime Environment,JRE)的机器上单独安装或者作为一个 Docker 安装。

    Jenkins 团队还有一个子项目叫做 Jenkins X,专门运行一个与 Kubernetes 无缝衔接的开箱即用的 pipeline。Jenkins X 巧妙地集成了 Helm、Jenkins CI/CD 服务器、Kubernetes 以及其它一些工具,来提供一个内置最佳实践的规范的 CI/CD 工具 pipeline,例如使用 GitOps 来管理环境。

    使用 Jenkins 的一个加分点是,其脚本结构良好、易于理解并且可读性很强。Jenkins 团队已经开发了近 1000 个插件,使得应用程序可以与其它熟悉的技术混合使用。除此之外,还可以使用 Credentials Command 之类的插件。这使得向脚本中添加隐藏的身份验证凭证等变得简单可行。

    一旦 Jenkins pipeline 开始运行,你还可以验证每个阶段通过与否以及每个阶段的总数。但是,你不能在提供的图形化概览中检查特定作业的状态。你可以做的是跟踪终端中的作业进度。

    2Jenkins 核心特性

    Jenkins 以其易于配置、自动化构建过程和它向用户提供的大量文档而闻名。当谈到 DevOps 测试时,Jenkins 被认为是非常可靠的,而且没必要监视整个构建过程,而对于其它 CI/CD 工具则不会这么放心。让我们看看 Jenkins 提供的一些最重要的特性——

     1. 免费、开源且易安装

    Jenkins 在 macOS、Unix、Windows 等平台上都非常容易安装。它可以与 Docker 结合,为自动化作业带来更高的一致性和额外的速度。它可以可以作为一个 servlet 运行在 Apache Tomcat 和 GlassFish 这样的 Java 容器中。你可以找到许多支持和文档来指导整个安装过程。

     2. 广泛的插件生态系统

    这个工具的插件生态系统相比于其它 CI/CD 工具来说更成熟。目前,这个生态系统提供了 1500+ 插件。由于这些插件的范围从特定语言开发工具到构建工具,这使得定制化变得非常简单便利。因此,你不需要购买昂贵的插件。Jenkins 插件集成也适用于一些 DevOps 测试工具。

     3. 易于安装和配置

    这个工具的配置过程非常简单,只需要在安装时操作一些步骤。Jenkins 的升级过程也不麻烦且非常直接。而且其提供的支持文档对于你根据自己的需求配置工具也帮助很大。

     4. 有用的社区

    如你所知,这是一个开源项目,拥有一个庞大的插件生态系统,所有插件的功能都得到了大量社区贡献的支持。伴随 Jenkins 的惊人的社区参与度也是促进其成熟的一个主要原因。

     5. 提供 REST API

    Jenkins 提供了 REST 风格的应用程序接口来便于扩展。Jenkins 的远程接入 API 有三种不同的风格——Python、XML 以及 JSON(支持 JSONP)。Jenkins 网站中有一个页面有关于 Jenkins API 的描述性文档,有助于扩展。

     6. 支持并行执行

    Jenkins 支持并行测试。你可以轻松将它与不同的工具集成并得到构建是否成功的通知。开发者甚至可以在不同的虚拟机上并行执行多个构建来加速测试过程。

     7. 轻松分配工作

    它可以毫不费力地运行分布式工作,即任务在不同的机器上运行,而不会对 GUI(用户图形界面)造成影响。值得一提的是,与其它 CI/CD 工具相比,只有这款工具能够使用与运行 GUI 相关任务的同一个实例。

    3GitLab CI/CD 介绍

    在所有用于测试的 CI/CD 工具中,GitLab CI/CD 毫无疑问是最新且最受赞赏的选择。它是一款免费且自托管的内置于 GitLab CI/CD 的持续集成工具。GitLab CI/CD 有一个社区版本,提供了 git 仓库管理、问题跟踪、代码评审、wiki 和活动订阅。许多公司在本地安装 GitLab CI/CD,并将它与 Active Directory 和 LDAP 服务器连接来进行安全授权和身份验证。

    GitLab CI/CD 先前是作为一个独立项目发布的,并从 2015 年 9 月发布的 GitLab 8.0 正式版开始集成到 GitLab 主软件。一个单独的 GitLab CI/CD 服务器可以管理 25000 多个用户,它还可以与多个活跃的服务器构成一个高可用性的配置。

    GitLab CI/CD 和 GitLab 是用 Ruby 和 Go 编写的,并在 MIT 许可下发布。除了其它 CI/CD 工具关注的 CI/CD 功能之外,GitLab CI/CD 还提供了计划、打包、源码管理、发布、配置和审查等功能。

    GitLab CI/CD 还提供了仓库,因此 GitLab CI/CD 的集成非常简单直接。在使用 GitLab CI/CD 时,phase 命令包含一系列阶段,这些阶段将按照精确的顺序实现或执行。在实现后,每个作业都被描述和配置了各种选项。

    每个作业都是一个阶段的一个部分,会在相似的阶段与其它作业一起自动并行运行。一旦你那样做,作业就被配置好了,你就可以运行 GitLab CI/CD 管道了。其结果会稍后演示,而且你可以检查某个阶段你指定的每一个作业的状态。这也是 GitLab CI/CD 与其它用于 DevOps 测试的 CI/CD 工具的不同之处。

    4GitLab CI/CD:核心特性

    GitLab CI/CD 是最受欢迎的用于 DevOps 测试的 CI/CD 工具之一。GitLab CI/CD 文档丰富、易于控制且用户体验好。如果你刚接触 GitLab CI/CD,我列举了 GitLab CI/CD 的主要功能,会有助于你了解它。来看看吧。

     1. 高可用性部署

    它被广泛采用,是最新可用的开源 CI/CD 工具之一。GitLab CI/CD 的安装和配置都很简单。它是内置于 GitLab 的免费且自托管的持续集成工具。GitLab CI/CD 逐渐发展成最受欢迎的用于自动化部署的免费 CI/CD 工具之一。

     2.Jekyll 插件支持

    Jekyll 插件是一个静态网站生成器,对 GitHub Pages 有比较好的支持,它使得构建过程更简单。Jekyll 插件支持使用 HTML 文件和 Markdown,基于你的布局偏好,创建一个完全静态的站点。你可以通过编辑你的 _config.yml 文件来很容易地配置大部分 Jekyll 设置,例如,你的网站的插件和主题。

     3. 里程碑设置

    工具中的里程碑设置是跟踪问题、改进系列问题、绘制仓库的请求的一种很好的方法。你可以轻易将项目里程碑分配给任何问题,或者合并项目中不常见的请求,或者将组里程碑分配给一组问题,或者合并该组中任何项目的请求。

     4. 自动伸缩的持续集成运行器

    自动伸缩的 GitLab 持续集成运行器可以轻松管理和节省 90%  EC2 成本。这真的非常重要,特别是对于并行测试环境。而且,对于组件级别或者项目级别的运行器,可以跨代码库使用。

     5. 问题跟踪和问题讨论

    由于其强大的问题跟踪和问题讨论功能,GitLab 是无数开源项目首选的 CI/CD 工具。它巧妙地允许你并行测试拉取请求和分支。为了简单方便地监控,测试结果被显示在 GitHub UI 上。由于简单的用户界面,相比于 Jenkins,它使用起来更加友好。

     6. 使用访问控制管理 Git 仓库

    你可以通过访问权限轻松管理 git 仓库。你可以轻松地向单个仓库的协作者授予写入 / 读取访问权限,甚至特定组织的成员也可以对组织的仓库进行更细粒度的访问控制。

     7. 活跃的社区支持

    活跃且进步的社区是 GitLab CI/CD 的一个主要加分点。提供的所有支持都是开箱即用的,不需要在额外的插件安装中进行修改。

     8. 代码评审和合并请求

    GitLab CI/CD 不仅仅用于构建代码,还用于评审代码。它允许使用简单的合并请求和合并管理系统来进行改进协作。它几乎支持所有的版本控制系统和构建环境。在 GitHub 项目下实现了大量协作方案,这些项目有助于 GitLab CI/CD 的扩展。

    5Jenkins vs GitLab CI/CD 的功能对比

    Jenkins 和 GitLab CI/CD 都有它们非常擅长的领域和各自的技术追随者。然而,在讨论 Jenkins vs GitLab CI/CD 之争时,会讨论许多功能。下图是这两个 CI/CD 工具提供的所有功能的比较。

    功能JENKINSGITLAB CI/CD
    开源 / 商业性开源开源
    产品类型自托管 / 本地部署自托管 / 本地部署
    内置 CI/ CDJenkins 根据需求支持 CI/CD我们不需要为了 CI/CD 而安装任何东西,这是一个内置功能
    独特功能插件自动化 DevOps/ 允许持续集成和代码管理在同一个地方进行。
    支持 / SLA没有官方支持或 SLAYes
    安装配置简单简单
    自托管选项开源软件和自托管是使用它的唯一方法Yes
    构建 Pipelines通过 Jenkins Pipeline DSL 自定义 pipelineYes
    应用程序性能监控没有提供用于分析性能的功能展示所有部署的应用程序的性能指标
    生态系统1000 个社区插件Yes
    全面的 API提供了全面的 API 功能提供了在软件项目中进行深层集成的 API
    特定语言支持:JavaScriptYesYes
    集成允许与其它工具集成(例如:Slack、GitHub)很多第三方集成都可以访问,最著名的是 GitHub 和 Kubernetes。
    CI/ CD 部署面板部分支持项目中的 CI 和 CD 功能可以根据项目中的 pipeline 历史和最近状态为每一个用户更改一个单独的面板
    APIYesYes, 提供了一个 REST API & 一个(新的)GraphQL API
    代码质量通过 Sonarqube 插件以及其它可以用来验证代码质量的不同插件来提供代码质量检查。GitLab 也提供了一个功能来仔细检查代码的质量。

    6Jenkins vs GitLab CI/CD 之间的区别

    既然你已经看了 Jenkins vs GitLab CI/CD 之间的功能对比,那也是时候来看看这两个 DevOps 测试工具之间的差别。这些差别将帮助你理解 Jenkins vs GitLab CI/CD 之争背后的真正原因。

    在 GitLab CI/CD 的帮助下,你可以通过对分支和其它一些方面的完全控制来控制 Git 仓库,从而使你的代码免受突然的威胁。然而,使用 Jenkins 时,你虽然可以控制代码库,但只有几个方面。Jenkins 不允许完全控制分支和其它方面。

    Jenkins 是“内部托管的”和“免费开源的”,这也是程序员选择它的原因。另一方面,GitLab CI/CD 是“自托管的”和“免费的”,这就是为什么开发人员更喜欢它。

    在 GitLab CI/CD 中,每一个项目都有一个跟踪程序,它将跟踪问题并进行代码评审来提高效率。而在 Jenkins 工具中,它改变了一些设置支持和一个简单的安装配置过程。

    7Jenkins vs GitLab CI/CD 优缺点

    我希望你现在理解 Jenkins vs GitLab CI/CD 这两个工具。为了更进一步,我列举了与 Jenkins vs GitLab CI/CD 有关的主要优点和缺点。我知道你已经决定了你要使用的 DevOps 测试工具,本节将帮您增强选择正确的 CI/CD 工具的信念。

     Jenkins 的优点

    • 大量插件库

    • 自托管,例如对工作空间的完全控制

    • 容易调试运行,由于对工作空间的绝对控制

    • 容易搭建节点

    • 容易部署代码

    • 非常好的凭证管理

    • 非常灵活多样的功能

    • 支持不同的语言

    • 非常直观

     Jenkins 的缺点

    • 插件集成复杂

    • 对于比较小的项目开销比较大,因为你需要自己搭建

    • 缺少对整个 pipeline 跟踪的分析

     GitLab CI/CD 的优点

    • 更好的 Docker 集成

    • 运行程序扩展或收缩比较简单

    • 阶段内的作业并行执行

    • 有向无环图 pipeline 的机会

    • 由于并发运行程序而非常易于扩展收缩

    • 合并请求集成

    • 容易添加作业

    • 容易处理冲突问题

    • 良好的安全和隐私政策

     GitLab CI/CD 的缺点

    • 需要为每个作业定义构建并上传 / 下载

    • 在实际合并发生之前测试合并状态是不可能的

    • 还不支持细分阶段

    8Jenkins vs GitLab CI/CD 如何选

    Jenkins 和 GitLab CI/CD 都有它们各自的优点和缺点,你在这两个工具之间的最终选择取决于项目需求和规格。其中每一个 CI/CD 工具都有它自己的优势和劣势,发布时都实现了完全相同的需求:自动化 CI/CD(持续集成和交付)的过程。Jenkins 用于持续集成,而 GitLab CI/CD 用于代码协作和版本控制。

    在选择最佳的用于 DevOps 测试的 CI/CD 工具时,除了突出的特性,你还应该查看价格列表和内部熟练度。

     作者介绍

    Rahul Jain 是 LambdaTest 的一名数字营销专家,热爱阅读和写作关于最新技术趋势、SEO、体育和旅行相关的内容。

    原文链接

    https://dzone.com/articles/jenkins-vs-gitlab-ci-battle-of-cicd-tools

    点个『在看』支持下 

    展开全文
  • CI/CD是什么?

    万次阅读 多人点赞 2019-07-09 19:25:43
    最近在求职中,会看到有的公司要求是了解CI/CD,那么这个CI/CD是什么呢? 通过查找资料后得知就是我们耳熟的持续集成、持续部署等持续动作。 CI全名Continuous Integration,啥意思?就是我们经常听到的持续集成...

    最近在求职中,会看到有的公司要求是了解CI/CD,那么这个CI/CD是什么呢?
    通过查找资料后得知就是我们耳熟的持续集成、持续部署等持续动作。

    CI全名Continuous Integration,啥意思?就是我们经常听到的持续集成概念。
    当开发每天会提交多次代码到主干上,会做一些重复性的动作时,就可以用持续集成环境来操作。
    有集成了,就肯定少不了它的好基友,没错就是CD。
    CD全名是Continuous Deployment,是持续部署。
    CD还有个小号,交持续交付,英文全称是Continuous delivery,缩写也是CD。

    CI/CD优点是,重复的工作用自动化来代替、减少时间成本、版本发布时间减短了。

    现在很多公司都有做持续集成,Jenkins就是一个持续集成的工具,开源的,基于 JAVA语言的。

    展开全文
  • CI/CD架构简介和配置

    千次阅读 2019-10-15 12:53:31
    CI/CD架构 CI/CD架构简介 CI/CD:持续集成/持续发布 continuous integration/continuous deployment CI/CD主要运用了jenkins进行对后端的开发代码的拉取,经过自动编译,打包,测试后,自动发布到tomcat服务器上...

    CI/CD架构

    CI/CD架构简介

    CI/CD:持续集成/持续发布
    continuous integration/continuous deployment
    CI/CD主要运用了jenkins进行对后端的开发代码的拉取,经过自动编译,打包,测试后,自动发布到tomcat服务器上,实现自动化的产品上线。

    CI/CD顶梁柱jenkins简介

    jenkins的功能是将获取的代码进行统一的编译,打包,发布到tomcat等容器上。
    其操作界面友好,由java语言编写,需要安装jdk。

    jenkins特性

    • 易安装,仅需要一个war包和jdk。
    • 图形化页面,配置简单。
    • 分布式构建:能够连接多台机器构建/测试。
    • 支持第三方插件:可以通过第三方插件来扩展功能,进行二次开发。

    jenkins工作流程

    在这里插入图片描述

    • step1:开发人员将代码上传到版本库
    • step2:jenkins通过配置从版本库拉取代码文件
    • step3:jenkins通过maven插件,将代码编译测试
    • step4:step3无误后通过ssh插件传递到tomcat服务器上。
    • step5:应用服务器通过shell脚本自动实现产品上线。

    部署jenkins

    • 版本库部署,获取代码。(略)
    • 安获取jdk包,maven包,tomcat包,jenkins.war包,并解压到/usr/local下,改成简单的名字。(略)
      war包地址:http://updates.jenkins-ci.org/download/war/
    • 改写jdk和码maven的环境变量,将maven移到java目录下
    [root@jenkins ~]# vi /etc/profile
    JAVA_HOME=/usr/local/java
    MAVEN_HOME=/usr/local/java/maven
    PATH=$PATH:$JAVA_HOME/bin:$MAVEN_HOME/bin
    export PATH USER LOGNAME MAIL HOSTNAME HISTSIZE HISTCONTROL JAVA_HOME MAVEN_HOME
    [root@jenkins ~]# source /etc/profile
    [root@jenkins ~]# java -version
    java version "1.8.0_191"
    Java(TM) SE Runtime Environment (build 1.8.0_191-b12)
    Java HotSpot(TM) 64-Bit Server VM (build 25.191-b12, mixed mode)
    [root@jenkins ~]# mvn -v
    Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-18T02:33:14+08:00)
    Maven home: /usr/local/java/maven
    Java version: 1.8.0_191, vendor: Oracle Corporation, runtime: /usr/local/java/jre
    Default locale: zh_CN, platform encoding: UTF-8
    OS name: "linux", version: "3.10.0-693.el7.x86_64", arch: "amd64", family: "unix"
    

    清理tomcat环境

    [root@jenkins ~]# rm -rf /usr/local/tomcat/webapps/*
    

    将jenkins.war移到该目录下

    [root@jenkins ~]# mv /jenkins.war /usr/local/tomcat/webapps/
    [root@jenkins ~]# /usr/local/tomcat/bin/startup.sh
    Using CATALINA_BASE:   /usr/local/tomcat
    Using CATALINA_HOME:   /usr/local/tomcat
    Using CATALINA_TMPDIR: /usr/local/tomcat/temp
    Using JRE_HOME:        /usr/local/java
    Using CLASSPATH:       /usr/local/tomcat/bin/bootstrap.jar:/usr/local/tomcat/bin/tomcat-juli.jar
    Tomcat started.
    
    • 为了jenkins利用ssh的免密登陆功能,要将jenkins服务器的ssh公钥发送给web服务器
    [root@jenkins ~]# ssh-keygen
    [root@jenkins ~]# ssh-copy-id -i 【服务器端的ip】
    

    浏览器访问页面
    http://192.168.178.132:8080/jenkins

    完成密码验证后,安装推荐的插件
    在这里插入图片描述
    添加以下所需要的插件
    Deploy to container,Maven Integration,Publish Over SSH,ssh见图,
    点击“直接安装”
    在这里插入图片描述
    在这里插入图片描述在这里插入图片描述

    配置ssh

    记得“保存”配置
    在这里插入图片描述在这里插入图片描述在这里插入图片描述

    新增jdk,maven

    记得“保存”配置!
    在这里插入图片描述
    在这里插入图片描述在这里插入图片描述

    jenkins构建发布

    回到主页,新建item
    在这里插入图片描述

    在这里插入图片描述在这里插入图片描述在这里插入图片描述在这里插入图片描述在这里插入图片描述 部署web服务器:

    • 安装jdk,tomcat,改写环境变量
    [root@webs ~]# vi /etc/profile
    添加以下内容:
    export JAVA_HOME=/usr/local/java
    export PATH=$JAVA_HOME/bin:$JAVA_HOME/jre/bin:$PATH
    export CLASSPATH=.:$JAVA_HOME/lib:$JAVA_HOME/jre/lib:$JAVA_HOME/lib/tools.jar
    export TOMCAT_HOME=/usr/local/tomcat
    [root@webs ~]# source /etc/profile
    

    清理tomcat默认发布目录下的neirong

    [root@webs ~]# rm -rf /usr/local/tomcat/webapps/*
    

    创建自动上线的脚本

    [root@webs ~]# mkdir -p /opt/script
    [root@webs ~]# cd /opt/script
    [root@webs script]# vi app-jenkins.sh
    #!/usr/bin/bash
    #本脚本适用于jenkins持续集成,实现备份war包到代码更新上线!使用时请注意全局变量。
    #================
    #Defining variables
    export JAVA_HOME=/usr/local/java
    webapp_path="/usr/local/tomcat/webapps"
    tomcat_run="/usr/local/tomcat/bin"
    updata_path="/data/update/`date +%F-%T`"
    backup_path="/data/backup/`date +%F-%T`"
    tomcat_pid=`ps -ef | grep tomcat | grep -v grep | awk '{print $2}'`
    files_dir="easy-springmvc-maven"
    files="easy-springmvc-maven.war"
    job_path="/root/upload"
    
    #Preparation environment
    echo "Creating related directory"
    mkdir -p $updata_path
    mkdir -p $backup_path
    
    echo "Move the uploaded war package to the update directory"
    mv $job_path/$files $updata_path
    
    echo "========================================================="
    cd /opt
    echo "Backing up java project"
    if [ -f $webapp_path/$files ];then
    	tar czf $backup_path/`date +%F-%H`.tar.gz $webapp_path
    	if [ $? -ne 0 ];then
    		echo "打包失败,自动退出"
    		exit 1
    	else
    		echo "Checking if tomcat is started"
    		if [ -n "$tomcat_pid" ];then
    			kill -9 $tomcat_pid
    			if [ $? -ne 0 ];then
    				echo "tomcat关闭失败,将会自动退出"
    				exit 2
    			fi
    		fi
    		cd $webapp_path
    		rm -rf $files && rm -rf $files_dir
    		cp $updata_path/$files $webapp_path
    		cd /opt
    		$tomcat_run/startup.sh
    		sleep 5
    		echo "显示tomcat的pid"
    		echo "`ps -ef | grep tomcat | grep -v grep | awk '{print $2}'`"
    		echo "tomcat startup"
    		echo "请手动查看tomcat日志。脚本将会自动退出"
    	fi
    else
    	echo "Checking if tomcat is started"
            if [ -n "$tomcat_pid" ];then
            	kill -9 $tomcat_pid
                    if [ $? -ne 0 ];then
                    	echo "tomcat关闭失败,将会自动退出"
                           	exit 2
                    fi
            fi
    	cp $updata_path/$files $webapp_path
    	$tomcat_run/startup.sh
            sleep 5
            echo "显示tomcat的pid"
            echo "`ps -ef | grep tomcat | grep -v grep | awk '{print $2}'`"
            echo "tomcat startup"
            echo "请手动查看tomcat日志。脚本将会自动退出"
    fi
    

    给脚本执行权限

    [root@webs ~]# chmod 777 /opt/script/app-jenkins.sh
    

    在jenkins页面上开始构建
    在这里插入图片描述
    在这里插入图片描述
    在web服务器的/usr/local/tomcat/webapps/下可以看到相应的war包,再用浏览器访问web服务器检测就可以了。

    展开全文
  • Drone CI:搭建自己CI/CD(一)

    千次阅读 2020-05-15 13:47:44
    CI/CD简介 CI全称为Continuous Integration,意为持续集成,是在源代码变更后自动检测、拉取、构建和进行自动化测试的过程,属于开发人员的自动化流程。该解决方案可以解决在一次开发中有太多应用分支,从而导致相互...

    CI篇:安装与配置

    CI/CD简介

    CI全称为Continuous Integration,意为持续集成,是在源代码变更后自动检测、拉取、构建和进行自动化测试的过程,属于开发人员的自动化流程。该解决方案可以解决在一次开发中有太多应用分支,从而导致相互冲突的问题。其基本思路是,自动化监测代码仓库的变化并拉取最新代码、编译构建和自动化测试。CI的触发方式可分为以下三种:

    • 轮询:按一定的时间间隔反复询问代码仓库是否发生了变更,若发生了变更则开启CI流程
    • 定时:定期从代码仓库拉去最新代码并进行构建与测试,不必关心是否有变更发生
    • 推送:当代码仓库发生变更时,通过推送的方式(如webhook)通知CI进行任务,这需要CI环境被代码仓库访问到,因此需要一个外网可达地址

    CD指的是持续交付(Continuous Delivery)持续部署(Continuous Deployment)持续交付通常是指开发人员对应用的更改会自动进行错误测试并上传到存储库(如 GitHub 或容器注册表),然后由运维团队将其部署到实时生产环境中。持续部署指的是自动将开发人员的更改从存储库发布到生产环境,它以持续交付为基础,实现了管道后续阶段的自动化。

    CI/CD 既可能仅指持续集成和持续交付构成的关联环节,也可以指持续集成、持续交付和持续部署这三项构成的关联环节。

    请参考:redhat:什么是CI/CD

    Drone CI简介

    Drone CI官网说:

    Drone is a self-service Continuous Delivery platform for busy development teams.

    相对于常见的Jenkins,选中 Drone的原因在于它非常简洁,不像Jenkins那样复杂,同时它拥有可以满足基本需求的能力,并且提供了许多实用的插件,如GitHubEmailhelm微信钉钉

    需要注意的是,drone 0.8版本和0.1版本差别较大,本文使用1.0版本

    安装Drone CI - GitHub

    drone文档给出了相对于不同git仓库和部署方式的方案,支持的git仓库有:

    在这里插入图片描述

    拿github来说,drone提供了以下部署方式:

    在这里插入图片描述

    本节给出对于GitHub单机部署方案,对官方部署方案做了docker-compose方案的补充

    设置GitHub OAuth Application

    • 登陆你的github账户,在右上角点击个人头像,选择Setting,选择Developer settings,选择OAuth Application,选择新建一个application,如下图:

    在这里插入图片描述

    • HomePage是DroneCI的访问地址,若是Drone由本地部署,那就可以设置为http://127.0.0.1
    • Authorization callback URL是DoneCI的登陆地址,格式必须是{{HomePage}}/login,如http://127.0.0.1/login
    • 创建成功以后,拿到Client IDClient Secret
      在这里插入图片描述

    下载安装docker和docker-compose

    Docker安装文档

    下载drone docker

    docker pull drone/drone:1.0.0-rc.6
    

    启动drone server

    • docker 启动:

      docker run \
        --volume=/var/run/docker.sock:/var/run/docker.sock \
        --volume=/var/lib/drone:/data \
        --env=DRONE_GITHUB_SERVER=https://github.com \
        --env=DRONE_GITHUB_CLIENT_ID={% your-github-client-id %} \
        --env=DRONE_GITHUB_CLIENT_SECRET={% your-github-client-secret %} \
        --env=DRONE_RUNNER_CAPACITY=2 \
        --env=DRONE_SERVER_HOST={% your-drone-server-host %} \
        --env=DRONE_SERVER_PROTO={% your-drone-server-protocol %} \
        --env=DRONE_TLS_AUTOCERT=true \
        --publish=80:80 \
        --publish=443:443 \
        --restart=always \
        --detach=true \
        --name=drone \
        drone/drone:1.0.0-rc.6
      
    • docker-compse 启动
      上面的启动命令是drone官方文档的方案,下面给出我使用的docker compose的方法

      1. 创建.env文件,这是docker-compose启动时默认读取的文件,用来设置环境变量
      
      DRONE_SERVER_HOST=127.0.0.1
      DRONE_GITHUB_CLIENT_ID=XXXXXXXXXXXXXX
      DRONE_GITHUB_CLIENT_SECRET=XXXXXXXXXX
      DRONE_SERVER_PROTO=http
      DRONE_SECRET_SECRET=ci-drone
      
      
      1. 创建docker-compose.yml文件
      # drone server 部署
      version: "2"
      
      services:
        drone-server:
          image: drone/drone:1.0.0-rc.6
          ports:
            - 80:80
            - 443:443
          volumes:
            - /var/run/docker.sock:/var/run/docker.sock
            - /var/lib/drone:/data
          restart: always
          environment:
            - DRONE_GITHUB_CLIENT_ID=${DRONE_GITHUB_CLIENT_ID}
            - DRONE_GITHUB_CLIENT_SECRET=${DRONE_GITHUB_CLIENT_SECRET}
            - DRONE_SERVER_PROTO=${DRONE_SERVER_PROTO}
            - DRONE_SERVER_HOST=${DRONE_SERVER_HOST}
            - DRONE_TLS_AUTOCERT=false
            - DRONE_RUNNER_CAPACITY=8
            - DRONE_DEBUG=false
            - DRONE_LOGS_DEBUG=false
            - DRONE_GIT_ALWAYS_AUTH=false
            - DRONE_SECRET_SECRET=${DRONE_SECRET_SECRET}
      
      
      1. drone配置项说明
      • DRONE_GITHUB_CLIENT_ID: 在Github中创建OAuth Application时生成的Client ID
      • DRONE_GITHUB_CLIENT_SECRET: 在Github中创建OAuth Application时生成的Client Secret
      • DRONE_SERVER_PROTO: Drone提供服务的prototype,可选为httphttps
      • DRONE_SERVER_HOST: Drone的server地址,设置为127.0.0.1作为本地地址,也可以设置为外部可访问的域名或IP地址
      • DRONE_TLS_AUTOCERT: 设置是否自动开启安全传输层协议,若设置为true,那么drone server proto会设置为使用httpsDRONE_SERVER_PROTO设置为http也是无效
      • DRONE_RUNNER_CAPACITY: drone提供服务的最大并行度
      • DRONE_SECRET_SECRET: 可自由设置
      • Drone用到的端口号有:80和443
      1. 启动服务
        docker-compose up
      

      或者通过后台的方式运行:

        docker-compose up -d
      

    配置CI仓库

    • 通过浏览器访问:http://127.0.0.1 ,浏览器会重定向到github登陆认证页面
      在这里插入图片描述

    使用github账户登陆之后,浏览器被重定向回drone,并被授权访问你的github仓库
    在这里插入图片描述

    • 选中你要配置的仓库,点击ACTIVATE按钮,进入SETTINGS卡片,点击ACTIVATE按钮开启这个仓库.开启之后可以设置CI任务的基本配置。用过jenkins的人会发现,这个页面显然简洁一点。
      此时,github仓库中会添加一条webhook地址,当github仓库发生改变时会通过webhook通知drone server。
      不过,问题是这个webhook地址是DRONE_SERVER_HOST,如果配置为127.0.0.1或外网不可达时,这个webhook地址github是访问不到的。不过这不影响Cron Job的触发。

    • 配置里面有四个主要选项

      • Main: 主要配置

        • Project settings:设置是否开启仓库保护,若开启,那么每次触发CI自动编译都需要仓库管理员手动确认
        • Project visibilty:设置仓库可见性,因为你设置的host地址所有人都可以访问到,并通过自己的github账户登陆,可见性可以保护你的仓库
        • Configuration:设置CI任务的yaml配置文件,这里面制定了CI的所有流程,一般放在仓库根目录下,名为.drone.yaml,稍后会详细说明
          在这里插入图片描述
      • Secrets:
        Drone Secret文档中所说,不方便明文存储到代码仓库里的密码值,可以通过Repository SecretsEncrypted SecretsExternal Secrets来存储
        这里的Secrets设置可以指定Repository Secrets,在Secret Name中指定密码名称,Secret Value中设置该值。Allow Pull Requests是指,当是pull_request请求时这个密钥是否可被使用,因为其他人可能会通过pull request来触发CI,造成安全隐患。
        在这里插入图片描述
        .drone.yaml中可以通过from_secret引用,如下面的usernamepassword

        kind: pipeline
        name: default
        
        steps:
        - name: build
          image: alpine
          environment:
            USERNAME:
              from_secret: username
            PASSWORD:
              from_secret: password
        
      • Cron Jobs:定时任务
        这里可以通过任务名称,分支名称和时间指定定期的CI任务。前文提到,CI触发有三种规则轮询定期推送
        注:但这里的定期任务稍微有点怪,cron job的执行逻辑是定期触发一次检查,事件是指定分支的最后一次事件,执行的pipline会验证trigger规则,不像是通常说的定期任务,也不能说是轮询,因为轮询是监测是否有新事件。

      • Badges:编译状态图标
        这里提供了CI运行的状态图标,可以放到Git仓库里作为编译状态。不过Drone server的地址就不能简单的设置为127.0.0.1了,因为Github访问不到,需要一个外网IP或域名

    .drone.yaml文件声明CI过程

    Drone通过Pipline的方式来声明CI的执行过程,如文档所示。

    kind: pipeline
    name: api
    steps:
      # api unit test
      - name: api-test
        image: node:11
        depends_on: [clone]
        commands:
          - cd ./api/
          - npm install --registry https://registry.npm.taobao.org
          - cd ./dgc_sdk && npm install --production
          - cd .. && npm run test
    
      # web lint
      - name: web-lint
        image: node:10.15.1
        depends_on: [clone]
        commands:
          - cd ./web
          - npm install --registry https://registry.npm.taobao.org
          - npm run lint
    
    trigger:
      branch:
        - master
      event:
        - pull_request
        - push
    
    ---
    # stream test
    kind: pipeline
    name: stream
    steps:
      - name: stream test
        image: ccr.ccs.tencentyun.com/star/stream-test-base
        commands:
          - echo 'Hello!'
    
    trigger:
      branch:
        - stream
      event:
        - pull_request
    
    
    • steps指定CI执行的步骤,默认pipline或创建一个叫做clone的步骤,它是从git仓库克隆代码大步骤

    • 多个step之间可以通过depends_on来指定执行顺序,比如先clone,后build,然后deploy

    • 同一个pipline下的多steps之间默认是串行的,实现方式应该是下面的stepdepends_on紧邻的上一个step

    • pipline之间是并行的,同一个yaml文件里使用---分割多个pipline的定义

    • triggers是指在什么情况下才会执行ICI任务,比如只对master分支的pull requestpush事件触发

    • 在每一个step中,可以通过Conditions来指定在CI过程中是否执行该step,通过when关键字指定。trriger是指定pipline何时被执行,condition指定pipline中的step是否被执行,如:

      kind: pipeline
      name: default
      
      steps:
      - name: build
        image: golang
        commands:
        - go build
        - go test
        when:
          branch:
          - master
          - feature/*
      

    配置完成

    • 若是配置了Cron Job,那到到该时间点时,会触发CI的任务,此时pipline中的trigger规则会失效
    • 配置Drone CI之后,Github的check功能也会被启用,对每一次event都会监控CI的状态

    注:

    • 使用Drone 1.0,与0.8版本差异较大
    • 当刚绑定仓库之后,Drone无法手动触发CI
    • trigger中指定eventpull_request时,使用的分支为target branch;当trigger中指定eventtag时,指定的branch规则是无效的
    • Project settings设置为Protected后,每次CI任务都要手动确定
    • 关于gitlab私有 docker 镜像dns设置,在下一篇继续说

    参考链接:

    展开全文
  • 【运维面试】你能阐述下CI/CD吗?

    千次阅读 2021-04-07 10:47:52
    这个问题在面试中也经常被问到,主要考察几个方面: 你对新技术的了解? 你们公司是如何落地的,来我们公司是否可以借鉴? 三个概念: 持续集成CI: 代码合并,构建,部署...CI/CD的最终目的是为了减少人工干预,实现
  • gitlab ci/cd自动化部署流程

    千次阅读 2020-12-03 18:53:37
    nginx默认指向/gitci/ci/dist目录,这里我们在root账户里只创建/gitci,至于/ci/dist使我们在其他用户gitlab-runner里面完成,下面是具体操作 gitlab-runner安装流程 curl -L ...
  • 如何从零开始搭建 CI/CD 流水线

    千次阅读 2019-04-10 14:24:51
    来源 | Saurabh Kulshrestha 译者 | 徐进 持续集成和持续部署成为现代 DevOps ...在当前 DevOps 的趋势下,持续集成(CI)和持续部署(CD)具有支柱性地位,那么能够成功搭建 CI/CD 流水线就至关重要了。我们可能...
  • 使用GitLab CI/CD进行自动测试和部署

    千次阅读 2019-10-09 11:26:55
    1.1 CI/CD CI,Continuous Integration,为持续集成。即在代码构建过程中持续地进行代码的集成、构建、以及自动化测试等;有了 CI 工具,我们可以在代码提交的过程中通过单元测试等尽早地发现引入的错误; CD,...
  • 作者丨田晓旭来源丨InfoQ 2019 年 8 月 8 日,GitHub 官方博客发文称,程序员期待已久的功能来了,Github Actions 终于支持内置 CI...
  • CI/CD流程图

    千次阅读 2019-05-26 23:25:47
    CI/CD实践 在gitlab上定义WebHooc事件,若发生push到GitLab操作,则触发Jenkins的Job Jenkins从GitLab拉取代码,静态分析,启动服务,单元测试,构建镜像,推送到Docker仓库:Harbor仓库等动作 docker build docker...
  • GitLab CI/CD 基础教程(一)

    万次阅读 多人点赞 2019-03-08 08:57:09
    1.1 CI/CD CI,Continuous Integration,为持续集成。即在代码构建过程中持续地进行代码的集成、构建、以及自动化测试等;有了 CI 工具,我们可以在代码提交的过程中通过单元测试等尽早地发现引入的错误; CD,...
  • 本章节主要讲的是 springboot 项目发到 gitlab 仓库,触发 gitlab ci/cd 实现项目自动集成和部署,其中部署是以 k8s 方式部署 关于 gitlab-runner 安装和注册可以参考我的另一篇博客 Docker安装gitlab-runner 实现...
  • Gitlab CI/CD + Sonarqube for Embedded

    千次阅读 2018-12-07 09:12:58
     Gitlab是常用的开源git代码管理工具之一,随着发展推出了ci/cd解决方案,顾名思义具体来说ci/cd主要完成以下两个工作:  ci(持续构建):代码提交后触发自动化的单元测试,代码预编译,构建镜像,上传镜像等 ...
  • docker与CI/CD

    千次阅读 2018-07-18 19:38:29
    1. 什么是CI/CD 持续集成 持续集成是指软件个人研发的部分向软件整体部分交付,频繁进行集成以便更快地发现其中的错误。“持续集成”源自于极限编程(XP),是 XP 最初的 12 种实践之一。   CI 需要具备这些: ...
  • gitlab CI/CD环境搭建

    千次阅读 2018-09-05 15:23:05
    他会提示你写gitlab的地址和token,这地址可以在gitlab的网页上的settings->CI/CD Pipelines 找到如图: 另外,配置好的runner可能需要开启-Run untagged jobs,同样在上图所示的页面中有一个Runners ...
  • 在GitLab CI / CD上使用SSH密钥

    千次阅读 2020-07-31 10:13:01
    亚搏体育app CI / CD 在GitLab CI / CD上使用SSH密钥 在GitLab CI / CD上使用SSH密钥 上次更新时间:2017-12-13• Using SSH keys with GitLab CI/CD GitLab当前不支持在构建环境(运行GitLab Runner的环境...
  • 文章目录1. Gitee Go 介绍2. 开通Gitee Go3. 提交一个vue项目到gitee...Gitee Go 是 Gitee 推出的 CI/CD 服务,通过自定义构建流程,可以实现从代码仓库到构建部署自动化。目前已支持 Maven、Gradle、npm、Python、Ant
  • GitLab 项目配置 CI/CD 自动化部署

    千次阅读 2020-08-28 17:37:44
    通过 Gitlab 实现 CI/CD 自动化部署有多种方式,本文只针对使用 shell 这一种方式进行实际操作说明,其他方式可自行查阅文档。 本文实现的 shell 方式,其自动化部署的核心是通过 rsync 命令进行文件同步。 前置条件...
  • 推荐一些顶级的开源CI/CD工具

    万次阅读 2019-01-01 10:03:22
    CI/CD 实践对于基础设施、第三方应用程序和内部开发的应用程序同样适用。虽然有许多不同的工具可以实践 CI/CD,但这些工具都使用类似的模型。最重要的也许是,引导公司采取这种新的做法会让你在公司里处于一个强有力...
  • GitLab CI/CD 视频教程 + 文字教程,从入门到精通。

    千次阅读 多人点赞 2021-05-22 22:01:40
    之前我在CSDN直播了GitLab CI/CD 入门及实践,收到了很多小伙伴的私信和赞誉,于是我开始了坚持在B站分享有关GitLab CI/CD的视频。以下是内容目录传送路。 GitLab CI/CD系列教程(一):Docker安装GitLab GitLab CI/...
  • 什么是CI/CD

    千次阅读 2019-08-25 19:45:49
    自动实现如下图:打包后直接进入服务器,没有容器情况下,脚本和配置文件会越来越多,很乱。 容器化后:打包后进入镜像仓库HARBOR, ...
  • CI/CD 自动部署落地方案分享

    千次阅读 2019-03-11 17:35:23
    CI/CD 自动化部署 {username}/dev testing release master - 开发(集成)服务器 测试服务器 线上A/B服务器 阶段1: {username}/dev => testing 代码格式检查 执行测试用例...
  • 推荐 10 个好用的 CI/CD 工具

    千次阅读 2019-03-11 13:58:16
    实际上,所有开发者都可在软件开发中使用 CI/CD,但团队使用可以获得更大优势,尤其是大型团队,因为他们通常在处理相同的互锁代码块。持续集成最全面的实现是在测试之前构建代码,寻找未被发现的错误和不兼...
  • GitLab在Kubernetes上的CI/CD

    千次阅读 2018-12-19 15:17:25
    GitLab在Kubernetes上的CI/CD 文章目录GitLab在Kubernetes上的CI/CD1. Gitlab在Kubernetes中CI/CD流程2. 环境3. Kubernetes安装4. GitLab安装5. Auto DevOps5.1 添加Kubernetes集群5.2 一个demo6. 小结 1. Gitlab在...
  • CI/CD 流程以及原理说明

    千次阅读 2019-10-21 23:30:58
    自动化部署 CI/CD 是一种通过在应用开发阶段引入自动化来频繁向客户交付应用的方法。CI/CD 的核心概念是持续集成、持续交付和持续部署。作为一个面向开发和运营团队的解决方案,CI/CD 主要针对在集成新代码时所引发...
  • Gitlab配置Gitlab-Runner实现简单的CI/CD

    千次阅读 2019-08-11 14:26:18
    文章目录Gitlab配置Gitlab-Runner实现简单的CI/CD配置说明GitlabGitlab Runner安装Gitlab-Runner注册Runner到Gitlab简单测试 Gitlab配置Gitlab-Runner实现简单的CI/CD 配置说明 Gitlab 系统:Ubuntu 16.04 Server ...
  • 敏捷开发、持续集成/交付(CI/CD)、DevOps学习笔记

    万次阅读 多人点赞 2018-08-09 22:56:16
    CI/CD是实现这两者理念的一种方法。 敏捷开发 前言 传统方式开发前有一份详细的开发文档,程序员照着需求直接敲代码,产品做好了直接部署上线。中间不会有人打扰,需求也不会变。 但是目前的情况是,用户需求...
  • GitLab CI/CD工作原理及使用

    万次阅读 2018-09-12 15:52:11
    持续集成(Continuous Integration) 持续集成指的是频繁的将代码集成到主干,每次集成都通过自动化的构建(包括编译、发布、自动化测试)来验证,它的好处主要有两个: ...GitLab CI/CD 从8.0版开...
  • 6、安装gitlab-runner实现CI/CD自动化 创建runner文件并在其内创建文件叫: docker-compose.yml version: '3.1' services: gitlab-runner: build: environment restart: always container_name: gitlab-...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 520,501
精华内容 208,200
关键字:

ci/cd