AI独角兽商汤科技的内部服务容器化历程

本文由阿尔曼，商汤科技运维工程师于4月26日晚在Rancher微信群所做的技术分享整理而成。商汤科技是专注于计算机视觉领域的AI公司。本次分享结合了容器平台团队帮助公司业务/内部服务容器化历程，介绍商汤科技在容器化历程中使用的工具、拥有的最佳实践及值得分享的经验教训。

---

内容目录

● 背景 
● 需求分析与技术选型 
● 容器镜像 
● 监控报警 
● 可靠性保障 
● 总结

背 景

商汤科技是一家计算机视觉领域的AI创业公司，公司内会有一些业务需要云端API支持，一些客户也会通过公网调用这些所谓SaaS服务。总体来讲，云API的架构比较简单，另外由于公司成立不久，历史包袱要轻许多，很多业务在设计之初就有类似微服务的架构，比较适合通过容器化来适配其部署较繁复的问题。

公司各个业务线相对独立，在组织上，体现在人员，绩效及汇报关系的差异；在技术上体现在编程语言，框架及技术架构的独自演进，而服务的部署上线和后续维护的工作，则划归于运维部门。这种独立性、差异性所加大的运维复杂度需要得到收敛。

我们遇到的问题不是新问题，业界也是有不少应对的工具和方法论，但在早期，我们对运维工具的复杂性增长还是保持了一定的克制：ssh + bash script扛过了早期的一段时光，ansible也得到过数月的应用，但现实所迫，我们最终还是投向了Docker的怀抱。

Docker是革命性的，干净利落的UX俘获了技术人员的芳心，我们当时所处的时期，容器编排的大战则正处于Docker Swarm mode发布的阶段，而我们需要寻找那种工具，要既能应对日益增长的运维复杂度，也能把运维工程师从单调、重复、压力大的发布中解放出来。

Rancher是我们在HackerNews上的评论上看到的，其简单易用性让我们看到了生产环境部署容器化应用的曙光，但是要真正能放心地在生产环境使用容器，不“翻车”，还是有不少工作要做。由于篇幅的原因，事无巨细的描述是不现实的。我接下来首先介绍我们当时的需求分析和技术选型，再谈谈几个重要的组成部分如容器镜像、监控报警和可靠性保障。

需求分析与技术选型

暂时抛开容器/容器编排/微服务这些时髦的词在一边，对于我们当时的情况，这套新的运维工具需要三个特性才能算成功：开发友好、操作可控及易运维。

开发友好

能把应用打包的工作推给开发来做，来消灭自己打包/编译如java/ruby/python代码的工作，但又要保证开发打出的包在生产环境至少要能运行，所以怎么能让开发人员方便正确地打出发布包，后者又能自动流转到生产环境是关键。长话短说，我们采取的是Docker + Harbor的方式，由开发人员构建容器镜像，通过LDAP认证推送到公司内部基于Harbor的容器镜像站，再通过Harbor的replication机制，自动将内部镜像同步到生产环境的镜像站，具体实现可参考接下来的容器镜像一节。

操作可控

能让开发人员参与到服务发布的工作中来，由于业务线迥异的业务场景/技术栈/架构，使得只靠运维人员来解决发布时出现的代码相关问题是勉为其难的，所以需要能够让开发人员在受控的情境下，参与到服务日常的发布工作中来，而这就需要像其提供一些受限可审计且易用的接口，WebUI+Webhook就是比较灵活的方案。这方面，Rancher提供的功能符合需求。

易运维

运维复杂度实话说是我们关注的核心，毕竟容器化是运维部门为适应复杂度与日俱增而发起的，屁股决定脑袋。考虑到本身容器的黑盒性和稳定性欠佳的问题，再加上真正把容器技术搞明白的人寥寥无几，能平稳落地的容器化运维在我们这里体现为三个需求：多租户支持，稳定且出了事能知道，故障切换成本低。多租户是支持多个并行业务线的必要项；容器出问题的情况太多，线上环境以操作系统镜像的方式限定每台机器Docker和内核版本；由于传统监控报警工具在容器化环境捉襟见肘，需要一整套新的监控报警解决方案；没人有把握能现场调试所有容器问题（如跨主机容器网络不通/挂载点泄漏/dockerd卡死/基础组件容器起不来），需要蓝绿部署的出故障后能立刻切换，维护可靠与可控感对于一个新系统至关重要。

技术架构图

总结一下，Rancher, Harbor, Prometheus/Alertmanager为主的开源系统组合可以基本满足容器管理的大部分需求，总体架构如下图