今天我会从三个方面介绍整个内容，第一个是背景，这个平台是干什么的，有些什么样的约束，我们是怎么把它做出来的。第二是我们在构建一个平台的时候想怎么运维好它，否则在可靠性方面就很难做到理性的状况。同样的道理，虽然我们是做产品，做运维的产品，但是这个运维的产品本身也会运维，也会交给其他的团队做运维，也是整个开发团队眼中的运维团队所做的事情，所以我会把这几个方面糅合到一起，我会讲平安云在构建的时候如何考虑运维的，把它推给用户的时候，是怎么把它跟运维的过程结合到一起，是这样一个内容。

这个图是给大家认识一下平安云在解决什么问题，这个问题很好回答，目前市面上大家做的尤其是金融企业做的无非两种，一种是基础设施的云服务，一种是各种各样的Paas服务，每个企业的规模不一样，构建的难度和复杂度也不一样，因为平安集团有几十家专业公司做一个内部客户，所以我们在构建一个云的时候，不是一个简单的私有云，是一个企业内部的公有云，对集团其他专业公司来讲我们是一个公有云，但是对集团外的客户来讲是私有云。所以我们在构建的时候，从产品形态、交付的模式、收费的模式基本上会参照公有云的做法，我们第一个学习对象就是亚马逊，包括我们所有产品的购买过程和我们产品的属性，第一个老师是亚马逊，第二个老师是阿里云，我们也会参照他们的做法去做，参照他们做法做出来的产品，第一个就是云主机，现在已经有上万台的云主机在运行，第二个是云磁盘，这是云主机的扩充，还有VPC的服务，也是在私有云比较难的地方，构建内部虚拟的私有云。还有对象存储，数据库服务团队，也在努力把传统的数据库做一些云化的工作，这些事情不是一天就能做成的，我们从2013年到现在，虽然我们花了很多的人力物力，包括各个兄弟单位一起支持，但是整个产品还是成长期，还没有完全成熟，但是已经在企业内部有一些成果。

紧接着就讲容器服务，容器在这几年有很大的热度，每个企业都在尝试，开发经理和CTO们也在想我们公司能不能用容器来解决包括架构的问题、交付的问题，平安也一样，我们也有很多人提出平安容器服务。之前有好多人在做平安容器服务，也在解决具体的问题，效果也都还OK，在平安云的框架下我们做的容器服务也有一个老师，还是亚马逊的容器服务。为什么我们想做这样一个容器服务，而不是通常讲的K8S模式呢？跟亚马逊遇到的问题是一样的，我们已经有一个Iaas的问题，这个解决了存储和网络的问题，我们现在要解决的是容器问题，现在基本上是默认Iaas平台上，我们会优先放在Iaas平台上，这样就有了物理机、虚拟机加容器这样的计算三剑客。这三剑客解决各类金融企业里面对IT基础设施的要求，因为我们有很多包括保险还有银行、证券，所有这些不同的业务模块对计算的要求是完全不一样的，所以我们提出这样一个方式，我们不只是提供虚拟机、物理机，还有提供容器服务，容器服务的目的就是为了解决用户快速交付、做微服务的支撑。

我们的容器服务也会有自己的特色，我觉得每一个云基本上不是公有云还是私有云，没有一个公司做的云和其他公司一样，我们也不会特别强调我们的编排怎么做的，我们支持多么复杂的基础设施，没有这样的场景，我们的场景很简单，就是把它归结为两块，一个是我做自助服务，做好之后开发团队想用这个容器来做应用，可以自主的完成，就像亚马逊穿一个ESS一样，拿到这个容器一样，可以很高级的用它也可以很低级的用它，都没关系，这是第一块。

第二块是我们也想支持流水线，刚才跟其他同事也交流了，我们同事在做一个开发过程的优化项目，就是希望通过流水线来实现整个开发环节的自动化，我们在环境交付这一块就是想实现一键交付，这个一键交付是开发人员直接去交付一整套的环境，点一个键，提交一个版本，后台编译、打包、验证所有搭建的有效性，一步到位。在没有完全实现广义上的一键交付，但是在某些特定场景，我们也实现了一键交付，正在向不同的开发团队推广，这是我们做容器平台要支持的第二个场景，就是支持开发到运维流程的打通，这是我们给容器服务定义的两个最大的场景。

接到这个题目的时候我一直在想，这是运维的大会，我们团队里面大部分都是开发人员，开发各种各样的云产品。不知道大家是否认可一个观点，运维这个团队最大的价值就是交付，就是把你的服务、把你的产品，以可靠的、有效的方式快速交付出去，其实我们做云产品也一样，我做云网络的产品，就是要把云网络交付出去，这个交付就隐含着从无到有做出来和高效的交给用户，还要持续保证服务的可用性，因此可以说，云平台团队除了销售人员之外，其他人员都可以认为是运维人员或者交付人员，因为他们都是在做相互相同的目标。因此我们在构建的时候，我们也在学习SRE的理念，但是我们没有这样一个岗位，我们是对所有产品岗位负责人是这样要求的，你产品设计的时候，必须从产品的生命周期，创建、规划、构建、交付、运维的几个环节来把运维的事情考虑进去。

刚才那两个是大的场景，做自助服务和流水线，从产品的形态和用户在用的场景，我们做了简化，包括一些共有的容器云也好，功能很多，大家会把整个开发的过程全部都考虑进去了。在平安做容器服务还是站在运维角度看的，所以我们把客户的场景做了几个归类，第一个是我们是多租户管理，所以首先会有租户管理，这个租户是针对整个Iaas平台也好，都会涉及到租户的管理。有租户的容器云和没有租户的容器云，或者构建多租户的Iaas的容器云有个特点，我们是要求租户主动地去启用容器服务，不是每个租户在平安云上一创建，就用到容器服务的，不是这样的，我们认为容器服务在目前阶段还是高级产品，也不是一个刚需产品，是一个需要用户主动去申请的服务。申请的过程在我们这边设计是管理员可以划定它的区域，把Iaas的资源池作为一个环境，在这个环境下构建一个独有容器的平台，跟一般做法不一样，我们并没有在一个大的容器平台上划租户，而是在Iaas平台上划租户，Iaas平台给容器平台，这样单租户就OK了，因为底下资源已经划分了。好处就是这个容器的用户可以有自己独立的网络和独立的资源池，不需要跟别的用户混在一起。等下也会看到这种方式给别的平台，给运维也带来了好处。

第二是环境管理，我有一个租户建了一个容器平台之后，他是需要划分它的环境，至少会有开发环境和生产环境，他可以去创建这个环境，每个环境又有独立的资源池和网络，也可以在这个环境设置相应的权限。

第三个是应用管理，这个应用管理对应了企业内部的一些应用或者系统，在平安叫做子系统的管理，它需要部署，这里面就是一个应用，在云平台或者容器服务里就是一个应用，这个应用需要一个人来统筹管理，也是对整个编排来讲，一个应用也是一个编排的单位，我也搭一套一个企业的网站或者门户网站，所有这些都会在容器的应用管理里去设置。

