|
@@ -17,8 +17,11 @@ docker-build - Build a new image from the source code at PATH
|
|
|
[**-m**|**--memory**[=*MEMORY*]]
|
|
|
[**--memory-swap**[=*MEMORY-SWAP*]]
|
|
|
[**-c**|**--cpu-shares**[=*0*]]
|
|
|
+[**--cpu-period**[=*0*]]
|
|
|
[**--cpu-quota**[=*0*]]
|
|
|
[**--cpuset-cpus**[=*CPUSET-CPUS*]]
|
|
|
+[**--cpuset-mems**[=*CPUSET-MEMS*]]
|
|
|
+[**--cgroup-parent**[=*CGROUP-PARENT*]]
|
|
|
|
|
|
PATH | URL | -
|
|
|
|
|
@@ -63,6 +66,77 @@ as context.
|
|
|
**-t**, **--tag**=""
|
|
|
Repository name (and optionally a tag) to be applied to the resulting image in case of success
|
|
|
|
|
|
+**-m**, **--memory**=*MEMORY*
|
|
|
+ Memory limit
|
|
|
+
|
|
|
+**--memory-swap**=*MEMORY-SWAP*
|
|
|
+ Total memory (memory + swap), '-1' to disable swap.
|
|
|
+
|
|
|
+**-c**, **--cpu-shares**=*0*
|
|
|
+ CPU shares (relative weight).
|
|
|
+
|
|
|
+ By default, all containers get the same proportion of CPU cycles. You can
|
|
|
+ change this proportion by adjusting the container's CPU share weighting
|
|
|
+ relative to the weighting of all other running containers.
|
|
|
+
|
|
|
+ To modify the proportion from the default of 1024, use the **-c** or
|
|
|
+ **--cpu-shares** flag to set the weighting to 2 or higher.
|
|
|
+
|
|
|
+ The proportion is only applied when CPU-intensive processes are running.
|
|
|
+ When tasks in one container are idle, the other containers can use the
|
|
|
+ left-over CPU time. The actual amount of CPU time used varies depending on
|
|
|
+ the number of containers running on the system.
|
|
|
+
|
|
|
+ For example, consider three containers, one has a cpu-share of 1024 and
|
|
|
+ two others have a cpu-share setting of 512. When processes in all three
|
|
|
+ containers attempt to use 100% of CPU, the first container would receive
|
|
|
+ 50% of the total CPU time. If you add a fourth container with a cpu-share
|
|
|
+ of 1024, the first container only gets 33% of the CPU. The remaining containers
|
|
|
+ receive 16.5%, 16.5% and 33% of the CPU.
|
|
|
+
|
|
|
+ On a multi-core system, the shares of CPU time are distributed across the CPU
|
|
|
+ cores. Even if a container is limited to less than 100% of CPU time, it can
|
|
|
+ use 100% of each individual CPU core.
|
|
|
+
|
|
|
+ For example, consider a system with more than three cores. If you start one
|
|
|
+ container **{C0}** with **-c=512** running one process, and another container
|
|
|
+ **{C1}** with **-c=1024** running two processes, this can result in the following
|
|
|
+ division of CPU shares:
|
|
|
+
|
|
|
+ PID container CPU CPU share
|
|
|
+ 100 {C0} 0 100% of CPU0
|
|
|
+ 101 {C1} 1 100% of CPU1
|
|
|
+ 102 {C1} 2 100% of CPU2
|
|
|
+
|
|
|
+**--cpu-period**=*0*
|
|
|
+ Limit the CPU CFS (Completely Fair Scheduler) period.
|
|
|
+
|
|
|
+ Limit the container's CPU usage. This flag causes the kernel to restrict the
|
|
|
+ container's CPU usage to the period you specify.
|
|
|
+
|
|
|
+**--cpu-quota**=*0*
|
|
|
+ Limit the CPU CFS (Completely Fair Scheduler) quota.
|
|
|
+
|
|
|
+ By default, containers run with the full CPU resource. This flag causes the
|
|
|
+kernel to restrict the container's CPU usage to the quota you specify.
|
|
|
+
|
|
|
+**--cpuset-cpus**=*CPUSET-CPUS*
|
|
|
+ CPUs in which to allow execution (0-3, 0,1).
|
|
|
+
|
|
|
+**--cpuset-mems**=*CPUSET-MEMS*
|
|
|
+ Memory nodes (MEMs) in which to allow execution (-1-3, 0,1). Only effective on
|
|
|
+ NUMA systems.
|
|
|
+
|
|
|
+ For example, if you have four memory nodes on your system (0-3), use `--cpuset-mems=0,1`
|
|
|
+to ensure the processes in your Docker container only use memory from the first
|
|
|
+two memory nodes.
|
|
|
+
|
|
|
+**--cgroup-parent**=*CGROUP-PARENT*
|
|
|
+ Path to `cgroups` under which the container's `cgroup` are created.
|
|
|
+
|
|
|
+ If the path is not absolute, the path is considered relative to the `cgroups` path of the init process.
|
|
|
+Cgroups are created if they do not already exist.
|
|
|
+
|
|
|
# EXAMPLES
|
|
|
|
|
|
## Building an image using a Dockerfile located inside the current directory
|