Red Hat收购CoreOS的真正原因

上周，企业开源领头羊Red Hat发表声明将收购CoreOS，一个在火热的容器市场中大有前途的玩家。表面上看，这次交易的动机很明显：Red Hat需要让自己的容器故事更加丰满，而CoreOS满足这个需求。然而，就像基础设施市场的绝大多数厂商一样，他们的（意图）是复杂的——正如容器世界中所有其他事物都是复杂的一样。可能会有人说，复杂度是关键。让容器企业就绪自从Docker公司2014年将容器技术带到

Docker_

4079人浏览 · 2018-02-13 00:00:00

Docker_ · 2018-02-13 00:00:00 发布

上周，企业开源领头羊Red Hat发表声明将收购CoreOS，一个在火热的容器市场中大有前途的玩家。

表面上看，这次交易的动机很明显：Red Hat需要让自己的容器故事更加丰满，而CoreOS满足这个需求。

然而，就像基础设施市场的绝大多数厂商一样，他们的（意图）是复杂的——正如容器世界中所有其他事物都是复杂的一样。

可能会有人说，复杂度是关键。

让容器企业就绪

自从Docker公司2014年将容器技术带到企业基础设施软件革命前线之后，厂商和企业的开发者一直在真正的企业场景中实现容器技术的应用。

容器编排和容器管理是众多缺失的环节中的两个。容器编排能使企业大规模部署容器，处理弹性伸缩中的细枝末节，对容器的价值主张至关重要。

容器管理是容器编排价值主张的补充。它使容器编排的环境具有可见性和可控制性，并增强其安全性，使其具备企业层面上运行容器其他必需的能力。

领导着容器编排战场的是Kubernetes——一个主要出自Google的开源项目。Docker有自带的编排工具Swarm，但是Kubernetes具有产品成熟度的优势，已经在生机勃勃的开源生态系统中夺取了统治者地位。

但是Kubernetes并没有直接解决容器管理中的复杂度问题，这正是CoreOS试图用自己的Tectonic产品来填补的空档。“Tectonic将领先的容器管理解决方案和大规模运行容器所有所需结合起来”，CoreOS的网站这样说道，“这意味着其拥有最好的开源组件，久经沙场的安全系统，和完全自动化的运营。Tectonic是企业级Kubernetes。”

复杂度的挑战

如果用来满足企业需求在技术层面听起来很复杂，那你的感觉没错——容器自身的复杂度是一个有争议的区域。“与平台自身不一样，构建Kubernetes自身这个日常的预先任务是复杂艰难的”，RackN的CEO和创始人之一Rob Hirschfeld说，“多节点运营是复杂的：这是我们想要Kubernetes这样平台的原因”。

但是，Kubernetes却没有让容器变得更简单。“实际的情况是Kubernetes很复杂。安装好并让它运行起来颇具挑战——没有必要否认这一点。但是这种复杂度也可以反过来说是一个好处”，Matt Rogish，ReactiveOps的创始人说。“ECS和Docker Swarm表面看来似乎简单点，但是它们有更高的偶然复杂度——而且这个复杂度被强加给你。相反，Kubernetes偶然复杂度很低，本质复杂度（用来实现实际上需要的功能的复杂度）很高”。

在Kubernetes上增加额外的像CoreOS Tectonic的容器管理层也并没有降低其复杂度。反而是为了帮助机构管理它。“基于容器的应用正驱动着下一代的技术，它们跨多个或者混合云平台应用驱动，包括物理的、虚拟的，私有云和公有云平台”，Paul Cormier，Red Hat的产品和技术部门总裁说。“我们相信这次收购将会奠定Red Hat在混合云和现代应用部署的奠基石地位”。

似曾相识的复杂度：OpenStack

有巨大复杂度的开源企业基础设施软件并不是什么新鲜事。拿OpenStack为例，这个私有云基础设施先驱有大量的活动部件，它的生态系统十分多元化、拥挤不堪，这为它赢得了格外复杂和难以处理的名声。好几年我们都听到OpenStack这同样的事情”，RackN的Hirschfeld说道。

一点也不让人意外的是，过去几年吸引到OpenStack的注意力都转移到了Kubernetes和容器社区的其他地方——今天，OpenStack已经成了像CoreOS Tectonic这样的科技要解决的复杂度。CoreOS的官网上称，“Tectonic是全面Kubernetes解决方案，用来在任何地方部署、管理、和安全加固容器，它能结合OpenStack的优点，和Kubernetes的基于容器的工具链。有CoreOS在你左右，借助最好的容器基础设施，OpenStack将变的更容易管理和部署”。

CoreOS的网站继续说道，“OpenStack在复杂度方面的名声有时候盖过了它的能力。Kubernetes集群编排能让OpenStack的管理和管理更加容易”。

对于Red Hat来说，OpenStack的复杂度是一个它能帮助客户解决的问题。“容器使得应用在混合云环境具有了可移植性，所以客户今天能在不同的地方部署应用：在Amazon、Azure和Google这样的公有云上，在VMWare和OpenStack这样的本地部署平台上，或者在物理裸机上”，Joe Fernanes，Red Hat的负责OpenShift产品部资深管理经理解释说，“一直以来，我们在OpenShift和Kubernetes以及容器上的投入都是要建立起这种抽象，使得应用可以高效地在所有这些地方部署”。

Alex Polvi，CoreOS的CEO，在这个话题上发表了更加细致的观点。“通过把OpenStack作为一个应用在Kubernetes运行，我们能将这个数据中心整合成一个已经被超大规模的巨头验证的平台”。

