北纬科技三步走完成 DevOps 转型

2022 年 2 月 28 日
本文字数：2086 字
阅读完需：约 7 分钟

分享人：任浩杰，北纬科技信息安全工程师，北纬科技云效迁移 DevOps 的技术负责人。

背景

北纬科技成立于 1997 年，是一家致力于提供移动互联网先进产品和服务的移动互联网服务集成商。早期自主研发了私有 PaaS 平台（北纬应用引擎 BWAE），后来由于公司转型及组织架构调整，逐步用云效+ACR+ACK 替代自研应用引擎，实现持续部署、交付、减轻管理、维护及运维的压力。

问题及痛点

为什么放弃自研，转而拥抱 Saas 服务？

早期公司自研 PaaS 平台，历时较长。因 PaaS 平台自身的复杂性、技术发展的多变性、系统要求的稳定性的各类复合型要求，使平台无法及时迭代更新满足各类场景需求，更好地为业务发展服务。同时公司组织战略调整，人力资源重新分配，公司的自研平台面临比较大的维护压力和运维压力。因此公司技术战略也随之调整，将自建机房及服务全部迁移到阿里云上，同时调研腾讯、阿里、华为等商业化的 DevOps 平台，最终选择阿里云云效作为 DevOps 持续部署的平台。

相比于自研，云效平台缺少了企业的定制化、个性化，只能做到普适性，但是增加了平台的稳定性、健壮性、多样性，同时大大减少了人力、物力，减轻了运维的压力。

解决效果

使用云效后效果如下：

迁移之路如何走？

经历过近 3 个月的云效使用调研之后，公司启动云效迁移项目,同时制定了以下三步走的迁移策略。

第一步：内部试点、发现问题、解决问题。

第二步：沉淀模版、梳理文档、规范流程。

第三步：全面迁移、分配新资源、回收旧资源。

在迁移中，对技术、成本、安全各方面进行不断优化。

1、技术优化

基础镜像优化：由于每次构建 Java 镜像会导致镜像体积过大，OpenJDK 官方的镜像大小为 488MB，如果每次构建的镜像都这么大的话，对网络、存储等的影响及费用都会比较大，因此我们采用分开构建的形式，基础镜像如 JDK、PHP、GO、Nginx 等镜像由运维人员维护，提供基础环境及 k8s 的主镜像。开发人员构建的镜像采用 busybox 镜像，该镜像仅有基础的 linux 功能，因此只有 1.23MB，该镜像只添加程序构建的产物如可执行文件、jar 包或者 html 文件等，作为 InitContainer 容器，在启动时将构建产物复制到基础镜像中。该方案大大缩小了 docker 镜像的大小和 docker 拉取镜像的网络开销。

流水线优化：基于一次构建，多次部署的思想，我们将构建和部署流水线做了分离，这样构建一次，开发、测试、生产可以多次部署，且部署的版本可以不同。

定制化不同的流水线模板，根据不同事业部，不同业务需求形式、技术开发特定的要求，制定符合各业务线的流水线模板。

不同的流水线模板

2、成本优化

经过了对企业应用部署的研究，我们在 ACK 集群上借助 kubernetes 提供的 LimitRange 的能力，对每一个命名空间做了一个基础容量的大小限制（CPU 0.5m，Memory 512Mi），而在应用的部署配置文件上为开发人员提供了设置 cpu 及 memory 的配置项，且提供了默认值。如果开发人员经过评估和开发环境、测试环境的验证，需要增加容量的，可以申请对该命名空间提高限制。一方面将一部分 ops 能力下放给 developer，两一个方面，通过对资源的主动和被动调节，大大节省了成本，降低了原来自研平台上任意配置资源的问题。

同时通过云效的 maven 服务、代码管理服务，替代了原有平台搭建的代码管理服务器、maven 服务器。不仅降低硬件成本资源，同时也降低维护此类服务器的人力成本。

3、安全优化

代码质量优化：得益于云效的代码扫描流水线中的代码扫描及安全扫描的任务插件，我们对于质量和安全的接入管理方便。

我们在流水线模版中引入了代码扫描及安全扫描，同时在生产环境加入了人工卡点的流程，作为审核，保证扫描结果符合要求。