一、镜像管理

1、拉取镜像

docker pull [选项] [Docker Registry 地址[:端口号]/]仓库名[:标签]

-- Docker 镜像仓库地址：一般是 域名或者IP[:端口号]。默认地址是 Docker Hub
-- 仓库名：两段式名称，即 用户名/软件名。对于Docker Hub，如果不给出用户名，则默认为 library，也就是官方镜像。

从下载过程中可以看到我们之前 提及的分层存储的概念，镜像是由多层存储所构成。下载也是一层一层的去下载，并非单一文件。

tips：Docker Hub 注册的时候要翻墙，否则那个注册按钮点击不了~

2、查看镜像

docker image ls
docker images

列表包含了 仓库名、标签、镜像ID、创建时间 以及 所占用的空间。

3、运行镜像

docker run -it --rm -d -p 8888:8080 tomcat:8.0
 -i：交互式操作
 -t：终端
 -rm：容器退出后随之将其删除，可以避免浪费空间
 -p ：端口映射
 -d ：容器在后台运行

指明了 -d 运行镜像，会返回容器的 id；如果不指明 -d 运行镜像，会打印出 catalina.out 的 日志，在 [crtl +c] 后，容器即停止运行。

至于容器启动后，如何关闭容器进程，查看系统日志等，会在下一篇文章中说明~

4、删除镜像

build 自己的 docker 镜像的时候，有时会遇到用一个甚至多个中间层镜像，这会一定程度上减少最终打包出来 docker 镜像的大小，但是会产生一些tag 为 none 的无用镜像，也称为悬挂镜像 (dangling images)

docker image rm IMAGE_ID（不需要全部的id字符，足够区分别的镜像就可以了）
docker image rm 镜像名（REPOSITORY:TAG） --备注：这个在删除远程推送镜像的时候特别有用
docker image rm $(docker images -q) --备注：批量删除所有的镜像
docker images -f "dangling=true" --备注：列出所有的 dangling images
docker rmi $(docker images -q -f dangling=true) --备注：删除所有未打 dangling 标签的镜像
docker image prune --备注：删除 dangling 或所有未被使用的镜像

tips：要注意镜像和容器依赖的问题。如果用这个镜像启动的容器存在（即使容器没有运行），那么同样不可以删除这个镜像，因为容器是以镜像为基础，再加一层容器存储层，组成的多层结构去运行的。所以删除 image 前要删除 container 中的引用。

5、镜像的导入导出

镜像的导入导出可以用于在不同的 Docker 物理主机上做迁移。

#打包压缩镜像：
docker save [镜像名:tag] | gzip > [保存的路径和文件名]
docker save admin:2.3.1 | gzip > /docker/admin.tar.gz
#解压缩导入镜像：
zcat admin.tar.gz | docker import - [镜像名:tag]
zcat admin.tar.gz | docker import - admin:latest

二、制作镜像

镜像的定制实际上就是定制每一层所添加的配置、文件。我们通常把每一层修改、安装、构建、操作的命令都写入一个脚本，用这个脚本来构建、定制镜像，这个脚本就是 Dockerfile。

之前说过，镜像是分层存储的，Dockerfile 中每一个指令都会构建一层。镜像构建时，一定要确保每一层只添加真正需要添加的东西，任何无关的东西都应该清理掉，避免镜像的臃肿。

现在我们来研究下 Dockerfile 的命令（不推荐使用的命令不做介绍），然后再用个 Demo 来说明：

FROM：制定基础镜像，镜像的定制一定是以一个镜像为基础，在其上进行定制。FROM 是必备的命令，而且必须是第一条指令。FROM scratch 意味着你不以任何镜像为基础，接下来所写的指令将作为镜像第一层开始存在。

RUN：用来执行命令行命令的。有两种格式：

-- shell 格式：RUN <命令>，就像直接在命令行中输入的命令一样。
-- exec 格式：RUN ["可执行文件", "参数1", "参数2"]，这更像是函数调用中的格式。

WORKDIR：指定工作目录，以后各层的当前目录就被改为指定的目录，如该目录不存在，WORKDIR 会帮你建立目录。

-- 格式：WORKDIR <工作目录路径>

USER：USER 指令和 WORKDIR 相似，都是改变环境状态并影响以后的层。

-- USER <用户名>

COPY：将从 <源路径>（上下文路径） 的文件/目录复制到新的一层的镜像内的 <目标路径> （可以是容器内的绝对路径或者相对于 WORKDIR 的相对路径）位置，源文件的各种元数据都会保留，比如读、写、执行权限等。

