本文讲的是把容器当作迷你虚拟机使用不是云原生！【编者的话】云服务和SaaS厂商创造了微服务的概念和“
云原生
”模型，以便在持续开发和运营过程中实现高效扩展。对于Facebook、Google或eBay这类始终在线的全球服务而言，传统的方法已不适用。容器与Docker作为此类微服务的终极打包工具应运而生，而
Kubernetes
、
Docker Swarm
和
DC/OS
这类新的编排平台则负责其部署、调度及生命周期的处理。Serverless及FaaS基本上就是这个模型更加自动化的一种演进。
【深入浅出学习 etcd】etcd为分布式系统提供可靠、高效的配置管理服务，在Docker、Kubernetes、Mesos等平台中扮演了越来越重要的角色。作为2013年开始的项目，它还很年轻，官方文档中缺乏实现上全面、系统的介绍，本课程深入浅出地介绍了etcd的实现，并为运维和二次开发提供了系统的指导和建议。
如果我们希望能动态地进行扩展、处理故障或修改版本，微服务就不能是有状态的。与传统应用不同，微服务使用的是不可变镜像，并将配置、日志、状态及数据储存在弹性云数据服务（对象、NoSQL/NewSQL、日志/消息流）中。
云数据服务通常是将一组商用服务器（具有本地磁盘）集群起来构建而成。我们要么使用预集成的云提供商数据服务，要么使用开源或商业软件来运行自己的数据服务。
开发人员和企业主立即就能感受到云原生方式的益处：这让他们可以使用一个敏捷的、持续的方法更快地进行应用开发，同时其弹性扩展可满足需求的波动。
上周在奥斯汀举行的 DockerCon 上，我看到一些厂商试图让容器像VMware或OpenStack那样工作。最极端的例子是将SAN或超聚合块存储作为“容器问题”的解决方案。其间，我与三个主要存储厂商的交流大致如此：
我： 你们的产品能为容器做什么？
他们： 我们负责编排容器块存储卷的创建、配备文件系统、快照、去重等等。
我： 但是我为什么需要这个，Docker提供了一个（不可变的、去重的）镜像文件系统，并且持久化数据是可选的，期望的是文件或数据库抽象层（不是虚拟磁盘）吧？
他们： 哦，这就是为什么我们复杂的自动化系统要分配并配备块空间、在磁盘卷上创建一个（具有固定容量的）文件系统并将其附加到容器中。
我： 但是磁盘卷无法在微服务之间共享（对于弹性而言这是非常基本的），而我希望容器是弹性的而非固定的。我可以使用一个共享文件系统，为什么还要让自己陷入一堆配置磁盘容量和格式化文件系统的麻烦中？难道我不能将共享文件系统挂载到容器中？
他们： 是的，正确的解决方案是使用一个集群的/共享的文件系统或对象，不过对我们来说开发过于困难，我们还无法提供。可能未来会有。对NoSQL数据库这类持久化系统，我们确实能提供价值。
我： 没错。难道我不能使用 Cassandra 、 MongoDB 、 Elasticsearch 自己的方案？它们全都在应用级别上进行分布和复制。它们内置了版本（快照）功能，当然，因为它是分布式的，所以我们无法在存储中一致地创建其快照。我还注意到它们提供了压缩技术，实际上更适用于短期（本地）存储。
他们： 哦，这点我们不清楚。当我们与IT人员（不是开发人员）讨论时，我们听到的是他们想将遗留应用和数据库运行在容器中，就像运行虚拟机一样！
……这凸显了围绕容器与现代云技术的混乱状态——开发人员与基础设施团队之间仍然存在着巨大的信息鸿沟。
如果你寻求的最快上线的方法，而不担心性能、技术锁定或长期预算，又或者你的公司比较小，可以使用一个公有云及其原生服务。使用一个容器编排系统，最好是开源的，比如Kubernetes。使用弹性云原生对象存储、数据库及消息系统，将精力放在无状态应用上。你甚至可以使用“serverless”来免除编排和CI/CD工具。
或者，如果你的公司足够大，又或者你关心性能和数据局部性，可以像云提供商而非传统应用那样进行构建。构建基准云原生服务，包括对象存储、日志、监控、身份管理、配置管理、消息、编排等等。使用开源工具或更健壮的商业产品。需要注意的是，为了保证效率和健壮性，对象存储、数据库或集群文件系统这类数据服务最好像公有云那样使用专有服务器，它们具备更高的磁盘或闪存性能。
创建类似公有云的服务之后即可添加无状态应用程序及应用程序生命周期管理工具，它们将通过服务绑定（比如URL和证书）挂接到基础设施服务中。
【深入浅出学习 etcd】etcd为分布式系统提供可靠、高效的配置管理服务，在Docker、Kubernetes、Mesos等平台中扮演了越来越重要的角色。作为2013年开始的项目，它还很年轻，官方文档中缺乏实现上全面、系统的介绍，本课程深入浅出地介绍了etcd的实现，并为运维和二次开发提供了系统的指导和建议。
云原生意味着什么
我们希望交付的是随着时间推移而演进或扩展的弹性应用。实现的方式是将应用打散成多个层级（微服务），每一层都具有自己的弹性扩展能力，然后通过可靠的消息在这些微服务之间进行通信。如果我们希望能动态地进行扩展、处理故障或修改版本，微服务就不能是有状态的。与传统应用不同，微服务使用的是不可变镜像，并将配置、日志、状态及数据储存在弹性云数据服务（对象、NoSQL/NewSQL、日志/消息流）中。
云数据服务通常是将一组商用服务器（具有本地磁盘）集群起来构建而成。我们要么使用预集成的云提供商数据服务，要么使用开源或商业软件来运行自己的数据服务。
开发人员和企业主立即就能感受到云原生方式的益处：这让他们可以使用一个敏捷的、持续的方法更快地进行应用开发，同时其弹性扩展可满足需求的波动。
为什么容器不是虚拟机
传统基础设施团队与厂商和云用户与提供商的想法不同。他们依然以虚拟机、虚拟网卡和虚拟磁盘（虚拟基础设施，即“私有云”）来看待这个世界，并试图让容器兼容现有的做法。这意味着他们将重心放在重构遗留的或单体的应用，以便其运行于容器中，从中获得的打包自动化好处最少，敏捷、弹性及CI/CD不在其列。他们也可能将那些应用保留在虚拟机中，并将其遗忘。上周在奥斯汀举行的 DockerCon 上，我看到一些厂商试图让容器像VMware或OpenStack那样工作。最极端的例子是将SAN或超聚合块存储作为“容器问题”的解决方案。其间，我与三个主要存储厂商的交流大致如此：
我： 你们的产品能为容器做什么？
他们： 我们负责编排容器块存储卷的创建、配备文件系统、快照、去重等等。
我： 但是我为什么需要这个，Docker提供了一个（不可变的、去重的）镜像文件系统，并且持久化数据是可选的，期望的是文件或数据库抽象层（不是虚拟磁盘）吧？
他们： 哦，这就是为什么我们复杂的自动化系统要分配并配备块空间、在磁盘卷上创建一个（具有固定容量的）文件系统并将其附加到容器中。
我： 但是磁盘卷无法在微服务之间共享（对于弹性而言这是非常基本的），而我希望容器是弹性的而非固定的。我可以使用一个共享文件系统，为什么还要让自己陷入一堆配置磁盘容量和格式化文件系统的麻烦中？难道我不能将共享文件系统挂载到容器中？
他们： 是的，正确的解决方案是使用一个集群的/共享的文件系统或对象，不过对我们来说开发过于困难，我们还无法提供。可能未来会有。对NoSQL数据库这类持久化系统，我们确实能提供价值。
我： 没错。难道我不能使用 Cassandra 、 MongoDB 、 Elasticsearch 自己的方案？它们全都在应用级别上进行分布和复制。它们内置了版本（快照）功能，当然，因为它是分布式的，所以我们无法在存储中一致地创建其快照。我还注意到它们提供了压缩技术，实际上更适用于短期（本地）存储。
他们： 哦，这点我们不清楚。当我们与IT人员（不是开发人员）讨论时，我们听到的是他们想将遗留应用和数据库运行在容器中，就像运行虚拟机一样！
……这凸显了围绕容器与现代云技术的混乱状态——开发人员与基础设施团队之间仍然存在着巨大的信息鸿沟。
多走一步，把重点放在云原生上
那么，要如何构建云原生？不要被各种宣传所迷惑，多做思考。有两种方式来解决这个问题：如果你寻求的最快上线的方法，而不担心性能、技术锁定或长期预算，又或者你的公司比较小，可以使用一个公有云及其原生服务。使用一个容器编排系统，最好是开源的，比如Kubernetes。使用弹性云原生对象存储、数据库及消息系统，将精力放在无状态应用上。你甚至可以使用“serverless”来免除编排和CI/CD工具。
或者，如果你的公司足够大，又或者你关心性能和数据局部性，可以像云提供商而非传统应用那样进行构建。构建基准云原生服务，包括对象存储、日志、监控、身份管理、配置管理、消息、编排等等。使用开源工具或更健壮的商业产品。需要注意的是，为了保证效率和健壮性，对象存储、数据库或集群文件系统这类数据服务最好像公有云那样使用专有服务器，它们具备更高的磁盘或闪存性能。
创建类似公有云的服务之后即可添加无状态应用程序及应用程序生命周期管理工具，它们将通过服务绑定（比如URL和证书）挂接到基础设施服务中。
原文链接：Using Containers As Mini-VMs is NOT Cloud-Native!（翻译：梁晓勇）
原文发布时间为：2017-05-23
本文作者：梁晓勇
本文来自云栖社区合作伙伴Dockerone.io，了解相关信息可以关注Dockerone.io。
原文标题：把容器当作迷你虚拟机使用不是云原生！
