play with Docker

Posted on |

Docker networking

  • bridge: the default network driver, only in standalone containers; best when have multiple containers to communicate on the same host machine.

  • host: for standalone containers, the Docker host use the host machine’s networking directly; best when need no isolated from the host machine.

  • overlay: connect multi Docker containers, enable swarm services to communicate with each other, no OS-level routing; best when need containers running on different host machines to communicate.

  • none: disable all networking

the network base is open source project libnetwork

containers can communicate through hostname, or through DNS(the now Docker engine has default built-in DNS server), but in early days, can use external dns, e.g. Blowb

to host docker images, either pull to Docker Hub, or to create a private cloud by ownCloud, or docker save/export tools:

1
2
3
4
docker save -o /path/to/save/file  image | gzip
scp *.tar.gz  remote_user@remote_hostname
docker load *.tar.gz

running GUI apps in Docker

there is a benchmark GUI/openGL test in Linux glxgears. to test the host machine support ssh or container based apps, we can first do the following test: 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
sudo apt-get install mesa-utils
glxinfo 
glxgears
``` 
Docker by default is bash/text based, but `nvidia-docker` is a gui-supported Docker engine, which requires Nvidia OpenGL drivers and Nvidia Gpus of course. since the gpu hardware version and the docker engine version, please check the compatability at first. 
## remote hosted apps
	
* configure master and worker nodes communication by setting IP address in the same domain, and setting the master node IP address as the gateway IP address for all worker nodes, basically the master node will work as the swticher.
* install xserver-common,  xserver-utils, as Ubuntu by deafult doesn't have X-server. 
```shell
master:~/    ssh -X user@worker
worker:~/    DISPLAY=:0
worker:~/	   ./gui_app
  • for docker containers, there is also authority property need take care.

Dockfile

when the Docker container starts, usually we want to auto start a shell process, so by CMD or ENTRYPOINT defined in the Dockfile.

for the base images, e.g. Ubuntu, busybox, are used as the base for upper applications, usually will use CMD at the end of Dockerfile; but if the Docker container is specially for a certain application, it’s usually using ENTRYPOINT.

the last line of Ubuntu 16.04 Dockerfile:

CMD '/bin/bash'

usually in one Dockerfile, there is only one CMD or ENTRYPOINT, and it’s better written in exec format:

CMD ["executable", "param1", "param2"]

ENTRYPOINT ["executable", "param1", "param2"]

since in shell format: 

CMD exectuable, param1, param2

Docker will trigger /bin/sh first by default, if not define a shell. and this shell is always the first process in this Docker container, which sometimes is not what we expected.

when using both CMD and ENTRYPOINT in one Dockfile, the output will looks like append/pipe CMD command after ENTRYPOINT command.

a sample of Dockerfile: 

1
2
3
4
5
6
7
8
9
FROM <image>:[<tag>] [AS <name>]
ADD [--chown=<user>:<group>] <src> ... <dest>
ADD [" ", ... " "]
COPY <src> ... <dest>
RUN <command>
VOLUME /mount/name
CMD ["executable", "param1", "param2"]
CMD command par1 par2

from docker image to dockerfile

we can easily pull images from hub, but when we try to build some images directly, there is also way to get Dockfile from existing docker image: dfimage 

1
sudo docker pull chenzj/dfimage

mount host volume to container

either we can define in Dockerfile by VOLUME, which is create a volume name in the base image, or during runtime, docker run -v /host/volume/path:/container/volume/path, to bind a host volume to current container.