Docker 镜像

（一）下载实例

在这里插入图片描述

（二）镜像基本操作

在这里插入图片描述
备注：
相同名称的镜像可以存在多个，即需要不同的tags版本

（三）使用 Dockerfile 定制镜像

（1）介绍

镜像的定制实际上就是定制每一层所添加的配置、文件。如果我们可以把每一层修改、安装、构建、操作的命令都写入一个脚本，用这个脚本来构建、定制镜像，那么之前提及的无法重复的问题、镜像构建透明性的问题、体积的问题就都会解决。这个脚本就是 Dockerfile。

Dockerfile 是一个文本文件，其内包含了一条条的指令(Instruction)，每一条指令构建一层，因此每一条指令的内容，就是描述该层应当如何构建。

注意：Docker是存在[沙箱机制]的，即每个启动的镜像是互不干扰的，所以我们在修改容器镜像的时候是要确定修改哪一个.
此外，每次执行run命令都是在新建一个容器对象，类似于类被new了一个对象，所以此时操作的可能不是我们想要操作的那个对象,当某个容器启动的时候我们想要操作我们需要进入该容器对象内，而不是重新run启动一个,应该exec

（2）自定义镜像

1：自定义镜像Dockerfile脚本必须有FROM命令
2：自定义镜像必须继承于一个基础镜像，即FROM

需求：自定义一个tomcat镜像，首页访问显示Hello World
流程：
1：首先你要清楚tomcat的目录结构和需要修改的部分
2：本次就修改index.jsp

FROM tomcat
RUN echo "Hello World" > /usr/local/tomcat/webapps/ROOT/index.html

3：构建镜像

docker build -t nginx:v3 .

4：启动Docker的Tomcat

docker run -p 8080:8080 myshop

（3）具体操作步骤

--在虚拟机服务器中进入目录：(默认都在这个目录下创建)
cd   /usr/local
--创建tomcat目录
mkdir  tomcat
--创建Dockerfile 文件
touch Dockerfile
--编辑Dockerfile文件
vim  Dockerfile
-- 输入如下内容，注意不能使用多个RUN，需要使用WORKDIR，详解参考（（四）Dockerfile相关命令）https://www.funtl.com/zh/docs-docker/Docker-Dockerfile-%E6%8C%87%E4%BB%A4%E8%AF%A6%E8%A7%A3.html#workdir-指定工作目录FROM tomcat
RUN  cd   /usr/local/tomcat/webapps/ \&&   mkdir ROOT   \&&  cd  ROOT    \&&  touch  index.html  \&&  echo "Hello World" > index.html

--构建镜像 , 点是告诉程序在当前目录下寻找Dockerfile文件,
myshop 是自定义的镜像名称
docker build -t myshop .

在这里插入图片描述
从图片我们看到构建了对应的镜像，而且是构建了两层

-- 查看镜像
docker  images

在这里插入图片描述

--启动镜像bash(docker run -it --rm tomcat:标签 bash)
docker run -it --rm tomcat bash
此时可去对应的目录下查看，如果错误，根据实际情况检查测试：docker run -p 8080:8080 myshop  启动Docker的Tomcat

（4）Dockerfile相关命令

FROM

FROM指定一个基础镜像，一般情况下一个可用的 Dockerfile一定是 FROM 为第一个指令。至于image则可以是任何合理存在的image镜像。 FROM 一定是首个非注释指令 Dockerfile. FROM 可以在一个 Dockerfile 中出现多次，以便于创建混合的images。如果没有指定 tag ，latest 将会被指定为要使用的基础镜像版本。

MAINTAINER

这里是用于指定镜像制作者的信息 RUN RUN命令将在当前image中执行任意合法命令并提交执行结果。命令执行提交后，就会自动执行Dockerfile中的下一个指令。层级 RUN 指令和生成提交是符合Docker核心理念的做法。它允许像版本控制那样，在任意一个点，对image 镜像进行定制化构建。 RUN 指令缓存不会在下个命令执行时自动失效。比如 RUN apt-get dist-upgrade -y 的缓存就可能被用于下一个指令. --no-cache 标志可以被用于强制取消缓存使用。

ENV

ENV指令可以用于为docker容器设置环境变量 ENV设置的环境变量，可以使用 docker inspect命令来查看。同时还可以使用docker run --env =来修改环境变量。

USER USER

用来切换运行属主身份的。Docker 默认是使用 root，但若不需要，建议切换使用者身分，毕竟 root 权限太大了，使用上有安全的风险。

WORKDIR

WORKDIR 用来切换工作目录的。Docker 默认的工作目录是/，只有 RUN 能执行 cd 命令切换目录，而且还只作用在当下下的 RUN，也就是说每一个 RUN 都是独立进行的。如果想让其他指令在指定的目录下执行，就得靠 WORKDIR。WORKDIR 动作的目录改变是持久的，不用每个指令前都使用一次 WORKDIR。

COPY

COPY 将文件从路径复制添加到容器内部路径。必须是想对于源文件夹的一个文件或目录，也可以是一个远程的url，是目标容器中的绝对路径。所有的新文件和文件夹都会创建UID 和 GID 。事实上如果是一个远程文件URL，那么目标文件的权限将会是600。

ADD

ADD 将文件从路径复制添加到容器内部路径。必须是想对于源文件夹的一个文件或目录，也可以是一个远程的url。是目标容器中的绝对路径。所有的新文件和文件夹都会创建UID 和 GID。事实上如果是一个远程文件URL，那么目标文件的权限将会是600。

