容器: 云计算的下一步

作者: songtianyi 本文中的大部分内容整理自互联网，如有侵权，请联系本人删除。

前言

云，已是企业 IT 的基本形态。以欧洲和美国为例，截止到 2019 年第一季度，IaaS 平台的覆盖率为 49%。随着企业逐步上云，借助云平台，我们解决了硬件资源的管理和交付的难题，解放了基础运维人员。但应用开发和应用运维人员可能觉得上云前和上云后区别并不大，应用的交付和运维还是很困难。这是一个必须要克服的困难。为什么呢？

数字化转型

答案是，被逼的，被数字化转型逼的，被市场逼的。数字化转型是指利用现代技术和通信手段，改变企业为客户创造价值的方式。比如，银行推出自己的手机 APP，改变服务方式。数字化的浪潮从互联网诞生之时就已经开始了，近年来，随着互联网技术的演进，大数据，人工智能，区块链，物联网等等，新的概念层出不穷，为了能够跟上节奏，企业 IT 不得不进行持续的革新，从而保证资源的交付效率和应用的交付效率，以及客户体验等等，进而保证企业在浪潮中不会掉队。例如，如果你的 APP 交易速度比别人慢，就很有可能会被市场淘汰。做完云基础设施的建设也不保证企业能够高枕无忧。如何克服？目前答案已经很明确了 ，容器。2013 年 docker 发布，拉开了基于容器技术的 IT 变革序幕，容器或者说 docker(容器的事实标准)，以及容器管理平台，如 kubernetes，已经深刻改变了应用交付和运维方式。

容器简史
  1. Unix 版本 7在开发过程中引入Chroot Jail以及 Chroot 系统调用。Chroot jail 被用于“Change Root”，它被认为是最早的容器化技术之一。它允许将进程及其子进程与操作系统的其余部分隔离开来。这种隔离的唯一问题是根进程（root process）可以轻松地退出 chroot, 未实现安全机制。FreeBSD Jail于 2000 年在 FreeBSD OS 中引入，旨在为简单的 Chroot 文件隔离带来更多安全性。与 Chroot 不同，FreeBSD 还实现了将进程及其活动隔离到文件系统的特定视图中。比如，你可以将一个 qcow2 镜像文件挂载到 linux 系统中，使用 chroot 将根目录切换到镜像文件的系统根目录，并运行程序，程序所读写的文件都是镜像文件，host 系统的文件都被隔离开了。但 chroot 机制不能限制系统资源的使用，如 I/O, CPU, 内存。
  2. 当 Linux 内核具有操作系统级的虚拟化的功能以后，Linux VServer于 2001 年被推出，它使用了类似 chroot 的机制与“安全上下文”（“security context”）以及操作系统虚拟化（容器化）相结合来提供虚拟化解决方案。它比简单的 chroot 更先进，允许您在单个 Linux 发行版（VPS）上运行多个 Linux 发行版。
  3. 2005 年，OpenVZ的第一个版本推出。OpenVZ 与 Linux-VServer 一样，使用操作系统级虚拟化，许多托管公司采用它来隔离和销售 VPS。操作系统级虚拟化有一些限制，因为容器共享相同的体系结构和内核版本，当客户需要不同于主机的内核版本的情况下这种缺点就会显现出来。
  4. 2007 年，谷歌发布了CGroups，这是一种机制，这种机制能限制和隔离一系列进程的资源使用（CPU，内存，磁盘 I / O，网络等）。与 OpenVZ 内核相反，CGroups 在 2007 年集成进了 Linux 内核。
  5. 2008 年，**LXC（Linux containers，Linux 容器）**的第一个版本发布。LXC 与 OpenVZ，Solaris Containers 和 Linux-VServer 类似，但是它使用的是已经在 Linux 内核中实现的 CGroup。
  6. 2013 年，Docker推出了的第一个版本。它像 OpenVZ 一样，实现操作系统级虚拟化。
容器大战

