CODING CD 主机组部署实践

主机组部署,即在原生 Linux 系统上,进行应用的部署。它是早期软件开发里常见、常用的部署方式,但随着 Docker、Kubernetes 的兴起,针对此类部署方式的支持也愈加稀少。因此一套整合了代码、制品、部署的整套流程更是屈指可数。如今 CODING CD 推出的主机组部署功能,正好能够弥补上这个缺口,让这种看似“原始”的方式也能加入进 DevOps 环中。本文将以一个简单实例的方式,来介绍 CODING CD 主机组部署的使用场景与流程。

概念与原理

使用主机部署前,需要简单了解 3 个与其相关的基本概念,会让您对后续的流程有一个更加深刻的理解。

agent

一个由 CODING 开发的二进制程序包,名称为 cloud-agent,它是作为 CODING CD 与您想要管理的主机之间的沟通桥梁。

cloud-agent 默认以后台进程启动,启动时会主动与 CODING CD 建立长连接,并通过长连接来接收 CODING CD 的指令,如部署。接收到指令后,通过 SSH 到相应的主机上去,做相应的处理。

目前 cloud-agent 只支持 Linux(macOS 也支持,但未提供该版本的二进制下载链接)。

堡垒机

运行 agent 的机器。当您在某一台机器上运行 agent 时,该机器便变成了堡垒机。

对堡垒机的要求总结来说一句话:既能“攘外”,又能“安内”。外便是 CODING,内便是您的主机。即如下两点:

  1. 能够访问外网,以便连接上 CODING 服务。
  2. 能够使用 SSH 免密登录您想管理的主机组

主机组

堡垒机能够访问的主机。从另外一个角度说,主机组也是 CODING CD 能够“掌控”的主机。同时,主机组也是您真正部署服务的机器。因此,您所部署的服务的依赖,需要先在主机组上解决。

对主机组的要求只有一点:开启 SSH 服务,并能够被堡垒机免密访问

适用场景

总体思想:CODING CD 借助 agent 实现部署,不对您的主机及主机构成的网络构成侵入。使用的场景以及工作原理,如下所示:

场景主要分为两种,一种是在公网的主机组,另一种是在私有网络的主机组。在本文中,将采用第二种,基于私有网络的主机组部署。

DEMO 简介

主要包含 DEMO 的基本介绍,详细的介绍请 clone 该 DEMO 项目到本地进行体验。

项目信息

  • service-one (端口:9001)
  • /health :健康检查用
  • /service-1/hola:hello-world 请求
  • service-two (端口:9002)
  • /health :健康检查用
  • /service-2/hello:hello-world 请求
  • service-three (端口:9003)
  • /health :健康检查用
  • /service-3/hi:hello-world 请求

主机组信息

拥有 4 台本地机器,一台作为 AGENT,一台作为主机 1,一台作为主机 2,一台用作请求转发。

堡垒机 主机 1 主机 2 负载均衡
IP 172.16.73.4 172.16.73.2 172.16.73.3 172.16.73.1
PORT 22 22 80
登录用户 agent user-for-deploy user-for-deploy
系统 Ubuntu 20.10 Ubuntu 20.10 Ubuntu 20.10

负载均衡配置

整体部署规划如下:

  • service-one 只部署到主机 1
  • service-two 只部署到主机 2
  • service-three 部署到主机 1 和主机 2

负载均衡配置如下:

worker_processes  1;
events {
    worker_connections  1024;
}
http {
    upstream service-one {
        server 172.16.73.2:9001;
    }
    upstream service-two {
        server 172.16.73.3:9002;
    }
    upstream service-three {
        server 172.16.73.2:9003;
        server 172.16.73.3:9003;
    }
    server {
        listen       80;
        server_name  172.16.73.1;
        location /service-1 {
            proxy_pass http://service-one;
        }
        location /service-2 {
            proxy_pass http://service-two;
        }
        location /service-3 {
            proxy_pass http://service-three;
        }
    }
}

修改 nginx 配置文件后,启动 nginx 或重新载入配置。

准备工作

堡垒机 上,将公钥拷贝到主机 1、主机 2 上,实现免密登录。

ssh-copy-id user-for-deploy@172.16.73.2
ssh-copy-id user-for-deploy@172.16.73.3

打开 功能设置-持续部署-堡垒机界面,点击添加堡垒机,拷贝初始化脚本,登录到 agent 上,粘贴运行,如下:

agent 运行成功后,可以回到添加堡垒机页面,看到刚刚添加的 agent,如下:

添加完堡垒机后,接下来添加主机组。我们可以由一个堡垒机,创建出多个主机组,此时,每个主机组的引申含义便是单个服务的集合,即服务组。例如,您的项目中有三个服务,三个服务的部署情况分别为:

  • 服务 1:只部署主机 1
  • 服务 2:只部署主机 2
  • 服务 3:同时部署主机 1主机 2

此时,我们可以创建 3 个主机组,分别对应于上面的三个服务。如下:

至此,准备工作完毕。

CI 配置

在项目页面,点击制品库,创建名为 jar-repo ,用来存放 jar 包的 generic 制品库。

在持续集成中,点击创建流水线,选择自定义构建过程模板,然后选择使用 DEMO 项目中的 Jenkinsfile。这这个过程中,您可能需要对流水线做一些细微的调整,具体用法可参考我们持续集成的配置文档。

