支持100+业务线、累计发布17万次|宜信容器云的A点与B点（分享实录）

宜信公司从2018年初开始建设容器云，至今，容器云的经常使用基本功能已经趋于完善，主要包括服务管理、应用商店、Nginx配置、存储管理、CI/CD、权限管理等，支持100+业务线、3500+的容器运行。伴随公司去VMware以及DevOps、微服务不断推动的背景，后续还会有更多的业务迁移到容器云上，容器云在宜信发挥着愈来愈重要的做用。本次分享主要介绍宜信容器云平台的背景、主要功能、落地实践及将来规划。

1、宜信容器云平台背景

宜信容器云平台的建设背景主要包括：

• 提升资源利用率。容器云建设以前，每台物理机上平均运行的虚拟机大概是20个，使用了容器云以后，每台物理机上平均运行的容器数达到50个；以前的CPU利用率大概在10%左右，迁移到容器云后，CPU利用率提升到20%以上，整个资源利用率获得了极大的提高。
• 提高服务可靠性。传统的虚拟机运维方式下，当机器宕机或系统故障时，须要运维手动重启虚拟机和服务，整个过程最快须要几十分钟到几个小时才能解决；使用容器云后，经过健康检查的方式，一旦发现有问题就自动重启恢复服务，能够达到分钟级甚至秒级的恢复。
• 节约成本。经过容器云提升了资源利用率，同时也节约了成本。公司每一年会采购一些商业化软件，如虚拟化软件、商业存储等，费用动辄千万。咱们基于开源技术自研一套容器解决方案，每一年为公司节省上千万的软件采购和维保费用。
• 弹性伸缩。咱们公司每一年都会组织财富峰会，在这里有一个很经典的场景：秒杀，秒杀场景须要很快扩展业务的计算能力。为了快速应对互联网突发流量，如上述的财富峰会、APP线上活动，咱们为服务设置了自动伸缩的策略：当CPU利用率达到60%的时候，自动作容器扩容，应对突发的业务流量，提升响应速度；活动事后，自动回收资源，提升资源的利用率。

• DevOps整合。DevOps和敏捷开发的理论已经提出不少年了，为何DevOps一直没有获得很好的推动和实践呢？由于缺少一种工具把Dev和Ops联系起来，而容器的诞生很好地解决了这个问题。开发人员在开发完代码并完成测试之后，能够拿着测试的产物直接到生产环境部署上线，而部署的问题能够直接反馈给开发，造成闭环。也就是说，经过容器的方式，能够实现一次构建屡次运行。因而可知，经过容器的方式实现DevOps是最佳的方案，企业亟需一套成熟的平台帮助开发和运维人员保持各个环境的一致性和快速发布、快速回滚。

在上述背景下，咱们结合宜信的业务场景开发建设宜信容器云平台。

2、宜信容器云平台主要功能

宜信容器云平台通过一年多时间的建设和开发，基本的经常使用功能已经具有。如图所示。

上图左侧是宜信容器云平台的主要功能，包括：服务管理、CI/CD、代理出口、配置管理、文件存储、告警策略、镜像管理、用户管理、权限管理、系统管理等。
右侧是一个服务管理的界面，从中能够看到服务列表、服务名称、服务状态及当前服务数量，还有当前镜像版本及更新时间。

2.1 宜信容器云平台架构

上图所示为整个容器云平台的架构图，在各类开源组件（包括Harbor镜像仓库、Kubernetes容器管理、Prometheus 监控、Jenkins构建、Nginx流量转发和Docker容器虚拟化等）的基础之上，咱们自研开发了5个核心模块。

• Cluster-mgr，负责多个Kubernetes集群之间的管理和调度，在一个Kubernetes集群出现问题后，将该集群的容器迁移到其余可用的Kubernetes集群，而且负责资源的计量。
• Ipaas，负责对接各类资源，如调用Kubernetes API建立容器、对接Ceph建立存储、对接Harbor获取镜像等。前端页面经过Ipaas获取容器相关的新闻数据、监控指标等。
• Codeflow，负责代码构建。经过对接Jenkins实现代码编译、打包镜像以及服务的滚动升级等工做。
• Nginx-mgr，一个对接多个Nginx集群的管理系统，负责将用户在页面配置的规则转成Nginx配置，并下发到对应的Nginx集群。
• Dophinsync，和公司CMDB系统打通，从CMDB系统同步公司全部项目和服务的相关数据和信息。

