Docker

Docker is a tool that allows applications inside sandboxed system environments called containers. It allows the user to reliably build a system environment including all required dependencies for an application independent of the host system.

Docker provides similar functionality as chroot or BSD jails but with extra services that simplifies configuring, deploying, and maintaining/orchestrating containers.

Docker containers are not virtual machines; applications run natively on the host's kernel.

Installation

Install docker using your package manager and then start the service.

On a Fedora distro (https://docs.docker.com/engine/installation/linux/docker-ce/fedora/#install-using-the-repository):

# dnf config-manager --add-repo  https://download.docker.com/linux/fedora/docker-ce.repo
# dnf install docker-ce
# systemctl start docker

If installed properly, the docker hello-world command should work without issue.

# docker run hello-world

To play with docker, you will need to run things as root or be part of a group that has access to docker's socket.

See more here: https://docs.docker.com/engine/installation/linux/linux-postinstall/

Introduction

Images and Starting & Stopping Containers

An image contains all the necessary files to start an application. This includes all libraries, system files, and configuration files. An image should only contain just enough files to get the application working.

To list all images on your system:

# docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
ubuntu              latest              2d696327ab2e        2 weeks ago         122MB
alpine              latest              76da55c8019d        3 weeks ago         3.97MB
hello-world         latest              05a3bd381fc2        3 weeks ago         1.84kB

To create a container, start a program with one of these images using the docker run command. A few common arguments that are passed to docker run are:

• -ti - terminal interactive (for interactive shells only)
• -d - start container detached; use docker attach <image id or name> to attach.
• --name - provides a name rather than the random one that is generated.
• --rm - removes the container after it stops (ie. the container application (in this example the shell) exits)

For example, to start a bash shell in the ubuntu image:

# docker run -ti --rm ubuntu:latest bash
root@c148fbe71597:/# cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=16.04
DISTRIB_CODENAME=xenial
DISTRIB_DESCRIPTION="Ubuntu 16.04.3 LTS"

You can see all running docker containers using the docker ps command. Common arguments to docker ps are:

• -a - To see all containers including ones that have stopped
• -l - Print the last stopped container

# docker ps -a
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS                       PORTS               NAMES
3ab813a72c70        ubuntu:latest       "bash"              5 minutes ago       Exited (130) 5 minutes ago                       agitated_dubinsky
2c4251af3005        alpine:latest       "bash"              6 minutes ago       Created                                          eager_murdock
d9f2d1a0025c        hello-world         "/hello"            29 minutes ago      Exited (0) 29 minutes ago                        musing_lewin

Docker containers can be referenced either by their container ID (which is a hash), or the randomly generated name.

A stopped container can be 'saved' back into an image using the docker commit command. There are two ways to go about this:

Manually commit the container ID (the hash), and then tag the image ID with an image name. # docker commit <container id> returns <image id> # docker tag <image id> <image tag>

Or, commit the container using the randomly generated name and the image name. # docker commit <container name> <image tag> returns <image id>

Dealing with Stopped Containers

A container is stopped if all processes in the container terminates (whether intentionally, segfaults, or if a stop/kill signal was sent to it).

To stop a running container, use either the docker stop or docker kill commands.

A stopped container can also be started again using docker start. Interactive commands (like a bash shell) will require the -ai flags.

Troubleshooting a stopped container can be done by viewing any generated output generated by the container with the docker log command. While all text output generated by a container is logged by docker, it is still a good idea to rely on file logs for performance (docker log can be slow).

Networking

Docker provides networking to containers by providing something similar to a port forwarding between the host and the container. Inside port and outside port mappings are provided by the -p in:out/proto argument when starting a container.

The inside port is required. If no outside port is provided, docker will use the next available port on the host system. If no protocol is provided, docker will use TCP.

For example:

docker run --rm -ti -p 80:8080 web-server bash

A service listening on TCP port 80 inside the container will be accessible through TCP port 8080 on the host.

Side note: You can make docker containers listen only to the host by running something similar to docker run -p 127.0.0.1:1234:1234/tcp. Docker will forward host only traffic on tcp 1234 to the container.

When 'exposing' a particular port on a container, docker sets up the standard network model:

1. Create a veth/eth interface pair
2. Connect veth to the docker bridge (docker0)
3. Add eth to the docker container namespace
4. Assign an IP address on eth (within same network as docker0)
5. Create any port forwarding necessary to 'expose' ports (eg. append to the DOCKER IPTable chain).

Linking

Docker provides a way for containers to 'link' to other containers on the same host. By linking one container to another, applications can talk to other applications in a separate container directly. When starting a container linked to another container, Docker will automatically update the /etc/hosts file and set up networking such that applications can talk to the other container directly without requiring traffic needing to route through the host.

Example:

On the 'server': # docker run -ti --rm --name server ubuntu bash root@85bdf83d4477:/# cat /etc/hosts 127.0.0.1 localhost ::1 localhost ip6-localhost ip6-loopback fe00::0 ip6-localnet ff00::0 ip6-mcastprefix ff02::1 ip6-allnodes ff02::2 ip6-allrouters 172.17.0.2 85bdf83d4477

On the 'client': # docker run --rm -ti --link server --name client ubuntu bash root@60e2d5ad2dbc:/# cat /etc/hosts 127.0.0.1 localhost ::1 localhost ip6-localhost ip6-loopback fe00::0 ip6-localnet ff00::0 ip6-mcastprefix ff02::1 ip6-allnodes ff02::2 ip6-allrouters 172.17.0.2 server 85bdf83d4477 172.17.0.3 60e2d5ad2dbc

The client can connect to 'server' directly by hostname.

This may be brittle, especially if containers are stopped/restarted anytime in the future separately.

Dynamic Linking

Containers can be linked together by creating a docker network. This is similar to a private network between two or more containers.

To create a network and use it:

# docker network create example
# docker run --rm -ti --net=example ubuntu bash

Unlike linking in the previous section, container names are looked up using the docker DNS server. Starting and restarting containers will not break lookups since the DNS will always have the most up to date information (verses the static /etc/hosts file that gets generated on startup).

Docker networks can be listed using docker network ls and its configuration as JSON using docker network inspect example.

Dockerfiles

Dockerfiles are used to create images programatically. It is similar to a script which tells docker how to create an image.

The steps involved with using dockerfiles are:

1. Create a directory
2. Optionally, copy any custom files that are needed in this image to this directory.
3. Create a Dockerfile in the directory.
4. Run docker build to build the image

A dockerfile should contain at the very least:

# The base image to use
FROM baseimage:version

# Things to do on the base image. This can contain any number of RUN or COPY commands
# Each RUN or COPY command will generate a new docker image.
RUN yum install any-dependencies

# Expose any ports that are required
EXPOSE 80

# run the application
CMD ["python", "/some/app.py"]

Each line takes the image from the previous line and produces another image. That is, docker will keep track of all the resulting images that are created from each step of a dockerfile. Because docker only keeps tracks of end results of each step, try to make each step produce the smallest image as possible to reduce bloat. (For example: Do download, compile, install, clean as one step rather than 4 separate steps. By keeping everything in one step, the image only has the compiled binaries rather than if split across 4 images which keeps track of source, and everything in between.) When re-running dockerfiles, docker will make use of existing images as best it can. As such, keep frequently changed lines near the end of the dockerfile.

Keep in mind that images do not have state (programs are not running) -- starting a program in one step of the dockerfile will not persist on the next step.

To build the dockerfile in the current directory (.):

# docker build -t name-of-result .

After building, the resulting image will be in the local docker registry.

Swarm Mode

See Also: https://docs.docker.com/engine/swarm/

Swarm mode is the cluster management and orchestration features embedded in and bundled with the Docker engine. A swarm can be deployed using a file that declares the state of components (ie. services) in an application. Swarms can span multiple machines.

Swarm mode enables features such as docker secrets used for storing passwords or sensitive data required by a container.

To create a swarm:

# docker swarm init

If you wish to join an existing docker swarm, use docker swarm join followed by the token and server address.

Use Docker Compose to define your application. See https://github.com/docker/labs/blob/master/beginner/chapters/votingapp.md

To deploy an application:

# docker stack deploy --compose-file docker-stack.yml vote

To verify the stack:

# docker stack services vote

To remove a stack

# docker stack rm vote

Other Notes

To detach from a container, use the key combination Ctrl+P Ctrl+Q.

To run another program in an existing container, use the docker exec command with the same commands as run.

Don't fetch dependencies when containers start. Instead, make it part of the image.

Resource constraints: docker run --memory max-memory docker run --cpu-shares (relative to other containers) docker run --cpu-quota (limit in general)

Tags if not provided will be 'latest'

When using Docker's Ubuntu image, you will want to:

# apt-get update
# apt-get install iputils-ping iproute2

Changing Docker IP Subnets

Docker will use the 172.17.0.0/16 for its internal networking. To run docker on networks that utilizes this network range, you will need to change docker's bridge IP address.

# ip a
3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN
    link/ether 02:42:68:e8:2f:99 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 scope global docker0
       valid_lft forever preferred_lft forever

To change docker's bridge IP address, stop the docker service (systemctl stop docker and then edit /etc/docker/daemon.json (Create it if it doesn't exist) with the following:

