面临当下客户需求多，产品迭代周期短，在部署环境多为中大型云原生的场景下如何保持产品对问题的及时响应并完成开发环境和测试环境的无缝对接，从而进一步的提升开发团队和测试团队的合作效率等问题，安全狗技术团队通过多次实践，借鉴现代云原生体系下的 DevOps 团队建设上的成功经验构建了CI/CD 系统从打通开发到发布的一站式流程，大大提升了客户端发布速度以及发布频率，并提升了环境的资源使用效率以及研发效率。笔者希望通过分享团队在容器化改造过程中遇到的系列问题以及对应的解决思路，为即将开启类似的“技术之旅”的安全人有所裨益。

容器改造三问

随着容器技术和 kubernetes 容器编排技术的大规模普及，围绕着云原生领域的软件工程实践也在不断的丰富。作为一款针对云原生领域安全的产品——云甲，为了满足用户不断变化的安全需求，也理所当然地拥抱了这一趋势。通过引入基于云原生的 DevOps 体系，将编译构建环境进行容器化改造，从而解决之前老编译环境上打包过程所遇到的各种问题。

问题1：老编译环境可维护性差

客户端自身的编译环境已经持续维护了数年，由于客户端核心依赖库需要兼容早期的操作系统版本以及系统动态库，所以如果重新搭建首先还是得考虑在这些早期版本得操作系统之上，而这些早期版本的操作系统和系统动态库的相关资源已经很难找到，并且，随着项目不断的迭代发展所产生的大量第三方依赖库都是通过打补丁的方式安装到操作系统中，而这些依赖库不仅多，而且有些也是一样属于早期版本甚至是进行内部修改后的版本，在这样的情况下，哪怕只是重新搭建编译环境，对团队来说也是一个不小的挑战，工作量也巨大，最后往往演变为团队共用一个编译服务器进行发布打包，并需要专人来进行定期的维护以保证环境持续可用。然而，这样的处理方式，不仅降低了团队的研发效率，同时让编译环境可维护性变差。

随着产品形态不断丰富，例如云甲的客户端都需要具备打包为容器镜像的形态，所以基于早期版本操作系统的编译打包环境无法完成这个工作。如果另外部署机器仅仅只进行容器镜像的构建，对计算机资源不仅是一种浪费，还进一步增加了维护的工作量。

问题2：老编译环境资源紧张

由于客户端产品形态多样，编译环境需要能支持多种产品的打包，所以导致了编译环境进一步臃肿和复杂化。同时，需要外部协调打包编译时间，以及需时刻关注是否有代码错误提交导致编译问题从而阻塞所有的打包流程。随着产品迭代周期的持续缩短和客户需求的增加，团队如何在资源紧张的情况下保障客户端能顺利发布也面对了巨大的挑战。

问题3：项目打包发布流程繁琐 自动化程度低

虽然项目本身增加了很多自动化脚本帮助打包，但是每次打包依然需要团队相关的小伙伴全程参与。并且，由于编译环境没有和任何的测试环境打通，每次编译打包完成后都需要进行手动部署、分发到测试环境中。这些繁琐的操作和研发任务影响不大，但是却挤占了一部分的时间，从而导致团队研发效率始终受到掣肘。

容器化改造的方向

在满足监管和安全等要求的前提下落地 CI/CD 平台

不废弃老旧编译环境，在维持原有开发流程基础上，通过接入 CI/CD 平台对资源进行重新整合而形成新的开发环境，实现平稳过渡

解决老环境对开发团队掣肘的问题

除了对业务流程上的改造要求，在平台的选型上主要考虑如下几点：

容器化 CI/CD 平台的稳定性和运维成本

容器化 CI/CD 平台对项目中对老环境以及老的三方依赖的兼容性支持

容器化 CI/CD 平台对项目未来持续改进的扩展性支持

容器化 CI/CD 平台对项目碎片化的管理以及构建支持

对项目的 CI/CD 化改造不应该过度侵入项目本身

尽可能的降低单次 CI/CD 的时间，提高项目发布速度

容器化 CI/CD 平台可以提供定时构建的功能，提高项目发布的频率

结合这些因素经过多轮比较，安全狗云甲开发团队最终选择了基于 kubernetes + gitea + drone + freeNAS的方案。

Kubernetes

Kubernetes 是一套生产级的容器编排体系，部署该平台不仅可以用于 CI/CD 平台的运维，保障稳定性。同时，该平台还可以作为客户端平行容器发布部署的初验平台，进一步整合开发和测试环境资源提高整体的资源利用率。

Gitea

Gitea 是一套开源的 Git 服务，它安装简易，运行迅速，并具备和 Github 和 Gitlab 类似的功能，可通过它来存放一些改造所需的支持脚本。同时，通过在上面建立针对项目的专用于打包的项目（也就是只存放同项目 CI/CD 流程相关的自动化脚本以及其它三方资源），而不是直接引入项目代码本身，避免了改造对项目的过度入侵；另外的好处是，通过 Gitea 来管理分支和创建工单来跟踪项目的 CI/CD 发展情况可以有效的针对多用户定制化需求导致的碎片化问题进行管理，并为未来项目的持续改进提供了可实验的场所和支持。

Drone

Drone 是一套专门用于 CI/CD 的服务平台 ，通过和 Gitea 对接实现手动以及自动的定时构建。

FreeNAS

