docker run命令-运行一个新的容器
run 运行一个新的容器
The docker run
command first creates
创建一个新可写的image, 然后 starts
启动. That is, docker run
相当于执行了 API/containers/create
then /containers/(id)/start
. 一个已经存在容器 可以使用start来启动
The docker run
command can be used in combination with docker commit
to change the command that a container runs.
See the Docker User Guide for more detailed information about the --expose
, -p
, -P
and --link
parameters, and linking containers.
Known Issues (run –volumes-from)已知的bug
- Issue 2702: "lxc-start: Permission denied - failed to mount" could indicate a permissions problem with AppArmor. Please see the issue for a workaround.
Examples:
这个容器将输出 test
在console. The cidfile
创建一个新的文件并把容器id写入. 如果文件已经存在就返回错误. docker run
退出时,将释放cid文件.
cap_sys_admin
--privileged
需要显式的指定权限才能进行mount等高权限操作:
The --privileged
flag gives all capabilities to the container, and it also lifts all the limitations enforced by the device
cgroup controller. In other words, the container can then do almost everything that the host can do. This flag exists to allow special use-cases, like running Docker within Docker.
The -w
lets the command being executed inside directory given, here /path/to/dir/
. If the path does not exists it is created inside the container.
The -v
flag mounts the current working directory into the container. The -w
lets the command being executed inside the current working directory, by changing into the directory to the value returned by pwd
. So this combination executes the command using the container, but inside the current working directory.
When the host directory of a bind-mounted volume doesn't exist, Docker will automatically create this directory on the host for you. In the example above, Docker will create the /doesnt/exist
folder before starting your container.
By bind-mounting the docker unix socket and statically linked docker binary (such as that provided byhttps://get.docker.io), you give the container the full access to create and manipulate the host's docker daemon.
This binds port 8080
of the container to port 80
on 127.0.0.1
of the host machine. The Docker User Guide explains in detail how to manipulate ports in Docker.
This exposes port 80
of the container for use within a link without publishing the port to the host system's interfaces. The Docker User Guide explains in detail how to manipulate ports in Docker.
This sets environmental variables in the container. For illustration all three flags are shown here. Where -e
, --env
take an environment variable and value, or if no "=" is provided, then that variable's current value is passed through (i.e. $MYVAR1 from the host is set to $MYVAR1 in the container). All three flags, -e
, --env
and --env-file
can be repeated.
Regardless of the order of these three flags, the --env-file
are processed first, and then -e
, --env
flags. This way, the -e
or --env
will override variables as needed.
The --env-file
flag takes a filename as an argument and expects each line to be in the VAR=VAL format, mimicking the argument passed to --env
. Comment lines need only be prefixed with #
An example of a file passed with --env-file
This will create and run a new container with the container name being console
.
The --link
flag will link the container named /redis
into the newly created container with the aliasredis
. The new container can access the network and environment of the redis
container via environment variables. The --name
flag will assign the name console
to the newly created container.
The --volumes-from
flag mounts all the defined volumes from the referenced containers. Containers can be specified by a comma separated list or by repetitions of the --volumes-from
argument. The container ID may be 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.
This pipes data into a container and prints the container's ID by attaching only to the container's STDIN
.
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 is how piping a file into a container could be done for a build. The container's ID will be printed after the build is done and the build logs could be retrieved using docker logs
. This is useful if you need to pipe a file or something else into a container and retrieve the container's ID once the container has finished running.
A complete example:
This example shows 5 containers that might be set up to test a web application change:
- Start a pre-prepared volume image
static-web-files
(in the background) that has CSS, image and static HTML in it, (with aVOLUME
instruction in the Dockerfile to allow the web server to use those files); - Start a pre-prepared
riakserver
image, give the container nameriak
and expose port8098
to any containers that link to it; - Start the
appserver
image, restricting its memory usage to 100MB, setting two environment variablesDEVELOPMENT
andBRANCH
and bind-mounting the current directory ($(pwd)
) in the container in read-only mode as/app/bin
; - Start the
webserver
, mapping port443
in the container to port1443
on the Docker server, setting the DNS server to10.0.0.1
and DNS search domain todev.org
, creating a volume to put the log files into (so we can access it from another container), then importing the files from the volume exposed by thestatic
container, and linking to all exposed ports fromriak
andapp
. Lastly, we set the hostname toweb.sven.dev.org
so its consistent with the pre-generated SSL certificate; - Finally, we create a container that runs
tail -f access.log
using the logs volume from theweb
container, setting the workdir to/var/log/httpd
. The--rm
option means that when the container exits, the container's layer is removed.