最上面是对用户提供的web-portal页面，一个用户自助的终端。

本次分享的标题是《宜信容器云的A点与B点》，之因此称为A点和B点，这与咱们的公司文化有关，咱们以“A点”代指如今已经作到的事情，以“B点”代指将来或者下个阶段要作的事情。

目前整个宜信容器云平台已经完成了大部分主要功能点的开发，这部分已经实现的功能即为“A点”，包括服务管理、应用商店、域名管理、CI/CD、镜像管理、文件存储、监控告警、定时任务、配置管理等。后续还有部分功能须要添加和完善，即为“B点”，主要包括：对象存储、大数据容器云、全面日志收集、自定义指标伸缩、智能调度和混部、多集群管理、安全隔离、站点监控等，

2.2 宜信容器云功能模块

上图为宜信容器云平台的总体功能图，其中蓝色表明已经完成的功能、黄色表明须要优化和改善的功能。

整个系统从资源管理的角度来看：

• 底层是硬件层面的计算、存储、网络；
• 其上是资源管理层，负责容器、存储、域名、镜像、集群管理；
• 往上是中间件层，包括Kafka、MySQL等中间件服务；
• 再往上是应用层，提供给用户使用的终端；
• 两侧分别是CI/CD的构建流程和安全认证相关的功能组件。

下面将经过页面截图的方式，详细介绍容器云的主要功能点。

2.2.1 主要功能点——服务管理

上图是服务管理页面的截图，逐一介绍各个功能。

• 容器列表。上侧的菜单是服务管理的列表，进入到某一个服务管理，就能够对服务进行具体操做，包括基本配置、升级、扩缩容、域名管理、同步生产环境等。
• 历史容器。 服务升级或故障迁移以后，容器的名称、IP地址等会发生变化，历史容器的功能是记录一个服务下面容器的变化状况，方便咱们追踪容器的变化，追溯性能监控数据，进行故障定位。
• 日志下载。能够经过页面方式直接下载用户日志数据。终端信息与前面的日志输出是有区别的。前面的日志下载是应用把日志保存到容器里的某一个指定路径下；终端信息是容器标准输出的日志，Event信息里主要记录容器的状态信息，好比何时拉取镜像、何时启动服务等。Webshell主要提供容器登陆，能够像SSH同样经过页面的方式登陆到终端。
• 非root登陆。为了保持容器生产环境的安全，咱们以非root的方式登陆容器控制台，避免误删数据。
• Debug容器实现，经过启动一个工具容器，挂载到业务容器里，共享网络、进程等数据。传统的方式但愿容器镜像尽量小、安装的软件尽量少，这样启动更快、安全性更高，但因为容器自己只安装了程序必要的依赖，致使排查文件困难。为了解决这个问题，咱们基于开源技术开发了debug容器功能：debug容器挂载到业务容器中，共享业务容器的网络内存和主机相关的各类信息，这样一来，就至关于在业务容器中执行了debug命令，既方便运维和业务人员排查故障，保障了容器的快速安全，又为业务提供了一种更好的debug方式。安装的客户端如Reids客户端、MySQL客户端、Tcpdump等。
• 容器性能监控，包括CPU、内存、网络IO、磁盘IO等监控指标。
• 审计，用户全部操做命令都会经过审计工具进行审核。
• 摘除实例，主要是针对一些异常容器的故障定位，将流量从负载均衡上摘除。
• 销毁功能，当容器须要重建时会用到销毁功能。

除了上文介绍的一排容器按钮之外，还有一些针对服务的相关操做，好比服务的基本配置：环境变量、域名解析、健康检查，服务的升级，替换镜像、扩缩容等操做。

2.2.2 主要功能点——应用商店

不少业务场景有这样的需求：但愿能够在测试环境里实现一键启动中间件服务，如MySQL、Zookerper 、Redis、Kafka等，不须要手动去配置kafka等集群。所以咱们提供了中间件容器化的解决方案，将一些经常使用的中间件导入容器中，后端经过Kubernetes维护这些中间件的状态，这样用户就能够一键建立中间件服务。

但因为这些中间件服务自己相对来讲比较复杂，因此目前咱们的应用商店功能主要是为你们提供测试环境，等这部分功能成熟以后，会把应用商店这些经常使用的中间件拓展到生产环境上，到时候就能够在生产环境使用容器化的中间件服务了。

2.2.3 主要功能点——CI/CD

