Jenkins的简单使用-Jenkins基于Gitee实现简单自动化部署-Jenkins实现docker部署

大家好，我是solly。

  最近使用了Jenkins自动化构建，将自己的学习心得分享出来。

  我在研究的过程中也是一步步遇到的问题，然后逐步的去解决这些问题。问题导向是我们学习中的一个重要的方法。

  我现在将这些问题抛出来，然后以我自己的方式挨个回答。（都是干货，拒绝AI式照本宣科，拒绝教材枯燥乏味）

Jenkins基于Gitee实现简单自动化部署

前言

  Jenkins的安装、部署、汉化我就不说了哈，这部分比较简单，简单搜搜AI都能解决。

  需要说明的是，如果在学习阶段，Jenkins尽量需要安装在外网能访问的机器上（如果没有考虑安全策略的话），能减少后期很多问题。

  Jenkins不能安装在应用服务器上。（能安装，但是不要这样装）

  原因请看第一个问题，Jenkins的架构。

 

 

一、Jenkins的架构是什么样的，如何实现构建部署的？

  在计算机世界中，我们学习一个新的东西，首先必须从架构开始，了解其运行原理。否则只是按命令和步骤机械式的操作，也是无意义的。

  Jenkins分为主节点和代理节点 ：

  主节点是控制中心，部署了Jenkins的主服务器；

  而代理节点是实际执行构建任务的节点，仅仅是执行构建任务，代理节点仅运行代理进程。

  可以把主节点比作导师，那么代理节点就是他的助手。这样做有利于构建与主服务分离，因为构建任务可能会耗费大量资源，构建有时也需要大量计算资源，可以横向扩展，并行构建等；另外，构建不会影响主服务崩溃。

1. 需要说明的是，主服务器默认自带一个代理节点。可以使用，但一般不建议使用。

   

2. 还有一个问题就是，代理节点和应用服务器的关系？

   首先，代理节点可以运行在应用服务器上，也可以运行在单独的机器上。二者没有特别大的联系，取决于项目实际的构建方案。

• • 如果代理节点运行在应用服务上。那么可以直接执行构建任务和运行任务。优点是：构建产物可以直接运行，无须其他操作，适用于简单构建项目。
  • 如果代理节点运行在单独的服务器上。那么构建任务需要执行构建任务，将构建产物上传到构建仓库，再指示应用服务器拉取构建产物，再运行构建产物。优点是：构建不影响生产中的应用；适用于规范的，大型的项目，适用于大厂。
  • 学习阶段一般直接将代理节点运行在应用服务器上，简单方便。

  3. 主节点、代理节点、代码托管平台这三者的网络访问是怎样的？

• • 不论内网外网，先总结下它们的访问原则：

访问者 被访问者	主节点	代理节点	代码托管平台
主节点	-	代理节点需要访问连接主节点	代码托管平台需要访问主节点，用于webhook触发器
代理节点	主节点不用访问代理节点	-	代码托管平台不用访问代理节点
代码托管平台	主节点一般不用访问代码托管平台（构建结果回发等情况需要用到）	代理节点需要访问代码托管平台，拉取代码	-

• • 下表总结了Jenkins内外网部署的相关情况（只考虑一般情况，实际上内外网还有很多通信策略）：

内外网	访问情况	说明
主节点部署在外网	完全访问	1. 代理节点运行需要访问主节点，与主节点通信 2. webhook触发器需要访问主节点，即代码仓库托管平台需要访问Jenkins 3. Jenkins也需要访问代码托管平台拉取代码。 优点：小项目，简单方便
主节点部署在内网	公共访问	基于上述要求，如果代理节点都部署在内网，代码托管也是在内网，那么需要保证代理节点和工作PC机能访问Jenkins，也要保证代码托管和Jenkins能互相通信，因为拉取代码和webhook触发器需要。 简而言之：如果Jenkins部署在内网，那么代理节点也需要在内网，代码托管平台可以在内网和外网，只是webhook能否使用的问题。 优点：大公司，安全要求高
主节点部署在内网	不能访问	无意义

• • 下表总结了三个服务在不同内外网的情况：

主节点部署情况	代理节点	代码托管平台	能否执行构建（代理节点运行、代码拉取）	能否使用webhook触发器（代码仓库变动触发构建）	构建结果回发到Git
外网	内网	内网	能	能	否
外网	内网	外网	能	能	能
外网	外网	内网	否	能	否
外网	外网	外网	能	能	能
内网	内网	内网	能	能	能
内网	内网	外网	能	否	能
内网	外网	内网	否	能	能
内网	外网	外网	否	否	能

• • 说了这么多，主要是想帮助用户理解Jenkins的架构关系。最好还是画一个架构图（我发现AI生成的架构图真的感人），我懒得画，我在网上找了一个比较贴切易懂的图：
•  
• 图片来源https://www.jianshu.com/p/8cc35b2ae083
• 基于学习的态度，这里只是最简单的部署架构，实际应用中可能还涉及镜像仓库、K8s集群等，不在本文讨论范围内。

  4. 如何运行代理节点？

  这个比较简单，网上搜索就能解决。

  首先进入节点管理菜单，然后点击新建节点

简单配置哈参数，主要是名称、描述（可选）、工作目录（必填），其余默认就行。

  然后进入节点状态菜单

  在机器上运行两行命令即可启动。

  代理进程最好配置为以服务的方式启动，这样可以设置自启动，也便于管理。如何将代理进程设置为服务，请参考我另一篇文章https://www.cnblogs.com/shoulisun/p/19240976

 

 

