99元服务器搭建CI/CD系统方案

未分类 4小时前程序员胖胖胖虎阿

3 0 0

基于99元服务器搭建CI/CD系统的方案

故事起始是这样的：闲暇时分在阿里云购入一款年付99元的服务器，在上面部署了Git服务，用于托管自己闲暇时编写的代码，同时也将其当作开发服务器来使用。起初为了便于应用管理，借助docker来管理和部署应用，之后进行了一次升级，用上了docker - compose，毕竟相较于手动输入命令，声明式部署更为科学，docker - compose对于依赖项目的管理也让人颇为满意。就这样相安无事地过了许久，直到不久前在腾讯云上领到一台体验服务器，是免费的。既然是体验版，不用的话可称不上体验，思来想去觉得应该组建集群，顺便搭建一套CI/CD，如此一来不仅能大幅提升编码时的愉悦感，还能对K8s有更深入的认识。

K3S

K3s是一款轻量级且完全兼容Kubernetes的发行版本。它易于安装，所占用的内存仅为Kubernetes的一半，所有组件都包含在一个小于100 MB的二进制文件中（约70MB）。官方期望安装的Kubernetes能节省一半内存。Kubernetes是个10字母的单词，它只用了5个，所以叫K3s。K3s很轻便，适合安装在2核2GB的云服务器上用于学习把玩。虽然程序大概70MB，但实际上包含Server和Agent两个应用（如同Master - Slave模式）。不仅如此，K3s打包了所需的依赖，包括containerd、Flannel、Traefik、Service LB等。看上去还挺不错，但实际操作还是有一定门槛的，由于基础知识的欠缺，单单熟悉kubectl这个工具就花了两天时间。再加上Flannel、LoadBalancer等相关内容，服务器都重装了好几回。好在，所有问题都能找到解决办法，一路克服困难不断成长，总算把K3s运行起来了。

Harness（open source）

记得它以前叫Gitness，他们家有不少产品，比如Drone。现在发展壮大后，Gitness改名为Harness了，它资源消耗很小。Harness自带Pipeline功能，这也是我比较喜欢的方式，CI的配置直接存放在项目里。它的服务用go编写，界面用react开发，打包用webpack，或许是他们那里网络带宽比较充裕吧，它打包的时候没有打压缩包（像常见的gzip），服务上也没有做内容压缩，部署在只有3M带宽的服务器上加载速度着实很慢，所以只能在代理层手动进行gzip压缩（同时还加上了http cache）。

ArgoCD

Argo CD是一款适用于Kubernetes的声明式GitOps持续交付工具。应用程序的定义、配置和环境应该是声明式的，并且受版本控制。应用程序的部署和生命周期管理应该是自动化的、可审计的，而且易于理解。这是官方给出的介绍，简单来说，它可以：
1. 从Git仓库拉取Kubernetes配置，并自动同步到集群。
2. 提供可视化UI，支持应用管理、版本回滚等操作。
3. 声明式管理，所有变更都由Git驱动，保证部署的一致性。

在我的架构中，ArgoCD负责密切关注Git仓库中的deployment.yaml，一旦检测到更新，就会自动部署最新的版本。如果出现问题，直接在UI里点击回滚，几秒钟就能搞定，既优雅又高效。

CI/CD流程效果

CI阶段（Harness Pipeline）
代码推送到Git仓库后，Harness触发Pipeline：
1. 检出代码
2. 安装依赖并构建应用
3. 构建Docker镜像
4. 将镜像上传到阿里云镜像仓库（个人版免费）
5. 修改deployment.yaml里的镜像版本号。

CI到此结束，下一步交由ArgoCD处理。

CD阶段（ArgoCD部署）
1. 自动拉取最新的配置deployment.yaml（deployment.yaml存放在Git仓库中）。
2. 自动同步或手动同步应用部署。

最终，实现了代码提交→自动构建→自动部署的完整闭环，整个过程无需手动干预，更新全自动完成！

防坑指南

最坑的还是AI大模型的幻觉问题，当下AI已成为生活中不可或缺的部分，它能快速分析问题并给出解决方案，也正因如此被它带着到处摸索，兜兜转转还是回到了起点，下面来盘点这次AI带我跳过的坑。
1. 禁用Traefik
安装K3s时它让我直接把Traefik禁用，然后用Nginx或Caddy做反向代理。正好我对Caddy比较熟悉，这坑跳得那叫一个心甘情愿。老实说，Caddy的配置确实简单，尤其是在开启Let‘s Encrypt和gzip压缩这方面，于是果断选择了Caddy。起初手动部署项目的时候用着还挺顺手，直到安装了ArgoCD要开始自动部署时，我突然意识到了问题，程序虽然自动部署了，域名绑定之类的怎么办呢？难道又要上服务器吗？这才明白Ingress Controller是不可替代的。不过这一路也不算白走，不仅加深了对Ingress Controller的认识，中间还因为Flannel配置出现的问题把LoadBalancer的知识也学了不少（AI让我把自带的ServiceLB禁用了，自己安装MetalLB，还真就乖乖照着做了）。
2. Harness Pipeline配置
这个其实有点甩锅，毕竟工具是我自己选的。在使用Pipeline插件构建docker镜像这件事上，Harness自己的插件文档给出的代码并不适用于Harness Pipeline。而且AI胡编乱造给我配置文件，折腾到几乎要放弃。好在在快要放弃的前一刻，自己根据pipeline示例配置结合官方文档修改出一份，最后竟然成功解决了问题。