docker-build - 云端在线

程序：

您的姓名

docker-build - 从 PATH 的源代码构建一个新图像

概要

搬运工人 建立 [--构建参数[=[]]][--cpu 份额[=0]][--cgroup-父级[=CGROUP-家长]]
[ - 帮帮我[-f|- 文件[=路径/Dockerfile]][--force-rm[- 隔离[=默认]][--无缓存]
[- 拉[-q|- 安静的[- R M[=true]][-t|- 标签[=[]]][-m|- 记忆[=记忆]]
[--内存交换[=极限]][--shm-大小[=SHM-尺寸]][--cpu-周期[=0]][--cpu-配额[=0]]
[--cpuset-cpus[=CPUSET-CPU]][--cpuset-mems[=CPUSET-MEMS]][--ulimit[=[]]] 路径 | 网址 | ——

商品描述

这将从中指定的目录中读取 Dockerfile PATH. 它也发送任何
在当前目录中找到的其他文件和目录到 Docker 守护进程。 这
此目录的内容将由 地址 在 Dockerfile 中找到的命令。

警告，这将根据内容向 Docker 守护进程发送大量数据
当前目录。 构建由 Docker 守护进程运行，而不是由 CLI 运行，所以整个
上下文必须传输到守护进程。 Docker CLI 报告“发送构建上下文
到 Docker 守护进程”，当上下文被发送到守护进程时。

当给出指向 tarball 存档或单个 Dockerfile 的 URL 时，不会发送上下文
从客户端到 Docker 守护进程。 在这种情况下，位于根目录的 Dockerfile
存档和存档的其余部分将用作构建的上下文。 当一个 Git
存储库设置为 网址，存储库在本地克隆，然后作为
上下文。

配置

-f, - 文件=路径/Dockerfile
要使用的 Dockerfile 的路径。 如果路径是相对路径，而您是
从本地目录构建，则路径必须相对于该目录
目录。 如果您是从指向一个的远程 URL 构建
tarball 或 Git 存储库，则路径必须相对于
远程上下文。 在所有情况下，文件都必须在构建上下文中。
默认是 Dockerfile.

--构建参数=变量
a 的名称和值 构建参数.

例如，如果你想传递一个值 HTTP_PROXY， 使用
--build-arg=http_proxy="http://some.proxy.url"

用户在构建时传递这些值。 Docker 使用 构建参数 作为
通过 Dockerfile 运行的命令的环境上下文 跑 指令
或用于其他 Dockerfile 指令中的变量扩展。 这不是故意的
用于传递秘密值。 ⟨/reference/builder/#arg⟩

--force-rm=true|false
始终删除中间容器，即使在构建失败后也是如此。 默认是
false.

- 隔离="默认"
隔离指定容器使用的隔离技术类型。

--无缓存=true|false
构建图像时不要使用缓存。 默认是 false.

- 帮帮我
打印使用说明

- 拉=true|false
始终尝试拉取更新版本的映像。 默认是 false.

-q, - 安静的=true|false
成功时禁止构建输出并打印图像 ID。 默认是 false.

- R M=true|false
成功构建后删除中间容器。 默认是 true.

-t, - 标签=“”
要应用于生成的图像的存储库名称（以及可选的标签）
成功的案例。

-m, - 记忆=记忆
内存限制

--内存交换=极限
等于内存加交换的限制值。 必须与 -m (- 记忆） 旗帜。 这
交换 极限 应该总是大于 -m (- 记忆） 价值。

格式 极限 is [ ]. 单位可以 b （字节）， k （千字节）， m
（兆字节），或 g （千兆字节）。 如果不指定单位， b 用来。 将限制设置为 -1 至
启用无限交换。

--shm-大小=SHM-尺寸
尺寸 /开发/shm. 格式是 . 数 必须大于 0.
单位是可选的，可以是 b （字节）， k （千字节）， m （兆字节），或 g （千兆字节）。
如果省略单位，系统将使用字节。
如果完全省略大小，系统将使用 64 m.

--cpu 份额=0
CPU 份额（相对权重）。

默认情况下，所有容器获得相同比例的 CPU 周期。
CPU 份额是一个“相对权重”，相对于默认设置 1024。
此默认值在此处定义：

猫 /sys/fs/cgroup/cpu/cpu.shares
1024

你可以通过调整容器的 CPU 份额来改变这个比例
权重相对于所有其他正在运行的容器的权重。

要修改默认值 1024 的比例，请使用 --cpu 份额
标志将权重设置为 2 或更高。

容器 CPU 份额标志
{C0} CPU 的 60% --cpu-shares=614（614 是 60 的 1024%）
{C1} CPU 的 40% --cpu-shares=410（410 是 40 的 1024%）

该比例仅在 CPU 密集型进程正在运行时应用。
当一个容器中的任务空闲时，其他容器可以使用
剩余的 CPU 时间。 实际使用的 CPU 时间取决于
系统上运行的容器数量。

例如，考虑三个容器，其中一个有 --cpu-shares=1024 和
另外两个有 --cpu-shares=512. 当在所有三个过程中
容器尝试使用 100% 的 CPU，第一个容器将收到
占总 CPU 时间的 50%。 如果您添加第四个容器 --cpu-shares=1024,
第一个容器只获得 33% 的 CPU。 剩余的容器
获得 16.5%、16.5% 和 33% 的 CPU。

Container CPU share Flag CPU 时间
{C0} 100% --cpu-shares=1024 33%
{C1} 50% --cpu-shares=512 16.5%
{C2} 50% --cpu-shares=512 16.5%
{C4} 100% --cpu-shares=1024 33%

在多核系统上，CPU 时间的份额分布在 CPU 上
核心。 即使容器被限制在少于 100% 的 CPU 时间，它也可以
100% 使用每个单独的 CPU 内核。

例如，考虑具有三个以上内核的系统。 如果你开始一个
容器 {C0} - --cpu-shares=512 运行一个进程和另一个容器
{C1} - --cpu-shares=1024 运行两个进程，这可能导致以下结果
CPU份额划分：

PID 容器 CPU CPU 份额
100 {C0} 0 100% 的 CPU0
101 {C1} 1 100% 的 CPU1
102 {C1} 2 100% 的 CPU2

--cpu-周期=0
限制 CPU CFS（完全公平调度程序）周期。

限制容器的 CPU 使用率。 这个标志会导致内核限制
容器的 CPU 使用率到您指定的时间段。

--cpu-配额=0
限制 CPU CFS（完全公平调度程序）配额。

默认情况下，容器以完整的 CPU 资源运行。 这个标志使内核
将容器的 CPU 使用率限制为您指定的配额。

--cpuset-cpus=CPUSET-CPU
允许执行的 CPU (0-3, 0,1)。

--cpuset-mems=CPUSET-MEMS
允许执行的内存节点 (MEM) (0-3, 0,1)。 仅对
NUMA 系统。

例如，如果您的系统上有四个内存节点 (0-3)，请使用 --cpuset-mems=0,1 至
确保 Docker 容器中的进程只使用前两个内存中的内存
节点。

--cgroup-父级=CGROUP-家长
路径 小组 容器的 群 被创建。

如果路径不是绝对路径，则认为该路径相对于 小组 的路径
初始化进程。 如果 Cgroup 尚不存在，则会创建它们。

--ulimit=[]
超限选项

想了解如何 极限 看到
⟨https://docs.docker.com/reference/commandline/run/#setting-ulimits-in-a-container⟩

示例

建筑物 an 图片 运用 a Dockerfile 位于 内 此 当前 目录

可以使用 build 命令和 Dockerfile 构建 Docker 镜像：

码头工人建造。

在构建过程中，Docker 创建中间镜像。 为了留住他们，你
必须明确设置 --rm=假.

docker build --rm=false 。

一个好的做法是创建一个具有相关名称的子目录并创建 Dockerfile
在那个目录中。 例如，一个名为 mongo 的目录可能包含一个 Dockerfile
创建一个 Docker MongoDB 镜像。 同样，另一个名为 httpd 的目录可用于
存储 Apache Web 服务器映像的 Dockerfile。

将图像所需的文件添加到子目录中也是一个很好的做法。
这些文件将被指定为 COPY or 地址 中的说明 Dockerfile.

注意：如果你包含一个 tar 文件（一个好的做法），那么 Docker 会自动解压
tar 文件中指定的内容 地址 指令进入指定的
目标。

建筑物 an 图片 和 命名 这 图片

一个好的做法是为您正在构建的图像命名。 注意只有a-z0-9-_。
应该用于一致性。 这里没有硬性规定，但最好给出
名称考虑。

特 -t/- 标签 标志用于重命名图像。 这里有些例子：

虽然这不是一个好习惯，但图像名称可以是任意的：

docker build -t myimage 。

更好的方法是提供完全限定且有意义的存储库、名称和标签
（这里上下文中的标记表示“:”之后的限定符）。 在这个例子中我们
为 Fedora 存储库构建一个 JBoss 映像并为其提供版本 1.0：

docker build -t fedora/jboss:1.0 。

下一个示例针对“whenry”用户存储库，使用 Fedora 和 JBoss 并给出
它是 2.1 版：

docker build -t whenry/fedora-jboss:v2.1 。

如果您不提供版本标记，则 Docker 将分配 最新:

docker build -t whenry/fedora-jboss 。

当您列出图像时，上面的图像将带有标签 最新.

您可以将多个标签应用于图像。 例如，您可以应用 最新 标记为
新建镜像并添加另一个引用特定版本的标签。 例如，到
将图像标记为 whenry/fedora-jboss：最新 和 Whenry/fedora-jboss:v2.1，使用
在以下：

docker build -t whenry/fedora-jboss:latest -t whenry/fedora-jboss:v2.1 。

所以重命名图像是任意的，但应该考虑一个有用的约定
这对消费者有意义，也应该考虑到 Docker 社区
约定。

建筑物 an 图片 运用 a 网址

这将从 URL 克隆指定的 GitHub 存储库并将其用作上下文。 这
存储库根目录下的 Dockerfile 用作 Dockerfile。 这仅适用于
GitHub 存储库是一个专用存储库。

码头工人构建 github.com/scollier/purpletest

注意：您可以通过 转到：// 架构。

建筑物 an 图片 运用 a 网址 至 a 压缩包 上下文

这会将 URL 本身发送到 Docker 守护程序。 守护进程将获取 tarball
存档，解压缩并将其内容用作构建上下文。 Dockerfile 在
存档的根目录和存档的其余部分将用作构建的上下文。
如果你通过一个 -f 路径/Dockerfile 选项，系统将查找该文件
在 tarball 的内容中。

docker build -f dev/Dockerfile https://10.10.10.1/docker/context.tar.gz

注意：支持的压缩格式有“xz”、“bzip2”、“gzip”和“identity”（没有
压缩）。

指定 隔离 技术 容器 （ - 隔离）

此选项在您在 Windows 上运行 Docker 容器的情况下很有用。
特 --隔离= option 设置容器的隔离技术。 在 Linux 上，唯一的
支持的是 默认 使用 Linux 命名空间的选项。 在 Microsoft Windows 上，您可以
指定这些值：

· 默认: 使用 Docker 守护进程指定的值 --执行选项 。 如果 守护 不
未指定隔离技术，Microsoft Windows 使用 过程 作为其默认值
计算值。

· 过程: 仅命名空间隔离。

· 超频：Hyper-V 管理程序基于分区的隔离。

指定 - 隔离 没有值的标志与设置相同
--isolation="默认".

历史

2014 年 XNUMX 月，最初由 William Henry (whenry at redhat dot com) 编译，基于
docker.com 源材料和内部工作。 2014 年 XNUMX 月，由 Sven Dowideit 更新
⟨[电子邮件保护]⟩ 2015 年 XNUMX 月，由 Sally O'Malley 更新 ⟨[电子邮件保护]⟩

使用 onworks.net 服务在线使用 docker-build