Docker容器之镜像仓库详解
本文将集中对镜像、仓库、容器的概念与三者之间的联系进行详细介绍,以及基本的镜像管理操作。
1. 什么是Docker Image?
About Docker Image
容器是容器镜像的运行实例。容器镜像是一个不可变的只读文件,其中包含有关创建Docker容器的说明。每次基于容器镜像文件启动容器时,无论在何处部署容器镜像文件,都将获得完全相同的Docker容器。
Docker镜像是一个只读的模板,含有启动容器所需要的文件系统及其内容,因此,其用于创建并启动容器。比如,一个镜像可以包含一个运行在Apache上的Web应用和其使用的Ubuntu操作系统。
镜像是用来创建容器的。Docker提供了简单的方法来建立新的镜像或者升级现有的镜像,你也可以下载别人已经创建好的镜像。Docker镜像是Docker的 构造 部分。
如上图所示,镜像采用分层构建机制,最底层为bootfs,其次为rootfs。
-
bootfs:用于系统引导的文件系统,包括BootLoader和kernel,容器启动完成后会会被卸载以节约内存资源;
-
rootfs:位于bootfs之上,表现为docker容器的根文件系统;
- 传统模式中,系统启动之时,内核挂载rootfs时会首先将其以“只读”模式挂载,完整性自检完成后将其重新挂载为读写模式;
- docker中,rootfs由内核以“只读”模式挂载,而后通过“联合挂载”技术额外挂载一个“可写”层,容器中的写操作都在这个层完成。
Docker Image Layer
通常,我们下载的镜像可能包含了很多层,位于下层的镜像称为父镜像(parent image),最底层的称为基础镜像(base image);最上层为“可读写”层,即可写容器。其下层均为“只读”
如下图所示中,基础镜像为ubuntu,这是可能是一个裁剪过的ubuntu系统,它作为整个镜像的base image;当加入了emacs后,又重新创建了一个包含了ubuntu和emacs的镜像;随后在emacs镜像重新加入Apache,又重新创建了一个包含了ubuntu、emacs、Apache的镜像;接下来,启动容器后,docker会在这些父镜像的最上层附加一层“可写容器”层。
容器在启动时,会将该镜像中的所有父镜像按顺序下载至本地,再启动容器。
base image通常都是由docker hub的专业维护人员制作而成,有了base image,再制作镜像就相对
通过上图我们了解到,镜像是分了很多层,那么这些层又是通过何种技术实现的,这就是接下来需要讨论的,AuFS和OverlayFS。
AuFS
AuFS的英文全称为Adanced multi-layered Unification File System(高级多层统一文件系统),它是一种Union File System。Union FS指把不通物理位置的目录合并mount到同一个目录中。UnionFS的一个显著的作用,即将一个CD/DVD和一个硬盘中的目录给联合挂载到一起,而后就可以对这个只读的CD/DVD上的文件进行修改,但是,修改的文件不是存在原来的CD/DVD上,而是存于硬盘中的目录。
AuFS主要就是用于为Linux文件系统实现“联合挂载”,它是UnionFS的重新实现,由Junjiro Okajima(岡島順治郎)在2006年开发的。
Docker最初使用aufs作为容器文件系统层,而且它目前仍作为存储后端之一来支持;aufs的竞争产品是overlayfs,后者从3.18版本开始被合并到Linux内核。
Docker的分层镜像,除了aufs,docker还支持brtfs,devicemapper和vfs等,在ubuntu系统下,docker默认的容器文件系统为aufs,而在CentOS7上,最初用的是devicemapper,现在是overlayfs。据说,devicemapper的表现极不稳定。
OverlayFS
OverlayFS是一个面向Linux的文件系统服务,其实现一个面向其他文件系统的联合挂载。
它于2014年被合并到LInux内核的3.18版本。其4.0版本带来必要的改进,例如Docker中所需的overlay2存储驱动程序。
OverlayFS的主要机制涉及当两个文件系统提供同一名称的目录时目录访问的合并。除此之外,OverlayF呈其中一个所产生的对象(如果有),“上层”文件系统优先。OverlayFS与其他覆盖型文件系统不同,OverlayFS合并的子目录树不一定来自不同的文件系统。OverlayFS支持在上层文件系统中的[whiteout和opaque目录,以允许删除文件和目录。
虽然截止2016年11月,大部分Linux发行版的Live CD使用AuFS,但Slackware为其Live CD使用OverlayFS。
在docker最新的18.09版本中,docker在redhat及centos等系统中,默认使用的便是overlay2的存储驱动程序。
[root@localhost ~]# docker info
Containers: 1
Running: 1
Paused: 0
Stopped: 0
Images: 4
Server Version: 18.09.2
Storage Driver: overlay2
Backing Filesystem: xfs
Supports d_type: true
Native Overlay Diff: true
2. 什么是Docker Registry?
关于Docker Registry
Registry可以理解为仓库,它是用来保存所有创建好的镜像统一存储的位置。它分为私有仓库(Private Registry)和公共仓库(Public Registry)。公有的Docker仓库名字是Docker Hub。Docker Hub提供了庞大的镜像集合供使用。这些镜像可以是你自己创建的,或者你也可以在别人的镜像基础上创建。Docker仓库是Docker的 分发 部分。
启动容器时,docker daemon会试图从从本地获取相关镜像;当本地镜像不存在时,其将从Regitry中下载该镜像并保存至本地;pull镜像必须使用https协议,如果要使用http,必须在配置文件中明确指定信任该http站点
Docker Registry的分类
Registry用户保存docker镜像,包括镜像的层次结构和元数据。用户可以自建Registry,也可以直接使用docker官方的Docker Hub。
Registry分为以下四种类型:
- Sponsor Registry:第三方的Registry,供客户和docker社区
- Mirror Registry:第三方的Registry,只让客户使用。比如阿里云注册后才可使用。
- Vendor Registry:由发布Docker镜像的供应商提供的Registry;通常代表是组织如redhat、google等。
- Private Registry:私有仓库;通过设有防火墙和额外的安全层的私有实体提供的Registry。
Docker Registry的组成:Repository 和 index
1)Repository
- Repository是指由某特定的docker镜像的所有迭代版本组成的镜像仓库。比如,在docker hub搜索nginx,会有一个nginx的Repository,包含有很多版本的nginx。
- 一个Registry中可以存在多个Repository
- Repository可以分为“顶层仓库”和“用户仓库”。
- 顶层仓库名称比如“仓库名”。
- 用户仓库名称格式为“用户名/仓库名”。
- 每个仓库可以包含多个Tag(标签),每个标签对应一个
2)Index
- 维护用户账户、镜像的校验以及公共命名空间的信息
- 相当于为Registry提供了一个完成用户认证等功能的检索
Docker Registry中的image
Docker Registry中的镜像通常由开发人员制作,而后推送至“公共”或“私有”的Registry上保存,供其他人员使用,例如“部署”到测试环境、生产环境等。
如下图所示:
Docker Hub
Docker Hub是世界上最大的容器镜像存储库,其中包含一系列内容源,包括容器社区开发人员,开源项目和独立软件供应商(ISV)构建和分发容器中的代码。用户可以访问免费的公共仓库来存储和共享镜像,也可以选择私人仓库的订阅计划。
**对于开发人员:**存储和共享您的个人项目,并查看容器社区正在构建的内容。
**对于团队:**利用私有仓库将内容限制为特定用户或团队。
**对于ISV:**列出并分发您的软件和插件作为容器,并覆盖容器社区的数百万最终用户。
**对于企业:**从经过验证的ISV中选择经过认证的容器并获得合作支持,这样您就可以确保在生产环境中运行。
在docker Hub中,镜像仓库的namespace层次结构附加了以下几种级别;
Name | Examples(/) |
---|---|
organizat | redhat/kubernetes,google/kubernetes |
login(u) | alice/applicaiton,bob/applicaiton |
roles | devel/database,test/database,prod/database |
官方镜像仓库:https://hub.docker.com/
第三方镜像仓库:https://quay.io/
3. 镜像相关的操作
镜像生成的三种途径
- Dockerfile
- 基于容器制作(docker commit)
- Dokcer Hub automated builds