一篇容器的前世今生说的清楚的文章

容器的前世今生

物理机

• 部署非常慢
• 购买服务器服务，放在IDC机房，各种走流程，很多流程不可控制流程慢。
• 成本非常高
• 物理的服务器，高额的配置成本贵。
• 资源浪费
• 资源太多了，针对app的服务可能利用率不够充分。
• 难于迁移和扩展
• 迁移app端的服务器，我们要提前准备好一个新的物理服务器，环境需要重新的迁移。资源消耗比较大的话，用户增加比较快需要扩展内存，cpu，硬盘麻烦，可能最后还是选择购买新的物理服务器。
• 可能会被限定硬件厂家
• 那些已经采用RISC架构或非x86平台的用户来说，要想体验到x86平台的高效、便捷就要进行系统迁移。但是对于绝大多数应用来说，迁移可不是一件容易的事儿，甚至有些人更是“谈虎色变”。任何解释性和编译性语言都存在代码的风险。

• 真实的服务器

虚拟机

物理资源的限定和调度，设置指定VM的内存，cpu，硬盘根据应用来进行控制，方便扩展，欢迎可以统一化，方便管理。可以使物理资源的最大化利用。

• 一个物理机部署多个服务
• 在软件中模拟各种操作系统，可以同时运行多个相同或者不同的操作系统方便，可挂起(暂停)，可作快照，可作克隆，在运行的时候占用内存。
• 每个app在独立的VM里
• 每个app都在一台VM里面，互相不干扰不影响。
• 资源池
• 一个物理机的资源分配到了不同的虚拟机里
• 很容易扩展
• 加物理机器 || 加虚拟机
• 很容易云化
• 亚马逊AWS，阿里云，腾讯云，华为云等
• 虚拟机的机构

虚拟机的局限性

每个虚拟机就是一个操作系统，每个操作系统都要分配对应的操作系统资源，大家都用window系统，真正的生产环境一般都是用linux操作系统其中一部分原因就是因为linux系统消耗资源比较少。如果在一个物理服务器上放入10个虚拟机，每个虚拟机系统占用1g资源，等于浪费了10g的内存资源。所以当操作系统越来越多的时候消耗在系统上的资源也就越来越大。

开发和运维面临的问题

上边是开发人员，下面是运维。

开发人员选择了不同语言和环境来进行开发，运维人员为了使应用正常的跑起来需要配置尽量和开发人员开发一样的环境来满足应用的正常使用。

开发人员/运维人员

容器解决了什么问题

docker进行了容器的打包，打包好的容器，可以运行在任何的环境，解决了开发和运维直接的矛盾。开发和运维之间建立了桥梁，这也是时间devops拿手的解决方案。

容器解决了什么

什么是容器

对软件和其依赖的标准化打包

应用之间相互隔离(肯定没有虚拟机和物理机隔离的那么完全)

共享同一个OS Kernel(同一个操作系统上)

可以运行在很多主流的操作系统上(unix，linux，windows等)

容器里面可以放入什么?

虚拟机和容器的区别

虚拟机是物理资源层面的隔离，容器是应用层面的隔离

虚拟化和容器的结合

在国内很多场景都是虚拟化和容器结合来使用的，将物理机进行虚拟化出来多个VM，在VM内部在使用容器化。

3个虚拟机，其中一个虚拟机里面跑这3个Docker

（编辑：ASP站长网）