网站响应式首页模板,泉州做网站优化的公司,本地网站搭建视频教程,网站后台发布新闻数人云上海深圳两地“ 容器之Mesos/K8S/Swarm三国演义”的嘉宾精彩实录第四弹#xff01;小数已经被接连不断的干货搞晕了#xff0c;沉浸技术的海洋好幸福~Windows container在国内的实践还比较少#xff0c;携程作为.Net大户#xff0c;率先进行了调研和实践应用深圳两地“ 容器之Mesos/K8S/Swarm三国演义”的嘉宾精彩实录第四弹小数已经被接连不断的干货搞晕了沉浸技术的海洋好幸福~Windows container在国内的实践还比较少携程作为.Net大户率先进行了调研和实践应用将其中的成果与大家分享。 罗勇携程云平台开发经理 主要负责携程云平台建设和维护熟悉OpenStackDocker 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和hyperv container 。 有人会问hyper-v不就是一个虚拟机的技术吗对其实它有点像虚拟机但是hyperv的技术略有不同速度会明显比虚拟机快很多只是在申请资源或者获取资源时比Windows server Container的速度稍稍慢一点点Windows server container可能3秒它可能4、5秒。但是资源的隔离度比较好一些类似于虚拟机微软公有云 Azure的容器服务也是采取这种容器类型他们的考虑是公有云上面部署的应用不是受信任的相互之间有可能“打架”的情况发生他想隔离好一些。 另一个区别Windows server Container的内核是共享的可以在宿主机上看到每个容器里面的进程这与Linux容器相似可以直接kill掉。hyper-v container宿主机是看不见容器内进程的像一个虚拟机一样。此外内存资源隔离不同Windows server Container内存可以sharehyper-v container不能sharehyper-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多个应用一旦容器跑起来了宿主机的规模还是比较可观的这种情况下大规模容器如何管理好这也是后面需要解决的问题。 这是我今天给大家分享的主要的内容谢谢大家! 活动相关阅读 构建与定制唯品会PaaS基于Kubernetes的实践 广发银行运维实践分享Docker适配传统运维那些事 Docker在Bilibili的实战由痛点推动的容器化 ——点击阅读原文下载活动PPT—— 内容转载自公众号 数人云 了解更多
