mirror of https://github.com/docker/cli.git
Removing sudo from command line examples
We now advise people to configure docker group and add to sudo. Mac shouldn't use sudo. Removed sudo from command examples. Left in installation to be removed in installation doc sweep -- removing requires finer grain control. Signed-off-by: Mary Anthony <mary@docker.com>
This commit is contained in:
Mary Anthony
Tibor Vass
parent
c4323175d9
commit
fb7eb87b94
|
|
@ -26,7 +26,7 @@ This file will describe the steps to assemble the image.
|
|||
Then call `docker build` with the path of your source repository as the argument
|
||||
(for example, `.`):
|
||||
|
||||
$ sudo docker build .
|
||||
$ docker build .
|
||||
|
||||
The path to the source repository defines where to find the *context* of
|
||||
the build. The build is run by the Docker daemon, not by the CLI, so the
|
||||
|
|
@ -49,7 +49,7 @@ directory.
|
|||
You can specify a repository and tag at which to save the new image if
|
||||
the build succeeds:
|
||||
|
||||
$ sudo docker build -t shykes/myapp .
|
||||
$ docker build -t shykes/myapp .
|
||||
|
||||
The Docker daemon will run your steps one-by-one, committing the result
|
||||
to a new image if necessary, before finally outputting the ID of your
|
||||
|
|
@ -65,7 +65,7 @@ accelerating `docker build` significantly (indicated by `Using cache` -
|
|||
see the [`Dockerfile` Best Practices
|
||||
guide](/articles/dockerfile_best-practices/#build-cache) for more information):
|
||||
|
||||
$ sudo docker build -t SvenDowideit/ambassador .
|
||||
$ docker build -t SvenDowideit/ambassador .
|
||||
Uploading context 10.24 kB
|
||||
Uploading context
|
||||
Step 1 : FROM docker-ut
|
||||
|
|
@ -175,7 +175,7 @@ The following example shows the use of the `.dockerignore` file to exclude the
|
|||
`.git` directory from the context. Its effect can be seen in the changed size of
|
||||
the uploaded context.
|
||||
|
||||
$ sudo docker build .
|
||||
$ docker build .
|
||||
Uploading context 18.829 MB
|
||||
Uploading context
|
||||
Step 0 : FROM busybox
|
||||
|
|
@ -185,7 +185,7 @@ the uploaded context.
|
|||
---> 99cc1ad10469
|
||||
Successfully built 99cc1ad10469
|
||||
$ echo ".git" > .dockerignore
|
||||
$ sudo docker build .
|
||||
$ docker build .
|
||||
Uploading context 6.76 MB
|
||||
Uploading context
|
||||
Step 0 : FROM busybox
|
||||
|
|
|
|||
|
|
@ -9,13 +9,20 @@ page_keywords: Docker, Docker documentation, CLI, command line
|
|||
To list available commands, either run `docker` with no parameters
|
||||
or execute `docker help`:
|
||||
|
||||
$ sudo docker
|
||||
$ docker
|
||||
Usage: docker [OPTIONS] COMMAND [arg...]
|
||||
-H, --host=[]: The socket(s) to bind to in daemon mode, specified using one or more tcp://host:port, unix:///path/to/socket, fd://* or fd://socketfd.
|
||||
|
||||
A self-sufficient runtime for Linux containers.
|
||||
|
||||
...
|
||||
Depending on your Docker system configuration, you may be required
|
||||
to preface each `docker` command with `sudo`. To avoid having to use `sudo` with
|
||||
the `docker` command, your system administrator can create a Unix group called
|
||||
`docker` and add users to it.
|
||||
|
||||
For more information about installing Docker or `sudo` configuration, refer to
|
||||
the [installation](/installation) instructions for your operating system.
|
||||
|
||||
## Environment Variables
|
||||
|
||||
|
|
@ -44,7 +51,7 @@ variables.
|
|||
## Help
|
||||
To list the help on any command just execute the command, followed by the `--help` option.
|
||||
|
||||
$ sudo docker run --help
|
||||
$ docker run --help
|
||||
|
||||
Usage: docker run [OPTIONS] IMAGE [COMMAND] [ARG...]
|
||||
|
||||
|
|
@ -79,11 +86,11 @@ be set to the non-default value by explicitly setting them to `false`:
|
|||
|
||||
Options like `-a=[]` indicate they can be specified multiple times:
|
||||
|
||||
$ sudo docker run -a stdin -a stdout -a stderr -i -t ubuntu /bin/bash
|
||||
$ docker run -a stdin -a stdout -a stderr -i -t ubuntu /bin/bash
|
||||
|
||||
Sometimes this can use a more complex value string, as for `-v`:
|
||||
|
||||
$ sudo docker run -v /host:/container example/mysql
|
||||
$ docker run -v /host:/container example/mysql
|
||||
|
||||
### Strings and Integers
|
||||
|
||||
|
|
@ -184,19 +191,19 @@ time using multiple `-H` options:
|
|||
The Docker client will honor the `DOCKER_HOST` environment variable to set
|
||||
the `-H` flag for the client.
|
||||
|
||||
$ sudo docker -H tcp://0.0.0.0:2375 ps
|
||||
$ docker -H tcp://0.0.0.0:2375 ps
|
||||
# or
|
||||
$ export DOCKER_HOST="tcp://0.0.0.0:2375"
|
||||
$ sudo docker ps
|
||||
$ docker ps
|
||||
# both are equal
|
||||
|
||||
Setting the `DOCKER_TLS_VERIFY` environment variable to any value other than the empty
|
||||
string is equivalent to setting the `--tlsverify` flag. The following are equivalent:
|
||||
|
||||
$ sudo docker --tlsverify ps
|
||||
$ docker --tlsverify ps
|
||||
# or
|
||||
$ export DOCKER_TLS_VERIFY=1
|
||||
$ sudo docker ps
|
||||
$ docker ps
|
||||
|
||||
The Docker client will honor the `HTTP_PROXY`, `HTTPS_PROXY`, and `NO_PROXY`
|
||||
environment variables (or the lowercase versions thereof). `HTTPS_PROXY` takes
|
||||
|
|
@ -260,7 +267,7 @@ Currently supported options are:
|
|||
|
||||
Example use:
|
||||
|
||||
$ sudo docker -d --storage-opt dm.basesize=20G
|
||||
$ docker -d --storage-opt dm.basesize=20G
|
||||
|
||||
* `dm.loopdatasize`
|
||||
|
||||
|
|
@ -270,7 +277,7 @@ Currently supported options are:
|
|||
|
||||
Example use:
|
||||
|
||||
$ sudo docker -d --storage-opt dm.loopdatasize=200G
|
||||
$ docker -d --storage-opt dm.loopdatasize=200G
|
||||
|
||||
* `dm.loopmetadatasize`
|
||||
|
||||
|
|
@ -281,7 +288,7 @@ Currently supported options are:
|
|||
|
||||
Example use:
|
||||
|
||||
$ sudo docker -d --storage-opt dm.loopmetadatasize=4G
|
||||
$ docker -d --storage-opt dm.loopmetadatasize=4G
|
||||
|
||||
* `dm.fs`
|
||||
|
||||
|
|
@ -290,7 +297,7 @@ Currently supported options are:
|
|||
|
||||
Example use:
|
||||
|
||||
$ sudo docker -d --storage-opt dm.fs=xfs
|
||||
$ docker -d --storage-opt dm.fs=xfs
|
||||
|
||||
* `dm.mkfsarg`
|
||||
|
||||
|
|
@ -298,7 +305,7 @@ Currently supported options are:
|
|||
|
||||
Example use:
|
||||
|
||||
$ sudo docker -d --storage-opt "dm.mkfsarg=-O ^has_journal"
|
||||
$ docker -d --storage-opt "dm.mkfsarg=-O ^has_journal"
|
||||
|
||||
* `dm.mountopt`
|
||||
|
||||
|
|
@ -306,7 +313,7 @@ Currently supported options are:
|
|||
|
||||
Example use:
|
||||
|
||||
$ sudo docker -d --storage-opt dm.mountopt=nodiscard
|
||||
$ docker -d --storage-opt dm.mountopt=nodiscard
|
||||
|
||||
* `dm.datadev`
|
||||
|
||||
|
|
@ -318,7 +325,7 @@ Currently supported options are:
|
|||
|
||||
Example use:
|
||||
|
||||
$ sudo docker -d \
|
||||
$ docker -d \
|
||||
--storage-opt dm.datadev=/dev/sdb1 \
|
||||
--storage-opt dm.metadatadev=/dev/sdc1
|
||||
|
||||
|
|
@ -336,7 +343,7 @@ Currently supported options are:
|
|||
|
||||
Example use:
|
||||
|
||||
$ sudo docker -d \
|
||||
$ docker -d \
|
||||
--storage-opt dm.datadev=/dev/sdb1 \
|
||||
--storage-opt dm.metadatadev=/dev/sdc1
|
||||
|
||||
|
|
@ -347,7 +354,7 @@ Currently supported options are:
|
|||
|
||||
Example use:
|
||||
|
||||
$ sudo docker -d --storage-opt dm.blocksize=512K
|
||||
$ docker -d --storage-opt dm.blocksize=512K
|
||||
|
||||
* `dm.blkdiscard`
|
||||
|
||||
|
|
@ -361,7 +368,7 @@ Currently supported options are:
|
|||
|
||||
Example use:
|
||||
|
||||
$ sudo docker -d --storage-opt dm.blkdiscard=false
|
||||
$ docker -d --storage-opt dm.blkdiscard=false
|
||||
|
||||
### Docker exec-driver option
|
||||
|
||||
|
|
@ -478,8 +485,8 @@ attaching to a tty-enabled container (i.e.: launched with `-t`).
|
|||
|
||||
#### Examples
|
||||
|
||||
$ sudo docker run -d --name topdemo ubuntu /usr/bin/top -b)
|
||||
$ sudo docker attach topdemo
|
||||
$ docker run -d --name topdemo ubuntu /usr/bin/top -b)
|
||||
$ docker attach topdemo
|
||||
top - 02:05:52 up 3:05, 0 users, load average: 0.01, 0.02, 0.05
|
||||
Tasks: 1 total, 1 running, 0 sleeping, 0 stopped, 0 zombie
|
||||
Cpu(s): 0.1%us, 0.2%sy, 0.0%ni, 99.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
|
||||
|
|
@ -516,14 +523,14 @@ attaching to a tty-enabled container (i.e.: launched with `-t`).
|
|||
And in this second example, you can see the exit code returned by the `bash` process
|
||||
is returned by the `docker attach` command to its caller too:
|
||||
|
||||
$ sudo docker run --name test -d -it debian
|
||||
$ docker run --name test -d -it debian
|
||||
275c44472aebd77c926d4527885bb09f2f6db21d878c75f0a1c212c03d3bcfab
|
||||
$ sudo docker attach test
|
||||
$ docker attach test
|
||||
$$ exit 13
|
||||
exit
|
||||
$ echo $?
|
||||
13
|
||||
$ sudo docker ps -a | grep test
|
||||
$ docker ps -a | grep test
|
||||
275c44472aeb debian:7 "/bin/bash" 26 seconds ago Exited (13) 17 seconds ago test
|
||||
|
||||
## build
|
||||
|
|
@ -636,7 +643,7 @@ See also:
|
|||
|
||||
#### Examples
|
||||
|
||||
$ sudo docker build .
|
||||
$ docker build .
|
||||
Uploading context 10240 bytes
|
||||
Step 1 : FROM busybox
|
||||
Pulling repository busybox
|
||||
|
|
@ -681,7 +688,7 @@ If you wish to keep the intermediate containers after the build is
|
|||
complete, you must use `--rm=false`. This does not
|
||||
affect the build cache.
|
||||
|
||||
$ sudo docker build .
|
||||
$ docker build .
|
||||
Uploading context 18.829 MB
|
||||
Uploading context
|
||||
Step 0 : FROM busybox
|
||||
|
|
@ -691,7 +698,7 @@ affect the build cache.
|
|||
---> 99cc1ad10469
|
||||
Successfully built 99cc1ad10469
|
||||
$ echo ".git" > .dockerignore
|
||||
$ sudo docker build .
|
||||
$ docker build .
|
||||
Uploading context 6.76 MB
|
||||
Uploading context
|
||||
Step 0 : FROM busybox
|
||||
|
|
@ -705,25 +712,25 @@ This example shows the use of the `.dockerignore` file to exclude the `.git`
|
|||
directory from the context. Its effect can be seen in the changed size of the
|
||||
uploaded context.
|
||||
|
||||
$ sudo docker build -t vieux/apache:2.0 .
|
||||
$ docker build -t vieux/apache:2.0 .
|
||||
|
||||
This will build like the previous example, but it will then tag the
|
||||
resulting image. The repository name will be `vieux/apache`
|
||||
and the tag will be `2.0`
|
||||
|
||||
$ sudo docker build - < Dockerfile
|
||||
$ 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.
|
||||
|
||||
$ sudo docker build - < context.tar.gz
|
||||
$ docker build - < context.tar.gz
|
||||
|
||||
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
|
||||
$ docker build github.com/creack/docker-firefox
|
||||
|
||||
This will clone the GitHub repository and use the cloned repository as
|
||||
context. The Dockerfile at the root of the
|
||||
|
|
@ -731,21 +738,21 @@ repository is used as Dockerfile. Note that you
|
|||
can specify an arbitrary Git repository by using the `git://` or `git@`
|
||||
schema.
|
||||
|
||||
$ sudo docker build -f Dockerfile.debug .
|
||||
$ docker build -f Dockerfile.debug .
|
||||
|
||||
This will use a file called `Dockerfile.debug` for the build
|
||||
instructions instead of `Dockerfile`.
|
||||
|
||||
$ sudo docker build -f dockerfiles/Dockerfile.debug -t myapp_debug .
|
||||
$ sudo docker build -f dockerfiles/Dockerfile.prod -t myapp_prod .
|
||||
$ docker build -f dockerfiles/Dockerfile.debug -t myapp_debug .
|
||||
$ docker build -f dockerfiles/Dockerfile.prod -t myapp_prod .
|
||||
|
||||
The above commands will build the current build context (as specified by
|
||||
the `.`) twice, once using a debug version of a `Dockerfile` and once using
|
||||
a production version.
|
||||
|
||||
$ cd /home/me/myapp/some/dir/really/deep
|
||||
$ sudo docker build -f /home/me/myapp/dockerfiles/debug /home/me/myapp
|
||||
$ sudo docker build -f ../../../../dockerfiles/debug /home/me/myapp
|
||||
$ docker build -f /home/me/myapp/dockerfiles/debug /home/me/myapp
|
||||
$ docker build -f ../../../../dockerfiles/debug /home/me/myapp
|
||||
|
||||
These two `docker build` commands do the exact same thing. They both
|
||||
use the contents of the `debug` file instead of looking for a `Dockerfile`
|
||||
|
|
@ -788,27 +795,27 @@ Supported `Dockerfile` instructions: `ADD`|`CMD`|`ENTRYPOINT`|`ENV`|`EXPOSE`|`FR
|
|||
|
||||
#### Commit a container
|
||||
|
||||
$ sudo docker ps
|
||||
$ docker ps
|
||||
ID IMAGE COMMAND CREATED STATUS PORTS
|
||||
c3f279d17e0a ubuntu:12.04 /bin/bash 7 days ago Up 25 hours
|
||||
197387f1b436 ubuntu:12.04 /bin/bash 7 days ago Up 25 hours
|
||||
$ sudo docker commit c3f279d17e0a SvenDowideit/testimage:version3
|
||||
$ docker commit c3f279d17e0a SvenDowideit/testimage:version3
|
||||
f5283438590d
|
||||
$ sudo docker images | head
|
||||
$ docker images | head
|
||||
REPOSITORY TAG ID CREATED VIRTUAL SIZE
|
||||
SvenDowideit/testimage version3 f5283438590d 16 seconds ago 335.7 MB
|
||||
|
||||
#### Commit a container with new configurations
|
||||
|
||||
$ sudo docker ps
|
||||
$ docker ps
|
||||
ID IMAGE COMMAND CREATED STATUS PORTS
|
||||
c3f279d17e0a ubuntu:12.04 /bin/bash 7 days ago Up 25 hours
|
||||
197387f1b436 ubuntu:12.04 /bin/bash 7 days ago Up 25 hours
|
||||
$ sudo docker inspect -f "{{ .Config.Env }}" c3f279d17e0a
|
||||
$ docker inspect -f "{{ .Config.Env }}" c3f279d17e0a
|
||||
[HOME=/ PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin]
|
||||
$ sudo docker commit --change "ENV DEBUG true" c3f279d17e0a SvenDowideit/testimage:version3
|
||||
$ docker commit --change "ENV DEBUG true" c3f279d17e0a SvenDowideit/testimage:version3
|
||||
f5283438590d
|
||||
$ sudo docker inspect -f "{{ .Config.Env }}" f5283438590d
|
||||
$ docker inspect -f "{{ .Config.Env }}" f5283438590d
|
||||
[HOME=/ PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin DEBUG=true]
|
||||
|
||||
## cp
|
||||
|
|
@ -884,9 +891,9 @@ Please see the [run command](#run) section and the [Docker run reference](
|
|||
|
||||
#### Examples
|
||||
|
||||
$ sudo docker create -t -i fedora bash
|
||||
$ docker create -t -i fedora bash
|
||||
6d8af538ec541dd581ebc2a24153a28329acb5268abe5ef868c1f1a261221752
|
||||
$ sudo docker start -a -i 6d8af538ec5
|
||||
$ docker start -a -i 6d8af538ec5
|
||||
bash-4.2#
|
||||
|
||||
As of v1.4.0 container volumes are initialized during the `docker create`
|
||||
|
|
@ -934,7 +941,7 @@ There are 3 events that are listed in the `diff`:
|
|||
|
||||
For example:
|
||||
|
||||
$ sudo docker diff 7bb0e258aefe
|
||||
$ docker diff 7bb0e258aefe
|
||||
|
||||
C /dev
|
||||
A /dev/kmsg
|
||||
|
|
@ -991,13 +998,13 @@ You'll need two shells for this example.
|
|||
|
||||
**Shell 1: Listening for events:**
|
||||
|
||||
$ sudo docker events
|
||||
$ docker events
|
||||
|
||||
**Shell 2: Start and Stop containers:**
|
||||
|
||||
$ sudo docker start 4386fb97867d
|
||||
$ sudo docker stop 4386fb97867d
|
||||
$ sudo docker stop 7805c1d35632
|
||||
$ docker start 4386fb97867d
|
||||
$ docker stop 4386fb97867d
|
||||
$ docker stop 7805c1d35632
|
||||
|
||||
**Shell 1: (Again .. now showing events):**
|
||||
|
||||
|
|
@ -1009,20 +1016,20 @@ You'll need two shells for this example.
|
|||
|
||||
**Show events in the past from a specified time:**
|
||||
|
||||
$ sudo docker events --since 1378216169
|
||||
$ docker events --since 1378216169
|
||||
2014-03-10T17:42:14.999999999Z07:00 4386fb97867d: (from ubuntu-1:14.04) die
|
||||
2014-05-10T17:42:14.999999999Z07:00 4386fb97867d: (from ubuntu-1:14.04) stop
|
||||
2014-05-10T17:42:14.999999999Z07:00 7805c1d35632: (from redis:2.8) die
|
||||
2014-03-10T17:42:14.999999999Z07:00 7805c1d35632: (from redis:2.8) stop
|
||||
|
||||
$ sudo docker events --since '2013-09-03'
|
||||
$ docker events --since '2013-09-03'
|
||||
2014-09-03T17:42:14.999999999Z07:00 4386fb97867d: (from ubuntu-1:14.04) start
|
||||
2014-09-03T17:42:14.999999999Z07:00 4386fb97867d: (from ubuntu-1:14.04) die
|
||||
2014-05-10T17:42:14.999999999Z07:00 4386fb97867d: (from ubuntu-1:14.04) stop
|
||||
2014-05-10T17:42:14.999999999Z07:00 7805c1d35632: (from redis:2.8) die
|
||||
2014-09-03T17:42:14.999999999Z07:00 7805c1d35632: (from redis:2.8) stop
|
||||
|
||||
$ sudo docker events --since '2013-09-03T15:49:29'
|
||||
$ docker events --since '2013-09-03T15:49:29'
|
||||
2014-09-03T15:49:29.999999999Z07:00 4386fb97867d: (from ubuntu-1:14.04) die
|
||||
2014-05-10T17:42:14.999999999Z07:00 4386fb97867d: (from ubuntu-1:14.04) stop
|
||||
2014-05-10T17:42:14.999999999Z07:00 7805c1d35632: (from redis:2.8) die
|
||||
|
|
@ -1030,29 +1037,29 @@ You'll need two shells for this example.
|
|||
|
||||
**Filter events:**
|
||||
|
||||
$ sudo docker events --filter 'event=stop'
|
||||
$ docker events --filter 'event=stop'
|
||||
2014-05-10T17:42:14.999999999Z07:00 4386fb97867d: (from ubuntu-1:14.04) stop
|
||||
2014-09-03T17:42:14.999999999Z07:00 7805c1d35632: (from redis:2.8) stop
|
||||
|
||||
$ sudo docker events --filter 'image=ubuntu-1:14.04'
|
||||
$ docker events --filter 'image=ubuntu-1:14.04'
|
||||
2014-05-10T17:42:14.999999999Z07:00 4386fb97867d: (from ubuntu-1:14.04) start
|
||||
2014-05-10T17:42:14.999999999Z07:00 4386fb97867d: (from ubuntu-1:14.04) die
|
||||
2014-05-10T17:42:14.999999999Z07:00 4386fb97867d: (from ubuntu-1:14.04) stop
|
||||
|
||||
$ sudo docker events --filter 'container=7805c1d35632'
|
||||
$ docker events --filter 'container=7805c1d35632'
|
||||
2014-05-10T17:42:14.999999999Z07:00 7805c1d35632: (from redis:2.8) die
|
||||
2014-09-03T15:49:29.999999999Z07:00 7805c1d35632: (from redis:2.8) stop
|
||||
|
||||
$ sudo docker events --filter 'container=7805c1d35632' --filter 'container=4386fb97867d'
|
||||
$ docker events --filter 'container=7805c1d35632' --filter 'container=4386fb97867d'
|
||||
2014-09-03T15:49:29.999999999Z07:00 4386fb97867d: (from ubuntu-1:14.04) die
|
||||
2014-05-10T17:42:14.999999999Z07:00 4386fb97867d: (from ubuntu-1:14.04) stop
|
||||
2014-05-10T17:42:14.999999999Z07:00 7805c1d35632: (from redis:2.8) die
|
||||
2014-09-03T15:49:29.999999999Z07:00 7805c1d35632: (from redis:2.8) stop
|
||||
|
||||
$ sudo docker events --filter 'container=7805c1d35632' --filter 'event=stop'
|
||||
$ docker events --filter 'container=7805c1d35632' --filter 'event=stop'
|
||||
2014-09-03T15:49:29.999999999Z07:00 7805c1d35632: (from redis:2.8) stop
|
||||
|
||||
$ sudo docker events --filter 'container=container_1' --filter 'container=container_2'
|
||||
$ docker events --filter 'container=container_1' --filter 'container=container_2'
|
||||
2014-09-03T15:49:29.999999999Z07:00 4386fb97867d: (from ubuntu-1:14.04) die
|
||||
2014-05-10T17:42:14.999999999Z07:00 4386fb97867d: (from ubuntu-1:14.04) stop
|
||||
2014-05-10T17:42:14.999999999Z07:00 7805c1d35632: (from redis:2.8) die
|
||||
|
|
@ -1087,16 +1094,16 @@ If the container is paused, then the `docker exec` command will fail with an err
|
|||
|
||||
#### Examples
|
||||
|
||||
$ sudo docker run --name ubuntu_bash --rm -i -t ubuntu bash
|
||||
$ docker run --name ubuntu_bash --rm -i -t ubuntu bash
|
||||
|
||||
This will create a container named `ubuntu_bash` and start a Bash session.
|
||||
|
||||
$ sudo docker exec -d ubuntu_bash touch /tmp/execWorks
|
||||
$ docker exec -d ubuntu_bash touch /tmp/execWorks
|
||||
|
||||
This will create a new file `/tmp/execWorks` inside the running container
|
||||
`ubuntu_bash`, in the background.
|
||||
|
||||
$ sudo docker exec -it ubuntu_bash bash
|
||||
$ docker exec -it ubuntu_bash bash
|
||||
|
||||
This will create a new Bash session in the container `ubuntu_bash`.
|
||||
|
||||
|
|
@ -1112,11 +1119,11 @@ This will create a new Bash session in the container `ubuntu_bash`.
|
|||
|
||||
For example:
|
||||
|
||||
$ sudo docker export red_panda > latest.tar
|
||||
$ docker export red_panda > latest.tar
|
||||
|
||||
Or
|
||||
|
||||
$ sudo docker export --output="latest.tar" red_panda
|
||||
$ docker export --output="latest.tar" red_panda
|
||||
|
||||
> **Note:**
|
||||
> `docker export` does not export the contents of volumes associated with the
|
||||
|
|
@ -1138,7 +1145,7 @@ This will create a new Bash session in the container `ubuntu_bash`.
|
|||
|
||||
To see how the `docker:latest` image was built:
|
||||
|
||||
$ sudo docker history docker
|
||||
$ docker history docker
|
||||
IMAGE CREATED CREATED BY SIZE
|
||||
3e23a5875458790b7a806f95f7ec0d0b2a5c1659bfc899c89f939f6d5b8f7094 8 days ago /bin/sh -c #(nop) ENV LC_ALL=C.UTF-8 0 B
|
||||
8578938dd17054dce7993d21de79e96a037400e8d28e15e7290fea4f65128a36 8 days ago /bin/sh -c dpkg-reconfigure locales && locale-gen C.UTF-8 && /usr/sbin/update-locale LANG=C.UTF-8 1.245 MB
|
||||
|
|
@ -1178,7 +1185,7 @@ uses up the `VIRTUAL SIZE` listed only once.
|
|||
|
||||
#### Listing the most recently created images
|
||||
|
||||
$ sudo docker images | head
|
||||
$ docker images | head
|
||||
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
|
||||
<none> <none> 77af4d6b9913 19 hours ago 1.089 GB
|
||||
committ latest b6fa739cedf5 19 hours ago 1.089 GB
|
||||
|
|
@ -1193,7 +1200,7 @@ uses up the `VIRTUAL SIZE` listed only once.
|
|||
|
||||
#### Listing the full length image IDs
|
||||
|
||||
$ sudo docker images --no-trunc | head
|
||||
$ docker images --no-trunc | head
|
||||
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
|
||||
<none> <none> 77af4d6b9913e693e8d0b4b294fa62ade6054e6b2f1ffb617ac955dd63fb0182 19 hours ago 1.089 GB
|
||||
committest latest b6fa739cedf5ea12a620a439402b6004d057da800f91c7524b5086a5e4749c9f 19 hours ago 1.089 GB
|
||||
|
|
@ -1212,7 +1219,7 @@ called a `digest`. As long as the input used to generate the image is
|
|||
unchanged, the digest value is predictable. To list image digest values, use
|
||||
the `--digests` flag:
|
||||
|
||||
$ sudo docker images --digests | head
|
||||
$ docker images --digests | head
|
||||
REPOSITORY TAG DIGEST IMAGE ID CREATED VIRTUAL SIZE
|
||||
localhost:5000/test/busybox <none> sha256:cbbf2f9a99b47fc460d422812b6a5adff7dfee951d8fa2e4a98caa0382cfbdbf 4986bf8c1536 9 weeks ago 2.43 MB
|
||||
|
||||
|
|
@ -1232,7 +1239,7 @@ Current filters:
|
|||
|
||||
##### Untagged images
|
||||
|
||||
$ sudo docker images --filter "dangling=true"
|
||||
$ docker images --filter "dangling=true"
|
||||
|
||||
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
|
||||
<none> <none> 8abc22fbb042 4 weeks ago 0 B
|
||||
|
|
@ -1250,7 +1257,7 @@ By having this flag it allows for batch cleanup.
|
|||
|
||||
Ready for use by `docker rmi ...`, like:
|
||||
|
||||
$ sudo docker rmi $(sudo docker images -f "dangling=true" -q)
|
||||
$ docker rmi $(docker images -f "dangling=true" -q)
|
||||
|
||||
8abc22fbb042
|
||||
48e5f45168b9
|
||||
|
|
@ -1287,21 +1294,21 @@ Supported `Dockerfile` instructions: `CMD`, `ENTRYPOINT`, `ENV`, `EXPOSE`,
|
|||
|
||||
This will create a new untagged image.
|
||||
|
||||
$ sudo docker import http://example.com/exampleimage.tgz
|
||||
$ docker import http://example.com/exampleimage.tgz
|
||||
|
||||
**Import from a local file:**
|
||||
|
||||
Import to docker via pipe and `STDIN`.
|
||||
|
||||
$ cat exampleimage.tgz | sudo docker import - exampleimagelocal:new
|
||||
$ cat exampleimage.tgz | docker import - exampleimagelocal:new
|
||||
|
||||
**Import from a local directory:**
|
||||
|
||||
$ sudo tar -c . | sudo docker import - exampleimagedir
|
||||
$ sudo tar -c . | docker import - exampleimagedir
|
||||
|
||||
**Import from a local directory with new configurations:**
|
||||
|
||||
$ sudo tar -c . | sudo docker import --change "ENV DEBUG true" - exampleimagedir
|
||||
$ sudo tar -c . | docker import --change "ENV DEBUG true" - exampleimagedir
|
||||
|
||||
Note the `sudo` in this example – you must preserve
|
||||
the ownership of the files (especially root ownership) during the
|
||||
|
|
@ -1317,7 +1324,7 @@ tar, then the ownerships might not get preserved.
|
|||
|
||||
For example:
|
||||
|
||||
$ sudo docker -D info
|
||||
$ docker -D info
|
||||
Containers: 14
|
||||
Images: 52
|
||||
Storage Driver: aufs
|
||||
|
|
@ -1373,25 +1380,25 @@ describes all the details of the format.
|
|||
For the most part, you can pick out any field from the JSON in a fairly
|
||||
straightforward manner.
|
||||
|
||||
$ sudo docker inspect --format='{{.NetworkSettings.IPAddress}}' $INSTANCE_ID
|
||||
$ docker inspect --format='{{.NetworkSettings.IPAddress}}' $INSTANCE_ID
|
||||
|
||||
**Get an instance's MAC Address:**
|
||||
|
||||
For the most part, you can pick out any field from the JSON in a fairly
|
||||
straightforward manner.
|
||||
|
||||
$ sudo docker inspect --format='{{.NetworkSettings.MacAddress}}' $INSTANCE_ID
|
||||
$ docker inspect --format='{{.NetworkSettings.MacAddress}}' $INSTANCE_ID
|
||||
|
||||
**Get an instance's log path:**
|
||||
|
||||
$ sudo docker inspect --format='{{.LogPath}}' $INSTANCE_ID
|
||||
$ docker inspect --format='{{.LogPath}}' $INSTANCE_ID
|
||||
|
||||
**List All Port Bindings:**
|
||||
|
||||
One can loop over arrays and maps in the results to produce simple text
|
||||
output:
|
||||
|
||||
$ sudo docker inspect --format='{{range $p, $conf := .NetworkSettings.Ports}} {{$p}} -> {{(index $conf 0).HostPort}} {{end}}' $INSTANCE_ID
|
||||
$ docker inspect --format='{{range $p, $conf := .NetworkSettings.Ports}} {{$p}} -> {{(index $conf 0).HostPort}} {{end}}' $INSTANCE_ID
|
||||
|
||||
**Find a Specific Port Mapping:**
|
||||
|
||||
|
|
@ -1403,7 +1410,7 @@ numeric public port, you use `index` to find the specific port map, and
|
|||
then `index` 0 contains the first object inside of that. Then we ask for
|
||||
the `HostPort` field to get the public address.
|
||||
|
||||
$ sudo docker inspect --format='{{(index (index .NetworkSettings.Ports "8787/tcp") 0).HostPort}}' $INSTANCE_ID
|
||||
$ docker inspect --format='{{(index (index .NetworkSettings.Ports "8787/tcp") 0).HostPort}}' $INSTANCE_ID
|
||||
|
||||
**Get config:**
|
||||
|
||||
|
|
@ -1412,7 +1419,7 @@ the template language's custom `json` function does. The `.config`
|
|||
section contains complex JSON object, so to grab it as JSON, you use
|
||||
`json` to convert the configuration object into JSON.
|
||||
|
||||
$ sudo docker inspect --format='{{json .config}}' $INSTANCE_ID
|
||||
$ docker inspect --format='{{json .config}}' $INSTANCE_ID
|
||||
|
||||
## kill
|
||||
|
||||
|
|
@ -1436,14 +1443,14 @@ signal specified with option `--signal`.
|
|||
Loads a tarred repository from a file or the standard input stream.
|
||||
Restores both images and tags.
|
||||
|
||||
$ sudo docker images
|
||||
$ docker images
|
||||
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
|
||||
$ sudo docker load < busybox.tar
|
||||
$ sudo docker images
|
||||
$ docker load < busybox.tar
|
||||
$ docker images
|
||||
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
|
||||
busybox latest 769b9341d937 7 weeks ago 2.489 MB
|
||||
$ sudo docker load --input fedora.tar
|
||||
$ sudo docker images
|
||||
$ docker load --input fedora.tar
|
||||
$ docker images
|
||||
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
|
||||
busybox latest 769b9341d937 7 weeks ago 2.489 MB
|
||||
fedora rawhide 0d20aec6529d 7 weeks ago 387 MB
|
||||
|
|
@ -1466,7 +1473,7 @@ If you want to login to a self-hosted registry you can specify this by
|
|||
adding the server name.
|
||||
|
||||
example:
|
||||
$ sudo docker login localhost:8080
|
||||
$ docker login localhost:8080
|
||||
|
||||
## logout
|
||||
|
||||
|
|
@ -1477,7 +1484,7 @@ adding the server name.
|
|||
|
||||
For example:
|
||||
|
||||
$ sudo docker logout localhost:8080
|
||||
$ docker logout localhost:8080
|
||||
|
||||
## logs
|
||||
|
||||
|
|
@ -1531,17 +1538,17 @@ for further details.
|
|||
You can find out all the ports mapped by not specifying a `PRIVATE_PORT`, or
|
||||
just a specific mapping:
|
||||
|
||||
$ sudo docker ps test
|
||||
$ docker ps test
|
||||
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
|
||||
b650456536c7 busybox:latest top 54 minutes ago Up 54 minutes 0.0.0.0:1234->9876/tcp, 0.0.0.0:4321->7890/tcp test
|
||||
$ sudo docker port test
|
||||
$ docker port test
|
||||
7890/tcp -> 0.0.0.0:4321
|
||||
9876/tcp -> 0.0.0.0:1234
|
||||
$ sudo docker port test 7890/tcp
|
||||
$ docker port test 7890/tcp
|
||||
0.0.0.0:4321
|
||||
$ sudo docker port test 7890/udp
|
||||
$ docker port test 7890/udp
|
||||
2014/06/24 11:53:36 Error: No public port '7890/udp' published for test
|
||||
$ sudo docker port test 7890
|
||||
$ docker port test 7890
|
||||
0.0.0.0:4321
|
||||
|
||||
## ps
|
||||
|
|
@ -1562,7 +1569,7 @@ just a specific mapping:
|
|||
|
||||
Running `docker ps --no-trunc` showing 2 linked containers.
|
||||
|
||||
$ sudo docker ps
|
||||
$ docker ps
|
||||
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
|
||||
4c01db0b339c ubuntu:12.04 bash 17 seconds ago Up 16 seconds 3300-3310/tcp webapp
|
||||
d7886598dbe2 crosbymichael/redis:latest /redis-server --dir 33 minutes ago Up 33 minutes 6379/tcp redis,webapp/db
|
||||
|
|
@ -1585,7 +1592,7 @@ Current filters:
|
|||
|
||||
##### Successfully exited containers
|
||||
|
||||
$ sudo docker ps -a --filter 'exited=0'
|
||||
$ docker ps -a --filter 'exited=0'
|
||||
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
|
||||
ea09c3c82f6e registry:latest /srv/run.sh 2 weeks ago Exited (0) 2 weeks ago 127.0.0.1:5000->5000/tcp desperate_leakey
|
||||
106ea823fe4e fedora:latest /bin/sh -c 'bash -l' 2 weeks ago Exited (0) 2 weeks ago determined_albattani
|
||||
|
|
@ -1615,20 +1622,20 @@ a protocol specifier (`https://`, for example).
|
|||
To download a particular image, or set of images (i.e., a repository),
|
||||
use `docker pull`:
|
||||
|
||||
$ sudo docker pull debian
|
||||
$ docker pull debian
|
||||
# will pull the debian:latest image and its intermediate layers
|
||||
$ sudo docker pull debian:testing
|
||||
$ docker pull debian:testing
|
||||
# will pull the image named debian:testing and any intermediate
|
||||
# layers it is based on.
|
||||
$ sudo docker pull debian@sha256:cbbf2f9a99b47fc460d422812b6a5adff7dfee951d8fa2e4a98caa0382cfbdbf
|
||||
$ docker pull debian@sha256:cbbf2f9a99b47fc460d422812b6a5adff7dfee951d8fa2e4a98caa0382cfbdbf
|
||||
# will pull the image from the debian repository with the digest
|
||||
# sha256:cbbf2f9a99b47fc460d422812b6a5adff7dfee951d8fa2e4a98caa0382cfbdbf
|
||||
# and any intermediate layers it is based on.
|
||||
# (Typically the empty `scratch` image, a MAINTAINER layer,
|
||||
# and the un-tarred base).
|
||||
$ sudo docker pull --all-tags centos
|
||||
$ docker pull --all-tags centos
|
||||
# will pull all the images from the centos repository
|
||||
$ sudo docker pull registry.hub.docker.com/debian
|
||||
$ docker pull registry.hub.docker.com/debian
|
||||
# manually specifies the path to the default Docker registry. This could
|
||||
# be replaced with the path to a local registry to pull from another source.
|
||||
|
||||
|
|
@ -1669,19 +1676,19 @@ The `docker rename` command allows the container to be renamed to a different na
|
|||
|
||||
#### Examples
|
||||
|
||||
$ sudo docker rm /redis
|
||||
$ docker rm /redis
|
||||
/redis
|
||||
|
||||
This will remove the container referenced under the link
|
||||
`/redis`.
|
||||
|
||||
$ sudo docker rm --link /webapp/redis
|
||||
$ docker rm --link /webapp/redis
|
||||
/webapp/redis
|
||||
|
||||
This will remove the underlying link between `/webapp` and the `/redis`
|
||||
containers removing all network communication.
|
||||
|
||||
$ sudo docker rm --force redis
|
||||
$ docker rm --force redis
|
||||
redis
|
||||
|
||||
The main process inside the container referenced under the link `/redis` will receive
|
||||
|
|
@ -1709,37 +1716,37 @@ You can remove an image using its short or long ID, its tag, or its digest. If
|
|||
an image has one or more tag or digest reference, you must remove all of them
|
||||
before the image is removed.
|
||||
|
||||
$ sudo docker images
|
||||
$ docker images
|
||||
REPOSITORY TAG IMAGE ID CREATED SIZE
|
||||
test1 latest fd484f19954f 23 seconds ago 7 B (virtual 4.964 MB)
|
||||
test latest fd484f19954f 23 seconds ago 7 B (virtual 4.964 MB)
|
||||
test2 latest fd484f19954f 23 seconds ago 7 B (virtual 4.964 MB)
|
||||
|
||||
$ sudo docker rmi fd484f19954f
|
||||
$ docker rmi fd484f19954f
|
||||
Error: Conflict, cannot delete image fd484f19954f because it is tagged in multiple repositories, use -f to force
|
||||
2013/12/11 05:47:16 Error: failed to remove one or more images
|
||||
|
||||
$ sudo docker rmi test1
|
||||
$ docker rmi test1
|
||||
Untagged: test1:latest
|
||||
$ sudo docker rmi test2
|
||||
$ docker rmi test2
|
||||
Untagged: test2:latest
|
||||
|
||||
$ sudo docker images
|
||||
$ docker images
|
||||
REPOSITORY TAG IMAGE ID CREATED SIZE
|
||||
test latest fd484f19954f 23 seconds ago 7 B (virtual 4.964 MB)
|
||||
$ sudo docker rmi test
|
||||
$ docker rmi test
|
||||
Untagged: test:latest
|
||||
Deleted: fd484f19954f4920da7ff372b5067f5b7ddb2fd3830cecd17b96ea9e286ba5b8
|
||||
|
||||
An image pulled by digest has no tag associated with it:
|
||||
|
||||
$ sudo docker images --digests
|
||||
$ docker images --digests
|
||||
REPOSITORY TAG DIGEST IMAGE ID CREATED VIRTUAL SIZE
|
||||
localhost:5000/test/busybox <none> sha256:cbbf2f9a99b47fc460d422812b6a5adff7dfee951d8fa2e4a98caa0382cfbdbf 4986bf8c1536 9 weeks ago 2.43 MB
|
||||
|
||||
To remove an image using its digest:
|
||||
|
||||
$ sudo docker rmi localhost:5000/test/busybox@sha256:cbbf2f9a99b47fc460d422812b6a5adff7dfee951d8fa2e4a98caa0382cfbdbf
|
||||
$ docker rmi localhost:5000/test/busybox@sha256:cbbf2f9a99b47fc460d422812b6a5adff7dfee951d8fa2e4a98caa0382cfbdbf
|
||||
Untagged: localhost:5000/test/busybox@sha256:cbbf2f9a99b47fc460d422812b6a5adff7dfee951d8fa2e4a98caa0382cfbdbf
|
||||
Deleted: 4986bf8c15363d1c5d15512d5266f8777bfba4974ac56e3270e7760f6f0a8125
|
||||
Deleted: ea13149945cb6b1e746bf28032f02e9b5a793523481a0a18645fc77ad53c4ea2
|
||||
|
|
@ -1814,12 +1821,12 @@ and linking containers.
|
|||
|
||||
#### Examples
|
||||
|
||||
$ sudo docker run --name test -it debian
|
||||
$ docker run --name test -it debian
|
||||
$$ exit 13
|
||||
exit
|
||||
$ echo $?
|
||||
13
|
||||
$ sudo docker ps -a | grep test
|
||||
$ docker ps -a | grep test
|
||||
275c44472aeb debian:7 "/bin/bash" 26 seconds ago Exited (13) 17 seconds ago test
|
||||
|
||||
In this example, we are running `bash` interactively in the `debian:latest` image, and giving
|
||||
|
|
@ -1827,14 +1834,14 @@ the container the name `test`. We then quit `bash` by running `exit 13`, which m
|
|||
will have an exit code of `13`. This is then passed on to the caller of `docker run`, and
|
||||
is recorded in the `test` container metadata.
|
||||
|
||||
$ sudo docker run --cidfile /tmp/docker_test.cid ubuntu echo "test"
|
||||
$ docker run --cidfile /tmp/docker_test.cid ubuntu echo "test"
|
||||
|
||||
This will create a container and print `test` to the console. The `cidfile`
|
||||
flag makes Docker attempt to create a new file and write the container ID to it.
|
||||
If the file exists already, Docker will return an error. Docker will close this
|
||||
file when `docker run` exits.
|
||||
|
||||
$ sudo docker run -t -i --rm ubuntu bash
|
||||
$ docker run -t -i --rm ubuntu bash
|
||||
root@bc338942ef20:/# mount -t tmpfs none /mnt
|
||||
mount: permission denied
|
||||
|
||||
|
|
@ -1842,7 +1849,7 @@ This will *not* work, because by default, most potentially dangerous kernel
|
|||
capabilities are dropped; including `cap_sys_admin` (which is required to mount
|
||||
filesystems). However, the `--privileged` flag will allow it to run:
|
||||
|
||||
$ sudo docker run --privileged ubuntu bash
|
||||
$ docker run --privileged ubuntu bash
|
||||
root@50e3f57e16e6:/# mount -t tmpfs none /mnt
|
||||
root@50e3f57e16e6:/# df -h
|
||||
Filesystem Size Used Avail Use% Mounted on
|
||||
|
|
@ -1853,12 +1860,12 @@ 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.
|
||||
|
||||
$ sudo docker run -w /path/to/dir/ -i -t ubuntu pwd
|
||||
$ docker run -w /path/to/dir/ -i -t ubuntu pwd
|
||||
|
||||
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.
|
||||
|
||||
$ sudo docker run -v `pwd`:`pwd` -w `pwd` -i -t ubuntu pwd
|
||||
$ docker run -v `pwd`:`pwd` -w `pwd` -i -t ubuntu pwd
|
||||
|
||||
The `-v` flag mounts the current working directory into the container. The `-w`
|
||||
lets the command being executed inside the current working directory, by
|
||||
|
|
@ -1866,41 +1873,41 @@ 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.
|
||||
|
||||
$ sudo docker run -v /doesnt/exist:/foo -w /foo -i -t ubuntu bash
|
||||
$ docker run -v /doesnt/exist:/foo -w /foo -i -t ubuntu bash
|
||||
|
||||
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.
|
||||
|
||||
$ sudo docker run --read-only -v /icanwrite busybox touch /icanwrite here
|
||||
$ docker run --read-only -v /icanwrite busybox touch /icanwrite here
|
||||
|
||||
Volumes can be used in combination with `--read-only` to control where
|
||||
a container writes files. The `--read-only` flag mounts the container's root
|
||||
filesystem as read only prohibiting writes to locations other than the
|
||||
specified volumes for the container.
|
||||
|
||||
$ sudo docker run -t -i -v /var/run/docker.sock:/var/run/docker.sock -v ./static-docker:/usr/bin/docker busybox sh
|
||||
$ docker run -t -i -v /var/run/docker.sock:/var/run/docker.sock -v ./static-docker:/usr/bin/docker busybox sh
|
||||
|
||||
By bind-mounting the docker unix socket and statically linked docker
|
||||
binary (such as that provided by [https://get.docker.com](
|
||||
https://get.docker.com)), you give the container the full access to create and
|
||||
manipulate the host's Docker daemon.
|
||||
|
||||
$ sudo docker run -p 127.0.0.1:80:8080 ubuntu bash
|
||||
$ docker run -p 127.0.0.1:80:8080 ubuntu bash
|
||||
|
||||
This binds port `8080` of the container to port `80` on `127.0.0.1` of
|
||||
the host machine. The [Docker User Guide](/userguide/dockerlinks/)
|
||||
explains in detail how to manipulate ports in Docker.
|
||||
|
||||
$ sudo docker run --expose 80 ubuntu bash
|
||||
$ docker run --expose 80 ubuntu bash
|
||||
|
||||
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](/userguide/dockerlinks) explains in detail how to manipulate
|
||||
ports in Docker.
|
||||
|
||||
$ sudo docker run -e MYVAR1 --env MYVAR2=foo --env-file ./env.list ubuntu bash
|
||||
$ docker run -e MYVAR1 --env MYVAR2=foo --env-file ./env.list ubuntu bash
|
||||
|
||||
This sets environmental variables in the container. For illustration all three
|
||||
flags are shown here. Where `-e`, `--env` take an environment variable and
|
||||
|
|
@ -1917,7 +1924,7 @@ override variables as needed.
|
|||
|
||||
$ cat ./env.list
|
||||
TEST_FOO=BAR
|
||||
$ sudo docker run --env TEST_FOO="This is a test" --env-file ./env.list busybox env | grep TEST_FOO
|
||||
$ docker run --env TEST_FOO="This is a test" --env-file ./env.list busybox env | grep TEST_FOO
|
||||
TEST_FOO=This is a test
|
||||
|
||||
The `--env-file` flag takes a filename as an argument and expects each line
|
||||
|
|
@ -1944,11 +1951,11 @@ An example of a file passed with `--env-file`
|
|||
TEST_APP_DEST_PORT=8888
|
||||
TEST_PASSTHROUGH=howdy
|
||||
|
||||
$ sudo docker run --name console -t -i ubuntu bash
|
||||
$ docker run --name console -t -i ubuntu bash
|
||||
|
||||
A label is a a `key=value` pair that applies metadata to a container. To label a container with two labels:
|
||||
|
||||
$ sudo docker run -l my-label --label com.example.foo=bar ubuntu bash
|
||||
$ docker run -l my-label --label com.example.foo=bar ubuntu bash
|
||||
|
||||
The `my-label` key doesn't specify a value so the label defaults to an empty
|
||||
string(`""`). To add multiple labels, repeat the label flag (`-l` or `--label`).
|
||||
|
|
@ -1961,7 +1968,7 @@ Use the `--label-file` flag to load multiple labels from a file. Delimit each
|
|||
label in the file with an EOL mark. The example below loads labels from a
|
||||
labels file in the current directory:
|
||||
|
||||
$ sudo docker run --label-file ./labels ubuntu bash
|
||||
$ docker run --label-file ./labels ubuntu bash
|
||||
|
||||
The label-file format is similar to the format for loading environment
|
||||
variables. (Unlike environment variables, labels are not visislbe to processes
|
||||
|
|
@ -1980,7 +1987,7 @@ For additional information on working with labels, see [*Labels - custom
|
|||
metadata in Docker*](/userguide/labels-custom-metadata/) in the Docker User
|
||||
Guide.
|
||||
|
||||
$ sudo docker run --link /redis:redis --name console ubuntu bash
|
||||
$ docker run --link /redis:redis --name console ubuntu bash
|
||||
|
||||
The `--link` flag will link the container named `/redis` into the newly
|
||||
created container with the alias `redis`. The new container can access the
|
||||
|
|
@ -1988,7 +1995,7 @@ network and environment of the `redis` container via environment variables.
|
|||
The `--name` flag will assign the name `console` to the newly created
|
||||
container.
|
||||
|
||||
$ sudo docker run --volumes-from 777f7dc92da7 --volumes-from ba8c0c54f0f2:ro -i -t ubuntu pwd
|
||||
$ docker run --volumes-from 777f7dc92da7 --volumes-from ba8c0c54f0f2:ro -i -t ubuntu pwd
|
||||
|
||||
The `--volumes-from` flag mounts all the defined volumes from the referenced
|
||||
containers. Containers can be specified by repetitions of the `--volumes-from`
|
||||
|
|
@ -2000,18 +2007,18 @@ 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.
|
||||
|
||||
$ echo "test" | sudo docker run -i -a stdin ubuntu cat -
|
||||
$ echo "test" | 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's `STDIN`.
|
||||
|
||||
$ sudo docker run -a stderr ubuntu echo test
|
||||
$ 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`.
|
||||
|
||||
$ cat somefile | sudo docker run -i -a stdin mybuilder dobuild
|
||||
$ cat somefile | docker run -i -a stdin mybuilder dobuild
|
||||
|
||||
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
|
||||
|
|
@ -2019,7 +2026,7 @@ 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.
|
||||
|
||||
$ sudo docker run --device=/dev/sdc:/dev/xvdc --device=/dev/sdd --device=/dev/zero:/dev/nulo -i -t ubuntu ls -l /dev/{xvdc,sdd,nulo}
|
||||
$ docker run --device=/dev/sdc:/dev/xvdc --device=/dev/sdd --device=/dev/zero:/dev/nulo -i -t ubuntu ls -l /dev/{xvdc,sdd,nulo}
|
||||
brw-rw---- 1 root disk 8, 2 Feb 9 16:05 /dev/xvdc
|
||||
brw-rw---- 1 root disk 8, 3 Feb 9 16:05 /dev/sdd
|
||||
crw-rw-rw- 1 root root 1, 5 Feb 9 16:05 /dev/nulo
|
||||
|
|
@ -2035,19 +2042,19 @@ flag:
|
|||
|
||||
|
||||
```
|
||||
$ sudo docker run --device=/dev/sda:/dev/xvdc --rm -it ubuntu fdisk /dev/xvdc
|
||||
$ docker run --device=/dev/sda:/dev/xvdc --rm -it ubuntu fdisk /dev/xvdc
|
||||
|
||||
Command (m for help): q
|
||||
$ sudo docker run --device=/dev/sda:/dev/xvdc:r --rm -it ubuntu fdisk /dev/xvdc
|
||||
$ docker run --device=/dev/sda:/dev/xvdc:r --rm -it ubuntu fdisk /dev/xvdc
|
||||
You will not be able to write the partition table.
|
||||
|
||||
Command (m for help): q
|
||||
|
||||
$ sudo docker run --device=/dev/sda:/dev/xvdc --rm -it ubuntu fdisk /dev/xvdc
|
||||
$ docker run --device=/dev/sda:/dev/xvdc --rm -it ubuntu fdisk /dev/xvdc
|
||||
|
||||
Command (m for help): q
|
||||
|
||||
$ sudo docker run --device=/dev/sda:/dev/xvdc:m --rm -it ubuntu fdisk /dev/xvdc
|
||||
$ docker run --device=/dev/sda:/dev/xvdc:m --rm -it ubuntu fdisk /dev/xvdc
|
||||
fdisk: unable to open /dev/xvdc: Operation not permitted
|
||||
```
|
||||
|
||||
|
|
@ -2057,11 +2064,11 @@ flag:
|
|||
|
||||
**A complete example:**
|
||||
|
||||
$ sudo docker run -d --name static static-web-files sh
|
||||
$ sudo docker run -d --expose=8098 --name riak riakserver
|
||||
$ sudo docker run -d -m 100m -e DEVELOPMENT=1 -e BRANCH=example-code -v $(pwd):/app/bin:ro --name app appserver
|
||||
$ sudo docker run -d -p 1443:443 --dns=10.0.0.1 --dns-search=dev.org -v /var/log/httpd --volumes-from static --link riak --link app -h www.sven.dev.org --name web webserver
|
||||
$ sudo docker run -t -i --rm --volumes-from web -w /var/log/httpd busybox tail -f access.log
|
||||
$ docker run -d --name static static-web-files sh
|
||||
$ docker run -d --expose=8098 --name riak riakserver
|
||||
$ docker run -d -m 100m -e DEVELOPMENT=1 -e BRANCH=example-code -v $(pwd):/app/bin:ro --name app appserver
|
||||
$ docker run -d -p 1443:443 --dns=10.0.0.1 --dns-search=dev.org -v /var/log/httpd --volumes-from static --link riak --link app -h www.sven.dev.org --name web webserver
|
||||
$ docker run -t -i --rm --volumes-from web -w /var/log/httpd busybox tail -f access.log
|
||||
|
||||
This example shows five containers that might be set up to test a web
|
||||
application change:
|
||||
|
|
@ -2130,7 +2137,7 @@ Docker supports the following restart policies:
|
|||
</tbody>
|
||||
</table>
|
||||
|
||||
$ sudo docker run --restart=always redis
|
||||
$ docker run --restart=always redis
|
||||
|
||||
This will run the `redis` container with a restart policy of **always**
|
||||
so that if the container exits, Docker will restart it.
|
||||
|
|
@ -2202,18 +2209,18 @@ each argument provided.
|
|||
|
||||
It is used to create a backup that can then be used with `docker load`
|
||||
|
||||
$ sudo docker save busybox > busybox.tar
|
||||
$ docker save busybox > busybox.tar
|
||||
$ ls -sh busybox.tar
|
||||
2.7M busybox.tar
|
||||
$ sudo docker save --output busybox.tar busybox
|
||||
$ docker save --output busybox.tar busybox
|
||||
$ ls -sh busybox.tar
|
||||
2.7M busybox.tar
|
||||
$ sudo docker save -o fedora-all.tar fedora
|
||||
$ sudo docker save -o fedora-latest.tar fedora:latest
|
||||
$ docker save -o fedora-all.tar fedora
|
||||
$ docker save -o fedora-latest.tar fedora:latest
|
||||
|
||||
It is even useful to cherry-pick particular tags of an image repository
|
||||
|
||||
$ sudo docker save -o ubuntu.tar ubuntu:lucid ubuntu:saucy
|
||||
$ docker save -o ubuntu.tar ubuntu:lucid ubuntu:saucy
|
||||
|
||||
## search
|
||||
|
||||
|
|
@ -2253,7 +2260,7 @@ more details on finding shared images from the command line.
|
|||
|
||||
Running `docker stats` on multiple containers
|
||||
|
||||
$ sudo docker stats redis1 redis2
|
||||
$ docker stats redis1 redis2
|
||||
CONTAINER CPU % MEM USAGE/LIMIT MEM % NET I/O
|
||||
redis1 0.07% 796 KiB/64 MiB 1.21% 788 B/648 B
|
||||
redis2 0.07% 2.746 MiB/64 MiB 4.29% 1.266 KiB/648 B
|
||||
|
|
@ -2317,7 +2324,7 @@ for further details.
|
|||
Show the Docker version, API version, Git commit, Go version and OS/architecture
|
||||
of both Docker client and daemon. Example use:
|
||||
|
||||
$ sudo docker version
|
||||
$ docker version
|
||||
Client version: 1.5.0
|
||||
Client API version: 1.17
|
||||
Go version (client): go1.4.1
|
||||
|
|
|
|||
Loading…
Reference in New Issue