Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs: refactor cli run reference #4615

Merged
merged 24 commits into from
Dec 13, 2023
Merged
Changes from 1 commit
Commits
Show all changes
24 commits
Select commit Hold shift + click to select a range
2f48f41
docs: improve introduction to docker run
dvdksn Oct 20, 2023
fad227d
docs: move info about fg/bg flags to run reference
dvdksn Oct 20, 2023
03dc883
docs: improve docs on container identification
dvdksn Nov 8, 2023
d66fe78
docs: move --pid to docker run reference
dvdksn Nov 22, 2023
ff62bf4
docs: move --uts to docker run reference
dvdksn Nov 22, 2023
5dd6e9a
docs: move --ipc to docker run reference
dvdksn Nov 22, 2023
7362097
docs: simplify container networking intro
dvdksn Nov 22, 2023
dbffa0d
docs: move --restart to docker run reference
dvdksn Nov 23, 2023
32189ca
docs: improve description about container exit codes
dvdksn Nov 23, 2023
f984444
docs: move --rm to docker run reference
dvdksn Nov 23, 2023
92c664b
docs: move info about --security-opt to docker run reference
dvdksn Nov 23, 2023
9e75a4c
docs: move --init to docker run reference
dvdksn Nov 23, 2023
72df196
docs: move --cgroup-parent to docker run reference
dvdksn Nov 23, 2023
4a6cde8
docs: move --log-driver to docker run reference
dvdksn Nov 23, 2023
c695ad9
docs: rewrite section on overriding image defaults
dvdksn Nov 23, 2023
b01e287
docs: rewrite section on default entrypoint
dvdksn Nov 27, 2023
3eeac20
docs: rewrite section on exposing ports
dvdksn Nov 27, 2023
7585d66
docs: rewrite section on overriding environment variables
dvdksn Nov 27, 2023
5ede4c8
docs: minor improvements to the healthcheck section
dvdksn Nov 27, 2023
52716c8
docs: move --tmpfs to docker run reference
dvdksn Nov 27, 2023
259aa90
docs: rewrite section on filesystem mounts
dvdksn Nov 27, 2023
4a84514
docs: rewrite section on setting user id
dvdksn Nov 27, 2023
2e394eb
docs: rewrite section on working directory
dvdksn Nov 28, 2023
f8dd8f0
docs: refresh --publish, add --publish-all
dvdksn Dec 12, 2023
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
122 changes: 76 additions & 46 deletions docs/reference/run.md
Original file line number Diff line number Diff line change
Expand Up @@ -189,6 +189,82 @@ round-trip min/avg/max = 0.257/0.288/0.326 ms
For more information about container networking, see [Networking
overview](https://docs.docker.com/network/)

## Filesystem mounts

By default, the data in a container is stored in an ephemeral, writable
container layer. Removing the container also removes its data. If you want to
use persistent data with containers, you can use filesystem mounts to store the
data persistently on the host system. Filesystem mounts can also let you share
data between containers and the host.

Docker supports two main categories of mounts:

- Volume mounts
- Bind mounts
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Related to my previous comment. Looks like this section is not as complete as https://docs.docker.com/storage/, and misses at least the tmpfs mounts.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah I didn't intend to make everything on this page exhaustive; it could put us back where this page started. My thinking is:

  • General information here
  • All the details in the reference docs


Volume mounts are great for persistently storing data for containers, and for
sharing data between containers. Bind mounts, on the other hand, are for
sharing data between a container and the host.

You can add a filesystem mount to a container using the `--mount` flag for the
`docker run` command.

The following sections show basic examples of how to create volumes and bind
mounts. For more in-depth examples and descriptions, refer to the section of
the [storage section](https://docs.docker.com/storage/) in the documentation.

### Volume mounts

To create a volume mount:

```console
$ docker run --mount source=<VOLUME_NAME>,target=[PATH] [IMAGE] [COMMAND...]
```

The `--mount` flag takes two parameters in this case: `source` and `target`.
The value for the `source` parameter is the name of the volume. The value of
`target` is the mount location of the volume inside the container. Once you've
created the volume, any data you write to the volume is persisted, even if you
stop or remove the container:

```console
$ docker run --rm --mount source=my_volume,target=/foo busybox \
echo "hello, volume!" > /foo/hello.txt
$ docker run --mount source=my_volume,target=/bar busybox
cat /bar/hello.txt
hello, volume!
```

The `target` must always be an absolute path, such as `/src/docs`. An absolute
path starts with a `/` (forward slash). Volume names must start with an
alphanumeric character, followed by `a-z0-9`, `_` (underscore), `.` (period) or
`-` (hyphen).

### Bind mounts

To create a bind mount:

```console
$ docker run -it --mount type=bind,source=[PATH],target=[PATH] busybox
```

In this case, the `--mount` flag takes three parameters. A type (`bind`), and
two paths. The `source` path is a the location on the host that you want to
bind mount into the container. The `target` path is the mount destination
inside the container.

Bind mounts are read-write by default, meaning that you can both read and write
files to and from the mounted location from the container. Changes that you
make, such as adding or editing files, are reflected on the host filesystem:

```console
$ docker run -it --mount type=bind,source=.,target=/foo busybox
/ # echo "hello from container" > /foo/hello.txt
/ # exit
$ cat hello.txt
hello from container
```

## Exit status

The exit code from `docker run` gives information about why the container
Expand Down Expand Up @@ -900,7 +976,6 @@ override those defaults using flags for the `docker run` command.
- [Expose ports](#exposed-ports)
- [Environment variables](#environment-variables)
- [Healthcheck](#healthchecks)
- [Filesystem mounts](#filesystem-mounts)
- [User](#user)
- [Working directory](#working-directory)

Expand Down Expand Up @@ -1130,51 +1205,6 @@ $ sleep 2; docker inspect --format='{{json .State.Health}}' test

The health status is also displayed in the `docker ps` output.

### Filesystem mounts

-v, --volume=[host-src:]container-dest[:<options>]: Bind mount a volume.
The comma-delimited `options` are [rw|ro], [z|Z],
[[r]shared|[r]slave|[r]private], and [nocopy].
The 'host-src' is an absolute path or a name value.

If neither 'rw' or 'ro' is specified then the volume is mounted in
read-write mode.

The `nocopy` mode is used to disable automatically copying the requested volume
path in the container to the volume storage location.
For named volumes, `copy` is the default mode. Copy modes are not supported
for bind-mounted volumes.

--volumes-from="": Mount all volumes from the given container(s)

> **Note**
>
> When using systemd to manage the Docker daemon's start and stop, in the systemd
> unit file there is an option to control mount propagation for the Docker daemon
> itself, called `MountFlags`. The value of this setting may cause Docker to not
> see mount propagation changes made on the mount point. For example, if this value
> is `slave`, you may not be able to use the `shared` or `rshared` propagation on
> a volume.

The volumes commands are complex enough to have their own documentation
in section [*Use volumes*](https://docs.docker.com/storage/volumes/). A developer can define
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
volume mounted on the host).

The `container-dest` must always be an absolute path such as `/src/docs`.
The `host-src` can either be an absolute path or a `name` value. If you
supply an absolute path for the `host-src`, Docker bind-mounts to the path
you specify. If you supply a `name`, Docker creates a named volume by that `name`.

A `name` value must start with an alphanumeric character,
followed by `a-z0-9`, `_` (underscore), `.` (period) or `-` (hyphen).
An absolute path starts with a `/` (forward slash).

For example, you can specify either `/foo` or `foo` for a `host-src` value.
If you supply the `/foo` value, Docker creates a bind mount. If you supply
the `foo` specification, Docker creates a named volume.

### User

`root` (id = 0) is the default user within a container. The image developer can
Expand Down