docker 发布之后便迅速占领市场，吸引了一众厂商参与，包括云计算的领头羊 amazon，google，ibm，微软等。docker 在构建，交付和运行分布式应用方面具有无可比拟的优势。彼时，云计算方兴未艾，硬件虚拟化(hardware-level-virtualization)占统治地位，docker 的发布让大家看到了大规模操作系统级虚拟化(os-level-virtualization)的可能性，为了不在云计算领域掉队，接受并参与 docker 是最好的选择。另一方面，IT 基础设施和应用架构在发生变化。企业上云的过程中，基础环境变得复杂，有的服务跑在硬件物理机上，有的跑在虚拟机上，既有本地数据中心，又有灾备数据中心; 在互联网时代，为了实现应用的快速开发迭代，和更好的弹性伸缩，互联网应用不再采用传统的三层架构，而是使用微服务的方式来实现软件系统的松耦合，因此应用的数量成倍地增长，给应用的交付带来巨大压力。因此，docker 的诞生适逢其时。docker 发布之后，coreos 成为其第二大贡献者，不久之后 coreos 和 docker 决裂，转而发布了 Rocket，docker 并没有什么硬伤，加上先入为主，Rocket 最终完败。在 PaaS 方面，2014 年 6 月 6 号，Google 发布了 kubernetes，并拉了 RedHat 参与，RedHat 基于 kubernetes 开发了企业级 kubernetes 平台 openshift；2014 年 12 月，docker 发布 swarm 项目；2015 年，Mesosphere 发布了基于 mesos 的 Marathon 项目。混战持续至 2017 年，最终 kubernetes 一统天下，docker 公司在自己的企业版 docker 中内置了 kubernetes。

软件交付革新

docker 项目发布时, 也是 LXC 的一个使用者，在容器方面和 CloudFoundry 并没有本质区别，属于组合式创新。但 docker 有一个杀手锏，那就是容器镜像。docker image 直接将应用所需的运行环境即操作系统也打包了进去，解决了运行环境的一致性问题，要知道维护一两台机器的一致性和几万台机器的一致性可是完全不同的，这种问题如果没有完善的监控是很难 debug 的; docker image 可以在任何支持 docker 的 linux 发行版上运行，屏蔽了系统间的差异; 镜像仓库解决了镜像在分布式环境的分发问题; 镜像引入了分层，commit 的概念，保证了分发的效率。最终，软件的交付形式由二进制/脚本变成了镜像。

渗透

docker 的诞生，让 PaaS 迎来了第二春，docker 体系是以“单一容器”为核心的应用定义方式，应用的生命周期管理都是基于单个容器的，而我们交付给用户的往往是一组容器，这些容器在分布式环境下的网络互通及隔离问题，存储怎么共享，docker 都没能给出答案。虽然 docker 引入了 docker-compose 来解决容器编排的问题，但面对大规模的分布式应用，docker-compose 仍然显得捉襟见肘。最终，基于 docker 平台的 kubernetes 在 Google 近十年的容器化基础设施方面的经验的加持下，取得了最终的领导地位，奠定了容器化基础设施的标准。kubernetes 对容器编排以及网络，存储进行更高层次的抽象，提供插件式的支持方案，以及它的声明式 API 重新定义了云时代的“应用”的概念，对于 kubernets 来说，应用是一组容器的有机组合，同时也包括了应用运行所需的网络／存储的需求描述。从而，docker 从软件交付渗透到了应用的定义，编排，交付及管理这一更高层次，成为基础设施中的基石。docker 的诞生还催生了 FAAS 这一新的生态，比较典型的例子是 aws 的 lambda, docker 和 kubernetes 可以让我们把更多的精力放在业务逻辑而不是应用的交付及运维上，而 FAAS 则完全无需关心应用的交付及运维。

焦虑

最近 ETC 营销大战的新闻大家应该有所耳闻，各个银行绞尽脑汁地去亏本获客，说明传统金融行业在 2013 年被余额宝打蒙之后已经缓过神来了，已经具备了一定的互联网思维。在这个不进则退的时代，面对互联网技术日新月异的变化，传统金融公司由于包袱重，反应稍显迟钝，会产生掉队的焦虑。消除焦虑最好的方式是去了解和跟踪这些技术，可以成立专门的部门来负责技术的调研和落地。