本文讲的是滥用容器无伤大雅【编者的话】虚拟化已经深入人心，而容器化方兴未艾，也许有人会担心滥用容器，但是本文告诉大家不用担心，无伤大雅。
虚拟化的曙光为传统的机架和堆栈系统管理员引入了在一个共同的硬件平台上通过适当的逻辑分组来最终同地协作处理工作负载的方式。这意味着我们可以把那些通常很少使用的多余硬件利用起来，并在一个集中的方法中共享CPU、内存、存储和网络能力。
对应于过去习惯的那种每个服务器对应一个应用程序的风格，现在我们如何能做的看起来像一个真正的转变，那么，这一切是如何进行的呢？
我们往往在大多数存储上是不吝提供的，我们使用虚拟机的设计方案，看起来跟对应的物理服务器是几乎相同的，但在更大的服务器上可以切分成更小的但是仍然是很大的虚拟机实例。当我们对虚拟化平台建立了更多的信任时，这是辅助的虚拟化方法。
现在我们越来越有信心了。我们使用P2V（Physical to Virtual）工具来提升当前物理应用程序环境，并且部署它们作为多CPU、大内存、大存储和虚拟机。这就是我们称之为“提升和转变”的方法。
在提升和转变方法以及超大的虚拟机之间，我们正在滥用虚拟化平台，但是没有关系，因为这个给了我们信心让我们重新思考创建和使用虚拟化架构的方法，正如我们在实践中所学到的。
这就是滥用开始的地方，P2V和超大的虚拟机成为了“改变我们IT交付方式”的途径，所以现在容器将会有同样可怕的习惯。我并不是说每个人都会这样做，但是大量的传统虚拟化商店发现自己仍然在过度提供“安全”，安全对这种方法究竟是什么? !
我们看到在生产环境的实现中虚拟机体积是通常超过10GB的，至少1GB的内存。相比之下，我所目睹的许多生产环境中的容器，都是不到768M的内存，并有大小范围从100MB到1GB的临时卷。
当容器使用者和消费者按照横向扩展和微服务架构来思考时，你可以看到方法在大小方面是如何完全不同的，比如更小、更薄的占用和更多的内容。
时刻铭记着容器是被设计为用于横向扩展的应用程序设计的，长时间运行的应用程序在容器中运行并不真正有利。为什么不呢？让我们找出一些容器给我们的红利：
在这四点中没有一点会在基础设施层提供弹性， 它们将弹性放在了应用程序层，因为它们都是被设计为能够迅速提高或下降的，可编程性方面也是如此。
换言之，长期运行的应用程序可能更适合于虚拟机基础设施配合容器基础设施一起工作，以确保提供资源的应用程序和架构需求可以服务于各自的需要。
明天就会用于生产环境吗？答案既是又非。
会用于整个应用程序生命周期管理吗？答案既是又非。
他们将取代VM基础设施吗？不会。
我们会将糟糕的面向虚拟机的设计习惯引入到容器基础设施设计和使用吗？是的，但是没有关系，我们将学习和演化，就像我们针对虚拟化所做的那样。
镜像来源： https://memegenerator.net/instance/69096326
虚拟化的曙光为传统的机架和堆栈系统管理员引入了在一个共同的硬件平台上通过适当的逻辑分组来最终同地协作处理工作负载的方式。这意味着我们可以把那些通常很少使用的多余硬件利用起来，并在一个集中的方法中共享CPU、内存、存储和网络能力。
对应于过去习惯的那种每个服务器对应一个应用程序的风格，现在我们如何能做的看起来像一个真正的转变，那么，这一切是如何进行的呢？
新瓶装旧酒
对于许多人来说，首次涉足虚拟化都会创建一个大型的虚拟机，该虚拟机采用接近2：1或者3：1预留配置比例的共享架构，这是安全的一步，除了我们实际上没有利用虚拟化的方式来提供真正有价值的能力。我们往往在大多数存储上是不吝提供的，我们使用虚拟机的设计方案，看起来跟对应的物理服务器是几乎相同的，但在更大的服务器上可以切分成更小的但是仍然是很大的虚拟机实例。当我们对虚拟化平台建立了更多的信任时，这是辅助的虚拟化方法。
现在我们越来越有信心了。我们使用P2V（Physical to Virtual）工具来提升当前物理应用程序环境，并且部署它们作为多CPU、大内存、大存储和虚拟机。这就是我们称之为“提升和转变”的方法。
在提升和转变方法以及超大的虚拟机之间，我们正在滥用虚拟化平台，但是没有关系，因为这个给了我们信心让我们重新思考创建和使用虚拟化架构的方法，正如我们在实践中所学到的。
进入容器
容器是被设计为虚拟机的简单、轻量级的替代品，容器允许更快速的交付面向应用的基础设施，该基础设施提供更快的启动时间，更好的移植性，因而IT可以更敏捷地交付。这就是滥用开始的地方，P2V和超大的虚拟机成为了“改变我们IT交付方式”的途径，所以现在容器将会有同样可怕的习惯。我并不是说每个人都会这样做，但是大量的传统虚拟化商店发现自己仍然在过度提供“安全”，安全对这种方法究竟是什么? !
小的虚拟机是真正的大容器
虚拟机的平均体积是很大的，相比较而言容器平均下来是极小的，因为设计就是这样的。需要大量的配套应用、运行时、软件库、数据和其他更多支持的工作负载都往往需要放在虚拟机里，因为此时需要更加整体的部署，一个VM的大小甚至可以有5GB。我们看到在生产环境的实现中虚拟机体积是通常超过10GB的，至少1GB的内存。相比之下，我所目睹的许多生产环境中的容器，都是不到768M的内存，并有大小范围从100MB到1GB的临时卷。
当容器使用者和消费者按照横向扩展和微服务架构来思考时，你可以看到方法在大小方面是如何完全不同的，比如更小、更薄的占用和更多的内容。
多福多寿：火神爱VMs
另一个挑战是目前的服务于容器化基础设施的架构都是针对支持应用程序的工作负载能够承受部分中断的，换句话说，容器有更短的生命周期，并且可以（而且应该）能够被终止而不影响整个应用程序的可用性。时刻铭记着容器是被设计为用于横向扩展的应用程序设计的，长时间运行的应用程序在容器中运行并不真正有利。为什么不呢？让我们找出一些容器给我们的红利：
- 更薄的基础系统
- 快速交付
- 快速重启和恢复
- 编排和部署的可编程性
在这四点中没有一点会在基础设施层提供弹性， 它们将弹性放在了应用程序层，因为它们都是被设计为能够迅速提高或下降的，可编程性方面也是如此。
换言之，长期运行的应用程序可能更适合于虚拟机基础设施配合容器基础设施一起工作，以确保提供资源的应用程序和架构需求可以服务于各自的需要。
容器来临
不管怎样，容器基础设施将会成为IT投资的一部分，也许现在已经小规模地成为环境的一部分了。明天就会用于生产环境吗？答案既是又非。
会用于整个应用程序生命周期管理吗？答案既是又非。
他们将取代VM基础设施吗？不会。
我们会将糟糕的面向虚拟机的设计习惯引入到容器基础设施设计和使用吗？是的，但是没有关系，我们将学习和演化，就像我们针对虚拟化所做的那样。
镜像来源： https://memegenerator.net/instance/69096326
原文链接：We are About to Misuse Containers, but it’s OK （翻译：胡震）
原文发布时间为：2016-07-14
本文作者：胡震
本文来自云栖社区合作伙伴Dockerone.io，了解相关信息可以关注Dockerone.io。
原文标题：滥用容器无伤大雅