FreeNAS 是一个提供网络存储的服务，用它实现 Gitea 上的 CI/CD 自动化相关支持的代码和项目本身的代码进行分离，做到不影响原有开发体系中所使用的 svn 服务，同时也可以省去每次 CI/CD 流程中拉取项目代码的操作，从而缩短 CI/CD 的时间，提高项目的发布速度。

下面我们详细介绍一下云甲使用的方案在开发环境中进行容器化改造的最佳实践。

容器化改造的最佳实践

基础设施部分

构建 Kubernetes 集群作为平台的基础环境，采用 v1.20.1 版本。

安装 Gitea 以及 Drone，为了保障 CI/CD 数据的持久化，需要在 Kubernetes 中部署一套 NFS 服务并通过 Storage Class 为 Gitea 以及 CI/CD 过程中的临时容器提供持久化存储（提供构建资源的以及发布产品的访问入口）。

部署 FreeNAS 服务在 Kubernetes 集群外部，为了满足安全需求，这里代码并不会存储在 Kuberntes 集群中提供的 NFS 服务中，而是每次将代码同步到 FreeNAS 服务中。而 FreeNAS 服务本身所处的内网环境安全等级更高，并且具备更多的实时流量监控手段，一旦发现异常的流量波动等情况就能及时处理。而这里将 FreeNAS 中暴露出来的接口挂载到 Kubernetes 创建出来的 PVC 目录之下，这样就实现了 CI/CD 对项目代码的访问，通过自动化的手段将其控制在仅在构建时挂载。进一步的保障了项目代码整体的安全性。

打通老编译服务器到 FreeNAS 的自动化同步机制，通过配置 rsync 的同步机制，定期将老编译服务器的代码更新到最新版本，并同步到 FreeNAS 指定的目录中。这样新的 CI/CD 服务平台并不会对老的编译服务器产生干扰，同时 rsync 强大的同步能力可以有效降低同步的资源消耗（增量同步），以及增强安全性（访问认证）。

CI/CD 及流水线

流水线建设的主要目标是重用打包服务器资源，保证老的流程不会受到 CI/CD 的影响，并降低流程复杂度。

上图中，蓝色标注线是老环境下的开发测试流程。可以看到开发人员需要承担手动打包和发布的流程，在任务紧急的情况下，这将对开发团队造成较大的工作量。而 CI/CD 平台接入后，开发人员原有代码提交方式没有变化（依然是通过 svn），但是通过额外的自动化同步服务，将代码镜像同步到 FreeNAS 中并进行 CI/CD 流程的打包和发布，避免了原有手动打包和发布流程中的繁琐操作。

由于没有使用老编译环境服务器做 CI/CD 的核心环境，这里采用的办法实际上是通过将原有编译环境中的 rootfs 复制出来，并裁剪优化后制作为一个容器镜像容器在 CI/CD 流程中使用。

将这个镜像上传到开发环境中的私有仓库，由于裁剪了过去长期积累在虚拟机中的其它不必要文件，这个镜像大小还大体能够接受。同时对于未来升级编译环境的操作，可以通过 commit 为一个新的镜像来完成。这样每一个人对环境的改动都将迅速的体现到 CI/CD 流程中，并且也可以通过更新镜像快速将更新同步到开发人员自己的本地环境上，简化维护手段。

客户端的发布使用的是平行容器模式，通过 helm 进行升级操作。在发布完成后，通过自动化脚本套用模板向相关团队发送邮件通知构建完成。这样产品的发布流程得到了进一步的标准化，同时大大减轻了开发人员自身的工作强度。并且，通过每日构建的形式，时刻掌握团队代码提交的整体情况，避免有问题的代码提交到服务器后长时间没有发现，当在需要紧急打包的时候才发现有问题而拖累整个开发团队的情况。同时，每次构建都会记录相应的构建日志以及持续时间等指标，这样为后续优化项目内部构建流程提供了参考。

平台推出对团队的收益

由于 Kubernetes + Gitea + Drone 的方案是一个相对比较成熟的方案，同时网络上关于同类平台的资料介绍也比较多，所以部署上花费的时间并不多。同时，由于有 Kubernetes 在后台的保障，日常的维护基本也不用过多的参与，Kubernetes 可以有效的检测到节点的磁盘内存和 CPU 的压力，一旦超过界限就会立刻做出提示，所以平台从搭建到运行至今基本没有出现过重大的崩溃问题。所以，总体来说这套平台的运维成本很低，基本不需要为了它而额外投入时间和精力。

同时，这套平台的每日构建功能极大地方便了测试团队对问题回归的环境保障需求。每天早上在凌晨的时候，平台会启动一次构建操作，随后将构建完成的客户端发布到测试环境中，这样每天测试团队从工作时间开始就可以投入到具体的测试工作，过去需要等待开发团队进行打包工作的费时且繁琐的流程一去不复返。产品迭代周期内的压力得到了缓解。

总结

简单总结一下，本文首先介绍了云甲产品的开发现状和所面临的问题以及进行容器化改造的背景，然后详细描述了落地过程中的一些实践，通过整体改造，原有环境中打包部署发布工作量大，流程繁琐并需要开发人员全程参与的状况都得到了解决。产品对外发布速度和响应客户需求的速度都得到了进一步的优化和提升。同时，环境不可维护以及成本问题都得到了有效的控制。希望本文能够对读者改造自己团队中的古老项目提供一定的参考和帮助。