应用的下一层就是服务，每一个集群都对应了一个服务，服务下面就是容器，相应有多个容器。还有一个容器特有的就是镜像管理，也是跟非容器的做法管理不一样。这是我们把它对接为五个，基本上把这五个步骤放在类似于一条生产线上，你可以一步一步往前做，不同角色可以看到不同功能，完成你自己的那一块，具备你相应的权限。

我们做了这样一个产品规划之后，接下来就要落地实现，实现的时候也会把刚才说的一些架构约束带进来，例如容器服务要同时支持物理机和虚拟机，也支持动态的添加资源，我不是买二十台服务器在那里给大家用，我们是把容器的资源池当做动态的资源池，就是利用Iaas的弹性动态来使用，而且我们需要在多个中心，如果用户想多中心部署，我们就在多中心给他创建这样一个容器服务。我们还要解决一些容器搞不定的问题，比如容器服务也好主机也好，肯定会跑到某个网络区里，跟网络区是有边界的，边界的防火墙不在容器范围内，包括还有一些运维系统也不在这个范围内，还有一些外围的数据库服务也不在这个范围内。这些服务也需要统筹进来，所以我们也有一个编排的框架，把容器当成一个产品，如果需要搭建容器的，我就调容器的接口，如果需要开墙我就调网络服务的接口。

因为容器平台做出来之后是要投产的，不投产平台就没有意义了，所以我们在创建这个平台的时候走得比较慢，我们一定要让它能够生产投产的规格，才能让它投产，所以我们兼容原有的ITIL平台。还有一个就是容器的网络，之前有一个容器网络做得不是很好，实际上我们绕过了这个问题，我们用最简单的网络方案来实现，借用底层的网络来做连通性的支持。这个图就展现了我们在多中心多租户的架构上，我们是怎么构建的。原理上很简单，因为多中心已经是多平台，通过一个集中的入口，对所有的平台进行管控，所以我们自己做了一个容器服务，底下对接一个编排的框架，来共同完成这样一个服务。底下有一个图，这个是租户环境，这个环境可以有多个主机，底下的编排就会把容器对应起来，也会跟镜像对应起来。

这是把其中的一块抽出来，中间是一个Caas的Portal，会有自己的数据库，这里写的平安云是平安的Iaas的接口，还有我们公司的资源管理平台，用来做资源的记录和查询，还有Ansible是做远程执行的，执行一些脚本和处理化的动作，还有一些远程登录的代理、镜像的拉取，这些动作都是通过Ansible去控制。中间我们是用registry做编排，因为我们做这个平台体系上已经够复杂了，所以编码这一块我们希望更简单，不需要引入更多的概念，大多数都是围绕刚才的产品定义和场景完成，只要这个编排框架够稳定够轻量，能够把容器编排在相应主机上，管理好镜像就可以了。目的就是不管编排框架怎么演变，我们的产品形态或者我们要实现的功能都是不变的，因为我们主体的功能和策略都在上层去做。还有一个是镜像，也是一个层次结构，不是单独的，这是架构，根据刚才的分解之后的架构。

刚才讲了产品规划我们做完了，产品设计也做完了，第三个是最重要的，是我们要把产品交付出去，交付服务也分为几个步骤，第一个是启动容器服务，但这是很难做的事情，为什么我们叫Caas，是把容器服务当做一个服务了，不是一个容器服务给更多人用，是为每个人或者每个租户建立自己的容器平台，他有自己的编排，有自己的编排体系，有自己的主机，有自己的权限，所以它的可用性是不会影响另外一个租户的，不会在容器管理平面上多个租户干扰，所以当用户在平安云的容器上启动服务，我们会有一系列的过程，当他把容器平台全新搭好。

第二个是创建容器环境，有了容器服务之后，你有你的编排，你可以存镜像，可以管理一些节点，有了这些基础东西，你还没有资源池，接下来就会启用这个环境，有资源池，为这个生产环境添加100台的主机，就可以在某个网站里把这100台的云主机创建好，再做初始化，初始化之后就在主机上安装一个跑起来，接下来你就可以像普通容器用户一样，创建你自己的应用，添加你的服务，管理你的容器。

第三个场景就是编排，因为用容器最简单的方式就是我在主机上命令好拉一个镜像出来，跑起来，这样作用很小，而且基本上要学习，对于要做到自动化交付的产品，我们肯定是要把编排作为最主要的功能，因为平安的交付环节里有架构设计和环境交付，在架构设计的产出，实际上就已经具备了编排的雏形，已经定义了每个组建的非功能性的要求和属性，把它作为一个编排的入口结合起来。

还有新建应用和服务，因为现在面向开发环境在做这个事情，基本上大家来的都知道，每个人来了以后新建一个应用，这个应用可以关联到管理体系的子系统，你创建好应用之后就可以添加，添加好之后构架了应用，应用构建完之后也会产生应用的编排文件。

接下来是服务管理，容器最擅长的是快速扩容，所以在服务里面，最开始就只有一个容器，可以把它变成两个三个，设置相应的策略，启停的策略和镜像的基本设置，所有的设置在这个服务管理。

最后是镜像仓库，这也是对运维团队来讲大家以前不是很关注的，但是我们希望把镜像仓库做成什么服务呢？就是做成普通的公有镜像和私有镜像的管理再加上商城的效果，平安的开发系统太多了，大的系统有一千多个，我们有很多产品是非常不错的，这些产品如果做得好的话，以前没有那么好的团队和方式销售出去，我们也可以组建一个销售团队，现在也有销售团队可以向潜在用户推我们平安的平台，要不要到你们公司落地一下，这当然很好，如果把商城就放在这里，这跟阿里的软件商城一样，把平安的软件改在上面，如果用户想要可以直接用这个商城或者镜像的方式直接交付出去，这是我们在服务交付这一块主要的环节。

这个图是现在已经实现的，刚才讲的那六个步骤，包括启用服务、镜像管理、应用管理编排所有都在这里。

讲到产品是怎么构建、怎么设计的，架构怎么构建的，也讲了交付的这几个环节，我们在不同环节交付不同的产品和功能。接下来讲从运维角度，我们怎么把这个平台，或者我们为了做好这个服务，维护好这个平台，我们需要做的事情。

第一就是监控，这个真的是最重要的，因为做运维的都知道，你不知道运维的情况，是没有办法做运维的，所以第一个是监控管理，这个管理我们也有一些基础功能和需要增加的功能，基础功能就是原来在主机层面就已经有一些监控的东西，之前是用了zabbix。

第二是日志管理，也是要多思考一个问题，因为之前运用层的日志基本上是落在主机上，这个主机也不会有太多的实力来贡献，之前是一个实力部在一台机上，有一个日志采集包括实时对分的采集，把日志手机到一个集中分析的平台上来做，在这个容器这个平台上，就要设置怎么把容器的日志像主机日志一样导出来，帮助用户审查、监控。我们也做了一个折中，把日志影射到主机上，这样把原有日志采集的平台就可以忽视容器的存在，直接把日志拿走。

