400 028 6601
根据您的个性需求进行定制 先人一步 抢占小程序红利时代
本篇内容介绍了“Dockerfile怎么构建私有镜像”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！
乌什网站建设公司成都创新互联,乌什网站设计制作，有大型网站制作公司丰富经验。已为乌什上1000+提供企业网站建设服务。企业网站搭建\成都外贸网站建设公司要多少钱，请找那个售后服务好的乌什做网站的公司定做！
镜像的定制实际上就是定制每一层所添加的配置、文件。我们可以把每一层修改、安装、构建、操作的命令都写入一个脚本，这个脚本就是 Dockerfile。
Dockerfile 是一个文本文件，其内包含了一条条的指令，每一条指令构建一层，因此每一条指令的内容，就是描述该层应当如何构建。
以 nginx 为例。
在一个空白目录中，建立一个文本文件，并命名为 Dockerfile：
mkdir mynginx cd mynginx touch Dockerfile
内容为：
FROM nginx RUN echo 'Hello, Docker!
' > /usr/share/nginx/html/index.html
FROM：指定基础镜像
如果你以 scratch 为基础镜像的话，意味着你不以任何镜像为基础，接下来所写的指令将作为镜像的第一层开始存在。
对于 Linux 静态编译的程序来说，并不需要有操作系统提供运行时支持，所需的一切库都已经在可执行文件里了，因此直接 FROM scratch 会让镜像体积更加小巧。使用 Go 语言开发的应用很多会使用这种方式来制作镜像，这也是为什么有人认为 Go 是特别适合容器微服务架构的语言的原因之一。
所谓定制镜像，一定是以一个镜像为基础，在其上进行定制。基础镜像是必须指定的，而 FROM 就是指定基础镜像，因此一个 Dockerfile 中的 FROM 是必备的指令，并且必须是第一条指令。在 Docker Hub 上有非常多的高质量的官方镜像，有可以直接拿来使用的服务类的镜像，如 nginx、redis、MySQL、tomcat 等；可以在其中寻找一个最符合我们最终目标的镜像为基础镜像进行定制。
如果没有找到对应服务的镜像，官方镜像中还提供了一些更为基础的操作系统镜像，如 ubuntu、debian、centos、alpine 等，这些操作系统的软件库为我们提供了更广阔的扩展空间。
除了选择现有镜像为基础镜像外，Docker 还存在一个特殊的镜像，名为 scratch。这个镜像是虚拟的概念，并不实际存在，它标识一个空白的镜像。
FROM scratch ...
RUN：执行命令
shell 格式：RUN <命令>
RUN echo 'Hello, Docker!
' > /usr/share/nginx/html/index.html
exec 格式：RUN ["可执行文件", "参数1", "参数2"]
RUN tar -zxf redis.tar.gz -C /usr/src/redis --strip-components=1 RUN make -C /usr/src/redis RUN make -C /usr/src/redis install
RUN 指令是用来执行命令行命令的。由于命令行的强大能力，RUN 指令在定制镜像时是最常用的指令之一。其格式有两种：
上面我们利用 Dockerfile 定制了 nginx 镜像，然后就需要构建镜像。
在 Dockerfile 文件所在目录执行：
docker build -t nginx:v3 .
从命令的输出结果中，我们可以清晰地看到镜像的构建过程。在 Step2 中，RUN 指令启动了一个容器 xxx1，执行了所要求的命令，并最后提交了这一层 xxx2，随后删除了所用到的这个容器 xxx1。
格式：
COPY <源路径>... <目标路径>
COPY ["<源路径1>",... "<目标路径>"]
COPY 指令将从构建上下文目录中 <源路径> 的文件/目录复制到新的一层的镜像内的 <目标路径> 位置。比如：
COPY package.json /usr/src/app/
源路径可以是多个，甚至可以是通配符，如：
COPY hom* /mydir/ COPY hom?.txt /mydir/
ADD 指令和 COPY 的格式和性质基本一致。但是在 COPY 的基础上增加了一些功能。比如源路径可以是一个 URL，这种情况下，Docker 引擎会试图去下载这个链接的文件放到 <目标路径> 去。
在 Docker 官方的 Dockerfile 最佳实践文档中要求，尽可能地使用 COPY，因为 COPY 的语义很明确，就是复制文件而已，而 ADD 则包含了更复杂的功能，其行为也不一定清晰，最适合使用 ADD 的场景，就是所提及的需要自动解压缩的场合。
在 COPY 和 ADD 指令中选择的时候，可以遵循这样的原则，所有的文件复制均使用 COPY 命令，仅在需要自动解压缩的场合使用 ADD。
CMD 指令的格式和 RUN 相似，也是两种格式：
shell 格式：CMD <命令>
exec 格式：CMD ["可执行文件", "参数1", "参数2" ...]
参数列表格式：CMD ["参数1", "参数2", ...]。在指定了 ENTRYPOINT 指令后，用 CMD指定具体的参数。
Docker 不是虚拟机，容器就是进程。既然是进程，那么在启动容器的时候，需要指定所运行的程序及参数。CMD 指令就是用于指定默认的容器主进程启动命令的。
ENTRYPOINT 的目的和 CMD 一样，都是在指定容器启动程序及参数。ENTRYPOINT 在运行时也可以替代，不过比 CMD 要略显繁琐，需要通过 docker run 的参数 --entrypoint 来指定。
当指定了 ENTRYPOINT 后，CMD 的含义就发生了改变，不再是直接地运行其命令，而是将 CMD 的内容作为参数传给 ENTRYPOINT 指令，换句话说实际执行时，将变为：
" "
格式有两种：
ENV
ENV
这个指令很简单，就是设置环境变量而已，无论是后面的其他指令，如 RUN，还是运行时的应用，都可以直接使用这里定义的环境变量。
ENV VERSION=1.0 DEBUG=on NAME="Happy Feet" $VERSION # 使用环境变量
下列指令可以支持环境变量展开：ADD、COPY、ENV、EXPOSE、LABEL、USER、WORKDIR、VOLUME、STOPSIGNAL、ONBUILD。
格式：
ARG <参数名>[=<默认值>]
构建参数和 ENV 的效果一样，都是设置环境变量。所不同的是，ARG 所设置的构建环境的环境变量，在将来容器运行时是不会存在这些环境变量的。但是不要因此就使用 ARG 保存密码之类的信息，因为 docker history 还是可以看到所有值的。
Dockerfile 中的 ARG 指令是定义参数名称，以及定义其默认值。该默认值可以在构建命令 docker build 中用 --build-arg <参数名>=<值>来覆盖。
格式：
VOLUME ["<路径1>", "<路径2>" ...]
VOLUME <路径>
容器运行时应该尽量保持容器存储层不发生写操作，对于数据库类需要保存动态数据的应用，其数据库文件应该保存于劵(volume)中，为了防止运行时用户忘记将动态文件所保存目录挂在为卷，在 Dockerfile 中，我们可以实现指定某些目录挂在为匿名卷，这样在运行时如果用户不指定挂载，其应用也可以正常运行，不会向容器存储层写入大量数据。
VOLUME /data
这里的 /data 目录就会在运行时自动挂载为匿名卷，任何向 /data 中写入的信息都不会记录进容器存储层，从而保证了容器存储层的无状态化。当然，运行时可以覆盖这个挂载位置。比如：
docker run -d -v mydata:/data xxxx
格式为：EXPOSE <端口1> [<端口2>...]
EXPOSE 指令是声明运行时容器提供服务端口，这只是一个声明，在运行时并不会因为这个声明应用就会开启这个服务的应用。
在 Dockerfile 中写入这样的声明有两个好处：
是帮助镜像使用者理解这个镜像服务的守护端口，以方便配置映射。
在运行时使随机端口映射时，也就是 docker run -P 时，会自动随机映射 EXPOST 端口。
格式为：WORKDIR <工作目录路径>
使用 WORKDIR 指令可以来指定工作目录（或者称为当前目录），以后各层的当前目录就被被改为指定的目录，如果目录不存在，WORKDIR 会帮你建立目录。
之前提到一些初学者常犯的错误把 Dockerfile 等同于 Shell 脚本来书写，这种错误的理解还可能会导致出现下面这样的错误：
RUN cd /app RUN echo "hello" > world.txt
如果经这个 Dockerfile 进行构建镜像运行后，会发现找不到 /app/world.txt。
原因：
在 Shell 中，连续两行是同一个进程执行环境，因此，前一个命令修改的内存状态，会直接影响后一个命令。
而在 Dockerfile 中，这两行 RUN 命令的执行环境根本不同，是两个完全不同的容器。这就是对 Dockerfile 构建分层存储的概念不了解所导致的错误。
每个 RUN 都是启动一个容器、执行命令、然后提交存储层文件变更。
第一层 RUN cd /app 的执行仅仅是当前进程的工作目录变更 ，一个内存上的变化而已，而结果不会造成任何文件变更。而到第二层的时候，启动的是一个全新的容器，跟第一层的容器完全没关系，自然不可能继承前一层构建中的内存变化。
如果需要改变以后各层的工作目录的位置，那么应该使用 WORKDIR 指令。
格式为：USER <用户名>
USER 指令和 WORKDIR 相似，都是改变环境状态并影响以后的层。WORKDIR 是改变工作目录，USER 则是改变之后层的执行 RUN、CMD 以及 ENTRYPOINT 这类命令的身份。
当然，和 WORKDIR 一样，USER 只是帮助你切换到指定用户而已，这个用户必须是事先建立好的，否则无法切换。
RUN groupadd -r redis && useradd -r- g redis redis USER redis RUN ["redis-server"]
格式：
HEALTHCHECK [选项] CMD <命令>：设置检查容器健康状况的命令。
HEALTHCHECK NONE：如果基础镜像有健康检查指令，可以屏蔽掉其健康检查指令。
HEALTHCHECK 指令是告诉 Docker 应该如何进行判断容器的状态是否正常，这是 Docker 1.12 引入的新指令。通过该指令指定一行命令，用这行命令来判断容器主进程的服务状态是否还真长，从而比较真实的反应容器实际状态。
一个镜像指定了 HEALTHCHECK 指令后，用其启动容器，初始状态会为 starting，在 执行健康检查成功后变为 healthy，如果连续一定次数失败，则会变为 unhealthy。
HEALTHCHECK 支持下列选项：
--interval=<间隔>：两次健康检查的间隔，默认为 30 秒。
--timeout=<时长>：健康检查命令运行超时时间，如果超过这个时间，本次健康检查就被视为失败，默认 30 秒。
--retries=<次数>：当连续失败指定次数后，则将容器状态视为 unhealthy，默认 3 次。
为了帮助排障，健康检查命令的输出（包括 stdout 以及 stderr）都会被存储于健康检查状态里，可以用 docker inspect 来查看。
格式：ONBUILD <其他指令>
ONBUILD 是一个特殊的指令，它后面跟的是其他指令，比如 RUN、COPY 等，而这些指令，在当前镜像构建时并不会执行。只有当以当前镜像为基础镜像，去构建下一级镜像的时候才会被执行。
Dockerfile 中的其他指令都是为了定制当前镜像而逐步内的，唯有 ONBUILD 是为了帮助别人定制自己而准备的。
Docker 还提供了 docker save 和 docker load 命令，用以将镜像保存为一个 tar 文件，然后传输到另一个位置上，再加载进来。这是在没有 Docker Registry 时的做法，现在已经不推荐，镜像迁移应该直接使用 Docker Registry，无论是直接使用 Docker Hub，还是使用内网私有 Registry 都可以。
例如：保存 nginx 镜像
docker save nginx | gzip > nginx-latest.tar.gz
然后我们将 nginx-latest.tar.gz 文件复制到另一个机器上，再次加载镜像：
docekr load -i nginx-latest.tar.gz
“Dockerfile怎么构建私有镜像”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注创新互联网站，小编将为大家输出更多高质量的实用文章！