CI/CD是代码构建流，咱们内部称为codeflow。其实代码构建流程很是简单，一句话归纳起来，就是：拉取仓库源代码，经过用户指定的编译脚本构建出执行程序，将执行程序放到用户指定部署路径，并经过启动命令启动这个服务。系统会为每一个codeflow生成对应的Dockerfile用于构建镜像，用户不须要具有Docker使用经验。

上面的流程是代码编译，下面是经过系统预先生成的Dockerfile，帮用户打包成Docker Image，这就是从代码拉取、代码编译、打包到Docker Image并推送到镜像仓库的整个流程。

用户完成配置并点击提交代码后，就能够经过手动或Webhook的方式触发整个构建流程。也就是说只要用户一提交代码，就会触发整个构建流程，编译源代码、打包Docker镜像、推送镜像仓库并触发滚动升级，用户能够在分钟级别看到效果。
在这里咱们还作了一些小的功能：

• 非root构建。咱们的后端实际上是在一个Jenkins集群下构建的，这样就存在一个问题：若是用户在编辑脚本的时候，不当心写错代码就可能会将整个主机上的东西都删除，很是不安全。为了解决这个问题，咱们在整个构建过程当中采用非root构建的方式，避免某个用户因编译脚本执行某些特权操做而影响系统安全。
• 自定义Dockerfile。支持某些用户使用本身的Dockerfile构建镜像，用户经过上传Dockerfile的方式，覆盖系统生成的Dockerfile。
• 预处理脚本，主要针对Python类的镜像构建，Python类的镜像构建自己不须要编译源代码，但运行环境须要依赖不少第三方的包和库，若是将这些依赖包都安装到基础镜像，不只会致使基础镜像过大，并且后期维护也很麻烦。为了支持Python软件容器化的运行，咱们提供了预处理脚本，即在业务镜像以前先执行预处理脚本，帮用户安装好所须要的依赖包，而后再把用户的代码拷贝过来，基于预处理脚本以后的镜像去生成业务镜像，下次构建的时候，只要预处理脚本不变，就能够直接构建业务镜像了。
• Webhook触发和Gitlab集成，经过Gitlab的Webhook，当用户在提交代码或者merge pr的时候即可以触发codeflow，执行自动上线流程。

2.2.4 主要功能点——文件存储

容器一般须要业务进行无状态的改造，所谓“无状态”是须要把一些状态数据放在外部的中间件或存储里。

咱们提供了两种存储方式：NFS和Cephfs文件存储。用户在页面选择存储的容量，而后点击建立，就能够直接建立一个Cephfs文件存储，而且能够在服务管理页面指定将这一存储挂载到容器的某一个路径下，当容器重启或者迁移后，文件存储会保持以前的目录挂载，从而保障数据不丢失。

2.2.5 主要功能点——Nginx配置

公司有大概100多个Nginx集群，以前这些Nginx集群都是经过运维人员手动方式变动配置和维护，配置文件格式不统一，且容易配置错误，问题和故障定位都很困难。为此咱们在容器云集成了Nginx配置管理，经过模板的方式生产Nginx配置。Nginx配置的功能比较多，包括健康检查规则、灰度发布策略等相关配置。

上图是一个系统管理员能够看到的页面，其中部分项目开放给业务用户，容许用户本身定义部分Nginx配置，如upstream列表，从而将公司域名配置模板化。

除此以外，咱们还作了配置文件的多版本对比，Nginx的每次配置都会生成一个对应的版本号，这样就能够看到在什么时间Nginx被谁修改了哪些内容等，若是发现Nginx配置修改有问题，能够点击回滚到Nginx的历史版本。

泛域名解析，主要适用于测试环境。以前每个测试服务都须要联系运维人员单独申请一个域名，为了节省用户申请域名的时间，咱们为每一个服务建立一个域名，系统经过泛域名解析的方式，将这些域名都指定到特定的Nginx集群。

Nginx后端能够包含容器也能够包含虚拟机，这是在业务迁移过程当中很是常见的，由于不少业务迁移到容器都并不是一蹴而就，而是先将部分流量切换到容器内运行。

2.2.6 主要功能点——配置文件管理

如今的架构提倡代码和配置分离，即在测试环境和生产环境使用相同的代码，不一样的配置文件。为了可以动态变动配置文件，咱们经过Kubernetes的Configmap实现了配置文件管理的功能：将配置文件挂载到容器内，用户能够在页面上传或者编辑配置文件，保存后，系统将配置文件更新到容器内。

