Docker是个很好的工具，刚开始用觉得还没虚拟环境好用，随着深入了解，越发觉得Docker好用，今天就来总结一下使用心得。

一、Docker基础

1、背景知识

1）docker是什么？

      Docker 属于 Linux 容器的一种封装，提供简单易用的容器使用接口。它是目前最流行的 Linux 容器解决方案。

Docker 将应用程序与该程序的依赖，打包在一个文件里面。运行这个文件，就会生成一个虚拟容器。程序在这个虚拟容器里运行，就好像在真实的物理机上运行一样。有了 Docker，就不用担心环境问题。总体来说，Docker 的接口相当简单，用户可以方便地创建和使用容器，把自己的应用放入容器。容器还可以进行版本管理、复制、分享、修改，就像管理普通的代码一样。

注册服务器（repository），仓库（registry），镜像（image），容器（container）之间的关系：注册服务器主要是用来存放仓库的服务器，在一个服务器上有多个仓库，而仓库又可以分为公共仓库和私有仓库，一个仓库里面有可以有多个镜像，而容器则是镜像的一个实例

 

    下图是docker组件：



      Docker之所以火的很快，原因之一就是它的仓库。仓库类似于github，很多现成的镜像供各位下载，直接用docker pull redis-server(这个名字是瞎起的)就可以拉下来一个redis服务器的镜像，放到自己的docker里就能用了，不用自己解决依赖、安装redis。好多开源工具都有docker镜像，这就使得用户只需要下载使用就行，完全省去了处理软件依赖、缺少库文件、安装部署等环节。

2） docker用途，目前有三大类

（1）提供一次性的环境。比如，本地测试他人的软件、持续集成的时候提供单元测试和构建的环境。

（2）提供弹性的云服务。因为 Docker 容器可以随开随关，很适合动态扩容和缩容。

（3）组建微服务架构。通过多个容器，一台机器可以跑多个服务，因此在本机就可以模拟出微服务架构。

2、docker安装：

1）Windows安装，推荐使用win10，参考我的另一篇博客---windows10安装docker以及挂在在pycharm

2）Mac安装，参考博客---Mac平台上Docker安装与使用

3)  Centos安装

    在centos下，如果有epel源直接yum install docker-io就完成安装了。

    

    /etc/init.d/docker start启动docker。

4）Ubuntu安装

    sudo apt-get remove debian-keyringdebian-archive-keyring

    sudo apt-get clean

    sudo apt-get update && sudo apt-get-y install debian-keyring debian-archive-keyring

    wget -qO- https://get.Docker.com/ | sh

    注：如果ubuntu启用了ufw，要配置使其能转发请求，并允许2375端口访问外网。

3、docker命令

 

在知道docker命令之前，有必要弄清楚镜像和容器的差别，简单来说，镜像是静止的，容器是动态的，镜像运行起来就是容器，下边是我认为比较好的一篇博客---docker容器和镜像区别

 

以下命令最好使用管理员权限运行，避免出错。

 

1、镜像

1）获取镜像：docker pull  images-name

2）查看所有镜像：docker images 

3）删除镜像：docker rmi image-id

4）保存镜像：docker commit -m="description about images" --author="author" {container_id}  {repository/images_name:tag}

5）推送镜像到代码仓库（可以后面的阅读完在看这个），以阿里云docker平台为例：

①  docker login --username=your_username registry.cn-beijing.aliyuncs.com
②  docker tag [ImageId] registry.cn-beijing.aliyuncs.com/[命名空间]/[仓库名称]:[镜像版本号]
③  docker push registry.cn-beijing.aliyuncs.com/[命名空间]/[仓库名称]:[镜像版本号]

6）使用Dockerfile创建新的镜像(注意：末尾有一个点，表示当前路径):docker build -t "repository/images_name:tag" .    

 

2、容器



docker start 容器id

docker stop 容器id

docker exec -it 容器id /bin/bash  # 进入容器