第三个就是服务管理，在容器服务管理上我们也做了一些工作，我们实现了在前端直接登入主机，不需要登录容器内部，更不需要先登录主机再登录容器，这些工作也是为了运维的需要，我们希望容器的用户在查看日志也好，通过命令行，可以在前端界面统一来做。

最后是事件响应，容器遇到的问题就是技能和团队的问题，因为做这个平台大部分是开发人员，他们也没有时间，也没有太多的底层的系统管理经验，所以这一块目前也是安排了传统或者之前负责容器服务的团队来做这样的事件响应。在事件响应的做法上也有一点创新，等下会讲。

这是我们目前在容器平台上实现的，跟日志监控有关的几个功能，日志这一块，当你创建一个服务的时候，直接可以看到你容器启用的状况。第二个就是主机监控，在Iaas层面上已经有，所以大家看这个图是主机的图，对于容器平台用户来讲，也可以端到端的平台上看到主机的经营状态，也可以在右边的图，在容器平台上看到CPU流量这样一些指标。这是在监控上、功能设计上，首先把最重要的日志和监控做进去。

在运维这一块，虽然我们的团队目前比较小，大家还在学习的过程中，但是我们也可以做一些尝试，例如资源池的管理，包括底下存储资源和计算资源，我们有一个智能化运维的项目，我们希望用人工智能思想来解决运维的一些问题。做资源池的集中管理是第一步，第二步是做了运维的即时通讯和客服机器人，这个不是为了容器单独做的，但是我们也是在人工智能这一块在想，我们基本上是把一些常见的问题都放在智能服务机器人来做，刚刚上线，常规咨询类的问题和操作性的问题都可以由他来回答，不需要我们再单独找开发人员、开发团队解决这个问题。第三个是我们也在做还没有做完的，是我们解决用户调度或者系统架构的层次的功能，很多人吐槽用了云平台之后，都不知道底下是什么样，上午也有大会分享嘉宾说，用了云之后成本变高了，甚至也不知道透明问题，所以我们做的这个平台，我是做Iaas服务的产品，但是对于用户来讲，不会管你是Iaas还是什么，还是像以前一样，需要知道从底到底所有的关系，因为用户也需要知道，他的容器跑到你的主机上，这个主机跑到什么物理机上，怎么关联储存。如果用户能知道的话，尤其是企业内部的知道的话，会更安心，而且也会帮你发现一些这个平台团队所无法解决的问题，可以看到跟他可用性有关的信息之后，可以帮助提升整个系统的可用性。如果仅仅从这个层面去做的话，我们可能要把每个资源的使用率多加一个9才能实现最终的可能性，但是如果我们把一些目前底下资源的情况，给它延伸上去之后，可以让用户通过集群部署来解决可能性的问题。所以我们做了图形化展示的尝试，希望把这个关系能够让他一步一步按照图的方式展现出来。最后是监控分析，这个跟日志易的方法基本一样，这也不是一步可以完成的，先做收集和简单的分析。后面也希望集合我们的理念去做成自动发现和诊断处理的过程。

还有一些不足的地方，并且是我们为什么这个服务不是很满意的地方，有两块，一块是功能这一块，这个服务推出来之后，对大多数用户来讲还是非常陌生的，虽然我们做了一些简化，但是毕竟是一个新东西，而且现有的流程也是很健壮的，我们把一个新的服务、一个新的模式嵌入进去之后，肯定会对现有的流程带来影响。所以我们也做了很多的折中，打比方，我们在版本发布流程这一块，虽然在很多逻辑平台想做一个Paas平台，但是我们没有提这样一个Paas平台，我们很难从资源供给者的角度推动整个公司开发模式的变化，我们更多是希望通过一步一步的引导，我先启动一个资源的Caas的平台，让开发团队去发挥他们的能动性，如果开发团队想去实现Devops，可以跟我们探讨需要哪些API，所以流水线也是这样的模式，有开发部门的工具支撑团队和我们对接，他们想把开发做成什么样的流水线都没问题，我们成为流水线里面的环节，我想这也是很多公司，某一个运维开发团队想做一个Paas的时候都要遇到的问题，你如何让整个公司的其他部门的其他用户的习惯跟你结合。还有一个是应用商城，想法肯定是不错的，但是整个做起来肯定也很复杂，第一个产品化，我们很多软件都不是产品，要产品化。第二个是公司的知识产权、收费、商务，这些东西都还没有，目前仅仅是镜像和编排做在一起，可以支持用户把它的应用发布成公共的镜像。

还有流程的衔接也没有那么顺畅，因为这个容器跑起来之后，最简单的可以把它当做一个实力的盒子，这个盒子拿了之后需要跟各种各样的工具做对接，这些工作都还任重而道远，所以后面会当做一个改进的地方。

刚才从一个构建者的角度，我要把这个平台搭起来受制于哪些约束，搭建起来之后，怎么把它跟我们日常的监控、日志所有的平台对接起来，这是第一阶段的工作。第二阶段的工作是，我们怎么把它用起来，如果对用户来讲，对于我们的开发团队或者是版本部署团队，怎么用好这样一个平台呢？

下面就是讲容器服务应用与运维，站在他们角度不会管你的产品怎么架构的，他们主要是在交付和日常运行环节。在这样的情况下我也罗列了一下，对我们公司非基础架构来讲，先做需求分析，知道它的应用场景和设计的关联系统，或者选定了一个开发平台，在平台上都是java的开发平台，还有应用架构是怎么样的，会有一些组件，确定之后就涉及到服务规划，以前叫架构设计，架构设计定义好一个系统的拓扑和约束性的设计，为什么要服务规划，这也是跟容器有关的，在容器里面，每一个你想用到的容器，不是像以前的主机一样单纯的东西，会有相应的基础软件放在上面，这些就是用来做规划的单元。第二就是想好部署方案，因为我们有很多开发项目团队还在用主机上部署的，容器的知名度也很多人怀疑，我们可以让用户在主机上自主选择，在某一批主机上直接部署应用，另外一批主机上跑容器，所以架构师也会考虑，把应用的哪一部分放在容器上，哪一部分不放在容器上，不是一刀切，这也是解决他们的顾虑，把容器的优势和他部署的地方分开，如果哪些组件基本上需要快速扩展，可以用容器部署，后端的基本上没有太大变化，也比较稳定，你可以用主机来部署，主机可以选择虚拟机和物理机，都可以，这也是我们构建容器服务里比较有特色的地方，我们是可进可退的，你后面觉得不好或者某些版本的环境老是出现问题，对你的可靠性有影响，可以回到主机，或者你用主机部署的觉得太慢了，希望用容器部署，你可以直接把它提升到容器，会在相同的网络区内，可能仅仅是端口的变化。

这是服务规划，对架构师来讲原来只需要考虑拓扑，现在要考虑更多。

第三个是环境部署，对用户来讲，需要考虑怎么编排，甚至可能需要去写一个编排的文件，也需要考虑怎么集成，因为并不是所有的服务都由容器提供，需要考虑集成。最好的办法是尽量多的服务放在容器平台下，你可以用容器里面跑的，如果你的负载度高的话，但是你要集成在一起，这就需要把服务跟服务之间串接起来。

