1berry/docker-cli
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Creating Engine specific menu

Browse Source 
Fixing the links
Updating with Seb's comments
Adding weight
Fixing the engine aliases
Updating after Arun pushed
Removing empty file

Signed-off-by: Mary Anthony <mary@docker.com>
This commit is contained in:
Mary Anthony 2016-01-23 20:36:40 -08:00 committed by Tibor Vass
parent 0441148c7d
commit 7910f01804
14 changed files with 228 additions and 58 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

150
docs/deprecated.md Normal file
View File

@ -0,0 +1,150 @@
<!--[metadata]>
+++
aliases = ["/engine/misc/deprecated/"]
title = "Deprecated Engine Features"
description = "Deprecated Features."
keywords = ["docker, documentation, about, technology, deprecate"]
[menu.main]
parent = "engine_use"
weight=80
+++
<![end-metadata]-->
# Deprecated Engine Features
The following list of features are deprecated in Engine.
### Ambiguous event fields in API
**Deprecated In Release: v1.10**
The fields `ID`, `Status` and `From` in the events API have been deprecated in favor of a more rich structure.
See the events API documentation for the new format.
### `-f` flag on `docker tag`
**Deprecated In Release: v1.10**
**Target For Removal In Release: v1.12**
To make tagging consistent across the various `docker` commands, the `-f` flag on the `docker tag` command is deprecated. It is not longer necessary to specify `-f` to move a tag from one image to another. Nor will `docker` generate an error if the `-f` flag is missing and the specified tag is already in use.
### HostConfig at API container start
**Deprecated In Release: v1.10**
**Target For Removal In Release: v1.12**
Passing an `HostConfig` to `POST /containers/{name}/start` is deprecated in favor of
defining it at container creation (`POST /containers/create`).
### Docker ps 'before' and 'since' options
**Deprecated In Release: [v1.10.0](https://github.com/docker/docker/releases/tag/v1.10.0)**
**Target For Removal In Release: v1.12**
The `docker ps --before` and `docker ps --since` options are deprecated.
Use `docker ps --filter=before=...` and `docker ps --filter=since=...` instead.
### Command line short variant options
**Deprecated In Release: v1.9**
**Target For Removal In Release: v1.11**
The following short variant options are deprecated in favor of their long
variants:
docker run -c (--cpu-shares)
docker build -c (--cpu-shares)
docker create -c (--cpu-shares)
### Driver Specific Log Tags
**Deprecated In Release: v1.9**
**Target For Removal In Release: v1.11**
Log tags are now generated in a standard way across different logging drivers.
Because of which, the driver specific log tag options `syslog-tag`, `gelf-tag` and
`fluentd-tag` have been deprecated in favor of the generic `tag` option.
docker --log-driver=syslog --log-opt tag="{{.ImageName}}/{{.Name}}/{{.ID}}"
### LXC built-in exec driver
**Deprecated In Release: v1.8**
**Target For Removal In Release: v1.10**
The built-in LXC execution driver is deprecated for an external implementation.
The lxc-conf flag and API fields will also be removed.
### Old Command Line Options
**Deprecated In Release: [v1.8.0](https://github.com/docker/docker/releases/tag/v1.8.0)**
**Target For Removal In Release: v1.10**
The flags `-d` and `--daemon` are deprecated in favor of the `daemon` subcommand:
docker daemon -H ...
The following single-dash (`-opt`) variant of certain command line options
are deprecated and replaced with double-dash options (`--opt`):
docker attach -nostdin
docker attach -sig-proxy
docker build -no-cache
docker build -rm
docker commit -author
docker commit -run
docker events -since
docker history -notrunc
docker images -notrunc
docker inspect -format
docker ps -beforeId
docker ps -notrunc
docker ps -sinceId
docker rm -link
docker run -cidfile
docker run -dns
docker run -entrypoint
docker run -expose
docker run -link
docker run -lxc-conf
docker run -n
docker run -privileged
docker run -volumes-from
docker search -notrunc
docker search -stars
docker search -t
docker search -trusted
docker tag -force
The following double-dash options are deprecated and have no replacement:
docker run --cpuset
docker run --networking
docker ps --since-id
docker ps --before-id
docker search --trusted
### Auto-creating missing host paths for bind mounts
**Deprecated in Release: v1.9**
**Target for Removal in Release: 1.11**
When creating a container with a bind-mounted volume-- `docker run -v /host/path:/container/path` --
docker was automatically creating the `/host/path` if it didn't already exist.
This auto-creation of the host path is deprecated and docker will error out if
the path does not exist.
### Interacting with V1 registries
Version 1.9 adds a flag (`--disable-legacy-registry=false`) which prevents the docker daemon from `pull`, `push`, and `login` operations against v1 registries. Though disabled by default, this signals the intent to deprecate the v1 protocol.
### Docker Content Trust ENV passphrase variables name change
**Deprecated In Release: v1.9**
**Target For Removal In Release: v1.10**
As of 1.9, Docker Content Trust Offline key will be renamed to Root key and the Tagging key will be renamed to Repository key. Due to this renaming, we're also changing the corresponding environment variables
- DOCKER_CONTENT_TRUST_OFFLINE_PASSPHRASE will now be named DOCKER_CONTENT_TRUST_ROOT_PASSPHRASE
- DOCKER_CONTENT_TRUST_TAGGING_PASSPHRASE will now be named DOCKER_CONTENT_TRUST_REPOSITORY_PASSPHRASE

12
docs/extend/authorization.md
View File

@ -4,7 +4,7 @@ title = "Access authorization plugin"
description = "How to create authorization plugins to manage access control to your Docker daemon." description = "How to create authorization plugins to manage access control to your Docker daemon."
keywords = ["security, authorization, authentication, docker, documentation, plugin, extend"] keywords = ["security, authorization, authentication, docker, documentation, plugin, extend"]
[menu.main] [menu.main]
parent = "mn_extend" parent = "engine_extend"
weight = -1 weight = -1
+++ +++
<![end-metadata]--> <![end-metadata]-->
@ -41,8 +41,8 @@ on both the current authentication context and the command context. The
authentication context contains all user details and the authentication method. authentication context contains all user details and the authentication method.
The command context contains all the relevant request data. The command context contains all the relevant request data.
Authorization plugins must follow the rules described in [Docker Plugin API](plugin_api.md). Authorization plugins must follow the rules described in [Docker Plugin API](plugin_api.md).
Each plugin must reside within directories described under the Each plugin must reside within directories described under the
[Plugin discovery](plugin_api.md#plugin-discovery) section. [Plugin discovery](plugin_api.md#plugin-discovery) section.
**Note**: the abbreviations `AuthZ` and `AuthN` mean authorization and authentication **Note**: the abbreviations `AuthZ` and `AuthN` mean authorization and authentication
@ -90,7 +90,7 @@ configure proper authentication and security policies.
## Docker client flows ## Docker client flows
To enable and configure the authorization plugin, the plugin developer must To enable and configure the authorization plugin, the plugin developer must
support the Docker client interactions detailed in this section. support the Docker client interactions detailed in this section.
### Setting up Docker daemon ### Setting up Docker daemon
@ -132,7 +132,7 @@ docker: Error response from daemon: plugin PLUGIN_NAME failed with error: AuthZP
## API schema and implementation ## API schema and implementation
In addition to Docker's standard plugin registration method, each plugin In addition to Docker's standard plugin registration method, each plugin
should implement the following two methods: should implement the following two methods:
* `/AuthzPlugin.AuthZReq` This authorize request method is called before the Docker daemon processes the client request. * `/AuthzPlugin.AuthZReq` This authorize request method is called before the Docker daemon processes the client request.
@ -198,7 +198,7 @@ should implement the following two methods:
The modified response enables the authorization plugin to manipulate the content The modified response enables the authorization plugin to manipulate the content
of the HTTP response. In case of more than one plugin, each subsequent plugin of the HTTP response. In case of more than one plugin, each subsequent plugin
receives a response (optionally) modified by a previous plugin. receives a response (optionally) modified by a previous plugin.
### Request authorization ### Request authorization

12
docs/extend/index.md
View File

@ -1,19 +1,19 @@
<!--[metadata]> <!--[metadata]>
+++ +++
title = "Extend Docker" title = "Extend Engine"
description = "How to extend Docker with plugins" description = "How to extend Docker Engine with plugins"
keywords = ["extend, plugins, docker, documentation, developer"] keywords = ["extend, plugins, docker, documentation, developer"]
[menu.main] [menu.main]
identifier = "mn_extend" identifier = "engine_extend"
name = "Extend Docker" parent = "engine_use"
weight = 6 weight = 6
+++ +++
<![end-metadata]--> <![end-metadata]-->
## Extending Docker ## Extending Docker Engine
Currently, you can extend Docker by adding a plugin. This section contains the following topics: Currently, you can extend Docker Engine by adding a plugin. This section contains the following topics:
* [Understand Docker plugins](plugins.md) * [Understand Docker plugins](plugins.md)
* [Write a volume plugin](plugins_volume.md) * [Write a volume plugin](plugins_volume.md)

2
docs/extend/plugin_api.md
View File

@ -4,7 +4,7 @@ title = "Plugins API"
description = "How to write Docker plugins extensions " description = "How to write Docker plugins extensions "
keywords = ["API, Usage, plugins, documentation, developer"] keywords = ["API, Usage, plugins, documentation, developer"]
[menu.main] [menu.main]
parent = "mn_extend" parent = "engine_extend"
weight=1 weight=1
+++ +++
<![end-metadata]--> <![end-metadata]-->

8
docs/extend/plugins.md
View File

@ -1,15 +1,15 @@
<!--[metadata]> <!--[metadata]>
+++ +++
title = "Extending Docker with plugins" title = "Extending Engine with plugins"
description = "How to add additional functionality to Docker with plugins extensions" description = "How to add additional functionality to Docker with plugins extensions"
keywords = ["Examples, Usage, plugins, docker, documentation, user guide"] keywords = ["Examples, Usage, plugins, docker, documentation, user guide"]
[menu.main] [menu.main]
parent = "mn_extend" parent = "engine_extend"
weight=-1 weight=-1
+++ +++
<![end-metadata]--> <![end-metadata]-->
# Understand Docker plugins # Understand Engine plugins
You can extend the capabilities of the Docker Engine by loading third-party You can extend the capabilities of the Docker Engine by loading third-party
plugins. This page explains the types of plugins and provides links to several plugins. This page explains the types of plugins and provides links to several
@ -65,7 +65,7 @@ The following plugins exist:
* The [REX-Ray plugin](https://github.com/emccode/rexray) is a volume plugin * The [REX-Ray plugin](https://github.com/emccode/rexray) is a volume plugin
which is written in Go and provides advanced storage functionality for many which is written in Go and provides advanced storage functionality for many
platforms including VirtualBox, EC2, Google Compute Engine, OpenStack, and EMC. platforms including VirtualBox, EC2, Google Compute Engine, OpenStack, and EMC.
* The [Contiv Volume Plugin](https://github.com/contiv/volplugin) is an open * The [Contiv Volume Plugin](https://github.com/contiv/volplugin) is an open
source volume plugin that provides multi-tenant, persistent, distributed storage source volume plugin that provides multi-tenant, persistent, distributed storage
with intent based consumption using ceph underneath. with intent based consumption using ceph underneath.

16
docs/extend/plugins_network.md
View File

@ -4,19 +4,19 @@ title = "Docker network driver plugins"
description = "Network driver plugins." description = "Network driver plugins."
keywords = ["Examples, Usage, plugins, docker, documentation, user guide"] keywords = ["Examples, Usage, plugins, docker, documentation, user guide"]
[menu.main] [menu.main]
parent = "mn_extend" parent = "engine_extend"
+++ +++
<![end-metadata]--> <![end-metadata]-->
# Docker network driver plugins # Engine network driver plugins
Docker network plugins enable Docker deployments to be extended to support a Docker Engine network plugins enable Engine deployments to be extended to
wide range of networking technologies, such as VXLAN, IPVLAN, MACVLAN or support a wide range of networking technologies, such as VXLAN, IPVLAN, MACVLAN
something completely different. Network driver plugins are supported via the or something completely different. Network driver plugins are supported via the
LibNetwork project. Each plugin is implemented asa "remote driver" for LibNetwork project. Each plugin is implemented asa "remote driver" for
LibNetwork, which shares plugin infrastructure with Docker. Effectively, LibNetwork, which shares plugin infrastructure with Engine. Effectively, network
network driver plugins are activated in the same way as other plugins, and use driver plugins are activated in the same way as other plugins, and use the same
the same kind of protocol. kind of protocol.
## Using network driver plugins ## Using network driver plugins

17
docs/extend/plugins_volume.md
View File

@ -4,32 +4,32 @@ title = "Volume plugins"
description = "How to manage data with external volume plugins" description = "How to manage data with external volume plugins"
keywords = ["Examples, Usage, volume, docker, data, volumes, plugin, api"] keywords = ["Examples, Usage, volume, docker, data, volumes, plugin, api"]
[menu.main] [menu.main]
parent = "mn_extend" parent = "engine_extend"
+++ +++
<![end-metadata]--> <![end-metadata]-->
# Write a volume plugin # Write a volume plugin
Docker volume plugins enable Docker deployments to be integrated with external Docker Engine volume plugins enable Engine deployments to be integrated with
storage systems, such as Amazon EBS, and enable data volumes to persist beyond external storage systems, such as Amazon EBS, and enable data volumes to persist
the lifetime of a single Docker host. See the [plugin documentation](plugins.md) beyond the lifetime of a single Engine host. See the [plugin
for more information. documentation](plugins.md) for more information.
## Command-line changes ## Command-line changes
A volume plugin makes use of the `-v`and `--volume-driver` flag on the `docker run` command. The `-v` flag accepts a volume name and the `--volume-driver` flag a driver type, for example: A volume plugin makes use of the `-v`and `--volume-driver` flag on the `docker run` command. The `-v` flag accepts a volume name and the `--volume-driver` flag a driver type, for example:
$ docker run -ti -v volumename:/data --volume-driver=flocker busybox sh $ docker run -ti -v volumename:/data --volume-driver=flocker busybox sh
This command passes the `volumename` through to the volume plugin as a This command passes the `volumename` through to the volume plugin as a
user-given name for the volume. The `volumename` must not begin with a `/`. user-given name for the volume. The `volumename` must not begin with a `/`.
By having the user specify a `volumename`, a plugin can associate the volume By having the user specify a `volumename`, a plugin can associate the volume
with an external volume beyond the lifetime of a single container or container with an external volume beyond the lifetime of a single container or container
host. This can be used, for example, to move a stateful container from one host. This can be used, for example, to move a stateful container from one
server to another. server to another.
By specifying a `volumedriver` in conjunction with a `volumename`, users can use plugins such as [Flocker](https://clusterhq.com/docker-plugin/) to manage volumes external to a single host, such as those on EBS. By specifying a `volumedriver` in conjunction with a `volumename`, users can use plugins such as [Flocker](https://clusterhq.com/docker-plugin/) to manage volumes external to a single host, such as those on EBS.
## Create a VolumeDriver ## Create a VolumeDriver
@ -214,4 +214,3 @@ Get the list of volumes registered with the plugin.
``` ```
Respond with a string error if an error occurred. Respond with a string error if an error occurred.

17
docs/reference/builder.md
View File

@ -4,7 +4,8 @@ title = "Dockerfile reference"
description = "Dockerfiles use a simple DSL which allows you to automate the steps you would normally manually take to create an image." description = "Dockerfiles use a simple DSL which allows you to automate the steps you would normally manually take to create an image."
keywords = ["builder, docker, Dockerfile, automation, image creation"] keywords = ["builder, docker, Dockerfile, automation, image creation"]
[menu.main] [menu.main]
parent = "mn_reference" parent = "engine_ref"
weight=-90
+++ +++
<![end-metadata]--> <![end-metadata]-->
@ -18,7 +19,7 @@ instructions in succession.
This page describes the commands you can use in a `Dockerfile`. When you are This page describes the commands you can use in a `Dockerfile`. When you are
done reading this page, refer to the [`Dockerfile` Best done reading this page, refer to the [`Dockerfile` Best
Practices](../articles/dockerfile_best-practices.md) for a tip-oriented guide. Practices](../userguide/eng-image/dockerfile_best-practices.md) for a tip-oriented guide.
## Usage ## Usage
@ -80,7 +81,7 @@ instructions.
Whenever possible, Docker will re-use the intermediate images (cache), Whenever possible, Docker will re-use the intermediate images (cache),
to accelerate the `docker build` process significantly. This is indicated by to accelerate the `docker build` process significantly. This is indicated by
the `Using cache` message in the console output. the `Using cache` message in the console output.
(For more information, see the [Build cache section](../articles/dockerfile_best-practices.md#build-cache)) in the (For more information, see the [Build cache section](../userguide/eng-image/dockerfile_best-practices.md#build-cache)) in the
`Dockerfile` best practices guide: `Dockerfile` best practices guide:
$ docker build -t svendowideit/ambassador . $ docker build -t svendowideit/ambassador .
@ -99,7 +100,7 @@ the `Using cache` message in the console output.
Successfully built 7ea8aef582cc Successfully built 7ea8aef582cc
When you're done with your build, you're ready to look into [*Pushing a When you're done with your build, you're ready to look into [*Pushing a
repository to its registry*](../userguide/dockerrepos.md#contributing-to-docker-hub). repository to its registry*](../userguide/containers/dockerrepos.md#contributing-to-docker-hub).
## Format ## Format
@ -298,7 +299,7 @@ Or
The `FROM` instruction sets the [*Base Image*](glossary.md#base-image) The `FROM` instruction sets the [*Base Image*](glossary.md#base-image)
for subsequent instructions. As such, a valid `Dockerfile` must have `FROM` as for subsequent instructions. As such, a valid `Dockerfile` must have `FROM` as
its first instruction. The image can be any valid image – it is especially easy its first instruction. The image can be any valid image – it is especially easy
to start by **pulling an image** from the [*Public Repositories*](../userguide/dockerrepos.md). to start by **pulling an image** from the [*Public Repositories*](../userguide/containers/dockerrepos.md).
- `FROM` must be the first non-comment instruction in the `Dockerfile`. - `FROM` must be the first non-comment instruction in the `Dockerfile`.
@ -369,7 +370,7 @@ cache for `RUN` instructions can be invalidated by using the `--no-cache`
flag, for example `docker build --no-cache`. flag, for example `docker build --no-cache`.
See the [`Dockerfile` Best Practices See the [`Dockerfile` Best Practices
guide](../articles/dockerfile_best-practices.md#build-cache) for more information. guide](../userguide/eng-image/dockerfile_best-practices.md#build-cache) for more information.
The cache for `RUN` instructions can be invalidated by `ADD` instructions. See The cache for `RUN` instructions can be invalidated by `ADD` instructions. See
[below](#add) for details. [below](#add) for details.
@ -608,7 +609,7 @@ of whether or not the file has changed and the cache should be updated.
> following instructions from the Dockerfile if the contents of `<src>` have > following instructions from the Dockerfile if the contents of `<src>` have
> changed. This includes invalidating the cache for `RUN` instructions. > changed. This includes invalidating the cache for `RUN` instructions.
> See the [`Dockerfile` Best Practices > See the [`Dockerfile` Best Practices
guide](../articles/dockerfile_best-practices.md#build-cache) for more information. guide](../userguide/eng-image/dockerfile_best-practices.md#build-cache) for more information.
`ADD` obeys the following rules: `ADD` obeys the following rules:
@ -959,7 +960,7 @@ containers. The value can be a JSON array, `VOLUME ["/var/log/"]`, or a plain
string with multiple arguments, such as `VOLUME /var/log` or `VOLUME /var/log string with multiple arguments, such as `VOLUME /var/log` or `VOLUME /var/log
/var/db`. For more information/examples and mounting instructions via the /var/db`. For more information/examples and mounting instructions via the
Docker client, refer to Docker client, refer to
[*Share Directories via Volumes*](../userguide/dockervolumes.md#mount-a-host-directory-as-a-data-volume) [*Share Directories via Volumes*](../userguide/containers/dockervolumes.md#mount-a-host-directory-as-a-data-volume)
documentation. documentation.
The `docker run` command initializes the newly created volume with any data The `docker run` command initializes the newly created volume with any data

2
docs/reference/commandline/export.md
View File

@ -23,7 +23,7 @@ the container, `docker export` will export the contents of the *underlying*
directory, not the contents of the volume. directory, not the contents of the volume.
Refer to [Backup, restore, or migrate data Refer to [Backup, restore, or migrate data
volumes](../../userguide/dockervolumes.md#backup-restore-or-migrate-data-volumes) in volumes](../../userguide/containers/dockervolumes.md#backup-restore-or-migrate-data-volumes) in
the user guide for examples on exporting data in a volume. the user guide for examples on exporting data in a volume.
## Examples ## Examples

5
docs/reference/commandline/index.md
View File

@ -1,11 +1,12 @@
<!-- [metadata]> <!-- [metadata]>
+++ +++
title = "Docker Engine Commands" title = "Command line reference"
description = "Docker's CLI command description and usage" description = "Docker's CLI command description and usage"
keywords = ["Docker, Docker documentation, CLI, command line"] keywords = ["Docker, Docker documentation, CLI, command line"]
[menu.main] [menu.main]
identifier= "smn_cli" identifier= "smn_cli"
parent = "mn_reference" parent = "engine_ref"
weight=-70
+++ +++
<![end-metadata]--> <![end-metadata]-->

2
docs/reference/commandline/search.md
View File

@ -21,7 +21,7 @@ parent = "smn_cli"
Search [Docker Hub](https://hub.docker.com) for images Search [Docker Hub](https://hub.docker.com) for images
See [*Find Public Images on Docker Hub*](../../userguide/dockerrepos.md#searching-for-images) for See [*Find Public Images on Docker Hub*](../../userguide/containers/dockerrepos.md#searching-for-images) for
more details on finding shared images from the command line. more details on finding shared images from the command line.
> **Note:** > **Note:**

2
docs/reference/commandline/tag.md
View File

@ -17,4 +17,4 @@ parent = "smn_cli"
--help Print usage --help Print usage
You can group your images together using names and tags, and then upload them You can group your images together using names and tags, and then upload them
to [*Share Images via Repositories*](../../userguide/dockerrepos.md#contributing-to-docker-hub). to [*Share Images via Repositories*](../../userguide/containers/dockerrepos.md#contributing-to-docker-hub).

18
docs/reference/index.md Normal file
View File

@ -0,0 +1,18 @@
<!-- [metadata]>
+++
title = "Engine reference"
description = "Docker Engine reference"
keywords = ["Engine"]
[menu.main]
parent="engine_use"
identifier="engine_ref"
weight=70
+++
<![end-metadata]-->
# Engine reference
* [Dockerfile reference](builder.md)
* [Docker run reference](run.md)
* [Command line reference](commandline/index.md)
* [API Reference](api/index.md)

23
docs/reference/run.md
View File

@ -4,7 +4,8 @@ title = "Docker run reference"
description = "Configure containers at runtime" description = "Configure containers at runtime"
keywords = ["docker, run, configure, runtime"] keywords = ["docker, run, configure, runtime"]
[menu.main] [menu.main]
parent = "mn_reference" parent = "engine_ref"
weight=-80
+++ +++
<![end-metadata]--> <![end-metadata]-->
@ -550,7 +551,7 @@ The exit code from `docker run` gives information about why the container
failed to run or why it exited. When `docker run` exits with a non-zero code, failed to run or why it exited. When `docker run` exits with a non-zero code,
the exit codes follow the `chroot` standard, see below: the exit codes follow the `chroot` standard, see below:
**_125_** if the error is with Docker daemon **_itself_** **_125_** if the error is with Docker daemon **_itself_**
$ docker run --foo busybox; echo $? $ docker run --foo busybox; echo $?
# flag provided but not defined: --foo # flag provided but not defined: --foo
@ -573,7 +574,7 @@ the exit codes follow the `chroot` standard, see below:
**_Exit code_** of **_contained command_** otherwise **_Exit code_** of **_contained command_** otherwise
$ docker run busybox /bin/sh -c 'exit 3' $ docker run busybox /bin/sh -c 'exit 3'
# 3 # 3
## Clean up (--rm) ## Clean up (--rm)
@ -1000,9 +1001,9 @@ For example, to set `/dev/sda` device weight to `200`:
ubuntu ubuntu
If you specify both the `--blkio-weight` and `--blkio-weight-device`, Docker If you specify both the `--blkio-weight` and `--blkio-weight-device`, Docker
uses the `--blkio-weight` as the default weight and uses `--blkio-weight-device` uses the `--blkio-weight` as the default weight and uses `--blkio-weight-device`
to override this default with a new value on a specific device. to override this default with a new value on a specific device.
The following example uses a default weight of `300` and overrides this default The following example uses a default weight of `300` and overrides this default
on `/dev/sda` setting that weight to `200`: on `/dev/sda` setting that weight to `200`:
$ docker run -it \ $ docker run -it \
@ -1018,7 +1019,7 @@ per second from `/dev/sda`:
The `--device-write-bps` flag limits the write rate (bytes per second)to a device. The `--device-write-bps` flag limits the write rate (bytes per second)to a device.
For example, this command creates a container and limits the write rate to `1mb` For example, this command creates a container and limits the write rate to `1mb`
per second for `/dev/sda`: per second for `/dev/sda`:
$ docker run -it --device-write-bps /dev/sda:1mb ubuntu $ docker run -it --device-write-bps /dev/sda:1mb ubuntu
@ -1061,7 +1062,7 @@ one can use this flag:
By default, Docker containers are "unprivileged" and cannot, for By default, Docker containers are "unprivileged" and cannot, for
example, run a Docker daemon inside a Docker container. This is because example, run a Docker daemon inside a Docker container. This is because
by default a container is not allowed to access any devices, but a by default a container is not allowed to access any devices, but a
"privileged" container is given access to all devices (see "privileged" container is given access to all devices (see
the documentation on [cgroups devices](https://www.kernel.org/doc/Documentation/cgroups/devices.txt)). the documentation on [cgroups devices](https://www.kernel.org/doc/Documentation/cgroups/devices.txt)).
When the operator executes `docker run --privileged`, Docker will enable When the operator executes `docker run --privileged`, Docker will enable
@ -1195,7 +1196,7 @@ container's logging driver. The following options are supported:
The `docker logs` command is available only for the `json-file` and `journald` The `docker logs` command is available only for the `json-file` and `journald`
logging drivers. For detailed information on working with logging drivers, see logging drivers. For detailed information on working with logging drivers, see
[Configure a logging driver](logging/overview.md). [Configure a logging driver](../admin/logging/overview.md).
## Overriding Dockerfile image defaults ## Overriding Dockerfile image defaults
@ -1383,7 +1384,7 @@ Similarly the operator can set the **hostname** with `-h`.
--volumes-from="": Mount all volumes from the given container(s) --volumes-from="": Mount all volumes from the given container(s)
> **Note**: > **Note**:
> The auto-creation of the host path has been [*deprecated*](../misc/deprecated.md#auto-creating-missing-host-paths-for-bind-mounts). > The auto-creation of the host path has been [*deprecated*](../deprecated.md#auto-creating-missing-host-paths-for-bind-mounts).
> **Note**: > **Note**:
> When using systemd to manage the Docker daemon's start and stop, in the systemd > When using systemd to manage the Docker daemon's start and stop, in the systemd
@ -1395,7 +1396,7 @@ Similarly the operator can set the **hostname** with `-h`.
The volumes commands are complex enough to have their own documentation The volumes commands are complex enough to have their own documentation
in section [*Managing data in in section [*Managing data in
containers*](../userguide/dockervolumes.md). A developer can define containers*](../userguide/containers/dockervolumes.md). A developer can define
one or more `VOLUME`'s associated with an image, but only the operator one or more `VOLUME`'s associated with an image, but only the operator
can give access from one container to another (or from a container to a can give access from one container to another (or from a container to a
volume mounted on the host). volume mounted on the host).