本文讲的是企业应用快速跨向容器时代的正确姿势【编者的话】文章以通俗易懂的方式详细解读容器的诞生、容器的管理以及容器如何对应打包等问题。
容器是 Container，Container另一个意思是集装箱，其实容器的思想就是要变成软件交付的集装箱。集装箱的特点，一是打包，二是标准。
在没有集装箱的时代，假设将货物从 A运到 B，中间要经过三个码头、换三次船。每次都要将货物卸下船来，摆的七零八落，然后搬上船重新整齐摆好。因此在没有集装箱的时候，每次换船，船员们都要在岸上待几天才能走。
有了集装箱以后，所有的货物都打包在一起了，并且集装箱的尺寸全部一致，所以每次换船的时候，一个箱子整体搬过去就行了，小时级别就能完成，船员再也不用上岸长时间耽搁了。
这是集装箱“打包”、“标准”两大特点在生活中的应用。下面用一个简单的案例来看看容器在开发部署中的实际应用。
假设有一个简单的 Java网站需要上线，代码的运行环境如下：
看，一个简单的 Java网站，就有这么多零零散散的东西！这就像很多零碎的货物，如果不打包，就需要在开发、测试、生产的每个环境上重新查看以保证环境的一致，有时甚至要将这些环境重新搭建一遍，就像每次将货物卸载、重装一样麻烦。中间稍有差池，比如开发环境用了 JDK 1.8，而线上是 JDK 1.7；比如开发环境用了 root用户，线上需要使用 Hadoop用户，都可能导致程序的运行失败。
那么容器如何对应用打包呢？还是要学习集装箱，首先要有个封闭的环境，将货物封装起来，让货物之间互不干扰，互相隔离，这样装货卸货才方便。好在 Ubuntu中的LXC技术早就能做到这一点。
封闭的环境主要使用了两种技术，一种是看起来是隔离的技术，称为 Namespace，也即每个 Namespace中的应用看到的是不同的 IP地址、用户空间、程号等。另一种是用起来是隔离的技术，称为 Cgroups，也即明明整台机器有很多的 CPU、内存，而一个应用只能用其中的一部分。
有了这两项技术，集装箱的铁盒子我们是焊好了，接下来就是决定往里面放什么。
最简单粗暴的方法，就是将上面列表中所有的都放到集装箱里面。但是这样太大了！因为即使你安装一个干干静静的 Ubuntu 操作系统，什么都不装，就很大了。把操作系统装进容器相当于把船也放到了集装箱里面！传统的虚拟机镜像就是这样的，动辄几十G。答案当然是 NO！所以第一项操作系统不能装进容器。
撇下第一项操作系统，剩下的所有的加起来，也就几百 M，就轻便多了。因此一台服务器上的容器是共享操作系统内核的，容器在不同机器之间的迁移不带内核，这也是很多人声称容器是轻量级的虚拟机的原因。轻不白轻，自然隔离性就差了，一个容器让操作系统崩溃了，其他容器也就跟着崩溃了，这相当于一个集装箱把船压漏水了，所有的集装箱一起沉。
另一个需要撇下的就是随着应用的运行而产生并保存在本地的数据。这些数据多以文件的形式存在，例如数据库文件、文本文件。这些文件会随着应用的运行，越来越大，如果这些数据也放在容器里面，会让容器变得很大，影响容器在不同环境的迁移。而且这些数据在开发、测试、线上环境之间的迁移是没有意义的，生产环境不可能用测试环境的文件，所以往往这些数据也是保存在容器外面的存储设备上。这也是为什么人们称容器是无状态的。
至此集装箱焊好了，货物也装进去了，接下来的问题就是如何将这个集装箱标准化，从而在哪艘船上都能运输。这里的标准一个是镜像，一个是容器的运行环境。
所谓的镜像，就是将你焊好集装箱的那一刻，将集装箱的状态保存下来，就像孙悟空说：“定”，集装箱里面就定在了那一刻，然后将这一刻的状态保存成一系列文件。这些文件的格式是标准的，谁看到这些文件都能还原当时定住的那个时刻。将镜像还原成运行时的过程（就是读取镜像文件，还原那个时刻的过程）就是容器运行的过程。除了大名鼎鼎的 Docker，还有其他的容器，例如 AppC、Mesos Container，都能运行容器镜像。所以说容器不等于 Docker。
总而言之，容器是轻量级的、隔离差的、适用于无状态的，可以基于镜像标准实现跨主机、跨环境的随意迁移。
有了容器，使得 PaaS层对于用户自身应用的自动部署变得快速而优雅。容器快就快在两方面：第一，虚拟机启动的时候要先启动操作系统，容器不用启动操作系统，因为是共享内核的；第二，虚拟机启动后使用脚本安装应用，容器不用安装应用，因为已经打包在镜像里面了。所以最终虚拟机的启动是分钟级别，而容器的启动是秒级。容器咋这么神奇？其实一点都不神奇，第一是偷懒少干活了，第二是提前把活干好了。
因为容器启动快，人们往往不会创建一个个小的虚拟机来部署应用，因为这样太浪费时间了，而是创建一个大的虚拟机，然后在大的虚拟机里面再划分容器，而不同的用户不共享大的虚拟机，可以实现操作系统内核的隔离。这又是一次合久必分的过程。由 IaaS层的虚拟机池，划分为更细粒度的容器池。
容器的粒度更加细，管理起来更难管，甚至是手动操作难以应对的。假设你有 100台物理机，其实规模不是太大，用 Excel人工管理是没问题的，但是一台上面开 10台虚拟机，虚拟机的个数就是 1000台，人工管理已经很困难了，但是一台虚拟机里面开 10个容器，就是 10000个容器，你是不是已经彻底放弃人工运维的想法了。
所以容器层面的管理平台是一个新的挑战，关键字就是自动化：
自发现：容器与容器之间的相互配置还能像虚拟机一样，记住 IP地址然后互相配置吗？这么多容器，一旦一台虚拟机挂了重启，IP改变，你怎么记得住应该改哪些配置，列表长度至少万行级别的啊。所以容器之间的配置通过名称来的，无论容器跑到哪台机器上，名称不变，就能访问到。
自修复：容器挂了，或是进程宕机了，能像虚拟机那样登陆上去查看一下进程状态，如果不正常可以重启一下么？那你要登陆万台 Docker了。所以容器的进程挂了，容器就自动挂掉了，然后自动重启。
弹性自伸缩 Auto Scaling：当容器的性能不足的时候，需要手动伸缩、手动部署么？当然也要自动来。
当前火热的容器管理平台有三大流派：
三大容器门派，到底鹿死谁手，谁又能一统江湖，尚未可知。
网易之所以选型 Kubernetes作为自己的容器管理平台，是因为基于 Borg 成熟的经验打造的 Kubernetes为容器编排管理提供了完整的开源方案，并且社区活跃，生态完善，积累了大量分布式、服务化系统架构的最佳实践。
图中中间的就是最核心的两个部分，一个是镜像 Images，一个是容器 Containers。镜像运行起来就是容器。容器运行的过程中，基于原始镜像做了改变，比如安装了程序，添加了文件，也可以提交回去（commit）成为镜像。
如果大家安装过系统，镜像有点像 GHOST镜像，从 GHOST镜像安装一个系统，运行起来，就相当于容器；容器里面自带应用，就像 GHOST镜像安装的系统里面不是裸的操作系统，里面可能安装了微信，QQ，视频播放软件等。安装好的系统使用过程中又安装了其他软件，或者下载了文件，还可以将这个系统重新 GHOST成一个镜像，当其他人通过这个镜像再安装系统的时候，则其他的软件也就自带了。
普通的 GHOST镜像就是一个文件，但是管理不方便。比如如果有十个 GHOST镜像的话，你可能已经记不清楚哪个镜像里面安装了哪个版本的软件了。所以容器镜像有 tag的概念，就是一个标签，比如 dev-1.0，dev-1.1，production-1.1等，凡是能够帮助你区分不同镜像的都可以。
为了镜像的统一管理，有一个镜像库的东西，可以通过 push将本地的镜像放到统一的镜像库中保存，可以通过 pull将镜像库中的镜像拉到本地来。
从镜像运行一个容器可使用下面的命令，如果初步使用 Docker，记下下面这一个命令就可以了。
这行命令会启动一个里面安装了 MySQL的容器。其中 docker run就是运行一个容器；--name就是给这个容器起个名字；-v 就是挂数据盘，将外面的一个目录 /my/own/datadir挂载到容器里面的一个目录 /var/lib/mysql作为数据盘，外面的目录是在容器所运行的主机上的，也可以是远程的一个云盘；-e 是设置容器运行环境的环境变量，环境变量是最常使用的设置参数的方式，例如这里设置 MySQL的密码。mysql:tag就是镜像的名字和标签。
docker stop可以停止这个容器，start可以再启动这个容器，restart可以重启这个容器。在容器内部做了改变，例如安装了新的软件，产生了新的文件，则调用 docker commit变成新的镜像。
镜像生产过程，除了可以通过启动一个 Docker，手动修改，然后调用 docker commit形成新镜像之外，还可以通过书写 Dockerfile，通过 docker build来编译这个 Dockerfile形成新的镜像。为什么要这样做呢？前面的方式太不自动化了，需要手工干预，而且还经常会忘了手工都做了什么。用 Dockerfile可以很好地解决这个问题。
Dockerfile 的一个简单的例子如下：
这其实是一个镜像的生产说明书，Docker build 的过程就是根据这个生产说明书来生产镜像：
这里需要说明一下的就是主程序是 Docker里面的一个重要的概念，虽然镜像里面可以安装很多的程序，但是必须有一个主程序，主程序和容器的生命周期完全一致，主程序在则容器在，主程序亡则容器亡。
容器是一个资源限制的框，但是这个框没有底，全靠主进程撑着，主进程挂了，衣服架子倒了，衣服也就垮了。
了解了如何运行一个独立的容器，接下来介绍如何使用容器管理平台。
多个容器组成一个 Pod，这几个容器亲如兄弟，干的也是相关性很强的活，能够通过 localhost访问彼此，真是兄弟齐心，力可断金。有的任务一帮兄弟还扛不住，就需要多个 Pod合力完成，这个由 ReplicationController进行控制，可以将一个 Pod复制 N个副本，同时承载任务，众人拾柴火焰高。
N个 Pod如果对外散兵作战，一是无法合力，二是给人很乱的感觉，因而需要有一个老大作为代言人，将大家团结起来，一致对外，这就是 Service。老大对外提供统一的虚拟 IP和端口，并将这个 IP和服务名关联起来，访问服务名则自动映射为虚拟 IP。老大的意思就是如果外面要访问我这个团队，喊一声名字就可以，例如”雷锋班，帮敬老院打扫卫生！”，你不用管雷锋班的哪个人去打扫卫生，每个人打扫哪一部分，班长会统一分配。
最上层通过 Namespace分隔完全隔离的环境，例如生产环境，测试环境，开发环境等。就像军队分华北野战军，东北野战军一样。野战军立正，出发，部署一个 Tomcat的 Java应用。
云计算的发展脉络
云计算整个发展过程，用一句话来形容，就是“分久必合，合久必分”。
容器的诞生
云计算解决了基础资源层的弹性伸缩，却没有解决 PaaS层应用随基础资源层弹性伸缩而带来的批量、快速部署问题。于是容器应运而生。容器是 Container，Container另一个意思是集装箱，其实容器的思想就是要变成软件交付的集装箱。集装箱的特点，一是打包，二是标准。
在没有集装箱的时代，假设将货物从 A运到 B，中间要经过三个码头、换三次船。每次都要将货物卸下船来，摆的七零八落，然后搬上船重新整齐摆好。因此在没有集装箱的时候，每次换船，船员们都要在岸上待几天才能走。
有了集装箱以后，所有的货物都打包在一起了，并且集装箱的尺寸全部一致，所以每次换船的时候，一个箱子整体搬过去就行了，小时级别就能完成，船员再也不用上岸长时间耽搁了。
这是集装箱“打包”、“标准”两大特点在生活中的应用。下面用一个简单的案例来看看容器在开发部署中的实际应用。
假设有一个简单的 Java网站需要上线，代码的运行环境如下：
看，一个简单的 Java网站，就有这么多零零散散的东西！这就像很多零碎的货物，如果不打包，就需要在开发、测试、生产的每个环境上重新查看以保证环境的一致，有时甚至要将这些环境重新搭建一遍，就像每次将货物卸载、重装一样麻烦。中间稍有差池，比如开发环境用了 JDK 1.8，而线上是 JDK 1.7；比如开发环境用了 root用户，线上需要使用 Hadoop用户，都可能导致程序的运行失败。
那么容器如何对应用打包呢？还是要学习集装箱，首先要有个封闭的环境，将货物封装起来，让货物之间互不干扰，互相隔离，这样装货卸货才方便。好在 Ubuntu中的LXC技术早就能做到这一点。
封闭的环境主要使用了两种技术，一种是看起来是隔离的技术，称为 Namespace，也即每个 Namespace中的应用看到的是不同的 IP地址、用户空间、程号等。另一种是用起来是隔离的技术，称为 Cgroups，也即明明整台机器有很多的 CPU、内存，而一个应用只能用其中的一部分。
有了这两项技术，集装箱的铁盒子我们是焊好了，接下来就是决定往里面放什么。
最简单粗暴的方法，就是将上面列表中所有的都放到集装箱里面。但是这样太大了！因为即使你安装一个干干静静的 Ubuntu 操作系统，什么都不装，就很大了。把操作系统装进容器相当于把船也放到了集装箱里面！传统的虚拟机镜像就是这样的，动辄几十G。答案当然是 NO！所以第一项操作系统不能装进容器。
撇下第一项操作系统，剩下的所有的加起来，也就几百 M，就轻便多了。因此一台服务器上的容器是共享操作系统内核的，容器在不同机器之间的迁移不带内核，这也是很多人声称容器是轻量级的虚拟机的原因。轻不白轻，自然隔离性就差了，一个容器让操作系统崩溃了，其他容器也就跟着崩溃了，这相当于一个集装箱把船压漏水了，所有的集装箱一起沉。
另一个需要撇下的就是随着应用的运行而产生并保存在本地的数据。这些数据多以文件的形式存在，例如数据库文件、文本文件。这些文件会随着应用的运行，越来越大，如果这些数据也放在容器里面，会让容器变得很大，影响容器在不同环境的迁移。而且这些数据在开发、测试、线上环境之间的迁移是没有意义的，生产环境不可能用测试环境的文件，所以往往这些数据也是保存在容器外面的存储设备上。这也是为什么人们称容器是无状态的。
至此集装箱焊好了，货物也装进去了，接下来的问题就是如何将这个集装箱标准化，从而在哪艘船上都能运输。这里的标准一个是镜像，一个是容器的运行环境。
所谓的镜像，就是将你焊好集装箱的那一刻，将集装箱的状态保存下来，就像孙悟空说：“定”，集装箱里面就定在了那一刻，然后将这一刻的状态保存成一系列文件。这些文件的格式是标准的，谁看到这些文件都能还原当时定住的那个时刻。将镜像还原成运行时的过程（就是读取镜像文件，还原那个时刻的过程）就是容器运行的过程。除了大名鼎鼎的 Docker，还有其他的容器，例如 AppC、Mesos Container，都能运行容器镜像。所以说容器不等于 Docker。
总而言之，容器是轻量级的、隔离差的、适用于无状态的，可以基于镜像标准实现跨主机、跨环境的随意迁移。
有了容器，使得 PaaS层对于用户自身应用的自动部署变得快速而优雅。容器快就快在两方面：第一，虚拟机启动的时候要先启动操作系统，容器不用启动操作系统，因为是共享内核的；第二，虚拟机启动后使用脚本安装应用，容器不用安装应用，因为已经打包在镜像里面了。所以最终虚拟机的启动是分钟级别，而容器的启动是秒级。容器咋这么神奇？其实一点都不神奇，第一是偷懒少干活了，第二是提前把活干好了。
因为容器启动快，人们往往不会创建一个个小的虚拟机来部署应用，因为这样太浪费时间了，而是创建一个大的虚拟机，然后在大的虚拟机里面再划分容器，而不同的用户不共享大的虚拟机，可以实现操作系统内核的隔离。这又是一次合久必分的过程。由 IaaS层的虚拟机池，划分为更细粒度的容器池。
容器管理平台
有了容器的管理平台，又是一次分久必合的过程。容器的粒度更加细，管理起来更难管，甚至是手动操作难以应对的。假设你有 100台物理机，其实规模不是太大，用 Excel人工管理是没问题的，但是一台上面开 10台虚拟机，虚拟机的个数就是 1000台，人工管理已经很困难了，但是一台虚拟机里面开 10个容器，就是 10000个容器，你是不是已经彻底放弃人工运维的想法了。
所以容器层面的管理平台是一个新的挑战，关键字就是自动化：
自发现：容器与容器之间的相互配置还能像虚拟机一样，记住 IP地址然后互相配置吗？这么多容器，一旦一台虚拟机挂了重启，IP改变，你怎么记得住应该改哪些配置，列表长度至少万行级别的啊。所以容器之间的配置通过名称来的，无论容器跑到哪台机器上，名称不变，就能访问到。
自修复：容器挂了，或是进程宕机了，能像虚拟机那样登陆上去查看一下进程状态，如果不正常可以重启一下么？那你要登陆万台 Docker了。所以容器的进程挂了，容器就自动挂掉了，然后自动重启。
弹性自伸缩 Auto Scaling：当容器的性能不足的时候，需要手动伸缩、手动部署么？当然也要自动来。
当前火热的容器管理平台有三大流派：
- 一个是 Kubernetes，我们称为段誉型。
段誉（Kubernetes）的父亲（Borg）武功高强，出身皇族（Google），管理过偌大的一个大理国（Borg是 Google数据中心的容器管理平台）。作为大理段式后裔，段誉的武功基因良好（Kubernetes的理念设计比较完善），周围的高手云集，习武环境也好（Kubernetes生态活跃，热度高），虽然刚刚出道的段誉武功不及其父亲，但是只要跟着周围的高手不断切磋，武功即可飞速提升。 - 一个是 Mesos，我们称为乔峰型。
乔峰（Mesos）的主要功夫降龙十八掌（Mesos的调度功能）独步武林，为其他帮派所无。而且乔峰也管理过人数众多的丐帮（Mesos管理过 Tweeter的容器集群）。后来乔峰从丐帮出来，在江湖中特例独行（Mesos的创始人成立了公司 Mesosphere）。乔峰的优势在于，乔峰的降龙十八掌（Mesos）就是在丐帮中使用的降龙十八掌，相比于段誉初学其父的武功来说，要成熟很多。但是缺点是，降龙十八掌只掌握在少数的几个丐帮帮主手中（Mesos社区还是以 Mesosphere为主导），其他丐帮兄弟只能远远崇拜乔峰，而无法相互切磋（社区热度不足）。 - 一个是 Swarm，我们称为慕容型。
慕容家族（Swarm是 Docker家族的集群管理软件）的个人功夫是非常棒的（Docker可以说称为容器的事实标准），但是看到段誉和乔峰能够管理的组织规模越来越大，有一统江湖的趋势，着实眼红了，于是开始想创建自己的慕容鲜卑帝国（推出 Swarm容器集群管理软件）。但是个人功夫好，并不代表着组织能力强（Swarm的集群管理能力），好在慕容家族可以借鉴段誉和乔峰的组织管理经验，学习各家公司，以彼之道，还施彼身，使得慕容公子的组织能力（Swarm借鉴了很多前面的集群管理思想）也在逐渐的成熟中。
三大容器门派，到底鹿死谁手，谁又能一统江湖，尚未可知。
网易之所以选型 Kubernetes作为自己的容器管理平台，是因为基于 Borg 成熟的经验打造的 Kubernetes为容器编排管理提供了完整的开源方案，并且社区活跃，生态完善，积累了大量分布式、服务化系统架构的最佳实践。
容器初体验
我们先了解一下 Docker的生命周期。如图所示。
图中中间的就是最核心的两个部分，一个是镜像 Images，一个是容器 Containers。镜像运行起来就是容器。容器运行的过程中，基于原始镜像做了改变，比如安装了程序，添加了文件，也可以提交回去（commit）成为镜像。
如果大家安装过系统，镜像有点像 GHOST镜像，从 GHOST镜像安装一个系统，运行起来，就相当于容器；容器里面自带应用，就像 GHOST镜像安装的系统里面不是裸的操作系统，里面可能安装了微信，QQ，视频播放软件等。安装好的系统使用过程中又安装了其他软件，或者下载了文件，还可以将这个系统重新 GHOST成一个镜像，当其他人通过这个镜像再安装系统的时候，则其他的软件也就自带了。
普通的 GHOST镜像就是一个文件，但是管理不方便。比如如果有十个 GHOST镜像的话，你可能已经记不清楚哪个镜像里面安装了哪个版本的软件了。所以容器镜像有 tag的概念，就是一个标签，比如 dev-1.0，dev-1.1，production-1.1等，凡是能够帮助你区分不同镜像的都可以。
为了镜像的统一管理，有一个镜像库的东西，可以通过 push将本地的镜像放到统一的镜像库中保存，可以通过 pull将镜像库中的镜像拉到本地来。
从镜像运行一个容器可使用下面的命令，如果初步使用 Docker，记下下面这一个命令就可以了。
这行命令会启动一个里面安装了 MySQL的容器。其中 docker run就是运行一个容器；--name就是给这个容器起个名字；-v 就是挂数据盘，将外面的一个目录 /my/own/datadir挂载到容器里面的一个目录 /var/lib/mysql作为数据盘，外面的目录是在容器所运行的主机上的，也可以是远程的一个云盘；-e 是设置容器运行环境的环境变量，环境变量是最常使用的设置参数的方式，例如这里设置 MySQL的密码。mysql:tag就是镜像的名字和标签。
docker stop可以停止这个容器，start可以再启动这个容器，restart可以重启这个容器。在容器内部做了改变，例如安装了新的软件，产生了新的文件，则调用 docker commit变成新的镜像。
镜像生产过程，除了可以通过启动一个 Docker，手动修改，然后调用 docker commit形成新镜像之外，还可以通过书写 Dockerfile，通过 docker build来编译这个 Dockerfile形成新的镜像。为什么要这样做呢？前面的方式太不自动化了，需要手工干预，而且还经常会忘了手工都做了什么。用 Dockerfile可以很好地解决这个问题。
Dockerfile 的一个简单的例子如下：
这其实是一个镜像的生产说明书，Docker build 的过程就是根据这个生产说明书来生产镜像：
- FROM基础镜像，先下载这个基础镜像，然后从这个镜像启动一个容器，并且登陆到容器里面；
- RUN 运行一个命令，在容器里面运行这个命令；
- COPY/ADD 将一些文件添加到容器里面；
- 最终给容器设置启动命令 ENTRYPOINT，这个命令不在镜像生成过程中执行，而是在容器运行的时候作为主程序执行；
- 将所有的修改commit成镜像。
这里需要说明一下的就是主程序是 Docker里面的一个重要的概念，虽然镜像里面可以安装很多的程序，但是必须有一个主程序，主程序和容器的生命周期完全一致，主程序在则容器在，主程序亡则容器亡。
容器是一个资源限制的框，但是这个框没有底，全靠主进程撑着，主进程挂了，衣服架子倒了，衣服也就垮了。
了解了如何运行一个独立的容器，接下来介绍如何使用容器管理平台。
容器管理平台初体验
容器管理平台会对容器做更高的抽象，容器不再是单打独斗，而且组成集团军共同战斗。多个容器组成一个 Pod，这几个容器亲如兄弟，干的也是相关性很强的活，能够通过 localhost访问彼此，真是兄弟齐心，力可断金。有的任务一帮兄弟还扛不住，就需要多个 Pod合力完成，这个由 ReplicationController进行控制，可以将一个 Pod复制 N个副本，同时承载任务，众人拾柴火焰高。
N个 Pod如果对外散兵作战，一是无法合力，二是给人很乱的感觉，因而需要有一个老大作为代言人，将大家团结起来，一致对外，这就是 Service。老大对外提供统一的虚拟 IP和端口，并将这个 IP和服务名关联起来，访问服务名则自动映射为虚拟 IP。老大的意思就是如果外面要访问我这个团队，喊一声名字就可以，例如”雷锋班，帮敬老院打扫卫生！”，你不用管雷锋班的哪个人去打扫卫生，每个人打扫哪一部分，班长会统一分配。
最上层通过 Namespace分隔完全隔离的环境，例如生产环境，测试环境，开发环境等。就像军队分华北野战军，东北野战军一样。野战军立正，出发，部署一个 Tomcat的 Java应用。
作者介绍
刘超，网易云首席解决方案架构师，代码级略懂OpenStack、Hadoop、Docker、Lucene、Mesos等开源软件，10多年的云计算架构与开发经历，积累了丰富的企业级应用的微服务化，容器化实战经验，曾出版《Lucene应用开发揭秘》，个人博客可搜索popsuper1982。
原文发布时间为：2017-01-24
本文作者：刘超
本文来自云栖社区合作伙伴Dockerone.io，了解相关信息可以关注Dockerone.io。
原文标题：企业应用快速跨向容器时代的正确姿势