{
  "bip": "192.168.252.1/22"
}

Restart the docker service using systemctl start docker.

Ensure that docker has updated the docker bridge IP and also the IPTable masquerade rules.

# iptables -t nat -L

You can also manually clear the docker rules:

# systemctl stop docker
# iptables -t nat -F POSTROUTING
# ip link set dev docker0 down
# ip addr del 172.17.0.1/16 dev docker0
# ip addr add 192.168.252.1/22 dev docker0

See Also: https://docs.docker.com/engine/userguide/networking/default_network/custom-docker0/

See: https://docs.docker.com/engine/swarm/networking/#customize-the-docker_gwbridge The docker_gwbridge is a virtual bridge that connects the overlay networks (including the ingress network) to an individual Docker daemon’s physical network. Docker creates it automatically when you initialize a swarm or join a Docker host to a swarm, but it is not a Docker device. It exists in the kernel of the Docker host. If you need to customize its settings, you must do so before joining the Docker host to the swarm, or after temporarily removing the host from the swarm.

# docker network inspect docker_gwbridge

Stop or disconnect all containers attached.

# docker network disconnect --force docker_gwbridge gateway_ingress-sbox

Then, remove and recreate the bridge:

# docker network rm docker_gwbridge
# docker network create \
--subnet 192.168.250.0/22 \
--opt com.docker.network.bridge.name=docker_gwbridge \
--opt com.docker.network.bridge.enable_icc=false \
--opt com.docker.network.bridge.enable_ip_masquerade=true \
docker_gwbridge

