From 8af4f89cba09105f3d581926aca6e231326f7054 Mon Sep 17 00:00:00 2001 From: Kenfe-Mickael Laventure Date: Fri, 18 Mar 2016 12:43:17 -0700 Subject: [PATCH] Remove unneeded references to execDriver This includes: - updating the docs - removing dangling variables Signed-off-by: Kenfe-Mickael Laventure --- contrib/completion/fish/docker.fish | 2 +- contrib/completion/zsh/_docker | 4 +- daemon/config.go | 4 +- daemon/daemon_unix.go | 27 ++- daemon/graphdriver/devmapper/README.md | 23 +- daemon/kill.go | 2 +- daemon/volumes_windows.go | 4 +- docs/admin/configuring.md | 4 +- docs/reference/commandline/daemon.md | 24 ++- docs/security/security.md | 8 +- .../storagedriver/device-mapper-driver.md | 198 +++++++++--------- integration-cli/docker_test_vars.go | 3 +- man/docker-daemon.8.md | 12 +- man/docker-inspect.1.md | 3 +- man/docker.1.md | 7 +- 15 files changed, 164 insertions(+), 161 deletions(-) diff --git a/contrib/completion/fish/docker.fish b/contrib/completion/fish/docker.fish index 1e734c7d3a..72ccd05533 100644 --- a/contrib/completion/fish/docker.fish +++ b/contrib/completion/fish/docker.fish @@ -51,7 +51,7 @@ complete -c docker -f -n '__fish_docker_no_subcommand' -s d -l daemon -d 'Enable complete -c docker -f -n '__fish_docker_no_subcommand' -l dns -d 'Force Docker to use specific DNS servers' complete -c docker -f -n '__fish_docker_no_subcommand' -l dns-opt -d 'Force Docker to use specific DNS options' complete -c docker -f -n '__fish_docker_no_subcommand' -l dns-search -d 'Force Docker to use specific DNS search domains' -complete -c docker -f -n '__fish_docker_no_subcommand' -l exec-opt -d 'Set exec driver options' +complete -c docker -f -n '__fish_docker_no_subcommand' -l exec-opt -d 'Set runtime execution options' complete -c docker -f -n '__fish_docker_no_subcommand' -l fixed-cidr -d 'IPv4 subnet for fixed IPs (e.g. 10.20.0.0/16)' complete -c docker -f -n '__fish_docker_no_subcommand' -l fixed-cidr-v6 -d 'IPv6 subnet for fixed IPs (e.g.: 2001:a02b/48)' complete -c docker -f -n '__fish_docker_no_subcommand' -s G -l group -d 'Group to assign the unix socket specified by -H when running in daemon mode' diff --git a/contrib/completion/zsh/_docker b/contrib/completion/zsh/_docker index 0f2a361a6b..8811261f22 100644 --- a/contrib/completion/zsh/_docker +++ b/contrib/completion/zsh/_docker @@ -650,8 +650,8 @@ __docker_subcommand() { "($help)*--dns-opt=[DNS options to use]:DNS option: " \ "($help)*--default-ulimit=[Default ulimit settings for containers]:ulimit: " \ "($help)--disable-legacy-registry[Do not contact legacy registries]" \ - "($help)*--exec-opt=[Exec driver options]:exec driver options: " \ - "($help)--exec-root=[Root of the Docker execdriver]:path:_directories" \ + "($help)*--exec-opt=[Runtime execution options]:runtime execution options: " \ + "($help)--exec-root=[Root directory for execution state files]:path:_directories" \ "($help)--fixed-cidr=[IPv4 subnet for fixed IPs]:IPv4 subnet: " \ "($help)--fixed-cidr-v6=[IPv6 subnet for fixed IPs]:IPv6 subnet: " \ "($help -G --group)"{-G=,--group=}"[Group for the unix socket]:group:_groups" \ diff --git a/daemon/config.go b/daemon/config.go index a1a5f48c53..5e9d5e5105 100644 --- a/daemon/config.go +++ b/daemon/config.go @@ -112,10 +112,10 @@ func (config *Config) InstallCommonFlags(cmd *flag.FlagSet, usageFn func(string) cmd.Var(opts.NewNamedListOptsRef("storage-opts", &config.GraphOptions, nil), []string{"-storage-opt"}, usageFn("Set storage driver options")) cmd.Var(opts.NewNamedListOptsRef("authorization-plugins", &config.AuthorizationPlugins, nil), []string{"-authorization-plugin"}, usageFn("List authorization plugins in order from first evaluator to last")) - cmd.Var(opts.NewNamedListOptsRef("exec-opts", &config.ExecOptions, nil), []string{"-exec-opt"}, usageFn("Set exec driver options")) + cmd.Var(opts.NewNamedListOptsRef("exec-opts", &config.ExecOptions, nil), []string{"-exec-opt"}, usageFn("Set runtime execution options")) cmd.StringVar(&config.Pidfile, []string{"p", "-pidfile"}, defaultPidFile, usageFn("Path to use for daemon PID file")) cmd.StringVar(&config.Root, []string{"g", "-graph"}, defaultGraph, usageFn("Root of the Docker runtime")) - cmd.StringVar(&config.ExecRoot, []string{"-exec-root"}, defaultExecRoot, usageFn("Root of the Docker execdriver")) + cmd.StringVar(&config.ExecRoot, []string{"-exec-root"}, defaultExecRoot, usageFn("Root directory for execution state files")) cmd.BoolVar(&config.AutoRestart, []string{"#r", "#-restart"}, true, usageFn("--restart on the daemon has been deprecated in favor of --restart policies on docker run")) cmd.StringVar(&config.GraphDriver, []string{"s", "-storage-driver"}, "", usageFn("Storage driver to use")) cmd.IntVar(&config.Mtu, []string{"#mtu", "-mtu"}, 0, usageFn("Set the containers network MTU")) diff --git a/daemon/daemon_unix.go b/daemon/daemon_unix.go index b6e60ff77c..43af8340f0 100644 --- a/daemon/daemon_unix.go +++ b/daemon/daemon_unix.go @@ -51,6 +51,10 @@ const ( // constants for remapped root settings defaultIDSpecifier string = "default" defaultRemappedID string = "dockremap" + + // constant for cgroup drivers + cgroupFsDriver = "cgroupfs" + cgroupSystemdDriver = "systemd" ) func getMemoryResources(config containertypes.Resources) *specs.Memory { @@ -460,29 +464,30 @@ func verifyContainerResources(resources *containertypes.Resources, sysInfo *sysi } func (daemon *Daemon) getCgroupDriver() string { - cgroupDriver := "cgroupfs" - if daemon.usingSystemd() { - cgroupDriver = "systemd" - } - return cgroupDriver -} + cgroupDriver := cgroupFsDriver -func usingSystemd(config *Config) bool { - for _, option := range config.ExecOptions { + // No other cgroup drivers are supported at the moment. Warn the + // user if they tried to set one other than cgroupfs + for _, option := range daemon.configStore.ExecOptions { key, val, err := parsers.ParseKeyValueOpt(option) if err != nil || !strings.EqualFold(key, "native.cgroupdriver") { continue } - if val == "systemd" { - return true + if val != cgroupFsDriver { + logrus.Warnf("cgroupdriver '%s' is not supported", val) } } + return cgroupDriver +} + +func usingSystemd(config *Config) bool { + // No support for systemd cgroup atm return false } func (daemon *Daemon) usingSystemd() bool { - return usingSystemd(daemon.configStore) + return daemon.getCgroupDriver() == cgroupSystemdDriver } // verifyPlatformContainerSettings performs platform-specific validation of the diff --git a/daemon/graphdriver/devmapper/README.md b/daemon/graphdriver/devmapper/README.md index fa9a501cfd..8de7fc226c 100644 --- a/daemon/graphdriver/devmapper/README.md +++ b/daemon/graphdriver/devmapper/README.md @@ -9,21 +9,21 @@ daemon via the `--storage-opt dm.thinpooldev` option. As a fallback if no thin pool is provided, loopback files will be created. Loopback is very slow, but can be used without any -pre-configuration of storage. It is strongly recommended that you do +pre-configuration of storage. It is strongly recommended that you do not use loopback in production. Ensure your Docker daemon has a `--storage-opt dm.thinpooldev` argument provided. In loopback, a thin pool is created at `/var/lib/docker/devicemapper` -(devicemapper graph location) based on two block devices, one for -data and one for metadata. By default these block devices are created -automatically by using loopback mounts of automatically created sparse +(devicemapper graph location) based on two block devices, one for +data and one for metadata. By default these block devices are created +automatically by using loopback mounts of automatically created sparse files. -The default loopback files used are -`/var/lib/docker/devicemapper/devicemapper/data` and -`/var/lib/docker/devicemapper/devicemapper/metadata`. Additional metadata -required to map from docker entities to the corresponding devicemapper -volumes is stored in the `/var/lib/docker/devicemapper/devicemapper/json` +The default loopback files used are +`/var/lib/docker/devicemapper/devicemapper/data` and +`/var/lib/docker/devicemapper/devicemapper/metadata`. Additional metadata +required to map from docker entities to the corresponding devicemapper +volumes is stored in the `/var/lib/docker/devicemapper/devicemapper/json` file (encoded as Json). In order to support multiple devicemapper graphs on a system, the thin @@ -92,6 +92,5 @@ This uses the `dm` prefix and would be used something like `docker daemon --stor These options are currently documented both in [the man page](../../../man/docker.1.md) and in [the online -documentation](https://docs.docker.com/reference/commandline/daemon/#docker- -execdriver-option). If you add an options, update both the `man` page and the -documentation. +documentation](https://docs.docker.com/reference/commandline/daemon/#storage-driver-options). +If you add an options, update both the `man` page and the documentation. diff --git a/daemon/kill.go b/daemon/kill.go index 69a9c5e67b..e6ccfc7955 100644 --- a/daemon/kill.go +++ b/daemon/kill.go @@ -103,7 +103,7 @@ func (daemon *Daemon) Kill(container *container.Container) error { // because if we can't stop the container by this point then // its probably because its already stopped. Meaning, between // the time of the IsRunning() call above and now it stopped. - // Also, since the err return will be exec driver specific we can't + // Also, since the err return will be environment specific we can't // look for any particular (common) error that would indicate // that the process is already dead vs something else going wrong. // So, instead we'll give it up to 2 more seconds to complete and if diff --git a/daemon/volumes_windows.go b/daemon/volumes_windows.go index b0ab4d6dd5..e7f9c098d9 100644 --- a/daemon/volumes_windows.go +++ b/daemon/volumes_windows.go @@ -11,8 +11,8 @@ import ( ) // setupMounts configures the mount points for a container by appending each -// of the configured mounts on the container to the oci mount structure -// which will ultimately be passed into the exec driver during container creation. +// of the configured mounts on the container to the OCI mount structure +// which will ultimately be passed into the oci runtime during container creation. // It also ensures each of the mounts are lexographically sorted. // BUGBUG TODO Windows containerd. This would be much better if it returned diff --git a/docs/admin/configuring.md b/docs/admin/configuring.md index 09ed39dd3b..e7556ab729 100644 --- a/docs/admin/configuring.md +++ b/docs/admin/configuring.md @@ -162,7 +162,7 @@ can be located at `/var/log/upstart/docker.log` $ tail -f /var/log/upstart/docker.log INFO[0000] Loading containers: done. - INFO[0000] docker daemon: 1.6.0 4749651; execdriver: native-0.2; graphdriver: aufs + INFO[0000] Docker daemon commit=1b09a95-unsupported graphdriver=aufs version=1.11.0-dev INFO[0000] +job acceptconnections() INFO[0000] -job acceptconnections() = OK (0) INFO[0000] Daemon has completed initialization @@ -273,7 +273,7 @@ be viewed using `journalctl -u docker` May 06 00:22:06 localhost.localdomain docker[2495]: time="2015-05-06T00:22:06Z" level="info" msg="-job init_networkdriver() = OK (0)" May 06 00:22:06 localhost.localdomain docker[2495]: time="2015-05-06T00:22:06Z" level="info" msg="Loading containers: start." May 06 00:22:06 localhost.localdomain docker[2495]: time="2015-05-06T00:22:06Z" level="info" msg="Loading containers: done." - May 06 00:22:06 localhost.localdomain docker[2495]: time="2015-05-06T00:22:06Z" level="info" msg="docker daemon: 1.5.0-dev fc0329b/1.5.0; execdriver: native-0.2; graphdriver: devicemapper" + May 06 00:22:06 localhost.localdomain docker[2495]: time="2015-05-06T00:22:06Z" level="info" msg="Docker daemon commit=1b09a95-unsupported graphdriver=aufs version=1.11.0-dev" May 06 00:22:06 localhost.localdomain docker[2495]: time="2015-05-06T00:22:06Z" level="info" msg="+job acceptconnections()" May 06 00:22:06 localhost.localdomain docker[2495]: time="2015-05-06T00:22:06Z" level="info" msg="-job acceptconnections() = OK (0)" diff --git a/docs/reference/commandline/daemon.md b/docs/reference/commandline/daemon.md index 20ea3cb20e..e292f1171e 100644 --- a/docs/reference/commandline/daemon.md +++ b/docs/reference/commandline/daemon.md @@ -32,8 +32,8 @@ weight = -1 --dns-opt=[] DNS options to use --dns-search=[] DNS search domains to use --default-ulimit=[] Set default ulimit settings for containers - --exec-opt=[] Set exec driver options - --exec-root="/var/run/docker" Root of the Docker execdriver + --exec-opt=[] Set runtime execution options + --exec-root="/var/run/docker" Root directory for execution state files --fixed-cidr="" IPv4 subnet for fixed IPs --fixed-cidr-v6="" IPv6 subnet for fixed IPs -G, --group="docker" Group for the unix socket @@ -476,24 +476,26 @@ Currently supported options of `zfs`: $ docker daemon -s zfs --storage-opt zfs.fsname=zroot/docker -## Docker execdriver option +## Docker runtime execution options -The Docker daemon uses a specifically built `libcontainer` execution driver as -its interface to the Linux kernel `namespaces`, `cgroups`, and `SELinux`. +The Docker daemon relies on a +[OCI](https://github.com/opencontainers/specs) compliant runtime +(invoked via the `containerd` daemon) as its interface to the Linux +kernel `namespaces`, `cgroups`, and `SELinux`. -## Options for the native execdriver +## Options for the runtime -You can configure the `native` (libcontainer) execdriver using options specified +You can configure the runtime using options specified with the `--exec-opt` flag. All the flag's options have the `native` prefix. A single `native.cgroupdriver` option is available. The `native.cgroupdriver` option specifies the management of the container's -cgroups. You can specify `cgroupfs` or `systemd`. If you specify `systemd` and -it is not available, the system uses `cgroupfs`. If you omit the +cgroups. You can specify only specify `cgroupfs` at the moment. If you omit the `native.cgroupdriver` option,` cgroupfs` is used. -This example sets the `cgroupdriver` to `systemd`: - $ sudo docker daemon --exec-opt native.cgroupdriver=systemd +This example explicitely sets the `cgroupdriver` to `cgroupfs`: + + $ sudo docker daemon --exec-opt native.cgroupdriver=cgroupfs Setting this option applies to all containers the daemon launches. diff --git a/docs/security/security.md b/docs/security/security.md index 9eea663788..b9738a3ce8 100644 --- a/docs/security/security.md +++ b/docs/security/security.md @@ -198,7 +198,7 @@ to the host. This won't affect regular web apps; but malicious users will find that the arsenal at their disposal has shrunk considerably! By default Docker drops all capabilities except [those -needed](https://github.com/docker/docker/blob/87de5fdd5972343a11847922e0f41d9898b5cff7/daemon/execdriver/native/template/default_template_linux.go#L16-L29), +needed](https://github.com/docker/docker/blob/master/oci/defaults_linux.go#L64-L79), a whitelist instead of a blacklist approach. You can see a full list of available capabilities in [Linux manpages](http://man7.org/linux/man-pages/man7/capabilities.7.html). @@ -243,11 +243,11 @@ with e.g., special network topologies or shared filesystems, you can expect to see tools to harden existing Docker containers without affecting Docker's core. -As of Docker 1.10 User Namespaces are supported directly by the docker -daemon. This feature allows for the root user in a container to be mapped +As of Docker 1.10 User Namespaces are supported directly by the docker +daemon. This feature allows for the root user in a container to be mapped to a non uid-0 user outside the container, which can help to mitigate the risks of container breakout. This facility is available but not enabled -by default. +by default. Refer to the [daemon command](../reference/commandline/daemon.md#daemon-user-namespace-options) in the command line reference for more information on this feature. diff --git a/docs/userguide/storagedriver/device-mapper-driver.md b/docs/userguide/storagedriver/device-mapper-driver.md index cf2d34731a..dc5143f12f 100644 --- a/docs/userguide/storagedriver/device-mapper-driver.md +++ b/docs/userguide/storagedriver/device-mapper-driver.md @@ -51,46 +51,46 @@ Device Mapper technology works at the block level rather than the file level. This means that `devicemapper` storage driver's thin provisioning and copy-on-write operations work with blocks rather than entire files. ->**Note**: Snapshots are also referred to as *thin devices* or *virtual ->devices*. They all mean the same thing in the context of the `devicemapper` +>**Note**: Snapshots are also referred to as *thin devices* or *virtual +>devices*. They all mean the same thing in the context of the `devicemapper` >storage driver. With `devicemapper` the high level process for creating images is as follows: 1. The `devicemapper` storage driver creates a thin pool. - The pool is created from block devices or loop mounted sparse files (more + The pool is created from block devices or loop mounted sparse files (more on this later). 2. Next it creates a *base device*. - A base device is a thin device with a filesystem. You can see which -filesystem is in use by running the `docker info` command and checking the + A base device is a thin device with a filesystem. You can see which +filesystem is in use by running the `docker info` command and checking the `Backing filesystem` value. 3. Each new image (and image layer) is a snapshot of this base device. - These are thin provisioned copy-on-write snapshots. This means that they -are initially empty and only consume space from the pool when data is written + These are thin provisioned copy-on-write snapshots. This means that they +are initially empty and only consume space from the pool when data is written to them. -With `devicemapper`, container layers are snapshots of the image they are -created from. Just as with images, container snapshots are thin provisioned -copy-on-write snapshots. The container snapshot stores all updates to the -container. The `devicemapper` allocates space to them on-demand from the pool +With `devicemapper`, container layers are snapshots of the image they are +created from. Just as with images, container snapshots are thin provisioned +copy-on-write snapshots. The container snapshot stores all updates to the +container. The `devicemapper` allocates space to them on-demand from the pool as and when data is written to the container. -The high level diagram below shows a thin pool with a base device and two +The high level diagram below shows a thin pool with a base device and two images. ![](images/base_device.jpg) -If you look closely at the diagram you'll see that it's snapshots all the way +If you look closely at the diagram you'll see that it's snapshots all the way down. Each image layer is a snapshot of the layer below it. The lowest layer of - each image is a snapshot of the base device that exists in the pool. This + each image is a snapshot of the base device that exists in the pool. This base device is a `Device Mapper` artifact and not a Docker image layer. -A container is a snapshot of the image it is created from. The diagram below +A container is a snapshot of the image it is created from. The diagram below shows two containers - one based on the Ubuntu image and the other based on the Busybox image. @@ -99,22 +99,22 @@ shows two containers - one based on the Ubuntu image and the other based on the ## Reads with the devicemapper -Let's look at how reads and writes occur using the `devicemapper` storage -driver. The diagram below shows the high level process for reading a single +Let's look at how reads and writes occur using the `devicemapper` storage +driver. The diagram below shows the high level process for reading a single block (`0x44f`) in an example container. ![](images/dm_container.jpg) 1. An application makes a read request for block `0x44f` in the container. - Because the container is a thin snapshot of an image it does not have the -data. Instead, it has a pointer (PTR) to where the data is stored in the image + Because the container is a thin snapshot of an image it does not have the +data. Instead, it has a pointer (PTR) to where the data is stored in the image snapshot lower down in the image stack. -2. The storage driver follows the pointer to block `0xf33` in the snapshot +2. The storage driver follows the pointer to block `0xf33` in the snapshot relating to image layer `a005...`. -3. The `devicemapper` copies the contents of block `0xf33` from the image +3. The `devicemapper` copies the contents of block `0xf33` from the image snapshot to memory in the container. 4. The storage driver returns the data to the requesting application. @@ -122,11 +122,11 @@ snapshot to memory in the container. ### Write examples With the `devicemapper` driver, writing new data to a container is accomplished - by an *allocate-on-demand* operation. Updating existing data uses a -copy-on-write operation. Because Device Mapper is a block-based technology + by an *allocate-on-demand* operation. Updating existing data uses a +copy-on-write operation. Because Device Mapper is a block-based technology these operations occur at the block level. -For example, when making a small change to a large file in a container, the +For example, when making a small change to a large file in a container, the `devicemapper` storage driver does not copy the entire file. It only copies the blocks to be modified. Each block is 64KB. @@ -136,10 +136,10 @@ To write 56KB of new data to a container: 1. An application makes a request to write 56KB of new data to the container. -2. The allocate-on-demand operation allocates a single new 64KB block to the +2. The allocate-on-demand operation allocates a single new 64KB block to the container's snapshot. - If the write operation is larger than 64KB, multiple new blocks are + If the write operation is larger than 64KB, multiple new blocks are allocated to the container's snapshot. 3. The data is written to the newly allocated block. @@ -152,7 +152,7 @@ To modify existing data for the first time: 2. A copy-on-write operation locates the blocks that need updating. -3. The operation allocates new empty blocks to the container snapshot and +3. The operation allocates new empty blocks to the container snapshot and copies the data into those blocks. 4. The modified data is written into the newly allocated blocks. @@ -164,18 +164,18 @@ to the application's read and write operations. ## Configuring Docker with Device Mapper The `devicemapper` is the default Docker storage driver on some Linux -distributions. This includes RHEL and most of its forks. Currently, the +distributions. This includes RHEL and most of its forks. Currently, the following distributions support the driver: * RHEL/CentOS/Fedora -* Ubuntu 12.04 -* Ubuntu 14.04 -* Debian +* Ubuntu 12.04 +* Ubuntu 14.04 +* Debian Docker hosts running the `devicemapper` storage driver default to a configuration mode known as `loop-lvm`. This mode uses sparse files to build -the thin pool used by image and container snapshots. The mode is designed to -work out-of-the-box with no additional configuration. However, production +the thin pool used by image and container snapshots. The mode is designed to +work out-of-the-box with no additional configuration. However, production deployments should not run under `loop-lvm` mode. You can detect the mode by viewing the `docker info` command: @@ -193,83 +193,83 @@ You can detect the mode by viewing the `docker info` command: Library Version: 1.02.93-RHEL7 (2015-01-28) ... -The output above shows a Docker host running with the `devicemapper` storage -driver operating in `loop-lvm` mode. This is indicated by the fact that the -`Data loop file` and a `Metadata loop file` are on files under -`/var/lib/docker/devicemapper/devicemapper`. These are loopback mounted sparse +The output above shows a Docker host running with the `devicemapper` storage +driver operating in `loop-lvm` mode. This is indicated by the fact that the +`Data loop file` and a `Metadata loop file` are on files under +`/var/lib/docker/devicemapper/devicemapper`. These are loopback mounted sparse files. ### Configure direct-lvm mode for production The preferred configuration for production deployments is `direct lvm`. This mode uses block devices to create the thin pool. The following procedure shows -you how to configure a Docker host to use the `devicemapper` storage driver in +you how to configure a Docker host to use the `devicemapper` storage driver in a `direct-lvm` configuration. -> **Caution:** If you have already run the Docker daemon on your Docker host -> and have images you want to keep, `push` them Docker Hub or your private +> **Caution:** If you have already run the Docker daemon on your Docker host +> and have images you want to keep, `push` them Docker Hub or your private > Docker Trusted Registry before attempting this procedure. -The procedure below will create a 90GB data volume and 4GB metadata volume to -use as backing for the storage pool. It assumes that you have a spare block -device at `/dev/xvdf` with enough free space to complete the task. The device -identifier and volume sizes may be be different in your environment and you -should substitute your own values throughout the procedure. The procedure also +The procedure below will create a 90GB data volume and 4GB metadata volume to +use as backing for the storage pool. It assumes that you have a spare block +device at `/dev/xvdf` with enough free space to complete the task. The device +identifier and volume sizes may be be different in your environment and you +should substitute your own values throughout the procedure. The procedure also assumes that the Docker daemon is in the `stopped` state. 1. Log in to the Docker host you want to configure and stop the Docker daemon. -2. If it exists, delete your existing image store by removing the +2. If it exists, delete your existing image store by removing the `/var/lib/docker` directory. $ sudo rm -rf /var/lib/docker -3. Create an LVM physical volume (PV) on your spare block device using the +3. Create an LVM physical volume (PV) on your spare block device using the `pvcreate` command. $ sudo pvcreate /dev/xvdf Physical volume `/dev/xvdf` successfully created - The device identifier may be different on your system. Remember to + The device identifier may be different on your system. Remember to substitute your value in the command above. -4. Create a new volume group (VG) called `vg-docker` using the PV created in +4. Create a new volume group (VG) called `vg-docker` using the PV created in the previous step. $ sudo vgcreate vg-docker /dev/xvdf Volume group `vg-docker` successfully created -5. Create a new 90GB logical volume (LV) called `data` from space in the +5. Create a new 90GB logical volume (LV) called `data` from space in the `vg-docker` volume group. $ sudo lvcreate -L 90G -n data vg-docker Logical volume `data` created. - The command creates an LVM logical volume called `data` and an associated -block device file at `/dev/vg-docker/data`. In a later step, you instruct the -`devicemapper` storage driver to use this block device to store image and + The command creates an LVM logical volume called `data` and an associated +block device file at `/dev/vg-docker/data`. In a later step, you instruct the +`devicemapper` storage driver to use this block device to store image and container data. - If you receive a signature detection warning, make sure you are working on -the correct devices before continuing. Signature warnings indicate that the -device you're working on is currently in use by LVM or has been used by LVM in + If you receive a signature detection warning, make sure you are working on +the correct devices before continuing. Signature warnings indicate that the +device you're working on is currently in use by LVM or has been used by LVM in the past. -6. Create a new logical volume (LV) called `metadata` from space in the +6. Create a new logical volume (LV) called `metadata` from space in the `vg-docker` volume group. $ sudo lvcreate -L 4G -n metadata vg-docker Logical volume `metadata` created. - This creates an LVM logical volume called `metadata` and an associated -block device file at `/dev/vg-docker/metadata`. In the next step you instruct -the `devicemapper` storage driver to use this block device to store image and + This creates an LVM logical volume called `metadata` and an associated +block device file at `/dev/vg-docker/metadata`. In the next step you instruct +the `devicemapper` storage driver to use this block device to store image and container metadata. -7. Start the Docker daemon with the `devicemapper` storage driver and the +7. Start the Docker daemon with the `devicemapper` storage driver and the `--storage-opt` flags. - The `data` and `metadata` devices that you pass to the `--storage-opt` + The `data` and `metadata` devices that you pass to the `--storage-opt` options were created in the previous steps. $ sudo docker daemon --storage-driver=devicemapper --storage-opt dm.datadev=/dev/vg-docker/data --storage-opt dm.metadatadev=/dev/vg-docker/metadata & @@ -279,13 +279,13 @@ options were created in the previous steps. INFO[0027] Option DefaultNetwork: bridge INFO[0027] Daemon has completed initialization - INFO[0027] Docker daemon commit=0a8c2e3 execdriver=native-0.2 graphdriver=devicemapper version=1.8.2 + INFO[0027] Docker daemon commit=1b09a95-unsupported graphdriver=aufs version=1.11.0-dev It is also possible to set the `--storage-driver` and `--storage-opt` flags in the Docker config file and start the daemon normally using the `service` or `systemd` commands. -8. Use the `docker info` command to verify that the daemon is using `data` and +8. Use the `docker info` command to verify that the daemon is using `data` and `metadata` devices you created. $ sudo docker info @@ -301,12 +301,12 @@ options were created in the previous steps. [...] The output of the command above shows the storage driver as `devicemapper`. - The last two lines also confirm that the correct devices are being used for + The last two lines also confirm that the correct devices are being used for the `Data file` and the `Metadata file`. ### Examine devicemapper structures on the host -You can use the `lsblk` command to see the device files created above and the +You can use the `lsblk` command to see the device files created above and the `pool` that the `devicemapper` storage driver creates on top of them. $ sudo lsblk @@ -319,7 +319,7 @@ You can use the `lsblk` command to see the device files created above and the └─vg--docker-metadata 253:1 0 4G 0 lvm └─docker-202:1-1032-pool 253:2 0 10G 0 dm -The diagram below shows the image from prior examples updated with the detail +The diagram below shows the image from prior examples updated with the detail from the `lsblk` command above. ![](http://farm1.staticflickr.com/703/22116692899_0471e5e160_b.jpg) @@ -335,73 +335,73 @@ Docker-MAJ:MIN-INO-pool `MAJ`, `MIN` and `INO` refer to the major and minor device numbers and inode. Because Device Mapper operates at the block level it is more difficult to see -diffs between image layers and containers. Docker 1.10 and later no longer -matches image layer IDs with directory names in `/var/lib/docker`. However, +diffs between image layers and containers. Docker 1.10 and later no longer +matches image layer IDs with directory names in `/var/lib/docker`. However, there are two key directories. The `/var/lib/docker/devicemapper/mnt` directory - contains the mount points for image and container layers. The -`/var/lib/docker/devicemapper/metadata`directory contains one file for every -image layer and container snapshot. The files contain metadata about each + contains the mount points for image and container layers. The +`/var/lib/docker/devicemapper/metadata`directory contains one file for every +image layer and container snapshot. The files contain metadata about each snapshot in JSON format. ## Device Mapper and Docker performance -It is important to understand the impact that allocate-on-demand and +It is important to understand the impact that allocate-on-demand and copy-on-write operations can have on overall container performance. ### Allocate-on-demand performance impact -The `devicemapper` storage driver allocates new blocks to a container via an -allocate-on-demand operation. This means that each time an app writes to -somewhere new inside a container, one or more empty blocks has to be located +The `devicemapper` storage driver allocates new blocks to a container via an +allocate-on-demand operation. This means that each time an app writes to +somewhere new inside a container, one or more empty blocks has to be located from the pool and mapped into the container. All blocks are 64KB. A write that uses less than 64KB still results in a single - 64KB block being allocated. Writing more than 64KB of data uses multiple 64KB -blocks. This can impact container performance, especially in containers that + 64KB block being allocated. Writing more than 64KB of data uses multiple 64KB +blocks. This can impact container performance, especially in containers that perform lots of small writes. However, once a block is allocated to a container subsequent reads and writes can operate directly on that block. ### Copy-on-write performance impact -Each time a container updates existing data for the first time, the -`devicemapper` storage driver has to perform a copy-on-write operation. This -copies the data from the image snapshot to the container's snapshot. This +Each time a container updates existing data for the first time, the +`devicemapper` storage driver has to perform a copy-on-write operation. This +copies the data from the image snapshot to the container's snapshot. This process can have a noticeable impact on container performance. -All copy-on-write operations have a 64KB granularity. As a results, updating -32KB of a 1GB file causes the driver to copy a single 64KB block into the -container's snapshot. This has obvious performance advantages over file-level -copy-on-write operations which would require copying the entire 1GB file into +All copy-on-write operations have a 64KB granularity. As a results, updating +32KB of a 1GB file causes the driver to copy a single 64KB block into the +container's snapshot. This has obvious performance advantages over file-level +copy-on-write operations which would require copying the entire 1GB file into the container layer. -In practice, however, containers that perform lots of small block writes +In practice, however, containers that perform lots of small block writes (<64KB) can perform worse with `devicemapper` than with AUFS. ### Other device mapper performance considerations -There are several other things that impact the performance of the +There are several other things that impact the performance of the `devicemapper` storage driver. -- **The mode.** The default mode for Docker running the `devicemapper` storage -driver is `loop-lvm`. This mode uses sparse files and suffers from poor +- **The mode.** The default mode for Docker running the `devicemapper` storage +driver is `loop-lvm`. This mode uses sparse files and suffers from poor performance. It is **not recommended for production**. The recommended mode for - production environments is `direct-lvm` where the storage driver writes + production environments is `direct-lvm` where the storage driver writes directly to raw block devices. - **High speed storage.** For best performance you should place the `Data file` - and `Metadata file` on high speed storage such as SSD. This can be direct + and `Metadata file` on high speed storage such as SSD. This can be direct attached storage or from a SAN or NAS array. -- **Memory usage.** `devicemapper` is not the most memory efficient Docker -storage driver. Launching *n* copies of the same container loads *n* copies of -its files into memory. This can have a memory impact on your Docker host. As a -result, the `devicemapper` storage driver may not be the best choice for PaaS +- **Memory usage.** `devicemapper` is not the most memory efficient Docker +storage driver. Launching *n* copies of the same container loads *n* copies of +its files into memory. This can have a memory impact on your Docker host. As a +result, the `devicemapper` storage driver may not be the best choice for PaaS and other high density use cases. -One final point, data volumes provide the best and most predictable -performance. This is because they bypass the storage driver and do not incur -any of the potential overheads introduced by thin provisioning and -copy-on-write. For this reason, you should to place heavy write workloads on +One final point, data volumes provide the best and most predictable +performance. This is because they bypass the storage driver and do not incur +any of the potential overheads introduced by thin provisioning and +copy-on-write. For this reason, you should to place heavy write workloads on data volumes. ## Related Information diff --git a/integration-cli/docker_test_vars.go b/integration-cli/docker_test_vars.go index 6bd02e059d..93518dcfb3 100644 --- a/integration-cli/docker_test_vars.go +++ b/integration-cli/docker_test_vars.go @@ -21,8 +21,7 @@ var ( // TODO Windows CI. These are incorrect and need fixing into // platform specific pieces. - runtimePath = "/var/run/docker" - execDriverPath = runtimePath + "/execdriver/native" + runtimePath = "/var/run/docker" workingDirectory string diff --git a/man/docker-daemon.8.md b/man/docker-daemon.8.md index 06bcf6438a..e313cd7e76 100644 --- a/man/docker-daemon.8.md +++ b/man/docker-daemon.8.md @@ -126,10 +126,10 @@ format. DNS search domains to use. **--exec-opt**=[] - Set exec driver options. See EXEC DRIVER OPTIONS. + Set runtime execution options. See RUNTIME EXECUTION OPTIONS. **--exec-root**="" - Path to use as the root of the Docker exec driver. Default is `/var/run/docker`. + Path to use as the root of the Docker execution state files. Default is `/var/run/docker`. **--fixed-cidr**="" IPv4 subnet for fixed IPs (e.g., 10.20.0.0/16); this subnet must be nested in the bridge subnet (which is defined by \-b or \-\-bip) @@ -289,13 +289,13 @@ will use more space for base images the larger the device is. The base device size can be increased at daemon restart which will allow -all future images and containers (based on those new images) to be of the +all future images and containers (based on those new images) to be of the new base device size. -Example use: `docker daemon --storage-opt dm.basesize=50G` +Example use: `docker daemon --storage-opt dm.basesize=50G` -This will increase the base device size to 50G. The Docker daemon will throw an -error if existing base device size is larger than 50G. A user can use +This will increase the base device size to 50G. The Docker daemon will throw an +error if existing base device size is larger than 50G. A user can use this option to expand the base device size however shrinking is not permitted. This value affects the system-wide "base" empty filesystem that may already diff --git a/man/docker-inspect.1.md b/man/docker-inspect.1.md index 6bb6a5809d..1bc2cf0b9c 100644 --- a/man/docker-inspect.1.md +++ b/man/docker-inspect.1.md @@ -16,7 +16,7 @@ CONTAINER|IMAGE [CONTAINER|IMAGE...] This displays all the information available in Docker for a given container or image. By default, this will render all results in a JSON -array. If the container and image have the same name, this will return +array. If the container and image have the same name, this will return container JSON for unspecified type. If a format is specified, the given template will be executed for each result. @@ -110,7 +110,6 @@ To get information on a container use its ID or instance name: "Name": "/adoring_wozniak", "RestartCount": 0, "Driver": "devicemapper", - "ExecDriver": "native-0.2", "MountLabel": "", "ProcessLabel": "", "Mounts": [ diff --git a/man/docker.1.md b/man/docker.1.md index f59f98abdf..c34d9c8d9a 100644 --- a/man/docker.1.md +++ b/man/docker.1.md @@ -224,15 +224,14 @@ inside it) See **docker-wait(1)** for full documentation on the **wait** command. -# EXEC DRIVER OPTIONS +# RUNTIME EXECUTION OPTIONS Use the **--exec-opt** flags to specify options to the execution driver. The following options are available: #### native.cgroupdriver -Specifies the management of the container's `cgroups`. You can specify -`cgroupfs` or `systemd`. If you specify `systemd` and it is not available, the -system uses `cgroupfs`. +Specifies the management of the container's `cgroups`. Only `cgroupfs` can be specified +`cgroupfs` at the moment. #### Client For specific client examples please see the man page for the specific Docker