Jenkins实现一键编译部署到Docker

Posted 2021-04-07 属于我们的PMO

第1章      引言

1.1 编写目的

编写此文档有几个目的：第一，简单介绍Jenkins的相关知识，让大家对Jenkins有大概的了解；第二，将调用Jenkins的使用方式、业务情景整理供大家查看；第三，介绍自动化编译部署任务的创建思想流程；第四，简单介绍docker的镜像优化；第五，便于开发人员和测试人员使用和改进。

1)        收集开发、测试在编译-打包-上传-备份-镜像-部署过程中的问题；

2)        供后续的开发测试人员熟悉业务，为以后的自动化部署做准备。

1.2 阅读对象

本需求规格说明书的主要阅读参考对象为：

1)        项目设计人员

2)        开发人员、测试人员

1.3 术语定义

本需求规格说明书的主要阅读参考对象为：

 

缩写、术语	解 释
Jenkins	个开源软件项目，是基于Java开发的一种持续集成工具，用于监控持续重复的工作，旨在提供一个开放易用的软件平台，使软件的持续集成变成可能
Docker	一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的容器中，然后发布到任何流行的 Linux 机器上，也可以实现虚拟化
Python3	为了统一优化，重构后的自动化编译部署都使用了python3来编写脚本。
中心	整个大项目分为很多模块，这些模块又叫中心；    现有中心为：01.boss_frm/02.boss_web/03.boss­_common/04.boss_client_comframe/10.boss_adm/11.boss_ord/12.boss_usr/14.boss_aaa/21.boss_task/22.boss_consume
主版本	开发人员在SVN上建立的项目版本，为主干版本，命名为trunk
分支版本	开发人员在SVN上建立的项目版本，为分支版本，命名为tags    一般用于对不同落地地区差异性的解决方案以及一些需求临时解决方法。现有分支为：ZhuJiang/HeBei
整包部署	将整个项目重新构建并部署。
补丁部署	将整个项目重新构建但只重新部署相应的补丁文件。
CSF构建	又名CSF中心构建。一切使用CSF来启动中心的项目。    现有中心中，除了02.boss_web都属于CSF中心
WEB构建	又名WEB中心构建。使用spring-boot框架。现有中心中，只有02.boss_web是WEB中心。
Jenkins任务	在Jenkins中，一切以任务（JOB）的形式来作为一个独立单位
Docker部署	将构建出来的包部署在docker容器中。

 

 

1.4 参考资料

Jenkins基本使用教程:
http://www.cnblogs.com/yangxia-test/p/4354328.html

Docker入门介绍：

http://dockone.io/article/101

Docker优化：

http://www.jianshu.com/p/ed3c04be6082

 

第2章      需求概述

2.1 需求背景

1、项目中使用Jenkins来构建

2、项目中使用docker来部署

3、在测试环境中，经常会需要发布补丁，以及不同分支版本，需要从构建到部署重新来一遍，每次人工重复操作费事费力，效率低下。

4、每次现场发包，需要整理合并这段时间内的sql，耗时又易出错。

 

2.2 任务目标

本任务的建设目标为中信国安项目从构建到部署实现一键化、参数化，减少人工干预，系统目标为：

1.       建立统一、稳定、高效、易扩展性的Jenkins任务。

2.       支持灵活参数化配置，使操作过程一键化。

3.       构建完成后有相关人员结果通知，以及结果验证。

4.       支持扩展改进，方便优化。

5.       DB变更文件合并（按类按时间排序合并）

 

第3章      业务场景

n   项目分为：主版本、分支版本；

n   项目构建部署分为：整包方式、补丁方式；

n   项目构建类型分为：CSF中心构建、WE中心目构建；

n   任务完成后需要根据成功与失败，对不同的人进行通知；

n   任务部署完成后需要对部署结果进行验证；

 

3.1 业务现状

    目前业务所包含任务如下：

u  主版本、CSF中心、整包构建、普通部署

   _01_zxga_zjsm

u  主版本、WEB中心、整包构建、普通部署

_02_zxga_zjsm_web

u  主版本、CSF中心、整包构建、docker部署

_03_ zxga_zjsm_docker

u  主版本、WEB中心、整包构建、docker部署

_04_zxga_zjsm_web_docker

u  分支版本、CSF中心、整包构建、docker部署

_05_ zxga_zjsm_tag

u  分支版本、WEB中心、整包构建、docker部署

_06_zxga_zjsm_web_tag

u  主版本/分支版本、CSF中心、补丁构建、docker部署

_07_zxga_zjsm_patch

u  主版本/分支版本、WEB中心、补丁构建、docker部署

_08_zxga_zjsm_web_patch

u  DB变更文件分类排序合并成4个文件