docker cp 宿主机绝对路径  容器id:路径   # 宿主机和docker容器之间复制文件 

# 关于删除容器：

方法一：

#显示所有的容器，过滤出Exited状态的容器，取出这些容器的ID，

sudo docker ps -a|grep Exited|awk '{print $1}'

#查询所有的容器，过滤出Exited状态的容器，列出容器ID，删除这些容器

sudo docker rm `docker ps -a|grep Exited|awk '{print $1}'`

方法二： 

#删除所有未运行的容器（已经运行的删除不了，未运行的就一起被删除了）

sudo docker rm $(sudo docker ps -a -q)

方法三：

#根据容器的状态，删除Exited状态的容器

sudo docker rm $(sudo docker ps -qf status=exited)

方法四：

#Docker 1.13版本以后，可以使用 docker containers prune 命令，删除孤立的容器。

sudo docker container prune  （推荐）

 



指定映射最常用的是第一种，直接指定宿主端口:容器端口；

第二种，假如宿主有多个ip的话，让容器的端口绑定到宿主的固定一个ip的端口上；

第三种，只绑定宿主ip，端口随机取；

第四种，它的意思是一条docker run命令可以同时用多次”-p”参数，指定多个端口映射关系，比如，docker run –d –p 99:80 –p 33:443 –name mynginx33 nginx



启动容器时用-P（大写）参数，表示让容器随机对应一个宿主机的端口，如上，容器的80端口对应宿主的32768端口，容器的443对应宿主的32769端口。

比如我的宿主ip是192.168.0.55，这时候在宿主机的浏览器输入192.168.0.55:32768就可以访问到docker容器里的nginx应用了。

端口随机映射的好处是：端口不会冲突。难点是，生产中还得用脚本或者其他方式获取到这个随机的端口，由于它是变化的，所以脚本必须得适应这种变化性。



用小p来手动指定端口映射，如上所示，将容器的80端口映射到宿主的91端口上，而443没有指定映射关系，所以443不可访问。

 

二、制作自己的Docker镜像

自己制作的docker我都推送到了阿里云docker管理平台了，而不是推送到docker官方的管理平台。下面首先介绍一下使用阿里云docker管理平台创建自己的仓库。

1、阿里云docker管理平台创建仓库

1）进入阿里云镜像服务控制台，新建镜像仓库，如图



2）新建仓库弹窗，一步一步按提示填，注意，设置代码源可以使用github，阿里云code等等，这里我使用的是阿里云code，后面可以使用项目里面的Dockerfile自动生成镜像，具体步骤下面会详细介绍



3）新建完之后，会有镜像仓库列表，显示镜像仓库信息



4）点击管理，基本信息，会有各个命令提示：

登录阿里云docker registry:

  $ sudo docker login --username=  registry.cn-beijing.aliyuncs.com


登录registry的用户名是您的阿里云账号全名，密码是您开通服务时设置的密码。

你可以在镜像管理首页点击右上角按钮修改docker login密码。

从registry中拉取镜像：

  $ sudo docker pull registry.cn-beijing.aliyuncs.com/spencer_docker/django2:[镜像版本号]


将镜像推送到registry：

  $ sudo docker login --username= registry.cn-beijing.aliyuncs.com
  $ sudo docker tag [ImageId] registry.cn-beijing.aliyuncs.com/spencer_docker/django2:[镜像版本号]
  $ sudo docker push registry.cn-beijing.aliyuncs.com/spencer_docker/django2:[镜像版本号]


其中[ImageId],[镜像版本号]请你根据自己的镜像信息进行填写。

 

2、手动构建Docker镜像

这种方法就是根据docker镜像为基础镜像来创建容器，然后运行容器，在容器中安装自己需要的包，然后再提交(commit)一下，推送(push)到自己的镜像仓库就ok了。

下面以一个Ubuntu:16.04为例，更改为自己的python3.6+django2.0镜像，由于三个版本(v1,v2,v3)都是使用的原始的Ubuntu:16.04，所以三种生成进行镜像方法介绍完之后再以一个版本为例介绍docker环境配置。