就是说当用户在页面上传或编译某个配置文件之后，平台会自动把配置文件刷新到容器里，容器就可使用最新的配置文件了。为了不用户误删配置文件，当系统发现配置文件被使用则不容许删除。

2.2.7 主要功能点——告警管理

告警管理功能基于Prometheus实现。平台会把全部的监控数据，包括容器相关的（CPU、内存、网络IO等）、Nginx相关的、各个组件状态相关的数据，都录入到Prometheus里，用户能够基于这些指标设置监控阈值，若是达到监控阈值，则向运维人员或业务人员发送告警。

值得一提的是，咱们提供了一种特殊的告警：单个容器性能指标。按常理，每一个容器监控指标应该是相似的，没有必要针对单个容器设置告警，但在实际生产环境中，咱们遇到过屡次因为某个特定请求触发的bug致使CPU飙升的场景，因此开发了针对单个容器的性能告警。

3、容器容器云平台落地实践

前面介绍了系统的一些经常使用功能，接下来介绍宜信容器云平台落地过程当中的实践。

3.1 实践——自定义日志采集

容器的使用方式建议用户将日志输出到控制台，但传统应用的日志都是分级别存储，如Debug日志、Info日志、Error日志等，业务须要采集容器内部指定目录的日志，怎么实现呢？

咱们经过二次开发Kubelet，在容器启动前判断是否有“KUBERNETES_FILELOGS”这个环境变量，若是存在，则将“KUBERNETES_FILELOGS”指定的容器目录挂载到宿主的“/logs/容器名称”这个目录下面，配合公司自研的日志采集插件Watchdog即可以将宿主机上这个目录下的文件统一收集。

3.2 实践——TCP代理出口

在实际过程当中咱们常常遇到网络对外提供服务的场景，系统中除了Nginx提供的 HTTP反向代理之外，还有一些须要经过TCP的方式对外提供的服务，咱们经过系统中指定的两台机器安装Keepalive和配置虚IP的方式，对外暴露TCP服务。

3.3 实践——自动扩容

自动扩容，主要是针对业务指标的一些突发流量能够作业务的自动伸缩。其原理很是简单：由于咱们全部的性能指标都是经过Prometheus统一采集，而Cluster-mgr负责多集群管理，它会定时（默认30s）去Prometheus获取容器的各类性能指标，经过上图的公式计算出每一个服务的最佳副本个数。公式很简单：就是每一个容器的性能指标求和，除以用户定义目标指标值，所得结果即为最佳副本数。而后Cluster-mgr会调用Ipaas操做多个集群扩容和缩容副本数。

举个例子，如今有一组容器，我但愿它的CPU利用率是50%，但当前4个副本，每一个副本都达到80%，求和为320，320除以50，最大副本数为6，获得结果后就能够自动扩容容器的副本了。

3.4 实践——多集群管理

传统模式下，单个Kubernetes集群是很难保证服务的状态的，单个集群部署在单个机房，若是机房出现问题，就会致使服务不可用。所以为了保障服务的高可用，咱们开发了多集群管理模式。

多集群管理模式的原理很简单：在多个机房分别部署一套Kubernetes集群，并在服务建立时，把应用部署到多个Kubernetes集群中，对外仍是提供统一的负载均衡器，负载均衡器会把流量分发到多个Kubernetes集群里去。避免由于一个集群或者机房故障，而影响服务的可用性。

若是要建立Kubernetes相关或Deployment相关的信息，系统会根据两个集群的资源用量去分配Deployment副本数；而若是要建立PV、PVC以及Configmap等信息，则会默认在多个集群同时建立。

集群控制器的功能是负责检测Kubernetes集群的健康状态，若是不健康则发出告警，通知运维人员切换集群，能够将一个集群的服务迁移到另外一个集群。两个集群以外经过Nginx切换多集群的流量，保障服务的高可用。

这里有3点须要注意：

• 存储迁移。底层提供了多机房共享的分布式存储，能够随着容器的迁移而迁移。
• 网络互通。网络是经过Flannel + 共享etcd的方案，实现跨机房容器互通及业务之间的相互调用。
• 镜像仓库间的数据同步。为了实现两个镜像仓库之间镜像的快速拉取，咱们在两个机房内都部署了一个镜像仓库，这两个镜像仓库之间的数据是互相同步的，这样就不用跨机房拉取镜像了。

3.5 实践——如何缩短构建时间