还有容器的配置信息，用了容器之后，我们希望没有变化，因为在逻辑这个层面上，这是非常合理的，基本上大家也都能理解，所以我们会把容器的配置信息的格式和主要的组件录入进去，仅仅在少数的没有镜像的，现在有了会增加一些字段关联起来。

还有运行监控，也是基于基础功能做起来，也是设置一些相应监控的策略，除了监控主机的信息，也可以去获得容器运行可靠性的信息。最后是版本发布，一个是配置管理，一个是扩容缩容，还有产品发布。

我们是基于VPC网络的，所以没有像传统的容器平台那样为了一个容器给一个IP，在一个大网里做物流，我们所有容器都做主机IP，这样容器的编排平台或者门户只需要管理好用户的端口就可以了，因为在我们公司或者某个区域内，几万个端口的容量是足够运行的。属于端口不够还有VPC，它解决了多子网的问题。

第二个背景是存储方案，我们为了解决扩容和迁移问题，我们用了网络存储，为了解决生产的可靠性问题，我们用了DNAS，不会宕机也不会丢失，很多的文件都会放在DNAS上，非重要的文件放在主机的磁盘上。

第三个是镜像库，大家都知道容器的 词里是秒级的创建，会把中央的镜像库按照镜像活跃度主动推送到各个镜像的镜像里面，在主机上再就近拉下来，刚开始可能会有预热的过程，时间长了之后，基本上主要的镜像都会在主机上有副本。

有了这个背景我们再讲配置管理，我们把公司的租户跟受益人对应起来，把容器应用和系统对应起来及把服务和集群对应起来，还是挺有特色的，不是每个容器都是这样构建的，我们做了这个对应关系之后，每个容器实例就是一个单位，但是不会很多，基本上是它的主机、名称这样一些信息，包括它的一些版本信息记录之后，大部分的信息在服务层面上，因为服务是用相同的配置、相同镜像解决的，包括端口也一样。下面这个图是我们在用的记录整个容器的应用和服务的配置信息。

扩容缩容这是所有用户跟我们讲，想用容器的时候说得最多的一句话，以前金融机构的系统基本上是没有波动的，一年到头基本上是均衡的，但是在某一天里，也会有一点变化，比如说典型双头峰的形态，早上会有高峰，大概在十点左右，下午在三点左右会有一个高峰，每天都是这样的M型，在平安里面对扩容要的最紧迫的就是保险的开门红，每年的元旦以后到春节期间都会有一个大的促销活动。还有在四五月份淡季也会做促销活动，还有在双十一双十二也会有金融行业产品的大促，所以他们都会到一个高峰。这个高峰也并不是很高，但是对于传统的部署还是会增加挑战，需要增加几倍，这就需要快速扩容。我们是这样做的，包括在互联网APP上做的，我们适用容器平台给他做扩容问题，把它的服务改造成比较标准的，需要在不同的点上消除它的状态，变成无状态，这样扩容的时候，基本上就没有太多的验证跟周边的操作，直接就扩上去了，这个平台也是这么做的，所以我们其实是有一些架构的要求，需要做更多的修改。包括负载也一样，能够远程修改的负载平台服务，否则也做不了，我们这一块也有一个负载的服务。这个功能就是运维日常会用到的功能，但是在容器里面就变成了基本功能。

我们提供两种版本发布的方式给到用户，一个是基于文件，这是最传统的，以前有版本发布的自动化平台，可以把每个应用所有的节点都记录下来，按照版本说明自动把应用包推到所有主机上执行一些远程的命令，做重启或者做替换，这个发布过程在容器下面是原封不动地接下来，我们不希望对用户的习惯带来太多的改变，就能够把服务推出去。所以每个容器服务会记录它的名称和IP，这个IP是主机IP，对部署团队没有什么变化，包括目录结构也是一样，所以在推送版本的时候可以跟原来一样，然后进行命令，把服务重启起来，这就实现了运维体系的兼容。

用户自己也可以上传文件，不用通过一整套的版本发布流程，自己有一个打包好的包上传上去，也可以在界面上上传文件，但是不是上传你的公众目录，可以做一个调整，你就可以把你的服务部署好，部署好之后，如果你长期运行，可以再转成镜像存起来，这是第一种基于文件的部署。第二是基于镜像的部署，这是比较理想化的情况，不是移交一个文件或者镜像，我们在一个专门的镜像制作的机器中制作一个镜像，再存到你的个人镜像库里，在基于镜像部署版本，所以我们比较推荐流水线自动打包的做法，才选择镜像发布。

这样就把从系统规划、系统需求收集、服务规划、部署日常、版本更新都讲到了，这就是我今天要讲的内容，谢谢大家。

观众提问

【提问】：陈老师你好，我想了解平安科技作为一家金融机构，是如何解决容器服务作为一项新技术的信任问题？是自下而上的推动还是自上而下的方式？第二个问题，我比较感兴趣你们在容器服务交互以后，有没有遇到过重大的危机、事故之类的？如何化解以及带来的影响。第三个问题，我想了解平安科技在容器服务这一块目前的交付比例，它的所占比重，谢谢老师。

【陈春润】：这是每个用户都跟我们讲的，在信任层面上不只是容器服务的信任问题，整个云对于传统的体系来讲都存在信任问题，解决信任问题的方法就是给用户多一个选择，比如刚才讲的，我们的容器服务并不是你只能上不能下的，我们是可进可退的，你可以把你部分非关键系统先上容器服务，你觉得不OK在没有太多的变化上，例如直接跑在容器运行的主机上，也可以支持部署你的应用，所以在容器和非容器这一块，我给它一个退路，它才敢上前迈一步尝试这个产品。第二个问题是交付的危机，肯定有的，而且踩坑还不少，我们已经投产的，之前搭建了一个容器平台，因为版本问题出现了一些比较严重的，某个容器当它更新应用版本之后，整个就crsh掉，需要重启服务器的情况也发生过。因为这条路始终要走的，我们只能硬着头皮往下走，现在通过升级docker版本，已经解决了，但是我觉得可能会有很多问题不断出现。第三个问题是比例，目前比例不大，因为物理机和虚拟机比例是一半一半，容器在这里面更小。

【提问】：谢谢，我们的问题跟基础架构都是很相似的，我们也是踩了很多坑。

【提问】：我知道平安应该是属于金融机构，你们对数据的耐用性应该是要求比较高，如果是在容器上，你们是怎么实现做数据备份？

【陈春润】：我们也是用了取巧的方法，首先在容器上不是用在数据库上的关键服务，容器上的数据大多数是无状态的，仅仅是应用层面的多实例部署，所以单个容器的数据本身不是太重要，真正重要的还是在数据库里，数据库目前还是用比较传统的方式来保持。在容器上的数据，刚才讲了我们的架构上用了共享存储，而且用的是高可用的共享存储保证数据的可靠性，我们想再看一看，我们先用一些新老结合的方式解决这个问题。（陈春润原创）