1）拉取Ubuntu:16.04官方镜像：



2）进入镜像，变为容器，随便安装一些包



3）退出容器，exit，提交镜像(命令可以看本博客命令部分的镜像命令)



如图，上图提交命令解释：

① -m是对提交的描述，author是作者(选填)，后面的c28e5976a6ab是修改容器的id，后面的是新镜像名字和标签(tag)。

② 成功之后，会生成新的镜像id

③ 输入docker images 查看镜像，会发现新的名为spencer/django，标签为v1的镜像已经存在。

4）推送到阿里云docker管理平台，命令参考上面将镜像推送到阿里云registry

 

 



 

5）打开阿里云镜像服务控制台，进入镜像仓库列表-->管理-->镜像版本，如下图，版本，镜像id，和本地推送上来的版本，镜像id一样



6）删除本地images，拉取阿里云docker镜像管理台镜像，如下图



3、利用Dockerfile构建Docker镜像

  由Dockerfile自动构建镜像，其实就是把手动构建的命令逐行写入一个“脚本”里，只不过这个脚本有自己的语法，如下图



1）现在在本地创建一个Dockerfile文件，如图，touch Dickerfile



2）使用Dockerfile生成镜像，注意：

     ① 如果是手动创建的话，不要创建txt文件，不然本地使用Dockerfile生成docker镜像的是，会报找不到的错误，

     ② 创建命令:docker build -t "repository/images_name:tag" .   

         新建镜像最好在Dockerfile当前路径下面创建，末尾可以用点表示，如果不是在当前路径，需要使用绝对路径



3）推送到阿里云docker管理平台，如下图



 

4、利用阿里云镜像平台的代码源Dockerfile构建docker镜像

   可以将Dockerfile文件放在项目里面，然后利用阿里云镜像平台自动生成镜像功能，生成镜像，生成之后可以直接在本地拉取远程镜像。

  1）可以在阿里云code，github，等代码管理平台，创建项目，然后将自己的Dockerfile放大项目，推送到远程代码管理平台，然后绑定到阿里云镜像仓库，在创建镜像仓库的时候，设置代码源的选项，设置到Dockerfile文件路径下面就行，具体项目代码不再展示，如下图



2）进入镜像列表-->管理-->构建-->立即构建，注意：构建设置里面要设置对的Dockefile路径，不然会构建失败。





3）构建成功，查看镜像，拉取镜像到本地

点击镜像版本，如图，构建成功



本地拉取镜像，如图



注意：建议大家使用dockerfile创建镜像，因为启动镜像，在容器内安装包再commit ，每一次ocmmit都相当于多了一层，这样会导致镜像占用空间比较大而且臃肿，推荐使用dockerfile创建镜像，把多个安装包的步骤放在一个RUN里面，使用&&连接，这样安装多个包相当于在一层中，详细可参考《从入门到实践2》一书，讲解的很到位，下面是百度云盘的链接，有需要的朋友可以拿走。

https://pan.baidu.com/s/1QLsprDiB_fz_r06m_HcKfQ

5、docker环境配置python3.6+django2.0

     其实docker镜像包都是可以通过Dockerfile一次性部署的，我在研究的时候分开了弄，走一遍流程，这样写到dockerfile中保证不会出错。接下来就是我研究过程，博友们不必看，就是简单的安装一些依赖包的过程

    因为我构建的镜像是以ubuntu为基础，ubuntu原始安装命令是apt-get install 

1）更新apt-get install 

     命令：apt-get update



2）安装Python3.6

说明一下：目前通过 apt-get install python3直接安装的是Python3.5版本，因为python3.6（apt-get install python3.6是无效的）是最新版本，所以只能先安装Python3.5然后升级到3.6。倘若Python3.6全部完善之后出来Python3.7,3.8,3.9等等，这样就可以直接通过apt-get install python3安装3.6了。

①安装Python3 ，安装成功之后，输入python3，会显示Python3.5的交互环境

