基于容器服务的持续集成与云端交付（二）- 多维度打磨交付能力

前言

在上一篇中，和大家一起讨论了传统软件交付的问题、持续交付的难点、以及为什么云端的容器交付可以协助大家快速的持续交付。

但是当真正的将一个系统通过云端容器交付的时候会发现不能单纯的将 Docker 作为一种交付工具来对待，更多的时候是作为一个交付平台的基础设施来看待，还需要关心的是使用 Docker 后网络、存储、安全、性能、监控等等不同方面带来的变革。

因为交付的本质是将一套复杂的软件系统从零到一完成开发、测试、部署、上线的过程，软件的复杂度直接关系到了交付的难度，特别是现在微服务的架构方式越来越成为主流，给交付也带了更多的挑战。

我们不仅要考虑一个系统交付的环境，而且还要考虑针对特定的软件架构，交付系统的网络、存储和安全等等是否能够满足需求。本文中将会针对上面提到的内容，分享我们是怎样从以上几个方面打磨交付能力。

关于容器服务

基于容器的交付方案有非常多的开源选型，K8S、Mesos 等等都是目前非常流行的方案，K8S 脱胎于 Google 的 Borg 系统，在 Google 内部已经运行多年，成熟度与稳定性上是其他系统无法比拟的；Mesos 则在资源分配上有先天的优势。

阿里云容器服务是基于阿里云 ECS 服务构建的 CaaS 层产品，提供兼容 Docker 的 API、Docker Compose 的模板，通过集成阿里云已有的 IaaS 层、SaaS 层的的云原生服务，提供完整的 Docker 的云原生的解决方案。对 Docker 的兼容性以及云原生的服务能力是容器服务与开源方案最大的区别，当开发者已经开始使用云服务作为软件架构的基础设施的时候，Docker 带来不应该是破旧立新的变化，而应该是更便捷的使用云服务来实现交付。

系统架构

(点击放大图像)

上面是容器服务的基本原理图，用户可以通过容器服务创建属于自己的容器服务集群，每个节点上会默认安装容器服务的Agent，容器服务通过提供高可用的管控服务，用户可以通过控制台或者API 下发指令到容器集群。对外暴漏的API 分为服务API 与集群API，服务API 是完全兼容Docker 的API，开发者可以直接通过Docker 命令操作远程的容器集群；集群API 是标准的阿里云OPEN API，开发者可以通过SDK 进行集群的创建、删除、扩缩容等操作。此外容器服务还同SLB(负载均衡服务)、SLS（日志服务）、CMS(云监控服务)、OSS(对象存储服务)、NAS（NAS 共享存储）等云原生服务打通，开发者可以在阿里云容器服务中便捷的使用云原生的服务能力。

下面我们主要在网络、存储、监控、日志等方面来简介下阿里云容器服务的交付能力。

网络

网络在容器的方案中是一个绕不开的老话题，使用容器可以让每台机器上运行更多的应用提高机器的资源利用率，可以让应用更简单的在机器之间迁移等等。

但是对外提供的服务都需要暴漏特定的端口或者服务端点，传统应用与宿主机共享网络的方式就很难满足需求。

Docker 默认提供了 None、Bridge、Host、Overlay 四种网络模型，其中 Host 网络模型就是宿主机与应用共享网络的架构，但是对于很多开发者而言，Overlay 的网络模型是更常用的网络方案。Overlay 网路是在集群上构建了一个全局的二层的网络，容器启动在这个全局的网络上，每个容器有自己在集群中独立的 IP 地址，集群节点上的容器可以直接通过容器的这个独立 IP 进行通信，而不需要通过 NAT 暴漏到主机端口，解耦了与宿主机 IP 的依赖，因此避免了做 NAT 的时候多个容器端口冲突的问题。但是 Overlay 网络是 Vxlan 的一种实现，在发送信息或者接收消息的时候会进行封包与解包，这样会在性能上造成 20% 左右的网络损耗。

因此阿里云容器服务在 VPC 网络中针对 Overlay 网络做了性能的优化。在 VPC 网络模式下容器互通是结合了阿里云 VPC 服务的自定义路由的功能，通过 Docker Network Plugin 的配置容器的 IP 在固定的网段，下图是 VPC+Docker 的网络结构：

(点击放大图像)

