使用腾讯云主机进行持续部署

在当今各种强调云原生的背景下,似乎云主机已经逐渐被大众所抛弃。但是事实真的是这样么?能用腾讯云的云主机玩出 k8s 的效果吗?比如,将服务数量根据业务的状态,进行随心所欲的伸缩。其实答案是可以的,在国外这种技术早已兴起,可以说蔚然成风,但在国内却不温不火。让我们今天,以一个技术人对新鲜事物的探索视角,来看看如果使用云主机来玩出新的花样。

我们经过大量实践,编写了此简易用例。在力求保证准确性的前提下,介绍它的快速使用方法,以致力于让您看到一个不一样的云主机,从而窥探技术的前沿。

通过阅读此文章,您将主要有如下收获:

  1. 如何使用云主机进行随心所欲的扩/缩容;
  2. 其中所用的工具、概念的分享与介绍。

效果展示

此处分两部分,简单的整体介绍与演示。

简介

初始时,所有的请求通过负载均衡器进行转发,且每个服务组拥有一个实例。

请求示例

扩容

结果为

可以看见,module01 服务组中的实例已经增加 1 个,等实例启动完成,即变成为

此时的请求如下,可以明显注意到,服务器的 hostname 已经变成了两个

缩容

缩容的结果,我们可以很清楚地从下面这张图中看到

以上便是扩/缩容部分的展示,除了上述显而易见的演示外,还有更多的功能隐藏在 CODING 持续部署中等待你的发掘。相信好奇心让你在内心深处产生了一个疑问:那么该如何下手?So, talk is cheap,show you the code!

动手实践

在动手实践开始之前,你所需的准备工作为:

  • 腾讯云账号(提供云服务;提供 CODING DevOps)。当然也可以在已有的 CODING 账号中,添加腾讯云账号,进行后续的实践。

  • 新建一个代码仓库,并克隆 DEMO 项目,该代码仓库中含有两个模块,即 module01 和 module02,这两个单独的服务,分别监听 9000、9001 这两个端口。另外该仓库中还包含后续所需要的 CI 配置文件,CD 配置文件。在开始前,先将此项目克隆到您的账号下。

  • 在【制品库】中新建一个名为 jar-repo 的 Generic 类型的仓库。

构建计划

在持续集成中,依次选择:【构建计划】->【+】-> 模板选【自定义构建过程】

配置来源勾选 使用代码库中的 Jenkinsfile,确认即可。

配置完手动触发一次构建计划,让制品库中有编译好的 jar 包。

持续部署

  1. 在部署设置中绑定腾讯云账号,名称为 tencent。

  2. 在 部署控制台 中新增应用,名称为 tencent-cvm,勾选支持 腾讯云服务器 部署,并将应用与项目进行关联。

  1. 新建一个负载均衡器,留作后面配置使用。如下图所示

  1. 创建一个部署流程 java-sample,选择 复制现有流程 - 空白模板 或 选择 腾讯云服务器 - 并行部署多个弹性伸缩组 模板,并按如下方式添加/配置阶段。

如果使用模板,请注意模板中生成的阶段与本文描述中阶段的对应关系,建议修改阶段名称,与本文保持一致。

此流水线中包含两个并行的 bake + deploy 操作。以 module01 为例,

  • BakeModule01 阶段的类型是 bake,主要用做烧录镜像,类似于 docker 中的构建自己的镜像,核心工作是往镜像中加入我们的服务;

  • DeployModule01 阶段的类型是 deploy,主要是将含有我们服务的镜像资源启动起来,类似于 docker 中的 docker run ,核心工作是启动。

持续部署详细配置

先看部署流程中的 配置,它主要定义一些流水线启动所需的制品,也就是我们烧录镜像所需要的 jar 包,以及流水线的触发方式。

启动所需制品

可粗浅理解为,当此部署流程开始时,能获取到 module01、module02 的 jar 的下载方式。

module01

注意勾选 使用默认制品,因为前面只是一个制品匹配规则,在匹配失败的时候,会使用默认的制品。

module02

还需再添加一个制品,步骤与上面的类似,但是为 module02。同样注意勾选 使用默认制品

自动触发器

点击添加触发器,类型选择 Webhook触发 ,如下:

拷贝该 Webhook 地址到前面构建计划中的触发持续部署中,以便于在构建计划中触发此流水线,如下:

bake

此处以 CentOS 系统 为例,若选择 Ubuntu 系统,请务必注意下面脚本是否兼容或适用。

先看 BakeModule01 的配置,如下图所示。此处有两处建议:

  • 镜像名称留空
  • 云服务器配置中,复用已存在的 VPC 和子网

上述建议的原因是由于当前腾讯云的上述资源存在数量上的限制,具体可参考腾讯云文档相关内容。

点开高级配置,

  • 预装软件-软件名称栏填入我们服务依赖的软件 java-1.8.0-openjdk-devel.x86_64,即 java。
  • 持久化文件处,选择 module01 制品,并填写好将该制品复制到镜像中的位置 /root/module_01-1.0-SNAPSHOT.jar
  • 运行脚本处,添加脚本,生成服务的自启动配置,如下:
echo '''#!bin/bash
java -jar /root/module_02-1.0-SNAPSHOT.jar 2>&1 > module_01.log &''' > /root/autostart.sh

chmod +x /root/autostart.sh

echo "begin to add systemd configuration..."

echo '''[Unit]
Description=TencentCVM Module 02
After=network.target

[Service]
Type=forking
ExecStart=/root/autostart.sh
User=root

[Install]
WantedBy=multi-user.target ''' > /usr/lib/systemd/system/tencentcvm.service

systemctl enable tencentcvm

对 BakeModule02 的配置,基本与 BakeModule01 类似,但是需要注意高级设置部分,要改为 module02 的 jar 包,包括脚本、持久化文件。为确保准确性,在此还是给出 module02 相关的 bake 高级配置信息,如下:

deploy

先看 DeployModule01 的配置,如下:

具体的各项设置为:

要注意安全组所定义的内容中,是否含有我们所需的业务端口,即 9000 和 9001,如果没有,那么后面部署会出现问题。

对 DeployModule02 的配置,它与 DeployModule01 的区别在于集群的名称、lb 的配置

其余均类似。

跑起来

至此,bake 和 deploy 的配置都已完成。让我们开始吧!

持续集成-构建计划 中,手动触发一次构建计划,让整个流程先跑起来,如下:

构建计划的执行结果

部署流程的执行结果

执行完后的集群信息

通过负载均衡器的访问结果

结语

我们还可以通过代码仓库来触发构建计划,即可通过代码提交的方式,来触发构建计划。这样我们就能做到了,在代码提交后,后面的部署完全自动化,并且部署成功后,可以随时调整服务的数量、或者设定检测条件,如 CPU 占用率达到 50% 便进行扩容。最后值得一提的是,部署应用时,新旧服务的交替,还有策略可供选择,如红/黑等。还有更多值得发现的功能,尽在 CODING DevOps,等你来发现!

上一篇使用 Serverless 实现动态准入控制
文档是否对您有用?
感谢反馈有用
感谢反馈没用