Docker Compose

Docker compose builds docker applications from one or more docker containers. The configuration file used by docker compose is a yaml file.

Networking

Ports:

Expose ports. Either specify both ports (HOST:CONTAINER), or just the container port (a random host port will be chosen).

• Ports mentioned in docker-compose.yml will be shared among different services started by the docker-compose.
• Ports will be exposed to the host machine to a random port or a given port.

Example:

mysql:
  image: mysql:5.7
  ports:
    - "3306"

Port 3306 will be exposed on the host machine (and to the internet)

Expose:

Expose ports without publishing them to the host machine - they’ll only be accessible to linked services. Only the internal port can be specified.

Ports are not exposed to host machines, only exposed to other services.

mysql:
  image: mysql:5.7
  expose:
    - "3306"

Port 3306 will not be exposed to the host machine; it can only be 'linked' to other containers.

Mounting NFS in Docker

See https://github.com/ContainX/docker-volume-netshare

Can't build it on CentOS, get this error:

# go build github.com/ContainX/docker-volume-netshare
src/github.com/ContainX/docker-volume-netshare/netshare/drivers/ceph.go:44: undefined: volume.Response
src/github.com/ContainX/docker-volume-netshare/netshare/drivers/ceph.go:68: undefined: volume.Response
src/github.com/ContainX/docker-volume-netshare/netshare/drivers/cifs.go:76: undefined: volume.Response
src/github.com/ContainX/docker-volume-netshare/netshare/drivers/cifs.go:128: undefined: volume.Response
src/github.com/ContainX/docker-volume-netshare/netshare/drivers/driver.go:23: undefined: volume.Response
src/github.com/ContainX/docker-volume-netshare/netshare/drivers/driver.go:23: undefined: volume.Request
src/github.com/ContainX/docker-volume-netshare/netshare/drivers/driver.go:47: undefined: volume.Response
src/github.com/ContainX/docker-volume-netshare/netshare/drivers/driver.go:47: undefined: volume.Request
src/github.com/ContainX/docker-volume-netshare/netshare/drivers/driver.go:61: undefined: volume.Response
src/github.com/ContainX/docker-volume-netshare/netshare/drivers/driver.go:61: undefined: volume.Request
src/github.com/ContainX/docker-volume-netshare/netshare/drivers/driver.go:61: too many errors

