前言
大家好，我是老白，过去一年中，我带领团队拥抱云原生，将公司基础构架从传统的虚拟机直接部署改为以Kubernetes为核心的云原生构架，并搭建了较为完善的CI/CD系统，在效率上有较大的提升。下面我抛砖引玉，介绍一下拥抱云原生过程中的经验总结。（文章首发于developer.volcengine.com/articles/73...)
云原生之前
我们的项目是一个7年前搭建的单体系统（Monolith），一直是基于虚拟机的部署，详细流程如下：
- 开发人员本地完成功能开发
- 开发人员本地完成单元测试
- 提交Pull Request
- Code Review人员完成review后合并
- 运维人员直接部署合并后代码到虚拟机
- 虚拟机需要手动管理
这样的做法显而易见地，有好些问题：
- 单元测试是在本地进行，难免遇到本地环境和服务器环境不一样的问题
- 部署流程没有自动化，需要运维人员去部署到服务器
- 没有代码和依赖库安全检查、分析
在项目的开发、部署过程中，也出现过好多次因为环境不一致的问题导致部署不成功，延迟上线甚至线上事故。所以拥抱云原生搭建一个现代化、自动、高效的环境和流程刻不容缓。
前期调研
我们想要达成的最终目标有以下几点：
- 确保环境和依赖的一致性
- 增加代码和依赖的静态安全代码扫描（Static Application Security Testing或SAST)
- 增加Artifact（制品）的安全扫描
- 代码质量管理
- 自动化打包和部署流程
毫无疑问，容器化+Kubernetes是最佳选择解决环境依赖一致性。我们选择了云服务托管的Kuberntes集群服务，相比使用Rancher、OpenShift等工具自建Kubernetes集群，托管的集群可以让我们更专注在业务上而非基础设施的搭建与维护。
自动化流程我们采用GitHub的GitHub Actions进行，并集成各个扫描工具在流程中。工具选择上我们优先开源、免费的工具，以最小的开销实现目标。
最终流程
下图为我们最终的流程图：
除了达成上文中提到的目标外，我们新增了预发布环境，预发布环境和正式环境（Production）保持一致，用于发布之前的回归测试和性能测试，当新版本在预发布环境通过测试后，再发布到正式环境。
以下为CI/CD流程中用到的工具：
- SonarQube Community Edition用于代码质量和风格分析，Community版本免费，但是需要手动部署，也可以考虑使用SAAS版本SonarCloud
- Trivy和Grype用于静态代码安全分析，配合GitHub Security功能，可以很方便的看到代码和依赖库中的潜在安全问题。需要注意的是我们有遇到过误报的情况，在使用过程中要注意区分。
杂项
在CI/CD流程运行中，我们也遇到了一些哭笑不得的问题，比如Grype经常会误报，我们一通检查后发现好像Grype有使用关键词检测，比如我们的项目中有使用一个叫mail依赖库，Grype会报Mac OS的Mail安全问题:(，详情可以看看GitHub相关issue: github.com/anchore/gry...
在构建Image时，可以使用GitHub Action Cache (docs.docker.com/build/cache...%25EF%25BC%258C%25E6%258F%2590%25E5%258D%2587%25E6%259E%2584%25E6%259E%25B6%25E9%2580%259F%25E5%25BA%25A6%25EF%25BC%258C%25E8%258A%2582%25E7%25BA%25A6GitHub "https://docs.docker.com/build/cache/backends/gha/)%EF%BC%8C%E6%8F%90%E5%8D%87%E6%9E%84%E6%9E%B6%E9%80%9F%E5%BA%A6%EF%BC%8C%E8%8A%82%E7%BA%A6GitHub") Runner资源。
总结
以上就是过去一年来我们拥抱云原生的经验，希望能为读者提供一些思路，做一点微小的贡献。个人方面，获得了了AWS Solution Architect Professional, AWS Solution DevOps Engineer, Alibaba Cloud ACE等认证，对各个云服务有了更深入的了解，也希望尽快能有应用在火山引擎上落地。