_80_zxga_zjsm_merge_db

u  重启docker应用（可选择是否重新打镜像）

_99_zxga_zjsm_restart

第4章      功能详解 

4.1 任务 _01_zxga_zjsm  

_01_zxga_zjsm项目是用来构建主版本的CSF中心，并发布到22服务器上。但不会自动部署。 

任务操作图如下： 

4.1.1    操作流程  

如上图中，先点击头部的zjsm分组（1），然后点击_01_zxga_zjsm任务（2），进入任务操作页面；当然也可以直接点击构建图标（3）直接进入构建页面。然后点击构建按钮即可。 

 

下图是任务页面： 

下图是构建页面： 

4.1.1    参数说明  

在构建页面，有参数选择，本任务的参数只有邮件收件人的选择，一般默认即可。 

4.1.1    日志查看  

变更记录是本次构建的最新代码变动； 

Console Output是构建日志输出（我们重点关注这个）； 

Parameters 是本次构建输入的参数； 

Environment Variables是本次构建的环境变量，上面Parameters也包含在里面。 

因此我们需要关注Console Output的内容，该任务的控制台输出内容分为三部分： 

1、第一部分是构建日志，构建失败，那任务肯定失败。 

2、第二部分是上传日志，当构建成功后，会将csf中心的包上传到应用服务器（22服务器）上。 

3、第三部分是邮件日志，无论构建成功还是失败，都会发送邮件到对应的人员。 

4.2 _02_zxga_zjsm_web 

4.2.1    操作流程 

_02_zxga_zjsm_web项目是用来构建主版本的WEB中心，并发布到22服务器上。但不会自动部署。（操作流程和4.1类似）。 

任务操作图如下： 

下面是构建页面： 

4.2.2    参数说明 

在构建页面，有参数选择，本任务的参数只有邮件收件人的选择，一般默认即可。 

4.2.3    日志查看 

4.3 _03_zxga-zjsm-docker 

4.3.1    操作流程  

_03_zxga_zjsm-docker项目是用来构建主版本的CSF中心，并发布到18服务器上。根据需要可以选择需要重新部署的中心。 

4.3.2    参数说明 

PROJECT-CENTER 是用来选择构建哪个中心的。 

但是，实际上，他影响的只是上传部署的中心！ 

首先：在编译的时候，会将所有CSF中心都编译出来。 

其次：在上传的时候，会将相应中心都上传到服务器。 

最后：在部署的时候，会根据所选的中心来部署。 

 

IS_DEPLOY 是用来控制是否部署的开关，如果勾上，那么在编译-上传后，会自动部署。 

 

4.3.3   日志查看  

日志分为部分： 

1、第一部分是构建日志，构建失败，那任务肯定失败。 

2、第二部分是上传日志，当构建成功后，会将csf中心的包上传到应用服务器（22服务器）上。 

3、第三部分是部署日志，当上传完成后，如果勾选了部署，那么会自动部署。部署流程为：先复制并覆盖到update目录，然后解压zip包，停止中心原有docker进程，构建镜像，启动中心 

4、第四部分是邮件日志，无论构建成功还是失败，都会发送邮件到对应的人员。 

 

4.4 _04_zxga-zjsm-web-docker 

4.4.1    操作流程 

_04_zxga-zjsm-web-docker项目是用来构建主版本的WEB中心，并发布到18服务器上（不自动部署，原先设定他是03任务的前置任务，可以加） 

4.4.2   参数说明 

现有模式中，该任务并不会自动部署。因为原本的设定是，该任务是03任务的前置任务，该任务完成后会触发03任务，让03任务去自动部署。不过现在应需求将触发器去掉了，如果有需要可以加上自动部署功能。 

4.4.3    日志查看  

4.5 _05_zxga-zjsm-tag 

4.5.1    操作流程 

_05_zxga_zjsm-tag项目是用来构建分支版本的CSF中心，并发布到18服务器上。根据需要可以选择需要重新部署的中心。 

4.5.2    参数说明 

这里需要选择分支的版本和子版本。 

 

SVN_TAGS       选择分支版本，该数据会自动从SVN从拉取。 

SVN_TAGS_SUB    输入分支子版本号，格式为formal_MMDD， 

例如formal_0712。不知道请查看邮件或者询问开发。 

4.5.3    日志查看 

可以根据部署成功后的输出查看是否部署正常。 

 

 

 

4.6    _06_zxga-zjsm-tag-web

4.6.1    操作流程 

_06_zxga_zjsm-tag-web项目是用来构建分支版本的WEB中心，并发布到18服务器上。根据需要可以选择需要重新部署。 

 

4.6.2    参数说明  

4.6.3    日志查看  

4.4 _07_zxga-zjsm-patch 