如何加速整个CI/CD构建的流程？这里总结了四点：

• 代码pull替换clone。在构建代码的过程当中，用pull替换clone的方式。用clone的方式拉取源代码很是耗时，特别是有些源代码仓库很大，拉取代码要耗费十几秒的时间；而用pull的方式，若是发现代码有更新，只须要拉取更新的部分就能够了，不须要从新clone整个源代码仓库，从而提升了代码拉取的速度。
• 本地（私有）仓库、mvn包本地缓存。咱们搭建了不少本地（私有）仓库，包括Java、Python的仓库，不须要再去公网拉取依赖包，这样不只更安全，并且速度更快。
• 预处理脚本。只在第一次构建时触发，以后即可以基于预处理脚本构建的镜像自动构建。
• SSD加持。经过SSD硬件的加持，也提升了整个代码构建的速度。

3.6 实践——什么样的程序适合容器

什么样的程序适合运行在容器里？

• 无操做系统依赖。目前主流容器方案都是基于Linux内核的cgroup和namespace相关技术实现的，这就意味着容器只能在Linux系统运行，若是是Windows或者C#之类的程序是没法运行到容器里面的。
• 无固定IP依赖。这个其实不算硬性要求，虽然容器自己是能够实现固定IP地址的，但固定的IP地址会为Deployment的自动伸缩以及集群迁移带来不少麻烦。
• 无本地数据依赖。容器的从新发布是经过拉取新的镜像启动新的容器进程的方式，这就但愿用户不要将数据保存到容器的本地，而是应该借助外部的中间件或者分布式存储保存这些数据。

3.7 避坑指南

在实践过程当中会遇到不少问题，本节将列举一些已经踩过的坑，逐一与你们分享咱们的避坑经验。

3.7.1 为啥个人服务没有起来？

这种状况多是由于服务被放在了后台启动，容器的方式和以前虚拟机的方式有很大区别，不能把容器服务放在后台启动，容器启动的进程的PID是1，这个程序进程是容器里惟一的启动进程，若是程序退出了容器就结束了，这就意味着程序不能退出。若是把程序放到后台启动，就会出现进程起来了但容器服务没有起来的状况。

3.7.2 为啥服务启动/访问变慢？

以前使用虚拟机的时候，因为配置比较高（4核8G），不少业务人员没有关心过这个问题。使用容器以后，平台默认会选中1核1G的配置，运行速度相对较慢，这就致使了业务在访问业务的时候会以为服务启动和访问变慢。

3.7.3 为啥服务会异常重启？

这和配置的健康检查策略有关，若是某应用的配置健康检查策略不经过的话，Kubernetes的Liveness探针将会重启该应用；若是业务是健康的，但提供的健康检查接口有问题或不存在，也会重启这个容器，因此业务要特别注意这个问题。

3.7.4 本地编译能够，为啥服务器上代码编译失败？

这个问题很是常见，大可能是因为编译环境和服务器环境的不一致致使的。不少业务在本地编译的时候，本地有一些开发工具的加持，有一些工做开发工具帮助完成了，而服务器上没有这些工具，所以会出现这个问题。

3.7.5 为啥个人历史日志找不到了？

这个问题和容器使用相关，容器里默认会为用户保存最近两天的日志，主机上有一个清理的功能，日志超过两天就会被清理掉。那这些超过两天的日志去哪里查看呢？咱们公司有一个统一的日志采集插件Watchdog，负责采集存储历史日志，能够在日志检索系统中检索到这些历史日志。

3.7.6 为啥IP地址会变化？

每次容器重启，其IP地址都会发生变化，但愿业务人员的代码不要依赖这些IP地址去配置服务调用。

3.7.7 为啥流量会打到异常容器？

容器已经异常了，为何还有流量过来？这个问题具体表现为两种状况：业务没起来，流量过来了；业务已经死了，流量还过来。这种两种状况都是不正常的。

• 第一种状况会致使访问报错，这种场景通常是经过配合健康检查策略完成的，它会检查容器服务到底起没起来，若是检查OK就会把新的流量打过来，这样就解决了新容器启动流量的异常。
• 第二种状况是和容器的优雅关闭相结合的，容器若是没有匹配优雅关闭，会致使K8s先去关闭容器，此时容器尚未从K8s的Service中摘除，因此还会有流量过去。解决这个问题须要容器里面应用可以支持优雅关闭，发送优雅关闭时，容器开始本身回收，在优雅关闭时间后强制回收容器。

