关于本⽂的任何指正，请在新浪微博或者在上。
如果你是刚开始接触的话，按照官⽅⽂档⾥的例⼦，很容易⼊门并且进⾏⼀些简单的⼯作。但是，如果再深⼊⼀些，⽐如要创建⾃⼰的Dockerfile的话，你就可能会有点感到困惑了。在众多初学者⽐较容易迷惑的问题中，这是⼀个⾮常普遍的问题：
我的Docker镜像（images）保存在哪⾥呢？
- 每个⼈
这个问题也着实让我挠头。更糟糕的是，作为⼀个新⼿，你的最终⽬标是将⾃⼰笨⼿笨脚创建的Docker镜像发布到官⽅的Docker镜像索引上。
快来看看我创建的Docker镜像吧，它⾮常棒 thoward/i_have_no_idea_what_im_doing.
但这不是我想要做的。
还有更糟糕的事情，在这之前很长的⼀段时间⾥，你都没法删除你发布的镜像，你那些让⼈羞愧尴尬的学习过程将永久性的贴在那⾥。
幸运的是，现在删除⼀个⾃⼰发布的镜像⽂件已经变得⾮常简单了。
所以，在这⾥我做⼀下⼩⼩的澄清。如果你满⾜下⾯的条件的话，那么请放⼼，你的镜像⽂件是不可能被发布为公开镜像的：你还没有在官⽅的public index注册账号。
你没有通过 docker login 命令登录。
你没有运⾏ docker push 命令将⾃⼰的镜像发布到public index上。
术语（⽤语、关键概念）
Docker所使⽤的术语，也是其致使⽤户产⽣困惑的原因。⽐如Docker可能会使⽤overlap，或者含义模糊，或者被错误使⽤的⽤语，也可能使⽤有悖于⼈们常识认识的⽤语。
所以，在这⾥我们先对⼀些术语做⼀下解释。
镜像（Image） vs Dockerfile
这组概念很少会让⼈产⽣疑惑，但是这两者的区别⾮常重要。Docker在镜像（image）中运⾏你的代码，⽽不是Dockerfile。Dockerfile是通过docker build命令来编译镜像的配置⽂件。
如果你去浏览⼀下public index的话，你将会看到那⾥罗列了很多镜像⽂件。但是，也许有些奇怪的是，你将看不到任何编译出它们的dockerfile。镜像⽂件就是从Dockerfile编译⽽得到的不透明资产（opaque asset）。
当你⽤docker push命令发布⾃⼰的镜像的时候，你发布的不是任何你的代码，⽽是由你的代码编译出来的镜像⽂件。
注册表（Registry） vs 索引（Index）
注册表（镜像注册表，registry）和索引（镜像索引，index）这两个概念，以及它们的区别也很特殊。
⼀个索引（index）⽤来管理⽤户账号，权限，搜索，打标签（tagging），以及其它可以⽅便的通过Web界⾯来完成的⼯作。
⼀个注册表（registry）则是真正的⽤来保存、提供镜像⽂件的概念。它通过索引（index）来完成⽤户认证步骤。
当你执⾏docker search命令的时候，Docker会到index⾥执⾏查⼯作，⽽不是registry。从实际上来说，Docker会在索引（index）所知道的多个注册表（registry）中进⾏查。
⽽当你执⾏docker push 或者 docker pull操作的时候，index会判断你是否有权限访问或者修改该镜像⽂件，如果通过index的认证操作的话，registry则进⾏实际的镜像存储⼯作或者将镜像⽂件发送给请求端。同样，index会知道你想访问的镜像的存储位置（哪个registry上），然后将访问请求转向到相应的 registry。
另外，当你在本地环境下，执⾏类似docker images⼯作的时候，你所打交道的既不是⼀个index，也不是⼀个registry，⽽是两者都会有⼀点。
Docker 使⽤类似于Github或者其他SCM⼯具的仓库概念。当然，它们也不完全等价。
下⾯这三个问题值得我们先好好思考⼀下：
仓库和注册表的区别是什么？
仓库和镜像的区别是什么？
仓库和 an index username的区别是什么？
实际上，这是⼀个问题，因为镜像仓库是所有这些概念的合集，⽽不是单独的任何⼀个。此外，当你执⾏docker images的话你将得到类似如下的输出：
$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
ubuntu 12.04 8dbd9e392a96 8 months ago 131.3 MB (virtual 131.3 MB)
ubuntu latest 8dbd9e392a96 8 months ago 131.3 MB (virtual 131.3 MB)
ubuntu precise 8dbd9e392a96 8 months ago 131.3 MB (virtual 131.3 MB)
ubuntu 12.10 b750fe79269d 8 months ago 24.65 kB (virtual 179.7 MB)
ubuntu quantal b750fe79269d 8 months ago 24.65 kB (virtual 179.7 MB)
上⾯镜像列表的东西看起来像⼀个仓库列表？嗯？实际上，那些GUID才是Docker镜像，但你并不和他们进⾏交互。
让我们来仔细看看这个问题。
当你执⾏docker build或者docker commit的时候，你可以给它指定⼀个镜像名称。这个名称⼀般来说都是类似username/image_name这样的格式，但这不是必须的。实际上你可以给镜像名称指定任何字符，甚⾄是那些已经公开的众所周知镜像的名称。
但是，等你进⾏docker push的时候，index将会检查镜像的名字，查看是否有和其匹配的仓库（respsitory）。如果到了匹配的仓库，将会继续检查你是否有权限操作这个仓库。如果你有权限的话，那么⼀个新版本的镜像将成功的存储（发布）到这个仓库中。从中我们可以看出，registry会保持⼀个仓库列表，每个仓库都有⾃⼰的名字。⽽每个仓库都保存的都是通过GUID来标识的镜像⽂件列表。 这⾥⼜出现了标签的概念。你可以对任何⼀个镜像进⾏打标签操作，并且在同⼀个仓库中，为同⼀个镜像保存不同的版本，不同的版本通过GUID来进⾏区分。我们可以通过username/image_name:tag这种⽅式来通过标签访问不同版本的镜像。
$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
ubuntu 12.04 8dbd9e392a96 8 months ago 131.3 MB (virtual 131.3 MB)
ubuntu latest 8dbd9e392a96 8 months ago 131.3 MB (virtual 131.3 MB)
ubuntu precise 8dbd9e392a96 8 months ago 131.3 MB (virtual 131.3 MB)
ubuntu 12.10 b750fe79269d 8 months ago 24.65 kB (virtual 179.7 MB)
ubuntu quantal b750fe79269d 8 months ago 24.65 kB (virtual 179.7 MB)
我们再来重新看⼀下docker images的输出结果，应该会有新的认识吧。我们有5个不同版本的ubuntu的镜像，这些镜像通过标签来区分。镜像仓库通过ubuntu这个名字来管理所有这些镜像。也许你会认为ubuntu是⼀个镜像的名字，但实际上这是⼀个仓库的名字，它告诉我们它从哪⾥取得，或者在发布镜像的时候将保存到何处。
此外，仓库名称还有它特殊的命名模式（schema），索引（index）会将仓库名字的第⼀部分解析为⽤户名，并且将定位仓库的位置。
那么问题就出现了，假设我们有⼀个Docker镜像 thoward/scooby_snacks。
这个镜像的“正式的名字”应该是thoward/scooby_snacks，尽管实际上我们潜意识⾥会认为它的名字就是scooby_snacks （这有点类似Github等服务⾥的仓库的概念）
实际上，当Docker的⽂档⾥说道仓库的时候，有时候指的是包含⽤户名在内的所有东西，⽽有时则只是去掉⽤户名后的部分。
这是因为⼀些仓库（⽐如ubuntu）等没有⽤户名。对⽤户名做特殊处理⾮常重要，因为index会⽤它来做认证操作，所以仓库名字⾥的⽤户名部分有它⾃⼰独特的意思。
Docker主机上的本地存储
到这⾥我们已经对Docker复杂的远程存储体系做出了说明，以及这⾥⾯容易让⼈混淆的⼏个概念。但是，docker images命令显⽰的内容都是本机上存在的资源。
那么本地资源都保存在什么位置呢？我们⾸先来看看 /var/lib/docker/这个⽂件夹下的内容。
打开这个⽂件夹下的 repositories ⽂件，你将会看到类似下⾯这样的JSON ⽂件：
$ sudo cat /var/lib/docker/repositories | python -l
{
“Repositories”: {
“ubuntu”: {
“12.04″: “8dbd9e392a964056420e5d58ca5cc376ef18e2de93b5cc90e868a1bbc8318c1c”,
“12.10″: “b750fe79269d2ec9a3c593ef05b4332b1d1a02a62b4accb2c21d589ff2f5f2dc”,
“latest”: “8dbd9e392a964056420e5d58ca5cc376ef18e2de93b5cc90e868a1bbc8318c1c”,
“precise”: “8dbd9e392a964056420e5d58ca5cc376ef18e2de93b5cc90e868a1bbc8318c1c”,
“quantal”: “b750fe79269d2ec9a3c593ef05b4332b1d1a02a62b4accb2c21d589ff2f5f2dc”
}
}
}
看看，是不是正好和docker images的内容⼀致呢。
REPOSITORY TAG IMAGE ID CREATED SIZE
ubuntu 12.04 8dbd9e392a96 8 months ago 131.3 MB (virtual 131.3 MB)
ubuntu latest 8dbd9e392a96 8 months ago 131.3 MB (virtual 131.3 MB)
ubuntu precise 8dbd9e392a96 8 months ago 131.3 MB (virtual 131.3 MB)
ubuntu 12.10 b750fe79269d 8 months ago 24.65 kB (virtual 179.7 MB)
ubuntu quantal b750fe79269d 8 months ago 24.65 kB (virtual 179.7 MB)
接着，我们再来看看 /var/lib/docker/graph/这个⽂件夹：
$ sudo ls -al /var/lib/docker/graph
total 24
drwx—— 6 root root 4096 Nov 22 06:52 .
drwx—— 5 root root 4096 Dec 13 04:25 ..
drwxr-xr-x 3 root root 4096 Dec 13 04:26 27cf784147099545
drwxr-xr-x 3 root root 4096 Nov 22 06:52 8dbd9e392a964056420e5d58ca5cc376ef18e2de93b5cc90e868a1bbc8318c1c
drwxr-xr-x 3 root root 4096 Nov 22 06:52 b750fe79269d2ec9a3c593ef05b4332b1d1a02a62b4accb2c21d589ff2f5f2dc
drwx—— 3 root root 4096 Nov 22 06:52 _tmp
这些输出结果可能有点晦涩（Not terribly friendly），但是从中我们可以看出Docker是使⽤repositories JSON⽂件来记述镜像信息的，此JSON⽂件包含了仓库名、标签、以及标签对应的镜像ID。
我们有两个来⾃ubuntu仓库的镜像，这其中标签为12.04，precise和latest都指向的是同⼀个镜像，其ID
为 8dbd9e392a964056420e5d58ca5cc376ef18e2de93b5cc90e868a1bbc8318c1c (这个ID长度为64位，但是我们可以使⽤其12位的简短模式，⽐如8dbd9e392a96)。
那么这些以镜像ID命名的⽂件夹下⾯⼜保存了什么东西呢？
$ sudo ls -al /var/lib/docker/graph/8dbd9e392a964056420e5d58ca5cc376ef18e2de93b5cc90e868a1bbc8318c1c
total 20
drwxr-xr-x 3 root root 4096 Nov 22 06:52 .
drwx—— 6 root root 4096 Nov 22 06:52 ..
-rw——- 1 root root 437 Nov 22 06:51 json
drwxr-xr-x 22 root root 4096 Apr 11 2013 layer
-rw——- 1 root root 9 Nov 22 06:52 layersize
这个⽂件夹下的内容如下：
json -保存着关于这个镜像的元数据
layersize – ⼀个整数，表⽰layer的⼤⼩。
layer/ – ⼦⽂件夹，保存着rootfs该容器的镜像
$ sudo cat /var/lib/docker/graph/8dbd9e392a964056420e5d58ca5cc376ef18e2de93b5cc90e868a1b
bc8318c1c/json | python -l
{
“comment”: “Imported from -”,
“container_config”: {
“AttachStderr”: false,
“AttachStdin”: false,
“AttachStdout”: false,
“Cmd”: null,
“Env”: null,
“Hostname”: “”,
“Image”: “”,
“Memory”: 0,
scm文件“MemorySwap”: 0,
“OpenStdin”: false,
“PortSpecs”: null,
“StdinOnce”: false,
“Tty”: false,
“User”: “”
},
“created”: “2013-04-11T14:13:15.57812-07:00″,
“docker_version”: “0.1.4″,
“id”: “8dbd9e392a964056420e5d58ca5cc376ef18e2de93b5cc90e868a1bbc8318c1c”
}
$ sudo cat /var/lib/docker/graph/8dbd9e392a964056420e5d58ca5cc376ef18e2de93b5cc90e868a1bbc8318c1c/layersize 131301903
$ sudo ls -al /var/lib/docker/graph/8dbd9e392a964056420e5d58ca5cc376ef18e2de93b5cc90e868a1bbc8318c1c/layer
total 88
drwxr-xr-x 22 root root 4096 Apr 11 2013 .
drwxr-xr-x 3 root root 4096 Nov 22 06:52 ..
drwxr-xr-x 2 root root 4096 Apr 11 2013 bin
drwxr-xr-x 2 root root 4096 Apr 19 2012 boot
drwxr-xr-x 4 root root 4096 Nov 22 06:51 dev
drwxr-xr-x 41 root root 4096 Nov 22 06:51 etc
drwxr-xr-x 2 root root 4096 Apr 19 2012 home
drwxr-xr-x 11 root root 4096 Nov 22 06:51 lib
drwxr-xr-x 2 root root 4096 Nov 22 06:51 lib64
drwxr-xr-x 2 root root 4096 Apr 11 2013 media
drwxr-xr-x 2 root root 4096 Apr 19 2012 mnt
drwxr-xr-x 2 root root 4096 Apr 11 2013 opt
drwxr-xr-x 2 root root 4096 Apr 19 2012 proc
drwx—— 2 root root 4096 Nov 22 06:51 root
drwxr-xr-x 4 root root 4096 Nov 22 06:51 run
drwxr-xr-x 2 root root 4096 Nov 22 06:51 sbin
drwxr-xr-x 2 root root 4096 Mar 5 2012 selinux
drwxr-xr-x 2 root root 4096 Apr 11 2013 srv
drwxr-xr-x 2 root root 4096 Apr 14 2012 sys
drwxrwxrwt 2 root root 4096 Apr 11 2013 tmp
drwxr-xr-x 10 root root 4096 Nov 22 06:51 usr
drwxr-xr-x 11 root root 4096 Nov 22 06:51 var
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议