小企业网站 优帮云,网站的设计与制作,景区网站建设方案,wordpress 工作流目录 一、概述 二、持续集成的典型操作流程 2.1 概述 2.2 持续集成的操作流程图 2.3 持续集成关键流程说明 三、构建持续集成流水线的方式 3.1 依托云厂商能力 3.2 采用开源产品 3.3 企业自研 四、构建持续化集成流水线 4.1 基于GitHub的持续集成流水线#xff08;公…目录 一、概述 二、持续集成的典型操作流程 2.1 概述 2.2 持续集成的操作流程图 2.3 持续集成关键流程说明 三、构建持续集成流水线的方式 3.1 依托云厂商能力 3.2 采用开源产品 3.3 企业自研 四、构建持续化集成流水线 4.1 基于GitHub的持续集成流水线公有云方案 4.1.1 概述 4.1.2 GitHub持续集成方案操作流程示意图 4.1.3 GitHub Actions持续集成技术实现原理 4.1.3.1 GitHub Actions工作流程构成关系图 4.1.3.2 GitHub Actions工作流程 4.1.3.2.1 新建Actions 4.1.3.2.2 自定义工作流程 4.1.3.2.3 选择快捷模板 4.1.3.2.4 进入配置页面 4.1.3.3 举例配置Node.js YAML文件 4.1.3.4 总结 4.2 基于Jenkins/GitLab CI的持续集成流水线私有云 4.2.1 概述 4.2.2 Jenkins持续集成方案操作流程示意图 4.2.3 JenkinsGitLab持续集成技术实现原理 4.2.3.1 说明 4.2.3.2 安装GitLab 4.2.3.3 安装Jenkins 4.2.3.4 GitLab配置访问令牌 4.2.3.5 Jenkins配置 一、概述 介绍完了持续集成基本概念和包含的主要系统接下来将从平台建设和技术实现的角度为大家详细讲述其典型流程下的技术细节。 二、持续集成的典型操作流程 2.1 概述 持续集成流程在DevSecOps平台中主要表现为持续集成流水线在实际的平台建设中这一段流程的线上化过程通常是分阶段、分步骤实现的。大多数情况下首先实现的是代码管理到集成测试这一段的线上化然后再通过安全左移逐步完成整个持续集成到持续开发的线上化。 2.2 持续集成的操作流程图 当整个流程完成线上化之后在DevSecOps平台中编排调度系统是持续集成平台能力的核心承担着流程调度、任务管理和面向用户交互的职责。基于日常的研发操作和上文中提及的持续集成流程中涉及的主要系统其典型操作流程如下图所示 2.3 持续集成关键流程说明 其关键流程如下 当开发人员完成开发后提交代码至代码存储仓库。触发源码及版本控制系统事件HOOK发起代码编译构建动作。编译构建系统拉取源代码开始代码编译。依次执行代码编译、制品打包、静态检测。当上述步骤执行通过后通过调度将制品上传至过程制品库。生成的过程制品将被部署在资源及环境管理系统准备好的研测环境上。制品部署完成后进入测试阶段依次完成集成测试、安全测试、回归测试。当测试阶段动作全部完成后将验证后的制品上传可发布制品库供生产环境发布使用。 在整个过程中各个任务在流水线上依次递进直至将代码转化为可交付的制品这就是DevSecOps平台中持续集成流程的核心作用。 三、构建持续集成流水线的方式 当一家企业着手搭建持续集成流水线时通常可以使用如下三种不同的方式去构建此能力 3.1 依托云厂商能力 依托云厂商能力即利用云厂商SaaS化持续集成相关系统或服务构建企业自身的持续集成流水线。 3.2 采用开源产品 采用开源产品即企业通过整合开源的持续集成相关产品构建本地化的持续集成流水线。 3.3 企业自研 企业自研即企业通过独立研发持续集成相关产品构建本地化的持续集成流水线。 上述三种平台能力构建方式中企业自研的方式更适用于大型互联网企业的大规模并发的持续集成场景当然需要的资源投入和实施周期也不一样。考虑本书内容的普及性和实用性这里主要以前两种方式为例向读者介绍持续集成流水线平台能力的搭建。 四、构建持续化集成流水线 4.1 基于GitHub的持续集成流水线公有云方案 4.1.1 概述 基于GitHub的持续集成流水线适合中小型互联网企业或者说使用公有云基础设施及源代码云托管服务的企业。这类企业有一个典型的特点是代码管理托管在云服务上这里主要是指GitHub企业大多数没有自己的数据中心采购云厂商的云主机、云数据库、云存储等作为企业的基础设施如研测环境和生产环境均在公有云上。 4.1.2 GitHub持续集成方案操作流程示意图 GitHub Actions是GitHub平台上的一个功能模块在代码托管的基础上可以承担持续集成流水线的功能用户通过GitHub Actions对软件开发流程的定义自动化地帮助用户完成代码检出、编译构建、代码检测、依赖管理、测试、部署等操作。当基础设施使用公有云时在此持续集成方案的基础上可以快速方便地完成持续部署的自动化。此方案的操作流程概览图如下图所示 从图中可以看出当使用GitHub作为持续集成流水线控制时GitHub Actions担当着总体流程调度的角色当触发工作流程的事件后流程启动开始执行。 4.1.3 GitHub Actions持续集成技术实现原理 4.1.3.1 GitHub Actions工作流程构成关系图 使用GitHub Actions来实现持续集成时工作流程是通过在GitHub上定义的YAML文件来描述的。YAML文件一般存放在.github/workflows目录中一个项目可以定义多个YAML文件一个YAML文件定义一个流程(Workflows)流程由事件(Event)触发作为入口。一个流程包含多个不同的任务(Job)每一个任务由一个或多个步骤(Step)组成每一个步骤可以执行一个或多个操作(Actions)。Workflows-Job-Step-Actions它们组装在一起构成整个工作流程如图所示 配置完成的工作流程可以通过手工操作、GitHub CLI、API接口等方式触发流程启动事件。事情启动后会依次执行每一个任务直至流程结束。如果流程执行失败GitHub Actions也会起到监控和调度的作用。 4.1.3.2 GitHub Actions工作流程 4.1.3.2.1 新建Actions 当用户代码托管在GitHub后可以在项目中的Code标签页直接新建Actions如图所示: 4.1.3.2.2 自定义工作流程 进入页面后单击New workflow的按钮开始定义工作流程。默认情况下当前页面提供了一系列的工作流程模板如推荐的模板列表、持续集成的模板列表、安全检测的模板列表等。同时用户也可以自定义自己的工作流程。 在上图中 ❶所示位置为用户自定义工作流程入口 ❷所示位置为系统推荐的工作流程模板入口。 4.1.3.2.3 选择快捷模板 当然用户还可以选择其他的工作流程的快捷模板如下图所示 4.1.3.2.4 进入配置页面 这里选择GitHub Actions工作流程后则进入YAML文件的配置页面如下图所示 在上图中 ❶所示区域为YAML文件的自定义配置编辑区 ❷所示区域为GitHub根据应用市场的使用情况推荐给用户的操作模板和说明文档。用户参考操作模板和说明文档完成YAML文件的自定义编辑之后修改❸的文件名最后单击❹Start commit按钮提交YAML文件提交后在代码项目“根目录/.github/workflows”下会存在刚才提交的YAML文件。 至此工作流程的定义已完成。当代码仓库发生变化时如果发现“根目录/. github/workflows”下存在yml文件将根据流程触发条件启动流程。 4.1.3.3 举例配置Node.js YAML文件 在整个工作流程中的定义中YAML文件的配置是流程定义关键。下面以一个Node.js项目为例介绍持续集成配置其文件样例如下图所示 在上图中文件主要包含三个部分 ❶表示整个流程的名称 ❷表示流程的触发条件为事件push ❸表示要执行的任务内容。 其中 ❹表示使用代码的主分支master ❺表示任务主要是编译构建与测试 ❻表示编译构建和测试的使用环境为Ubuntu操作系统 ❼表示当前Job任务所包含的步骤 ❽~11均为其操作步骤 ❽表示代码Checkout操作 ❾表示命令行环境下依赖环境的安装、构建和测试操作 10表示对dist目录下的文件排除txt类型之后生成的制品上传 11表示上传自动化测试报告。 这是一个简单的Node.js项目持续集成样例在实际使用中开发语言不同使用场景不同流程的定义往往要复杂得多。但通过这个样例读者能概要性地了解GitHub Actions实现持续集成流程的基本逻辑。 4.1.3.4 总结 对于GitHub Actions的使用GitHub官方文档中有比较详细的描述感兴趣的读者可以详细阅读其案例并动手操作理解不同场景下的持续集成流程的定义和使用。 例如GitHub上Action的代码仓库包含各种流程定义模板感兴趣的读者可以访问地址 GitHub - actions/starter-workflows: Accelerating new GitHub Actions workflows 同时在GitHub的应用市场上也有非常多的使用案例这些案例既包含持续集成能力也包含安全能力如下图所示 既包含GitHub自身功能也包含其他厂商的SaaS化能力如亚马逊AWS、阿里云、RedHat等如下图所示。 这些与GitHub可集成的能力对于使用GitHub实现持续集成流水线的企业来说无疑是极大地缩短了DevSecOps能力构建的周期降低了平台学习和平台使用的成本。 4.2 基于Jenkins/GitLab CI的持续集成流水线私有云 4.2.1 概述 基于Jenkins或GitLab CI去构建企业级持续集成流水线是业界非常普遍的方案这与它们本身的开源、易于操作满足常见持续集成场景下各个任务的调度需求有关同时也与周边生态系统的成熟与版本管理工具、版本控制工具、构建工具等易于集成也有很大的关系。用户通过使用此类方案可以方便、一揽子地解决多个业务操作和系统数据之间的打通与联动。 除了少数大规模、高并发的大型互联网企业需要自己去研发流程调度系统外在使用已有的开源产品或商业产品来构建持续集成能力时Jenkins通常是企业的首选方案。 4.2.2 Jenkins持续集成方案操作流程示意图 Jenkins是基于Java语言的企业级持续集成工具可以持续、自动化、分布式完成持续集成流程中的多个任务如构建、测试、监控等。以Jenkins为流程调度的持续集成流水线其概览图如下图所示 从此方案中可以看到图中编译、打包、镜像构建、上传镜像、删除镜像等操作都是在Jenkins统一调度下完成的Jenkins通过API接口、脚本、应用等调用完成持续集成流程中的关键任务。它与基于GitHub持续集成方案的不同在于此方案中代码托管在本地环境管理工具使用的是Git和GitLabJenkins、Docker仓库、测试环境等也都是企业自己搭建的整个平台具有很好的自主性和可定制性。 4.2.3 JenkinsGitLab持续集成技术实现原理 4.2.3.1 说明 接下来将以JenkinsGitLab相结合的方案介绍持续集成能力的实现。JenkinsGitLab的安装市面上有很多文字资料和视频这里仅做简要地介绍通过简化安装让读者了解其系统构成即可。 4.2.3.2 安装GitLab GitLab是业界使用比较广泛的一款覆盖DevSecOps全流程的软件它分为GitLab CE和GitLab EE两个版本其中GitLab CE为社区的开源版本GitLab EE为企业级版本企业版有一定时间的免费试用期。这里以GitLab CE版本为例讲述GitLab的安装。GitLab安装有多种安装方式常见的有使用已下载安装包安装、在线安装如Linux环境下rpm包安装yum在线安装、Docker安装等。使用yum安装时需要注意的是安装时需要考虑到网络速度的传输。建议选择安装源时首选考虑国内的安装镜像源如清华大学开源软件镜像源、科大镜像源、华为镜像源等如下图所示 本文为了简化GitLab的安装操作方便读者快速使用和了解GitLab使用Docker化安装方式。Docker安装首先要下载GitLab如下命令行所示 待此命令执行完成后即可启动GitLab如下命令行所示 等待一段时间当所有的容器状态正常时即可以通过gitlab.devsecops-demo.com访问GitLab。如果通过域名无法访问读者需要配置IP解析。首次使用时需要配置GitLab管理员密码设置完密码后才可以管理员身份登录GitLab。 相比yum安装Docker的安装与配置要简单得多读者也可以使用其他方式安装来加深对GitLab的理解。另外对于英文不好的读者建议安装时选择中文版即选择镜像gitlab-ce-zh:latest即可其他步骤与英文版一致。 4.2.3.3 安装Jenkins Jenkins是Java语言开发的所以安装之前先查看本机是否已安装JDK如果没有安装则需要首先安装JDK。本文默认JDK已正确安装如果有读者不知道JDK如何安装请查阅相关资料。这里仍以Docker环境为例讲述Jenkins的安装过程。 在Docker命令行模式下执行以下命令 默认情况下使用latest镜像。待此命令执行完成后即可启动GitLab如下命令行所示 等命令行执行完成后即可通过jenkins.devsecops-demo.com访问页面。这里需要读者注意的是GitLab的Docker启动参数与Jenkins的启动参数在端口上要避免冲突并且和GitLab安装一样考虑jenkins.devsecops-demo.com与IP地址的解析。否则也是无法访问的。 首次访问Jenkins需要解锁管理员密码这时只需要进入Jenkins HOME目录查询密码复制输入即可如下图所示 解锁完成后即可登录进系统参考新手入门的指引创建用户、添加插件及执行相关配置。 4.2.3.4 GitLab配置访问令牌 GitLab配置访问令牌并通过令牌与Jenkins之间进行认证和授权。进入GitLab主界面进入一个代码仓库后选择【Setting】→【Access Tokens】填写Token namegitlab-jenkins-user-api-token并勾选【api】后生成令牌信息如下图所示 需要将该令牌信息复制下来并保存至安全的位置后续在Jenkins配置的时候还会使用到该令牌。 4.2.3.5 Jenkins配置 Jenkins主页选择【Manage Jenkins】→【Available】安装Jenkins GitLab Plugin插件如下图所示 选择【Credentials】→【System】→【Global Credentials】→【Add Credentials】填写GitLab用户令牌如下图所示 最后选择【Manage Jenkins】→【Configure System】选择【GitLab】标签填入GitLab相关配置如下图所示 通过以上四个步骤已经完成了GitLab与Jenkins的集成。接下来就可以在Jenkins中创建任务进行构建。 好了本次内容就分享到这欢迎大家关注《DevSecOps》专栏后续会继续输出相关内容文章。如果有帮助到大家欢迎大家点赞关注收藏有疑问也欢迎大家评论留言