运行 CI 后,制品库中应该有 3 个 jar 包,后续是通过制品库的制品更新触发 CD。接下来进入 CD 的配置。

CD 配置

打开部署控制台,新建应用 host_server_deploy_demo,勾选 主机组部署 选项。创建应用成功后,进入该应用。我们在此选择通过 CODING Generic 制品库来触发 CD 流水线,因此每个制品对应一次服务部署,也就是说每个制品,创建一个部署流水线。

由于三个服务在配置上的相似性,在此,我们以 ServiceOne 为例,其他两个服务,可参考 ServiceOne 的配置。

  1. 选择新建流水线 ,点击空白流程,输入名称 DeployServiceOne,如下:

  1. 点击创建,成功创建流水线后,进入流水线的配置界面。选择流水线部署服务时所需的制品,即:
  • service-one-latest.jar

在选择匹配规则完成后,记得勾选上使用默认制品,并将该制品的别名改成您能识别的,例如:ONE。然后点击保存。过程如下:

在本文中,后续两个流水线中所需制品的别名,将分别命名为 TWO、THREE。

  1. 在保存好制品后,再创建 CODING Generic 制品库触发器,这样每次制品版本更新都能触发此流水线,也就是说,每次更新服务后,通过 CI 构建好服务的 jar 包,上传到 CODING Generic 制品库即可触发 CD 流程。

  1. 接着,添加 部署(主机组)阶段,阶段名称改为 Deploy Service One 。选择所需要部署的服务组,即选择此次部署行为的目标机群。按照我们开始的规划,这里的:
  • 主机组选择服务 1

  • 服务名称为 ServiceOne

  • 策略选普通部署

  • 前置脚本做一些部署的准备工作,如干掉之前在跑的程序,如下:

    PID=`ps -ef | grep java | grep one.jar | awk '{print $2}'`
    if [  "$PID" = "" ]; then
      echo "not running"
    else
      echo "the service is RUNNING and it will be killed by agent"
      kill -9 $PID
    fi
  • 制品选择前面配置的 ONE,为 service-one-latest.jar 的别名,复制到主机上的 ~/one.jar

  • 后置脚本用来启动 java 程序,如下:

     java -jar ~/one.jar > /dev/null 2>&1 &
  • 启用健康探针,选择 HTTP 探针,请求路径填写 DEMO 中的 /health 的 URL,如下:

注意事项:

  • 脚本内容(包括前置脚本后置脚本不应该包括阻塞命令,比如说开启 Java Web 服务。这样会堵塞脚本的执行,导致部署流程卡住,进而导致部署失败。对堵塞命令有如下两个建议才不会导致部署流程卡住:

  • 后台运行

  • 重定向标准输出与标准错误

    即对堵塞的服务,用类似 cmd >/dev/null 2>&1 & 的命令来启动。

  • 如果开启了健康探针,主机中需要安装 curl 命令。

  1. 在配置完 service-one 之后,接着配置 service-two 与 service-three。与 service-one 类似,都需要重复上面的操作。要注意修改相应的参数,新增完成后,将得到 3 个流水线,如下所示:

部署效果

为了触发 CD,手动触发 CI 或者修改 DEMO 代码,并推送到代码仓库中,成功触发 CD 后,在 部署控制台 我们能看到部署流程的状态,以及集群中我们服务组的状态,如下:

部署控制台状态

依次访问 DEMO 中的服务,可以看到部署成功后的效果如下:

部署效果

其中,service-three 由于有两个服务,可以看到实际提供服务的 ip 的变化,而其他两个服务则没有 ip 的变化。

滚动部署

所谓滚动部署,即当服务的部署对象有多个时,不是一次性部署完,而是分批次部署。因此,我们能清楚地看见服务在各个实例上的发布过程。CODING CD 的主机组部署中也实现了这种能力。

我们打开 Deploy Service Three因为此服务需要部署到 2 个主机上)的配置,找到部署策略,选择滚动部署。在此,我们选择每次部署数量为 1,每部署完一个批次后,等待 60s 之后,再进行下个批次的部署。如下:

注意:如果在上图的 运行部署流程 中选择了 A 应用B 流程,那么运行周期将变成:

  1. B 流水线
  2. Deploy Service Three
  3. 等待 60s
  4. B 流水线
  5. Deploy Service Three
  6. 等待 60s
  7. B 流水线

从上面 7 个步骤中可以看出,每一个批次都会被两个 B 流水线 包裹。如下图所示:

勾选运行部署流程效果

因此,是否选择 运行部署流程 须根据您的实际需求来决定。目前此项功能可用来调整负载均衡配置

保存流水线后,修改 service-three 的代码,即在 hi 接口中,添加前缀 Edited:,如下:

代码修改

推送到 CODING 代码仓库,接着触发 CI、CD,最终我们来到 service-three 的滚动部署,当部署完第一批后:

部署完第一批

我们可以肉眼观察到部署的整个流程,如下:

滚动部署中

在等待 60s 后,两批全部部署完成

部署完成

部署操作完成后,服务的效果可以看出,两个实例都已更新完毕

更新完后的效果

结语

至此,本文所介绍的 CODING CD 主机部署,已经完毕,如果还有疑问或建议,欢迎前来交流探讨!

上一篇基于腾讯云弹性伸缩(AS)的持续部署
最近更新
感谢反馈有用
感谢反馈没用

在阅读中是否遇到以下问题?

您希望我们如何改进?