.Net大户的选择:Windows Container在携程的应用

数人云上海&深圳两地“容器之Mesos/K8S/Swarm三国演义”的嘉宾精彩实录第四弹!小数已经被接连不断的干货搞晕了,沉浸技术的海洋好幸福~Windows container在国内的实践还比较少,携程作为.Net大户,率先进行了调研和实践应用,将其中的成果与大家分享。

罗勇,携程云平台开发经理 主要负责携程云平台建设和维护,熟悉OpenStack,Docker ,Linux/Windows Container 等技术领域

今天的主题是Windows容器。今年下半年携程开始了对Windows container的调研工作,目前已经有一些成果和实际应用案例,与大家分享一下,主要内容有:

  • 携程为什么要使用Windows container (可能国内大部分的人了解Windows container少一些,特别是具体的实践,分享重点会偏Windows container细节)
  • 传统.Net应用容器化实践
  • 容器存储&网络&编排

携程为什么要做Windows container?

现状:

  • 携程是.Net应用大户,由技术栈决定的,早期携程整个应用架构都放在该平台上,线上跑了3000多个核心应用,覆盖了20多个BU(业务部门),这让我们不得不关注这一庞大的系统。
  • 平台要往java方面转,去分享java的红利,但是.Net 线上应用不可能都重写;
  • .Net 的应用目前90%左右的应用都跑在虚拟机上,从虚拟机自身来看,粒度太粗,对资源的使用率还不是很好。
  • 持续发布,应用上线,从拿到机器环境准备好环境上线生产,虚拟机模式下周期长,扩容慢。

新一代发布平台的需求,希望缩短环境准备时间,做到秒级部署, Linux平台的应用非常容易做到,但是Windows .Net 应用在这方面支持比较难,另外,为了确保生产和测试环境高度一致,希望应用发布是单一应用、单一镜像的,最好是一个容器尽量少的包含系统进程,这样可以把资源隔离的粒度控制在小范围内,尽量榨取宿主机的资源,同时希望Linux容器和Windows容器的方案尽可能接近,比如网络、存储,不需要两套不一样的方案或是有大的有变化。

一些Windows container的技术细节

最开始的时候携程用物理机部署应用,为了保证互不冲突,用户在一个物理机上只部署一个应用。后来认为此举太浪费,就部署了多个应用,但是为管理带来了麻烦,应用之间有一定的冲突或者相互影响。之后有了虚拟机,虚拟机上可以部署更多的应用,而且隔离比较好,不过虚拟机资源隔离的粒度太粗了,于是容器走了过来,能做到把一个应用打到包里,这个包涵盖了环境配置等,run起来可以只是一个进程,又具备一定的隔离性,同时把资源使用的粒度控制足够的细。

Windows container目前支持的系统是Windows server 2016,这个版本是去年10月份正式发布的(携程是国内比较早的一批拿到了他们的RTM版本),支持两类server ,一类是server core,另一类是nano server 。 nano server是微软比较推荐的一类服务器系统,启动非常快,可以大幅度缩短计划内维护宕机时间,通常几秒钟就起来了,不包含硬件检测的时间,几十秒都能够起来。这块携程还没有用于生产环境,目前只测试了用server core作为容器宿主机的系统的情况。需要着重提一下的是,如果宿主机打了补丁或者升级,容器也要对应的做补丁或者升级。当然不一定说立马做补丁升级,但一定要比较精确的找到对应的版本做升级。

Windows container有两种container类型,这两种容器都是跑到Windows servrer 2016的,但还有一种容器的玩法是在Liunx平台跑.Net core,这种方案我们也看过,大家很容易想到它的局限,其实只能跑到用.Net 技术开发的Windows的应用,一些非.Net的应用不支持,因此这个方案被Pass了。直接在Windows server跑容器的方案更为靠谱,该方案有两种类型,Windows server和hyper-v container 。

有人会问,hyper-v不就是一个虚拟机的技术吗?对,其实它有点像虚拟机,但是hyper-v的技术略有不同,速度会明显比虚拟机快很多,只是在申请资源或者获取资源时,比Windows server Container的速度稍稍慢一点点,Windows server container可能3秒,它可能4、5秒。但是资源的隔离度比较好一些,类似于虚拟机,微软公有云 Azure的容器服务也是采取这种容器类型,他们的考虑是公有云上面部署的应用不是受信任的,相互之间有可能“打架”的情况发生,他想隔离好一些。

另一个区别,Windows server Container的内核是共享的,可以在宿主机上看到每个容器里面的进程,这与Linux容器相似,可以直接kill掉。hyper-v container宿主机是看不见容器内进程的,像一个虚拟机一样。此外,内存资源隔离不同,Windows server Container内存可以share,hyper-v container不能share,hyper-v container一旦分配就不能重新进行修改。对系统应用是信任的,这种比较适合做私有云的一些产品,因为在应用上跑的什么东西,这个应用能干什么坏事或者是相互之间有没有影响,都可以控制,但是公有云不能这样做,应用使用率很高,会把别的容器影响到。启动速度上也会有差别,一个启动快,一个启动慢一点,当然并不是特别慢。