二、Jenkins如何配置Gitee通信？

• 为什么要配置gitee通信？这是为了加密通信，触发构建，将构建结果通知到Gitee。其他代码托管平台也是类似。
• 主要配置过程如下（参照下面截图）：
  • 在Jenkins中安装Gitee插件
  • 配置Gitee名称和链接地址
  • 配置私人令牌

• 代码拉取通信配置如下（参照下面截图）：
  • 配置仓库地址
  • 选择私人令牌 
  • 填写构建分支
  • 

  具体配置过程请参考https://help.gitee.com/devops/connect/Jenkins-Plugin

• 在项目配置中，可以直接选择将构建状态回发到Gitee

 

 

三、如何实现不停机发布？

  1. 蓝绿发布  

（因为现有条件和时间不值得我去研究和部署镜像仓库，所以我直接将我的代理节点部署在应用服务器上，构建运行一条龙）

  不停机发布有很多策略。最常用的是蓝绿发布。但是我没有搞成功，这里说下我的研究过程。

  蓝绿发布需要至少两个应用节点，然后使用Nginx反向代理将流量转发至其中一个节点。

  方案一：使用Nginx流量切换。这里面涉及主要有几个问题，蓝应用和绿应用使用两个不同的端口，如果端口固定，如何轮训？如果端口不固定，如何探测和使用？在绿应用启动后，如何健康检测（这里可能需要修改代码）？ 如何切换流量（Nginx需要修配置文件，脚本操作极为不便）？

  方案二：使用Docker内部网络的dns解析。在Docker内部给蓝绿容器分别命名别称，使用dns解析出内部IP地址，这样Nginx只用配置别名就行了，省去了修改Nginx配置文件。但是在实际实验中发现，dns有缓存，当应用容器重建时，Nginx容器解析出的IP地址是重建前的IP地址，无法访问。

  综上所述，我放弃了蓝绿发布。因为花费了太多时间，我也放弃了不停机发布。

  2. 新旧镜像和容器的替换、重建

  接下来我又研究了在Docker构建应用后，如何判断和删除旧容器，旧镜像。

  因为我们是基于PR的快速构建，所以不用区分构建的版本号，每一次构建都会新建相同名称的镜像，导致Docker会出现悬空镜像。

  再者，对于容器来说，新建容器时有相同名称的容器则不能新建，又要判断容器是否存在。

  这一系列的操作下来，我觉得脚本太复杂了，我不喜欢写那么复杂的脚本。我觉得脚本应该是干净清爽的，不应该夹杂很多的结果判断、循环等逻辑（因为调试优化很费时间费精力）。

  所以我感觉我又要放弃了。

  3. 使用Docker compose

  在我看不到希望的时候，我使用了Docker compose。这不是我第一次知道它。（它是Docker内置的多容器编排工具）

  我马上尝试了下，Docker compose会自动重新构建镜像，自动重建容器。很符合我的需求。虽然重建时会有短暂的停机时间，但是这已经够用了。

  所以我的最终构建脚本非常简单。一行docker compose 搞定。

sudo -E docker compose -f docker-compose.staging.yml up -d --build adminapi

 

 

四、如何实现机密参数注入？

  这个最简单了。

  构建脚本可以访问Jenkins提供的环境变量。包括构建前的一些元数据，项目名称、构建次数等等。具体参数可以参考：

  将机密参数添加到Jenkins的凭据中，然后在项目配置凭据注入。

  然后在脚本中可以直接使用${CONN_DB}获取环境变量，Windows脚本中使用%CONN_DB%

  特别注意：

  如果在脚本中使用了sudo执行命令，则需要在sudo后加上 -E 参数传递环境变量，这样docker-compose.yml配置文件中才能引用CONN_DB环境变量。

 

 

五、如何实现代码仓库变动时触发构建？

   Gitee设置触发器是通过webhook实现的，需要在两边配置。主要目的就是为了配置加密通信。

  Jenkins会暴露一个http的URL地址（前提是必须安装Gitee插件）， 然后Gitee仓库添加webhook后，可以配置指定的触发事件，比如代码变动，分支变动，PR变动等事件，Gitee会带上事件变动的详细信息请求该URL地址。

  Jenkins收到请求后根据设置过滤出符合条件的请求，然后执行构建。

  第一步，先在Jenkins项目配置中勾选Triggers下面的Gitee触发器

    勾选后，请记住webhook的URL，该URL需要填写到Gitee仓库配置的webhook中。

    然后选择需要触发的条件。这里我选择了接受PR和评论PR。

  往下翻，还需要配置Gitee webhook密码。

  这个密码是自动生成的，也可以点击生成重新生成密码。

  请记住这个密码，该密码需要填写到Gitee仓库设置中的webhook配置中。

  第二步，在Gitee仓库设置中Webhook菜单添加记录

 

   第三步，测试是否成功。

  

  第四步，如何排查触发器问题？

• 首先排查发送方（Gitee）是否发送？可以查看webhook请求历史，看看事件触发时是否发送成功。

• 其次排查Jenkins是否过滤了请求。可以把触发器勾选条件那里选项取消了试试。

  全文结束。

  如果本文对您有帮助，将是我对计算机行业的一个贡献！

  谢谢大家！