Using binaries from https://github.com/ContainX/docker-volume-netshare/releases

Usage Reference

Command	Description
docker images	Lists docker images that you created or pulled using docker pull
docker pull	Pulls a docker image from a registry (can be from docker.io or a private registry) Version numbers can be given after a colon.
docker run	Runs a command in a container. Eg. docker run alpine ls -l For commands that require an interactive shell, pass in -it. Pass in --name for a custom name instead of a long hash Pass environment vars using -e Pass -d to detach immediately Pass -P to specify the image
docker exec	Starts another process in the specified container. Eg: docker exec -ti container-name bash
docker ps	Lists containers that are running. Pass -a to see all containers that executed.
docker port	shows the port mapping between the container and the host.
docker stop	Stop a container (By sending SIGSTOP?)
docker kill	Stops a container (By sending SIGKILL?)
docker rm	Removes a container. Use -rf to stop and remove.

Deploying an Application

Use Docker Swarm mode to deploy an application that relies on multiple services where each is a separate docker instance.

The swarm file lets you define each server that is part of the application.

See more at https://github.com/docker/labs/blob/master/beginner/chapters/votingapp.md

Questions

• How does one run a newer distro on an old host kernel that may have a different kerenl ABI or different sets of available syscalls?
  • For the most part, the kernel system calls are the same. There should be no problems running older distros since the kernel retains backwards compatibility. Newer distros may be an issue however.

• What are the security implications of root inside the container? Can they break out of the container context?
  • https://github.com/rootwyrm/lxc-media/tree/master/systemd_transmission
  • https://www.reddit.com/r/freebsd/comments/5vfj3w/docker_vs_jails/

• How are updates to the base image done? Does it automatically update containers relying on it? Or will containers need to be rebuilt again?
  • Images are supposed to be immutable. When starting an image, any data that needs to be persistent must be externally provided as volumes using -v outside/path:inside/path. When the base image is updated (say, CentOS 7.2 to CentOS 7.3), all images relying on it will need to be rebuilt from the Dockerfile. The resulting image is then used to 'relaunch' the container.

• How is data kept persistent? Does it need to be copied out/in every time it is to be rebuilt?
  • Persistent data should be saved outside of the container using the -v outside/path:inside/path.

• NFS access from the container?
  • You must use something like docker-volume-netshare in order to have NFS volumes in the docker container. It does not seem like you can map an existing NFS volume to a docker volume.

• Domain trust - is it the same as a regular VM?
  • Yes. If domain trust in a docker container is required, it's best to send the domain credentials using docker secrets (as part of a swarm) and join the domain using the entry point shell script (or during the build stage, but keep in mind that hostnames may change and you may have multiple instances of it).

Could it be used for:

• dictd - yes
• WebCat (tomcat + MySQL) - yes
• ftp (Requires NFS) - yes*
• compute balancer - yes
• firewall manager (swarm apache + MySQL) - yes
• pages (NFS + AD integration for mod_userdir) - yes

See Also

• https://github.com/docker/labs/tree/master/beginner/
• http://blog.yohanliyanage.com/2015/05/docker-clean-up-after-yourself/