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 --linkparameters, 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 aVOLUMEinstruction in the Dockerfile to allow the web server to use those files); - Start a pre-prepared
riakserverimage, give the container nameriakand expose port8098to any containers that link to it; - Start the
appserverimage, restricting its memory usage to 100MB, setting two environment variablesDEVELOPMENTandBRANCHand bind-mounting the current directory ($(pwd)) in the container in read-only mode as/app/bin; - Start the
webserver, mapping port443in the container to port1443on the Docker server, setting the DNS server to10.0.0.1and 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 thestaticcontainer, and linking to all exposed ports fromriakandapp. Lastly, we set the hostname toweb.sven.dev.orgso its consistent with the pre-generated SSL certificate; - Finally, we create a container that runs
tail -f access.logusing the logs volume from thewebcontainer, setting the workdir to/var/log/httpd. The--rmoption means that when the container exits, the container's layer is removed.