今天我会从三个方面介绍整个内容，第一个是背景，这个平台是干什么的，有些什么样的约束，我们是怎么把它做出来的。第二是我们在构建一个平台的时候想怎么运维好它，否则在可靠性方面就很难做到理性的状况。同样的道理，虽然我们是做产品，做运维的产品，但是这个运维的产品本身也会运维，也会交给其他的团队做运维，也是整个开发团队眼中的运维团队所做的事情，所以我会把这几个方面糅合到一起，我会讲平安云在构建的时候如何考虑运维的，把它推给用户的时候，是怎么把它跟运维的过程结合到一起，是这样一个内容。

这个图是给大家认识一下平安云在解决什么问题，这个问题很好回答，目前市面上大家做的尤其是金融企业做的无非两种，一种是基础设施的云服务，一种是各种各样的Paas服务，每个企业的规模不一样，构建的难度和复杂度也不一样，因为平安集团有几十家专业公司做一个内部客户，所以我们在构建一个云的时候，不是一个简单的私有云，是一个企业内部的公有云，对集团其他专业公司来讲我们是一个公有云，但是对集团外的客户来讲是私有云。所以我们在构建的时候，从产品形态、交付的模式、收费的模式基本上会参照公有云的做法，我们第一个学习对象就是亚马逊，包括我们所有产品的购买过程和我们产品的属性，第一个老师是亚马逊，第二个老师是阿里云，我们也会参照他们的做法去做，参照他们做法做出来的产品，第一个就是云主机，现在已经有上万台的云主机在运行，第二个是云磁盘，这是云主机的扩充，还有VPC的服务，也是在私有云比较难的地方，构建内部虚拟的私有云。还有对象存储，数据库服务团队，也在努力把传统的数据库做一些云化的工作，这些事情不是一天就能做成的，我们从2013年到现在，虽然我们花了很多的人力物力，包括各个兄弟单位一起支持，但是整个产品还是成长期，还没有完全成熟，但是已经在企业内部有一些成果。

紧接着就讲容器服务，容器在这几年有很大的热度，每个企业都在尝试，开发经理和CTO们也在想我们公司能不能用容器来解决包括架构的问题、交付的问题，平安也一样，我们也有很多人提出平安容器服务。之前有好多人在做平安容器服务，也在解决具体的问题，效果也都还OK，在平安云的框架下我们做的容器服务也有一个老师，还是亚马逊的容器服务。为什么我们想做这样一个容器服务，而不是通常讲的K8S模式呢？跟亚马逊遇到的问题是一样的，我们已经有一个Iaas的问题，这个解决了存储和网络的问题，我们现在要解决的是容器问题，现在基本上是默认Iaas平台上，我们会优先放在Iaas平台上，这样就有了物理机、虚拟机加容器这样的计算三剑客。这三剑客解决各类金融企业里面对IT基础设施的要求，因为我们有很多包括保险还有银行、证券，所有这些不同的业务模块对计算的要求是完全不一样的，所以我们提出这样一个方式，我们不只是提供虚拟机、物理机，还有提供容器服务，容器服务的目的就是为了解决用户快速交付、做微服务的支撑。

我们的容器服务也会有自己的特色，我觉得每一个云基本上不是公有云还是私有云，没有一个公司做的云和其他公司一样，我们也不会特别强调我们的编排怎么做的，我们支持多么复杂的基础设施，没有这样的场景，我们的场景很简单，就是把它归结为两块，一个是我做自助服务，做好之后开发团队想用这个容器来做应用，可以自主的完成，就像亚马逊穿一个ESS一样，拿到这个容器一样，可以很高级的用它也可以很低级的用它，都没关系，这是第一块。

第二块是我们也想支持流水线，刚才跟其他同事也交流了，我们同事在做一个开发过程的优化项目，就是希望通过流水线来实现整个开发环节的自动化，我们在环境交付这一块就是想实现一键交付，这个一键交付是开发人员直接去交付一整套的环境，点一个键，提交一个版本，后台编译、打包、验证所有搭建的有效性，一步到位。在没有完全实现广义上的一键交付，但是在某些特定场景，我们也实现了一键交付，正在向不同的开发团队推广，这是我们做容器平台要支持的第二个场景，就是支持开发到运维流程的打通，这是我们给容器服务定义的两个最大的场景。

接到这个题目的时候我一直在想，这是运维的大会，我们团队里面大部分都是开发人员，开发各种各样的云产品。不知道大家是否认可一个观点，运维这个团队最大的价值就是交付，就是把你的服务、把你的产品，以可靠的、有效的方式快速交付出去，其实我们做云产品也一样，我做云网络的产品，就是要把云网络交付出去，这个交付就隐含着从无到有做出来和高效的交给用户，还要持续保证服务的可用性，因此可以说，云平台团队除了销售人员之外，其他人员都可以认为是运维人员或者交付人员，因为他们都是在做相互相同的目标。因此我们在构建的时候，我们也在学习SRE的理念，但是我们没有这样一个岗位，我们是对所有产品岗位负责人是这样要求的，你产品设计的时候，必须从产品的生命周期，创建、规划、构建、交付、运维的几个环节来把运维的事情考虑进去。

刚才那两个是大的场景，做自助服务和流水线，从产品的形态和用户在用的场景，我们做了简化，包括一些共有的容器云也好，功能很多，大家会把整个开发的过程全部都考虑进去了。在平安做容器服务还是站在运维角度看的，所以我们把客户的场景做了几个归类，第一个是我们是多租户管理，所以首先会有租户管理，这个租户是针对整个Iaas平台也好，都会涉及到租户的管理。有租户的容器云和没有租户的容器云，或者构建多租户的Iaas的容器云有个特点，我们是要求租户主动地去启用容器服务，不是每个租户在平安云上一创建，就用到容器服务的，不是这样的，我们认为容器服务在目前阶段还是高级产品，也不是一个刚需产品，是一个需要用户主动去申请的服务。申请的过程在我们这边设计是管理员可以划定它的区域，把Iaas的资源池作为一个环境，在这个环境下构建一个独有容器的平台，跟一般做法不一样，我们并没有在一个大的容器平台上划租户，而是在Iaas平台上划租户，Iaas平台给容器平台，这样单租户就OK了，因为底下资源已经划分了。好处就是这个容器的用户可以有自己独立的网络和独立的资源池，不需要跟别的用户混在一起。等下也会看到这种方式给别的平台，给运维也带来了好处。

第二是环境管理，我有一个租户建了一个容器平台之后，他是需要划分它的环境，至少会有开发环境和生产环境，他可以去创建这个环境，每个环境又有独立的资源池和网络，也可以在这个环境设置相应的权限。

第三个是应用管理，这个应用管理对应了企业内部的一些应用或者系统，在平安叫做子系统的管理，它需要部署，这里面就是一个应用，在云平台或者容器服务里就是一个应用，这个应用需要一个人来统筹管理，也是对整个编排来讲，一个应用也是一个编排的单位，我也搭一套一个企业的网站或者门户网站，所有这些都会在容器的应用管理里去设置。

