Docker. Network settings

Docker network settings are the following:

--dns for setting up DNS server, which will be used by container.

-- dns-search. FQDN part without host name.

If --dns or --dns-search is not given, then the /etc/resolv.conf ile of the container will be the same as the /etc/resolv.conf file of the host the daemon is running on.

-h –hostname allows to setup the hostname of the container. The related record  will be added to the etc/hosts.

--link. Allows to setup the connection to other container. Knowledge IP of other container is not required. Only the name of the container.

To assign the name to the container one should use --name flag.

For example, there are two containers: web and db. To create the link between containers one should stop the web container and start it with --name flag like this:

 # docker run -d -P --name web --link db:db <image> startserver.sh

By using docker -ps you can see the links between containers.

Also in containers env variables and /etc/hosts are altered.

Also, container can bind the ports to the host ports. Use-p flag:

1. docker run -p IP:host_port:container_port

2. docker run -p IP::container_port

3. docker run -p host_port:container_port

When necessary containers can be moved to another subnet. For this the docker daemon should be used with —bip flag.

Docker. Limit container resources.

Here is how to limit the containers resources:

Limit by CPU:

Use docker run -c option.

Limit RAM:

docker run -m 1024m

Limit by HDD:

There is no universal way to achieve it. It is recommended to use devicemapper storage driver.

Also, by default the size of container is 10 Gb. This can be tuned by changing the parameter dm.basesize.

Docker. Storage driver for CentOS 7.1

By default, when starting Docker container following message appears:

Usage of loopback devices is strongly discouraged for production use. Either use `--storage-opt dm.thinpooldev` or use `--storage-opt dm.no_warn_on_loop_devices=true` to suppress this warning.

Reading the man docker page reveals the following:

The only backend which currently takes options is devicemapper.

Docker. Application logging patterns inside container

Here are three patterns on how to get the logs from the Docker container.

First, use -v option to mount a file location inside the container  to the location inside the host file system. The -v option gives you flexibility on where to redirect files.

Second, use centralized logging server. For example, Kafka queues for further processing.

Third, you can use shared volumes from another container to pull logs into another running container. This way can save up processing resources. Imagine that every system runs a service to send logs, than it would be waste of resources to send logs from every container. Instead pull the logs into one container and use a single logging service to send logs.

Docker. Logs. CentOS 7.1

To view the container logs you should run  `docker logs <container id>`.

By default container logs are located in

/var/lib/docker/containers/[CONTAINER ID]/[CONTAINER_ID]-json.log.

Logs are constantly increasing. So they should be cleaned up on a timely base.

In Docker 1.8 and up there is built in logs rotation mechanism.

The current best practice for rotation of Docker logs is to have logrotate use the copytruncate method to copy the logfile and then truncate it in place.

For this create the file `/etc/logrotate.d/docker-container`

with the following content:

/var/lib/docker/containers/*/*.log {

rotate 7

daily

compress

size=1M

missingok

delaycompress

copytruncate

}

Update the logrotate config:

logrotate -fv /etc/logrotate.d/docker-container.

That is all.

There is a possibility to redirect logs to different backends with parameter --log-driver.

By default json driver is used. In case of other log drivers the built in docker command 'docker logs` stops working.

Docker. Install on CentOS 7.1

A lot of blog posts and articles today are written about Docker.
What is this all about?
Docker is an open-source project that automates the deployment of applications inside software containers, by providing an additional layer of abstraction and automation of operating-system-level virtualization on Linux, Mac OS and Windows.