4.7.1    操作流程 

_07_zxga_zjsm-patch项目是用来构建主版本/分支版本的CSF中心的补丁，并发布到18服务器上。根据需要可以选择需要重新部署相应的中心。 

 

4.7.2    参数说明 

SVN_TYPE_PATH：输入构建补丁的项目版本号，可以在研发邮件中找到 

PATCH_LIST：需要构建的补丁目录，特别注意的是： 

补丁需要是同一个版本号，不然会出现解析问题；其次是会忽略web中心的补丁，因为这里只会编译CSF中心。 

 

4.7.3    日志查看 

4.8 _08_zxga-zjsm-patch-web 

4.8.1    操作流程 

_08_zxga_zjsm-patch-web项目是用来构建主版本/分支版本的WEB中心的补丁，并发布到18服务器上。根据需要可以选择是否需要重新部署。 

4.8.2    参数说明 

SVN_TYPE_PATH：输入构建补丁的项目版本号，可以在研发邮件中找到 

PATCH_LIST：需要构建的补丁目录，特别注意的是： 

补丁需要是同一个版本号，不然会出现解析问题；其次是会忽略CSF中心的补丁，因为这里只会编译WEB中心。 

 

4.8.3  日志查看 

4.9 _80_zxga-zjsm-patch-web 

4.9.1    操作流程 

4.9.2    参数说明 

START_DATE :       开始时间【格式如20170801】 

END_DATE:            结束时间【格式如20170808】 

脚本会根据这两个字段值，取两个时间段内的所有sql（包含这两个日期），并分类合并。 

 

4.10 _99_zxga-zjsm-patch-web 

4.10.1    操作流程 

  

4.10.2    参数说明 

第5章    Jenkins介绍 

5.1 Jenkins是什么 

Jenkins 是一个可扩展的持续集成引擎。 

 

主要用于： 

持续、自动地构建/测试软件项目。 

监控一些定时执行的任务。 

 

Jenkins拥有的特性包括： 

u  易于安装-只要把jenkins.war部署到servlet容器，不需要数据库支持。 

u  易于配置-所有配置都是通过其提供的web界面实现。 

u  集成RSS/E-mail通过RSS发布构建结果或当构建完成时通过e-mail通知。 

u  生成JUnit/TestNG测试报告。 

u  分布式构建支持Jenkins能够让多台计算机一起构建/测试。 

u  文件识别:Jenkins能够跟踪哪次构建生成哪些jar，哪次构建使用哪个版本的jar等。 

u  插件支持:支持扩展插件，你可以开发适合自己团队使用的工具。 

 

 

 

 

 

 

5.2 安装与启动 

Jenkins搭建有两种方式，一种是直接启动war；另一种是在tomcat等容器中启动。 

 

1、下载最新的版本（一个 WAR 文件）。Jenkins官方网址: http://Jenkins-ci.org/

 

方法一： 

2、命运行运行 java -jar jenkins.war　（默认情况下端口是8080，如果要使用其他端口启动，可以通过命令行“java –jar Jenkins.war --httpPort=80”的方式修改） 

方法二： 

打开后如下： 

  

5.3 全局配置 

5.3.1     配置JAVA/GRADLE/SVN/MAVEN 

5.3.2     配置SCP  

5.3.3     配置邮件（使用email-ext插件扩展的邮件功能）  

5.3.4   配置SSH  

5.4 自定义任务配置 

5.4.1    新建任务  

6.1.2     Docker组件与元素  

Docker有三个组件和三个基本元素，读者可以快速浏览下面这个视频来了解这些组建和元素，以及它们的关系。三个组件分别是： 

• Docker Client 是用户界面，它支持用户与Docker Daemon之间通信。 

• Docker Daemon运行于主机上，处理服务请求。 

• Docker Index是中央registry，支持拥有公有与私有访问权限的Docker容器镜像的备份。 

三个基本要素分别是： 

• Docker Containers负责应用程序的运行，包括操作系统、用户添加的文件以及元数据。 

• Docker Images是一个只读模板，用来运行Docker容器。 

• DockerFile是文件指令集，用来说明如何自动创建Docker镜像。 

  
  

在讨论Docker组件和基本要素如何交互之前，让我们来谈谈Docker的支柱。Docker使用以下操作系统的功能来提高容器技术效率： 

• Namespaces 充当隔离的第一级。确保一个容器中运行一个进程而且不能看到或影响容器外的其它进程。 

• Control Groups是LXC的重要组成部分，具有资源核算与限制的关键功能。 

• UnionFS（文件系统）作为容器的构建块。为了支持Docker的轻量级以及速度快的特性，它创建了用户层。 

 

 

 

6.1.3     如何把它们放在一起  

运行任何应用程序，都需要有两个基本步骤： 