-- COPY <源路径> <目标路径>
-- COPY ["<源路径1>",... "<目标路径>"]

CMD：用于指定默认的容器主进程的启动命令的（执行目标镜像中包含的软件），只能出现一次，CMD 后面的命令可被运行时 [ docker run xxxx:1.0 参数 ] 中的参数取代。对于容器而言，其启动程序就是容器应用进程，容器就是为了主进程而存在的，主进程退出，容器就失去了存在的意义，从而退出，其它辅助进程不是它需要关心的东西。

-- shell 格式：CMD <命令>
-- exec 格式：CMD ["可执行文件", "参数1", "参数2"...]
-- 参数列表格式：CMD ["参数1", "参数2"...]。在指定了 ENTRYPOINT 指令后，用 CMD 指定具体的参数。用来和 ENTRYPOINT 指令搭配使用

ENTRYPOINT：目的和 CMD 一样，都是在指定容器启动程序及参数，只能出现一次。主要有两点不同，一是 ENTRYPOINT 可以在启动时，为其之后的命令添加自定义的参数；二是与 CMD 的交互，当 Dockerfile 文件中指定了 ENTRYPOINT 时，CMD 中的内容就变成了 ENTRYPOINT的参数。

-- shell 格式：ENTRYPOINT <命令>
-- exec 格式：ENTRYPOINT ["可执行文件", "参数1", "参数2"]

ENV：设置环境变量，无论是后面的其它指令，还是运行时的应用，都可以直接使用这里定义的环境变量（$KEY）

-- ENV <key> <value>
-- ENV <key1>=<value1> <key2>=<value2>...

ARG：和 ENV 的效果一样，都是设置环境变量。所不同的是，ARG 所设置的构建环境的环境变量，在将来容器运行时是不会存在这些环境变量的。而且该值可以在构建命令 docker build 中用 --build-arg <参数名>=<值> 来覆盖。

-- ARG <参数名>[=<默认值>]

VOLUME：指定某些目录挂载为匿名卷，这样在运行时如果用户不指定挂载，其应用也可以正常运行，不会向容器存储层写入大量数据。

-- VOLUME ["<路径1>", "<路径2>"...]
-- VOLUME <路径>

EXPOSE：声明运行时容器提供服务端口，这只是一个声明，在运行时并不会因为这个声明应用就会开启这个端口的服务。主要是为了镜像使用者在宿主开启端口服务时，可以映射到容器的端口。

-- EXPOSE <端口1> [<端口2>...]

HEALTHCHECK：告诉 Docker 应该如何进行判断容器的状态是否正常，当在一个镜像指定了 HEALTHCHECK 指令后，用其启动容器，初始状态会为 starting，在 HEALTHCHECK 指令检查成功后变为 healthy，如果连续一定次数失败，则会变为 unhealthy。

-- HEALTHCHECK [选项] CMD <命令>：设置检查容器健康状况的命令
--interval=<间隔>：两次健康检查的间隔，默认为 30 秒；
--timeout=<时长>：健康检查命令运行超时时间，如果超过这个时间，本次健康检查就被视为失败，默认 30 秒；
--retries=<次数>：当连续失败指定次数后，则将容器状态视为 unhealthy，默认 3 次。

-- HEALTHCHECK NONE：如果基础镜像有健康检查指令，使用这行可以屏蔽掉其健康检查指令

ONBUILD： 是一个特殊的指令，它后面跟的是其它指令，比如 RUN, COPY 等，而这些指令，在当前镜像构建时并不会被执行。只有当以当前镜像为基础镜像，去构建下一级镜像的时候才会被执行。

-- ONBUILD <其它指令>

tips：在指令格式上，一般推荐使用 exec 格式，这类格式在解析时会被解析为 JSON 数组，因此一定要使用双引号 "，而不要使用单引号。

简单了解完这些命令后，让我们来试着制作一个web工程的镜像吧！为此，查了很多网上制作镜像的教程，结果都不是很尽人意，很多竟然都是通过 docker commit 来制作的（不推荐使用 docker commit 来制作镜像，会添加进很多编译的文件，造成镜像的臃肿），还有一些虽然是通过 Dockerfile 文件的方式来制作镜像，但是 Dockerfile 的语法却不是很规范（比如将多个 Linux 命令写在多行，造成 镜像无谓的分层，因为Dockerfile 一条命令就是一层结构）。