命令：

apt-get install python3



②安装Python3.6的需求包

命令：

apt-get install software-properties-common



③添加Python3.6

命令：

add-apt-repository ppa:jonathonf/python-3.6



④更新apt-get 

命令：

apt-get update




⑤安装Python3.6，

命令：

apt-get install python3.6



⑥安装成功之后输入Python3依旧是Python3.5的交互环境，这样很不方便，接下来就是实现输入Python直接进入到Python3.6的交互环境，如下图：

第一步：which python3 ---查看Python3.5安装在何处

第二步：更改软链接，输入Python默认启动Python3.5，命令：ln -s /usr/bin/python3.6 /usr/bin/python

第三步：更改默认启动为Python3.6，注意第三条命令最后的一个2，这个是排序，只要python3.6的排序比3.5的高就行，命令：

           update-alternatives --install /usr/bin/python3 python3 /usr/bin/python3.6 2



3）安装pip

①安装pip3

命令：

apt-get install python3-pip



②更新pip3为pip，并升级

命令：

pip3 install --upgrade pip



4）升级python-dev

起初并不知道这个还需要升级，因为他原本的dev是Python3-dev，但是安装一些包的时候老是报如下错误：

Command "/usr/bin/python3 -u -c "import setuptools, tokenize;__file__='........

找了n久，才发现是这个原因，之前安装原本的dev是Python3-dev，要升级到Python3.6-dev，如下图

命令：

apt-get install python3.6-dev



5）批量安装依赖包

     把需要安装的依赖放到一个名为requerments的文件中，然后使用命令 pip install -r requerments，批量安装依赖包

命令：

pip install -r requerments



 

 

 

    

                    

                    

                    
                    
                    序言
    很久没有思维抖动的时候，就在风吹的一瞬间。。。美滋滋。。。
容器镜像的删除
     在使用容器的时候，我们都是自己搭建一个私有的容器镜像环境，一般使用的镜像也就是registry了，用来保存相关的镜像，搭建了镜像，上传了镜像，使用了镜像，那么。。。一直没有尝试过删除镜像。

    当环境不停的升级的时候，镜像的数量会不停的增长，磁盘空间总归是有限的，so。。。需要将老版本的镜像文件删除。

    有的时候，当听到没有想过的想法的时候。。。这感觉很酷。。。
    1、 运行一个registry镜像
    2、注册镜像中心
    3、 上传镜像到镜像中心
    4、 删除镜像
    先获取到tag信息，然后获取到摘要信息，然后删除（默认未开启删除功能）
    5、 修改配置文件
    6、 重新删除
    在删除的时候，使用DELETE只会删除元数据，而不会删除真正的数据，从而空间不会真正的释放，从而可以执行垃圾回收，将磁盘空间进行回收（http响应码202表示服务器已经收到请求，会异步的进行处理）。

    API地址为：https://docs.docker.com/registry/spec/api/

    这种都可以用脚本来实现：



                
  

大规模容器镜像管理方案

随着容器技术的深入和广泛应用，容器镜像的管理成为了一个关键的环节，在大规模并发访问镜像中心的时候，镜像仓库的高可用性、性能及安全性都是值得关注的问题。目前市场上存在一些开源及商业的解决方案，旨在满足特定场景下的需求，本篇文章就针对容器镜像管理的一些场景和方案进行梳理。