容器镜像,这个和Linux容器的镜像类似,可以分层。最下面一层是基础镜像,但是基础镜像和Linux有区别。Linux镜像可以自己搞,弄一个系统把它做成镜像,但是微软没有办法自己做一个Windows container base镜像。或者说现在只是Windows server 2016的镜像,想跑一个2012的系统是不行的。当前系统内核只能支持win10,在上面可以继续安装想要的东西,比如接着安装Framework,然后在最上面装应用。

镜像构建也是一样,Windows container容器和Docker集成比较好,可以用Docker工具的一些命令进行build,用Dockerfile来Build一个镜像。registry是镜像可以直接push到一个平台或者是私有的registry上面去,通过Docker pull方式拉下来,Docker run跑起来。

Windows container的镜像,可以在Docker网站上可以找到关于Windows container的一些base image, pull下来大概有8G左右,在外网上下载可能要两天。大家可以尝试一下。也可以建私有的registry ,携程采用的VMware开源的Harbor方案,本身没有做太多的修改,直接可以用。和携程的AD整合以后基本上能用了, registry可以把Linux和Windows的镜像都放在一起,两边都能用,都能管,这部分省掉了很多的内容,不需要做额外的开发,这样Windows和Linux的平台的image管理方案是一致的。

传统.Net应用迁移

迁移背景:

之前提到携程有3000多个.Net应用,这些应用每天要不停的发布、测试、编译打包,是一项很大的繁琐工程,有个叫“build”的项目负责这个事情。最初这些跑在虚拟机里,资源使用率很低,白天很忙,晚上使用率很低,有一定的资源浪费,且构建环境也经常不一致。为了积攒容器应用使用的经验,我们考虑把build项目先容器化,也就意味着.Net应用自己的编译在容器里面编译,看能撞出来什么样的火花。

原来写几千个应用的编译脚本,如果改了一些东西,变更维护的代价是非常大的,尽量这个方案不要用到原来以往用的工具和使用方式,不去动它,最好能够拿过来不怎么修改,就跑起来。另外,重点看一下像vs2010和vs201这样的工具能不能在容器里跑,实践证明是可以的。然后看MSBuild 在容器里面是否兼容,支持不同的.Net Framework版本,这些都是比较通用的软件,结果是这些功能都能够支持,另外也包括python 、MVC、GIT等等。

迁移收益

  • 首先环境,编译的环境高度一致,每个环境没有太多的区别,容器拉起来直接跑,提高了编译成功率。
  • 其次资源利用率提高了,我们把虚拟机资源砍掉了一半,就只需要两台宿机机搞定整个携程3000多个.Net应用的编译。
  • 编译时长也缩短了,原来用一次构建平均要几分钟,现在90秒左右基本上能构建完成。

待解决的问题:

  • 图形不支持,这个是某些企业想用Windows container的大问题,它本身图形不支持。后台程序没有太大问题,不过有一些依赖图像工具比较难支持。
  • 旧应用兼容不是很好。比如遇到MGwin编译出来的包,一旦代码中有调用标准输出的语句程序直接就挂了,遇到这类问题,需要把源码拉下来重新编译,比较有难度。
  • 不支持RDP,远程桌面是不能用的,那怎么做到远程访问呢? 还好Windows 现在支持SSHD安装了,只需要容器内装一个SSHD,然后远程SSH去,当然可以用powershell远程的登录方式,两种方案都可以用,SSH方案更统一一些, 如果用户当前正在Linux平台上工作,突然想登一个Windows的容器怎么办?当然也可以用linux 平台的powershell工具实现远程登陆容器。
  • 不支持D盘。携程迁移过来很多老的应用是要装在D盘的,容器拉起来没有D盘,只有一个C盘。本身Docker有一个volume功能,可以挂一个数据的盘,问题是这样会导致在宿主机上留下一些东西,和宿主机产生耦合,如果容器删除或者迁移,宿主机上就留下了脏数据。后来我们为D盘做一个link,相当于D盘可以快捷的方式连到C盘,映射到C盘的某个目录,这样数据都是落地到在容器的磁盘上,如果想在别的地方拉起来这个容器,可以直接push register,就可以在别的地方部署且环境一样。

存储&网络&编排

接下来Windows container容器的存储,网络,编排方面的技术与大家分享一下。

Windows container资源的隔离方式和配置管理API 是借用Docker规范,设计理念和Linux Container类似,也支持CPU share的这种方式去控制资源的分配。内存可以通过quota的方式去分配内存,Disk也能够充分应用到IO的带宽,这一块还没有做非常多严格的测试。关于网络的支持,携程做了很多测试,整体来讲比较不错,问题较少。性能也满足需求,多个容器在一个同一个宿主机上也能尽量用到整个宿主机的带宽。

容器的存储

存储有三种:一种是镜像,镜像本身是一个存储,设计之初定义就不是一个永久的存储,当前容器存储拉掉那个存储就没有了,也不是设计安全的。另外一种存储是volume(卷) ,可以挂一个数据盘到某一个容器上,在容器里扩展存储空间。同时多个容器也可以挂载宿主机上的一个同一个volume(卷目录),这样大家可以实现NFS一样的效果。最后一类存储是网络存储,比如可以用SMB的方式挂网络盘在容器里面使用,里面如果有万兆的带宽支持还可以玩一下,如果没有万兆带宽的话就不要玩了,它只能放一些冷数据。