Red Hat的开源策略

Red Hat的商业模型集中在为本质上免费开源的软件提供支持和服务。然而，尽管CoreOS是基于开源构建的，Tectonic也包含商业代码。“我们想特别澄清的是CoreOS专注于开源项目和协作，即使这意味着我们对手可以与我们竞争，我们在保持这两个平台分离”，Kelsey Hightower在2015年当他还是CoreOS的开发者和提倡者的时候这样说。他现在是Google的Staff Developer Advocate。“有一个coreos.com，其是关于Linux容器开源项目的；然后tectonic.com是将这些项目结合起来组成一个商业解决方案的，但是它们并不与相关开源项目冲突”。

就其本身而言，Red Hat一直以来都是Kubernetes的一个主要贡献方。“Red Hat在拥抱容器和容器编排方面起步早，已经向相关的开源社区做了深度贡献，其中就包括Kubernetes，在其中是仅次于Google的第二大领导者。”Red Hat在一个新闻发布上解释道：“现在有了Red Hat和CoreOS的结合，Red Hat同时扩大了其在上游社区和基于容器的企业解决方案方面的领导力。”

在Red Hat是否会将Tectonic中的商业代码开源这一件事情上，他们的态度很谨慎。“CoreOS的绝大多数技术都已经开源”，Red Hat的FAQ列表解释道，“Red Hat长久以来都展示了将不开源的在必要时候开源的决心，我们没有理由看到我们在这条策略上会有什么改变”。

整理总结

作为一个开源厂商，Red Hat不是从软件的知识产权中获利——因此，CoreOS的IP价值对于这次收购关系很小。

这个故事实际上是关于人的，CoreOS公司有130名员工，从很多方面看这次交易是一次收购式招聘，同时借助Red Hat的专业团队来将为其企业客户提供了更加全方位服务。

相比较而言，这次交易与Red Hat的传统竞争者IBM和Oracle关系较小，与Docker公司竞争的关系更大。“它们的联合对于我而言是一次人才的合并……能壮大OpenShift Enterprise相较于Docker公司的Docker企业版的影响力”，BoxBoat的CTO，Will Kinard说。

OpenShift是Red Hat的PaaS方案，而且有一些CoreOS的技术和人力将会分别在OpenShift产品和OpenShift团队中找到更好的位置。

Janakiram & Associates分析师Janakiram MSV同意这种观点。“在企业领域，Red Hat是Docker公司的一个关键竞争者。这次收购将会给Docker公司带来压力，它们目前为止已经从不同的投资方募集到2.4亿美元。它必须加快在获取企业客户的速度，并且推动其商业产品的采用率。”

然而，对于Red Hat的客户来说，这场战斗是关于人才的——这是一个OpenStack和Kubernetes相继追随的模式。“客户不具有OpenStack的技术积累，它们只知道它们需要它”，Jon Keller，Technologent的field CTO说。“对于Kubernetes是同样的情况。它十分合适，因为它们无法找到足够多的人来自己做”。

容器生态如此复杂因而对于Red Hat来说是一个加分，特别是在混合IT情景增加了额外的复杂度的情况下。“我们相信这次收购会为Red Hat在混合云和现代应用部署打好奠基石”，Red Hat的Cormier总结说。

总之，Red Hat的客户成为最后的赢家。“我们相信我们最大的客户将会从中获益”，Red Hat的VP和总经理Ashesh Badani说。

CoreOS的技术和团队在Kubernetes方面已经具有全面的能力，它们的加入在混合IT的情景下能呈现出在今天可能最可靠和全面的现代基础设施。随着整个容器生态系统走向成熟，Red Hat的统治只会变得愈来愈强。

原文链接：https://www.forbes.com/sites/jasonbloomberg/2018/02/04/the-real-reason-red-hat-is-acquiring-coreos

Kubernetes 实战培训

本次培训内容包括：Docker容器的原理与基本操作；容器网络与存储解析；Kubernetes的架构与设计理念详解；Kubernetes的资源对象使用说明；Kubernetes 中的开放接口CRI、CNI、CSI解析；Kubernetes监控、网络、日志管理；容器应用的开发流程详解等，点击识别下方二维码加微信好友了解 具体培训内容。

3月23日开始上课，点击阅读原文链接即可报名。

向您推荐>>Eolink开发者社区

权威｜前沿｜技术｜干货｜国内首个API全生命周期开发者社区

更多推荐

ELK实现containerd的容器日志采集展示【基于logging的全栈监测】

企业级ELK Stack构建介绍

云原生

深入理解 Mocha 测试框架：从零实现一个 Mocha

前言什么是自动化测试自动化测试在很多团队中都是Devops环节中很难执行起来的一个环节，主要原因在于测试代码的编写工作很难抽象，99%的场景都需要和业务强绑定，而且写测试代码的编写工作量往往比编写实际业务代码的工作量更多。在一些很多业务场景中投入产出比很低，适合写自动化测试的应该是那些中长期业务以及一些诸如组件一样的基础库。自动化测试是个比较大的概念，其中分类也比较多，比如单元测试，端对端测试，集

云原生

(20200916 Solved)docker-compose up创建容器自动退出

问题描述如题，创建容器后自动退出了。并且docker start container无效解决方案原因是缺失了控制终端的配置，需要在docker-compose.yml中增加tty:true ，有时候这样也不行，需要再增加一个command:/bin/bash，命令不一定是这个，需要是一个不会退出的命令，然后用-d后台启动容器。Referencesdocker-compose启动容器后自动退出...