3.7.8 为啥无法登陆容器？

不少时候这些容器尚未起来，此时固然就没法登录。

3.7.9 Nginx后端应该配置几个？OOM？Cache？

这几个问题也常常遇到。在业务使用过程当中会配置CPU、内存相关的东西，若是没有合理配置，就会致使容器的OOM。咱们新版的容器镜像都是自适应、自动调整JVM参数，不须要业务人员去调整配置，

3.8 faketime

容器不是虚拟机，因此有些容器的使用方式并不能和虚拟机彻底一致。在咱们的业务场景里还有一个问题：业务须要调整时钟。

容器和虚拟机的其中一个区别是：虚拟机是独立的操做系统，修改其中一个虚拟机里的任何东西都不会影响其余虚拟机。而容器除了前面说的几种隔离之外，其余东西都不是隔离的，全部的容器都是共享主机时钟的，这就意味着若是你改了一个容器的时钟，就至关于改了整个全部容器的时钟。

如何解决这个问题呢？咱们在网上找到一种方案：经过劫持系统调用的方式修改容器的时钟。但这个方案有一个问题：faketime不能睡着了。

3.9 使用状况

通过几年的推广，目前宜信容器云平台上已经支持了100多条业务线，运行了3700个容器，累计发布17万次，还荣获了“CNCF容器云优秀案例”。

4、宜信容器云将来规划

前文介绍了宜信容器云平台目前取得的一些小成就，即宜信容器云平台的A点，接下来介绍宜信容器云的B点，即将来的一些规划。

4.1 对象存储

公司有不少文件须要对外提供访问，如网页中的图片、视频、pdf、word文档等，这些文件大部分都是零散地保存在各自系统的存储中，没有造成统一的存储管理。若是文件须要对外提供访问，则是经过Nginx反向代理挂载NAS存储的方式，这些文件的维护成本很是高，安全性也得不到保障。

咱们基于Ceph开发一个统一的对象存储服务，把公司零散在各个系统的小文件集中到对象存储中去，对于能够提供外网或公网访问的部分，生成外网访问的HTTP的URL。目前对象存储已经在业务的测试环境上线。

4.2 站点监控

站点监控是一个正在重点研发的功能。公司开源了智能运维工具UAVstack，侧重于应用的监控，还缺少服务外部的站点监控。站点监控是为了监控服务接口的运行状态，并发送告警。

咱们经过在公司外部部署采集Agent，这些Agetnt会根据用户定义的监控URL定时调用接口是否正常运行，若是接口返回数据不符合用户设定条件则发出告警，如HTTP返回5xx错误或者返回的body中包含ERROR字符等。

4.3 大数据容器云

在大部分业务迁移到容器后，咱们开始尝试将各类大数据中间件（如Spark、Flink等）也迁移到Kubernetes集群之上，利用Kubernetes提供的特性更好地运维这些中间件组件，如集群管理、自动部署、服务迁移、故障恢复等。

4.4 混合部署

公司有不少长任务，这些长任务有一个很是明显的特色：白天访问量较高，晚上访问量较低。对应的是批处理任务，批处理主要指公司的跑批任务，如报表统计、财务帐单等，其特色是天天凌晨开始执行，执行时对CPU和内存的消耗特别大，但只运行十几分钟或几个小时，白天基本空闲。

为了获得更高的资源利用率，咱们正在尝试经过历史数据进行建模，将批处理任务和长任务混合部署。

4.5 将来规划——DevOps平台

最后介绍咱们整个平台的DevOps规划。

回到以前容器云的背景，业务须要一套统一的DevOps平台，在这个平台上，能够帮助业务完成代码构建、自动化测试、容器发布以及应用监控等一系列功能。

其实这些功能咱们基础研发部门都有所涉及，包括自动化测试平台 Gebat、应用监控UAVStack、容器云平台等，可是业务须要登陆到不一样的平台，关联不一样的数据，而各个平台之间的数据不一致、服务名称不对应，没办法直接互通，操做起来很是麻烦。
咱们但愿经过创建一个统一的DevOps平台，把代码发布、自动化测试、容器运行和监控放到同一个平台上去，让用户能够在一个平台完成全部操做。

内容来源：宜信技术学院第7期技术沙龙-线上直播|宜信容器云的A点与B点

主讲人：宜信高级架构师 & 宜信PaaS平台负责人 陈晓宇

来源：宜信技术学院