应用的下一层就是服务，每一个集群都对应了一个服务，服务下面就是容器，相应有多个容器。还有一个容器特有的就是镜像管理，也是跟非容器的做法管理不一样。这是我们把它对接为五个，基本上把这五个步骤放在类似于一条生产线上，你可以一步一步往前做，不同角色可以看到不同功能，完成你自己的那一块，具备你相应的权限。

我们做了这样一个产品规划之后，接下来就要落地实现，实现的时候也会把刚才说的一些架构约束带进来，例如容器服务要同时支持物理机和虚拟机，也支持动态的添加资源，我不是买二十台服务器在那里给大家用，我们是把容器的资源池当做动态的资源池，就是利用Iaas的弹性动态来使用，而且我们需要在多个中心，如果用户想多中心部署，我们就在多中心给他创建这样一个容器服务。我们还要解决一些容器搞不定的问题，比如容器服务也好主机也好，肯定会跑到某个网络区里，跟网络区是有边界的，边界的防火墙不在容器范围内，包括还有一些运维系统也不在这个范围内，还有一些外围的数据库服务也不在这个范围内。这些服务也需要统筹进来，所以我们也有一个编排的框架，把容器当成一个产品，如果需要搭建容器的，我就调容器的接口，如果需要开墙我就调网络服务的接口。

因为容器平台做出来之后是要投产的，不投产平台就没有意义了，所以我们在创建这个平台的时候走得比较慢，我们一定要让它能够生产投产的规格，才能让它投产，所以我们兼容原有的ITIL平台。还有一个就是容器的网络，之前有一个容器网络做得不是很好，实际上我们绕过了这个问题，我们用最简单的网络方案来实现，借用底层的网络来做连通性的支持。这个图就展现了我们在多中心多租户的架构上，我们是怎么构建的。原理上很简单，因为多中心已经是多平台，通过一个集中的入口，对所有的平台进行管控，所以我们自己做了一个容器服务，底下对接一个编排的框架，来共同完成这样一个服务。底下有一个图，这个是租户环境，这个环境可以有多个主机，底下的编排就会把容器对应起来，也会跟镜像对应起来。

这是把其中的一块抽出来，中间是一个Caas的Portal，会有自己的数据库，这里写的平安云是平安的Iaas的接口，还有我们公司的资源管理平台，用来做资源的记录和查询，还有Ansible是做远程执行的，执行一些脚本和处理化的动作，还有一些远程登录的代理、镜像的拉取，这些动作都是通过Ansible去控制。中间我们是用registry做编排，因为我们做这个平台体系上已经够复杂了，所以编码这一块我们希望更简单，不需要引入更多的概念，大多数都是围绕刚才的产品定义和场景完成，只要这个编排框架够稳定够轻量，能够把容器编排在相应主机上，管理好镜像就可以了。目的就是不管编排框架怎么演变，我们的产品形态或者我们要实现的功能都是不变的，因为我们主体的功能和策略都在上层去做。还有一个是镜像，也是一个层次结构，不是单独的，这是架构，根据刚才的分解之后的架构。

刚才讲了产品规划我们做完了，产品设计也做完了，第三个是最重要的，是我们要把产品交付出去，交付服务也分为几个步骤，第一个是启动容器服务，但这是很难做的事情，为什么我们叫Caas，是把容器服务当做一个服务了，不是一个容器服务给更多人用，是为每个人或者每个租户建立自己的容器平台，他有自己的编排，有自己的编排体系，有自己的主机，有自己的权限，所以它的可用性是不会影响另外一个租户的，不会在容器管理平面上多个租户干扰，所以当用户在平安云的容器上启动服务，我们会有一系列的过程，当他把容器平台全新搭好。

第二个是创建容器环境，有了容器服务之后，你有你的编排，你可以存镜像，可以管理一些节点，有了这些基础东西，你还没有资源池，接下来就会启用这个环境，有资源池，为这个生产环境添加100台的主机，就可以在某个网站里把这100台的云主机创建好，再做初始化，初始化之后就在主机上安装一个跑起来，接下来你就可以像普通容器用户一样，创建你自己的应用，添加你的服务，管理你的容器。

第三个场景就是编排，因为用容器最简单的方式就是我在主机上命令好拉一个镜像出来，跑起来，这样作用很小，而且基本上要学习，对于要做到自动化交付的产品，我们肯定是要把编排作为最主要的功能，因为平安的交付环节里有架构设计和环境交付，在架构设计的产出，实际上就已经具备了编排的雏形，已经定义了每个组建的非功能性的要求和属性，把它作为一个编排的入口结合起来。

还有新建应用和服务，因为现在面向开发环境在做这个事情，基本上大家来的都知道，每个人来了以后新建一个应用，这个应用可以关联到管理体系的子系统，你创建好应用之后就可以添加，添加好之后构架了应用，应用构建完之后也会产生应用的编排文件。

接下来是服务管理，容器最擅长的是快速扩容，所以在服务里面，最开始就只有一个容器，可以把它变成两个三个，设置相应的策略，启停的策略和镜像的基本设置，所有的设置在这个服务管理。

最后是镜像仓库，这也是对运维团队来讲大家以前不是很关注的，但是我们希望把镜像仓库做成什么服务呢？就是做成普通的公有镜像和私有镜像的管理再加上商城的效果，平安的开发系统太多了，大的系统有一千多个，我们有很多产品是非常不错的，这些产品如果做得好的话，以前没有那么好的团队和方式销售出去，我们也可以组建一个销售团队，现在也有销售团队可以向潜在用户推我们平安的平台，要不要到你们公司落地一下，这当然很好，如果把商城就放在这里，这跟阿里的软件商城一样，把平安的软件改在上面，如果用户想要可以直接用这个商城或者镜像的方式直接交付出去，这是我们在服务交付这一块主要的环节。

这个图是现在已经实现的，刚才讲的那六个步骤，包括启用服务、镜像管理、应用管理编排所有都在这里。

讲到产品是怎么构建、怎么设计的，架构怎么构建的，也讲了交付的这几个环节，我们在不同环节交付不同的产品和功能。接下来讲从运维角度，我们怎么把这个平台，或者我们为了做好这个服务，维护好这个平台，我们需要做的事情。

第一就是监控，这个真的是最重要的，因为做运维的都知道，你不知道运维的情况，是没有办法做运维的，所以第一个是监控管理，这个管理我们也有一些基础功能和需要增加的功能，基础功能就是原来在主机层面就已经有一些监控的东西，之前是用了zabbix。

第二是日志管理，也是要多思考一个问题，因为之前运用层的日志基本上是落在主机上，这个主机也不会有太多的实力来贡献，之前是一个实力部在一台机上，有一个日志采集包括实时对分的采集，把日志手机到一个集中分析的平台上来做，在这个容器这个平台上，就要设置怎么把容器的日志像主机日志一样导出来，帮助用户审查、监控。我们也做了一个折中，把日志影射到主机上，这样把原有日志采集的平台就可以忽视容器的存在，直接把日志拿走。

