Mesosphere
掀起容器技术风潮的Docker问世不过才3年，不只掀起了Container应用风潮，带动了微服务新兴IT架构崛起，更让开发维运一体化的DevOps模式更容易实现。
Docker执行长Ben Golub今年6月在DockerCon年度大会上揭露了最新的Docker使用者调查，有6成Docker使用者，开始在正式环境中使用Container，而不像过去大多用于测试、开发阶段。大型企业拥抱Container的脚步也开始改变，他更引用另一个2016年中调查，在超过500人规模的大型企业中，更有73％的企业在正式环境中採用。
而且不只有新创或大型网路公司拥抱Container，电商（如ebay、乐天），媒体（如Netflix、纽约时报、BBC），医疗（如Merck、Abbott）、金融服务（如VISA、ADP、PayPal）、製造业（奇异、空中巴士等），科技公司（如Amadeus、IBM、思科）、电信（例如瑞士电信）等，越来越多的产业都开始导入。
应用情境也不再以开发、测试、DevOps、CI/CD为主，Ben Golub透露，儘管DevOps驱动的CD需求仍是大宗，超过5成应用案例都属这类，但也有43%的Docker案例用来将老旧系统微服务化进而搬上云端，另外也有37％的Docker使用案例是将老旧应用容器化。目前Docker容器运用上有43％的容器是用来执行传统的资料库系统。
Container成为企业双头IT的另一列火车头
Container不只是科技新创或网路公司爱用的技术，开始成为企业双头IT的另一列火车头，专攻云端原生应用和App。企业面临的新架构不只是混合云的架构，还是云端原生应用的微服务架构，要和传统应用程式架构的整合。
举例来说，IT团队多达1,300人规模的Airbus，不只希望能在企业内部实现快速开发和部署应用程式，还想要进一步将这个速度力延伸到云端，并且希望扩充应用程式规模时，可以兼顾资源利用率优化来控管成本，更关键是，还要简化旧有非云端应用系统的汰换过程。「拥抱DevOps和Container的PaaS平台，是唯一的选择。」Airbus公司IT工具服务新创部门首席Nicolas Fanjeau在红帽大会上透露。
也因此，Airbus採用Docker Container技术，并使用Kubernetes来作为Container丛集的管理平台。不只在新专案上用Container，「内部採用PHP开发的150套应用系统，超过40套已经準备好要改部署到Container上。」他说。
奇异家电靠800容器执行350个App
美国奇异集团旗下的奇异家电，则是靠800个容器撑起了350个App的后端架构，甚至还能将61年老系统所用的后端资料库Docker化后，方便搬进私有云中调度管理。
营收超过50亿美元的奇异家电，早在2012年中时开始导入私有云和敏捷流程，花了一年时间打造了一套自助式IaaS平台。但是奇异家电后来发现，负责维运IaaS平台的团队，成了最大的瓶颈。因为不同应用程式所需的执行环境配置差异太大，而且非常複杂，即使已提供了通用配置的IaaS平台，连资料库都建立了DBaaS服务，但奇异家电的IT团队，仍旧得花很多时间来进行手动微调，才足以满足业务部门需要的应用环境特殊需求。
直到2014年8月，奇异家电在当年Dockercon上看到了Docker和Mesosphere后决定导入，一方面用Docker建立高弹性的AP可移植性，降低部署到多种环境时的配置门槛，另一方面则利用Mesosphere来管理容器、建立自动化排程、扩充等需求，来简化资料中心维运和管理。
奇异家电还自己打造了一个自助式Web版管理平台，称为Voyager，作为应用系统管理者的管理之用，避免直接连线到容器内应用提高安全性和政策控管。经过一年，奇异家电至少已将350个内部应用App转移到Docker环境上正式提供服务，使用了超过800个容器。可以说奇异家电大多数的关键应用系统都已经Docker化了，甚至连用了61年老系统后端搭配的资料库也容器化放到IaaS上管理。原本奇异家电评估，得花上好几年才能转移老旧系统到云端环境，但后来只用了4个月，就将45％的应用系统转移到新架构上。
下一步，奇异家电给自己设定的新挑战是，要尽可能提高容器执行密度，希望能做到在单一刀锋伺服器上能跑1,000个容器，也希望能将核心的Oracle ERP搬上Docker环境。但这些挑战都不只是Docker技术本身的考验，更是大规模容器丛集的维运难题。
容器正式应用越多，Orchestration机制越显得重要
越来越多企业拥抱容器技术后，新挑战也接踵而来，不只是数个或数十个容器，企业要面对的是成千上百个容器的维运，如何管理超大规模容器丛集，正是Container平台的下一个新挑战。Docker丛集专案Swarmkit负责人陈东洛表示，越来越多人想在生产环境上使用Container，Orchestration（调度）机制更显得重要。
Docker丛集专案Swarmkit负责人陈东洛表示：「企业要回到调度需求本身来看，而不只是看应用规模就决定导入Orchestration工具，要找出调度需求的痛点，而不是容器需求的痛点。」
过去企业建置大规模丛集时，最常用来管理丛集内伺服器调度的做法，前Mesosphere分散式系统首席工程师Timothy Chen打趣的说，其实是靠Excel。在Excel表单上列出每一台伺服器的IP和用途，每有异动就更新这张Excel表单，来建立一份丛集节点调度清单，但随着微服务（Microservices）架构开始盛行、容器技术走向正式环境，单靠Excel已经很难管理複杂的大规模容器调度问题。
容器丛集的考验是得管理上千个生命周期
CoreOS分布式项目主管李响更直指，容器丛集的挑战是，企业不仅要管理一个应用程式的生命周期，而是要管理成百上千个容器的生命周期。
尤其在大规模容器丛集的管理上，有三大问题，李响解释，第一是如何部署容器丛集、其次是如何从中找到特定一个容器，以及如何连结或存取到这个特定的容器。
管理容器丛集常见工具之一就是排程工具（Scheduler），作用就像是过去管理丛集常用的Excel档，但更自动化也能更聪明。李响表示，Scheduler的作用时将实体资源都抽象成一个资源池，让开发者只需要向Scheduler提出应用程式需要的资源，再由Scheduler来安排如何提供。换句话说，「对应用程式开发者而言，细节都被Scheduler 抽象化了。」其他可用来管理大规模容器丛集的关键的是，李响表示，最新作法是开始採用「服务」（Service）的概念来管理容器丛集，透过「服务」概念来抽象化，多个容器之间的沟通。例如透过服务概念来部署应用程式，做到如滚动升级、自动扩充、副本控制的效果，也比直接调度容器更简单。
李响提到的Scheduler，只是调度层工具的其中一环，Timothy Chen补充，虚拟化时代，是在一个基础架构上，管理多个VM内的单一应用，但是使用容器和微服务架构之后，往往得在基础架构上，提供多个VM，执行多个Container，来提供不同的微服务，组合成各式各样的应用系统。
因为每一个微服务都得像过去一个应用程式那样来管理生命周期，「导致开发者在正式环境中运作应用程式所花的时间，比思考程式业务逻辑的时间还要多得多。」Timothy Chen说。
也因此，许多大型网路公司都各使用了不同的Orchestration工具来管理大规模的丛集，如Facebook的Tupperware、Google则有Borg和Omega、Yahoo则利用了Hadoop专案中的YARN，Twitter则是使用了Mesos和Aurora。
CoreOS分布式项目主管李响直言:「容器丛集的挑战是，企业不仅要管理一个应用程式的生命周期，而是要管理成百上千个（容器）的生命周期。」
Orchestration工具三大功能
Timothy Chen归纳Orchestration工具一般涵盖了三大类功能，包括了服务管理机制、排程机制和资源管理机制，Orchestration工具可以将Web应用和各类服务和Container Runtime层隔离，来简化複杂的容器丛集管理难题。
更进一步的功能细节，排程工具要做到置换、扩充／複製、重新排程、升级、降级、资源蒐集等。而资源管理机制则要能管CPU、记忆体、GPU、储存（Volumes）、网路埠、IP位址等资源，而服务管理机制则要做到如标记（Labels）、命名空间或群组（Groups/Namespaces）、相依性（Dependencies）、负载平衡（Load Balancing）、可读性检查（Readiness Checking）等。另外，Orchestration工具最好还要能实作出非功能性的能力，例如扩充性、可用性、弹性、使用友善、移植性、安全性等。「最终就是要用Orchestration工具来建立一个高度可程式化的基础架构（Programmable Infrastructure）。」Timothy Chen说。
像CoreOS想要实现的目标也类似，李响表示，CoreOS的目标是，开发者只需使用一套丛集管理平台，就能执行任何自己的分散式应用，甚至可以具备有Google级架构的基础架构资源池，也就是拥有了GIFEE架构（Google's Infrastructure for Everyone Else，任何人都可用的Google架构）可以使用。
不让各家Orchestration平台专美于前，Docker也在今年6月的DockerCon大会上宣布进军Orchestration平台的竞争，从Docker 1.12新版开始内建Swarm丛集管理工具，将Orchestration变成Docker引擎的核心机制之一。
陈东洛是Swarm丛集专案开发的负责人，他解释，其实Docker一直在研究容器调度工具，在1.12版之前，Docker透过Swarm、Compose、Machine等部署工具来实现容器调度，Swarm功能内建后，Docker新的丛集与调度工具是Swarmkit。
前Mesosphere分散式系统首席工程师Timothy Chen认为:「不同企业需要的网路、储存、资安的差异很大，Orchestration平台想要设计一套符合所有需求的通用架构，目前还是一大挑战。」
Docker内建丛集管理新架构
新版Docker 1.12将调度功能内建，提供了新的丛集与调度工具Swarmkit，使用了Docker的Service API来管理服务，要做到服务包含任务，而任务由容器来实现，并内建服务生命周期管理，还要将系统状态保存在内建的raft store上，所有服务的负载平衡机制也内建，不需像过去得由外部工具提供。所有容器间的通讯皆预设加密。
Docker为何要内建丛集调度
陈东洛想要透过Swarmkit解决的容器Orchestration需求，包括了如何将任务分配到对应的运算、网路和储存资源上来执行、如何管理系统资源和系统变化（如新增节点或离线）、如何调度任务岛的节点、管理任务的生命周期、协助使用者使用调度工具、实现端到端到安全性确保、另外还要满足公有云、私有云和混合云部署的需求。
因此，新版Docker 1.12所新增Swarmkit，使用了Docker的Service API来管理服务，要做到服务包含任务，而任务由容器来实现，并将服务生命周期管理内建，另外还要能将系统状态保存在内建的raft store上，所有服务的负载平衡机制也内建，不需像过去得由外部工具提供。整个容器丛集内建CA，所有容器间的通讯皆预设加密。
Orchestration才刚起步，导入得先评估需求
儘管用Orchestration来管理大规模容器丛集已经成了Container圈的热门话题，但是，目前这类工具还处于发展初期。上海道客网路科技技术合伙人孙宏亮就坦言，儘管Orchestration确定是主流趋势，但目前才刚在起步阶段，企业类型差异很大，若没有大型企业的人力资源，中小企业导入调度工具前，反而应先将基础做的更踏实，例如改变资源管理方式、强化容器安全管理等。
上海道客网路科技技术合伙人孙宏亮坦言:「儘管Orchestration确定是主流趋势，但目前才刚在起步阶段，若没有足够人力，中小企业导入调度工具前，反而应先将容器管理做得更踏实。」
李响也认为，Orchestration是一个新的领域，目前还缺乏一个共同的抽象层，可供不同的Orchestration平台来遵循。甚至，Timothy Chen认为，目前Orchestration平台大多来自大型网路业者的经验所发展出来的架构，Google的Kubernetes就是最典型的例子，但是每一家企业需要的网路架构、储存需求、资安需求的差异很大，Orchestration平台想要设计一套符合所有需求的通用架构，目前还是一大挑战。
陈东洛表示，在不同应用框架中，各家调度工具的设计有其各自的目标情境，例如网路模式、储存模式、锁定机制上的作法仍有不同，儘管大家都希望能适用更多业务情境，但可能还要1-2年后，出现更常见的使用者模式后，才会出现主流的Orchestration设计模式。
这正意味着，如何选对合乎需求的调度平台，以及上手这些调度工具的门槛成了企业得付出的代价。在Orchestration工具发展初期，企业到底应该等待技术更成熟再採用，还是现在就要一步到位拥抱Orchestration，这成了企业拥抱Container之后的新难题。
陈东洛则建议，企业要回到「调度」需求本身来看，而不只是看规模或数量来决定是否导入Orchestration，他就曾遇过Docker建置规模很大的企业，却不需要使用调度工具，因为他们可能只在一台VM上跑一个容器。调度可解决的需求例如複杂问题，有各种依赖关係，资源大小需求不统一，资源相互竞争时需要保障特定情境的使用等。「这些都是业务面的痛点，找出调度需求的痛点，而不是容器需求的痛点，」他建议，首先该做的是提高对自身业务的了解，妥善监测自家业务的使用情况，再从数据来决定，是不是真有调度需求。
李响则建议可以从Dev和Ops的角度来评估，对开发者而言，产品发布流程卡在维运因素，导致长达2、3个月才能发布一次改版，就可以导入调度，「因为调度工具可以将维运流程自动化，将维运时间缩短到2,3天，不只是让开发者高兴，更可以提高收益。」而对维运团队而言，每次新服务上线后，监控新服务的资源利用率是不是一大难题，若这也是企业维运的痛点，也可以成为一股导入调度工具的动力。若开发或维运都没有遇到这类困难，「第一步是先容器化，而不要一次就导入调度工具。」
打造过维运10万容器PaaS平台的百度资深工程师段兵建议，企业得评估容器化的目的，不一定所有应用都需要容器化，以无状态服务或Web类应用比较适合。百度先从PHP应用开始，结合有迭代改版需求的大型服务，如百度贴吧来降低难度，直到最近才开始将複杂应用迁移到容器环境中，儘管迁移过程问题不少，但对比于未来几年可预期的研发效率提升，还是值得投入。尤其需要深思的是，段兵认为：「拥抱容器和调度平台，不只是技术问题，更是架构变革，连带也会引起组织变革，这是一条长路，得从技术和管理双管齐下。」
百度资深工程师段兵表示：「拥抱容器和调度平台，不只是技术问题，更是架构变革，连带也会引起组织变革，这是一条长路，得从技术和管理双管齐下。」
?相关报导 ?Container平台新挑战：超大规模容器丛集怎幺管？
I 相关 / Other
数读国庆长假：全国零售和餐饮企业销售达1.2万亿 [热事件]
10月7日是国庆黄金周的最后一天。各部门相继发布相关监测数据，繁荣、活跃、平稳、有序成为解读这次黄金周的关键词。市场保持繁荣活跃全国零售和餐饮企业实现销售额约12000亿元商务部7日发布的数据显示：今年十一黄金
【大规模容器丛集实例】百度打造自家PaaS私有云，1人也能维运10万台Container
BOAS架构中最底层的IaaS层，由伺服器、网路、储存等元件组成，并且利用百度自家开发的Matrix丛集作业系统，可对大规模Container进行调度。（图片来源／百度） 从搜寻引擎起家的百度，除了原有的搜寻服务，近年更跨
【大规模容器丛集实例】雷亚游戏借助Kubernetes，3人搞定百万玩家App底层维运
雷亚游戏技术长钟志远解释，Kubernetes不如IaaS的操作，必须深入至VM层级手动建置服务，但是也不受限于PaaS环境的局限，可以在Container环境中选择偏好的技术建置开发环境。（图片来源／雷亚游戏） 席捲IT业界的Co
网络配图女员工排队吻老板惹争议，引发众网友声讨到底是谁在玷污企业文化?北京通州一间销售自酿啤酒机器的公司员工一多半是女性，为了把公司企业文化搞出特色，凝聚员工人心，公司规定：每天早上9点到9点半时间是公司
女员工须每天排队吻老板什么梗 特立独行企业文化聚人心 [非常娱乐]
女员工须每天排队吻老板什么梗 特立独行企业文化聚人心【女员工须每天排队吻老板…[email protected]：北京一间销售自酿啤酒机器的公司员工一多半是女性，为了把公司企业文化搞出特色，凝聚员工人心，公司