mirror of https://github.com/docker/cli.git
Formatting and consistency fixes to CLI and RUN references
* Removed double backticks. * Reformatted paragraphs. * Fixed consistent STDOUT/STDIN/STDERR references. * Fixed several broken URLs. * Fixed backtick mismatches. Docker-DCO-1.1-Signed-off-by: James Turnbull <james@lovedthanlost.net> (github: jamtur01)
This commit is contained in:
James Turnbull
Tibor Vass
parent
382814d8d8
commit
dce7a15eda
|
|
@ -199,26 +199,26 @@ To kill the container, use `docker kill`.
|
|||
--rm=true Remove intermediate containers after a successful build
|
||||
-t, --tag="" Repository name (and optionally a tag) to be applied to the resulting image in case of success
|
||||
|
||||
Use this command to build Docker images from a Dockerfile
|
||||
and a "context".
|
||||
Use this command to build Docker images from a Dockerfile and a
|
||||
"context".
|
||||
|
||||
The files at `PATH` or `URL` are called the "context" of the build. The build
|
||||
process may refer to any of the files in the context, for example when using an
|
||||
[*ADD*](/reference/builder/#dockerfile-add) instruction. When a single Dockerfile is
|
||||
given as `URL` or is piped through STDIN (`docker build - < Dockerfile`), then
|
||||
no context is set.
|
||||
The files at `PATH` or `URL` are called the "context" of the build. The
|
||||
build process may refer to any of the files in the context, for example
|
||||
when using an [*ADD*](/reference/builder/#dockerfile-add) instruction.
|
||||
When a single Dockerfile is given as `URL` or is piped through `STDIN`
|
||||
(`docker build - < Dockerfile`), then no context is set.
|
||||
|
||||
When a Git repository is set as `URL`, then the
|
||||
repository is used as the context. The Git repository is cloned with its
|
||||
submodules (git clone –recursive). A fresh git clone occurs in a
|
||||
temporary directory on your local host, and then this is sent to the
|
||||
Docker daemon as the context. This way, your local user credentials and
|
||||
vpn's etc can be used to access private repositories.
|
||||
When a Git repository is set as `URL`, then the repository is used as
|
||||
the context. The Git repository is cloned with its submodules (`git
|
||||
clone -recursive`). A fresh `git clone` occurs in a temporary directory
|
||||
on your local host, and then this is sent to the Docker daemon as the
|
||||
context. This way, your local user credentials and VPN's etc can be
|
||||
used to access private repositories.
|
||||
|
||||
If a file named ``.dockerignore`` exists in the root of ``PATH`` then it is
|
||||
interpreted as a newline-separated list of exclusion patterns. Exclusion
|
||||
patterns match files or directories relative to ``PATH`` that will be excluded
|
||||
from the context. Globbing is done using Go's
|
||||
If a file named `.dockerignore` exists in the root of `PATH` then it
|
||||
is interpreted as a newline-separated list of exclusion patterns.
|
||||
Exclusion patterns match files or directories relative to `PATH` that
|
||||
will be excluded from the context. Globbing is done using Go's
|
||||
[filepath.Match](http://golang.org/pkg/path/filepath#Match) rules.
|
||||
|
||||
See also:
|
||||
|
|
@ -304,15 +304,14 @@ and the tag will be `2.0`
|
|||
|
||||
$ sudo docker build - < Dockerfile
|
||||
|
||||
This will read a Dockerfile from STDIN without
|
||||
context. Due to the lack of a context, no contents of any local
|
||||
directory will be sent to the `docker` daemon. Since
|
||||
there is no context, a Dockerfile `ADD`
|
||||
only works if it refers to a remote URL.
|
||||
This will read a Dockerfile from `STDIN` without context. Due to the
|
||||
lack of a context, no contents of any local directory will be sent to
|
||||
the Docker daemon. Since there is no context, a Dockerfile `ADD` only
|
||||
works if it refers to a remote URL.
|
||||
|
||||
$ sudo docker build - < context.tar.gz
|
||||
|
||||
This will build an image for a compressed context read from STDIN.
|
||||
This will build an image for a compressed context read from `STDIN`.
|
||||
Supported formats are: bzip2, gzip and xz.
|
||||
|
||||
$ sudo docker build github.com/creack/docker-firefox
|
||||
|
|
@ -518,7 +517,7 @@ by default.
|
|||
|
||||
### Filtering
|
||||
|
||||
The filtering flag (-f or --filter) format is of "key=value". If there are more
|
||||
The filtering flag (`-f` or `--filter`) format is of "key=value". If there are more
|
||||
than one filter, then pass multiple flags (e.g. `--filter "foo=bar" --filter "bif=baz"`)
|
||||
|
||||
Current filters:
|
||||
|
|
@ -562,11 +561,10 @@ NOTE: Docker will warn you if any containers exist that are using these untagged
|
|||
|
||||
Create an empty filesystem image and import the contents of the tarball (.tar, .tar.gz, .tgz, .bzip, .tar.xz, .txz) into it, then optionally tag it.
|
||||
|
||||
URLs must start with `http` and point to a single
|
||||
file archive (.tar, .tar.gz, .tgz, .bzip, .tar.xz, or .txz) containing a
|
||||
root filesystem. If you would like to import from a local directory or
|
||||
archive, you can use the `-` parameter to take the
|
||||
data from STDIN.
|
||||
URLs must start with `http` and point to a single file archive (.tar,
|
||||
.tar.gz, .tgz, .bzip, .tar.xz, or .txz) containing a root filesystem. If
|
||||
you would like to import from a local directory or archive, you can use
|
||||
the `-` parameter to take the data from `STDIN`.
|
||||
|
||||
### Examples
|
||||
|
||||
|
|
@ -578,7 +576,7 @@ This will create a new untagged image.
|
|||
|
||||
**Import from a local file:**
|
||||
|
||||
Import to docker via pipe and STDIN.
|
||||
Import to docker via pipe and `STDIN`.
|
||||
|
||||
$ cat exampleimage.tgz | sudo docker import - exampleimagelocal:new
|
||||
|
||||
|
|
@ -681,7 +679,7 @@ contains complex json object, so to grab it as JSON, you use
|
|||
|
||||
-s, --signal="KILL" Signal to send to the container
|
||||
|
||||
The main process inside the container will be sent SIGKILL, or any
|
||||
The main process inside the container will be sent `SIGKILL`, or any
|
||||
signal specified with option `--signal`.
|
||||
|
||||
## load
|
||||
|
|
@ -739,8 +737,8 @@ The `docker logs` command batch-retrieves all logs
|
|||
present at the time of execution.
|
||||
|
||||
The ``docker logs --follow`` command will first return all logs from the
|
||||
beginning and then continue streaming new output from the container's stdout
|
||||
and stderr.
|
||||
beginning and then continue streaming new output from the container's `STDOUT`
|
||||
and `STDERR`.
|
||||
|
||||
## port
|
||||
|
||||
|
|
@ -1074,7 +1072,7 @@ This will create and run a new container with the container name being
|
|||
|
||||
The `--link` flag will link the container named `/redis` into the newly
|
||||
created container with the alias `redis`. The new container can access the
|
||||
network and environment of the redis container via environment variables.
|
||||
network and environment of the `redis` container via environment variables.
|
||||
The `--name` flag will assign the name `console` to the newly created
|
||||
container.
|
||||
|
||||
|
|
@ -1087,19 +1085,19 @@ optionally suffixed with `:ro` or `:rw` to mount the volumes in read-only
|
|||
or read-write mode, respectively. By default, the volumes are mounted in
|
||||
the same mode (read write or read only) as the reference container.
|
||||
|
||||
The `-a` flag tells `docker run` to bind to the container's stdin, stdout or
|
||||
stderr. This makes it possible to manipulate the output and input as needed.
|
||||
The `-a` flag tells `docker run` to bind to the container's `STDIN`, `STDOUT` or
|
||||
`STDERR`. This makes it possible to manipulate the output and input as needed.
|
||||
|
||||
$ echo "test" | sudo docker run -i -a stdin ubuntu cat -
|
||||
|
||||
This pipes data into a container and prints the container's ID by attaching
|
||||
only to the container'sstdin.
|
||||
only to the container's `STDIN`.
|
||||
|
||||
$ sudo docker run -a stderr ubuntu echo test
|
||||
|
||||
This isn't going to print anything unless there's an error because We've
|
||||
only attached to the stderr of the container. The container's logs still
|
||||
store what's been written to stderr and stdout.
|
||||
This isn't going to print anything unless there's an error because we've
|
||||
only attached to the `STDERR` of the container. The container's logs
|
||||
still store what's been written to `STDERR` and `STDOUT`.
|
||||
|
||||
$ cat somefile | sudo docker run -i -a stdin mybuilder dobuild
|
||||
|
||||
|
|
|
|||
|
|
@ -5,13 +5,13 @@ page_keywords: docker, run, configure, runtime
|
|||
# Docker Run Reference
|
||||
|
||||
**Docker runs processes in isolated containers**. When an operator
|
||||
executes `docker run`, she starts a process with its
|
||||
own file system, its own networking, and its own isolated process tree.
|
||||
The [*Image*](/terms/image/#image-def) which starts the process may
|
||||
define defaults related to the binary to run, the networking to expose,
|
||||
and more, but `docker run` gives final control to
|
||||
the operator who starts the container from the image. That's the main
|
||||
reason [*run*](/reference/commandline/cli/#cli-run) has more options than any
|
||||
executes `docker run`, she starts a process with its own file system,
|
||||
its own networking, and its own isolated process tree. The
|
||||
[*Image*](/terms/image/#image-def) which starts the process may define
|
||||
defaults related to the binary to run, the networking to expose, and
|
||||
more, but `docker run` gives final control to the operator who starts
|
||||
the container from the image. That's the main reason
|
||||
[*run*](/reference/commandline/cli/#cli-run) has more options than any
|
||||
other `docker` command.
|
||||
|
||||
## General Form
|
||||
|
|
@ -36,10 +36,10 @@ The list of `[OPTIONS]` breaks down into two groups:
|
|||
2. Setting shared between operators and developers, where operators can
|
||||
override defaults developers set in images at build time.
|
||||
|
||||
Together, the `docker run [OPTIONS]` give complete
|
||||
control over runtime behavior to the operator, allowing them to override
|
||||
all defaults set by the developer during `docker build`
|
||||
and nearly all the defaults set by the Docker runtime itself.
|
||||
Together, the `docker run [OPTIONS]` give complete control over runtime
|
||||
behavior to the operator, allowing them to override all defaults set by
|
||||
the developer during `docker build` and nearly all the defaults set by
|
||||
the Docker runtime itself.
|
||||
|
||||
## Operator Exclusive Options
|
||||
|
||||
|
|
@ -54,10 +54,8 @@ following options.
|
|||
- [PID Equivalent](#pid-equivalent)
|
||||
- [Network Settings](#network-settings)
|
||||
- [Clean Up (--rm)](#clean-up-rm)
|
||||
- [Runtime Constraints on CPU and
|
||||
Memory](#runtime-constraints-on-cpu-and-memory)
|
||||
- [Runtime Privilege and LXC
|
||||
Configuration](#runtime-privilege-and-lxc-configuration)
|
||||
- [Runtime Constraints on CPU and Memory](#runtime-constraints-on-cpu-and-memory)
|
||||
- [Runtime Privilege and LXC Configuration](#runtime-privilege-and-lxc-configuration)
|
||||
|
||||
## Detached vs Foreground
|
||||
|
||||
|
|
@ -78,28 +76,28 @@ container in the detached mode, then you cannot use the `--rm` option.
|
|||
|
||||
### Foreground
|
||||
|
||||
In foreground mode (the default when `-d` is not specified), `docker run`
|
||||
can start the process in the container and attach the console to the process's
|
||||
standard input, output, and standard error. It can even pretend to be a TTY
|
||||
(this is what most command line executables expect) and pass along signals. All
|
||||
of that is configurable:
|
||||
In foreground mode (the default when `-d` is not specified), `docker
|
||||
run` can start the process in the container and attach the console to
|
||||
the process's standard input, output, and standard error. It can even
|
||||
pretend to be a TTY (this is what most command line executables expect)
|
||||
and pass along signals. All of that is configurable:
|
||||
|
||||
-a=[] : Attach to ``stdin``, ``stdout`` and/or ``stderr``
|
||||
-a=[] : Attach to `STDIN`, `STDOUT` and/or `STDERR`
|
||||
-t=false : Allocate a pseudo-tty
|
||||
--sig-proxy=true: Proxify all received signal to the process (even in non-tty mode)
|
||||
-i=false : Keep STDIN open even if not attached
|
||||
|
||||
If you do not specify `-a` then Docker will [attach everything (stdin,stdout,stderr)](
|
||||
https://github.com/dotcloud/docker/blob/
|
||||
75a7f4d90cde0295bcfb7213004abce8d4779b75/commands.go#L1797). You can specify to which
|
||||
of the three standard streams (`stdin`, `stdout`, `stderr`) you'd like to connect
|
||||
instead, as in:
|
||||
If you do not specify `-a` then Docker will [attach all standard
|
||||
streams]( https://github.com/dotcloud/docker/blob/
|
||||
75a7f4d90cde0295bcfb7213004abce8d4779b75/commands.go#L1797). You can
|
||||
specify to which of the three standard streams (`STDIN`, `STDOUT`,
|
||||
`STDERR`) you'd like to connect instead, as in:
|
||||
|
||||
$ docker run -a stdin -a stdout -i -t ubuntu /bin/bash
|
||||
|
||||
For interactive processes (like a shell) you will typically want a tty as well as
|
||||
persistent standard input (`stdin`), so you'll use `-i -t` together in most
|
||||
interactive cases.
|
||||
For interactive processes (like a shell) you will typically want a tty
|
||||
as well as persistent standard input (`STDIN`), so you'll use `-i -t`
|
||||
together in most interactive cases.
|
||||
|
||||
## Container Identification
|
||||
|
||||
|
|
@ -113,19 +111,18 @@ The operator can identify a container in three ways:
|
|||
- Name ("evil_ptolemy")
|
||||
|
||||
The UUID identifiers come from the Docker daemon, and if you do not
|
||||
assign a name to the container with `--name` then
|
||||
the daemon will also generate a random string name too. The name can
|
||||
become a handy way to add meaning to a container since you can use this
|
||||
name when defining
|
||||
[*links*](/userguide/dockerlinks/#working-with-links-names)
|
||||
(or any other place you need to identify a container). This works for
|
||||
both background and foreground Docker containers.
|
||||
assign a name to the container with `--name` then the daemon will also
|
||||
generate a random string name too. The name can become a handy way to
|
||||
add meaning to a container since you can use this name when defining
|
||||
[*links*](/userguide/dockerlinks/#working-with-links-names) (or any
|
||||
other place you need to identify a container). This works for both
|
||||
background and foreground Docker containers.
|
||||
|
||||
### PID Equivalent
|
||||
### PID Equivalent
|
||||
|
||||
And finally, to help with automation, you can have Docker write the
|
||||
Finally, to help with automation, you can have Docker write the
|
||||
container ID out to a file of your choosing. This is similar to how some
|
||||
programs might write out their process ID to a file (you`ve seen them as
|
||||
programs might write out their process ID to a file (you've seen them as
|
||||
PID files):
|
||||
|
||||
--cidfile="": Write the container ID to the file
|
||||
|
|
@ -141,14 +138,14 @@ PID files):
|
|||
|
||||
By default, all containers have networking enabled and they can make any
|
||||
outgoing connections. The operator can completely disable networking
|
||||
with `docker run --net none` which disables all incoming and
|
||||
outgoing networking. In cases like this, you would perform I/O through
|
||||
files or STDIN/STDOUT only.
|
||||
with `docker run --net none` which disables all incoming and outgoing
|
||||
networking. In cases like this, you would perform I/O through files or
|
||||
`STDIN` and `STDOUT` only.
|
||||
|
||||
Your container will use the same DNS servers as the host by default, but
|
||||
you can override this with `--dns`.
|
||||
|
||||
Supported networking modes are:
|
||||
Supported networking modes are:
|
||||
|
||||
* none - no networking in the container
|
||||
* bridge - (default) connect the container to the bridge via veth interfaces
|
||||
|
|
@ -156,35 +153,40 @@ Supported networking modes are:
|
|||
* container - use another container's network stack
|
||||
|
||||
#### Mode: none
|
||||
With the networking mode set to `none` a container will not have a access to
|
||||
any external routes. The container will still have a `loopback` interface
|
||||
enabled in the container but it does not have any routes to external traffic.
|
||||
|
||||
With the networking mode set to `none` a container will not have a
|
||||
access to any external routes. The container will still have a
|
||||
`loopback` interface enabled in the container but it does not have any
|
||||
routes to external traffic.
|
||||
|
||||
#### Mode: bridge
|
||||
With the networking mode set to `bridge` a container will use docker's default
|
||||
networking setup. A bridge is setup on the host, commonly named `docker0`,
|
||||
and a pair of veth interfaces will be created for the container. One side of
|
||||
the veth pair will remain on the host attached to the bridge while the other
|
||||
side of the pair will be placed inside the container's namespaces in addition
|
||||
to the `loopback` interface. An IP address will be allocated for containers
|
||||
on the bridge's network and trafic will be routed though this bridge to the
|
||||
container.
|
||||
|
||||
With the networking mode set to `bridge` a container will use docker's
|
||||
default networking setup. A bridge is setup on the host, commonly named
|
||||
`docker0`, and a pair of `veth` interfaces will be created for the
|
||||
container. One side of the `veth` pair will remain on the host attached
|
||||
to the bridge while the other side of the pair will be placed inside the
|
||||
container's namespaces in addition to the `loopback` interface. An IP
|
||||
address will be allocated for containers on the bridge's network and
|
||||
traffic will be routed though this bridge to the container.
|
||||
|
||||
#### Mode: host
|
||||
|
||||
With the networking mode set to `host` a container will share the host's
|
||||
network stack and all interfaces from the host will be available to the
|
||||
container. The container's hostname will match the hostname on the host
|
||||
system. Publishing ports and linking to other containers will not work
|
||||
when sharing the host's network stack.
|
||||
network stack and all interfaces from the host will be available to the
|
||||
container. The container's hostname will match the hostname on the host
|
||||
system. Publishing ports and linking to other containers will not work
|
||||
when sharing the host's network stack.
|
||||
|
||||
#### Mode: container
|
||||
With the networking mode set to `container` a container will share the
|
||||
network stack of another container. The other container's name must be
|
||||
|
||||
With the networking mode set to `container` a container will share the
|
||||
network stack of another container. The other container's name must be
|
||||
provided in the format of `--net container:<name|id>`.
|
||||
|
||||
Example running a redis container with redis binding to localhost then
|
||||
running the redis-cli and connecting to the redis server over the
|
||||
localhost interface.
|
||||
Example running a Redis container with Redis binding to `localhost` then
|
||||
running the `redis-cli` command and connecting to the Redis server over the
|
||||
`localhost` interface.
|
||||
|
||||
$ docker run -d --name redis example/redis --bind 127.0.0.1
|
||||
$ # use the redis container's network stack to access localhost
|
||||
|
|
@ -211,15 +213,14 @@ container:
|
|||
-c=0 : CPU shares (relative weight)
|
||||
|
||||
The operator can constrain the memory available to a container easily
|
||||
with `docker run -m`. If the host supports swap
|
||||
memory, then the `-m` memory setting can be larger
|
||||
than physical RAM.
|
||||
with `docker run -m`. If the host supports swap memory, then the `-m`
|
||||
memory setting can be larger than physical RAM.
|
||||
|
||||
Similarly the operator can increase the priority of this container with
|
||||
the `-c` option. By default, all containers run at
|
||||
the same priority and get the same proportion of CPU cycles, but you can
|
||||
tell the kernel to give more shares of CPU time to one or more
|
||||
containers when you start them via Docker.
|
||||
the `-c` option. By default, all containers run at the same priority and
|
||||
get the same proportion of CPU cycles, but you can tell the kernel to
|
||||
give more shares of CPU time to one or more containers when you start
|
||||
them via Docker.
|
||||
|
||||
## Runtime Privilege and LXC Configuration
|
||||
|
||||
|
|
@ -277,19 +278,20 @@ commandline:
|
|||
|
||||
$ docker run [OPTIONS] IMAGE[:TAG] [COMMAND] [ARG...]
|
||||
|
||||
This command is optional because the person who created the `IMAGE` may have
|
||||
already provided a default `COMMAND` using the Dockerfile `CMD`. As the
|
||||
operator (the person running a container from the image), you can override that
|
||||
`CMD` just by specifying a new `COMMAND`.
|
||||
This command is optional because the person who created the `IMAGE` may
|
||||
have already provided a default `COMMAND` using the Dockerfile `CMD`
|
||||
instruction. As the operator (the person running a container from the
|
||||
image), you can override that `CMD` instruction just by specifying a new
|
||||
`COMMAND`.
|
||||
|
||||
If the image also specifies an `ENTRYPOINT` then the `CMD` or `COMMAND` get
|
||||
appended as arguments to the `ENTRYPOINT`.
|
||||
If the image also specifies an `ENTRYPOINT` then the `CMD` or `COMMAND`
|
||||
get appended as arguments to the `ENTRYPOINT`.
|
||||
|
||||
## ENTRYPOINT (Default Command to Execute at Runtime)
|
||||
|
||||
--entrypoint="": Overwrite the default entrypoint set by the image
|
||||
|
||||
The ENTRYPOINT of an image is similar to a `COMMAND` because it
|
||||
The `ENTRYPOINT` of an image is similar to a `COMMAND` because it
|
||||
specifies what executable to run when the container starts, but it is
|
||||
(purposely) more difficult to override. The `ENTRYPOINT` gives a
|
||||
container its default nature or behavior, so that when you set an
|
||||
|
|
@ -310,10 +312,10 @@ or two examples of how to pass more parameters to that ENTRYPOINT:
|
|||
|
||||
## EXPOSE (Incoming Ports)
|
||||
|
||||
The Dockerfile doesn't give much control over networking, only providing the
|
||||
`EXPOSE` instruction to give a hint to the operator about what incoming ports
|
||||
might provide services. The following options work with or override the
|
||||
Dockerfile's exposed defaults:
|
||||
The Dockerfile doesn't give much control over networking, only providing
|
||||
the `EXPOSE` instruction to give a hint to the operator about what
|
||||
incoming ports might provide services. The following options work with
|
||||
or override the Dockerfile's exposed defaults:
|
||||
|
||||
--expose=[]: Expose a port from the container
|
||||
without publishing it to your host
|
||||
|
|
@ -324,34 +326,34 @@ Dockerfile's exposed defaults:
|
|||
(use 'docker port' to see the actual mapping)
|
||||
--link="" : Add link to another container (name:alias)
|
||||
|
||||
As mentioned previously, `EXPOSE` (and `--expose`) make a port available **in**
|
||||
a container for incoming connections. The port number on the inside of the
|
||||
container (where the service listens) does not need to be the same number as the
|
||||
port exposed on the outside of the container (where clients connect), so inside
|
||||
the container you might have an HTTP service listening on port 80 (and so you
|
||||
`EXPOSE 80` in the Dockerfile), but outside the container the port might be
|
||||
42800.
|
||||
As mentioned previously, `EXPOSE` (and `--expose`) make a port available
|
||||
**in** a container for incoming connections. The port number on the
|
||||
inside of the container (where the service listens) does not need to be
|
||||
the same number as the port exposed on the outside of the container
|
||||
(where clients connect), so inside the container you might have an HTTP
|
||||
service listening on port 80 (and so you `EXPOSE 80` in the Dockerfile),
|
||||
but outside the container the port might be 42800.
|
||||
|
||||
To help a new client container reach the server container's internal port
|
||||
operator `--expose`'d by the operator or `EXPOSE`'d by the developer, the
|
||||
operator has three choices: start the server container with `-P` or `-p,` or
|
||||
start the client container with `--link`.
|
||||
To help a new client container reach the server container's internal
|
||||
port operator `--expose`'d by the operator or `EXPOSE`'d by the
|
||||
developer, the operator has three choices: start the server container
|
||||
with `-P` or `-p,` or start the client container with `--link`.
|
||||
|
||||
If the operator uses `-P` or `-p` then Docker will make the exposed port
|
||||
accessible on the host and the ports will be available to any client that
|
||||
can reach the host. To find the map between the host ports and the exposed
|
||||
ports, use `docker port`)
|
||||
accessible on the host and the ports will be available to any client
|
||||
that can reach the host. To find the map between the host ports and the
|
||||
exposed ports, use `docker port`)
|
||||
|
||||
If the operator uses `--link` when starting the new client container, then the
|
||||
client container can access the exposed port via a private networking interface.
|
||||
Docker will set some environment variables in the client container to help
|
||||
indicate which interface and port to use.
|
||||
If the operator uses `--link` when starting the new client container,
|
||||
then the client container can access the exposed port via a private
|
||||
networking interface. Docker will set some environment variables in the
|
||||
client container to help indicate which interface and port to use.
|
||||
|
||||
## ENV (Environment Variables)
|
||||
|
||||
The operator can **set any environment variable** in the container by using one
|
||||
or more `-e` flags, even overriding those already defined by the developer with
|
||||
a Dockerfile `ENV`:
|
||||
The operator can **set any environment variable** in the container by
|
||||
using one or more `-e` flags, even overriding those already defined by
|
||||
the developer with a Dockerfile `ENV`:
|
||||
|
||||
$ docker run -e "deep=purple" --rm ubuntu /bin/bash -c export
|
||||
declare -x HOME="/"
|
||||
|
|
@ -420,18 +422,19 @@ mechanism to communicate with a linked container by its alias:
|
|||
If "container-dir" is missing, then docker creates a new volume.
|
||||
--volumes-from="": Mount all volumes from the given container(s)
|
||||
|
||||
The volumes commands are complex enough to have their own documentation in
|
||||
section [*Share Directories via Volumes*](/userguide/dockervolumes/#volume-def).
|
||||
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
|
||||
The volumes commands are complex enough to have their own documentation
|
||||
in section [*Share Directories via
|
||||
Volumes*](/userguide/dockervolumes/#volume-def). 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).
|
||||
|
||||
## USER
|
||||
|
||||
The default user within a container is `root` (id = 0), but if the developer
|
||||
created additional users, those are accessible too. The developer can set a
|
||||
default user to run the first process with the `Dockerfile USER` command,
|
||||
but the operator can override it:
|
||||
The default user within a container is `root` (id = 0), but if the
|
||||
developer created additional users, those are accessible too. The
|
||||
developer can set a default user to run the first process with the
|
||||
Dockerfile `USER` instruction, but the operator can override it:
|
||||
|
||||
-u="": Username or UID
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue