容器与镜像的关系
在实际操作中，我们配置好需要的容器之后可以将它转化为镜像提交到仓库，以便之后使用。
先看一下容器与镜像的转换关系图:
容器提交(docker commit)
根据容器生成一个新的镜像
命令格式:docker commit [参数] 容器[版本]
常用参数:
-a 添加作者 -c 为创建的镜像加入Dockerfile命令 -m 类似git commit -m -p 提交时暂停容器
容器导出(docker export)
将当前容器导出为TAR文件
命令格式:docker export [参数] 容器
常用参数:-o 指定写入的文件
容器导入(docker import)
将之前导出的容器文件导入并创建为一个镜像
命令格式:docker import [参数] 文件|链接|[版本信息]
常用参数:
-m 导入时添加提交信息 -c 为创建的镜像加入Dockerfile命令
docker import 与 docker commit 的区别
当你使用docker import 时，导入的镜像是一个全新镜像，是无法使用docker history查看到镜像的历史信息，使用docker commit 导入时，生成的镜像可以使用docker history查看到镜像的历史信息的。
深入理解Docker容器和镜像
在docker文章的第一篇，我和大家简单的比喻了镜像和容器的关系，有位读者就这个问题和我讨论了一番，这里就这个问题做一个简单的描述，深入理解下镜像和容器。
在镜像层面上:
当我们查看镜像详细信息时，可以看到以下信息:
这里的Layers指的就是一个个只读的文件系统，镜像就是由这样一个个文件系统组成的，我们把镜像运行起来就会成为一个个容器，当我们在容器中做了修改并commit为镜像后，就会不断在原有的Layers层上新增一个Layer层，就像下面看到的这样。
镜像的Layer
所以当我们commit后，我们看到的镜像就是最上层的Layer。
镜像的视角
在容器层面上:
当我们使用docker create [image id]用指定镜像创建容器时，可以理解为在镜像的最上层创建了一个可读可写的Layer，当我们修改完，使用commit提交后，这个容器的可读可写的Layer层就会转化为镜像的只读的Layer层。
而当我们使用docker inspect查看容器的时候只能查看到最上层容器的信息而无法查看到像镜像那样的Layers，这是因为在容器的视角中Layer层是这样的:
当容器中有进程运行时:
容器内部是这样的:
总结
关于深入理解镜像和容器的部分，如若有理解错误的地方希望大家指正，这一部分有些抽象大家可以结合实际操作加深理解，也欢迎各路大佬一起交流探讨。