常用的容器镜像中心
容器镜像管理中心是云原生应用持续交付体系中的一个非常底层且关键的部分，目前市场上主流的容器镜像管理中心主要有开源的 Docker Registry，VMWare Harbor, Sonatype Nexus3 及商业的JFrog Artifactory，这些产品适用于不同的场景，但都支持相同的标准协议。
Docker Registry
Docker Registry 应该是我们认识最早的容器镜像中心，是由 Docker 公司开发的一款开源软件，采用 Apache License 开源协议。很多小规模开发团队喜欢在私有的开发测试环境使用它，因为它轻巧灵便，非常适合在规模不大的场景下提供镜像存储和分发服务。
在著名的公有 Docker 镜像中心 - Docker Hub 上，我们可以查找到创建Docker Registry 的镜像，因此 Docker 镜像中心 registry 也可以以容器方式运行，特殊点在于其应用本身就是管理容器镜像的。
VMWare Harbor
Harbor 是一个开源的企业级 Docker 镜像中心，也是目前唯一原创于中国的CNCF 项目。Harbor 所做的事情并不是取代 Docker Registry，而是为其增加了诸多企业级特性，如 UI, RBAC, Security 及 Replication 等等。
Harbor 主要分5个大部分：

由 Nginx 服务器构成的反向代理
由 Docker 官方的开源 registry 镜像构成的容器实例
架构中的 core services, 此部分是 Harbor 项目的主体
由官方 MySql 镜像构成的数据库容器
运行着 rsyslogd 的容器，通过 log-driver 的形式收集其他容器的日志



Harbor 在业内使用较为广泛，作为镜像管理中心，Harbor 还提供了用户权限、镜像安全及复制分发等企业特性，使得更多企业用户在研发测试环境中使用。在很多云厂商产品中也有集成 Harbor 作为整体解决方案的一部分，并且在云原生领域已经开始支持Helm仓库，使得云原生应用的部署更加便捷。
Sonatype Nexus
Sonatype Nexus 是一款优秀的Java私服仓库，集中管理Java语言的制品，后来加入了其他语言的支持，如Python, NuGet 及 Docker 镜像。众多用户都是使用其开源版本，而并未使用带高可用特性的企业版本，于此同时企业版也将Helm仓库纳入其 RoadMap，不过是通过社区插件的形式来支持，由于 Sonatype 主要关注安全领域，未来在制品仓库领域的发展策略尚不明朗。
JFrog Artifactory
JFrog Artifactory 是目前原生支持开发语言类型最多的制品仓库，除了传统的Java、.NET、Python、Php等等还支持Docker、Helm等仓库，甚至还可以支持Debian/RPM仓库，针对应用配置管理也有其独特的解决方案，深受广大用户的欢迎。
Artifactory 除了存储镜像还可以记录镜像整个生命周期数据，为用户在镜像复用、阶段交付及上线发布时提供数据决策支撑。很多企业都有镜像安全审计需求，该制品仓库可以清晰地展现容器镜像中的内容，如RUN命令的所有指令，可在镜像上传时检查指令合规性。于此同时，针对企业关心的正反向依赖解析也有很好的支持，可快速分析某个其他语言的制品(比如java语言JAR包)被哪些镜像层所引用，以及镜像层被其他哪些镜像所公用。


容器镜像中心面临的挑战
容器镜像中心在实际生产环境中依然会遇到一些棘手的问题，比如并发量比较大的场景下的性能问题，安全相关的问题及数据热备容灾等等。
镜像中心的多活及容灾热备
单节点容器镜像中心在高并发下载场景下会出现性能瓶颈，从而需要多节点来共同分担下载请求负载，因此多活节点是保证性能的必要手段。由于上传流量相对于下载流量小很多，因此常常被人忽略，集群模式下写入必须满足数据一致性，即必须由Leader负责与集群其他节点的数据同步。因此由多活节点保证并行性能及容灾备份节点提供冗余机制的模型就成为大规模镜像管理集群的标准架构。


镜像中心的多数据中心投送
容器应用在本地数据中心内会由于升级、迁移、回滚等动作而需要实时拉取镜像，如果此时镜像在异地数据中心，那么性能肯定会收到较大影响，最终用提体验较差。因此，在跨地多数据中心部署架构下，比如能够实现镜像的多数据中心投送，确保应用在本地数据中心获取镜像，这与缓存的基本思想类似。
镜像的多数据中心投送场景不仅仅局限于应用部署，在常见的多地域研发中心协同的时候，也会存在这种跨数据中心依赖的情形，需要能够按需从异地数据中心获取镜像，然后再本地数据中心进行缓存，以提升研发或构建时依赖获取的效率。


