Docker images
关于Docker images
Docker镜像含有启动容器所需要的文件系统及内容，因此镜像主要用于创建并启动docker容器；
Docker镜像含里面是一层层文件系统，叫做Union File System（Union FS 联合文件系统）可将多个目录挂载到一起从而形成一整个虚拟文件系统，该虚拟文件系统的目录结构就像普通linux的目录结构一样，docker通过这些文件加上宿主机的内核提供里一个linux的虚拟环境，每一层文件系统我们叫做一层layer，联合文件系统可以对每一层文件系统设置三种权限，只读（readonly）、读写（readwrite）和写出（whiteout-able），但docker镜像中每一层文件系统都相当于做一层的修改，增加了一层文件系统，一层层叠加，上层的修改会覆盖底层该位置的可见性，就像上层把底层遮住一样；当使用镜像时，我们只会看到一个完全的整体。
典型的启动Linux运行需要两个FS: bootfs + rootfs:
bootfs (boot file system) 主要包含 bootloader和 kernel, bootloader主要是引导加载kernel, 当kernel 被加载到内存中后 bootfs就被umount了。rootfs (root file system) 包含的就是典型 Linux 系统中的 /dev, /proc,/bin, /etc 等标准目录和文件。
docker中，rootfs由内核挂在为”只读“模式，而后通过“联合挂载（AUFS）”技术额外挂在一个可读写层。
docker镜像通常比较小，官方提供centos基础镜像在200MB左右，一些其他版本镜像可能只有几MB，docker镜像直接调用宿主机的内核，镜像中只提供rootfs；只包含基本命令、工具、工程库，例如alpine镜像在5M左右
下图就是docker image中最基础的两层结构，不同的linux发行版（Centos/Ubantu）在rootfs这一层会有所区别。
典型的Linux在启动后，首先将 rootfs 设置为 readonly, 进行一系列检查, 然后将其切换为 "readwrite" 供用户使用。在Docker中，初始化时也是将 rootfs 以readonly方式加载并检查，然而接下来利用 union mount 的方式将一个 readwrite 文件系统挂载在 readonly 的rootfs之上，并且允许再次将下层的 FS(file system) 设定为readonly 并且向上叠加, 这样一组readonly和一个writeable的结构构成一个container的运行时态, 每一个FS被称作一个FS层。如下图:
得益于AUFS的特性, 每一个对readonly层文件/目录的修改都只会存在于上层的writeable层中。这样由于不存在竞争, 多个container可以共享readonly的FS层。 所以Docker将readonly的FS层称作 "image" - 对于container而言整个rootfs都是read-write的，但事实上所有的修改都写入最上层的writeable层中, image不保存用户状态，只用于模板、新建和复制使用。
上层的image依赖下层的image，因此Docker中把下层的image称作父image，没有父image的image称作base image。因此想要从一个image启动一个container，Docker会先加载这个image和依赖的父images以及base image，用户的进程运行在writeable的layer中。所有parent image中的数据信息以及 ID、网络和lxc管理的资源限制等具体container的配置，构成一个Docker概念上的container。如下图:
Docker images基础操作
镜像命名
镜像层的ID既可以识别每个镜像层，也可以用来直接识别镜像（因为根据最上层镜像能够找出所有依赖的下层镜像，所以最上层进行的镜像层ID就能表示镜像的ID），但是使用这种无意义的超长哈希码显然是违背人性的，所以需要引入镜像命名，通过镜像名能够更容易的识别镜像。
在docker images命令打印出的内容中，有两个与镜像命名有关的数据：repository和tag，这两者组成了docker对镜像的命名规则。
完整看，镜像的命名可以分成三个部分：username、repository和tag。
- username： 上传镜像的用户，与GitHub中的用户空间类似
- repository：镜像内容，形成对镜像的表意描述
- tag：表示镜像版本，方便区分内容细节
搜索镜像
登录hub.docker.com进行搜索，并查看tag信息
#配置好docker镜像源后可进行搜索
docker search jdk
NAME DESCRIPTION STARS OFFICIAL AUTOMATED
primetoninc/jdk Oracle jdk 1.8, 1.7 18 [OK]
codenvy/jdk8_maven3_tomcat8 JDK 8, Maven 3, Tomcat 8 9 [OK]
ascdc/jdk8 jdk8 8 [OK]
......
获取镜像
#未指定默认从dockerhub自动获取镜像，默认地址https://index.docker.io/v1/
#docker pull 仓库服务器：端口/项目名称/镜像名称:tag（版本）号
docker pull [OPTIONS] NAME[:TAG|@DIGEST]
docker pull <registry>[:<port>]/[<namespace>/]<name>:<tag>
#获取ubantu镜像，未指明tag，则默认为latest
docker pull ubantu:19.10
#获取flannel镜像
docker pull quay.io/coreos/flannel:v0.10.0-amd64
#其他镜像地址
https://quay.io
推送镜像
#推送至aliyun
#服务器地址/名称空间/仓库名：标签
docker tag [ImageID] registry.cn-qingdao.aliyuncs.com/guomiaosen/httpd:[镜像版本号]
docker login --username=guomiaosen registry.cn-qingdao.aliyuncs.com
#不指定镜像则推送整个仓库
docker push registry.cn-qingdao.aliyuncs.com/guomiaosen/httpd:[镜像版本号]
查看本地镜像
docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
nginx latest 2622e6cca7eb 2 weeks ago 132MB
alpine latest a24bb4013296 4 weeks ago 5.57MB
| 意义 | |
|---|---|
| REPOSITORY | 镜像所属仓库名称 |
| TAG | 镜像版本号标识符 |
| IMAGE ID | 镜像唯一ID表示 |
| CREATED | 镜像创建时间 |
| SIZE | 镜像的大小 |
当镜像REPOSITORY、TAG为None None时，通常是后期导入或制作的镜像与之前已存在的镜像REPOSITORY、TAG冲突，从而把之前的覆盖而导致，有很少部分镜像下载后这样
镜像导入
#-o指定输出文件名称
docker save [Imagename] -o gms.gz [ImageID] #名称空间/仓库名：标签
#保存导出nginx镜像
docker save ngixn -o /opt/nginx.tar.gz
#保存导出nginx镜像
docker save nginx:1.16.1 > /opt/nginx-1.16.1.tar.gz
镜像导出
#-i指定加载文件
docker load -i gms.gz
#加载nginx镜像
docker load -i nginx-1.16.1.tar.gz
#加载nginx镜像
docker load < nginx-1.16.1.tar.gz
缺陷：使用docker run时，若无本地镜像时；还会连接远程dockerhub再次进行拉取操作
删除镜像&删除容器
#推荐使用IMAGE ID来删除镜像；也可以使用镜像名称，但强烈建议添加上tag号
docker rm [IMAGE ID]
docker rm IMAGE NAME/tag
#通过镜像启动容器时，镜像不能被删除，除非关闭容器，强制删除加-f
docker rmi [IMAGE ID]
docker rmi IMAGE NAME/tag
docker rmi nginx:1.16.1
设置镜像标签
我们可以使用 docker tag 命令，为镜像添加一个新的标签。
docker tag 860c279d2fec runoob/centos:dev
#docker tag 镜像ID，这里是 860c279d2fec ,用户名称、镜像源名(repository name)和新的标签名(tag)。
#使用 docker images 命令可以看到，ID为860c279d2fec的镜像多一个标签。
docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
runoob/centos 6.7 860c279d2fec 5 hours ago 190.6 MB
runoob/centos dev 860c279d2fec 5 hours ago 190.6 MB
runoob/ubuntu v2 70bf1840fd7c 22 hours ago 158.5 MB
ubuntu 14.04 90d5884b1ee0 6 days ago 188 MB
php 5.6 f40e9e0f10c8 10 days ago 444.8 MB
nginx latest 6f8d099c3adc 13 days ago 182.7 MB
mysql 5.6 f2e8d6c772c0 3 weeks ago 324.6 MB
httpd latest 02ef73cf1bc0 3 weeks ago 194.4 MB
ubuntu 15.10 4e3b13c8a266 5 weeks ago 136.3 MB
hello-world latest 690ed74de00f 6 months ago 960 B
centos 6.7 d95b5ca17cc3 6 months ago 190.6 MB
查看镜像创建历史
docker history : 查看指定镜像的创建历史。
语法
docker history [OPTIONS] IMAGE
OPTIONS说明：
-
-H :以可读的格式打印镜像大小和日期，默认为true；
-
--no-trunc :显示完整的提交记录；
-
-q :仅列出提交记录ID。
实例
查看本地镜像runoob/ubuntu:v3的创建历史。
root@runoob:~# docker history runoob/ubuntu:v3
IMAGE CREATED CREATED BY SIZE COMMENT
4e3b13c8a266 3 months ago /bin/sh -c #(nop) CMD ["/bin/bash"] 0 B
<missing> 3 months ago /bin/sh -c sed -i 's/^#s*(deb.*universe)$/ 1.863 kB
<missing> 3 months ago /bin/sh -c set -xe && echo '#!/bin/sh' > /u 701 B
<missing> 3 months ago /bin/sh -c #(nop) ADD file:43cb048516c6b80f22 136.3 MB