VOLUME

创建一个可以从本地主机或其他容器挂载的挂载点，一般用来存放数据库和需要保持的数据等。

EXPOSE

EXPOSE 指令指定在docker允许时指定的端口进行转发。

CMD

Dockerfile.中只能有一个CMD指令。如果你指定了多个，那么最后个CMD指令是生效的。 CMD指令的主要作用是提供默认的执行容器。这些默认值可以包括可执行文件，也可以省略可执行文件。当你使用shell或exec格式时， CMD 会自动执行这个命令。

ONBUILD

ONBUILD 的作用就是让指令延迟執行，延迟到下一个使用 FROM 的 Dockerfile 在建立 image 时执行，只限延迟一次。 ONBUILD 的使用情景是在建立镜像时取得最新的源码 (搭配 RUN) 与限定系统框架。

ARG

ARG是Docker1.9 版本才新加入的指令。 ARG 定义的变量只在建立 image 时有效，建立完成后变量就失效消失 LABEL 定义一个 image 标签 Owner，并赋值，其值为变量 Name 的值。(LABEL Owner=$Name )

ENTRYPOINT

ENTRYPOINT是指定 Docker image 运行成 instance (也就是 Docker container) 时，要执行的命令或者文件。

（5）镜像构建上下文（Context）

如果注意，会看到 docker build 命令最后有一个 .。. 表示当前目录，而 Dockerfile 就在当前目录，因此不少初学者以为这个路径是在指定 Dockerfile 所在路径，这么理解其实是不准确的。如果对应上面的命令格式，你可能会发现，这是在指定上下文路径。那么什么是上下文呢？

首先我们要理解 docker build 的工作原理。Docker 在运行时分为 Docker 引擎（也就是服务端守护进程）和客户端工具。Docker 的引擎提供了一组 REST API，被称为 Docker Remote API，而如 docker 命令这样的客户端工具，则是通过这组 API 与 Docker 引擎交互，从而完成各种功能。因此，虽然表面上我们好像是在本机执行各种 docker 功能，但实际上，一切都是使用的远程调用形式在服务端（Docker 引擎）完成。也因为这种 C/S 设计，让我们操作远程服务器的 Docker 引擎变得轻而易举。

当我们进行镜像构建的时候，并非所有定制都会通过 RUN 指令完成，经常会需要将一些本地文件复制进镜像，比如通过 COPY 指令、ADD 指令等。而 docker build 命令构建镜像，其实并非在本地构建，而是在服务端，也就是 Docker 引擎中构建的。那么在这种客户端/服务端的架构中，如何才能让服务端获得本地文件呢？

这就引入了上下文的概念。当构建的时候，用户会指定构建镜像上下文的路径，docker build 命令得知这个路径后，会将路径下的所有内容打包，然后上传给 Docker 引擎。这样 Docker 引擎收到这个上下文包后，展开就会获得构建镜像所需的一切文件

在这里插入图片描述
如果在 Dockerfile 中这么写：

COPY ./package.json /app/

这并不是要复制执行 docker build 命令所在的目录下的 package.json，也不是复制 Dockerfile 所在目录下的 package.json，而是复制上下文（context）目录下的 package.json。

因此，COPY 这类指令中的源文件的路径都是相对路径。这也是初学者经常会问的为什么 COPY …/package.json /app 或者 COPY /opt/xxxx /app 无法工作的原因，因为这些路径已经超出了上下文的范围，Docker 引擎无法获得这些位置的文件。如果真的需要那些文件，应该将它们复制到上下文目录中去。

现在就可以理解刚才的命令 docker build -t nginx:v3 . 中的这个 .，实际上是在指定上下文的目录，docker build 命令会将该目录下的内容打包交给 Docker 引擎以帮助构建镜像。

如果观察 docker build 输出，我们其实已经看到了这个发送上下文的过程：

$ docker build -t nginx:v3 .
Sending build context to Docker daemon 2.048 kB
...

理解构建上下文对于镜像构建是很重要的，避免犯一些不应该的错误。比如有些初学者在发现 COPY /opt/xxxx /app 不工作后，于是干脆将 Dockerfile 放到了硬盘根目录去构建，结果发现 docker build 执行后，在发送一个几十 GB 的东西，极为缓慢而且很容易构建失败。那是因为这种做法是在让 docker build 打包整个硬盘，这显然是使用错误。

一般来说，应该会将 Dockerfile 置于一个空目录下，或者项目根目录下。如果该目录下没有所需文件，那么应该把所需文件复制一份过来。如果目录下有些东西确实不希望构建时传给 Docker 引擎，那么可以用 .gitignore 一样的语法写一个 .dockerignore，该文件是用于剔除不需要作为上下文传递给 Docker 引擎的。

那么为什么会有人误以为 . 是指定 Dockerfile 所在目录呢？这是因为在默认情况下，如果不额外指定 Dockerfile 的话，会将上下文目录下的名为 Dockerfile 的文件作为 Dockerfile。

这只是默认行为，实际上 Dockerfile 的文件名并不要求必须为 Dockerfile，而且并不要求必须位于上下文目录中，比如可以用 -f …/Dockerfile.php 参数指定某个文件作为 Dockerfile。

当然，一般大家习惯性的会使用默认的文件名 Dockerfile，以及会将其置于镜像构建上下文目录中