背景

2021 年初，我们计划实现一套高性能、操作便捷、易于维护的 WEB 版测试环境发布管理系统。起初已经完成了设计与关键技术点调研，也完成了基础应用架构和主流程脚本的开发，就差应用梳理和功能开发了。但是由于非技术方面的管理原因，导致项目中止。想来也是自己的一次成长与付出，做个记录纪念我死去的脑细胞，也方便以后翻出来复习。

补充说明

设计出来的背景是什么？
背景上面介绍了部分，再补充下吧。
我们平时有几十个并行版本会同时在测试，原先使用环境发布系统，设计上存在一定短板，如资源利用率低、系统健壮性差、历史遗留冗余功能太多、交互卡顿，且由于原开发团队人员流失，后续的外系统对接、功能维护和改进方案很难推进，因此我们需要一个易于维护可扩展的发布系统。

要解决什么问题？
我们主要着眼于团队最为关心的质量、时间、成本，这三个方面进行了平台的设计：
质量：采用 k8s 的环境隔离方案，和 rancher 的集群管理能力，结合自定义的深度健康检查机制，保障应用服务容器的稳定在线。
时间：将 git 提交行为与 jenkins 关联，结合动态节点配置，在空闲时段自动准备好发布镜像，让应用编译行为前置，缩短发布时间。
成本：这个分为 2 个方面考虑：人员使用成本、系统资源维护成本。测试应用的占用资源，交由 rancher 在服务器资源中动态分配，摆脱我们老系统资源位置固定、ip、dns 资源固定的弊端。并且我们整合了原来复杂发布步骤，让测试人员可以更便捷管理被版本环境。

解决的核心思路是啥？
核心思路是围绕 rancher 和 jenkins 提供的动态管理能力，串联必要 api 接口，让测试环境从代码到服务的操作路径缩短。

整个流程跑起来是怎么样？
以一个版本测试环境准备为例：

• 1. 测试人员进入平台，选择对应的版本号和相关应用，创建一个发布任务。
• 2. 系统检查对应用的镜像是否需要编译生成，并结合 jenkins 进行 CI 操作。
• 3. 系统调用 rancher 创建一个独立项目环境，并部署应用，通过中转代理对外提供服务发现。
• 4. 测试人员收到部署通知，配置代理或 host，访问被测试环境。

这其中的 2～3 步骤，对于测试人员来说是不用管的，看到的一个部署状态的提示。

架构设计

技术坑点记录

• Jenkins default Jnlp node name
• Pipline 语法（拼接 pod template）
• harbor 认证服务
• Docker https 限制
• kubernetes plugin 配置
• NFS 搭建与 PVC 的使用
• 内网路由穿透配置（方便单应用的服务发现，非必需）
• Jenkins 分布式 + 集群 +docker in docker
• Pipline 失败重试 try catch 版本号
• Tomcat 路径资源
• Ingress 映射关系暴露
• Nginx https 反向代理
• python Jenkins api 使用
• Rancher Api 调用梳理
• Jenkins 模版使用
• Nginx 忽略报错启动（reslover）
• Nginx 参数化部署
• Jenkins 指定节点的编译环境设置

参考文档

• NGINX Ingress Controller
• Python-jenkins 模块获取 jobs 的执行状态操作
• Rancher-2-2-2 之 Jenkins+rancher+harbor+Gitlab 部署应用到生产
• Kubernetes 权威指南学习笔记
• 从 Docker 到 Kubernetes 进阶
• Rancher Api
• Python-Jenkins 助力传统发布流程
• Nginx Docker and Environment Variables

# 结语
技术的终点是管理，管理的终点是格局，格局的终点是人性。