第三个就是服务管理，在容器服务管理上我们也做了一些工作，我们实现了在前端直接登入主机，不需要登录容器内部，更不需要先登录主机再登录容器，这些工作也是为了运维的需要，我们希望容器的用户在查看日志也好，通过命令行，可以在前端界面统一来做。

最后是事件响应，容器遇到的问题就是技能和团队的问题，因为做这个平台大部分是开发人员，他们也没有时间，也没有太多的底层的系统管理经验，所以这一块目前也是安排了传统或者之前负责容器服务的团队来做这样的事件响应。在事件响应的做法上也有一点创新，等下会讲。

这是我们目前在容器平台上实现的，跟日志监控有关的几个功能，日志这一块，当你创建一个服务的时候，直接可以看到你容器启用的状况。第二个就是主机监控，在Iaas层面上已经有，所以大家看这个图是主机的图，对于容器平台用户来讲，也可以端到端的平台上看到主机的经营状态，也可以在右边的图，在容器平台上看到CPU流量这样一些指标。这是在监控上、功能设计上，首先把最重要的日志和监控做进去。

在运维这一块，虽然我们的团队目前比较小，大家还在学习的过程中，但是我们也可以做一些尝试，例如资源池的管理，包括底下存储资源和计算资源，我们有一个智能化运维的项目，我们希望用人工智能思想来解决运维的一些问题。做资源池的集中管理是第一步，第二步是做了运维的即时通讯和客服机器人，这个不是为了容器单独做的，但是我们也是在人工智能这一块在想，我们基本上是把一些常见的问题都放在智能服务机器人来做，刚刚上线，常规咨询类的问题和操作性的问题都可以由他来回答，不需要我们再单独找开发人员、开发团队解决这个问题。第三个是我们也在做还没有做完的，是我们解决用户调度或者系统架构的层次的功能，很多人吐槽用了云平台之后，都不知道底下是什么样，上午也有大会分享嘉宾说，用了云之后成本变高了，甚至也不知道透明问题，所以我们做的这个平台，我是做Iaas服务的产品，但是对于用户来讲，不会管你是Iaas还是什么，还是像以前一样，需要知道从底到底所有的关系，因为用户也需要知道，他的容器跑到你的主机上，这个主机跑到什么物理机上，怎么关联储存。如果用户能知道的话，尤其是企业内部的知道的话，会更安心，而且也会帮你发现一些这个平台团队所无法解决的问题，可以看到跟他可用性有关的信息之后，可以帮助提升整个系统的可用性。如果仅仅从这个层面去做的话，我们可能要把每个资源的使用率多加一个9才能实现最终的可能性，但是如果我们把一些目前底下资源的情况，给它延伸上去之后，可以让用户通过集群部署来解决可能性的问题。所以我们做了图形化展示的尝试，希望把这个关系能够让他一步一步按照图的方式展现出来。最后是监控分析，这个跟日志易的方法基本一样，这也不是一步可以完成的，先做收集和简单的分析。后面也希望集合我们的理念去做成自动发现和诊断处理的过程。

还有一些不足的地方，并且是我们为什么这个服务不是很满意的地方，有两块，一块是功能这一块，这个服务推出来之后，对大多数用户来讲还是非常陌生的，虽然我们做了一些简化，但是毕竟是一个新东西，而且现有的流程也是很健壮的，我们把一个新的服务、一个新的模式嵌入进去之后，肯定会对现有的流程带来影响。所以我们也做了很多的折中，打比方，我们在版本发布流程这一块，虽然在很多逻辑平台想做一个Paas平台，但是我们没有提这样一个Paas平台，我们很难从资源供给者的角度推动整个公司开发模式的变化，我们更多是希望通过一步一步的引导，我先启动一个资源的Caas的平台，让开发团队去发挥他们的能动性，如果开发团队想去实现Devops，可以跟我们探讨需要哪些API，所以流水线也是这样的模式，有开发部门的工具支撑团队和我们对接，他们想把开发做成什么样的流水线都没问题，我们成为流水线里面的环节，我想这也是很多公司，某一个运维开发团队想做一个Paas的时候都要遇到的问题，你如何让整个公司的其他部门的其他用户的习惯跟你结合。还有一个是应用商城，想法肯定是不错的，但是整个做起来肯定也很复杂，第一个产品化，我们很多软件都不是产品，要产品化。第二个是公司的知识产权、收费、商务，这些东西都还没有，目前仅仅是镜像和编排做在一起，可以支持用户把它的应用发布成公共的镜像。

还有流程的衔接也没有那么顺畅，因为这个容器跑起来之后，最简单的可以把它当做一个实力的盒子，这个盒子拿了之后需要跟各种各样的工具做对接，这些工作都还任重而道远，所以后面会当做一个改进的地方。

刚才从一个构建者的角度，我要把这个平台搭起来受制于哪些约束，搭建起来之后，怎么把它跟我们日常的监控、日志所有的平台对接起来，这是第一阶段的工作。第二阶段的工作是，我们怎么把它用起来，如果对用户来讲，对于我们的开发团队或者是版本部署团队，怎么用好这样一个平台呢？

下面就是讲容器服务应用与运维，站在他们角度不会管你的产品怎么架构的，他们主要是在交付和日常运行环节。在这样的情况下我也罗列了一下，对我们公司非基础架构来讲，先做需求分析，知道它的应用场景和设计的关联系统，或者选定了一个开发平台，在平台上都是java的开发平台，还有应用架构是怎么样的，会有一些组件，确定之后就涉及到服务规划，以前叫架构设计，架构设计定义好一个系统的拓扑和约束性的设计，为什么要服务规划，这也是跟容器有关的，在容器里面，每一个你想用到的容器，不是像以前的主机一样单纯的东西，会有相应的基础软件放在上面，这些就是用来做规划的单元。第二就是想好部署方案，因为我们有很多开发项目团队还在用主机上部署的，容器的知名度也很多人怀疑，我们可以让用户在主机上自主选择，在某一批主机上直接部署应用，另外一批主机上跑容器，所以架构师也会考虑，把应用的哪一部分放在容器上，哪一部分不放在容器上，不是一刀切，这也是解决他们的顾虑，把容器的优势和他部署的地方分开，如果哪些组件基本上需要快速扩展，可以用容器部署，后端的基本上没有太大变化，也比较稳定，你可以用主机来部署，主机可以选择虚拟机和物理机，都可以，这也是我们构建容器服务里比较有特色的地方，我们是可进可退的，你后面觉得不好或者某些版本的环境老是出现问题，对你的可靠性有影响，可以回到主机，或者你用主机部署的觉得太慢了，希望用容器部署，你可以直接把它提升到容器，会在相同的网络区内，可能仅仅是端口的变化。

这是服务规划，对架构师来讲原来只需要考虑拓扑，现在要考虑更多。

第三个是环境部署，对用户来讲，需要考虑怎么编排，甚至可能需要去写一个编排的文件，也需要考虑怎么集成，因为并不是所有的服务都由容器提供，需要考虑集成。最好的办法是尽量多的服务放在容器平台下，你可以用容器里面跑的，如果你的负载度高的话，但是你要集成在一起，这就需要把服务跟服务之间串接起来。