容器的网络

相对来讲复杂一些,Windows 支持有四种网络模型,第一种NAT模式大家比较熟悉,起一个本地或者是数据本地的IP地址,如果你想外网访问的话,把Docker映射出来,这种方式比较适合做一个JOB类型的应用在上面,不需要外边可以访问它,但是容器里面可以去下载东西。之前讲的build项目就是用这个网络模型,非常简单,不需要考虑太多网络的模型就可以直接用。

第二种是transparent网络模型,这种模型是现在主要用于生产的模型,首先它是通过mac 地址伪装实现数据透传,对网络的性能本身折损也比较少,它也支持把多个工作网卡绑到一个交换机上,然后把这个交换机给容器用。网络模型在容器宿主机以外的机器上看到Windows容器和一台物理机没有什么区别。

还有一种是L2 bridge这种采用openstack网络的Flat模式,所用的网络跟宿主机的网络是一样的,和宿主机在同一个网段,这样有很大的局限性,网络和宿主机混在一起没有办法做到多租户隔离,然后网段用光了就完了,适用于比较小的集群。

最后一种是Tunnel mode,没有太多研究这一种,但是微软Azure用的这一种网络模型。本身携程为了和虚拟机的很多的品牌网络模型一致,所以这一种没有那么快的推进。

hyper-v的网络模型

Hyper-v宿主机是2012上面hyper-v的网络模型,之前要求一台宿主机尽量要4块网卡,为什么要用4块网卡?两块给虚拟机用,另外两块做一些管理,比如对存储用,虚拟机迁移等,可以做宿主机的管理。另一种方式,2016建议的一种网络方式,这里面有一个叫做embed team,内嵌交换机,它的好处是把下面无论是两块还是N块网卡都可以绑在一个bound,然后把这个bound放在一个交换机里面,每个容器port全部放在交换机里面,然后容器给port打相应的vlan tag,这样容器的网就通了。

embed team的好处是不需要要求宿主机一定要有这么多的网卡才可以用,另一个好处是对这些不同的vlan之间做一些流量的控制,携程的container 的网络模型也是基于嵌入式交换机上实现的。把宿主机至少两块网卡做了bound,放在一个embed team里面去,另外加一个port给宿主机做管理网卡。容器宿主机相比虚拟机宿主机简单,没有存储和迁移的需求,就不要以额外的划分网络了,如果需要为容器的存储单独挂一个网络的话可以加一个Port做这个事情。不同的网段的这种容器在上面可以再创建不同的Docker,加不同的port,然后容器在里面可以互通,这样的好处就是既实现了多租户、实现了网络隔离,同时和虚拟机包括Linux上面的网络模型是一致的。

容器编排

编排这块通常一个容器部署到多个宿主机上,同时一套应用下来有数据层、业务层、也有web层,这些应用要分开放,它们中间放在哪里需要有一个地方,把整个管起来,也希望这个东西能自动化,本身做编排这些,无论是Swarm、K8S、Mesos都是需要解决的问题。一种方案是用Docker compose这种方式,适合于单宿主机管理。想编排一下容器,看如何跑,这种方式用Docker compose就能解决。当然,微软现在对Docker Swarm支持好一些,实现成本比较低,基本上能管,但是性能方面没有做太多的测试,目前一些基本的调度、主机分类等等都能用。

为什么携程选择使用Mesos?

因为携程的Linux平台用的也是这套方案做的编排相关的管理,希望有一套方案能够尽量两种容器一致,于是我们的方案采用Mesos 加上Marathon对它进行管理,本身它也有一些现成的工具,比如UI等现成的工具都可以用,这部分还在进行测试和研究中。官方下来的包不能直接跑到Windows server上面,要拿下来重新编译才能用。最终携程是想做到这么简单的一个容器的管理的架构,就是说希望Mesos在里面能够同时管Linux容器和Windows容器,对它进行统一的调度,最大限度的优化这种调度策略,提升使用率,这是最终整体的设计理念。

待解决问题

有一些急迫解决的问题,与大家交流一下。首先Windows container的镜像比较大,在生产环境,如果批量pull base image,网络的带宽会很快被打满,会对业务带宽造成影响。我们需要有一套方案来解决这个问题, 如何能够比较“经济”的方式把Based image或者变更的Layer文件下发下去,是后续要解决的问题。

Windows container的监控日志,没有现成的方案,我也有与微软团队交流过,这部分文档非常少,携程之后也会重点解决监控问题。

推行单容器、单应用的发布方式,希望后面能够把各种FAT/UAT/Prod环境之间打通,都可以通过Windows容器方式,秒级发布。

携程有3000多个应用,一旦容器跑起来了,宿主机的规模还是比较可观的,这种情况下,大规模容器如何管理好?这也是后面需要解决的问题。

这是我今天给大家分享的主要的内容,谢谢大家!