1. 构建一个镜像。 

2. 运行容器。 

这些步骤都是从Docker Client的命令开始的。Docker Client使用的是Docker二进制文件。在基础层面上，Docker Client会告诉Docker Daemon需要创建的镜像以及需要在容器内运行的命令。当Daemon接收到创建镜像的信号后，会进行如下操作： 

第1步：构建镜像 

如前所述，Docker Image是一个构建容器的只读模板，它包含了容器启动所需的所有信息，包括运行程序和配置数据。
每个镜像都源于一个基本的镜像，然后根据Dockerfile中的指令创建模板。对于每个指令，在镜像上创建一个新的层面。

一旦镜像创建完成，就可以将它们推送到中央registry：Docker Index，以供他人使用。然而，Docker Index为镜像提供了两个级别的访问权限：公有访问和私有访问。你可以将镜像存储在私有仓库，Docker官网有私有仓库的套餐可以供你选择。总之，公有仓库是可搜索和可重复使用的，而私有仓库只能给那些拥有访问权限的成员使用。Docker Client可用于Docker Index内的镜像搜索。 

 

第2步：运行容器 

6.2 Docker搭建 

（请自行百度搭建）略。 

6.3 Docker构建镜像优化

6.3.1     从镜像获取角度

当需要在本地不同的宿主机中部署相同的镜像，如果分主机一个一个从dockerhub上下载是低效的，故采用了私人registry仓库部署，从而达到一次下载进行分配而无需多次下载

 

 

6.3.2     从复用镜像层角度（dockerfile角度）

方式：

• 改变语序以复用缓存

• 减少构建上下文大小

• 使用缓存代理

 

Docker是一层一层地生成容器镜像的。Dockerfile的每一行命令都创建新的一层，包含了这一行命令执行前后文件系统的变化。

 

为了优化这个过程，Docker使用了一种缓存机制：只要这一行命令不变，那么结果和上一次是一样的，直接使用上一次的结果即可。

 

为了充分利用层级缓存，我们必须要理解Dockerfile中的命令行是如何工作的，尤其是RUN，ADD和COPY这几个命令。

RUN命令

 

Run代表在容器中运行一个命令，语法如下：

 

RUN <command> <args>

 

RUN命令只有在其生成的层没被缓存时，才会执行。所以在build一个只包含RUN命令的Dockerfile时，只会真正build一次，下一次build，Docker会使用上一次的缓存。

 

当然，可以实现在下一次build时强制重新build：

 

    build时使用–no-cache标志，笔者看来这个办法最好不用，因为没有任何层缓存，build必然会慢很多；

    弄明白ADD和COPY是如何让层缓存失效的，下面将讨论这种方式：

    改变RUN命令行的形式，这里的问题和第1点一样，还需要一个build前的步骤，每次生产一个不同的Dockerfile；

 

ADD和COPY命令

 

ADD和COPY命令向正在构建的容器中引入了外部文件，语法如下：

 

COPY <external file(s)> <directory>

ADD <external archives(s) or URL(s)> <directory>

 

ADD和COPY命令总是会被执行，外部文件从archive或URL中获取，写入到硬盘上。一旦获取到文件，Docker会将它和上一次build时获取的文件比较。

 

    如果没变化，这个层缓存会被使用，直到下一个ADD或COPY命令之前，都使用上一次build的缓存。

    如果有变化，这个层缓存将失效，之后所有的命令行都会被执行；

 

显然加速容器build的方式就是：跳过那些执行时间很长的RUN命令，直接使用上一次build的结果。

Docker试图在Dockerfile中缓存所有步骤且不改变，但是如果改变一些语句，接下来所有的步骤将会重做。通过安排Dockerfile按照最小可能更容易改变的次序排序，可以在创建项目中节省不少时间。也就是将不变的放前面，将易变的放后面。

6.3.3     减少构建上下文大小(即使用dockerignore忽略一些文件)

在构建开始时，有Sending build context to Docker daemon这么一个过程。它是会将Dockerfile所在的目录以及子目录打包发送到Docker daemon。例如我们现在的测试环境，将所有中心都放在了一个目录下，那么每次都会讲这个文件夹发送过去，有1.6G。所以最好的做法是一个Dockerfile所在的文件夹里只有和镜像相关的，别的都去掉，或者用dockerignore来忽略

 

6.3.4     使用缓存代理（即使用依赖包代理工具有效减短编译指令所消耗的时间）

一个基于Debian的系统的Docker镜像从APT资源库中下载依赖包，编译镜像的过程中，apt-get install指令运行的时间长短取决于网络与所需要下载依赖包的大小。降低时间的技巧是引入这些依赖包的缓存代理：如apt-cacher-ng工具等等