还有容器的配置信息，用了容器之后，我们希望没有变化，因为在逻辑这个层面上，这是非常合理的，基本上大家也都能理解，所以我们会把容器的配置信息的格式和主要的组件录入进去，仅仅在少数的没有镜像的，现在有了会增加一些字段关联起来。

还有运行监控，也是基于基础功能做起来，也是设置一些相应监控的策略，除了监控主机的信息，也可以去获得容器运行可靠性的信息。最后是版本发布，一个是配置管理，一个是扩容缩容，还有产品发布。

我们是基于VPC网络的，所以没有像传统的容器平台那样为了一个容器给一个IP，在一个大网里做物流，我们所有容器都做主机IP，这样容器的编排平台或者门户只需要管理好用户的端口就可以了，因为在我们公司或者某个区域内，几万个端口的容量是足够运行的。属于端口不够还有VPC，它解决了多子网的问题。

第二个背景是存储方案，我们为了解决扩容和迁移问题，我们用了网络存储，为了解决生产的可靠性问题，我们用了DNAS，不会宕机也不会丢失，很多的文件都会放在DNAS上，非重要的文件放在主机的磁盘上。

第三个是镜像库，大家都知道容器的 词里是秒级的创建，会把中央的镜像库按照镜像活跃度主动推送到各个镜像的镜像里面，在主机上再就近拉下来，刚开始可能会有预热的过程，时间长了之后，基本上主要的镜像都会在主机上有副本。

有了这个背景我们再讲配置管理，我们把公司的租户跟受益人对应起来，把容器应用和系统对应起来及把服务和集群对应起来，还是挺有特色的，不是每个容器都是这样构建的，我们做了这个对应关系之后，每个容器实例就是一个单位，但是不会很多，基本上是它的主机、名称这样一些信息，包括它的一些版本信息记录之后，大部分的信息在服务层面上，因为服务是用相同的配置、相同镜像解决的，包括端口也一样。下面这个图是我们在用的记录整个容器的应用和服务的配置信息。

扩容缩容这是所有用户跟我们讲，想用容器的时候说得最多的一句话，以前金融机构的系统基本上是没有波动的，一年到头基本上是均衡的，但是在某一天里，也会有一点变化，比如说典型双头峰的形态，早上会有高峰，大概在十点左右，下午在三点左右会有一个高峰，每天都是这样的M型，在平安里面对扩容要的最紧迫的就是保险的开门红，每年的元旦以后到春节期间都会有一个大的促销活动。还有在四五月份淡季也会做促销活动，还有在双十一双十二也会有金融行业产品的大促，所以他们都会到一个高峰。这个高峰也并不是很高，但是对于传统的部署还是会增加挑战，需要增加几倍，这就需要快速扩容。我们是这样做的，包括在互联网APP上做的，我们适用容器平台给他做扩容问题，把它的服务改造成比较标准的，需要在不同的点上消除它的状态，变成无状态，这样扩容的时候，基本上就没有太多的验证跟周边的操作，直接就扩上去了，这个平台也是这么做的，所以我们其实是有一些架构的要求，需要做更多的修改。包括负载也一样，能够远程修改的负载平台服务，否则也做不了，我们这一块也有一个负载的服务。这个功能就是运维日常会用到的功能，但是在容器里面就变成了基本功能。

我们提供两种版本发布的方式给到用户，一个是基于文件，这是最传统的，以前有版本发布的自动化平台，可以把每个应用所有的节点都记录下来，按照版本说明自动把应用包推到所有主机上执行一些远程的命令，做重启或者做替换，这个发布过程在容器下面是原封不动地接下来，我们不希望对用户的习惯带来太多的改变，就能够把服务推出去。所以每个容器服务会记录它的名称和IP，这个IP是主机IP，对部署团队没有什么变化，包括目录结构也是一样，所以在推送版本的时候可以跟原来一样，然后进行命令，把服务重启起来，这就实现了运维体系的兼容。

用户自己也可以上传文件，不用通过一整套的版本发布流程，自己有一个打包好的包上传上去，也可以在界面上上传文件，但是不是上传你的公众目录，可以做一个调整，你就可以把你的服务部署好，部署好之后，如果你长期运行，可以再转成镜像存起来，这是第一种基于文件的部署。第二是基于镜像的部署，这是比较理想化的情况，不是移交一个文件或者镜像，我们在一个专门的镜像制作的机器中制作一个镜像，再存到你的个人镜像库里，在基于镜像部署版本，所以我们比较推荐流水线自动打包的做法，才选择镜像发布。

这样就把从系统规划、系统需求收集、服务规划、部署日常、版本更新都讲到了，这就是我今天要讲的内容，谢谢大家。

观众提问

【提问】：陈老师你好，我想了解平安科技作为一家金融机构，是如何解决容器服务作为一项新技术的信任问题？是自下而上的推动还是自上而下的方式？第二个问题，我比较感兴趣你们在容器服务交互以后，有没有遇到过重大的危机、事故之类的？如何化解以及带来的影响。第三个问题，我想了解平安科技在容器服务这一块目前的交付比例，它的所占比重，谢谢老师。

【陈春润】：这是每个用户都跟我们讲的，在信任层面上不只是容器服务的信任问题，整个云对于传统的体系来讲都存在信任问题，解决信任问题的方法就是给用户多一个选择，比如刚才讲的，我们的容器服务并不是你只能上不能下的，我们是可进可退的，你可以把你部分非关键系统先上容器服务，你觉得不OK在没有太多的变化上，例如直接跑在容器运行的主机上，也可以支持部署你的应用，所以在容器和非容器这一块，我给它一个退路，它才敢上前迈一步尝试这个产品。第二个问题是交付的危机，肯定有的，而且踩坑还不少，我们已经投产的，之前搭建了一个容器平台，因为版本问题出现了一些比较严重的，某个容器当它更新应用版本之后，整个就crsh掉，需要重启服务器的情况也发生过。因为这条路始终要走的，我们只能硬着头皮往下走，现在通过升级docker版本，已经解决了，但是我觉得可能会有很多问题不断出现。第三个问题是比例，目前比例不大，因为物理机和虚拟机比例是一半一半，容器在这里面更小。

【提问】：谢谢，我们的问题跟基础架构都是很相似的，我们也是踩了很多坑。

【提问】：我知道平安应该是属于金融机构，你们对数据的耐用性应该是要求比较高，如果是在容器上，你们是怎么实现做数据备份？

【陈春润】：我们也是用了取巧的方法，首先在容器上不是用在数据库上的关键服务，容器上的数据大多数是无状态的，仅仅是应用层面的多实例部署，所以单个容器的数据本身不是太重要，真正重要的还是在数据库里，数据库目前还是用比较传统的方式来保持。在容器上的数据，刚才讲了我们的架构上用了共享存储，而且用的是高可用的共享存储保证数据的可靠性，我们想再看一看，我们先用一些新老结合的方式解决这个问题。（陈春润原创）