зеркало из https://github.com/microsoft/docker.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
Родитель
a4609a1dfb
Коммит
29d01b7dde
|
|
@ -31,7 +31,7 @@ A Dockerfile is similar to a Makefile.
|
|||
|
||||
# USAGE
|
||||
|
||||
sudo docker build .
|
||||
docker build .
|
||||
|
||||
-- Runs the steps and commits them, building a final image.
|
||||
The path to the source repository defines where to find the context of the
|
||||
|
|
@ -41,7 +41,7 @@ A Dockerfile is similar to a Makefile.
|
|||
daemon.
|
||||
|
||||
```
|
||||
sudo docker build -t repository/tag .
|
||||
docker build -t repository/tag .
|
||||
```
|
||||
|
||||
-- specifies a repository and tag at which to save the new image if the build
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@ Show the history of when and how an image was created.
|
|||
Only show numeric IDs. The default is *false*.
|
||||
|
||||
# EXAMPLES
|
||||
$ sudo docker history fedora
|
||||
$ docker history fedora
|
||||
IMAGE CREATED CREATED BY SIZE
|
||||
105182bb5e8b 5 days ago /bin/sh -c #(nop) ADD file:71356d2ad59aa3119d 372.7 MB
|
||||
73bd853d2ea5 13 days ago /bin/sh -c #(nop) MAINTAINER Lokesh Mandvekar 0 B
|
||||
|
|
|
|||
|
|
@ -24,11 +24,11 @@ Restores both images and tags.
|
|||
|
||||
# EXAMPLES
|
||||
|
||||
$ sudo docker images
|
||||
$ 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
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@ It is also possible to specify a non-default registry to pull from.
|
|||
# Note that if the image is previously downloaded then the status would be
|
||||
# 'Status: Image is up to date for fedora'
|
||||
|
||||
$ sudo docker pull fedora
|
||||
$ docker pull fedora
|
||||
Pulling repository fedora
|
||||
ad57ef8d78d7: Download complete
|
||||
105182bb5e8b: Download complete
|
||||
|
|
@ -38,7 +38,7 @@ It is also possible to specify a non-default registry to pull from.
|
|||
|
||||
Status: Downloaded newer image for fedora
|
||||
|
||||
$ sudo docker images
|
||||
$ docker images
|
||||
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
|
||||
fedora rawhide ad57ef8d78d7 5 days ago 359.3 MB
|
||||
fedora 20 105182bb5e8b 5 days ago 372.7 MB
|
||||
|
|
@ -49,7 +49,7 @@ It is also possible to specify a non-default registry to pull from.
|
|||
# Note that if the image is previously downloaded then the status would be
|
||||
# 'Status: Image is up to date for registry.hub.docker.com/fedora:20'
|
||||
|
||||
$ sudo docker pull registry.hub.docker.com/fedora:20
|
||||
$ docker pull registry.hub.docker.com/fedora:20
|
||||
Pulling repository fedora
|
||||
3f2fed40e4b0: Download complete
|
||||
511136ea3c5a: Download complete
|
||||
|
|
@ -57,7 +57,7 @@ It is also possible to specify a non-default registry to pull from.
|
|||
|
||||
Status: Downloaded newer image for registry.hub.docker.com/fedora:20
|
||||
|
||||
$ sudo docker images
|
||||
$ docker images
|
||||
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
|
||||
fedora 20 3f2fed40e4b0 4 days ago 372.7 MB
|
||||
|
||||
|
|
|
|||
|
|
@ -433,7 +433,7 @@ Host shows a shared memory segment with 7 pids attached, happens to be from http
|
|||
Now run a regular container, and it correctly does NOT see the shared memory segment from the host:
|
||||
|
||||
```
|
||||
$ sudo docker run -it shm ipcs -m
|
||||
$ docker run -it shm ipcs -m
|
||||
|
||||
------ Shared Memory Segments --------
|
||||
key shmid owner perms bytes nattch status
|
||||
|
|
@ -442,7 +442,7 @@ Now run a regular container, and it correctly does NOT see the shared memory seg
|
|||
Run a container with the new `--ipc=host` option, and it now sees the shared memory segment from the host httpd:
|
||||
|
||||
```
|
||||
$ sudo docker run -it --ipc=host shm ipcs -m
|
||||
$ docker run -it --ipc=host shm ipcs -m
|
||||
|
||||
------ Shared Memory Segments --------
|
||||
key shmid owner perms bytes nattch status
|
||||
|
|
@ -452,7 +452,7 @@ Testing `--ipc=container:CONTAINERID` mode:
|
|||
|
||||
Start a container with a program to create a shared memory segment:
|
||||
```
|
||||
sudo docker run -it shm bash
|
||||
$ docker run -it shm bash
|
||||
$ sudo shm/shm_server &
|
||||
$ sudo ipcs -m
|
||||
|
||||
|
|
@ -462,7 +462,7 @@ Start a container with a program to create a shared memory segment:
|
|||
```
|
||||
Create a 2nd container correctly shows no shared memory segment from 1st container:
|
||||
```
|
||||
$ sudo docker run shm ipcs -m
|
||||
$ docker run shm ipcs -m
|
||||
|
||||
------ Shared Memory Segments --------
|
||||
key shmid owner perms bytes nattch status
|
||||
|
|
@ -471,7 +471,7 @@ Create a 2nd container correctly shows no shared memory segment from 1st contain
|
|||
Create a 3rd container using the new --ipc=container:CONTAINERID option, now it shows the shared memory segment from the first:
|
||||
|
||||
```
|
||||
$ sudo docker run -it --ipc=container:ed735b2264ac shm ipcs -m
|
||||
$ docker run -it --ipc=container:ed735b2264ac shm ipcs -m
|
||||
$ sudo ipcs -m
|
||||
|
||||
------ Shared Memory Segments --------
|
||||
|
|
|
|||
|
|
@ -28,8 +28,8 @@ Stream to a file instead of STDOUT by using **-o**.
|
|||
Save all fedora repository images to a fedora-all.tar and save the latest
|
||||
fedora image to a fedora-latest.tar:
|
||||
|
||||
$ sudo docker save fedora > fedora-all.tar
|
||||
$ sudo docker save --output=fedora-latest.tar fedora:latest
|
||||
$ docker save fedora > fedora-all.tar
|
||||
$ docker save --output=fedora-latest.tar fedora:latest
|
||||
$ ls -sh fedora-all.tar
|
||||
721M fedora-all.tar
|
||||
$ ls -sh fedora-latest.tar
|
||||
|
|
|
|||
|
|
@ -41,7 +41,7 @@ is automated.
|
|||
Search the registry for the term 'fedora' and only display those images
|
||||
ranked 3 or higher:
|
||||
|
||||
$ sudo docker search -s 3 fedora
|
||||
$ docker search -s 3 fedora
|
||||
NAME DESCRIPTION STARS OFFICIAL AUTOMATED
|
||||
mattdm/fedora A basic Fedora image corresponding roughly... 50
|
||||
fedora (Semi) Official Fedora base image. 38
|
||||
|
|
@ -53,7 +53,7 @@ ranked 3 or higher:
|
|||
Search the registry for the term 'fedora' and only display automated images
|
||||
ranked 1 or higher:
|
||||
|
||||
$ sudo docker search -s 1 -t fedora
|
||||
$ docker search -s 1 -t fedora
|
||||
NAME DESCRIPTION STARS OFFICIAL AUTOMATED
|
||||
goldmann/wildfly A WildFly application server running on a ... 3 [OK]
|
||||
tutum/fedora-20 Fedora 20 image with SSH access. For the r... 1 [OK]
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ Display a live stream of one or more containers' resource usage statistics
|
|||
|
||||
Run **docker stats** with 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
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ Look up the running process of the container. ps-OPTION can be any of the
|
|||
|
||||
Run **docker top** with the ps option of -x:
|
||||
|
||||
$ sudo docker top 8601afda2b -x
|
||||
$ docker top 8601afda2b -x
|
||||
PID TTY STAT TIME COMMAND
|
||||
16623 ? Ss 0:00 sleep 99999
|
||||
|
||||
|
|
|
|||
|
|
@ -19,9 +19,9 @@ Block until a container stops, then print its exit code.
|
|||
|
||||
# EXAMPLES
|
||||
|
||||
$ sudo docker run -d fedora sleep 99
|
||||
$ docker run -d fedora sleep 99
|
||||
079b83f558a2bc52ecad6b2a5de13622d584e6bb1aea058c11b36511e85e7622
|
||||
$ sudo docker wait 079b83f558a2bc
|
||||
$ docker wait 079b83f558a2bc
|
||||
0
|
||||
|
||||
# HISTORY
|
||||
|
|
|
|||
|
|
@ -34,23 +34,23 @@ controlled entirely from the `docker run` parameters.
|
|||
|
||||
Start actual Redis server on one Docker host
|
||||
|
||||
big-server $ sudo docker run -d --name redis crosbymichael/redis
|
||||
big-server $ docker run -d --name redis crosbymichael/redis
|
||||
|
||||
Then add an ambassador linked to the Redis server, mapping a port to the
|
||||
outside world
|
||||
|
||||
big-server $ sudo docker run -d --link redis:redis --name redis_ambassador -p 6379:6379 svendowideit/ambassador
|
||||
big-server $ docker run -d --link redis:redis --name redis_ambassador -p 6379:6379 svendowideit/ambassador
|
||||
|
||||
On the other host, you can set up another ambassador setting environment
|
||||
variables for each remote port we want to proxy to the `big-server`
|
||||
|
||||
client-server $ sudo docker run -d --name redis_ambassador --expose 6379 -e REDIS_PORT_6379_TCP=tcp://192.168.1.52:6379 svendowideit/ambassador
|
||||
client-server $ docker run -d --name redis_ambassador --expose 6379 -e REDIS_PORT_6379_TCP=tcp://192.168.1.52:6379 svendowideit/ambassador
|
||||
|
||||
Then on the `client-server` host, you can use a Redis client container
|
||||
to talk to the remote Redis server, just by linking to the local Redis
|
||||
ambassador.
|
||||
|
||||
client-server $ sudo docker run -i -t --rm --link redis_ambassador:redis relateiq/redis-cli
|
||||
client-server $ docker run -i -t --rm --link redis_ambassador:redis relateiq/redis-cli
|
||||
redis 172.17.0.160:6379> ping
|
||||
PONG
|
||||
|
||||
|
|
@ -62,19 +62,19 @@ does automatically (with a tiny amount of `sed`)
|
|||
On the Docker host (192.168.1.52) that Redis will run on:
|
||||
|
||||
# start actual redis server
|
||||
$ sudo docker run -d --name redis crosbymichael/redis
|
||||
$ docker run -d --name redis crosbymichael/redis
|
||||
|
||||
# get a redis-cli container for connection testing
|
||||
$ sudo docker pull relateiq/redis-cli
|
||||
$ docker pull relateiq/redis-cli
|
||||
|
||||
# test the redis server by talking to it directly
|
||||
$ sudo docker run -t -i --rm --link redis:redis relateiq/redis-cli
|
||||
$ docker run -t -i --rm --link redis:redis relateiq/redis-cli
|
||||
redis 172.17.0.136:6379> ping
|
||||
PONG
|
||||
^D
|
||||
|
||||
# add redis ambassador
|
||||
$ sudo docker run -t -i --link redis:redis --name redis_ambassador -p 6379:6379 busybox sh
|
||||
$ docker run -t -i --link redis:redis --name redis_ambassador -p 6379:6379 busybox sh
|
||||
|
||||
In the `redis_ambassador` container, you can see the linked Redis
|
||||
containers `env`:
|
||||
|
|
@ -96,9 +96,9 @@ containers `env`:
|
|||
This environment is used by the ambassador `socat` script to expose Redis
|
||||
to the world (via the `-p 6379:6379` port mapping):
|
||||
|
||||
$ sudo docker rm redis_ambassador
|
||||
$ docker rm redis_ambassador
|
||||
$ sudo ./contrib/mkimage-unittest.sh
|
||||
$ sudo docker run -t -i --link redis:redis --name redis_ambassador -p 6379:6379 docker-ut sh
|
||||
$ docker run -t -i --link redis:redis --name redis_ambassador -p 6379:6379 docker-ut sh
|
||||
|
||||
$ socat TCP4-LISTEN:6379,fork,reuseaddr TCP4:172.17.0.136:6379
|
||||
|
||||
|
|
@ -107,14 +107,14 @@ Now ping the Redis server via the ambassador:
|
|||
Now go to a different server:
|
||||
|
||||
$ sudo ./contrib/mkimage-unittest.sh
|
||||
$ sudo docker run -t -i --expose 6379 --name redis_ambassador docker-ut sh
|
||||
$ docker run -t -i --expose 6379 --name redis_ambassador docker-ut sh
|
||||
|
||||
$ socat TCP4-LISTEN:6379,fork,reuseaddr TCP4:192.168.1.52:6379
|
||||
|
||||
And get the `redis-cli` image so we can talk over the ambassador bridge.
|
||||
|
||||
$ sudo docker pull relateiq/redis-cli
|
||||
$ sudo docker run -i -t --rm --link redis_ambassador:redis relateiq/redis-cli
|
||||
$ docker pull relateiq/redis-cli
|
||||
$ docker run -i -t --rm --link redis_ambassador:redis relateiq/redis-cli
|
||||
redis 172.17.0.160:6379> ping
|
||||
PONG
|
||||
|
||||
|
|
|
|||
|
|
@ -22,9 +22,9 @@ use to build Ubuntu images.
|
|||
It can be as simple as this to create an Ubuntu base image:
|
||||
|
||||
$ sudo debootstrap raring raring > /dev/null
|
||||
$ sudo tar -C raring -c . | sudo docker import - raring
|
||||
$ sudo tar -C raring -c . | docker import - raring
|
||||
a29c15f1bf7a
|
||||
$ sudo docker run raring cat /etc/lsb-release
|
||||
$ docker run raring cat /etc/lsb-release
|
||||
DISTRIB_ID=Ubuntu
|
||||
DISTRIB_RELEASE=13.04
|
||||
DISTRIB_CODENAME=raring
|
||||
|
|
|
|||
|
|
@ -4,26 +4,30 @@ page_keywords: Examples, Usage, basic commands, docker, documentation, examples
|
|||
|
||||
# First steps with Docker
|
||||
|
||||
## Check your Docker install
|
||||
|
||||
This guide assumes you have a working installation of Docker. To check
|
||||
your Docker install, run the following command:
|
||||
|
||||
# Check that you have a working install
|
||||
$ sudo docker info
|
||||
$ docker info
|
||||
|
||||
If you get `docker: command not found` or something like
|
||||
`/var/lib/docker/repositories: permission denied` you may have an
|
||||
incomplete Docker installation or insufficient privileges to access
|
||||
Docker on your machine.
|
||||
Docker on your machine. Please
|
||||
|
||||
Additionally, 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.
|
||||
|
||||
Please refer to [*Installation*](/installation)
|
||||
for installation instructions.
|
||||
|
||||
## Download a pre-built image
|
||||
|
||||
# Download an ubuntu image
|
||||
$ sudo docker pull ubuntu
|
||||
$ docker pull ubuntu
|
||||
|
||||
This will find the `ubuntu` image by name on
|
||||
[*Docker Hub*](/userguide/dockerrepos/#searching-for-images)
|
||||
|
|
@ -46,7 +50,7 @@ image cache.
|
|||
# To detach the tty without exiting the shell,
|
||||
# use the escape sequence Ctrl-p + Ctrl-q
|
||||
# note: This will continue to exist in a stopped state once exited (see "docker ps -a")
|
||||
$ sudo docker run -i -t ubuntu /bin/bash
|
||||
$ docker run -i -t ubuntu /bin/bash
|
||||
|
||||
## Bind Docker to another host/port or a Unix socket
|
||||
|
||||
|
|
@ -92,7 +96,7 @@ Run Docker in daemon mode:
|
|||
|
||||
Download an `ubuntu` image:
|
||||
|
||||
$ sudo docker -H :5555 pull ubuntu
|
||||
$ docker -H :5555 pull ubuntu
|
||||
|
||||
You can use multiple `-H`, for example, if you want to listen on both
|
||||
TCP and a Unix socket
|
||||
|
|
@ -100,60 +104,60 @@ TCP and a Unix socket
|
|||
# Run docker in daemon mode
|
||||
$ sudo <path to>/docker -H tcp://127.0.0.1:2375 -H unix:///var/run/docker.sock -d &
|
||||
# Download an ubuntu image, use default Unix socket
|
||||
$ sudo docker pull ubuntu
|
||||
$ docker pull ubuntu
|
||||
# OR use the TCP port
|
||||
$ sudo docker -H tcp://127.0.0.1:2375 pull ubuntu
|
||||
$ docker -H tcp://127.0.0.1:2375 pull ubuntu
|
||||
|
||||
## Starting a long-running worker process
|
||||
|
||||
# Start a very useful long-running process
|
||||
$ JOB=$(sudo docker run -d ubuntu /bin/sh -c "while true; do echo Hello world; sleep 1; done")
|
||||
$ JOB=$(docker run -d ubuntu /bin/sh -c "while true; do echo Hello world; sleep 1; done")
|
||||
|
||||
# Collect the output of the job so far
|
||||
$ sudo docker logs $JOB
|
||||
$ docker logs $JOB
|
||||
|
||||
# Kill the job
|
||||
$ sudo docker kill $JOB
|
||||
$ docker kill $JOB
|
||||
|
||||
## Listing containers
|
||||
|
||||
$ sudo docker ps # Lists only running containers
|
||||
$ sudo docker ps -a # Lists all containers
|
||||
$ docker ps # Lists only running containers
|
||||
$ docker ps -a # Lists all containers
|
||||
|
||||
## Controlling containers
|
||||
|
||||
# Start a new container
|
||||
$ JOB=$(sudo docker run -d ubuntu /bin/sh -c "while true; do echo Hello world; sleep 1; done")
|
||||
$ JOB=$(docker run -d ubuntu /bin/sh -c "while true; do echo Hello world; sleep 1; done")
|
||||
|
||||
# Stop the container
|
||||
$ sudo docker stop $JOB
|
||||
$ docker stop $JOB
|
||||
|
||||
# Start the container
|
||||
$ sudo docker start $JOB
|
||||
$ docker start $JOB
|
||||
|
||||
# Restart the container
|
||||
$ sudo docker restart $JOB
|
||||
$ docker restart $JOB
|
||||
|
||||
# SIGKILL a container
|
||||
$ sudo docker kill $JOB
|
||||
$ docker kill $JOB
|
||||
|
||||
# Remove a container
|
||||
$ sudo docker stop $JOB # Container must be stopped to remove it
|
||||
$ sudo docker rm $JOB
|
||||
$ docker stop $JOB # Container must be stopped to remove it
|
||||
$ docker rm $JOB
|
||||
|
||||
## Bind a service on a TCP port
|
||||
|
||||
# Bind port 4444 of this container, and tell netcat to listen on it
|
||||
$ JOB=$(sudo docker run -d -p 4444 ubuntu:12.10 /bin/nc -l 4444)
|
||||
$ JOB=$(docker run -d -p 4444 ubuntu:12.10 /bin/nc -l 4444)
|
||||
|
||||
# Which public port is NATed to my container?
|
||||
$ PORT=$(sudo docker port $JOB 4444 | awk -F: '{ print $2 }')
|
||||
$ PORT=$(docker port $JOB 4444 | awk -F: '{ print $2 }')
|
||||
|
||||
# Connect to the public port
|
||||
$ echo hello world | nc 127.0.0.1 $PORT
|
||||
|
||||
# Verify that the network connection worked
|
||||
$ echo "Daemon received: $(sudo docker logs $JOB)"
|
||||
$ echo "Daemon received: $(docker logs $JOB)"
|
||||
|
||||
## Committing (saving) a container state
|
||||
|
||||
|
|
@ -166,10 +170,10 @@ will be stored (as a diff). See which images you already have using the
|
|||
`docker images` command.
|
||||
|
||||
# Commit your container to a new named image
|
||||
$ sudo docker commit <container_id> <some_name>
|
||||
$ docker commit <container_id> <some_name>
|
||||
|
||||
# List your containers
|
||||
$ sudo docker images
|
||||
$ docker images
|
||||
|
||||
You now have an image state from which you can create new instances.
|
||||
|
||||
|
|
|
|||
|
|
@ -94,7 +94,7 @@ your image with the docker build command, e.g.,
|
|||
Start the container with `apache2` and `sshd` running and managed, forwarding
|
||||
a port to our SSH instance:
|
||||
|
||||
$ sudo docker run -p 127.0.0.1:222:22 -d managed_image "/usr/sbin/sshd" "/etc/init.d/apache2 start"
|
||||
$ docker run -p 127.0.0.1:222:22 -d managed_image "/usr/sbin/sshd" "/etc/init.d/apache2 start"
|
||||
|
||||
We now clearly see one of the benefits of the cfe-docker integration: it
|
||||
allows to start several processes as part of a normal `docker run` command.
|
||||
|
|
|
|||
|
|
@ -43,7 +43,7 @@ The next step is to pull a Docker image. For this, we have a resource:
|
|||
|
||||
This is equivalent to running:
|
||||
|
||||
$ sudo docker pull samalba/docker-registry
|
||||
$ docker pull samalba/docker-registry
|
||||
|
||||
There are attributes available to control how long the cookbook will
|
||||
allow for downloading (5 minute default).
|
||||
|
|
@ -68,7 +68,7 @@ managed by Docker.
|
|||
|
||||
This is equivalent to running the following command, but under upstart:
|
||||
|
||||
$ sudo docker run --detach=true --publish='5000:5000' --env='SETTINGS_FLAVOR=local' --volume='/mnt/docker:/docker-storage' samalba/docker-registry
|
||||
$ docker run --detach=true --publish='5000:5000' --env='SETTINGS_FLAVOR=local' --volume='/mnt/docker:/docker-storage' samalba/docker-registry
|
||||
|
||||
The resources will accept a single string or an array of values for any
|
||||
Docker flags that allow multiple values.
|
||||
|
|
|
|||
|
|
@ -723,7 +723,7 @@ the Internet.
|
|||
|
||||
# The network, as seen from a container
|
||||
|
||||
$ sudo docker run -i -t --rm base /bin/bash
|
||||
$ docker run -i -t --rm base /bin/bash
|
||||
|
||||
$$ ip addr show eth0
|
||||
24: eth0: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
|
||||
|
|
@ -908,14 +908,14 @@ Docker do all of the configuration:
|
|||
# At one shell, start a container and
|
||||
# leave its shell idle and running
|
||||
|
||||
$ sudo docker run -i -t --rm --net=none base /bin/bash
|
||||
$ docker run -i -t --rm --net=none base /bin/bash
|
||||
root@63f36fc01b5f:/#
|
||||
|
||||
# At another shell, learn the container process ID
|
||||
# and create its namespace entry in /var/run/netns/
|
||||
# for the "ip netns" command we will be using below
|
||||
|
||||
$ sudo docker inspect -f '{{.State.Pid}}' 63f36fc01b5f
|
||||
$ docker inspect -f '{{.State.Pid}}' 63f36fc01b5f
|
||||
2778
|
||||
$ pid=2778
|
||||
$ sudo mkdir -p /var/run/netns
|
||||
|
|
@ -1016,18 +1016,18 @@ the previous section to go something like this:
|
|||
|
||||
# Start up two containers in two terminal windows
|
||||
|
||||
$ sudo docker run -i -t --rm --net=none base /bin/bash
|
||||
$ docker run -i -t --rm --net=none base /bin/bash
|
||||
root@1f1f4c1f931a:/#
|
||||
|
||||
$ sudo docker run -i -t --rm --net=none base /bin/bash
|
||||
$ docker run -i -t --rm --net=none base /bin/bash
|
||||
root@12e343489d2f:/#
|
||||
|
||||
# Learn the container process IDs
|
||||
# and create their namespace entries
|
||||
|
||||
$ sudo docker inspect -f '{{.State.Pid}}' 1f1f4c1f931a
|
||||
$ docker inspect -f '{{.State.Pid}}' 1f1f4c1f931a
|
||||
2989
|
||||
$ sudo docker inspect -f '{{.State.Pid}}' 12e343489d2f
|
||||
$ docker inspect -f '{{.State.Pid}}' 12e343489d2f
|
||||
3004
|
||||
$ sudo mkdir -p /var/run/netns
|
||||
$ sudo ln -s /proc/2989/ns/net /var/run/netns/2989
|
||||
|
|
|
|||
|
|
@ -47,7 +47,7 @@ defined type which can be used like so:
|
|||
|
||||
This is equivalent to running:
|
||||
|
||||
$ sudo docker pull ubuntu
|
||||
$ docker pull ubuntu
|
||||
|
||||
Note that it will only be downloaded if an image of that name does not
|
||||
already exist. This is downloading a large binary so on first run can
|
||||
|
|
@ -71,7 +71,7 @@ managed by Docker.
|
|||
|
||||
This is equivalent to running the following command, but under upstart:
|
||||
|
||||
$ sudo docker run -d ubuntu /bin/sh -c "while true; do echo hello world; sleep 1; done"
|
||||
$ docker run -d ubuntu /bin/sh -c "while true; do echo hello world; sleep 1; done"
|
||||
|
||||
Run also contains a number of optional parameters:
|
||||
|
||||
|
|
|
|||
|
|
@ -29,11 +29,11 @@ There are two steps to set up and use a local registry mirror.
|
|||
You will need to pass the `--registry-mirror` option to your Docker daemon on
|
||||
startup:
|
||||
|
||||
sudo docker --registry-mirror=http://<my-docker-mirror-host> -d
|
||||
docker --registry-mirror=http://<my-docker-mirror-host> -d
|
||||
|
||||
For example, if your mirror is serving on `http://10.0.0.2:5000`, you would run:
|
||||
|
||||
sudo docker --registry-mirror=http://10.0.0.2:5000 -d
|
||||
docker --registry-mirror=http://10.0.0.2:5000 -d
|
||||
|
||||
**NOTE:**
|
||||
Depending on your local host setup, you may be able to add the
|
||||
|
|
@ -47,7 +47,7 @@ You will need to start a local registry mirror service. The
|
|||
functionality. For example, to run a local registry mirror that serves on
|
||||
port `5000` and mirrors the content at `registry-1.docker.io`:
|
||||
|
||||
sudo docker run -p 5000:5000 \
|
||||
docker run -p 5000:5000 \
|
||||
-e STANDALONE=false \
|
||||
-e MIRROR_SOURCE=https://registry-1.docker.io \
|
||||
-e MIRROR_SOURCE_INDEX=https://index.docker.io \
|
||||
|
|
@ -58,7 +58,7 @@ port `5000` and mirrors the content at `registry-1.docker.io`:
|
|||
With your mirror running, pull an image that you haven't pulled before (using
|
||||
`time` to time it):
|
||||
|
||||
$ time sudo docker pull node:latest
|
||||
$ time docker pull node:latest
|
||||
Pulling repository node
|
||||
[...]
|
||||
|
||||
|
|
@ -68,11 +68,11 @@ With your mirror running, pull an image that you haven't pulled before (using
|
|||
|
||||
Now, remove the image from your local machine:
|
||||
|
||||
$ sudo docker rmi node:latest
|
||||
$ docker rmi node:latest
|
||||
|
||||
Finally, re-pull the image:
|
||||
|
||||
$ time sudo docker pull node:latest
|
||||
$ time docker pull node:latest
|
||||
Pulling repository node
|
||||
[...]
|
||||
|
||||
|
|
|
|||
|
|
@ -91,13 +91,13 @@ launches.
|
|||
|
||||
We can now build our new image.
|
||||
|
||||
$ sudo docker build -t <yourname>/supervisord .
|
||||
$ docker build -t <yourname>/supervisord .
|
||||
|
||||
## Running our Supervisor container
|
||||
|
||||
Once We've got a built image we can launch a container from it.
|
||||
|
||||
$ sudo docker run -p 22 -p 80 -t -i <yourname>/supervisord
|
||||
$ docker run -p 22 -p 80 -t -i <yourname>/supervisord
|
||||
2013-11-25 18:53:22,312 CRIT Supervisor running as root (no user in config file)
|
||||
2013-11-25 18:53:22,312 WARN Included extra file "/etc/supervisor/conf.d/supervisord.conf" during parsing
|
||||
2013-11-25 18:53:22,342 INFO supervisord started with pid 1
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ page_keywords: Docker, docker, registry, accounts, plans, Dockerfile, Docker Hub
|
|||
You can `search` for all the publicly available repositories and images using
|
||||
Docker.
|
||||
|
||||
$ sudo docker search ubuntu
|
||||
$ docker search ubuntu
|
||||
|
||||
This will show you a list of the currently available repositories on the
|
||||
Docker Hub which match the provided keyword.
|
||||
|
|
|
|||
|
|
@ -35,16 +35,16 @@ Use the following Dockerfile:
|
|||
|
||||
To build the image using:
|
||||
|
||||
$ sudo docker build -t eg_apt_cacher_ng .
|
||||
$ docker build -t eg_apt_cacher_ng .
|
||||
|
||||
Then run it, mapping the exposed port to one on the host
|
||||
|
||||
$ sudo docker run -d -p 3142:3142 --name test_apt_cacher_ng eg_apt_cacher_ng
|
||||
$ docker run -d -p 3142:3142 --name test_apt_cacher_ng eg_apt_cacher_ng
|
||||
|
||||
To see the logfiles that are `tailed` in the default command, you can
|
||||
use:
|
||||
|
||||
$ sudo docker logs -f test_apt_cacher_ng
|
||||
$ docker logs -f test_apt_cacher_ng
|
||||
|
||||
To get your Debian-based containers to use the proxy, you can do one of
|
||||
three things
|
||||
|
|
@ -68,7 +68,7 @@ a local version of a common base:
|
|||
**Option 2** is good for testing, but will break other HTTP clients
|
||||
which obey `http_proxy`, such as `curl`, `wget` and others:
|
||||
|
||||
$ sudo docker run --rm -t -i -e http_proxy=http://dockerhost:3142/ debian bash
|
||||
$ docker run --rm -t -i -e http_proxy=http://dockerhost:3142/ debian bash
|
||||
|
||||
**Option 3** is the least portable, but there will be times when you
|
||||
might need to do it and you can do it from your `Dockerfile`
|
||||
|
|
@ -78,7 +78,7 @@ Apt-cacher-ng has some tools that allow you to manage the repository,
|
|||
and they can be used by leveraging the `VOLUME`
|
||||
instruction, and the image we built to run the service:
|
||||
|
||||
$ sudo docker run --rm -t -i --volumes-from test_apt_cacher_ng eg_apt_cacher_ng bash
|
||||
$ docker run --rm -t -i --volumes-from test_apt_cacher_ng eg_apt_cacher_ng bash
|
||||
|
||||
$$ /usr/lib/apt-cacher-ng/distkill.pl
|
||||
Scanning /var/cache/apt-cacher-ng, please wait...
|
||||
|
|
@ -102,6 +102,6 @@ instruction, and the image we built to run the service:
|
|||
Finally, clean up after your test by stopping and removing the
|
||||
container, and then removing the image.
|
||||
|
||||
$ sudo docker stop test_apt_cacher_ng
|
||||
$ sudo docker rm test_apt_cacher_ng
|
||||
$ sudo docker rmi eg_apt_cacher_ng
|
||||
$ docker stop test_apt_cacher_ng
|
||||
$ docker rm test_apt_cacher_ng
|
||||
$ docker rmi eg_apt_cacher_ng
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ different versions of CouchDB on the same data, etc.
|
|||
|
||||
Note that we're marking `/var/lib/couchdb` as a data volume.
|
||||
|
||||
$ COUCH1=$(sudo docker run -d -p 5984 -v /var/lib/couchdb shykes/couchdb:2013-05-03)
|
||||
$ COUCH1=$(docker run -d -p 5984 -v /var/lib/couchdb shykes/couchdb:2013-05-03)
|
||||
|
||||
## Add data to the first database
|
||||
|
||||
|
|
@ -24,19 +24,19 @@ We're assuming your Docker host is reachable at `localhost`. If not,
|
|||
replace `localhost` with the public IP of your Docker host.
|
||||
|
||||
$ HOST=localhost
|
||||
$ URL="http://$HOST:$(sudo docker port $COUCH1 5984 | grep -o '[1-9][0-9]*$')/_utils/"
|
||||
$ URL="http://$HOST:$(docker port $COUCH1 5984 | grep -o '[1-9][0-9]*$')/_utils/"
|
||||
$ echo "Navigate to $URL in your browser, and use the couch interface to add data"
|
||||
|
||||
## Create second database
|
||||
|
||||
This time, we're requesting shared access to `$COUCH1`'s volumes.
|
||||
|
||||
$ COUCH2=$(sudo docker run -d -p 5984 --volumes-from $COUCH1 shykes/couchdb:2013-05-03)
|
||||
$ COUCH2=$(docker run -d -p 5984 --volumes-from $COUCH1 shykes/couchdb:2013-05-03)
|
||||
|
||||
## Browse data on the second database
|
||||
|
||||
$ HOST=localhost
|
||||
$ URL="http://$HOST:$(sudo docker port $COUCH2 5984 | grep -o '[1-9][0-9]*$')/_utils/"
|
||||
$ URL="http://$HOST:$(docker port $COUCH2 5984 | grep -o '[1-9][0-9]*$')/_utils/"
|
||||
$ echo "Navigate to $URL in your browser. You should see the same data as in the first database"'!'
|
||||
|
||||
Congratulations, you are now running two Couchdb containers, completely
|
||||
|
|
|
|||
|
|
@ -100,9 +100,9 @@ With our `Dockerfile`, we can now build the MongoDB image using Docker. Unless
|
|||
experimenting, it is always a good practice to tag Docker images by passing the
|
||||
`--tag` option to `docker build` command.
|
||||
|
||||
# Format: sudo docker build --tag/-t <user-name>/<repository> .
|
||||
# Format: docker build --tag/-t <user-name>/<repository> .
|
||||
# Example:
|
||||
$ sudo docker build --tag my/repo .
|
||||
$ docker build --tag my/repo .
|
||||
|
||||
Once this command is issued, Docker will go through the `Dockerfile` and build
|
||||
the image. The final image will be tagged `my/repo`.
|
||||
|
|
@ -114,13 +114,13 @@ All Docker image repositories can be hosted and shared on
|
|||
you need to be logged-in.
|
||||
|
||||
# Log-in
|
||||
$ sudo docker login
|
||||
$ docker login
|
||||
Username:
|
||||
..
|
||||
|
||||
# Push the image
|
||||
# Format: sudo docker push <user-name>/<repository>
|
||||
$ sudo docker push my/repo
|
||||
# Format: docker push <user-name>/<repository>
|
||||
$ docker push my/repo
|
||||
The push refers to a repository [my/repo] (len: 1)
|
||||
Sending image list
|
||||
Pushing repository my/repo (1 tags)
|
||||
|
|
@ -132,16 +132,16 @@ Using the MongoDB image we created, we can run one or more MongoDB instances
|
|||
as daemon process(es).
|
||||
|
||||
# Basic way
|
||||
# Usage: sudo docker run --name <name for container> -d <user-name>/<repository>
|
||||
$ sudo docker run --name mongo_instance_001 -d my/repo
|
||||
# Usage: docker run --name <name for container> -d <user-name>/<repository>
|
||||
$ docker run --name mongo_instance_001 -d my/repo
|
||||
|
||||
# Dockerized MongoDB, lean and mean!
|
||||
# Usage: sudo docker run --name <name for container> -d <user-name>/<repository> --noprealloc --smallfiles
|
||||
$ sudo docker run --name mongo_instance_001 -d my/repo --noprealloc --smallfiles
|
||||
# Usage: docker run --name <name for container> -d <user-name>/<repository> --noprealloc --smallfiles
|
||||
$ docker run --name mongo_instance_001 -d my/repo --noprealloc --smallfiles
|
||||
|
||||
# Checking out the logs of a MongoDB container
|
||||
# Usage: sudo docker logs <name for container>
|
||||
$ sudo docker logs mongo_instance_001
|
||||
# Usage: docker logs <name for container>
|
||||
$ docker logs mongo_instance_001
|
||||
|
||||
# Playing with MongoDB
|
||||
# Usage: mongo --port <port you get from `docker ps`>
|
||||
|
|
|
|||
|
|
@ -125,11 +125,11 @@ Go to the directory that has your `Dockerfile` and run the following command
|
|||
to build a Docker image. The `-t` flag lets you tag your image so it's easier
|
||||
to find later using the `docker images` command:
|
||||
|
||||
$ sudo docker build -t <your username>/centos-node-hello .
|
||||
$ docker build -t <your username>/centos-node-hello .
|
||||
|
||||
Your image will now be listed by Docker:
|
||||
|
||||
$ sudo docker images
|
||||
$ docker images
|
||||
|
||||
# Example
|
||||
REPOSITORY TAG ID CREATED
|
||||
|
|
@ -142,15 +142,15 @@ Running your image with `-d` runs the container in detached mode, leaving the
|
|||
container running in the background. The `-p` flag redirects a public port to
|
||||
a private port in the container. Run the image you previously built:
|
||||
|
||||
$ sudo docker run -p 49160:8080 -d <your username>/centos-node-hello
|
||||
$ docker run -p 49160:8080 -d <your username>/centos-node-hello
|
||||
|
||||
Print the output of your app:
|
||||
|
||||
# Get container ID
|
||||
$ sudo docker ps
|
||||
$ docker ps
|
||||
|
||||
# Print app output
|
||||
$ sudo docker logs <container id>
|
||||
$ docker logs <container id>
|
||||
|
||||
# Example
|
||||
Running on http://localhost:8080
|
||||
|
|
@ -159,7 +159,7 @@ Print the output of your app:
|
|||
|
||||
To test your app, get the port of your app that Docker mapped:
|
||||
|
||||
$ sudo docker ps
|
||||
$ docker ps
|
||||
|
||||
# Example
|
||||
ID IMAGE COMMAND ... PORTS
|
||||
|
|
|
|||
|
|
@ -72,11 +72,11 @@ Start by creating a new `Dockerfile`:
|
|||
|
||||
Build an image from the Dockerfile assign it a name.
|
||||
|
||||
$ sudo docker build -t eg_postgresql .
|
||||
$ docker build -t eg_postgresql .
|
||||
|
||||
And run the PostgreSQL server container (in the foreground):
|
||||
|
||||
$ sudo docker run --rm -P --name pg_test eg_postgresql
|
||||
$ docker run --rm -P --name pg_test eg_postgresql
|
||||
|
||||
There are 2 ways to connect to the PostgreSQL server. We can use [*Link
|
||||
Containers*](/userguide/dockerlinks), or we can access it from our host
|
||||
|
|
@ -93,7 +93,7 @@ Containers can be linked to another container's ports directly using
|
|||
`docker run`. This will set a number of environment
|
||||
variables that can then be used to connect:
|
||||
|
||||
$ sudo docker run --rm -t -i --link pg_test:pg eg_postgresql bash
|
||||
$ docker run --rm -t -i --link pg_test:pg eg_postgresql bash
|
||||
|
||||
postgres@7ef98b1b7243:/$ psql -h $PG_PORT_5432_TCP_ADDR -p $PG_PORT_5432_TCP_PORT -d docker -U docker --password
|
||||
|
||||
|
|
@ -104,7 +104,7 @@ host-mapped port to test as well. You need to use `docker ps`
|
|||
to find out what local host port the container is mapped to
|
||||
first:
|
||||
|
||||
$ sudo docker ps
|
||||
$ docker ps
|
||||
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
|
||||
5e24362f27f6 eg_postgresql:latest /usr/lib/postgresql/ About an hour ago Up About an hour 0.0.0.0:49153->5432/tcp pg_test
|
||||
$ psql -h localhost -p 49153 -d docker -U docker --password
|
||||
|
|
@ -135,7 +135,7 @@ prompt, you can create a table and populate it.
|
|||
You can use the defined volumes to inspect the PostgreSQL log files and
|
||||
to backup your configuration and data:
|
||||
|
||||
$ sudo docker run --rm --volumes-from pg_test -t -i busybox sh
|
||||
$ docker run --rm --volumes-from pg_test -t -i busybox sh
|
||||
|
||||
/ # ls
|
||||
bin etc lib linuxrc mnt proc run sys usr
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ image.
|
|||
Next we build an image from our `Dockerfile`.
|
||||
Replace `<your username>` with your own user name.
|
||||
|
||||
$ sudo docker build -t <your username>/redis .
|
||||
$ docker build -t <your username>/redis .
|
||||
|
||||
## Run the service
|
||||
|
||||
|
|
@ -33,7 +33,7 @@ Importantly, we're not exposing any ports on our container. Instead
|
|||
we're going to use a container link to provide access to our Redis
|
||||
database.
|
||||
|
||||
$ sudo docker run --name redis -d <your username>/redis
|
||||
$ docker run --name redis -d <your username>/redis
|
||||
|
||||
## Create your web application container
|
||||
|
||||
|
|
@ -43,7 +43,7 @@ created with an alias of `db`. This will create a secure tunnel to the
|
|||
`redis` container and expose the Redis instance running inside that
|
||||
container to only this container.
|
||||
|
||||
$ sudo docker run --link redis:db -i -t ubuntu:14.04 /bin/bash
|
||||
$ docker run --link redis:db -i -t ubuntu:14.04 /bin/bash
|
||||
|
||||
Once inside our freshly created container we need to install Redis to
|
||||
get the `redis-cli` binary to test our connection.
|
||||
|
|
|
|||
|
|
@ -101,7 +101,7 @@ Populate it with the following program definitions:
|
|||
|
||||
Now you should be able to build a Docker image for Riak:
|
||||
|
||||
$ sudo docker build -t "<yourname>/riak" .
|
||||
$ docker build -t "<yourname>/riak" .
|
||||
|
||||
## Next steps
|
||||
|
||||
|
|
|
|||
|
|
@ -33,15 +33,15 @@ quick access to a test container.
|
|||
|
||||
Build the image using:
|
||||
|
||||
$ sudo docker build -t eg_sshd .
|
||||
$ docker build -t eg_sshd .
|
||||
|
||||
## Run a `test_sshd` container
|
||||
|
||||
Then run it. You can then use `docker port` to find out what host port
|
||||
the container's port 22 is mapped to:
|
||||
|
||||
$ sudo docker run -d -P --name test_sshd eg_sshd
|
||||
$ sudo docker port test_sshd 22
|
||||
$ docker run -d -P --name test_sshd eg_sshd
|
||||
$ docker port test_sshd 22
|
||||
0.0.0.0:49154
|
||||
|
||||
And now you can ssh as `root` on the container's IP address (you can find it
|
||||
|
|
@ -72,7 +72,7 @@ short script to do the same before you start `sshd -D` and then replace the
|
|||
Finally, clean up after your test by stopping and removing the
|
||||
container, and then removing the image.
|
||||
|
||||
$ sudo docker stop test_sshd
|
||||
$ sudo docker rm test_sshd
|
||||
$ sudo docker rmi eg_sshd
|
||||
$ docker stop test_sshd
|
||||
$ docker rm test_sshd
|
||||
$ docker rmi eg_sshd
|
||||
|
||||
|
|
|
|||
|
|
@ -198,7 +198,7 @@ then run.
|
|||
Either by using the `docker` binary or via the API, the Docker client tells the Docker
|
||||
daemon to run a container.
|
||||
|
||||
$ sudo docker run -i -t ubuntu /bin/bash
|
||||
$ docker run -i -t ubuntu /bin/bash
|
||||
|
||||
Let's break down this command. The Docker client is launched using the `docker`
|
||||
binary with the `run` option telling it to launch a new container. The bare
|
||||
|
|
|
|||
|
|
@ -115,7 +115,7 @@ supports:
|
|||
|
||||
It's possible to run:
|
||||
|
||||
$ sudo docker pull https://<registry>/repositories/samalba/busybox
|
||||
$ docker pull https://<registry>/repositories/samalba/busybox
|
||||
|
||||
In this case, Docker bypasses the Docker Hub. However the security is not
|
||||
guaranteed (in case Registry A is corrupted) because there won't be any
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ A Registry is a hosted service containing
|
|||
|
||||
The default registry can be accessed using a browser at
|
||||
[Docker Hub](https://hub.docker.com) or using the
|
||||
`sudo docker search` command.
|
||||
`docker search` command.
|
||||
|
||||
## Further Reading
|
||||
|
||||
|
|
|
|||
|
|
@ -13,11 +13,11 @@ server.
|
|||
Images can be associated with a repository (or multiple) by giving them
|
||||
an image name using one of three different commands:
|
||||
|
||||
1. At build time (e.g., `sudo docker build -t IMAGENAME`),
|
||||
1. At build time (e.g., `docker build -t IMAGENAME`),
|
||||
2. When committing a container (e.g.,
|
||||
`sudo docker commit CONTAINERID IMAGENAME`) or
|
||||
`docker commit CONTAINERID IMAGENAME`) or
|
||||
3. When tagging an image id with an image name (e.g.,
|
||||
`sudo docker tag IMAGEID IMAGENAME`).
|
||||
`docker tag IMAGEID IMAGENAME`).
|
||||
|
||||
A Fully Qualified Image Name (FQIN) can be made up of 3 parts:
|
||||
|
||||
|
|
|
|||
|
|
@ -42,7 +42,7 @@ going on in the world of Docker.
|
|||
You can also create a Docker Hub account via the command line with the
|
||||
`docker login` command.
|
||||
|
||||
$ sudo docker login
|
||||
$ docker login
|
||||
|
||||
### Confirm your email
|
||||
|
||||
|
|
@ -58,7 +58,7 @@ After you complete the confirmation process, you can login using the web console
|
|||
|
||||
Or via the command line with the `docker login` command:
|
||||
|
||||
$ sudo docker login
|
||||
$ docker login
|
||||
|
||||
Your Docker Hub account is now active and ready to use.
|
||||
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ including:
|
|||
Let's start with listing the images we have locally on our host. You can
|
||||
do this using the `docker images` command like so:
|
||||
|
||||
$ sudo docker images
|
||||
$ docker images
|
||||
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
|
||||
training/webapp latest fc77f57ad303 3 weeks ago 280.5 MB
|
||||
ubuntu 13.10 5e019ab7bf6d 4 weeks ago 180 MB
|
||||
|
|
@ -63,11 +63,11 @@ refer to a tagged image like so:
|
|||
|
||||
So when we run a container we refer to a tagged image like so:
|
||||
|
||||
$ sudo docker run -t -i ubuntu:14.04 /bin/bash
|
||||
$ docker run -t -i ubuntu:14.04 /bin/bash
|
||||
|
||||
If instead we wanted to run an Ubuntu 12.04 image we'd use:
|
||||
|
||||
$ sudo docker run -t -i ubuntu:12.04 /bin/bash
|
||||
$ docker run -t -i ubuntu:12.04 /bin/bash
|
||||
|
||||
If you don't specify a variant, for example you just use `ubuntu`, then Docker
|
||||
will default to using the `ubuntu:latest` image.
|
||||
|
|
@ -85,7 +85,7 @@ add some time to the launch of a container. If we want to pre-load an image we
|
|||
can download it using the `docker pull` command. Let's say we'd like to
|
||||
download the `centos` image.
|
||||
|
||||
$ sudo docker pull centos
|
||||
$ docker pull centos
|
||||
Pulling repository centos
|
||||
b7de3133ff98: Pulling dependent layers
|
||||
5cc9e91966f7: Pulling fs layer
|
||||
|
|
@ -99,7 +99,7 @@ We can see that each layer of the image has been pulled down and now we
|
|||
can run a container from this image and we won't have to wait to
|
||||
download the image.
|
||||
|
||||
$ sudo docker run -t -i centos /bin/bash
|
||||
$ docker run -t -i centos /bin/bash
|
||||
bash-4.1#
|
||||
|
||||
## Finding images
|
||||
|
|
@ -117,7 +117,7 @@ which to do our web application development. We can search for a suitable image
|
|||
by using the `docker search` command to find all the images that contain the
|
||||
term `sinatra`.
|
||||
|
||||
$ sudo docker search sinatra
|
||||
$ docker search sinatra
|
||||
NAME DESCRIPTION STARS OFFICIAL AUTOMATED
|
||||
training/sinatra Sinatra training image 0 [OK]
|
||||
marceldegraaf/sinatra Sinatra test app 0
|
||||
|
|
@ -152,11 +152,11 @@ prefixed with the user name, here `training`, of the user that created them.
|
|||
|
||||
We've identified a suitable image, `training/sinatra`, and now we can download it using the `docker pull` command.
|
||||
|
||||
$ sudo docker pull training/sinatra
|
||||
$ docker pull training/sinatra
|
||||
|
||||
The team can now use this image by running their own containers.
|
||||
|
||||
$ sudo docker run -t -i training/sinatra /bin/bash
|
||||
$ docker run -t -i training/sinatra /bin/bash
|
||||
root@a8cb6ce02d85:/#
|
||||
|
||||
## Creating our own images
|
||||
|
|
@ -174,7 +174,7 @@ update and create images.
|
|||
To update an image we first need to create a container from the image
|
||||
we'd like to update.
|
||||
|
||||
$ sudo docker run -t -i training/sinatra /bin/bash
|
||||
$ docker run -t -i training/sinatra /bin/bash
|
||||
root@0b2616b0e5a8:/#
|
||||
|
||||
> **Note:**
|
||||
|
|
@ -192,7 +192,7 @@ Now we have a container with the change we want to make. We can then
|
|||
commit a copy of this container to an image using the `docker commit`
|
||||
command.
|
||||
|
||||
$ sudo docker commit -m "Added json gem" -a "Kate Smith" \
|
||||
$ docker commit -m "Added json gem" -a "Kate Smith" \
|
||||
0b2616b0e5a8 ouruser/sinatra:v2
|
||||
4f177bd27a9ff0f6dc2a830403925b5360bfe0b93d476f7fc3231110e7f71b1c
|
||||
|
||||
|
|
@ -215,7 +215,7 @@ the image: `v2`.
|
|||
We can then look at our new `ouruser/sinatra` image using the `docker images`
|
||||
command.
|
||||
|
||||
$ sudo docker images
|
||||
$ docker images
|
||||
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
|
||||
training/sinatra latest 5bc342fa0b91 10 hours ago 446.7 MB
|
||||
ouruser/sinatra v2 3c59e02ddd1a 10 hours ago 446.7 MB
|
||||
|
|
@ -223,7 +223,7 @@ command.
|
|||
|
||||
To use our new image to create a container we can then:
|
||||
|
||||
$ sudo docker run -t -i ouruser/sinatra:v2 /bin/bash
|
||||
$ docker run -t -i ouruser/sinatra:v2 /bin/bash
|
||||
root@78e82f680994:/#
|
||||
|
||||
### Building an image from a `Dockerfile`
|
||||
|
|
@ -273,7 +273,7 @@ Sinatra gem.
|
|||
|
||||
Now let's take our `Dockerfile` and use the `docker build` command to build an image.
|
||||
|
||||
$ sudo docker build -t ouruser/sinatra:v2 .
|
||||
$ docker build -t ouruser/sinatra:v2 .
|
||||
Sending build context to Docker daemon 2.048 kB
|
||||
Sending build context to Docker daemon
|
||||
Step 0 : FROM ubuntu:14.04
|
||||
|
|
@ -467,7 +467,7 @@ containers will get removed to clean things up.
|
|||
|
||||
We can then create a container from our new image.
|
||||
|
||||
$ sudo docker run -t -i ouruser/sinatra:v2 /bin/bash
|
||||
$ docker run -t -i ouruser/sinatra:v2 /bin/bash
|
||||
root@8196968dac35:/#
|
||||
|
||||
> **Note:**
|
||||
|
|
@ -489,14 +489,14 @@ You can also add a tag to an existing image after you commit or build it. We
|
|||
can do this using the `docker tag` command. Let's add a new tag to our
|
||||
`ouruser/sinatra` image.
|
||||
|
||||
$ sudo docker tag 5db5f8471261 ouruser/sinatra:devel
|
||||
$ docker tag 5db5f8471261 ouruser/sinatra:devel
|
||||
|
||||
The `docker tag` command takes the ID of the image, here `5db5f8471261`, and our
|
||||
user name, the repository name and the new tag.
|
||||
|
||||
Let's see our new tag using the `docker images` command.
|
||||
|
||||
$ sudo docker images ouruser/sinatra
|
||||
$ docker images ouruser/sinatra
|
||||
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
|
||||
ouruser/sinatra latest 5db5f8471261 11 hours ago 446.7 MB
|
||||
ouruser/sinatra devel 5db5f8471261 11 hours ago 446.7 MB
|
||||
|
|
@ -509,7 +509,7 @@ Hub](https://hub.docker.com) using the `docker push` command. This
|
|||
allows you to share it with others, either publicly, or push it into [a
|
||||
private repository](https://registry.hub.docker.com/plans/).
|
||||
|
||||
$ sudo docker push ouruser/sinatra
|
||||
$ docker push ouruser/sinatra
|
||||
The push refers to a repository [ouruser/sinatra] (len: 1)
|
||||
Sending image list
|
||||
Pushing repository ouruser/sinatra (3 tags)
|
||||
|
|
@ -523,7 +523,7 @@ containers](
|
|||
|
||||
Let's delete the `training/sinatra` image as we don't need it anymore.
|
||||
|
||||
$ sudo docker rmi training/sinatra
|
||||
$ docker rmi training/sinatra
|
||||
Untagged: training/sinatra:latest
|
||||
Deleted: 5bc342fa0b91cabf65246837015197eecfa24b2213ed6a51a8974ae250fedd8d
|
||||
Deleted: ed0fffdcdae5eb2c3a55549857a8be7fc8bc4241fb19ad714364cbfd7a56b22f
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ application inside a container takes a single command: `docker run`.
|
|||
|
||||
Let's try it now.
|
||||
|
||||
$ sudo docker run ubuntu:14.04 /bin/echo 'Hello world'
|
||||
$ docker run ubuntu:14.04 /bin/echo 'Hello world'
|
||||
Hello world
|
||||
|
||||
And you just launched your first container!
|
||||
|
|
@ -53,7 +53,7 @@ only run as long as the command you specify is active. Here, as soon as
|
|||
Let's try the `docker run` command again, this time specifying a new
|
||||
command to run in our container.
|
||||
|
||||
$ sudo docker run -t -i ubuntu:14.04 /bin/bash
|
||||
$ docker run -t -i ubuntu:14.04 /bin/bash
|
||||
root@af8bae53bdd3:/#
|
||||
|
||||
Here we've again specified the `docker run` command and launched an
|
||||
|
|
@ -98,7 +98,7 @@ like most of the applications we're probably going to run with Docker.
|
|||
|
||||
Again we can do this with the `docker run` command:
|
||||
|
||||
$ sudo docker run -d ubuntu:14.04 /bin/sh -c "while true; do echo hello world; sleep 1; done"
|
||||
$ docker run -d ubuntu:14.04 /bin/sh -c "while true; do echo hello world; sleep 1; done"
|
||||
1e5535038e285177d5214659a068137486f96ee5c2e85a4ac52dc83f2ebe4147
|
||||
|
||||
Wait, what? Where's our "hello world" output? Let's look at what we've run here.
|
||||
|
|
@ -135,7 +135,7 @@ do that with the `docker ps` command. The `docker ps` command queries
|
|||
the Docker daemon for information about all the containers it knows
|
||||
about.
|
||||
|
||||
$ sudo docker ps
|
||||
$ docker ps
|
||||
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
|
||||
1e5535038e28 ubuntu:14.04 /bin/sh -c 'while tr 2 minutes ago Up 1 minute insane_babbage
|
||||
|
||||
|
|
@ -155,7 +155,7 @@ Okay, so we now know it's running. But is it doing what we asked it to do? To se
|
|||
we're going to look inside the container using the `docker logs`
|
||||
command. Let's use the container name Docker assigned.
|
||||
|
||||
$ sudo docker logs insane_babbage
|
||||
$ docker logs insane_babbage
|
||||
hello world
|
||||
hello world
|
||||
hello world
|
||||
|
|
@ -171,7 +171,7 @@ Now we've established we can create our own containers let's tidy up
|
|||
after ourselves and stop our daemonized container. To do this we use the
|
||||
`docker stop` command.
|
||||
|
||||
$ sudo docker stop insane_babbage
|
||||
$ docker stop insane_babbage
|
||||
insane_babbage
|
||||
|
||||
The `docker stop` command tells Docker to politely stop the running
|
||||
|
|
@ -180,7 +180,7 @@ has just stopped.
|
|||
|
||||
Let's check it worked with the `docker ps` command.
|
||||
|
||||
$ sudo docker ps
|
||||
$ docker ps
|
||||
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
|
||||
|
||||
Excellent. Our container has been stopped.
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ container linking.
|
|||
In [the Using Docker section](/userguide/usingdocker), you created a
|
||||
container that ran a Python Flask application:
|
||||
|
||||
$ sudo docker run -d -P training/webapp python app.py
|
||||
$ docker run -d -P training/webapp python app.py
|
||||
|
||||
> **Note:**
|
||||
> Containers have an internal network and an IP address
|
||||
|
|
@ -30,14 +30,14 @@ any network port inside it to a random high port within an *ephemeral port
|
|||
range* on your Docker host. Next, when `docker ps` was run, you saw that port
|
||||
5000 in the container was bound to port 49155 on the host.
|
||||
|
||||
$ sudo docker ps nostalgic_morse
|
||||
$ docker ps nostalgic_morse
|
||||
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
|
||||
bc533791f3f5 training/webapp:latest python app.py 5 seconds ago Up 2 seconds 0.0.0.0:49155->5000/tcp nostalgic_morse
|
||||
|
||||
You also saw how you can bind a container's ports to a specific port using
|
||||
the `-p` flag:
|
||||
|
||||
$ sudo docker run -d -p 5000:5000 training/webapp python app.py
|
||||
$ docker run -d -p 5000:5000 training/webapp python app.py
|
||||
|
||||
And you saw why this isn't such a great idea because it constrains you to
|
||||
only one container on that specific port.
|
||||
|
|
@ -47,7 +47,7 @@ default the `-p` flag will bind the specified port to all interfaces on
|
|||
the host machine. But you can also specify a binding to a specific
|
||||
interface, for example only to the `localhost`.
|
||||
|
||||
$ sudo docker run -d -p 127.0.0.1:5000:5000 training/webapp python app.py
|
||||
$ docker run -d -p 127.0.0.1:5000:5000 training/webapp python app.py
|
||||
|
||||
This would bind port 5000 inside the container to port 5000 on the
|
||||
`localhost` or `127.0.0.1` interface on the host machine.
|
||||
|
|
@ -55,18 +55,18 @@ This would bind port 5000 inside the container to port 5000 on the
|
|||
Or, to bind port 5000 of the container to a dynamic port but only on the
|
||||
`localhost`, you could use:
|
||||
|
||||
$ sudo docker run -d -p 127.0.0.1::5000 training/webapp python app.py
|
||||
$ docker run -d -p 127.0.0.1::5000 training/webapp python app.py
|
||||
|
||||
You can also bind UDP ports by adding a trailing `/udp`. For example:
|
||||
|
||||
$ sudo docker run -d -p 127.0.0.1:5000:5000/udp training/webapp python app.py
|
||||
$ docker run -d -p 127.0.0.1:5000:5000/udp training/webapp python app.py
|
||||
|
||||
You also learned about the useful `docker port` shortcut which showed us the
|
||||
current port bindings. This is also useful for showing you specific port
|
||||
configurations. For example, if you've bound the container port to the
|
||||
`localhost` on the host machine, then the `docker port` output will reflect that.
|
||||
|
||||
$ sudo docker port nostalgic_morse 5000
|
||||
$ docker port nostalgic_morse 5000
|
||||
127.0.0.1:49155
|
||||
|
||||
> **Note:**
|
||||
|
|
@ -98,19 +98,19 @@ yourself. This naming provides two useful functions:
|
|||
|
||||
You can name your container by using the `--name` flag, for example:
|
||||
|
||||
$ sudo docker run -d -P --name web training/webapp python app.py
|
||||
$ docker run -d -P --name web training/webapp python app.py
|
||||
|
||||
This launches a new container and uses the `--name` flag to
|
||||
name the container `web`. You can see the container's name using the
|
||||
`docker ps` command.
|
||||
|
||||
$ sudo docker ps -l
|
||||
$ docker ps -l
|
||||
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
|
||||
aed84ee21bde training/webapp:latest python app.py 12 hours ago Up 2 seconds 0.0.0.0:49154->5000/tcp web
|
||||
|
||||
You can also use `docker inspect` to return the container's name.
|
||||
|
||||
$ sudo docker inspect -f "{{ .Name }}" aed84ee21bde
|
||||
$ docker inspect -f "{{ .Name }}" aed84ee21bde
|
||||
/web
|
||||
|
||||
> **Note:**
|
||||
|
|
@ -129,7 +129,7 @@ source container and a recipient container. The recipient can then access select
|
|||
about the source. To create a link, you use the `--link` flag. First, create a new
|
||||
container, this time one containing a database.
|
||||
|
||||
$ sudo docker run -d --name db training/postgres
|
||||
$ docker run -d --name db training/postgres
|
||||
|
||||
This creates a new container called `db` from the `training/postgres`
|
||||
image, which contains a PostgreSQL database.
|
||||
|
|
@ -137,11 +137,11 @@ image, which contains a PostgreSQL database.
|
|||
Now, you need to delete the `web` container you created previously so you can replace it
|
||||
with a linked one:
|
||||
|
||||
$ sudo docker rm -f web
|
||||
$ docker rm -f web
|
||||
|
||||
Now, create a new `web` container and link it with your `db` container.
|
||||
|
||||
$ sudo docker run -d -P --name web --link db:db training/webapp python app.py
|
||||
$ docker run -d -P --name web --link db:db training/webapp python app.py
|
||||
|
||||
This will link the new `web` container with the `db` container you created
|
||||
earlier. The `--link` flag takes the form:
|
||||
|
|
@ -153,7 +153,7 @@ alias for the link name. You'll see how that alias gets used shortly.
|
|||
|
||||
Next, inspect your linked containers with `docker inspect`:
|
||||
|
||||
$ sudo docker inspect -f "{{ .HostConfig.Links }}" web
|
||||
$ docker inspect -f "{{ .HostConfig.Links }}" web
|
||||
[/db:/web/db]
|
||||
|
||||
You can see that the `web` container is now linked to the `db` container
|
||||
|
|
@ -239,7 +239,7 @@ Returning back to our database example, you can run the `env`
|
|||
command to list the specified container's environment variables.
|
||||
|
||||
```
|
||||
$ sudo docker run --rm --name web2 --link db:db training/webapp env
|
||||
$ docker run --rm --name web2 --link db:db training/webapp env
|
||||
. . .
|
||||
DB_NAME=/web2/db
|
||||
DB_PORT=tcp://172.17.0.5:5432
|
||||
|
|
@ -276,7 +276,7 @@ In addition to the environment variables, Docker adds a host entry for the
|
|||
source container to the `/etc/hosts` file. Here's an entry for the `web`
|
||||
container:
|
||||
|
||||
$ sudo docker run -t -i --rm --link db:webdb training/webapp /bin/bash
|
||||
$ docker run -t -i --rm --link db:webdb training/webapp /bin/bash
|
||||
root@aed84ee21bde:/opt/webapp# cat /etc/hosts
|
||||
172.17.0.7 aed84ee21bde
|
||||
. . .
|
||||
|
|
@ -314,9 +314,9 @@ If you restart the source container, the linked containers `/etc/hosts` files
|
|||
will be automatically updated with the source container's new IP address,
|
||||
allowing linked communication to continue.
|
||||
|
||||
$ sudo docker restart db
|
||||
$ docker restart db
|
||||
db
|
||||
$ sudo docker run -t -i --rm --link db:db training/webapp /bin/bash
|
||||
$ docker run -t -i --rm --link db:db training/webapp /bin/bash
|
||||
root@aed84ee21bde:/opt/webapp# cat /etc/hosts
|
||||
172.17.0.7 aed84ee21bde
|
||||
. . .
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ Typically, you'll want to start by creating an account on Docker Hub (if you hav
|
|||
already) and logging in. You can create your account directly on
|
||||
[Docker Hub](https://hub.docker.com/account/signup/), or by running:
|
||||
|
||||
$ sudo docker login
|
||||
$ docker login
|
||||
|
||||
This will prompt you for a user name, which will become the public namespace for your
|
||||
public repositories.
|
||||
|
|
@ -45,7 +45,7 @@ You can search the [Docker Hub](https://hub.docker.com) registry via its search
|
|||
interface or by using the command line interface. Searching can find images by image
|
||||
name, user name, or description:
|
||||
|
||||
$ sudo docker search centos
|
||||
$ docker search centos
|
||||
NAME DESCRIPTION STARS OFFICIAL TRUSTED
|
||||
centos Official CentOS 6 Image as of 12 April 2014 88
|
||||
tianon/centos CentOS 5 and 6, created using rinse instea... 21
|
||||
|
|
@ -60,7 +60,7 @@ repository from the image name.
|
|||
|
||||
Once you've found the image you want, you can download it with `docker pull <imagename>`:
|
||||
|
||||
$ sudo docker pull centos
|
||||
$ docker pull centos
|
||||
Pulling repository centos
|
||||
0b443ba03958: Download complete
|
||||
539c0211cd76: Download complete
|
||||
|
|
@ -86,7 +86,7 @@ or committed your container to a named image as we saw
|
|||
|
||||
Now you can push this repository to the registry designated by its name or tag.
|
||||
|
||||
$ sudo docker push yourname/newimage
|
||||
$ docker push yourname/newimage
|
||||
|
||||
The image will then be uploaded and available for use by your team-mates and/or the
|
||||
community.
|
||||
|
|
|
|||
|
|
@ -44,7 +44,7 @@ You can add a data volume to a container using the `-v` flag with the
|
|||
to mount multiple data volumes. Let's mount a single volume now in our web
|
||||
application container.
|
||||
|
||||
$ sudo docker run -d -P --name web -v /webapp training/webapp python app.py
|
||||
$ docker run -d -P --name web -v /webapp training/webapp python app.py
|
||||
|
||||
This will create a new volume inside a container at `/webapp`.
|
||||
|
||||
|
|
@ -86,7 +86,7 @@ directory from your Docker daemon's host into a container.
|
|||
> `docker run -v /c/Users/<path>:/<container path ...` (Windows). All other paths
|
||||
> come from the Boot2Docker virtual machine's filesystem.
|
||||
|
||||
$ sudo docker run -d -P --name web -v /src/webapp:/opt/webapp training/webapp python app.py
|
||||
$ docker run -d -P --name web -v /src/webapp:/opt/webapp training/webapp python app.py
|
||||
|
||||
This will mount the host directory, `/src/webapp`, into the container at
|
||||
`/opt/webapp`.
|
||||
|
|
@ -111,7 +111,7 @@ create it for you.
|
|||
Docker defaults to a read-write volume but we can also mount a directory
|
||||
read-only.
|
||||
|
||||
$ sudo docker run -d -P --name web -v /src/webapp:/opt/webapp:ro training/webapp python app.py
|
||||
$ docker run -d -P --name web -v /src/webapp:/opt/webapp:ro training/webapp python app.py
|
||||
|
||||
Here we've mounted the same `/src/webapp` directory but we've added the `ro`
|
||||
option to specify that the mount should be read-only.
|
||||
|
|
@ -121,7 +121,7 @@ option to specify that the mount should be read-only.
|
|||
The `-v` flag can also be used to mount a single file - instead of *just*
|
||||
directories - from the host machine.
|
||||
|
||||
$ sudo docker run --rm -it -v ~/.bash_history:/.bash_history ubuntu /bin/bash
|
||||
$ docker run --rm -it -v ~/.bash_history:/.bash_history ubuntu /bin/bash
|
||||
|
||||
This will drop you into a bash shell in a new container, you will have your bash
|
||||
history from the host and when you exit the container, the host will have the
|
||||
|
|
@ -145,15 +145,15 @@ Let's create a new named container with a volume to share.
|
|||
While this container doesn't run an application, it reuses the `training/postgres`
|
||||
image so that all containers are using layers in common, saving disk space.
|
||||
|
||||
$ sudo docker create -v /dbdata --name dbdata training/postgres /bin/true
|
||||
$ docker create -v /dbdata --name dbdata training/postgres /bin/true
|
||||
|
||||
You can then use the `--volumes-from` flag to mount the `/dbdata` volume in another container.
|
||||
|
||||
$ sudo docker run -d --volumes-from dbdata --name db1 training/postgres
|
||||
$ docker run -d --volumes-from dbdata --name db1 training/postgres
|
||||
|
||||
And another:
|
||||
|
||||
$ sudo docker run -d --volumes-from dbdata --name db2 training/postgres
|
||||
$ docker run -d --volumes-from dbdata --name db2 training/postgres
|
||||
|
||||
In this case, if the `postgres` image contained a directory called `/dbdata`
|
||||
then mounting the volumes from the `dbdata` container hides the
|
||||
|
|
@ -166,7 +166,7 @@ volumes from multiple containers.
|
|||
You can also extend the chain by mounting the volume that came from the
|
||||
`dbdata` container in yet another container via the `db1` or `db2` containers.
|
||||
|
||||
$ sudo docker run -d --name db3 --volumes-from db1 training/postgres
|
||||
$ docker run -d --name db3 --volumes-from db1 training/postgres
|
||||
|
||||
If you remove containers that mount volumes, including the initial `dbdata`
|
||||
container, or the subsequent containers `db1` and `db2`, the volumes will not
|
||||
|
|
@ -189,7 +189,7 @@ backups, restores or migrations. We do this by using the
|
|||
`--volumes-from` flag to create a new container that mounts that volume,
|
||||
like so:
|
||||
|
||||
$ sudo docker run --volumes-from dbdata -v $(pwd):/backup ubuntu tar cvf /backup/backup.tar /dbdata
|
||||
$ docker run --volumes-from dbdata -v $(pwd):/backup ubuntu tar cvf /backup/backup.tar /dbdata
|
||||
|
||||
Here we've launched a new container and mounted the volume from the
|
||||
`dbdata` container. We've then mounted a local host directory as
|
||||
|
|
@ -201,11 +201,11 @@ we'll be left with a backup of our `dbdata` volume.
|
|||
You could then restore it to the same container, or another that you've made
|
||||
elsewhere. Create a new container.
|
||||
|
||||
$ sudo docker run -v /dbdata --name dbdata2 ubuntu /bin/bash
|
||||
$ docker run -v /dbdata --name dbdata2 ubuntu /bin/bash
|
||||
|
||||
Then un-tar the backup file in the new container's data volume.
|
||||
|
||||
$ sudo docker run --volumes-from dbdata2 -v $(pwd):/backup busybox tar xvf /backup/backup.tar
|
||||
$ docker run --volumes-from dbdata2 -v $(pwd):/backup busybox tar xvf /backup/backup.tar
|
||||
|
||||
You can use the techniques above to automate backup, migration and
|
||||
restore testing using your preferred tools.
|
||||
|
|
|
|||
|
|
@ -27,12 +27,12 @@ flags and arguments.
|
|||
|
||||
# Usage: [sudo] docker [command] [flags] [arguments] ..
|
||||
# Example:
|
||||
$ sudo docker run -i -t ubuntu /bin/bash
|
||||
$ docker run -i -t ubuntu /bin/bash
|
||||
|
||||
Let's see this in action by using the `docker version` command to return
|
||||
version information on the currently installed Docker client and daemon.
|
||||
|
||||
$ sudo docker version
|
||||
$ docker version
|
||||
|
||||
This command will not only provide you the version of Docker client and
|
||||
daemon you are using, but also the version of Go (the programming
|
||||
|
|
@ -54,7 +54,7 @@ language powering Docker).
|
|||
We can see all of the commands available to us with the Docker client by
|
||||
running the `docker` binary without any options.
|
||||
|
||||
$ sudo docker
|
||||
$ docker
|
||||
|
||||
You will see a list of all currently available commands.
|
||||
|
||||
|
|
@ -71,12 +71,12 @@ You can also zoom in and review the usage for specific Docker commands.
|
|||
Try typing Docker followed with a `[command]` to see the usage for that
|
||||
command:
|
||||
|
||||
$ sudo docker attach
|
||||
$ docker attach
|
||||
Help output . . .
|
||||
|
||||
Or you can also pass the `--help` flag to the `docker` binary.
|
||||
|
||||
$ sudo docker attach --help
|
||||
$ docker attach --help
|
||||
|
||||
This will display the help text and all available flags:
|
||||
|
||||
|
|
@ -102,7 +102,7 @@ Docker.
|
|||
For our web application we're going to run a Python Flask application.
|
||||
Let's start with a `docker run` command.
|
||||
|
||||
$ sudo docker run -d -P training/webapp python app.py
|
||||
$ docker run -d -P training/webapp python app.py
|
||||
|
||||
Let's review what our command did. We've specified two flags: `-d` and
|
||||
`-P`. We've already seen the `-d` flag which tells Docker to run the
|
||||
|
|
@ -125,7 +125,7 @@ Lastly, we've specified a command for our container to run: `python app.py`. Thi
|
|||
|
||||
Now let's see our running container using the `docker ps` command.
|
||||
|
||||
$ sudo docker ps -l
|
||||
$ docker ps -l
|
||||
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
|
||||
bc533791f3f5 training/webapp:latest python app.py 5 seconds ago Up 2 seconds 0.0.0.0:49155->5000/tcp nostalgic_morse
|
||||
|
||||
|
|
@ -160,7 +160,7 @@ to a high port (from *ephemeral port range* which typically ranges from 32768
|
|||
to 61000) on the local Docker host. We can also bind Docker containers to
|
||||
specific ports using the `-p` flag, for example:
|
||||
|
||||
$ sudo docker run -d -p 5000:5000 training/webapp python app.py
|
||||
$ docker run -d -p 5000:5000 training/webapp python app.py
|
||||
|
||||
This would map port 5000 inside our container to port 5000 on our local
|
||||
host. You might be asking about now: why wouldn't we just want to always
|
||||
|
|
@ -196,7 +196,7 @@ Docker has a useful shortcut we can use: `docker port`. To use `docker port` we
|
|||
specify the ID or name of our container and then the port for which we need the
|
||||
corresponding public-facing port.
|
||||
|
||||
$ sudo docker port nostalgic_morse 5000
|
||||
$ docker port nostalgic_morse 5000
|
||||
0.0.0.0:49155
|
||||
|
||||
In this case we've looked up what port is mapped externally to port 5000 inside
|
||||
|
|
@ -207,7 +207,7 @@ the container.
|
|||
Let's also find out a bit more about what's happening with our application and
|
||||
use another of the commands we've learnt, `docker logs`.
|
||||
|
||||
$ sudo docker logs -f nostalgic_morse
|
||||
$ docker logs -f nostalgic_morse
|
||||
* Running on http://0.0.0.0:5000/
|
||||
10.0.2.2 - - [23/May/2014 20:16:31] "GET / HTTP/1.1" 200 -
|
||||
10.0.2.2 - - [23/May/2014 20:16:31] "GET /favicon.ico HTTP/1.1" 404 -
|
||||
|
|
@ -222,7 +222,7 @@ the application running on port 5000 and the access log entries for it.
|
|||
In addition to the container's logs we can also examine the processes
|
||||
running inside it using the `docker top` command.
|
||||
|
||||
$ sudo docker top nostalgic_morse
|
||||
$ docker top nostalgic_morse
|
||||
PID USER COMMAND
|
||||
854 root python app.py
|
||||
|
||||
|
|
@ -235,7 +235,7 @@ Lastly, we can take a low-level dive into our Docker container using the
|
|||
`docker inspect` command. It returns a JSON hash of useful configuration
|
||||
and status information about Docker containers.
|
||||
|
||||
$ sudo docker inspect nostalgic_morse
|
||||
$ docker inspect nostalgic_morse
|
||||
|
||||
Let's see a sample of that JSON output.
|
||||
|
||||
|
|
@ -255,7 +255,7 @@ Let's see a sample of that JSON output.
|
|||
We can also narrow down the information we want to return by requesting a
|
||||
specific element, for example to return the container's IP address we would:
|
||||
|
||||
$ sudo docker inspect -f '{{ .NetworkSettings.IPAddress }}' nostalgic_morse
|
||||
$ docker inspect -f '{{ .NetworkSettings.IPAddress }}' nostalgic_morse
|
||||
172.17.0.5
|
||||
|
||||
## Stopping our Web Application Container
|
||||
|
|
@ -263,13 +263,13 @@ specific element, for example to return the container's IP address we would:
|
|||
Okay we've seen web application working. Now let's stop it using the
|
||||
`docker stop` command and the name of our container: `nostalgic_morse`.
|
||||
|
||||
$ sudo docker stop nostalgic_morse
|
||||
$ docker stop nostalgic_morse
|
||||
nostalgic_morse
|
||||
|
||||
We can now use the `docker ps` command to check if the container has
|
||||
been stopped.
|
||||
|
||||
$ sudo docker ps -l
|
||||
$ docker ps -l
|
||||
|
||||
## Restarting our Web Application Container
|
||||
|
||||
|
|
@ -278,7 +278,7 @@ developer needs the container back. From here you have two choices: you
|
|||
can create a new container or restart the old one. Let's look at
|
||||
starting our previous container back up.
|
||||
|
||||
$ sudo docker start nostalgic_morse
|
||||
$ docker start nostalgic_morse
|
||||
nostalgic_morse
|
||||
|
||||
Now quickly run `docker ps -l` again to see the running container is
|
||||
|
|
@ -294,7 +294,7 @@ responds.
|
|||
Your colleague has let you know that they've now finished with the container
|
||||
and won't need it again. So let's remove it using the `docker rm` command.
|
||||
|
||||
$ sudo docker rm nostalgic_morse
|
||||
$ docker rm nostalgic_morse
|
||||
Error: Impossible to remove a running container, please stop it first or use -f
|
||||
2014/05/24 08:12:56 Error: failed to remove one or more containers
|
||||
|
||||
|
|
@ -302,9 +302,9 @@ What happened? We can't actually remove a running container. This protects
|
|||
you from accidentally removing a running container you might need. Let's try
|
||||
this again by stopping the container first.
|
||||
|
||||
$ sudo docker stop nostalgic_morse
|
||||
$ docker stop nostalgic_morse
|
||||
nostalgic_morse
|
||||
$ sudo docker rm nostalgic_morse
|
||||
$ docker rm nostalgic_morse
|
||||
nostalgic_morse
|
||||
|
||||
And now our container is stopped and deleted.
|
||||
|
|
|
|||
Загрузка…
Ссылка в новой задаче