网络请求无需再封包解包，可以直接通过虚拟交换机与虚拟路由器直接进行转发，降低了网络的性能损耗。

存储

Docker 的特性，决定了容器本身是非持久化的；容器被删除后，其中的数据也一并被删除了。而且使用容器进行部署的应用通常以无状态的应用为主，大多是水平扩展的，因此一旦涉及到落盘的存储就需要在不同的容器之间进行共享。

针对落盘的存储，Docker 提供数据卷（Volume），通过挂载宿主机上的目录来实现持久存储。但在集群环境中，宿主机上的数据卷有很大的局限性。容器在机器间迁移时，数据无法迁移，不同机器之间不能共享数据卷。容器服务通过 Docker Volume Plugin 的方式集成了阿里云磁盘，OSS，NAS 的容器存储，在容器重启和迁移的时候也可以自动的挂载，保证了容器持久化存储的共享和安全。容器服务通过将 OSS、NAS 的远程存储端点映射成为一个主机的磁盘挂载点，开发者可以像使用本地磁盘的方式直接使用不同类型的共享存储。

对于非落盘的存储，例如缓存、数据库等，可以直接使用云原生的服务例如 RDS(关系型数据库)、KVStore(缓存服务) 等等来实现，不建议使用容器化的存储服务，云原生的数据存储服务可靠性更高，性能更好，而且在运维、安全等场景中有先天的优势。

监控

监控在容器的场景中是一个非常重要的功能，因为容器的场景下需要做宿主机与容器两个维度的监控，而容器的弹性扩缩容也依托于监控的功能。

为了应对特定的场景实现，我们的监控依托于阿里云云监控服务，提供默认的监控、告警规则配置等服务。与此同时容器服务还提供了非常简单快速地与第三方开源监控方案（例如 InfluxDB、Grafana）集成的能力，用户可以方便的和自己的监控或报警系统对接。并且，多维度全方位地提供各个层次的聚合监控指标，以期在不同的维度做监控、告警提示、分析以及实现自动化运维。开发者可以在云监控中查看主机级别、应用级别、服务级别、容器级别等多个维度的监控，依托着四个维度的监控指标，可以进行主机级别的弹性伸缩与容器级别的弹性伸缩。

日志

日志是应用排查问题的最后一个手段，当应用容器化之后日志的收集面临了更大的挑战。需要能够收集、聚合多个容器的日志并且容器迁移或者重新部署后日志仍然可以进行收集，因此传统的落盘采集式的日志收集方式就无法满足需求了。

容器服务提供了集成阿里云日志服务的能力，日志服务是针对日志场景的平台化服务。无需开发就可以快速完成日志收集、分发、投递与查询， 适用于日志中转、监控、性能诊断、日志分析、审计等场景。在容器服务中集成的日志服务，可以方便的把容器日志发送到日志服务里，只需要在 Docker Compose 编排模板中添加 aliyun.log_store_name: 的标签就能实现容器日志的自动采集与上报。日志的配置与应用是关联的，日志的采集与应用的容器是动态链接的，容器的变更会触发日志插件重新链接与容器的关联关系，当日志流从容器产生时就会动态地被采集到日志服务，通过日志服务进行聚合，如果有更细粒度的分析需求，可以将日志投递到 MaxCompute（大规模计算）进行数据分析。

尾声

在上面我们浏览了下阿里云容器服务提供的能力，云端交付的首要条件是能够交付，然后才是如何交付。阿里云容器服务在网络、存储、监控方面对基于容器场景的架构进行了增强。让复杂的系统在云端容器交付中成为了可能。此外容器给开发者带来的最大价值是可能性，容器服务也在机器学习、高性能计算等领域进行了探索，希望越来越多的领域可以在容器的帮助下更好地实现自身的价值。在下一篇文章中，我们将会讨论如何从零搭建一个持续交付系统并交付软件。

个人简介

莫源，阿里云高级研发工程师。在加入阿里巴巴之前，先后在北京天方地圆科技有限公司、微软亚洲研究院任职。现主要负责阿里云容器服务产品的底层服务发现系统、集群管理系统的研发，从事容器的持续交付、持续集成的方案的设计与实现。在云计算、分布式系统、图像识别与虚拟现实方向有多年的开发经验。

感谢木环对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。