镜像的核心历史元信息管理
镜像本身也是线上运行的交付制品，隐含着很多的背景信息，比如构建信息、测试信息及安全信息等等，这些信息对于线上应用的可用性和稳定性都有着千丝万缕的联系，这些信息如果没有集中进行管理，会导致整个交付信息流中断，不利于线上问题的排查及对交付流程的评估分析。


镜像的动态及静态安全管理
镜像本身由各个镜像层组成，每个镜像层又由若干二进制文件组成，这些文件中绝大多数都不是由开发者开发的，而是第三方或者开源的内容，然而开源并不等同于安全，这些安全状态未知的内容的潜在风险非常大，而这些问题的影响范围如何更加不得而知。
其实安全不仅仅来自于外部，内部开发的组件在被层层引用时也可能会造成整个业务组件发生问题，比如存在内存溢出等，甚至是老版本的升级对受影响的组件的回归测试不完整也会造成不可预知的问题。


镜像除了静态一些安全因素之外，动态安全也应该是受到关注的内容，如镜像中哪些指令是允许执行的，而哪些不允许执行的，如何动态学习一些频发执行且需要root权限的系统调用(syscall)等行为，给管理者进行风险告警和快速阻断，这些都是生产环境需要解决的重要课题。


容器应用编排及配置管理
容器引用发布其实不仅仅设计镜像，而且还设计很多容器应用本身的参数，比如实例数、服务、config、Volume等等，这些资源要进行一个统一的编排其实还是有一定的复杂度的。大型开发项目人员众多，各自有各自的习惯和做法，缺乏有效的标准和工具，很容易造成碎片化、难以复用共享等问题。
Helm 是Kubernetes官方的包管理器(Package Manager)，除了提供Chart的仓库，还能够对容器应用的生命周期管理，比如部署、升级、回滚等，配置其生命周期事件的扩展(Hook)及插件机制，可以很方便地实现灰度、蓝绿等策略支持，这个对于容器应用编排有着很大的促进作用。


容器应用的灰度及蓝绿发布策略需要一些基础条件，比如应用需建立起与配置的关联关系，配置需要建立与运行环境中配置Key的关联关系，这样才能通过自动化的手段实现在检测到异常时自动回滚，并且配置中心还必须保证高可用。这些基础条件必须与开发工具、语言无关，最好是通过同一个平台进行管理。


容器镜像存储及分发优化
容器镜像是分层存储的，除了最上层是读写层之外，其余的全部是只读层，从存储优化的角度来说，这时候就需要在多个镜像之间来共享某些层。在物理层如果镜像层物理文件依然是目录递归查询的方式，显然查询效率会大大降低，而比较合适的一种设计是通过建立二进制文件的SHA2码的索引，从而实现快速定位具体二进制文件的物理位置，类似存储虚拟化的设计思路。


容器镜像分发解决方案
容器镜像分发通常有两种模式，一种是Push模式，即一个中心节点向多个远端节点进行推送，另一种是由远端节点进行定时轮询，发现有新的内容则拉取到本地。对于触发方式，也分为定时触发和事件触发两种。
边缘节点CDN加速
通过CDN形式进行分发是最直观的加速方式，在边缘网络提供只读节点，供用户就近访问可以减少中心节点的访问流量，达到提升镜像下载速度的目的。在实际的分发架构中，制品库对接分发者，分发者可以控制分发策略等，分发者对接各个边缘节点(Edge Node)，最后用户可以从多个边缘节点的负载均衡进行下载，进一步提升和下载速度，因为边缘节点支持缓存机制。


P2P 分发
目前通过P2P协议分发镜像也是一种逐渐成为主流的方案，国内的华为、阿里及百度均在此领域有探索，企业级开源容器镜像中心VMWare Harbor也有类似方案。例如阿里的Dragonfly已经成为正式的CNCF项目，华为容器技术团队也发表了相应的技术方案。整体来看，P2P分发协议是通过Controller下发镜像分发任务，由Tracker去跟踪各个客户端下载的二进制层的元数据信息，最终进行汇总决定任务是否完成。整体架构如下:

