Docker基础概念与操作
基础概念:
o 镜像就像是一个可执行文件。
o 镜像在仓库注册中心内被分门别类的存起来。
o 镜像最终被放在每一个机器上,启动为一个个的容器。
镜像:
因为镜像就像是一个可执行程序,所以,就会有一种约定的打包方式。Docker的守护程序就能按照这种格式,将程序启动起来,变成一个个的容器。
既然镜像是运行前的程序,它存在的地方和形式也有多种形式。我们可以知道,大概镜像有如下的地方进行存在:
1、 仓库内
2、 Docker管理的地方
3、 单独的包,可以被复制和传递
镜像存在的形式也是有不同:
1、 在仓库内,和Docker管理的地方:镜像是分层存储的,以便进行管理;
2、 单独的包,它被打成了一个tar包。
我们看看单独的包,长的是什么样子:
google_containers-pause-2.0.tar.gz是一个k8s的基础镜像包,我们打开看看,
里面是两个目录,每个目录是一个层,这些层叠在一起就构成了一个目录结构,也就是分层文件系统。我们看看每个层的内容。
每个层里面有一个json文件,描述该层的信息:
另两个就是真正的层数据文件,和版本文件。
我们再看看镜像在Docker守护进程管理的目录下,长什么样子:
cat /var/lib/docker/image/overlay/repositories.json
{
"Repositories": {
"quay.io/coreos/etcd": {
"quay.io/coreos/etcd:v3.0.15":"sha256:2bdf33352107013ee45d76ad4dd4bb6929b121688084b9a56be536706085f832",
"quay.io/coreos/etcd@sha256:aed90a29fbe7ad0e6629b2ea5a290f5b6efb9b719cec97c756df13f1db3760bf":"sha256:2bdf33352107013ee45d76ad4dd4bb6929b121688084b9a56be536706085f832"
}
}
}
可以看出,在Docker守护进程管理的目录下,有一个详细的Repository描述文件,每一个Repository都有一个名字,下面有具体的每一个版本的(tag)的信息。原来,无论是Docker镜像仓库,还是Docker的守护进程,都是以Repository为单位,管理程序的。这里的Repository,算是一个“仓库”吧。
镜像包内容本来是一个文件,导入到Docker守护进程内部后,就被放入仓库描述文件中,打上标签后,就可以用于启动容器了。
单独的镜像文件没有什么直接的用途,必须纳入Docker守护进程的管理体系才能进行后继的操作,镜像既可以直接连接远程的注册表,通过网络下载到本地;也可以直接装载进Docker的管理目录内。一旦纳入管理后,就可以使用如下的命令查看了:
容器:
容器是运行态的镜像,所以运行的容器,本地一定有一个对应的镜像存在,并额外叠加容器的一些数据。
一个镜像可以启动多个容器,所以,每次启动都会建一个新的容器目录。
启动完容器后,可以使用如下命令查看:
停止容器:
停止后的容器,也可以查看到:
仓库注册中心:
仓库注册中心就是存储镜像的地方。为了优化存储效率,理论上仓库注册中心内也是按照分层存储的。相同的层,互相引用就行了,不需要反复存储。
Docker在公网上运行了一个统一的仓库注册中心,叫做docerhub。全世界的开发者都可以使用这个中心来分发应用。
如果在内网上,不便于连接外部的docerhub来下载应用,可以使用docker公司提供的仓库注册中心的程序来自建一个仓库注册中心。
由于国内外的网速差别,还可以构建一些镜像的仓库注册中心,这些镜像的注册中心定期的和dockerhub同步,然后大家就近的使用这些本地的仓库注册中心就能顺利的下镜像了。docker国内官方的合作伙伴是阿里,他也会提供类似的服务。
docker的守护进程负责通过合适的协议,将本地的镜像分层的上传到镜像注册中心,或者下载到本地。由于它能判断本地是否已经有相同的层,所以从传输的角度来看,也是十分高效的。
仓库注册中心支持查询操作,可以查询是否存在需要的镜像:
仓库注册中心好像并没有提供类似网页等上传的能力,估计有如下原因:
1. 通信协议不高效,docker守护进程可以进行分层判断,而web上传只能一次性上传所有的包,上传完毕后再进行剃重,明显效率不高。
2. 通常镜像中都只有分层的数据,上传上去后,仓库的一些信息不完善,所以仍然需要告诉仓库注册中心。这两个过程不太协调。
估计如果能开发一个web的插件,还能实现docker守护进程和仓库注册中心的通讯协议,应该能解决一些PaaS应用部署的易用性问题。