转载

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

前言

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

但是当真正的将一个系统通过云端容器交付的时候会发现不能单纯的将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: <log location>的标签就能实现容器日志的自动采集与上报。日志的配置与应用是关联的，日志的采集与应用的容器是动态链接的，容器的变更会触发日志插件重新链接与容器的关联关系，当日志流从容器产生时就会动态地被采集到日志服务，通过日志服务进行聚合，如果有更细粒度的分析需求，可以将日志投递到MaxCompute（大规模计算）进行数据分析。

尾声

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