Docker镜像是按照Layer存储的，意味着不同的镜像可共享Layer，这种机制不仅减少了物理存储空间的消耗，也在分发时减少了带宽的损耗。当查询到需要下载Layer时先通过export的方式导出和压缩Layer文件，然后为其制作BT种子，并由控制器分发下载任务给各个客户端代理，客户端代理收到任务会检查要下载Layer本地是否已存在，若不存在则根据任务中的Layer相关信息进行下载，然后由Docker Daemon进行导入，整个下载的过程都是并发执行的。
总结
随着容器规模的快速增长，容器镜像中心的高可用性保障遇到的挑战将会越来越大，本质上来说也是对分布式文件系统的可靠性的检验，企业级容器镜像中心将会是云原生时代应用基础设施的关键组成部分，各种管理架构和技术也在不断深化和发展中，期望这篇文章对于关注相关技术的读者有所帮助。

很多刚刚接触容器技术的朋友，不容易弄清楚容器，容器镜像和Docker这几个词的区别和联系。

我们首先来看容器和容器镜像。举个例子，执行命令行docker search nginx，搜索结果的一条条记录就是一个个容器镜像。

所谓镜像，就是一个静态概念，一个镜像由若干只读层(read-only layer)构成。

上图左边是Docker镜像的内部实现细节，我们能看到多个只读层叠加在一起，层与层之间通过指针关联，这些层能够在运行Docker的宿主机的文件系统上访问到。
Linux的统一文件系统(union file system)技术将这些叠加的只读层合并成一个文件系统，该系统为这些只读层提供了一个统一的视角，从而为Docker的用户隐藏了多层的存在。
从Docker用户的视角出发，一个Docker镜像只存在一个文件系统，即上图右边所示。
这些文件系统的设计是Docker实现细节，一般情况下我们不用去深究。但如果您足够好奇，使用命令sudo tree浏览目录 /var/lib/docker即可：

比如我用命令docker images浏览下载到本地的docker镜像：

其中一个叫jerry-nginx的镜像，是一个web应用，它的所有内容能在/var/lib/docker目录下的这个目录查到：

讲完了容器镜像，我们再来看容器。

容器和容器镜像一样，也是若干层的叠加，唯一区别是所有只读层的最上面一层，是一层可读可写层，如上图绿色图例所示。
初学者可以记住这个简单的公式：容器 = 容器镜像 + 可读可写层

我们如果用命令docker ps --all查看本机所有容器列表，会发现有的容器处于运行状态，有的处于退出状态。
因此，一个处于运行状态的容器(running container)包含一个可读写的文件系统加上隔离的进程空间。
容器里的进程可以对这个可读写文件系统内的文件进行修改、删除、创建等操作。
镜像里每一层其实都能在docker文件夹的containers子目录下找到：

上图每一个红色文件夹代表镜像里的一层，蓝色文件包含了该层运行时的日志文件，或者网络相关配置等。
做个实验：

ubuntu这个容器执行结束后，使用find / -name i042416.txt文件，这说明docker运行时能对宿主机的文件系统进行写操作。

下面分析几个常用的易混淆的命令。
docker create 
先看它的帮助文档：

试着执行以下：

产生一个输出id：
7ee10851c3f1e53bbd35e5f196f34de560afa1a20d9bf1ced587630dbcda877b
create创建的容器，状态变为created：

docker create命令给通过命令行传入的容器镜像创建了一个新的可读可写层，从而生成了一个新的容器实例：

然后再执行docker start，输入docker create创建的容器实例ID，就可以启动这个容器实例了。
而docker run其实就是docker create和docker start这两个命令合二为一的版本。
希望这篇文章能帮助大家理解容器和容器镜像的区别。

要获取更多Jerry的原创文章，请关注公众号"汪子熙":