微企点建好网站后要怎么做,网站制作费用多少钱,充电宝seo关键词优化,阿里巴巴推广FROM 基础镜像
可以选择现有的镜像#xff0c;比如centos、debian、apline等#xff0c;特殊镜像scratch#xff0c;它是一个空镜像。
如果你以 scratch 为基础镜像的话#xff0c;意味着你不以任何镜像为基础#xff0c;接下来所写的指令将作为镜像第一层开始存在。
不…FROM 基础镜像
可以选择现有的镜像比如centos、debian、apline等特殊镜像scratch它是一个空镜像。
如果你以 scratch 为基础镜像的话意味着你不以任何镜像为基础接下来所写的指令将作为镜像第一层开始存在。
不以任何系统为基础直接将可执行文件复制进镜像的做法并不罕见比如swarm、coreos/etcd。对于 Linux 下静态编译的程序来说并不需要有操作系统提供运行时支持所需的一切库都已经在可执行文件里了因此直接 FROM scratch 会让镜像体积更加小巧。使用 Go 语言开发的应用很多会使用这种方式来制作镜像这也是为什么有人认为 Go 是特别适合容器微服务架构的语言的原因之一。
RUN 指令 shell 格式RUN 命令就像直接在命令行中输入的命令一样。刚才写的 Dockerfile 中的 RUN 指令就是这种格式。 exec 格式RUN [可执行文件, 参数1, 参数2]这更像是函数调用中的格式。 Union FS 是有最大层数限制的比如 AUFS曾经是最大不能超过 42 层现在是不能超过 127 层。
构建上下文
如果注意会看到 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以及会将其置于镜像构建上下文目录中。
重点需要理解构建上下文对于构建优化比较重要。
其他用法
1. 从url构建
示例
docker build https://github.com/twang2218/gitlab-ce-zh.git#:8.14 这行命令指定了构建所需的 Git repo并且指定默认的 master 分支构建目录为 /8.14/然后 Docker 就会自己去 git clone 这个项目、切换到指定分支、并进入到指定目录后开始构建。 2. 用给定的 tar 压缩包构建
docker build http://server/context.tar.gz ocker 引擎会下载这个包并自动解压缩以其作为上下文开始构建。 3. 从标准输入中读取 Dockerfile 进行构建
docker build - Dockerfilecat Dockerfile | docker build - 如果标准输入传入的是文本文件则将其视为 Dockerfile并开始构建。这种形式由于直接从标准输入中读取 Dockerfile 的内容它没有上下文因此不可以像其他方法那样可以将本地文件 COPY 进镜像之类的事情。 4. 从标准输入中读取上下文压缩包进行构建
docker build - context.tar.gz如果发现标准输入的文件格式是 gzip、bzip2 以及 xz 的话将会使其为上下文压缩包直接将其展开将里面视为上下文并开始构建。
更多详情请阅读如何优雅的使用 Dockerfile 定制镜像超详细