所以就自己着手写一个 Dockerfile 文件吧！思路是这样的，首先先写一个基础环境镜像，基于 centos 服务器，安装好 jdk 环境和 Tomcat；然后基于这个基础环境镜像构建web镜像 — 将 war 包拷贝进 webapps 目录，启动 Tomcat。

基础镜像文件 Dockerfile：

FROM centos
#1、指定工作目录
WORKDIR /usr/local
#2、指定版本信息
ENV JAVA=jdk-8u181-linux-x64 TOMCAT=apache-tomcat-8.0.53
#3、创建目录,多个命令尽量在一个Dockerfile 命令中完成，避免构建多层,做好清理工作
RUN mkdir java \
 && mkdir tomcat \
 && cd java \
 && yum -y install wget \
 && wget -q -O jdk-linux.rpm --no-check-certificate --no-cookies --header "Cookie: oraclelicense=accept-securebackup-cookie" http://download.oracle.com/otn-pub/java/jdk/8u181-b13/96a7b8442fe848ef90c96a2fad6ed6d1/${JAVA}.rpm \
 && rpm -ivh jdk-linux.rpm \
 && rm -rf jdk-linux.rpm \
 && cd ../tomcat \
 && wget -q http://apache.claz.org/tomcat/tomcat-8/v8.0.53/bin/${TOMCAT}.tar.gz \
 && tar -zxv -f ${TOMCAT}.tar.gz \
 && rm -rf ${TOMCAT}.tar.gz \
 && rm -rf ${TOMCAT}/webapps/ROOT \
 && yum -y remove wget;
#4、把上下文目录中的 war 复制进来
ONBUILD COPY *.war ./tomcat/${TOMCAT}/webapps/
#5、启动容器
ONBUILD ENTRYPOINT ["/usr/local/tomcat/apache-tomcat-8.0.53/bin/catalina.sh","run"]
#6、基础环境构建完毕
CMD ["sh","-c","echo Environment construction completed"]

然后运行构建镜像，注意docker build 最后面的那个点，表示的是镜像的上下文目录，COPY 命令的上下文目录指的就是这个。

这个镜像制作的，额，差强人意吧，竟然有600多兆。不过，最开放我思维的是那两个 ONBUILD 命令，就像上文提到的 ONBUILD 命令本次镜像不会被执行，只有以这个镜像为基础镜像的时候才会被执行。所以，大家想想看，有了这个基础镜像后，我们将打好的 war 包放在上下文目录，然后就可以运行起来任意的 web 工程啦！

接下来，来看看 web 镜像是怎么制作出来的吧！已经进展到了这一步，你会发现出奇的简单~

FROM myenv:1.0

是的，你没有看错，整个 Dockerfile 就只要这行命令就够了，然后构建的时候，会帮你把 war 包放进 webapps 目录（ONBUILD 的效果），接着构建运行起来吧~

#构建（--no-cache=true 表示不使用镜像缓存）
docker build -t myweb .
#运行
docker run -p 7575:8080 myweb

哈哈，折腾了一个周末，终于成功了！小激动小激动~~ 写的两个镜像已经上传到了 Docker hub，喜欢的点个推荐吧！

Dockerfile 的一些书写建议：

1. 使用 Dockerfile 构建镜像时最好是将 Dockerfile 放置在一个新建的空目录下。然后将构建镜像所需要的文件添加到该目录中。
2. 应该保证在一个容器只运行一个进程。将多个应用解耦到不同容器中，保证容器的横向扩展和复用。例如 web 应用应该包含三个容器：web应用、数据库、缓存。
3. FROM：推荐使用 Alpine 镜像，因为它被严格控制并保持最小尺寸（目前小于 5 MB），但它仍然是一个完整的 Linux 发行版。
4. 多行命令用反斜杠 \ 分割成多行，增加可读性。
5. 不要使用 RUN apt-get upgrade 或 dist-upgrade，因为许多基础镜像中的「必须」包不会在一个非特权容器中升级。
6. 永远将 RUN apt-get update 和 apt-get install 组合成一条 RUN 声明，将 apt-get update 放在一条单独的 RUN 声明中会导致缓存问题以及后续的 apt-get install 失败。
7. 应该避免使用 sudo，因为它不可预期的 TTY 和信号转发行为可能造成的问题比它能解决的问题还多。

Docker hub 地址：https://hub.docker.com/u/jmcui/